[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IKEV2: Issue #4 Revised Identity




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

Yeah but the only way for it to be useful is if you support URL retrieval.
If the only way I can obtain a certificate is in band IKE but I say I
support URL retrieval (the only way to get the hash) and therefore you send
me a URL how do I get your certificate?  Does this mean that you propose
that I first send an IDAccept of URL then if I can't find it in the cache
then fail IKE, and retry with an IDAccept of Certificate?  Otherwise I don't
see how to get around the start-up problem.

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

Yeah I know nothing in the document says that, in fact there is no mention
of UDP fragmentation in the document at all.

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

So here we are defining mechanisms for X.509 and you don't even want to
consider the optional use of a DIRECTORY for retrieval of certificate
information.  Great.  So instead you'll dupe IPSec vendors into believing
that if they implement HTTP that they will magically have everything they
need to do certificate validation.  This would only work for rather simple
certificate chain validation (or handing it off to some as of yet not
defined certificate validation server).  I don't know of any CA that will
publish a cert chain bundle to an HTTP server, however I have been lead to
believe that LDAP client code is in a fair amount of router code.

>>deleted crl stuff
>See above.

I don't follow.  If you are going to spec out a solution for X.509 you can't
ignore CRLs.  I haven't seen any discussion on this list.

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

Hence the haha, since your proposal does away with it in its current form.

>certificates looking for CAs you trust. If multiple certs match, you
>parse them for IDs that you trust. Done.

But that would mean multiple queries to a policy database looking for a
match.  With the IKEv1 style you explicitly have an ID (in the ID Payload)
which to match on.  With your method you would have to look for matches in
your policy db for each ID in a certificate, and then possibly do that for
multiple certificates.  Yes I know you said that the implementer is free to
chose which ever ID they want to then use in the certificate, but I fail to
see how this helps interoperability.  If I choose to only accept DNs, and
you choose to only accept DNS (in the subjectAltName) as "ID" how do we
interoperate?  In the current scheme an implementation would have to accept
any of the ID types as input to the policy engine, so theoretically you
could at least configure my DN as acceptable.

>Spoken like a true PKI vendor. :-)

Actually I have no affiliation.

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

Yeah when logic and reason fail...

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

From the DOI:
"When an IKE exchange is authenticated using certificates (of any
   format), any ID's used for input to local policy decisions SHOULD be
   contained in the certificate used in the authentication of the
   exchange."

Yes it didn't hand hold the implementer of how to actually do the mapping,
they would have had to pick up a copy of the PKIX or X.509 specs to find
where to look for IDs (with only two places, the DN or subjectAltName).  At
every bakeoff from about Sept '97 I had a CA there with instructions on how
to put IPSec ID information in a certificate, I also had a free test site up
at http://freecerts.entrust.com/vpncerts/certreq.htm (even appears to still
work, damn) which I sent emails to the IPSec list altering any implementers
to.  And even you pointed out a 'problem' as early as 1999 to the list (and
I replied).  So if they implemented in good faith they missed a lot of
opportunities to get it right.  For the sake of argument I'll even concede
my point and agree that it was possible to get it wrong if implemented in
good faith.  However I do not see how the profile draft will punish those
people who got it wrong.  Yes they will have to fix it, but by doing so they
end up with an implementation that is secure and interoperable, that doesn't
sound like screwing anyone to me.

Greg