RE: IKEV2: Issue #4 Revised Identity

["Greg Carter" <greg@carter-engineering.com>]

Mucho comments below...

>-----Original Message-----
>From: owner-ipsec@lists.tislabs.com
>[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC
>Sent: February 11, 2003 1:35 PM
>To: ipsec@lists.tislabs.com
>Subject: Re: IKEV2: Issue #4 Revised Identity


>At 11:07 PM -0800 2/10/03, Eric Rescorla wrote:
>>In IKEv1 the authenticating party tells the client what its identity is
>>and then the verifying party compares the ID payload to the
>>certificate.

>That is one interpretation; there are many others. As others have
>said before on this thread, anyone who has gone to the bakeoffs knows
>this.

Yeah they know it is the correct way to do it.  And if they were not doing
it before now, the pkix profile draft makes it explicitly clear.  I
remembered talking about this a lot 'back in the day', and here is a message
from 1998 that I wrote to the list:
http://www.sandelman.ottawa.on.ca/ipsec/1998/07/msg00074.html
and another from 1999
http://www.sandelman.ottawa.on.ca/ipsec/1999/10/msg00212.html


I am sure I mentioned it in other emails, but I am guessing that was to the
ANX bakeoff (bakeoff!) list.  At the bakeoffs I know I told anyone who would
listen.

>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

Just so I am clear, with your Revised ID proposal the only way to achieve
certificate caching is if the IKE implementation supports retrieval of
certificates via http URLs? Further the only way to prevent IKE UDP packet
fragmentation is via out of band certificate/chain retrieval (http)?

So the problems solved are caching and UDP fragmentation (BTW the latter is
not a stated goal of your draft).  I am not a router guru so I don't know
the details of the fragmentation issue.  I guess I would like to see a
better description of the UDP fragmentation problem if that is one of the
goals.  I think I did see it once at a bakeoff but that was with large CRLs,
and at the time was dismissed as a problem with the receiver.

Problems with the Revised Identity proposal:
 - mandates HTTP to retrieve the certificate.  What about the rest of the
chain (intermediate CAs and CRLs)?  Ideally you would allow either LDAP or
HTTP.  If I can do full path building via a repository it will most likely
be via LDAP (well that is my experience), not HTTP.  With the risk of being
stoned to death I'll mention WAP defined a decent certificate URL format for
both HTTP and LDAP.  So if this proposal goes further you might want to look
at it.
 - does not allow CRLs in band.  Whether or not IKEv1 implementations use
this feature today isn't the issue, the fact is you can do this in IKEv1 and
it handles the VPN case nicely.  Gateway pushes down its certificate, any
intermediate certificates, and any CRLs needed over IKE.  Client has
everything it needs to validate, doesn't have to go to any remote repository
or validation server (which presumably it couldn't even if it wanted to).
 - Certificate bundling - The end of section 3.1 implies that a certificate
bundle will contain end entity certificates with different IDs (CAs?).  How
am I supposed to know which certificate to use (look in the ID payload
haha)?  I assume they will all have different key pairs, so the process of
choosing one becomes "attempt signature validation for cert N, repeat".
This seems a bit at odds with the notion of "The certificate is the ID"
philosophy.  I would rather see a definition that limited the cert bundle to
only one end entity certificate (or only one with the correct key usage).

Along the same lines, I don't understand this statement from section 3.1:
 "If a system can resolve URLs, it SHOULD use type 3 and 4 unless it is sure
that it does not have the certificate of the other side, such as if it has
just recovered from a crash and its cache is empty."

If it can resolve URLs, it can resolve URLs, it doesn't matter if the cache
is empty.  If the cache is empty then it, oddly enough, resolves the URL :)
Maybe I am missing something.

Caching Alternatives
I haven't put too much thought into this, and I expect it is too late to
define something like this but here goes:
One way to add explicit caching would be to have a new payload "CERT_HASH"
which would optionally be sent in messages 1 & 2.   The payload would
contain a list of hash values of the end entity certificates you could
possibly send to the other end.  If the receiver of the "CERT_HASH" payload
doesn't have one of those hash values in it's cache then it sends the cert
request payload in message 3 or 4.  If you do not receive a CERT_REQ
payload, do not send your certificate.  This mechanism could be defined to
indicate what CERT type is associated with the hash (caching CRLs etc).  IDs
remain as in IKEv1.  Not sure if this will leak identity...

Of course the another alternative is to do nothing.  A clever implementation
could keep state associated with the peer (works for clients, not the VPN
gateway), or define your own vendor payload ("Hey I connected yesterday, so
you probably have my cert cached so don't ask for it unless you think you
need it").

UDP Fragmentation
Neither of the above alternatives would help with fragmentation, but I don't
know enough about the problem.

One last thing... in another email to the list you mentioned the problems of
IKEv2 referencing the profile draft.  Putting aside IETF protocol, the
difference between referencing it and the Revised ID draft is that the
profile draft clarifies how existing implementations should already be
working, not defining new behaviour.

Greg Carter