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

From: Sean Kevin O'Keeffe <[email-masked]>
Date: Thu, 2 Jul 2009 19:06:07 -0400

At 3:19 PM -0400 7/1/09, Scott C Moonen wrote:
 > RFC 4753 documents that the shared secret obtained from an ECP
 > Diffie-Hellman operation is the concatenation of the x and y
 > coordinates of the derived point.
 > Is that correct?

It is not.  There is an errata for RFC 4753.  The shared secret
is the x coordinate of the derived point.

See: http://www.rfc-editor.org/errata_search.php?eid=9

Regards, Sean

Sean Kevin O'Keeffe
STRATUS Solutions, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Jul 2009 17:18:07 -0700

>See: http://www.rfc-editor.org/errata_search.php?eid=9

Urrrrgh. (I have elided something much stronger...)

First, thanks to Sean for pointing this out.

It appears that the errata is either wrong or insufficient. If the errata is right, then I'm pretty sure the test vectors in section 8 are wrong. For example, from 8.1:
------------------------------------
gix:
 DAD0B653 94221CF9 B051E1FE CA5787D0 98DFE637 FC90B9EF 945D0C37 72581180

giy:
 5271A046 1CDB8252 D61F1C45 6FA3E59A B1F45B33 ACCF5F58 389E0577 B8990BB3

   The KEi payload is as follows.

 00000048 00130000 DAD0B653 94221CF9 B051E1FE CA5787D0 98DFE637 FC90B9EF
 945D0C37 72581180 5271A046 1CDB8252 D61F1C45 6FA3E59A B1F45B33 ACCF5F58
 389E0577 B8990BB3
------------------------------------
That sure looks like the concatenation of x an y, which is why I responded as I did earlier.

The record of this change is pretty clear. On 16 Feb 2006, Tero posted a criticism of the -02 version of the draft, saying that it didn't explain the formats explicitly, only in the test vectors. After that, the authors updated the draft to -03 to say explicitly that the format was the concatenation of x and y, which matches the test vectors that had already been in the document. The errata disagrees with the change in -03 and the test vectors.

My view is that the errata is technically wrong and should be withdrawn because it changes something that is disagreed to by test vectors in the document itself. If the authors of RFC 4753 want the format to be just the x coordinate, they should prepare a revision to RFC 4753 that obsoletes it and has correct text and test vectors.

--Paul Hoffman, Director
--VPN Consortium

---

From: Sean Kevin O'Keeffe <[email-masked]>
Date: Thu, 2 Jul 2009 21:46:11 -0400

On Jul 2, 2009, at 8:18 PM, Paul Hoffman wrote:

 > It appears that the errata is either wrong or insufficient. If the
 > errata is right, then I'm pretty sure the test vectors in section 8
 > are wrong. For example, from 8.1:

<snip>

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.

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.

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."
I'm aware of several implementations that comply with this errata,
so I think a decision to withdraw it requires careful deliberation.
That being said, this issue needs to be clearly resolved so
implementations from different vendors can interoperate.

Regards, Sean

Sean Kevin O'Keeffe
STRATUS Solutions, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Jul 2009 19:13:24 -0700

>wire between IKEv2 peers, and the value they used as a seed to

The fact that they're different seems needlessly error-prone.

>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.

>   "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.

>implementations from different vendors can interoperate.

Fully agree.

--Paul Hoffman, Director
--VPN Consortium

---

From: Scott C Moonen <[email-masked]>
Date: Sat, 4 Jul 2009 07:43:11 -0400

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

From:
Paul Hoffman <[email-masked]>
To:
"Sean Kevin O'Keeffe" <[email-masked]>
Cc:
[email-masked]
Date:
07/02/2009 10:13 PM
Subject:
Re: [IPsec] IKE's DH groups 19-21, NIST, FIPS 140-2, etc.

>   "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:

giry:

g^ir:

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.

Fully agree.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 4 Jul 2009 07:58:17 -0700

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

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 5 Jul 2009 10:26:21 +0300

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Hoffman
> Sent: Saturday, July 04, 2009 17:58
> To: Scott C Moonen
> Cc: [email-masked]; Sean Kevin O'Keeffe
> Subject: Re: [IPsec] IKE's DH groups 19-21, NIST, FIPS 140-2, etc.
> 
> 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.
> 
> Scanned by Check Point Total Security Gateway.

---

From: Scott C Moonen <[email-masked]>
Date: Mon, 6 Jul 2009 09:44:22 -0400

> 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.

From:
Yaron Sheffer <[email-masked]>
To:
Paul Hoffman <[email-masked]>, Scott C Moonen/Raleigh/IBM@IBMUS
Cc:
"[email-masked]" <[email-masked]>, "Sean Kevin O'Keeffe" 
<[email-masked]>
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

> >If there's agreement that we need a new RFC, I'd be glad to pitch in 
with
> the effort.

---

From: Russ Housley <[email-masked]>
Date: Mon, 06 Jul 2009 13:55:07 -0400

I agree.  The Y coordinate should not be part of the
calculation.

Russ

At 09:44 AM 7/6/2009, Scott C Moonen wrote:

> - There are no security
implications: the application of PRF in "SKEYSEED =

> 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.

From: Yaron Sheffer
<[email-masked]>

To: Paul Hoffman
<[email-masked]>, Scott C Moonen/Raleigh/IBM@IBMUS

Cc:
"[email-masked]" <[email-masked]>,
"Sean Kevin O'Keeffe" <[email-masked]>

Date: 07/05/2009 03:26
AM

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

Given that:

- 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

(
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

> From: [email-masked]
[mailto:[email-masked]
] On Behalf Of

> >If there's agreement that we need a new RFC, I'd be glad to
pitch in with

> Generally, this should be done by the authors themselves. Failing
that,

> someone else could do it.

IPsec mailing list

[email-masked]

---

From: Russ Housley <[email-masked]>
Date: Mon, 06 Jul 2009 16:15:58 -0400

I think a fix is already in the works:
https://datatracker.ietf.org/doc/draft-solinas-rfc4753bis/

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 9 Jul 2009 18:27:22 -0700 (PDT)

Hi,

  RFC 5114 claims it defines new ECP groups 19, 20, and 21 for IKE but
so does RFC 4753. Interestingly the curve definitions are different but
the orders are the same (maybe it's just interesting because I don't
understand why). RFC 5114 also defines some new MODP groups but RFC 4753
does not.

  One nice thing about RFC 5114 is that it updates the IANA repositories
for TLS, SSH, and SMIME as well as IKE so these groups can be used by
other IETF protocols that require them. RFC 4753 only defines their use
in IKE.

  If there is no cryptographic difference between ECP curve 19 (20 and 21)
as defined in RFC 5114 and RFC 4753 then can some mention be made in this
draft to that effect? And can it then obsolete RFC 5114 as well as RFC
4753? It just seems strange to have two RFCs defining the same group
differently. And can this I-D also include IANA considerations for TLS,
SSH, and SMIME if it's going to obsolete RFC 5114?

  regards,

  Dan.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 12 Jul 2009 08:32:52 -0700

At 6:27 PM -0700 7/9/09, Dan Harkins wrote:
>so does RFC 4753.

To be fair, I don't see where RFC 5114 claims that they are new. In fact, it says "Three of these groups were previously specified for use with IKE [RFC4753]".

> Interestingly the curve definitions are different but
>understand why).

Where do you think they differ? The values look the same to me, but I could have missed something.

>draft to that effect?

RFC 4753 and RFC 5114 are uncorrelated Informational RFCs written by different groups of authors. Maybe it is better to keep them uncorrelated, and only link them if one of the other goes on Standards Track.

> And can it then obsolete RFC 5114 as well as RFC
>4753?

As you point out, 5114 does things that 4753 does not (new MODP groups, coverage of more protocols). I don't think we should ask the 4753bis authors to significantly expand their document in a way that they didn't intend in the original.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 12 Jul 2009 09:59:41 -0700 (PDT)

Hi Paul,

  RFC5114 doesn't say they're new, it just gives a definition for them.
And the difference is in the curve equations. For group 19 RFC4753 says
that the equation for the curve is y^2 = x^3 - 3x + b and RFC5114 say the
equation for the curve is y^2 = x^3 + ax + b.

  The equation for the curve is what defines whether a particular (x,y)
combination is a valid point on the curve-- i.e. that it's in the group.
That's why I find it interesting that the order (the number of points
that satisfy the equation for the curve) is the same for both definitions.

  Of course, since p-3=a and the generator is the same it may not matter.
But it still seems wrong to have two different documents defining the same
curve differently, even if they are uncorrelated Informational RFCs.

  Can you elaborate on why you don't want to "ask the 4753bis authors to
significantly expand their document in a way that they didn't intend in
the original"? It seems like a perfectly reasonable request. And "no, we
don't want to do that" is an acceptable response provided it has a
reason.

  regards,

  Dan.

On Sun, July 12, 2009 8:32 am, Paul Hoffman wrote:
> To be fair, I don't see where RFC 5114 claims that they are new. In fact,
> it says "Three of these groups were previously specified for use with IKE
> [RFC4753]".
>
> RFC 4753 and RFC 5114 are uncorrelated Informational RFCs written by
> different groups of authors. Maybe it is better to keep them uncorrelated,
> and only link them if one of the other goes on Standards Track.
>
> As you point out, 5114 does things that 4753 does not (new MODP groups,
> coverage of more protocols). I don't think we should ask the 4753bis
> authors to significantly expand their document in a way that they didn't
> intend in the original.
>
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 12 Jul 2009 13:33:28 -0700

>  Of course, since p-3=a and the generator is the same it may not matter.

Exactly.

>curve differently, even if they are uncorrelated Informational RFCs.

Again: RFC 5114 does not "define" those three curves. The IANA registry, <http://www.iana.org/assignments/ikev2-parameters>, defines them, and has the definition pointing to RFC 4753.

>the original"?

Yes. The current rfc4752bis, which is in IETF Last Call, has a very clear focus, namely to fix the error that started this thread. Asking them to also take on work that is unrelated to that focus is inappropriate. If they wanted to do that, they could have done so before IETF Last Call.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 12 Jul 2009 23:30:38 -0700 (PDT)

On Sun, July 12, 2009 1:33 pm, Paul Hoffman wrote:
> Again: RFC 5114 does not "define" those three curves. The IANA registry,
> <http://www.iana.org/assignments/ikev2-parameters>, defines them, and has
> the definition pointing to RFC 4753.

  No, the IANA registry defines a magic number one uses to refer to
the parameters of the curve which are actually defined in an RFC. And while
FFFFFFFF 00000001 00000000 00000000 00000000 FFFFFFFF FFFFFFFF FFFFFFFC
may equal -3 in this wonderful prime modulus group it causes a double- or
triple-take when implementing the group referred to by the IANA registry
that is defined in this RFC. There are 2 RFCs that define the same
parameters of group 19 differently even if mathematically they are not
different.

  And actually I think defining the curve ala RFC5114 is better since
a prime finite field is defined as [0, 1, ..., p-1] and "-3" is not in
that set.

> Yes. The current rfc4752bis, which is in IETF Last Call, has a very clear
> focus, namely to fix the error that started this thread. Asking them to
> also take on work that is unrelated to that focus is inappropriate. If
> they wanted to do that, they could have done so before IETF Last Call.

  When "Last Call" is announced it doesn't mean you can't order a drink
anymore, it means this is your last chance to order a drink before it's
too late. For I-Ds, comments post publication are "too late" and it hasn't
been published yet so it's not too late to ask the authors to change
their draft.

  Dan.