Re: IKEV2: Issue #4 Revised Identity

["Theodore Ts'o" <tytso@mit.edu>]

On Wed, Feb 12, 2003 at 02:36:51PM +0100, Pekka Riikonen wrote:
> 
> The revised identity can solve the problem of defining what the ID
> actually is and when not to send certificates.  

Well, the revised identity draft does solve the problem, essentially
be eliminating the ID and CERT payloads altogether, conflating the
IKEv1 concept of identity and certificate, and instead always
requiring both sides to send a certificate, which *is* the identity.  

> However, having read the draft it is in my opinion clear that same
> features can be accomplished without introducing new payloads, but
> using the Certificate Request (CR) payload, and revising the
> specification for this payload.  

Well, yes, and that's what the pki-profile document does, and without
needing to change the IKEv1 specification (but instead making the
specification tighter):

   3.3.7. Presence or Absence of Certificate Request Payloads

   When in-band exchange of certificate keying materials is desired,
   implementations MUST inform the peer of this by sending at least one
   CERTREQ. An implementation which does not send any CERTREQs during an
   exchange SHOULD NOT expect to receive any CERT payloads.

	...

   3.3.8.1. Specifying Certificate Authorities

   Implementations MUST generate CERTREQs for every peer root that local
   policy explicitly deems trusted during a given exchange. Implementa-
   tions MUST populate the Certificate Authority field with the Subject
   Name of the trusted root, populated such that binary comparison of
   the Subject Name and the Certificate Authority will succeed.

   Upon receipt of a CERTREQ where the Certificate Type is either "X.509
   Certificate - Signature" or "X.509 Certificate - Key Exchange",
   implementations MUST respond by sending each certificate in the chain
   from the end entity certificate to the certificate whose Issuer Name
   matches the name specified in the Certificate Authority field. Imple-
   mentations MAY send other certificates from the chain.

The IKEv1 interoperability problems arose because IKEv1 underspecified
how the payloads should be used.  

> What is nice about revised identity draft (as opposed to pki-profile) is
> that it allows the use of URL to tell where the cert is available.  This
> too could be done by revising the Certificate payload by adding new
> encoding types (like URL) if this feature is really needed.

As I have pointed out in the past, this could be added to IKEv2 (and
IKEv1) for that matter, simply by defining a new certificate encoding
type to the CERT payload.  This issue is independent of whether to use
a IKEv1 or Revisied identity-style approach.  The tradeoffs are
reducing the UDP packet size, versus additional complexity caused by
(a) needing to have some kind of access controls since you don't want
to responder to visit an arbitrary URL based on an unauthenticated
request from the initiator, and (b) dealing with the case where the
initiator doesn't have access to the global internet (i.e., in the
dialup VPN case), and is presented with a certificate URL.

						- Ted