Re: IKEV2: Issue #4 Revised Identity
Eric Rescorla <ekr@rtfm.com> Tue, 11 February 2003 08:54 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 DAA23916 for <ipsec-archive@lists.ietf.org>; Tue, 11 Feb 2003 03:54:39 -0500 (EST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA00300 Tue, 11 Feb 2003 01:59:58 -0500 (EST)
To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Cc: ipsec@lists.tislabs.com
Subject: Re: IKEV2: Issue #4 Revised Identity
References: <E18hLq2-0001mO-00@think.thunk.org> <kjn0l3o6t0.fsf@romeo.rtfm.com> <p05210328ba6e339fc43f@[63.202.92.156]>
Reply-To: EKR <ekr@rtfm.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 10 Feb 2003 23:07:13 -0800
In-Reply-To: <p05210328ba6e339fc43f@[63.202.92.156]>
Message-ID: <kjfzqvnvmm.fsf@romeo.rtfm.com>
Lines: 101
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Paul Hoffman / VPNC <paul.hoffman@vpnc.org> writes: > At 7:05 PM -0800 2/10/03, Eric Rescorla wrote: > >(1) There's no way to use caching without having HTTP access. > > Sure you can. You can cache earlier receipt of a full cert in IKE messages. How do you tell the peer that you don't want to get the cert in the revised identity scheme? > > What you actually want is for peer A to say "I have the > > following cert cached for you. Either send me an OK > > or send me a new cert." But there's no way to do that > > with this proposal. > > But that's a reasonable counter-proposal that gets to the same end: > not having to send certs each time, and therefore avoid the failure in > routers and firewalls that don't pass fragmented UDP. Without a > hash-of-cert mechanism, implementations will continue to suffer this > silent failure. You need some kind of mechanism. It doesn't necessarily have to be hash-of-cert. Section 3.3.11.2 of draft-ietf-ipsec-pki-profile describes how to make this work with the current CERTREQ payload (using the DN). > >(2) It's underspecified. > > > > (a) The actual contents and encodings of TrustedRoot and IDAccepted > > payloads are not specified. > > This is trivial to fix, and was supposed to be done if the WG showed > more interest. It may or may not be trivial to fix. I generally prefer to see protocols fully specified before I draw that kind of conclusion. > > (b) The actual data that's at the target of the URL is left > > unclear. What's the MIME type? What is the actual ASN.1 type > > of the data? > > Not true; this has been fully specified in the PKIX and OpenPGP WGs > for many years. I don't recall such a mechanism, and Russ was in the WG meeting when TLS was thrashing around for one. You have a reference? In any case, the revised identity draft doesn't reference it. > > (b) New error codes are invented but not actually assigned. > > I don't understand this. Section 4 of your document names a bunch of new errors but doesn't give them codes. The point isn't that one couldn't specify this stuff, but merely that your proposal isn't finished. Given that we're proposing being done in 4-5 days, that's pretty scary. > >(3) Removal of semantically meaningful IDs. There are a number of > > different ways in which it might be meaningful to name a > > peer (e.g. IP address, FQDN, etc.) This proposal reduces > > the names to whatever happens to appear in the certificate. > > Not true at all. It works exactly like IKEv1 works, except that you > don't have the ID payload. If the receiver knows that Joe is > identified by his IP address, regardless of what is in the > certificate, the receiver uses that information. In IKEv1 the authenticating party tells the client what its identity is and then the verifying party compares the ID payload to the certificate. In your scheme the verifying party has to guess based on the certificate, which is a potential problem if the cert has ambiguous identity information. [IKEv1 is underspecified] > I take it that you think this is just fine for IKEv2. Others, > particularly implementers who have been hurt by the lack of > interoperability, have said they disagree. No, I don't think it's just fine. I think that it needs to be nailed down. > > > Keeping essentially the same certificate handling in IKEv2 > > but clarifying the semantics allows us to tighten IKEv1 > > as well. > > But this is not what the WG chairs have proposed. There is no proposal > for clarifying the semantics in IKEv2 on the table. We are left with > the same nothing as in IKEv1. Why would an implementer go to IKEv2 if > the major user problems with IKEv1 are left the same? As far as I can tell, it is what they've proposed. Quoting from Ted's message: 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. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/
- 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