Re: [IPsec] Matching certificates in IKEv2
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
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
Re: [IPsec] Matching certificates in IKEv2
Valery Smyslov writes: And this not the only contradiction between RFC5996 and RFC4945 - the latter requires ID_IPV*_ADDR to match source IP address of IKE packet by default, while the former explicitely allows not to do it in any case. RFC4945 requires that implementations MUST be capable of verifying the ID_IPV*_ADDR and IP-address of the packet. RFC5996 says that IKEv2 does not require such check. There is no contradiction there. RFC4945 requires (MUST) this check to be done by default, treats mismatch as an error and allows (MAY) to skip this check only for interoperability purpose. Probably not contradiction, but some inconsistency, in my opinion. Not really inconsistency, it just means that the RFC4945 profile requires more features than what is required in IKEv2 in general (i.e. to be able to do the check, and that check is on by default). So RFC4945 is bit more strict than RFC5996. RFC4945 is IPsec PKI profile document so it is intended to limit things more than the basic IKEv2. If someone writes some IPsec XXX Profile document that might add some other restrictions, for example such profile might require that 4096 bit RAW RSA keys must be used for all authentication for that XXX environment. This is again more strict than RFC5996 and there is no contradiction or inconsistency there. There are RFC5996 implementations which do not need to implement RFC4945. Perhaps adding reference to the RFC4945 at the end of section 3.5. Identification Payloads in the RFC5996bis? Yes, and some explanation text about inconsistencies between the approaches to match ID to certificate. No. I do not think we need such text. RFC5996 text is for general IKEv2 implementation. RFC4945 text is only for those implementations which support that RFC, not for all IKEv2 implementations. RFC4945 is supposed to be stricter than RFC5996. If there is case where RFC4945 requires operations which are not allowed by RFC5996 then we do have inconsistancy. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Matching certificates in IKEv2
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. 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! Quoting: This profile of the IKE and PKIX frameworks is intended to provide an agreed-upon standard for using PKI technology in the context of IPsec by profiling the PKIX framework for use with IKE and IPsec, and by documenting the contents of the relevant IKE payloads and further specifying their semantics. Thanks, Yaron On 09/19/2013 02:45 PM, Tero Kivinen wrote: Valery Smyslov writes: And this not the only contradiction between RFC5996 and RFC4945 - the latter requires ID_IPV*_ADDR to match source IP address of IKE packet by default, while the former explicitely allows not to do it in any case. [...] Perhaps adding reference to the RFC4945 at the end of section 3.5. Identification Payloads in the RFC5996bis? Yes, and some explanation text about inconsistencies between the approaches to match ID to certificate. No. I do not think we need such text. RFC5996 text is for general IKEv2 implementation. RFC4945 text is only for those implementations which support that RFC, not for all IKEv2 implementations. RFC4945 is supposed to be stricter than RFC5996. If there is case where RFC4945 requires operations which are not allowed by RFC5996 then we do have inconsistancy. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Matching certificates in IKEv2
So do you think it would be appropriate to mandate these matching rules in rfc5996bis, or should this be left to AD-VPN solutions. IOW, is such a standard rule needed for generic IKE/IPsec? It's definitely worth to mention these rules in RFC5996bis, or at least point to the RFC4945. Now that I've seen it, I don't think so. Not without updating it. See RFC 5996 says in section 4: For an implementation to be called conforming to this specification, it MUST be possible to configure it to accept the following: o Public Key Infrastructure using X.509 (PKIX) Certificates containing and signed by RSA keys of size 1024 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or ID_DER_ASN1_DN. Note the ID_KEY_ID. But RFC 4945 says this is section 3.1.7: The ID_KEY_ID type used to specify pre-shared keys and thus is out of scope. And in the table in section 3.1: ID type | Support | Correspond | Cert | SPD lookup | for send | PKIX Attrib | matching | rules --- | | | | KEY_ID | MUST NOT | n/a | n/a | n/a | | | | Yes, there is no obvious mapping between ID_KEY_ID and certificates and thus ID_KEY_ID is out of scope for RFC4945. And this not the only contradiction between RFC5996 and RFC4945 - the latter requires ID_IPV*_ADDR to match source IP address of IKE packet by default, while the former explicitely allows not to do it in any case. But I still believe that adding a few words about matching ID to certificates, or point to RFC4945 (probably with some explanation text) will still be useful for not so experienced RFC readers as the members of this list. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Matching certificates in IKEv2
Valery Smyslov writes: Yes, there is no obvious mapping between ID_KEY_ID and certificates and thus ID_KEY_ID is out of scope for RFC4945. As rfc5996 describes ID_KEY_ID as An opaque octet stream that may be used to pass vendor-specific information necessary to do certain proprietary types of identification. I see no problem that it is not in the RFC4945. It is intended for the vendor-specific information so no standard mapping is provided, vendor will decide one for it. And this not the only contradiction between RFC5996 and RFC4945 - the latter requires ID_IPV*_ADDR to match source IP address of IKE packet by default, while the former explicitely allows not to do it in any case. RFC4945 requires that implementations MUST be capable of verifying the ID_IPV*_ADDR and IP-address of the packet. RFC5996 says that IKEv2 does not require such check. There is no contradiction there. All of that is mostly because in IKEv1 that check was always done, and people considered it important to be done. In IKEv2 we realized that kind of test does not really help, and can cause some problems in some scenarios, so that check was explictly said not to be required anymore. The RFC4945 parts are shared with IKEv1 and IKEv2, thus they set the same requirements for it, but IKEv2 implementation can be conformant with both of them, i.e provide option to disable that check, and make it so that by default the checks are done (to be conformant to RFC4945), but allow those test to be disabled (as is allowed in the RFC5996). But I still believe that adding a few words about matching ID to certificates, or point to RFC4945 (probably with some explanation text) will still be useful for not so experienced RFC readers as the members of this list. Yes adding reference to the RFC4945 might be useful, it was not done in the RFC4306 as the RFC4945 was not ready at that time. Most likely we should have added it when doing RFC5996 but we didn't. Perhaps adding reference to the RFC4945 at the end of section 3.5. Identification Payloads in the RFC5996bis? -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Matching certificates in IKEv2
And this not the only contradiction between RFC5996 and RFC4945 - the latter requires ID_IPV*_ADDR to match source IP address of IKE packet by default, while the former explicitely allows not to do it in any case. RFC4945 requires that implementations MUST be capable of verifying the ID_IPV*_ADDR and IP-address of the packet. RFC5996 says that IKEv2 does not require such check. There is no contradiction there. RFC4945 requires (MUST) this check to be done by default, treats mismatch as an error and allows (MAY) to skip this check only for interoperability purpose. Probably not contradiction, but some inconsistency, in my opinion. Yes adding reference to the RFC4945 might be useful, it was not done in the RFC4306 as the RFC4945 was not ready at that time. Most likely we should have added it when doing RFC5996 but we didn't. Perhaps adding reference to the RFC4945 at the end of section 3.5. Identification Payloads in the RFC5996bis? Yes, and some explanation text about inconsistencies between the approaches to match ID to certificate. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Matching certificates in IKEv2
Hi Yoav, What I could not find anywhere in the RFC is how to match name in the ID payload to the certificate. In HTTPS we have a requirement that either the CN or the dNSName alternate name match the domain name in the URL. We don't have similar rules for IKE, do we? Yes, we do: RFC4945. So do you think it would be appropriate to mandate these matching rules in rfc5996bis, or should this be left to AD-VPN solutions. IOW, is such a standard rule needed for generic IKE/IPsec? It's definitely worth to mention these rules in RFC5996bis, or at least point to the RFC4945. Yoav Regards, Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Matching certificates in IKEv2
Valery Smyslov writes: So do you think it would be appropriate to mandate these matching rules in rfc5996bis, or should this be left to AD-VPN solutions. IOW, is such a standard rule needed for generic IKE/IPsec? It's definitely worth to mention these rules in RFC5996bis, or at least point to the RFC4945. I think adding pointer could be useful, I do not think we should go in to any kind of details about those. Also the RFC4945 is just one profile document, there can also be others. For example some big enterprise or goverment might create their own profile setting different set of rules, and require the implementations they buy to conform to that profile. Most of this is just what kind of policy setups and configurations can be done on the implementation, it does not affect the bits on the wire. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
