Re: Adding revised identities to IKEv2

[Paul Hoffman / VPNC <paul.hoffman@vpnc.org>]

At 3:52 PM +0100 11/6/02, Francis Dupont wrote:
>  In your previous mail you wrote:
>
>    Greetings again. draft-ietf-ipsec-ikev2-03 adds some new functionality
>    to IKEv2, but doesn't cover better use of identities and certificates.
>
>=> I really prefer your way to deal with identities/certificates than
>the traditional IKEv[12] one with its unspecified link between identities
>and addresses.

Thank you.

>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.

>  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.

--Paul Hoffman, Director
--VPN Consortium