Network Working Group M. Lepinski Request for Comments: 5114 S. Kent Category: Informational BBN Technologies January 2008
Additional Diffie-Hellman Groups for Use with IETF Standards
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.
Abstract
This document describes eight Diffie-Hellman groups that can be used in conjunction with IETF protocols to provide security for Internet communications. The groups allow implementers to use the same groups with a variety of security protocols, e.g., SMIME, Secure SHell (SSH), Transport Layer Security (TLS), and Internet Key Exchange (IKE).
All of these groups comply in form and structure with relevant standards from ISO, ANSI, NIST, and the IEEE. These groups are compatible with all IETF standards that make use of Diffie-Hellman or Elliptic Curve Diffie-Hellman cryptography.
These groups and the associated test data are defined by NIST on their web site [EX80056A], but have not yet (as of this writing) been published in a formal NIST document. Publication of these groups and associated test data, as well as describing how to use Diffie-Hellman and Elliptic Curve Diffie-Hellman for key agreement in all of the protocols cited below, in one RFC, will facilitate development of interoperable implementations and support the Federal Information Processing Standard (FIPS) validation of implementations that make use of these groups.
Lepinski & Kent Informational [Page 1]
RFC 5114 Additional Diffie-Hellman Groups January 2008
Table of Contents
1. Introduction ....................................................2 2. Additional Diffie-Hellman Groups ................................4 2.1. 1024-bit MODP Group with 160-bit Prime Order Subgroup ......4 2.2. 2048-bit MODP Group with 224-bit Prime Order Subgroup ......4 2.3. 2048-bit MODP Group with 256-bit Prime Order Subgroup ......5 2.4. 192-bit Random ECP Group ...................................6 2.5. 224-bit Random ECP Group ...................................7 2.6. 256-bit Random ECP Group ...................................7 2.7. 384-bit Random ECP Group ...................................8 2.8. 521-bit Random ECP Group ...................................9 3. Using These Groups with IETF Standards ..........................9 3.1. X.509 Certificates .........................................9 3.2. IKE .......................................................10 3.3. TLS .......................................................10 3.4. SSH .......................................................11 3.5. SMIME .....................................................11 4. Security Considerations ........................................12 5. IANA Considerations ............................................13 6. Acknowledgments ................................................13 Appendix A: Test Data .............................................14 A.1. 1024-bit MODP Group with 160-bit Prime Order Subgroup......15 A.2. 2048-bit MODP Group with 224-bit Prime Order Subgroup......15 A.3. 2048-bit MODP Group with 256-bit Prime Order Subgroup......16 A.4. 192-bit Random ECP Group ..................................17 A.5. 224-bit Random ECP Group ..................................18 A.6. 256-bit Random ECP Group ..................................18 A.7. 384-bit Random ECP Group ..................................19 A.8. 521-bit Random ECP Group ..................................19 Normative References ..............................................20 Informative References ............................................20
This document provides parameters and test data for several Diffie-Hellman (D-H) groups that can be used with IETF protocols that employ D-H keys, (e.g., IKE, TLS, SSH, and SMIME) and with IETF standards, such as Public Key Infrastructure for X.509 Certificates (PKIX) (for certificates that carry D-H keys). These groups complement others already documented for the IETF, including the "Oakley" groups defined in RFC 2409 [RFC2409] for use with IKEv1, and several additional D-H groups defined later, e.g., [RFC3526] and [RFC4492].
Lepinski & Kent Informational [Page 2]
RFC 5114 Additional Diffie-Hellman Groups January 2008
The initial impetus for the definition of D-H groups (in the IETF) arose in the IPsec (IKE) context, because of the use of an ephemeral, unauthenticated D-H exchange as the starting point for that protocol. RFC 2409 defined 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) was declared to be mandatory for all IKEv1 implementations to support, while the other four were optional. Sixteen additional groups subsequently have been defined and registered with IANA for use with IKEv1, including eight that have also been registered for use with IKEv2. All of these additional groups are optional in the IKE context. Of the twenty-one groups defined so far for use with IKE, eight are MODP groups (exponentiation groups modulo a prime), ten are EC2N groups (elliptic curve groups over GF[2^N]), and three are ECP groups (elliptic curve groups over GF[P]).
The purpose of this document is to provide the parameters and test data for eight additional groups, in a format consistent with existing RFCs along with instructions on how these groups can be used with IETF protocols such as SMIME, SSH, TLS, and IKE. Three of these groups were previously specified for use with IKE [RFC4753], and five of these groups were previously specified for use with TLS [RFC4492]. (The latter document does not provide or reference test data for the specified groups). By combining the specification of all eight groups with test data and instructions for use in a variety of protocols, this document serves as a resource for implementers who may wish to offer the same Diffie-Hellman groups for use with multiple IETF protocols.
All of these groups are compatible with applicable ISO [ISO-14888-3], ANSI [X9.62], and NIST [NIST80056A] standards for Diffie-Hellman key exchange. These groups and the associated test data are defined by NIST on their web site [EX80056A], but have not yet (as of this writing) been published in a formal NIST document. Publication of these groups with associated test data as an RFC will facilitate development of interoperable implementations and support FIPS validation of implementations that make use of these groups.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
Lepinski & Kent Informational [Page 3]
RFC 5114 Additional Diffie-Hellman Groups January 2008
This section contains the specification for eight groups for use in IKE, TLS, SSH, etc. There are three standard prime modulus groups and five elliptic curve groups. All groups were taken from publications of the National Institute of Standards and Technology, specifically [DSS] and [NIST80056A]. Test data for each group is provided in Appendix A.
2.1. 1024-bit MODP Group with 160-bit Prime Order Subgroup
The curve is based on the integers modulo the prime p given by: p = 2^(384)-2^(128)-2^(96)+2^(32)-1
Group prime (in hexadecimal): p = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFFFF 00000000 00000000 FFFFFFFF
The equation for the elliptic curve is: y^2 = x^3 + ax + b (mod p)
Group curve parameter A (in hexadecimal): a = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFFFF 00000000 00000000 FFFFFFFC
Group curve parameter B (in hexadecimal): b = B3312FA7 E23EE7E4 988E056B E3F82D19 181D9C6E FE814112 0314088F 5013875A C656398D 8A2ED19D 2A85C8ED D3EC2AEF
The generator for this group is given by: g=(gx,gy) where
Representation of both MODP and Elliptic Curve Diffie-Hellman public keys (and associated parameters) in X.509 certificates is defined in [RFC3279]. The MODP groups defined above MUST be represented via the syntax defined in Section 2.3.3, and the elliptic curve groups via
Lepinski & Kent Informational [Page 9]
RFC 5114 Additional Diffie-Hellman Groups January 2008
the syntax defined in Section in 2.3.5 of that RFC. When a Diffie-Hellman public key is encoded in a certificate, if the KeyUsage extension is present, the keyAgreement bits MUST be asserted, and encipherOnly or decipherOnly (but not both) MAY be asserted.
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).
In order to use a Diffie-Hellman group with IKE, it is required that a transform ID for the group be registered with IANA. The following table provides the Transform IDs of each Diffie-Hellman group described in this document, as registered in both [IANA-IKE] and [IANA-IKE2].
NAME | NUMBER --------------------------------------------------------+--------- 1024-bit MODP Group with 160-bit Prime Order Subgroup | 22 2048-bit MODP Group with 224-bit Prime Order Subgroup | 23 2048-bit MODP Group with 256-bit Prime Order Subgroup | 24 192-bit Random ECP Group | 25 224-bit Random ECP Group | 26 256-bit Random ECP Group | 19 384-bit Random ECP Group | 20 521-bit Random ECP Group | 21
Use of MODP Diffie-Hellman groups in TLS 1.1 is defined in [RFC4346]. TLS 1.0, the widely deployed predecessor of TLS 1.1, is specified in [RFC2246] and is the same as TLS 1.1 with respect to the use of (MODP) Diffie-Hellman to compute a pre-Master secret. (Currently, the TLS working group is in the process of producing a specification for TLS 1.2. It is unlikely that TLS 1.2 will make significant changes to the use of Diffie-Hellman, and thus the following will likely also be applicable to TLS 1.2).
Lepinski & Kent Informational [Page 10]
RFC 5114 Additional Diffie-Hellman Groups January 2008
A server may employ a certificate containing (fixed) Diffie-Hellman parameters, and likewise for a client using a certificate. Thus, the relevant PKIX RFCs (see 3.1 above) are applicable. Alternatively, a server may send ephemeral Diffie-Hellman parameters in the server key exchange message, where the message signature is verified using an RSA- or DSS-signed server certificate. The details for accomplishing this for MODP Diffie-Hellman groups are provided in [RFC2246].
Use of Elliptic Curve Diffie-Hellman in TLS 1.1 (and 1.0) is defined in [RFC4492]. The elliptic curves in this document appear in the IANA EC Named Curve Registry [IANA-TLS], although the names in the registry are taken from the Standards for Efficient Cryptography Group (SECG) specification [SECG] and differ from the names appearing in NIST publications. The following table provides the EC Named Curve ID for each of the elliptic curves along with both the NIST name and the SECG name for the curve.
NAME (NIST) | NUMBER | NAME (SECG) ---------------------------------+--------------+--------------- 192-bit Random ECP Group | 19 | secp192r1 224-bit Random ECP Group | 21 | secp224r1 256-bit Random ECP Group | 23 | secp256r1 384-bit Random ECP Group | 24 | secp384r1 521-bit Random ECP Group | 25 | secp521r1
Use of Diffie-Hellman with SSH was defined initially in [RFC4253]. That RFC defined two MODP Diffie-Hellman groups, and called for the registration of additional groups via an IANA registry. However, [RFC4419] extended the original model to allow MODP Diffie-Hellman parameters to be transmitted as part of the key exchange messages. Thus, using RFC 4419, no additional specifications (or IANA registry actions) are required to enable use of the MODP groups defined in this document. At this time, no RFC describes the use of Elliptic Curve Diffie-Hellman with SSH. However, [SSH-ECC] provides a description of how to make use of Elliptic Curve Diffie-Hellman with SSH.
Use of Diffie-Hellman in SMIME is defined via a discussion of Cryptographic Message Syntax (CMS) enveloped data [RFC3852]. For MODP Diffie-Hellman, the appropriate reference is [RFC2631]. This specification calls for a sender to extract the Diffie-Hellman (MODP) parameters from a recipient's certificate, and thus the PKIX specifications for representation of Diffie-Hellman parameters suffice. The sender transmits his public key via the
Lepinski & Kent Informational [Page 11]
RFC 5114 Additional Diffie-Hellman Groups January 2008
OriginatorIdentifierorKey field, or via a reference to the sender's certificate.
Use of Elliptic Curve Diffie-Hellman in CMS is defined in [RFC3278]. As with use of MODP Diffie-Hellman in the CMS context, the sender is assumed to acquire the recipient's public key and parameters from a certificate. The sender includes his Elliptic Curve Diffie-Hellman public key in the KeyAgreeRecipientInfo originator field. (See Section 8.2 of RFC 3278 for details of the ECC-CMS-SharedInfo).
The strength of a key derived from a Diffie-Hellman exchange using any of the groups defined here depends on the inherent strength of the group, the size of the exponent used, and the entropy provided by the random number generator used. The groups defined in this document were chosen to make the work factor for solving the discrete logarithm problem roughly comparable to an attack on the subgroup.
Using secret keys of an appropriate size is crucial to the security of a Diffie-Hellman exchange. For modular exponentiation groups, the size of the secret key should be equal to the size of q (the size of the prime order subgroup). For elliptic curve groups, the size of the secret key must be equal to the size of n (the order of the group generated by the point g). Using larger secret keys provides absolutely no additional security, and using smaller secret keys is likely to result in dramatically less security. (See [NIST80056A] for more information on selecting secret keys.)
When secret keys of an appropriate size are used, an approximation of the strength of each of the Diffie-Hellman groups is provided in the table below. For each group, the table contains an RSA key size and symmetric key size that provide roughly equivalent levels of security. This data is based on the recommendations in [NIST80057].
GROUP | SYMMETRIC | RSA -------------------------------------------+------------+------- 1024-bit MODP with 160-bit Prime Subgroup | 80 | 1024 2048-bit MODP with 224-bit Prime Subgroup | 112 | 2048 2048-bit MODP with 256-bit Prime Subgroup | 112 | 2048 192-bit Random ECP Group | 80 | 1024 224-bit Random ECP Group | 112 | 2048 256-bit Random ECP Group | 128 | 3072 384-bit Random ECP Group | 192 | 7680 521-bit Random ECP Group | 256 | 15360
Lepinski & Kent Informational [Page 12]
RFC 5114 Additional Diffie-Hellman Groups January 2008
Updated the IKE and IKEv2 registries to include the following five groups defined in this document: (Note that the other three ECP groups defined in this document have already been added to the IKE registry).
o 1024-bit MODP Group with 160-bit Prime Order Subgroup
o 2048-bit MODP Group with 224-bit Prime Order Subgroup
o 2048-bit MODP Group with 256-bit Prime Order Subgroup
o 192-bit Random ECP Group
o 224-bit Random ECP Group
Updated [IANA-IKE] and [IANA-IKE2] to reflect the above, which now appear as entries in the list of Diffie-Hellman groups given by Group Description. The descriptions are as stated above.
We wish to thank NIST for publishing the group definitions and providing test data to assist implementers in verifying that software or hardware correctly implements these groups. We also wish to thank Tero Kivinen and Sean Turner for providing helpful comments after reviewing an earlier version of this document.
Lepinski & Kent Informational [Page 13]
RFC 5114 Additional Diffie-Hellman Groups January 2008
The test data in this appendix is a protocol-independent subset of the test data in [EX80056A]. In the test data for the three modular exponentiation groups, we use the following notation:
xA: The secret key of party A
yA: The public key of party A
xB: The secret key of party B
yB: The public key of party B
Z: The shared secret that results from the Diffie-Hellman computation
In the test data for the five elliptic curve groups, we use the following notation:
dA: The secret value of party A
x_qA: The x-coordinate of the public key of party A
y_qA: The y-coordinate of the public key of party A
dB: The secret value of party B
x_qA: The x-coordinate of the public key of party B
y_qA: The y-coordinate of the public key of party B
x_Z: The x-coordinate of the shared secret that results from the Diffie-Hellman computation
y_Z: The y-coordinate of the shared secret that results form the Diffie-Hellman computation
Lepinski & Kent Informational [Page 14]
RFC 5114 Additional Diffie-Hellman Groups January 2008
A.1. 1024-bit MODP Group with 160-bit Prime Order Subgroup
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
Informative References
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC3278] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 3278, April 2002.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
Lepinski & Kent Informational [Page 20]
RFC 5114 Additional Diffie-Hellman Groups January 2008
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie- Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol", RFC 4419, March 2006.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC4753] Fu, D. and J. Solinas, "ECP Groups For IKE and IKEv2", RFC 4753, January 2007.
[SSH-ECC] Green, J. and D. Stebila, "Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer", Work in Progress, 2007.
[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.
RFC 5114 Additional Diffie-Hellman Groups January 2008
[NIST80056A] 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
[X9.62] ANSI X9.62-2005, Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA). 2005.
Author's Addresses
Matt Lepinski BBN Technologies 10 Moulton St. Cambridge, MA 02138
EMail: mlepinski@bbn.com
Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138
EMail: kent@bbn.com
Lepinski & Kent Informational [Page 22]
RFC 5114 Additional Diffie-Hellman Groups January 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.