Fixing identity and cert-sending

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

We have an opportunity in successor-to-IKE to fix two major problems that
have plagued us in IKEv1: a misunderstanding about what is identity, and
having to send certificates every time because you don't know if the
other party already has your certificate.

This proposal (which could work in either IKEv2 or JFK) covers both
topics at once because it turns out that they are related. Suggestions
are welcome.

The discussion below is for the successor-to-IKE proposals. Ignore
everything about today's cert, certrequest, and ID payloads; they will
not be used.

Messages 1 and 2 MAY include a TrustedRoot payload. The TrustedRoot
payload includes a series of one or more PKIX keyIdentifiers of roots
trusted by the sender. This payload is completely optional and is
used only to inform the recipient of what capabilities the sender has.

Messages 1 and 2 MUST include exactly one IDAccepted payload. The payload
holds a series of one or more fields indicating the FullID types that the
sender will accept. The receiver MUST NOT send any FullID payloads that
are not listed in the sender's IDAccepted payload.

Messages 3 and 4 MUST include exactly one FullID payload. The payload's
format is an ID type followed by content. The ID types are:

1  PKIX cert -- A standalone PKIX cert.
2  Cert bundle -- A simple ASN.1 sequence of PKIX certs. A bundle can
       have end-entity certs or cert chains. The first cert in the bundle
       is the sender's preferred identity certificate, but beyond that
       there is no meaning to the ordering.
3  Hash-and-URL of PKIX cert -- The first 20 octets are the SHA-1 of a
      certificate; the rest is a URL that resolves to the cert. This is
      described in more detail below.
4  URL to a PKIX cert bundle  -- This is described in more detail below.
5  PKIX keyIdentifier -- Identifies a self-signed certificate that the
      receiver has already pre-loaded. Note that this is only useful when
      using self-signed certs.
6  IDForSharedSecret -- This is only for use with shared secrets. It is an
      ASCII string (all octets are 31 < x < 127) of any length.

For ID types 3 and 4: the URL scheme must be http, although it can be on
any port, and there might be requirements for how the named part looks.
The URL might be to a persistent repository, or it might be to the
initiating machine (such as in a remote access client). For type 3, the
recipient might cache the cert with the hash as an index, or it can be
retrieved from the URL.

If a system that is using certs knows that it cannot resolve URLs (because it
is not yet on the Internet), it should use 1 and 2 in its IDAccepted payload.
If a system can resolve URLs, it should use include type 3 and 4. All systems
should be able to handle bundles because the other party might have multiple
identities which have different certificates.

There will be new error codes:
- Could not get your cert through the URL
- Could not get your cert bundle through the URL
- Bundle was malformed
- Could not find the cert that matches the keyIdentifier
- Could not use your IDForSharedSecret

The authentication data needs to specify what kind of authentication
is being used (signed or HMACed).

--Paul Hoffman, Director
--VPN Consortium