Re: IKEV2: Issue #4 Revised Identity

[Brian Korver <briank@briank.com>]

Paul,

Comments below...

-brian
briank@briank.com

Paul Hoffman / VPNC wrote:
> At 9:11 PM -0500 2/11/03, Greg Carter wrote:
> >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?
> 
> Nope, nothing in the document says that. You can cache any certs you
> know about from any means, such as from people who sent them to you
> in IKE.

Of course you can cache anything you want, but what the Revised ID
proposal is missing is a way to specify to a peer that it needn't
resend the already-cached items.  Certs and CRLs are large, processing
them is costly, and IKE is over UDP, so some see not having to resend
these as a real benefit.  YMMV.


 
> >  Further the only way to prevent IKE UDP packet
> >fragmentation is via out of band certificate/chain retrieval (http)?
> 
> Nope, nothing in the document says this either. The only way to
> prevent IKE UDP packet fragmentation is to make the fragments small
> enough not to fragment. URL-and-hash will help that. Sending only a
> single small cert will help that. Sending raw RSA keys will help that.
> 
> >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.
> 
> This has been discussed in the WG a few times. Basically, some
> devices will drop any fragmented UDP packets either all the time or
> when their reassembly buffers are full.
> 
> >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.
> 
> Ideally for whom? That is certainly not ideal for IPsec implementers.

That the caching mechanism does not support CRLs does seem like a shortcoming.
Regarding LDAP, I think Greg might have a good point here, at least one that
deserves more discussion.



> 
> >   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.
> 
> IPsec vendors have looked at it, and they came to a different
> conclusion than the PKI vendors. No surprise there.
> 
> >  - 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).
> 
> See above.
> 
> >  - 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)?
> 
> The ID payload wouldn't help you there, obviously. You parse the
> certificates looking for CAs you trust. If multiple certs match, you
> parse them for IDs that you trust. Done.
> 
> >   I assume they will all have different key pairs, so the process of
> >choosing one becomes "attempt signature validation for cert N, repeat".
> 
> Spoken like a true PKI vendor. :-)
> 
> >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).
> 
> That's a possibility. Well, it was a possibility before the proposal was axed.
> 
> >One last thing... in another email to the list you mentioned the problems of
> >IKEv2 referencing the profile draft.  Putting aside IETF protocol,
> 
> Er, this is a WG in the IETF. We don't get to "put 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.
> 
> ...and thereby screwing all the vendors who implemented IKEv1 in good
> faith, following what little it said and making guesses about the
> rest. The IETF has rules about not doing that.

The pki-profile draft is currently being revised due to comments that
were posted to the list, so now is an excellent time to submit feedback
describing how the draft could be improved.  BTW, the currently draft is
advertised as a straw man, so no one should feel "screwed" by it.



> 
> --Paul Hoffman, Director
> --VPN Consortium