Requirements for IKEv2 implementations

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

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