Re: Adding revised identities to IKEv2

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   >But it shows we have to understand exactly what could/should
   >be the usage of addresses in key management protocols too (see after).
   
   Why? What people have found from many years of VPN deployment is that 
   customers generally want one of two things:
   - The ability to say "let any gateway with this identity set up any 
   kind of tunnel with me"
   - The ability to say "let the gateway with this identity set up a 
   tunnel with these features"
   For preshared secrets, there is no question of the identity. For PKIX 
   certificates, the identity problem is so convoluted, almost all 
   customers say "any identity is OK as long as the certificate 
   correctly chains to this trusted root". The identity is logged, but 
   the type of identity is not related to the ability to set up tunnels.
   
=> there is no agreement about what checks must be done:
 - common sense says the identity must be a subject of the certificate
   (but this is not clearly specified in IKEv1 and perhaps some
    implementations don't perform this check)
 - if the identity is an address, one can verify this is the address
   IKE runs over or can accept a different address. The current
   specs (until your proposal) are really loose about this point.
 - the lack of protection of peer addresses is a security flaw,
   IMHO customers want to set up a tunnel with the gateway, not
   with an unknown box (:-). I understand the need for a NAT
   traversal feature but I disagree to get a security flaw even
   when I know there is no NAT on the path.

   >  A little point: if the URL is to the initiating machine there can be
   >some bootstrap problems (to get it can need an IPsec-protected connection
   >to the initiator), so this case should be added to the unresolvable URLs.
   
   It would be silly to put your cert *behind* your gateway. But the 
   gateway itself might have a trivial HTTP server to allow access to 
   certs; in fact, this is what many people expect to happen.
   
=> I agree this kind of bootstrap problems comes from silly configurations
but the IPv6 neighbor discovery issue showed these silly configurations
happen in the real world so they should be handled. In this case
the "unresolvable URLs" case should be extended to the inaccessible
because of IPsec cross-dependence case.

Thanks

Francis.Dupont@enst-bretagne.fr