[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

More questions on ID types


   I thought I understood the role of IDs but I am not so sure any more.
   I hope some one on this list can help. I used to think that the 
   (mandatory) IDs in phase I identify ISAKMP participants (the initiator
   and responder) and (optional) phase II IDs identify clients, 
   such as subnets, for which the ISAKMP participants negotiate
   tunnel-mode IPSec SAs. A typical scenario might be two firewalls
   that use ISAKMP to negotiate IPSec SAs for two subnets -- each subnet
   represents a branch office and hosts on these subnets wish to 
   communicate across the Internet using a secure tunnel.
   
   According to the latest ISAKMP draft, the only ID types allowed in
   phase I are: ID_IPV4_ADDR, ID_IPV6_ADDR, ID_IPV4_ADDR_SUBNET,
   ID_IPV6_ADDR_SUBNET. With the reasoning above, I can see how the
   first two make sense as IDs for phase I. However, the latter two
   ID types seem more appropriate for use in phase II.

   I have some concerns about limiting phase I IDs to these four types.
   I am interested in the use of IPSec in remote access scenarios
   (details in draft-gupta-ipsec-remote-access-00.txt). In particular,
   I'd like to use IPSec to securely connect a road warrior (attached
   to the Internet using a dynamic, ISP-allocated address) to his
   corporate Intranet. In order to minimize the changes required within
   the Intranet, I'd like to use IPSec in "end-to-edge" mode
   i.e. from the remote computer (R) to an IPSec gateway (G) on the
   Intranet's periphery. Most Intranets assume mutual trust between
   internal hosts and use addresses that are not advertised on the
   Internet (even when they are globally unique). Private addresses
   on the Intranet can be handled by using NAT  (network address and
   port translation) or dynamically assigning the remote host an
   internal address (as described in the ISAKMP configuration draft).
   However, before anything else,  R must set up an ISAKMP SA with G.
   Assuming that preshared keys are used for phase I authentication,
   R needs to convey an identity that G can use to look up its preshared
   secret associated with R (or the employee authorized to use R).
   Since R communicates with G using a dynamic ISP address, what 
   identity type should it use in phase I -- ID_IPV4_ADDR doesn't 
   help because there is no "fixed" address associated with the
   portable that could be used to look up the preshared secret.
   
   If ID_USER_FQDN or ID_KEY_ID were allowed as valid phase I 
   ID types, they could be used effectively in this situation.

   Am I missing something here? Thanks for your time.     
   
   vipul
   
   
> To: Vipul Gupta <vgupta@nobel.eng.sun.com>
> cc: ipsec@tis.com, vipul.gupta@Eng
> Subject: Re: Question about ID types in IPSEC DOI 
> Date: Thu, 25 Jun 1998 18:27:28 -0700
> From: "Derrell D. Piper" <ddp@network-alchemy.com>
> 
> Vipul,
> 
> The is a actually a bug in the current DOI.  Since the last draft of ISAKMP,
> the IPSEC DOI ID types apply only to Phase 2 negotiations.  The valid Phase 1
> types are now listed in the ISAKMP draft (and are much more limited).  
> 
> The ID_KEY_ID type predates the ISAKMP Vendor ID payload and should probably
> be deprecated in favor of that, since it's essentially a private extension.
> 
> Who's using this type in Phase 1?
> 
> Derrell
>