Re: [IPsec] Matching certificates in IKEv2
Still might be worth a document proposing some profile, even if it does not match current practice. On Sep 24, 2013, at 9:12 PM, Yaron Sheffer wrote: > I'll defer to Paul on this one. > > Thanks, > Yaron > > On 09/24/2013 05:00 PM, Paul Hoffman wrote: >> >> >> On Sep 24, 2013, at 4:21 AM, Tero Kivinen 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. >> ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Matching certificates in IKEv2
I'll defer to Paul on this one. Thanks, Yaron On 09/24/2013 05:00 PM, Paul Hoffman wrote: On Sep 24, 2013, at 4:21 AM, Tero Kivinen 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. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Matching certificates in IKEv2
On Sep 24, 2013, at 4:21 AM, Tero Kivinen 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
On Sep 24, 2013, at 3:04 PM, Valery Smyslov 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
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? Regards, Valery. kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Matching certificates in IKEv2
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. > 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. > 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." This very clearly tells the first part (i.e. the profiling the PKIX), and bit vaguely describes the second part (i.e. "document the contents of relevant IKE payloads and further specifying their semantics" meaning that it profiles the IPsec implementations by specifying more exact contents and semantics to the payloads, when the IPsec specifications usually leave them open). It is profile in such sense that it gives common ground for PKIX and IPsec vendors so they can agree on what kind of certs can be used in IPsec. 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. -- 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
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
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
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
> > 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
On Sep 16, 2013, at 2:02 PM, Valery Smyslov wrote: > 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. Thanks. I usually search for RFCs by the ipsec or ipsecme working groups, and I totally forgot about pki4ipsec. >> 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 | | | | ___ 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
[IPsec] Matching certificates in IKEv2
Yoav Nir writes: > 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? That is mostly local matter for the CA, cert user and the configuration of the devices. As Valery already pointed out the RFC4945 gives some minimum requirements what implementations need to do. Implementations are free to whatever they feel like to match those rules, for example they might support matching against the sub CAs, or do LDAP lookup or database based on the ID send by the the other end, and then get rules how the cert is matched against the ID. The section 3.5 of the RFC5996 says: -- 3.5. Identification Payloads The Identification payloads, denoted IDi and IDr in this document, allow peers to assert an identity to one another. This identity may be used for policy lookup, but does not necessarily have to match anything in the CERT payload; both fields may be used by an implementation to perform access control decisions. ... The Peer Authorization Database (PAD) as described in RFC 4301 [IPSECARCH] describes the use of the ID payload in IKEv2 and provides a formal model for the binding of identity to policy in addition to providing services that deal more specifically with the details of policy enforcement. The PAD is intended to provide a link between the SPD and the IKE Security Association management. See Section 4.4.3 of RFC 4301 for more details. -- And the section 4.4.3 in RFC4301 has even more text about that. > Of course, looking at RFC 5280, we have all sorts of alternate names > that look suspiciously useful: otherName, rfc822Name, dNSName, > directoryName, iPAddress. But it is not immediately obvious: > > 1. Is it enough for the ID payload to match the alternate name? > 2. Is it enough for an ID_FQDN to match the CommonName of a > certificate subject? > 3. Is it enough for an ID_DER_ASN1_DN to match the certificate subject? Depending on the policy yes. > 4. Is it enough if the ID_IPV*_ADDR matches the source IP of the IKE packet? In the RFC5996 section 3.5 it says: -- When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does not require this address to match the address in the IP header of IKEv2 packets, or anything in the TSi/TSr payloads. The contents of IDi/IDr are used purely to fetch the policy and authentication data related to the other party. -- Meaning that the IKEv2 implementation might check that, but that check is not required, and depending on the policy and setup it might or might not be done. In most cases it is not useful to do that check, as it does not provide any information. The ID is used to fetch and check the authentication information, i.e. if shared key is found based on the ID and the other end proofs it knows it, that is enough to identify the other end, even if the packets didn't come from that source address. This kind of setup might be useful setup in some environments, for example the enterprice adminstrators might assign each laptop a unique 10.0.x.y address for inside company use, and create certificate or shared key for that specific address. When using the laptop inside the company network the IP address and the ID matches, but when the device is away from the company network it might still be useful to use same ID when connecting the VPN gateway, or servers in the company network, even when the outer IP address might be something completely different. > I've looked in RFC 4301 and found this in section 4.4.3.2: >This document does not require that the IKE ID asserted by a peer be >syntactically related to a specific field in an end entity >certificate that is employed to authenticate the identity of that >peer. However, it often will be appropriate to impose such a >requirement, e.g., when a single entry represents a set of peers each >of whom may have a distinct SPD entry. > > The reason this came up in the context of AD-VPN, is that unlike > "static" VPN, in AD-VPN the PAD is populated dynamically, so while > we can manually configure a static VPN implementation that to assert > identity "foo", a peer must present a certificate with value "baz" > and field "bar", we'd need to either copy that rule to other peers > in AD-VPN (regardless of which solution, btw), or we'd need a good > rule. In the AD-VPN I would expect this kind of things depended a lot about the environment. In some cases the certificates are already ther
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
[IPsec] Matching certificates in IKEv2
Hi While working on some text for the AD-VPN document, I came across some weirdness in the base IKEv2 specification: The IDi and IDr payloads have any of several types: ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, ID_IPV6_ADDR, ID_DER_ASN1_DN, ID_DER_ASN1_GN, and ID_KEY_ID. Section 4 (conformance requirements) says that implementations MUST support "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.". Section 2.15 (authentication of the IKE SA has the following paragraph: Optionally, messages 3 and 4 MAY include a certificate, or certificate chain providing evidence that the key used to compute a digital signature belongs to the name in the ID payload. 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? Of course, looking at RFC 5280, we have all sorts of alternate names that look suspiciously useful: otherName, rfc822Name, dNSName, directoryName, iPAddress. But it is not immediately obvious: 1. Is it enough for the ID payload to match the alternate name? 2. Is it enough for an ID_FQDN to match the CommonName of a certificate subject? 3. Is it enough for an ID_DER_ASN1_DN to match the certificate subject? 4. Is it enough if the ID_IPV*_ADDR matches the source IP of the IKE packet? I've looked in RFC 4301 and found this in section 4.4.3.2: This document does not require that the IKE ID asserted by a peer be syntactically related to a specific field in an end entity certificate that is employed to authenticate the identity of that peer. However, it often will be appropriate to impose such a requirement, e.g., when a single entry represents a set of peers each of whom may have a distinct SPD entry. The reason this came up in the context of AD-VPN, is that unlike "static" VPN, in AD-VPN the PAD is populated dynamically, so while we can manually configure a static VPN implementation that to assert identity "foo", a peer must present a certificate with value "baz" and field "bar", we'd need to either copy that rule to other peers in AD-VPN (regardless of which solution, btw), or we'd need a good rule. 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? Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
