Re: IKEV2: Issue #4 Revised Identity

[Eric Rescorla <ekr@rtfm.com>]

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/