IKEV2: Issue #4 Revised Identity
"Theodore Ts'o" <tytso@mit.edu> Sat, 08 February 2003 05:28 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02190 for <ipsec-archive@lists.ietf.org>; Sat, 8 Feb 2003 00:28:24 -0500 (EST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA18380 Fri, 7 Feb 2003 22:37:10 -0500 (EST)
To: ipsec@lists.tislabs.com
Subject: IKEV2: Issue #4 Revised Identity
From: Theodore Ts'o <tytso@mit.edu>
Phone: (781) 391-3464
Message-Id: <E18hLq2-0001mO-00@think.thunk.org>
Date: Fri, 07 Feb 2003 22:39:34 -0500
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
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
- IKEV2: Issue #4 Revised Identity Theodore Ts'o
- Re: IKEV2: Issue #4 Revised Identity Eric Rescorla
- Re: IKEV2: Issue #4 Revised Identity Paul Hoffman / VPNC
- Re: IKEV2: Issue #4 Revised Identity Eric Rescorla
- Re: IKEV2: Issue #4 Revised Identity Paul Hoffman / VPNC
- Re: IKEV2: Issue #4 Revised Identity Eric Rescorla
- RE: IKEV2: Issue #4 Revised Identity Greg Carter
- RE: IKEV2: Issue #4 Revised Identity Paul Hoffman / VPNC
- Re: IKEV2: Issue #4 Revised Identity Eric Rescorla
- Re: IKEV2: Issue #4 Revised Identity Michael Richardson
- Re: IKEV2: Issue #4 Revised Identity Francis Dupont
- Re: IKEV2: Issue #4 Revised Identity Brian Korver
- Re: IKEV2: Issue #4 Revised Identity Eric Rescorla
- Re: IKEV2: Issue #4 Revised Identity Theodore Ts'o
- Re: IKEV2: Issue #4 Revised Identity Eric Rescorla
- Re: IKEV2: Issue #4 Revised Identity Theodore Ts'o
- Re: IKEV2: Issue #4 Revised Identity Michael Richardson
- Re: IKEV2: Issue #4 Revised Identity Michael Richardson
- Re: IKEV2: Issue #4 Revised Identity Bill Sommerfeld
- Re: IKEV2: Issue #4 Revised Identity Eric Rescorla
- Re: IKEV2: Issue #4 Revised Identity Eric Rescorla
- RE: IKEV2: Issue #4 Revised Identity Greg Carter
- Re: IKEV2: Issue #4 Revised Identity Pekka Riikonen
- Re: IKEV2: Issue #4 Revised Identity Paul Hoffman / VPNC
- Re: IKEV2: Issue #4 Revised Identity Eric Rescorla
- Re: IKEV2: Issue #4 Revised Identity Pekka Riikonen
- Re: IKEV2: Issue #4 Revised Identity Tero Kivinen
- Re: IKEV2: Issue #4 Revised Identity (fwd) Pekka Riikonen
- Re: IKEV2: Issue #4 Revised Identity Pekka Riikonen
- Re: IKEV2: Issue #4 Revised Identity Pekka Riikonen
- Re: IKEV2: Issue #4 Revised Identity Brian Korver
- Re: IKEV2: Issue #4 Revised Identity Pekka Riikonen
- Re: IKEV2: Issue #4 Revised Identity Russ Housley