Re: Adding revised identities to IKEv2

["Padmapriya Parthasarathy" <padmapriyap@hotmail.com>]

 > 
> > - with regard to identities, IPsec supports two basic types of 
> > identities: addresses and symbolic names. 
> 
>And symbolic names IMHO is the only way to establish/authenticate a 
>secure connection in a dynamic environment. 
> 
> > - when names are used as identities, we need to be able to map the 
> > name to a current address (during SA establishment) so that we can 
> > make later decisions on a per-packet basis using the current address. 
> 

>Absolutely. But start from symbolic names, and map them to IP address 

>for Phase 2. Seems easy/trivial to implement. 

Do we really do this mapping ? We either get separate ID payload in phase II or the ip headers implicitly carry the phase II identity. Do we ever try to validate this with the phase I identity e.g. mapping the FQDN in Phase I to the IP address in Phase II (or reverse lookup of IP address to phase I identity) or checking with the address in certificate with the one in Phase II. 

thanks

priya

 
> > - we don't have to trust an IPsec peer to assert the right name for 
> > itself or an entity behind it. we need to have an authentication 
> > mechanism that allows us to verify that the asserted name is valid 
> > relative to some framework for names. 
> 
>Oh sure. If I say the entity name is "Uri Blumenthal" - then there has 
>to be a key/cert associated with that name. As it only matters for 
>signing the Phase 1 exchange to validate IP address from which the 
>traffic is originating, for subsequent Phase 2 things. 
> 
> > I suggest that we better document these notions, and offer as 
> > examples, the sort of identification and authentication processes I 
> > note above as we go forward with IKE v2. Comments? 
> 
>I strongly support. 
> 
>And I want a relaxed identification - something like "as long as 
>I can associate a key with the identity, the identity is OK". 


----------
MSN 8 helps

ELIMINATE E-MAIL VIRUSES. Get 2 months FREE*.