Internet Engineering Task Force (IETF) D. Fu Request for Comments: 5903 J. Solinas Obsoletes: 4753 NSA Category: Informational June 2010 ISSN: 2070-1721
Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2
Abstract
This document describes three Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups. These groups are based on modular arithmetic rather than binary arithmetic. These groups are defined to align IKE and IKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. This document obsoletes RFC 4753.
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5903.
Fu & Solinas Informational [Page 1]
RFC 5903 ECP Groups for IKE and IKEv2 June 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................3 2. Requirements Terminology ........................................4 3. Additional ECC Groups ...........................................4 3.1. 256-Bit Random ECP Group ...................................4 3.2. 384-Bit Random ECP Group ...................................5 3.3. 521-Bit Random ECP Group ...................................6 4. Security Considerations .........................................7 5. Alignment with Other Standards ..................................7 6. IANA Considerations .............................................7 7. ECP Key Exchange Data Formats ...................................8 8. Test Vectors ....................................................9 8.1. 256-Bit Random ECP Group ...................................9 8.2. 384-Bit Random ECP Group ..................................10 8.3. 521-Bit Random ECP Group ..................................11 9. Changes from RFC 4753 ..........................................13 10. References ....................................................13 10.1. Normative References .....................................13 10.2. Informative References ...................................14
This document describes default Diffie-Hellman groups for use in IKE and IKEv2 in addition to the Oakley Groups included in [IKE] and the additional groups defined since [IANA-IKE]. This document assumes that the reader is familiar with the IKE protocol and the concept of Oakley Groups, as defined in RFC 2409 [IKE].
RFC 2409 [IKE] defines five standard Oakley Groups: three modular exponentiation groups and two elliptic curve groups over GF[2^N]. One modular exponentiation group (768 bits - Oakley Group 1) is mandatory for all implementations to support, while the other four are optional. Nineteen additional groups subsequently have been defined and assigned values by IANA. All of these additional groups are optional.
The purpose of this document is to expand the options available to implementers of elliptic curve groups by adding three ECP groups (elliptic curve groups modulo a prime). The reasons for adding such groups include the following.
- The groups proposed afford efficiency advantages in software applications since the underlying arithmetic is integer arithmetic modulo a prime rather than binary field arithmetic. (Additional computational advantages for these groups are presented in [GMN].)
- The groups proposed encourage alignment with other elliptic curve standards. The proposed groups are among those standardized by NIST, the Standards for Efficient Cryptography Group (SECG), ISO, and ANSI. (See Section 5 for details.)
- The groups proposed are capable of providing security consistent with the Advanced Encryption Standard [AES].
In summary, due to the performance advantages of elliptic curve groups in IKE implementations and the need for further alignment with other standards, this document defines three elliptic curve groups based on modular arithmetic.
These groups were originally proposed in [RFC4753]. This document changes the format of the shared key produced by a Diffie-Hellman exchange using these groups. The shared key format used in this specification appeared earlier as an erratum to RFC 4753 [Err9], but some implementors of RFC 4753 were unaware of the erratum and did not implement the correction. Implementations of RFC 4753 that incorporate the correction are interoperable with implementations of this specification. However, there is a potential for interoperability problems between implementations of this
Fu & Solinas Informational [Page 3]
RFC 5903 ECP Groups for IKE and IKEv2 June 2010
specification and implementations of RFC 4753 that did not implement the correction from the erratum. These problems could be difficult to detect and analyze since both use the same code point but the secret value (which is probably not available to the trouble desk) is computed differently. Where peers are not interoperable, the initiator will never receive a response and eventually times out.
Section 9 provides more details of the changes from [RFC4753]. This document obsoletes RFC 4753 and addresses the erratum.
IKE and IKEv2 implementations SHOULD support an ECP group with the following characteristics. The curve is based on the integers modulo the generalized Mersenne prime p given by:
IKE and IKEv2 implementations SHOULD support an ECP group with the following characteristics. The curve is based on the integers modulo the generalized Mersenne prime p given by:
IKE and IKEv2 implementations SHOULD support an ECP group with the following characteristics. The curve is based on the integers modulo the Mersenne prime p given by:
Since this document proposes groups for use within IKE and IKEv2, many of the security considerations contained within [IKE] and [IKEv2] apply here as well.
The groups proposed in this document correspond to the symmetric key sizes 128 bits, 192 bits, and 256 bits. This allows the IKE key exchange to offer security comparable with the AES algorithms [AES].
IANA has updated its registries of Diffie-Hellman groups for IKE in [IANA-IKE] and for IKEv2 in [IANA-IKEv2] to include the groups defined above.
In [IANA-IKE], the groups appear as entries in the list of Diffie- Hellman groups given by Group Description (attribute class 4).
Fu & Solinas Informational [Page 7]
RFC 5903 ECP Groups for IKE and IKEv2 June 2010
The descriptions are "256-bit random ECP group", "384-bit random ECP group", and "521-bit random ECP group". In each case, the group type (attribute class 5) has the value 2 (ECP, elliptic curve group over GF[P]).
In [IANA-IKEv2], the groups appear as entries in the list of IKEv2 transform type values for Transform Type 4 (Diffie-Hellman groups).
These entries in both [IANA-IKE] and [IANA-IKEv2] have been updated. The update consisted of changing the reference from [RFC4753] to this document.
In an ECP key exchange, the Diffie-Hellman public value passed in a KE payload consists of two components, x and y, corresponding to the coordinates of an elliptic curve point. Each component MUST have bit length as given in the following table.
Diffie-Hellman group component bit length ------------------------ --------------------
256-bit Random ECP Group 256 384-bit Random ECP Group 384 521-bit Random ECP Group 528
This length is enforced, if necessary, by prepending the value with zeros.
The Diffie-Hellman public value is obtained by concatenating the x and y values.
The Diffie-Hellman shared secret value consists of the x value of the Diffie-Hellman common value.
These formats should be regarded as specific to ECP curves and may not be applicable to EC2N (elliptic curve group over GF[2^N]) curves.
The following are examples of the IKEv2 key exchange payload for each of the three groups specified in this document.
We denote by g^n the scalar multiple of the point g by the integer n; it is another point on the curve. In the literature, the scalar multiple is typically denoted ng; the notation g^n is used in order to conform to the notation used in [IKE] and [IKEv2].
Section 7 (ECP Key Exchange Data Formats) of [RFC4753] states that
The Diffie-Hellman public value is obtained by concatenating the x and y values.
The format of the Diffie-Hellman shared secret value is the same as that of the Diffie-Hellman public value.
This document replaces the second of these two paragraphs with the following:
The Diffie-Hellman shared secret value consists of the x value of the Diffie-Hellman common value.
This change aligns the ECP key exchange format with that used in other standards.
This change appeared earlier as an erratum to RFC 4753 [Err9]. This document obsoletes RFC 4753 and addresses the erratum.
Section 8 (Test Vectors) of [RFC4753] provides three examples of Diffie-Hellman key agreement using the ECP groups. This document changes the last paragraph of each subsection of Section 8 to reflect the new format.
[AES] U.S. Department of Commerce/National Institute of Standards and Technology, Advanced Encryption Standard (AES), FIPS PUB 197, November 2001, <http://csrc.nist.gov/publications/fips/index.html>.
[DSS] U.S. Department of Commerce/National Institute of Standards and Technology, Digital Signature Standard (DSS), FIPS PUB 186-2, January 2000. <http://csrc.nist.gov/publications/fips/index.html>.
[ISO-14888-3] International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 14888-3:2006, Information Technology: Security Techniques: Digital Signatures with Appendix: Part 3 - Discrete Logarithm Based Mechanisms.
[ISO-15946-1] International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 15946-1: 2002-12-01, Information Technology: Security Techniques: Cryptographic Techniques based on Elliptic Curves: Part 1 - General.
Fu & Solinas Informational [Page 14]
RFC 5903 ECP Groups for IKE and IKEv2 June 2010
[ISO-15946-2] International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 15946-2: 2002-12-01, Information Technology: Security Techniques: Cryptographic Techniques based on Elliptic Curves: Part 2 - Digital Signatures.
[ISO-15946-3] International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 15946-3: 2002-12-01, Information Technology: Security Techniques: Cryptographic Techniques based on Elliptic Curves: Part 3 - Key Establishment.
[ISO-15946-4] International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 15946-4: 2004-10-01, Information Technology: Security Techniques: Cryptographic Techniques based on Elliptic Curves: Part 4 - Digital Signatures giving Message Recovery.
[ISO-18031] International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 18031:2005, Information Technology: Security Techniques: Random Bit Generation.
[NIST] U.S. Department of Commerce/National Institute of Standards and Technology. Recommendation for Pair- Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, NIST Special Publication 800-56A, March 2006, <http://csrc.nist.gov/CryptoToolkit/KeyMgmt.html>.
[SEC2] Standards for Efficient Cryptography Group. SEC 2 - Recommended Elliptic Curve Domain Parameters, v. 1.0, 2000, <http://www.secg.org>.
[X9.62-1998] American National Standards Institute, X9.62-1998: Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm. January 1999.
[X9.62-2005] American National Standards Institute, X9.62:2005: Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA).
Fu & Solinas Informational [Page 15]
RFC 5903 ECP Groups for IKE and IKEv2 June 2010
[X9.63] American National Standards Institute. X9.63-2001, Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport using Elliptic Curve Cryptography. November 2001.
Authors' Addresses
David E. Fu National Information Assurance Research Laboratory National Security Agency
EMail: defu@orion.ncsc.mil
Jerome A. Solinas National Information Assurance Research Laboratory National Security Agency