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

Re: addresses and IKEv2



At 09:07 AM 5/20/2002 -0400, Stephen Kent wrote:
>At 4:38 PM -0700 5/17/02, Alex Alten wrote:
>>
>>  >Alex,
>>>
>>>I assume you have read the new ESP ID from last fall, as well as the
>>>new AH ID from this spring, and have followed the WG discussions of
>>>why the SA can be determined by examining just the SPI 9without
>>>referebce to the destination address), for unicast traffic.  Given
>>>that context, I'm not sure I understand your comments above.  Could
>>>you clarify?
>>>
>>>Thanks,
>>>
>>>Steve
>>>
>>
>>Steve,
>>
>>My comments only apply to the RFCs as they stand today.  SPI is a
>>different beast than what I'm discussing even with your latest ESP
>>ID adjustments.
>>
>>The fundamental problem is how can we identify a host unambigously in
>>real time in order to be able to automate the picking of the correct
>>crypto key used to authenticate it and then bootstrap the SA?  I don't
>>see the answer anywhere in the RFCs or IDs.  Certainly there are a lot
>>of documents and maybe I've missed seeing it.  I know that X.509 certs
>>are not the answer (the bound name/address is too static and can be
>>unreliable).
>>
>>- Alex
>
>if the concern is, as you state above, the initial binding of host ID 
>to a credential, then an X.509 cert with a name seems to address the 
>problem, irrespective of a static address binding.  IKE provides for 
>exchange of certs that contains names, e.g., DNS names or DNs, and if 
>one uses SPD entries with these symbolic names for IP address 
>selectors, the mapping to current addresses will happen dynamically.
>
>Steve
>

Steve, 

On the surface using a global name space like DNS seems like a good
idea.  But the fundamental problem is that a DNS name maps to an IP 
address which is already a slippery beast.  Also not every IP address
has a corresponding DNS name.  And a DNS name can map to multiple IP
addresses.  So the certificate binding of a DNS name to a Public Key is
not a practical approach.  A X.500 DN is even worse, except for LDAP
trees, it is hardly used.

A much better approach is to have a large, global numerical address space.
Each host then is assigned a unique security address from this space.  IP 
addresses can flit in and out of existence for a host, but it's security
address remains fixed, a least for the duration between enrollment and
revocation in an "IPsec global system".  If one can reliably assign a 
unique number to each host, then it can be used to look up the authentication
key in a secure database to verify that indeed a particular host is assigned
that number.  Once you can rely on this number, effectively a global host id,
it is much more practical to automate the setting up of a VPN between two
hosts, even in the context of Mobile IP or through a NAT or even between two 
different organizations.

It seems to me that until the issue of how to effectively identify hosts and
manage the resulting address space is agreed upon all the IKEs and JFKs
will be failures.  Or at best they will only be a way to automate the key
suite 
negotiation between two hosts (or VPN gateways), thus providing just a modest
advantage over the manual keying that dominates IPsec VPN setup today.

- Alex

--

Alex Alten
Alten@ATTBI.com