IKEV2: Issue #4 Revised Identity

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

This item has not received as much discussion as the working group
chairs have hoped.  In the past week, Paul Hoffman has sent a message
questioning the process by which the working group chairs would
attempt to determine the consensus position of the working group.
Our position about this the process issue has been addressed in an
earlier message.  

As far as technical discussion of this proposal, Cheryl Madson and
Scott Kelley both agreed that from a requirements standpoint, the
behavior under-specification of certificate handling in IKEv1 needs to
be avoided.

Francis Dupont noted that either revised-identity draft or sections
of the draft-ietf-ipsec-pki-profile I-D would serve to fully define
certificate handling.  This point was echoed by Michael Choung Sheih,
who pointed out that the pki-profile document would address these
issues.

Derrell Piper agreed, and also expressed concerns about how "the
management paradigm for many vendors is tied to the existing IKE
identity types, so wholesale revision on this area might well
represent a serious headache for many vendors".  He was also concerned
that implementing revised-identity might force vendors to "start from
scratch" at the next IKE bake-off.  He contrasted this with the impact
of the other IKEv2 protocol changes, which are largely transparent
(aside from the need to delete some options) to existing management
software, end-user documentation, and regression testing.

Gregory Lebovitz has spoken up in favor of revised identities, agreeing
with the central premise of the revised-identity I-D that by using the
certificate itself as the identity, it eliminates a number of
interoperability problems which original IKE implementations suffered
at the bakeoffs.  (This issues have largely been settled at this
point, although to quote Cheryl Madson, "the WG has been extremely
apathetic about any attempts to clarify things", by which presumably
she is referring to the pki-profile I-D, and perhaps earlier attempts
to specify certificate handling.)   

Gregory also argued that most deployed uses of IPSEC are using shared
secrets, and are not certificates, and that that therefore this is an
opportunity to simplify how certificates and identity are handled.
While it is certainly a true statement that IKEv2 represents an
opportunity to change how certificates are handled, the deployment
status of certificate-based IPSEC clients/servers seems to be mostly
irrelevant to the question at hand, since nearly all or most IPSEC
implementations support certificates.  Gregory's observation does
imply, however, that the number of customers/administrators that might
require retraining is small; however, it does not change the work
required of IPSEC implementors to make (perhaps significant) changes
to the implementation, documentation, and training to support the
revised identities.

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.

					Barbara Fraser
					Ted Ts'o
					IPSEC working group chairs