Re: IKEV2: Issue #4 Revised Identity

[Paul Hoffman / VPNC <paul.hoffman@vpnc.org>]

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.

>     This is quite undesirable since these two issues are
>     actually unrelated and it's reasonable to believe that
>     there will be a significant number of agents which don't
>     have HTTP access but can cache.

See above.

>  Even if one believes that
>     all agents have HTTP access, the need to do an HTTP
>     fetch adds significant additional latency.

Which is why it is not mandatory. Gateways that are not concerned 
about latency on the first hit use it, others don't. They can even 
change based on current latency times.

>     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.

>(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.

>     (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.

>	    (b) New error codes are invented but not actually assigned.

I don't understand this.

>(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.

>     Since certificates often have multiple name forms of
>     different types, or worse yet, everything compressed into
>     the CN, this proposal is going to make it very hard
>     for a verifier to figure out what the peer's identity is.

To recap: IKEv1 implementers cannot decide what to do with the 
information in the ID payload when used with certificates. Does the 
receiver have to use it as the identifier? What if the ID payload 
contains something that isn't in the certificate? What if the ID 
payload matches something in the certificate but the receiver uses 
some other type of identification?

There are almost as many answers to these questions as there are 
implementations. Different profiles have attempted to pick a single 
meaning, and each proposal has had a shower of complaints because it 
doesn't match with what many implementers are already doing while 
following the lack of information in IKEv1.

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.


>(4) It invents new mechanisms to do things that do things that
>     are already done (confusingly) in IKEv1.

Fully agree.

>  The problem with
>     IKEv1 certificate handling is largely that it's underspecified.

Right.

>     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?

>  This is a good thing since we are probably stuck with
>     IKEv1 for a while.

Folks who have been badly hurt by the lack of interoperability might 
disagree with that assessment.

--Paul Hoffman, Director
--VPN Consortium