Internet Draft Paul Hoffman draft-hoffman-ipsec-algorithms-02.txt VPN Consortium May 16, 2003 Expires in six months Intended status: Standards Track Security Algorithms for IKEv2 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The IKEv2 protocol [IKEv2] relies on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IKEv2 systems cannot interoperate unless they are using the same algorithms. This document specifies an initial set of algorithms for registration with IANA, and specifies which are mandatory to implement. This document also specifies optional suites of algorithms and attributes that can be used to simplify the administration of IKEv2. 1. Introduction This document is a companion to IKEv2. Like most security protocols, IKEv2 allows users to chose which cryptographic algorithms they want to use to meet their security needs. Because having choices without any sensible mandatory-to-implement specifications leads to lack of interoperability, this document also specifies which algorithms need to be implemented by systems that conform to the IKEv2 specification. Implementation experience with IKEv1 [RFC2409] has shown that there are so many choices for typical system administrators to make that it is difficult to achieve interoperability without careful pre-agreement. Because of this, the IPsec Working Group agreed that there should be a small number of named suites that cover typical security policies. These suites may be presented in the administrative interface of the IKEv2 system. These suites, often called "UI suites", are optional and do not prevent implementers from allowing individual selection of the security algorithms. 1.1 Mandatory security The must-be-implemented security algorithms listed here are based on currently-deployed hardware that meets the security requirements of the vast majority of current IPsec users, and should be useful for at least a decade according to cryptographic estimates from NIST for business user scenarios. The should-be-implemented security algorithms are based on expectations of where the security industry is moving (namely, to the AES encryption suite) and where more security-conscious users are moving as current key lengths become more attackable due to the steady lowering of cost to mount brute-force attacks. An important lesson learned from IKEv1 is that no system should only implement the mandatory algorithms and expect them to be the best choice for all customers. Some of the requirements sections in this document say "It is expected that in the not-distant future, ...". These statements are based on discussions in the IPsec Working Group and the larger security community. Although there is no guarantee that the changes that are said to be expected will actually happen, IKEv2 implementers should strongly consider following the advice here so that their implementations have the best chance of meeting future expected changes. 1.2 Coverage This document does not specify cryptographic algorithms for IKEv1. IKEv1 specified its own values and mandatory-to-implement algorithms. Note, however, that some of the algorithms in IKEv1 that are listed as mandatory are considered too weak to use for most security environments. This document does not specify cryptographic algorithms for IPsec [RFC2401] when used with manual keying. 1.3 Definitions The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [RFC2119]. 2. Assigned values This section lists the values used in IKEv2 for many security algorithms and functions. These values will be embodied in appropriate registries at IANA. It is expected that the IANA registries might expand over time to include values not listed in this document. Implementers of IKEv2 SHOULD NOT rely on the values in this document, but should instead rely on the values found at IANA. The algorithms in this section are for IKEv2 transforms, described in section 3.3.2 of [IKEv2]. 2.1 Transform type 1: encryption algorithms Name Number Defined in RESERVED 0 ENCR_DES_IV64 1 RFC 1827 ENCR_DES 2 RFC 2405 ENCR_3DES 3 RFC 2451 ENCR_RC5 4 RFC 2451 ENCR_IDEA 5 RFC 2451 ENCR_CAST 6 RFC 2451 ENCR_BLOWFISH 7 RFC 2451 ENCR_3IDEA 8 RFC 2451 ENCR_NULL 9 RFC 2410 ENCR_AES_128_CBC 10 draft-ietf-ipsec-ciph-aes-cbc ENCR_AES_128_CTR 11 draft-ietf-ipsec-ciph-aes-ctr Values 241-255 are for private use among mutually-consenting parties. For IKEv2, ENCR_3DES (3) MUST be implemented and ENCR_AES_128_CBC (12) SHOULD be implemented. It is expected that in the not-distant future, ENCR_AES_128_CBC (12) will become a MUST-level requirement and that ENCR_3DES (3) will become a SHOULD-level requirement. 2.2 Transform type 2: pseudo-random functions Name Number Defined In RESERVED 0 PRF_HMAC_MD5 1 RFC 2104 PRF_HMAC_SHA1 2 RFC 2104 PRF_HMAC_TIGER 3 RFC 2104 PRF_AES128_CBC 4 draft-ietf-ipsec-ciph-aes-cbc Values 241-255 are for private use among mutually-consenting parties. For IKEv2, PRF_HMAC_SHA1 (2) MUST be implemented and PRF_AES128_CBC (4) SHOULD be implemented. 2.3 Transform type 3: integrity algorithm Name Number Defined In NONE 0 AUTH_HMAC_MD5_96 1 RFC 2403 AUTH_HMAC_SHA1_96 2 RFC 2404 AUTH_KPDK_MD5 3 RFC 1826 AUTH_AES_XCBC_96 4 draft-ietf-ipsec-ciph-aes-xcbc-mac Values 241-255 are for private use among mutually-consenting parties. For IKEv2, AUTH_HMAC_SHA1_96 (2) MUST be implemented and AUTH_AES_XCBC_96 (5) SHOULD be implemented. 2.4 Transform type 4: Diffie-Hellman group Name Number NONE 0 Defined in Appendix A 1 - 5 Defined in [RFC3526] 14 - 18 MODP (exponentiation) 201 (w/attributes) ECP (elliptic curve over GF[P] 202 (w/attributes) EC2N (elliptic curve over GF[2^N]) 203 (w/attributes) Values 1-5 are defined in Appendix A. Values 14 - 18 are defined in [RFC3526]. Values 6-13 and 19-200 are reserved to IANA for new MODP, ECP or EC2N groups. Values 204-255 are for private use among mutually-consenting parties. Specification of values 201, 202 or 203 allow peers to define a new Diffie-Hellman group in-line as part of the exchange. Private use of Values 204-255 are for private use among mutually-consenting parties and MAY entail complete definition of a group, or may require attributes to accompany them. For IKEv2, implementations MUST support 1024-bit MODP (2) and SHOULD support 2048-bit MODP (14). It is expected that in the not-distant future, 2048-bit MODP (14) will become a MUST-level requirement and that 1024-bit MODP (2) will become a SHOULD-level requirement. All implementations of IKEv2 SHOULD include a management facility that allows specification (by a user or system administrator) of Diffie- Hellman parameters (the generator, modulus, and exponent lengths and values) for new DH groups. Implementations SHOULD provide a management interface through which a user or system administrator can enter these parameters and the associated transform IDs to enable negotiating such groups. 3 UI suites This section lists optional, non-mandatory suites that be presented to system administrators to ease the burden of choosing among the many options in IKEv2. These suites cannot cover all of the options that an administrator needs to select. Instead, they give values for a subset of the options. Note that these UI suites are simply collections of values for some options in IKEv2. Use of UI suites does not change the IKEv2 protocol in any way. Specifically, the transform substructure in IKEv2 must be used to give the value for each specified option regardless of whether or not UI suites are used. Implementations that use UI suites SHOULD also provide a management interface for specifying values for individual cryptographic options. That is, it is unlikely that UI suites are a complete solution for matching the security policies of many IKEv2 users, and therefore an interface that gives a more complete set of options should be used as well. IKEv2 implementations that use these UI suites SHOULD use the suite names listed here. IKEv2 implementations SHOULD NOT use names different than those listed here for suites that are described, and SHOULD NOT use the names listed here for suites that do not match these values. Note that the suites listed here are for use of IPsec in virtual private networks. Other uses of IKEv2 and IPsec will probably want to define their own suites and give them different names. Additional suites can be defined by standards-track RFCs. UI suites are not expected to be registered by IANA. 3.1 Suite "VPN-A" This suite matches the commonly-used corporate VPN security used in IKEv1 at the time this document is being written. Option Value IKEv2 transform 1 ENCR_3DES (3) IKEv2 transform 2 PRF_HMAC_SHA1 (2) IKEv2 transform 3 AUTH_HMAC_SHA1_96 (2) IKEv2 transform 4 1024-bit MODP (2) IPsec protocol ESP without extended sequence numbers ESP encryption ENCR_3DES (3) ESP integrity AUTH_HMAC_SHA1_96 (2) Rekeying with the CREATE_CHILD_SA exchange can occur at any time based on the wish of either party. The initiator of this exchange MAY include a new Diffie-Hellman key; if it is included, it MUST be of type 1024-bit MODP (2). If the initiator of the exchange includes a Diffie-Hellman key, the responder MUST include a Diffie-Hellman key, and it MUST of type 1024-bit MODP (2). This means that perfect forward secrecy is optional for the CREATE_CHILD_SA exchange, but it has to be supported in the suite. 3.2 Suite "VPN-B" This suite is what many people expect the commonly-used corporate VPN security that will be used within a few years of the time this document is being written. Option Value IKEv2 transform 1 ENCR_AES_128_CBC (10) IKEv2 transform 2 PRF_AES128_CBC (4) IKEv2 transform 3 AUTH_AES_XCBC_96 (4) IKEv2 transform 4 2048-bit MODP (14) IPsec protocol ESP with extended sequence numbers ESP encryption ENCR_AES_128_CBC (10) ESP integrity AUTH_AES_XCBC_96 (4) Rekeying with the CREATE_CHILD_SA exchange can occur at any time based on the wish of either party. The initiator of this exchange MAY include a new Diffie-Hellman key; if it is included, it MUST be of type 2048-bit MODP (14). If the initiator of the exchange includes a Diffie-Hellman key, the responder MUST include a Diffie-Hellman key, and it MUST of type 2048-bit MODP (14). This means that perfect forward secrecy is optional for the CREATE_CHILD_SA exchange, but it has to be supported in the suite. 4. Acknowledgements Much of the text and ideas in this document came from earlier versions of the IKEv2 document edited by Charlie Kaufman. Other text and ideas were contributed by other members of the IPsec Working Group. 5. Security considerations This document inherits all of the security considerations of the IKEv2 document. Some of the security options defined in this document may be found in the future to have properties significantly weaker than those that were believed at the time this document was produced. 6. IANA considerations The values in section 2 of this document need to be registered by IANA in new registries created for IKEv2. Specifically, the new registries are: Transform type 1: encryption algorithms (section 2.1) Transform type 2: pseudo-random functions (section 2.2) Transform type 3: integrity algorithm (section 2.3) Transform type 4: Diffie-Hellman group (section 2.4) 7. References 7.1 Normative references [IKEv2] "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-nn.txt, work in progress. [RFC3526] "More MODP Diffie-Hellman groups for IKE", RFC 3526. [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. [RFC2409] "The Internet Key Exchange (IKE)", RFC 2409. 7.2 Non-normative references [RFC2401] "Security Architecture for the Internet Protocol", RFC 2401. [RFC2412] Orman, H., "The Oakley Key Determination Protocol", RFC 2412, November 1998. 8. Author's address Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 USA paul.hoffman@vpnc.org A. Diffie-Hellman Groups This appendix defines five Diffie-Hellman groups for use in IKEv2. These groups were generated by Richard Schroeppel at the University of Arizona. The properties of these primes are described in [RFC2412]. Note that additional Diffie-Hellman groups have been defined in [RFC3526]. A.1 Group ID 1 - 768 Bit MODP The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } Its hexadecimal value is: FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF The generator is 2. A.2 Group ID 2 - 1024 Bit MODP The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. Its hexadecimal value is: FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 FFFFFFFF FFFFFFFF The generator is 2. A.3 Group ID 3 - 155 Bit EC2N The curve is based on the Galois Field GF[2^155]. The field size is 155. The irreducible polynomial for the field is: u^155 + u^62 + 1. The equation for the elliptic curve is: y^2 + xy = x^3 + ax^2 + b. Field Size: 155 Group Prime/Irreducible Polynomial: 0x0800000000000000000000004000000000000001 Group Generator One: 0x7b Group Curve A: 0x0 Group Curve B: 0x07338f Group Order: 0x0800000000000000000057db5698537193aef944 The data in the KE payload when using this group is the value x from the solution (x,y), the point on the curve chosen by taking the randomly chosen secret Ka and computing Ka*P, where * is the repetition of the group addition and double operations, P is the curve point with x coordinate equal to generator 1 and the y coordinate determined from the defining equation. The equation of curve is implicitly known by the Group Type and the A and B coefficients. There are two possible values for the y coordinate; either one can be used successfully (the two parties need not agree on the selection). A.4 Group ID 4 - 185 Bit EC2N The curve is based on the Galois Field GF[2^185]. The field size is 185. The irreducible polynomial for the field is: u^185 + u^69 + 1. The equation for the elliptic curve is: y^2 + xy = x^3 + ax^2 + b. Field Size: 185 Group Prime/Irreducible Polynomial: 0x020000000000000000000000000000200000000000000001 Group Generator One: 0x18 Group Curve A: 0x0 Group Curve B: 0x1ee9 Group Order: 0x01ffffffffffffffffffffffdbf2f889b73e484175f94ebc The data in the KE payload when using this group will be identical to that as when using Group 3 described in Appendix A.3. B.5 Group ID 5 - 1536 Bit MODP The prime is 2^1536 - 2^1472 - 1 + 2^64 * {[2^1406 pi] + 741804}. Its hexadecimal value is FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF The generator is 2. B. Changes from draft-hoffman-ipsec-algorithms-01.txt 2: Fixed typo in the first sentence. 2.4: Fixed the second sentence to correctly list what is reserved to IANA. 3: Fixed typo in first paragraph. 6: Updated to give more specific instructions to IANA. 7: Updated the reference for [MODP] to [RFC3526]. A: Added this appendix based on text from [IKEv2].