Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)

[Yoav Nir <[e-mail]>]

If there is such an implementation, then it's not interoperating with all the other implementations and should be fixed.

If someone shipped something like that, then the only reason they haven't noticed yet, is because they (1) didn't test it well enough, and (2) their customers are using some other option like 1024-bit MODP group (and 3DES, but that's beside the point)

Anyway, making everyone add a new group "28" just so nobody needs to patch their old implementation of group "20" seems like wasted effort to me.  We can keep group 20, and fix the spec to prescribe what everybody is doing anyway.
________________________________________
From: [e-mail] [[e-mail]] On Behalf Of Scott C Moonen [[e-mail]]
Sent: Friday, December 18, 2009 15:37
To: Tero Kivinen
Cc: [e-mail]; [e-mail]
Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)

Tero, what you propose seems the right way to go in principle, but I suspect we are solving a problem that doesn't exist.  Is there any crypto library or device that exposes the y coordinate for use in the ECDH secret?  It seems pretty well established that the x coordinate serves as the ECDH secret.  Moreover, since the y coordinate provides only one more bit of independent information, it's actually misleading to use it.

I seriously doubt there is any implementation that does not implement the intent of the erratum, if only because there are immense practical barriers to implementing the RFC as written.  Given that, I think the practical result of what you propose will actually be more confusion and a longer period of time before all implementations (as well as all standards/profiles) are able to re-stabilize to the new ECDH landscape.  The practical cost of making this change is greater than the practical benefit it buys.

On the other hand, if there is such an implementation, then we probably do need to do something like what you propose.


Scott Moonen ([e-mail])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From:   Tero Kivinen <[e-mail]>
To:     [e-mail]
Date:   12/18/2009 08:08 AM
Subject:        [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)

________________________________



I got just request to review modifications to IKEv2 IANA because of
the draft-solinas-rfc4753bis-01.txt.

We had this discussion a while back on the IPsec list where we noted
that having errata which makes non-interoperable change to the RFC is
not really ok, and we requested the authors to submit new document.

Errata: http://www.rfc-editor.org/errata_search.php?rfc=4753&rec_status=15&presentation=records

Email thread: http://www.ietf.org/mail-archive/web/ipsec/current/msg04529.html

At that point Paul summarized things very nicely:

  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.

Now when this came to me when IANA asked me to do Expert review to the
IANA allocations, I noticed that it would be very bad if we reused the
old numbers 19, 20, 21 as that would mean nobody knows which version
of the RFC (old RFC without errata, or RFC4753 with errata == new RFC)
is really used.

As the Diffie-Hellman groups are negotiated and the registry is 16
bits, we do not need to try to save the numbers, I think it would be
bad idea to reuse the existing values with different meaning. Because
of this I answered that the new groups with new meanings would need to
get new numbers.

When I started investigating problem bit more I found out that RFC5114
which defines 2 new ECP groups (in addition of repeating the 3 ECP
groups from RFC4753) says:
----------------------------------------------------------------------
3.2.  IKE

  Use of MODP Diffie-Hellman groups with IKEv2 is defined in [RFC4306],
  and the use of MODP groups with IKEv1 is defined in [RFC2409].
  However, in the case of ECP Diffie-Hellman groups, the format of key
  exchange payloads and the derivation of a shared secret has thus far
  been specified on a group-by-group basis.  For the ECP Diffie-Hellman
  groups defined in this document, the key exchange payload format and
  shared key derivation procedure specified in [RFC4753] MUST be used
  (with both IKEv2 and IKEv1).
----------------------------------------------------------------------

Now if we obsolete RFC4753, does that mean that this reference will
also change, so which format is used for these groups 25 and 26 define
in RFC5114?

Do we need a new numbers for those groups also so it will be clear
which version they use.

Then there is also the RFC4869 which defines UI suites. That refers
Diffie-Hellman groups as "256-bit random ECP group [RFC4753]". Which
format of group those uses. When we now change RFC4753 does that mean
that old implementations using RFC4869 UI suites using original
RFC4753 groups is not compatible with newer RFC4869 version or what?

I think the best way forward is to allocate new numbers for all
RFC4753 derived groups (19, 20, 21, 25, 26) and create new UI suites
using those new group numbers.

This will create one time update where everybody needs to change their
code by changing number 19 to n and 20 to n+1 and so on, and at the
same time verify that the secret they use is only the x-coordinate.
This change is small and can be done very quickly, but after that we
do not need to think whether we can interoperate with someone using
ECP group n, as we know it must be using new secret format.

If someone uses old groups 19, 20, 21, 25, or 26 then you can make
your guess whether they also implemented errata or not, and act based
on that. Good thing is that as Diffie-Hellman groups are negotiated in
IKEv2 it is easy to offer both 19 and new group n if backward
compatibility with old versions is needed (provided you also know
whether the group 19 on the other end uses errata or not).
--
[e-mail]
_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec