RE: Requirements for IKEv2 implementations

[Gregory Lebovitz <Gregory@netscreen.com>]

...Interesting silence to this post...

MY WG and Security Area member perspective: 
Certificates are good security and we should try as much as we can to help
implementations adopt them. Any worthwhile IKEv1 implementation today can
handle certs. IKEv2 should be no different.

My NetScreen employee perspective:
Our implementations do both today, so its no big deal if certs are required.

Market observer perspective:
PKI has been a royal pain for many interested in IPsec VPNs. Just ask the
PKI vendors. They have abandoned the application as a focus for their
development, marketing and sales. At an absolute minimum, PSS is a MUST. 

Gregory.

> -----Original Message-----
> From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]
> Sent: Saturday, April 26, 2003 4:21 PM
> To: ipsec@lists.tislabs.com
> Subject: Requirements for IKEv2 implementations
> 
> 
> Greetings again. The -05 draft of IKEv2 introduced the 
> following requirements:
> 
>     For an implementation to be called conforming to this 
> specification,
>     it MUST be possible to configure it to accept the following:
> 
>     PKIX Certificates containing and signed by RSA keys of 
> size 1024 or
>     2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN,
>     ID_RFC822_ADDR, or ID_DER_ASN1_DN.
> 
>     Shared key authentication where the ID passes is any of ID_KEY_ID,
>     ID_FQDN, or ID_RFC822_ADDR.
> 
>     Authentication where the responder authenticates using PKIX
>     Certificates and the initiator authenticates using shared key
>     authentication.
> 
> I don't remember seeing this discussed in the WG before now.
> 
> There are many reasons why an implementation might not want to 
> support PKIX certificates, including the fact that many vendors find 
> that PKIX is too complicated to support securely. In some security 
> environments, other forms of public key infrastructures are more 
> appropriate for some security uses. And, of course, for systems that 
> have the ability to create and distribute good shared secrets, PKIX 
> support is just dangerous bloat.
> 
> The minimum that is needed for interoperability is shared secrets. 
> The document already has requirements for handling large shared 
> secrets, so we don't need to worry about limitations that reduce to 
> passwords. Requiring both shared secrets *and* PKIX-specific public 
> key support does not help interoperability, and because of the nature 
> of PKIX, hurts it significantly. We only need to mandate one or the 
> other, and given the ugly reality of PKIX, it should only be 
> sufficiently long shared secrets.
> 
> --Paul Hoffman, Director
> --VPN Consortium
>