[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKEV2: Issue #4 Revised Identity
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.
> 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.
> 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.
--Paul Hoffman, Director
--VPN Consortium