[IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)
Tero Kivinen <kivinen@iki.fi> Fri, 18 December 2009 13:08 UTC
Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E8A3A6A25 for <ipsec@core3.amsl.com>; Fri, 18 Dec 2009 05:08:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level:
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x85rbGSCw9lG for <ipsec@core3.amsl.com>; Fri, 18 Dec 2009 05:08:16 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 80EC33A6955 for <ipsec@ietf.org>; Fri, 18 Dec 2009 05:08:14 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nBID7t76020467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ipsec@ietf.org>; Fri, 18 Dec 2009 15:07:55 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBID7tk9018489; Fri, 18 Dec 2009 15:07:55 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <19243.32427.247190.77844@fireball.kivinen.iki.fi>
Date: Fri, 18 Dec 2009 15:07:55 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: ipsec@ietf.org
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 26 min
X-Total-Time: 66 min
Subject: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Dec 2009 13:08:17 -0000
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). -- kivinen@iki.fi
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Yaron Sheffer
- [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess … Tero Kivinen
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Scott C Moonen
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Paul Hoffman
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Dan Harkins
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Yoav Nir
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Tero Kivinen
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Tero Kivinen
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Tero Kivinen
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Yaron Sheffer
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Dan Harkins
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Dan Harkins
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Black_David
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Bill Sommerfeld
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Dan Harkins
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Black_David
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Dan Harkins
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Yoav Nir
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Tero Kivinen
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Tero Kivinen
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Tero Kivinen
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Jerome A. Solinas
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Dan Harkins
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Tero Kivinen
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Jerome A. Solinas