Thanks, Paul, Sean. What's the next step? If there's agreement that we need a new RFC, I'd be glad to pitch in with the effort.
Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Paul Hoffman <paul.hoff...@vpnc.org> To: "Sean Kevin O'Keeffe" <s...@stratussolutions.com> Cc: ipsec@ietf.org Date: 07/02/2009 10:13 PM Subject: Re: [IPsec] IKE's DH groups 19-21, NIST, FIPS 140-2, etc. At 9:46 PM -0400 7/2/09, Sean Kevin O'Keeffe wrote: >We need to differentiate between the values transmitted over the >wire between IKEv2 peers, and the value they used as a seed to >derive keying material. The fact that they're different seems needlessly error-prone. >I think the KE payload examples are correct in 8.1. The peers need >both coordinates to compute the derived point. However, they only >need to use the x coordinate of this point as the shared secret. Correct; that's what Scott was referring to when he started this thread. >In the context of the example in 8.1, I interpreted the errata as >changing the last sentence in the section to: > "girx is the value that is used in the formation of SKEYSEED." This might make sense, but it still completely disagrees with examples given. Look at the end of 8.1: ----------------------- The shared secret value g^ir=(girx,giry) where girx: D6840F6B 42F6EDAF D13116E0 E1256520 2FEF8E9E CE7DCE03 812464D0 4B9442DE giry: 522BDE0A F0D8585B 8DEF9C18 3B5AE38F 50235206 A8674ECB 5D98EDB2 0EB153A2 These are concatenated to form g^ir: D6840F6B 42F6EDAF D13116E0 E1256520 2FEF8E9E CE7DCE03 812464D0 4B9442DE 522BDE0A F0D8585B 8DEF9C18 3B5AE38F 50235206 A8674ECB 5D98EDB2 0EB153A2 This is the value that is used in the formation of SKEYSEED. ------------------------ Doesn't that say "the concatenated values is used in the formation of SKEYSEED"? >I'm aware of several implementations that comply with this errata, This might be true, but it doesn't follow from the RFC, or from the errata. The fact that several implementations agreed after testing with each other is cause to update the RFC. >so I think a decision to withdraw it requires careful deliberation. Absolutely. It would be much better to, instead, obsolete this RFC with one that matches what the implementations are doing, noting the difference in the new RFC. >That being said, this issue needs to be clearly resolved so >implementations from different vendors can interoperate. Fully agree. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
