This document is obsolete. Please
refer to RFC 5903.
Network Working Group D. Fu Request for Comments: 4753 J. Solinas Category: Informational NSA January 2007
ECP Groups for IKE and IKEv2
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes new 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. Specifically, the new curve groups are based on modular arithmetic rather than binary arithmetic. These new 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.
Table of Contents
1. Introduction ....................................................2 2. Requirements Terminology ........................................3 3. Additional ECC Groups ...........................................3 3.1. 256-bit Random ECP Group ...................................3 3.2. 384-bit Random ECP Group ...................................4 3.3. 521-bit Random ECP Group ...................................5 4. Security Considerations .........................................6 5. Alignment with Other Standards ..................................6 6. IANA Considerations .............................................6 7. ECP Key Exchange Data Formats ...................................7 8. Test Vectors ....................................................7 8.1. 256-bit Random ECP Group ...................................8 8.2. 384-bit Random ECP Group ...................................9 8.3. 521-bit Random ECP Group ..................................10 9. References .....................................................12
Fu & Solinas Informational [Page 1]
RFC 4753 ECP Groups for IKE and IKEv2 January 2007
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. Thirteen additional groups subsequently have been defined and assigned values by IANA. All of these additional groups are optional. Of the eighteen groups defined so far, eight are MODP groups (exponentiation groups modulo a prime), and ten are EC2N groups (elliptic curve groups over GF[2^N]). See [RFC3526] for more information on MODP groups.
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 new Advanced Encryption Standard.
These groups could also be defined using the New Group Mode, but including them in this RFC will encourage interoperability of IKE implementations based upon elliptic curve groups. In addition, the availability of standardized groups will result in optimizations for a particular curve and field size and allow precomputation that could result in faster implementations.
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.
Fu & Solinas Informational [Page 2]
RFC 4753 ECP Groups for IKE and IKEv2 January 2007
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 new 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 new entries in the list of Diffie-Hellman groups given by Group Description (attribute class 4). The descriptions are "256-bit random ECP group", "384-bit random ECP
Fu & Solinas Informational [Page 6]
RFC 4753 ECP Groups for IKE and IKEv2 January 2007
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 new entries in the list of IKEv2 transform type values for Transform Type 4 (Diffie-Hellman groups).
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 format of the Diffie-Hellman shared secret value is the same as that of the Diffie-Hellman public value.
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].
Fu & Solinas Informational [Page 7]
RFC 4753 ECP Groups for IKE and IKEv2 January 2007
[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)
[GMN] J. Solinas, Generalized Mersenne Numbers, Combinatorics and Optimization Research Report 99-39, 1999. (http://www.cacr.math.uwaterloo.ca/)
[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.
[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.
Fu & Solinas Informational [Page 13]
RFC 4753 ECP Groups for IKE and IKEv2 January 2007
[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 Publication 800-56A, March 2006. (http://csrc.nist.gov/CryptoToolkit/KeyMgmt.html)
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[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).
[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.
Fu & Solinas Informational [Page 14]
RFC 4753 ECP Groups for IKE and IKEv2 January 2007
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
EMail: jasolin@orion.ncsc.mil
Fu & Solinas Informational [Page 15]
RFC 4753 ECP Groups for IKE and IKEv2 January 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.