> - There are no security implications: the application of PRF in "SKEYSEED = > prf(Ni | Nr, g^ir)" takes care of extracting the entropy even if both X and > the dependent Y are included in g^ir. So either way is fine.
Agreed, but as long as it's up in the air, the clincher for me is that few, if any, crypto providers seem to externalize the y coordinate of the derived point. E.g., OpenSSL, smart cards, etc. This is certainly a good "best practice" for crypto providers, because returning the y coordinate only gives the illusion of extra degrees of freedom. But it also means that to require IKE to use the y coordinate as part of the shared secret is creating a very onerous burden for many implementations. Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Yaron Sheffer <yar...@checkpoint.com> To: Paul Hoffman <paul.hoff...@vpnc.org>, Scott C Moonen/Raleigh/i...@ibmus Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "Sean Kevin O'Keeffe" <s...@stratussolutions.com> Date: 07/05/2009 03:26 AM Subject: RE: [IPsec] IKE's DH groups 19-21, NIST, FIPS 140-2, etc. Given that: - There are several implementations that include Russ's errata. - We have not heard from anybody who has *not* implemented it. - This errata is clearly in conflict with the test vectors in the RFC. - There are no security implications: the application of PRF in "SKEYSEED = prf(Ni | Nr, g^ir)" takes care of extracting the entropy even if both X and the dependent Y are included in g^ir. So either way is fine. ...I suggest that we move forward in line with Russ's errata, and develop a new RFC that includes the errata and also corrects the relevant test vectors. Paul, can you modify your recent errata (http://www.rfc-editor.org/errata_search.php?eid=1800) so that implementers are aware that there is ongoing work to resolve this issue? Otherwise we have two errata in conflict with one another *and* with the RFC, which is mildly confusing. Thanks, Yaron > -----Original Message----- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Paul Hoffman > Sent: Saturday, July 04, 2009 17:58 > To: Scott C Moonen > Cc: ipsec@ietf.org; Sean Kevin O'Keeffe > Subject: Re: [IPsec] IKE's DH groups 19-21, NIST, FIPS 140-2, etc. > > At 7:43 AM -0400 7/4/09, Scott C Moonen wrote: > >What's the next step? > > I have sent a message to the RFC Editor (which then gets sent to the doc > authors and the IESG) about my concern about the correctness of the > errata. We see how that plays out. > > >If there's agreement that we need a new RFC, I'd be glad to pitch in with > the effort. > > Generally, this should be done by the authors themselves. Failing that, > someone else could do it. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway.
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
