Re: [IPsec] Other documents to upgrade to internet standard
On Nov 7, 2013, at 9:52 AM, Yoav Nir wrote: > On Nov 7, 2013, at 9:43 AM, Tero Kivinen > wrote: > >> So have you actually seen anyone actually using those groups between >> different vendors? > > Perhaps we should have an interop event. How about the Sunday of the London > meeting? Tero was probably talking about using them in the wild, not at an interop event. We have messages saying that vendors have shown interop among themselves, so an interop event just for this point is overkill, given the amount of work it takes to organize everyone. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Other documents to upgrade to internet standard
Hi, speaking for the strongSwan Project I report that we support and frequently use the following algorithms: - RFC 5903: ECP Groups for IKE and IKEv2 - RFC 4754: IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA) - RFC 4106: The Use of Galois/Counter Mode (GCM) in IPsec ESP ECP, ECDSA and AES-GCM interoperability has been successfully tested multiple times with Microsoft's Vista/Windows 7 IKEv1 Advanced Firewall implementation. Additionally starting with strongSwan 5.1.1, we support - RFC 6932: Brainpool Elliptic Curves for the IKE Group Description Registry as an alternative for the NIST curves. Best regards Andreas On 11/07/2013 04:29 PM, Yoav Nir wrote: > > On Nov 7, 2013, at 6:46 AM, wrote: > >> >> On Nov 7, 2013, at 2:11 AM, Yaron Sheffer >> wrote: >> >>> ... IIRC we published RFC 5903 using the old code points because >>> there was no objection, i.e. no indication that people had >>> deployed pre-errata 4753. Whether this was the right thing to do >>> or not is not very interesting now. >>> >>> So, seeing that people are slowly moving to ECC, I would like >>> some input from the group on whether to progress RFC 5903. We >>> will need to demonstrate implementation experience to do that. >> >> "Slowly moving"? I'm not sure they are moving at all. It may be >> there are implementations of IPSec/IKE with ECC, but I've never >> encountered one in the wild. > > Huh? > > The VPN products from Cisco, Juniper and Check Point support them, as > well as both StrongSwan and OpenSwan. I'm sure there are others as > well. > > Yoav == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===[ITA-HSR]== smime.p7s Description: S/MIME Cryptographic Signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Other documents to upgrade to internet standard
On Nov 10, 2013, at 10:12 AM, Tero Kivinen wrote: > Paul Hoffman writes: >>> No. Because the mess with RFC5903 and RFC 4753, i.e. reusing the same >>> IANA values for two different non-interoperable uses of the groups, I >>> cannot say there is enough interoperable use for that RFC. >> >> Nor can you say that there is *not* enough interoperable use. As >> others have pointed out, there are lots implementations, and as far >> as I have heard, all current implementations are using RFC 5930. > > I agree there is enough interoperable implementations, I do not know > if they are "widely used". As far as I know people are still using > MODP DH groups when they are actually using IKEv2 in the field. Given that you told your customers not to the ECDSA curves, it seems sensible that you would not hear them saying that they were disagreeing with you. :-) >>> I have recommended everybody not to use them, as you never know if >>> they work, as you do not know if the other end is upgraded to Errata >>> version of 4753 (i.e. RFC5903). >> >> That's fine if you want to recommend it; many implementors are >> ignoring you and interoperating just fine. > > Again I did not recommend implementors not to implement it or fix > their code to use RFC5930 way of doing thigs, I was recommending users > not to use them unless they are sure all their environment is updated > to latest versions (which usually is not the case). > > You are confusing the "use" vs "implementation" here. No, I'm not. > There needs to > be "widespread deployment and successful operational experience.", and > that at least for me would mean that actually would need to use that > feature, not just that it might be complied in to the implementation. Correct. And some US government installations are seeing both, most likely because they are requiring it. >> That may all be true, but it is also irrelevant to whether the RFC >> itself should advance. The IANA values are not in question: only the >> bits on the wire are covered in the RFCs. The bits on the wire in >> RFC 5930 are highly interoperable, as shown by many different >> implementations (possibly even yours). > > And how does that point there is "successful operational experience" > for those groups? I didn't say that it did; so, see above. There has been both conformance and interoperability testing for those curves, and day-to-day deployment. (Which is more than you can probably show for some of the two largest MODP groups in RFC 3526, but I think it is fine to leave them in because there was limited interop testing for them a decade ago and that's good enough.) --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Other documents to upgrade to internet standard
Paul Hoffman writes: > > No. Because the mess with RFC5903 and RFC 4753, i.e. reusing the same > > IANA values for two different non-interoperable uses of the groups, I > > cannot say there is enough interoperable use for that RFC. > > Nor can you say that there is *not* enough interoperable use. As > others have pointed out, there are lots implementations, and as far > as I have heard, all current implementations are using RFC 5930. I agree there is enough interoperable implementations, I do not know if they are "widely used". As far as I know people are still using MODP DH groups when they are actually using IKEv2 in the field. > > I have recommended everybody not to use them, as you never know if > > they work, as you do not know if the other end is upgraded to Errata > > version of 4753 (i.e. RFC5903). > > That's fine if you want to recommend it; many implementors are > ignoring you and interoperating just fine. Again I did not recommend implementors not to implement it or fix their code to use RFC5930 way of doing thigs, I was recommending users not to use them unless they are sure all their environment is updated to latest versions (which usually is not the case). You are confusing the "use" vs "implementation" here. There needs to be "widespread deployment and successful operational experience.", and that at least for me would mean that actually would need to use that feature, not just that it might be complied in to the implementation. > That may all be true, but it is also irrelevant to whether the RFC > itself should advance. The IANA values are not in question: only the > bits on the wire are covered in the RFCs. The bits on the wire in > RFC 5930 are highly interoperable, as shown by many different > implementations (possibly even yours). And how does that point there is "successful operational experience" for those groups? When I went through the list of IPsec related standards I used following criteria for it: 1) It is widely implemented 2) It is widely used 3) If document does not have errata, it is easy to upgrade. The RFC6410 lists following ones: (1) There are at least two independent interoperating implementations with widespread deployment and successful operational experience. (2) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones. (3) There are no unused features in the specification that greatly increase implementation complexity. (4) If the technology required to implement the specification requires patented or otherwise controlled technology, then the set of implementations must demonstrate at least two independent, separate and successful uses of the licensing process. The first one covers my case 1 and 2. My case for 3 is more strict, as (2) only requires there is no errata that would cause implementation to fail. The errata in RFC4753 was definately such, the errata to RFC5903 is not. (3) and (4) should not be problem for it. This for example one reason I do not think we can put some of the other ones forward either. I.e. following ones are standard track, but even if some of them do have enough implementations, I do not think they are used widely enough yet: MOBIKE (4555), ECDSA (4754=>5903), OCSP extensions (4806), AEAD for IKEv2 (5282), redirect (5685), session resumption (5723), EAP only athentication (5998), Quick Crash Detection (6290), High Availibility (6311). > > > Do others in the WG feel that the issues Tero brought up are > significant enough to prevent RFC 5930 from advancing on the > standards track? -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Other documents to upgrade to internet standard
On Nov 6, 2013, at 10:41 AM, Tero Kivinen wrote: >> Do we have enough implementations of EC groups to progress RFC 5903? I >> realize that NSA RFCs are not that popular nowadays... > > No. Because the mess with RFC5903 and RFC 4753, i.e. reusing the same > IANA values for two different non-interoperable uses of the groups, I > cannot say there is enough interoperable use for that RFC. Nor can you say that there is *not* enough interoperable use. As others have pointed out, there are lots implementations, and as far as I have heard, all current implementations are using RFC 5930. > I have recommended everybody not to use them, as you never know if > they work, as you do not know if the other end is upgraded to Errata > version of 4753 (i.e. RFC5903). That's fine if you want to recommend it; many implementors are ignoring you and interoperating just fine. On Nov 7, 2013, at 9:25 AM, Tero Kivinen wrote: > As an IANA expert I said we are going to allocate new numbers for > this, but area directors were against this and they managed to talk me > out it (unfortunately, I still think it would have been much better to > allocate new numbers). The only comment why keep original numbers was > that there was ONE implementation out there that used them, and that > implementation would never get updated to include new numbers if we > allocated them. I myself considered this as very weak reason, but > other people had different opinions. BTW most of this discussion > happened face-to-face, not in the mailing list. That may all be true, but it is also irrelevant to whether the RFC itself should advance. The IANA values are not in question: only the bits on the wire are covered in the RFCs. The bits on the wire in RFC 5930 are highly interoperable, as shown by many different implementations (possibly even yours). Do others in the WG feel that the issues Tero brought up are significant enough to prevent RFC 5930 from advancing on the standards track? --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Other documents to upgrade to internet standard
On Nov 7, 2013, at 9:43 AM, Tero Kivinen wrote: > Yoav Nir writes: >> The VPN products from Cisco, Juniper and Check Point support them, >> as well as both StrongSwan and OpenSwan. I'm sure there are others >> as well. > > But which version of their products support which version of the ECC > groups? For example I have no idea which version our toolkit, our > customers are using in their products, so I cannot know which version > of groups they support. I do know that some of them do use very old > versions, because there release cycle is very long. I'm pretty sure that is true for my company's customers as well. > So have you actually seen anyone actually using those groups between > different vendors? Perhaps we should have an interop event. How about the Sunday of the London meeting? > I think quite a lot of our customers still have > IKEv1 configured by default, and they have not yet moved to IKEv2 > unless they want to use EAP or MOBIKE or something like that which is > only supported by IKEv2. I know our default is IKEv1 and I don't think many of our customers switched to IKEv2. Perhaps now they will, because we only support IPv6 with IKEv2. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Other documents to upgrade to internet standard
On Thu, 7 Nov 2013, Tero Kivinen wrote: The VPN products from Cisco, Juniper and Check Point support them, as well as both StrongSwan and OpenSwan. I'm sure there are others as well. But which version of their products support which version of the ECC groups? So have you actually seen anyone actually using those groups between different vendors? I think quite a lot of our customers still have IKEv1 configured by default Yes, with 3des-md5 and pfs disabled. Every single time I talk to a sysadmin configuring interop to a Cisco. I don't think it is the vendor's fault. It's that IPsec is too complicated for sysadmins, so the documentation from 15 years ago is still re-used today. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Other documents to upgrade to internet standard
Yoav Nir writes: > The VPN products from Cisco, Juniper and Check Point support them, > as well as both StrongSwan and OpenSwan. I'm sure there are others > as well. But which version of their products support which version of the ECC groups? For example I have no idea which version our toolkit, our customers are using in their products, so I cannot know which version of groups they support. I do know that some of them do use very old versions, because there release cycle is very long. So have you actually seen anyone actually using those groups between different vendors? I think quite a lot of our customers still have IKEv1 configured by default, and they have not yet moved to IKEv2 unless they want to use EAP or MOBIKE or something like that which is only supported by IKEv2. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Other documents to upgrade to internet standard
Yaron Sheffer writes: > IIRC we published RFC 5903 using the old code points because there was > no objection, i.e. no indication that people had deployed pre-errata > 4753. Whether this was the right thing to do or not is not very > interesting now. There was very strong objection, at least from me. http://www.ietf.org/mail-archive/web/ipsec/current/msg05445.html And as I pointed out at that time was that our code for example was changed to use pre errata 4753 because other implementor complained that we did things wrong, so our toolkits are using either pre-errata or post-errata 4753 depending on the version (very old ones use post-errata, then several years for per-errata, and then again post-errata). This was discussed in the email. As an IANA expert I said we are going to allocate new numbers for this, but area directors were against this and they managed to talk me out it (unfortunately, I still think it would have been much better to allocate new numbers). The only comment why keep original numbers was that there was ONE implementation out there that used them, and that implementation would never get updated to include new numbers if we allocated them. I myself considered this as very weak reason, but other people had different opinions. BTW most of this discussion happened face-to-face, not in the mailing list. I did point out at that time, that this will mean that those ECP groups cannot get wide use as people cannot enable them unless they are using exactly same version of IPsec in all of their devices, and I have been recommending to our customers to stay away from thse groups. > So, seeing that people are slowly moving to ECC, I would like some input > from the group on whether to progress RFC 5903. We will need to > demonstrate implementation experience to do that. I am against for RFC5903 going forward as we KNOW there is known implemnetation issues with the groups defined there, and those problems manifest by just causing timeouts during the IKE_AUTH exchange, i.e. there is no proper way to do good fallback. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Other documents to upgrade to internet standard
On Nov 7, 2013, at 8:32 AM, Paul Wouters wrote: > On Thu, 7 Nov 2013, Yoav Nir wrote: > >>> openswan / libreswan do not support ecc at this moment. >> >> That's the trouble with open source. You never know which fork. >> https://rhn.redhat.com/errata/RHEA-2010-0411.html > > Only the modp groups from RFC 5114 were added, not the ecp groups. I stand corrected. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Other documents to upgrade to internet standard
On Thu, 7 Nov 2013, Yoav Nir wrote: openswan / libreswan do not support ecc at this moment. That's the trouble with open source. You never know which fork. https://rhn.redhat.com/errata/RHEA-2010-0411.html Only the modp groups from RFC 5114 were added, not the ecp groups. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Other documents to upgrade to internet standard
On Nov 7, 2013, at 7:46 AM, Paul Wouters wrote: > On Thu, 7 Nov 2013, Yoav Nir wrote: > So, seeing that people are slowly moving to ECC, I would like some input from the group on whether to progress RFC 5903. We will need to demonstrate implementation experience to do that. >>> >>> "Slowly moving"? I'm not sure they are moving at all. It may be there are >>> implementations of IPSec/IKE with ECC, but I've never encountered one in >>> the wild. >> >> Huh? >> >> The VPN products from Cisco, Juniper and Check Point support them, as well >> as both StrongSwan and OpenSwan. I'm sure there are others as well. > > openswan / libreswan do not support ecc at this moment. That's the trouble with open source. You never know which fork. https://rhn.redhat.com/errata/RHEA-2010-0411.html ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Other documents to upgrade to internet standard
On Thu, 7 Nov 2013, Yoav Nir wrote: So, seeing that people are slowly moving to ECC, I would like some input from the group on whether to progress RFC 5903. We will need to demonstrate implementation experience to do that. "Slowly moving"? I'm not sure they are moving at all. It may be there are implementations of IPSec/IKE with ECC, but I've never encountered one in the wild. Huh? The VPN products from Cisco, Juniper and Check Point support them, as well as both StrongSwan and OpenSwan. I'm sure there are others as well. openswan / libreswan do not support ecc at this moment. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Other documents to upgrade to internet standard
On Nov 7, 2013, at 6:46 AM, wrote: > > On Nov 7, 2013, at 2:11 AM, Yaron Sheffer wrote: > >> ... >> IIRC we published RFC 5903 using the old code points because there was no >> objection, i.e. no indication that people had deployed pre-errata 4753. >> Whether this was the right thing to do or not is not very interesting now. >> >> So, seeing that people are slowly moving to ECC, I would like some input >> from the group on whether to progress RFC 5903. We will need to demonstrate >> implementation experience to do that. > > "Slowly moving"? I'm not sure they are moving at all. It may be there are > implementations of IPSec/IKE with ECC, but I've never encountered one in the > wild. Huh? The VPN products from Cisco, Juniper and Check Point support them, as well as both StrongSwan and OpenSwan. I'm sure there are others as well. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Other documents to upgrade to internet standard
On Nov 7, 2013, at 2:11 AM, Yaron Sheffer wrote: > ... > IIRC we published RFC 5903 using the old code points because there was no > objection, i.e. no indication that people had deployed pre-errata 4753. > Whether this was the right thing to do or not is not very interesting now. > > So, seeing that people are slowly moving to ECC, I would like some input from > the group on whether to progress RFC 5903. We will need to demonstrate > implementation experience to do that. "Slowly moving"? I'm not sure they are moving at all. It may be there are implementations of IPSec/IKE with ECC, but I've never encountered one in the wild. paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Other documents to upgrade to internet standard
Do we have enough implementations of EC groups to progress RFC 5903? I realize that NSA RFCs are not that popular nowadays... No. Because the mess with RFC5903 and RFC 4753, i.e. reusing the same IANA values for two different non-interoperable uses of the groups, I cannot say there is enough interoperable use for that RFC. I have recommended everybody not to use them, as you never know if they work, as you do not know if the other end is upgraded to Errata version of 4753 (i.e. RFC5903). Thats why I would not recommend RFC5903 to be upgraded at this time. And there is errata for RFC5903, so it does not go in my category of "Easy, no need to revise document", which was my original list selection criteria. Hmm.. actually I see that both errata entries for the RFC5903 are actually rejected, so perhaps it could still be done inplace. IIRC we published RFC 5903 using the old code points because there was no objection, i.e. no indication that people had deployed pre-errata 4753. Whether this was the right thing to do or not is not very interesting now. So, seeing that people are slowly moving to ECC, I would like some input from the group on whether to progress RFC 5903. We will need to demonstrate implementation experience to do that. Thanks, Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Other documents to upgrade to internet standard
Yaron Sheffer writes: > > - RFC2451 "The ESP CBC-Mode Cipher Algorithms" > > This is nominally a generic document, but it's really about a list of > specific algorithms, none of which is in wide use today (we are trying > to phase out 3DES and in general 64-bit block algorithms). This document > is not referenced by RFC 4303. So I don't think we should upgrade it. True, but it is one of the normative references to the RFC5996, but I agree that if we downgrade 3DES from MUST to MAY, then we skip this one. > > - RFC3526 "More Modular Exponential (MODP) Diffie-Hellman groups for > >Internet Key Exchange" > > Yes, probably. Although crypto recommendations are time-dependent, this > RFC describes the actual algorithms and not just their use in IKE. Yep. Meaning there is lots of use for these groups. > Do we have enough implementations of EC groups to progress RFC 5903? I > realize that NSA RFCs are not that popular nowadays... No. Because the mess with RFC5903 and RFC 4753, i.e. reusing the same IANA values for two different non-interoperable uses of the groups, I cannot say there is enough interoperable use for that RFC. I have recommended everybody not to use them, as you never know if they work, as you do not know if the other end is upgraded to Errata version of 4753 (i.e. RFC5903). Thats why I would not recommend RFC5903 to be upgraded at this time. And there is errata for RFC5903, so it does not go in my category of "Easy, no need to revise document", which was my original list selection criteria. Hmm.. actually I see that both errata entries for the RFC5903 are actually rejected, so perhaps it could still be done inplace. > > - RFC3948 "UDP Encapsulation of IPsec ESP Packets" > > Definitely. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Other documents to upgrade to internet standard
On Nov 5, 2013, at 9:58 PM, Yaron Sheffer wrote: > > Do we have enough implementations of EC groups to progress RFC 5903? I > realize that NSA RFCs are not that popular nowadays… How many is "enough"? I have one. Besides, the NSA is very popular nowadays. In fact, where dedicating both tomorrow's plenary *and* the perpass session to celebrate our appreciation of the NSA. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Other documents to upgrade to internet standard
Hi Tero, On 2013-11-06 02:23, Tero Kivinen wrote: While we are working on the ESP, AH, IKEv2, and Architecture documents, I think we should do also the easy ones: - RFC2451 "The ESP CBC-Mode Cipher Algorithms" This is nominally a generic document, but it's really about a list of specific algorithms, none of which is in wide use today (we are trying to phase out 3DES and in general 64-bit block algorithms). This document is not referenced by RFC 4303. So I don't think we should upgrade it. - RFC3526 "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange" Yes, probably. Although crypto recommendations are time-dependent, this RFC describes the actual algorithms and not just their use in IKE. Do we have enough implementations of EC groups to progress RFC 5903? I realize that NSA RFCs are not that popular nowadays... - RFC3948 "UDP Encapsulation of IPsec ESP Packets" Definitely. None of them has Errata, and they are all widely used, so we should just upgrade them on in place (i.e. no need to get new RFC). ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
