Re: IKEV2: Issue #4 Revised Identity

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

On Tue, Feb 11, 2003 at 10:34:48AM -0800, Paul Hoffman / VPNC wrote:
> >        The choice between the working group, then is between using
> >        language taken from pki-profile-01 to make explicit when
> >        certificate payloads are sent, or choosing the
> >        revised-identity proposal.  More comments about the tradeoffs
> >        inherent between these two choices are hereby requested.
> 
> So, let's ask the WG chairs then: is Eric's interpretation correct? 
> Is this also a WG last call on pki-profile-01? If not, then IKEv2 
> will be plagued with the same interop problems that IKEv1 has. If it 
> is a last call, the WG should be discussing the document, which has 
> gotten no traffic to date.

If you take a close look at the pki-profile ID, you will find that it
is really two documents in one.  Following the introduction and the
background information, section 3 is a profile of ISAKMP/IKEv1, and
section 4 is a profile of PKIX/x.509 certificates.  

If you then take a closer look at section 3, a good part of the
material in section 3 are definitions already found in the IKEv1 and
IKEv2 drafts (but which were necessary to make pki-profile a
standalone document), and the rest are a tightening up of the
requirements, because IKEv1 was too loose in its specifications.  For
example, pki-profile states that if in-band certificats are expected,
implementations MUST inform the peer of this by sending at least one
CERTREQ, and that implementations MUST respond to CERTREQ's by sending
a CERT payload with the appropriate certificate.  

This is all arguably good stuff that should have been in the original
IKEv1 specification, but which was very unfortunately missing.  If it
had been there, I suspect most of the interoperability headaches that
IKEv1 implementors suffered from could have been avoided --- and I
believe a goood part of what is in the pki-profile is essentially
summarizing what IKEv1 implementors have had to discover the hard way
from bakeoffs, and codifying it into a specification.  In essense,
pki-profile supplies the semantics to IKEv1, which in the case of the
CERT and ID payload, very unfortunately had synxtax only, but no
semantics in its original specification.  

In our summary of the revised identity issue, we pointed to comments
made by at least two working group members, who stated that an
alternative to revised identity would be to adopt text from the
pki-profile ID to fully define certificate handling.  Presumably, this
would be taking selected text from section 3 of this document, which
arguably should have been in IKEv1 in the first place, and not in a
separate profile document.  Fortunately, we have an opportunity to fix
this in IKEv1, and Francis Dupont stated that if we didn't incorporate
the revised-identity proposal, that taking text from pki-profile-01
would be a requirement.

Hence, our sumary of the discussion on this issue pointed out what we
believe are the alternatives facing the working group:

#1) adopting text from the revised-idendity I-D and including it into
	the ikev2 I-D

#2) adopting text from the pki-profile I-D and including it into ikev2 I-D


I am in agreement with you in that I wish there had been more
discussion on both proposals.  Howeer, neither I-D is new, and to my
knowledge no one has shown substantive, show-stopping technical
problems with either text.  They have tradeoffs, to be sure, and
indeed the dispute seems to center around preferences towards one
engineering tradeoff versus the other.  But one way or another, we
need to decide.

						- Ted