Internet Draft Paul Hoffman draft-hoffman-ipsec-algorithms-00.txt VPN Consortium April 25, 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 may 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_DES_IV32 9 ENCR_RC4 10 ENCR_NULL 11 RFC 2410 ENCR_AES_128_CBC 12 ENCR_AES_128_CTR 13 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_AES_128_CBC (12) 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 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_DES_MAC 3 AUTH_KPDK_MD5 4 RFC 1826 AUTH_AES_XCBC_96 5 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 [IKEv2] 1 - 5 Defined in [MODP] 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 [IKEv2]. Values 14 - 18 are defined in [MODP]. Values 6-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, the 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) 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 (12) IKEv2 transform 2 PRF_AES128_CBC (4) IKEv2 transform 3 AUTH_AES_XCBC_96 (5) IKEv2 transform 4 2048-bit MODP (14) IPsec protocol ESP with extended sequence numbers ESP encryption ENCR_AES_128_CBC (12) ESP integrity AUTH_AES_XCBC_96 (5) 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. 7. References 7.1 Normative references [IKEv2] "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-nn.txt, work in progress. [MODP] "More MODP Diffie-Hellman groups for IKE", draft-ietf-ipsec-ike-modp-groups-nn.txt, work in progress. [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. 8. Author's address Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 USA paul.hoffman@vpnc.org