Re: IKEV2: Issue #4 Revised Identity

[Tero Kivinen <kivinen@iki.fi>]

ekr@rtfm.com (Eric Rescorla) writes:
> >   That's why we want to just send the URL (or URN if you want) where the
> > certificate, whatever chain you need, and maybe the CRL, can be
> > found. 
> And if the implementation can't do HTTP you're completely SOL--or
> rather you have to send the whole chain over UDP, which is
> what you say you're trying to avoid.

For the client / remote access case you do following: If you have
certificate for the other end you ask only the hash and url of the
certificate from the other end. If you do not have certificate for the
other end then you request either PKIX certificate or certificate
bundle.

If the other end replies to your hash + URL request with hash that you
do not have in your cache (for example the key of the other end has
changed), you remove (or mark the key to be old) the old key from the
cache and restart (i.e start over and then you notice that you do not
have key for the other end and request full certificate).

When you receive PKIX certificate or bundle from the other end you
store that certificate to your cache and associate it with the
gateway, so you know next time that you have key for that site.

The gateway side normally will have connection to the internet and can
use http, thus it can always request hash + URL and cache the
certificates it fetches using http.

> It's my view that part of REASON that so many implementations run shared
> secrets is that IKE certificate handling is so screwed up.

And thats why we should fix it and take the text from the
revised-identity draft.
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/