Re: [IPsec] IKE's DH groups 19-21, NIST, FIPS 140-2, etc.

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 (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Paul Hoffman <paul.hoffman@vpnc.org>
To:
"Sean Kevin O'Keeffe" <sean@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