Re: [IPsec] Matching certificates in IKEv2

[Yoav Nir]

On Sep 24, 2013, at 3:04 PM, Valery Smyslov sva...@gmail.com wrote:

 I just reread the introduction of RFC 4945 and I don't understand its
 purpose. So I'm not sure it should be referenced from 5996bis.
 
 Ok, if there is any disagreement about it, then I think it is better
 to leave it out from 5996bis.
 
 If we leave it out, than original Yoav's question is there anywhere in the 
 RFC
 description of how to match ID to certificates will arise from implementers.
 And not all of them will be able to find RFC4945 without reference.
 So, what's wrong in referencing it, at least as informative reference?

It's really worse than just implementers asking questions. As long as there's 
no definitive profile, any implementer and often any administrator can stuff 
whatever they want in the certificate, and the other implementations have to 
deal with it. 

For example, my implementation by default stuffs some internal name into the 
subject common name, and an IP address of the gateway into an alternate name.  
For interop with other gateways, we have this dialog box called Certificate 
Matching Criteria for each peer gateway, where the administrator can specify 
the subject DN, the IP address (as an alternate name), or an RFC822 name (as an 
alternate name, not an RDN). And because there is no standard way to map ID 
payloads to certificate fields, we just ignore them (and have a way to 
configure what we send for interop).

For the purposes of ADVPN we (different we this time) will create our own 
profile, which is actually a reverse profile - we're not specifying what a 
certificate should hold, but what the ID payload should hold, given an existing 
certificate. 

I don't think we have an answer for the general IKEv2 question, though.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Matching certificates in IKEv2

[Paul Hoffman]

no hat

On Sep 24, 2013, at 4:21 AM, Tero Kivinen kivi...@iki.fi wrote:

 Yaron Sheffer writes:
 I just reread the introduction of RFC 4945 and I don't understand its 
 purpose. So I'm not sure it should be referenced from 5996bis.
 
 Ok, if there is any disagreement about it, then I think it is better
 to leave it out from 5996bis. 

Please do not. It is flawed, but it is the best we have. If you leave it out, 
then you will have to reproduce all the valuable matching bits in 5996bis. 
That's possible, but likely more work than you expect.

 It is definitely not a profile in the sense that Tero is alluding to. 
 Tero's own minimal IKEv2 is a profile for a specific use. RFC 4945 
 just attempts to fill in the holes (or perceived holes) in RFC 4306 and 
 PKIX docs wrt PKI use in IPsec. Which just happens to be the main use 
 case of IKE/IPsec!
 
 I have understood that RFC4945 is profile which profiles both PKIX and
 IPsec, i.e. tell the CA vendors what kind of features might be needed
 form the PKIX if certificates are used in the IPsec environment, and
 tell the IPsec vendors what kind of certificates it will receive from
 the CAs and how those can be used in the IPsec environment.

Tero's description of what was intended is exactly right. Whether or not we 
achieved that goal is a different matter.

 It is not the only possible way of combining PKIX and IPsec, for
 example if someone wants to use certificates and IPsec to protect
 routers, the requirements what kind of certificats and what kind of
 IKE payloads and their semantics might be different.

...and therefore cause lack of interop.

--Paul Hoffman

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec