Re: Requirements for IKEv2 implementations

[Charlie_Kaufman@notesdev.ibm.com]

> 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 was a long though indecisive discussion of RSA vs DSS keys and
required key sizes about six months ago. I don't believe the other issues
have been discussed.  I believe there has been expressed a consensus for
for following very ambitious goal: it must be possible to configure any two
implementations that conform to the RFC to interoperate. I have been adding
conformance requirements as people point out places where the spec allows
two implementations that include all of the MUSTs to fail to interoperate.
I'm sure we will find more in interoperability testing, but we should find
only bugs in implementations and bugs in the spec. Not legitimately
differing interpretations.

There will certainly be cases where the goal will not be met. There are
asymmetric cases where a laptop designed to connect to a corporate firewall
may not have a smarts to accept a connection from a similarly configured
laptop. And the "can be configured" language is critical. Deployments are
likely to restrict what forms of authentication they accept and what
algorithms they use. So in some sense, requiring configurability doesn't
guarantee anything. But in practice, I believe it will make a big
difference.

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

I have no particular preference here. In the early days of IKEv2, there was
no shared key authentication, so certificate based authentication was a
MUST. At first, shared key authentication was optional, but I was convinced
that because of its wide deployment in IKEv1, it also should be a MUST. I
think it would be fairly harmless to make authentication using raw RSA keys
also be a MUST, but no one made a case for it until now. I think it would
be a mistake to remove the requirement for certificate based
authentication, because it is hard, people would be tempted to leave it
out, and I believe that's where we want to end up in the long run. But it's
not my decision... what do people want?

I would have expected the issue of ID types to be more controversial. I
added the language last year attempting to respond to the issues raised by
your Revised Identity proposals.

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

As currently written, a node may identify itself by any of those four ID
types, and the other end MUST be capable of accepting any of them and using
them to find a policy (again, must be capable of being configured to accept
any of them). If this set were smaller, it would make life easier for the
parsers but less flexible in terms of allowed configurations.

      --Charlie