Network Working Group Y. Nir Internet-Draft Check Point Intended status: Standards Track T. Kivinen Expires: May 12, 2016 INSIDE Secure P. Wouters Red Hat D. Migault Ericsson November 9, 2015 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) draft-ietf-ipsecme-rfc4307bis-01 Abstract The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange protocol provides a mechanism to negotiate which algorithms should be used in any given association. However, to ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on May 12, 2016. Nir, et al. Expires May 12, 2016 [Page 1] Internet-Draft IKEv2 Cryptographic Algorithms November 2015 Copyright Notice Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 3 3.1. IKEv2 Transform Type 1 Algorithms . . . . . . . . . . . . 3 3.2. IKEv2 Transform Type 3 Algorithms . . . . . . . . . . . . 4 3.3. IKEv2 Transform Type 2 Algorithms . . . . . . . . . . . . 5 3.4. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The Internet Key Exchange protocol [RFC7296] provides for the negotiation of cryptographic algorithms between both endpoints of a cryptographic association. Different implementations of IPsec and IKE may provide different algorithms. However, the IETF desires that all implementations should have some way to interoperate. In particular, this requires that IKE define a set of mandatory-to- implement algorithms because IKE itself uses such algorithms as part of its own negotiations. This requires that some set of algorithms be specified as "mandatory-to-implement" for IKE. The nature of cryptography is that new algorithms surface continuously and existing algorithms are continuously attacked. An algorithm believed to be strong today may be demonstrated to be weak tomorrow. Given this, the choice of mandatory-to-implement algorithm Nir, et al. Expires May 12, 2016 [Page 2] Internet-Draft IKEv2 Cryptographic Algorithms November 2015 should be conservative so as to minimize the likelihood of it being compromised quickly. Thought should also be given to performance considerations as many uses of IPsec will be in environments where performance is a concern. Finally, we need to recognize that the mandatory-to-implement algorithm(s) may need to change over time to adapt to the changing world. For this reason, the selection of mandatory-to-implement algorithms was removed from the main IKEv2 specification and placed in this document. As the choice of algorithm changes, only this document should need to be updated. Ideally, the mandatory-to-implement algorithm of tomorrow should already be available in most implementations of IPsec by the time it is made mandatory. To facilitate this, we will attempt to identify those algorithms (that are known today) in this document. There is no guarantee that the algorithms we believe today may be mandatory in the future will in fact become so. All algorithms known today are subject to cryptographic attack and may be broken in the future. 2. Conventions Used in This Document 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 [RFC2119]. We define some additional terms here: SHOULD+ This term means the same as SHOULD. However, it is likely that an algorithm marked as SHOULD+ will be promoted at some future time to be a MUST. SHOULD- This term means the same as SHOULD. However, an algorithm marked as SHOULD- may be deprecated to a MAY in a future version of this document. MUST- This term means the same as MUST. However, we expect at some point that this algorithm will no longer be a MUST in a future document. Although its status will be determined at a later time, it is reasonable to expect that if a future revision of a document alters the status of a MUST- algorithm, it will remain at least a SHOULD or a SHOULD-. 3. Algorithm Selection 3.1. IKEv2 Transform Type 1 Algorithms The algorithms in the below table are negotiated in the SA payload and used in the ENCR payload. References to the specifications defining these algorithms and the ones in the following subsections Nir, et al. Expires May 12, 2016 [Page 3] Internet-Draft IKEv2 Cryptographic Algorithms November 2015 are in the IANA registry [IKEV2-IANA]. Some of these algorithms are Authenticated Encryption with Associated Data (AEAD - [RFC5282]). Algorithms that are not AEAD MUST be used in conjunction with the integrity algorithms in Section 3.2. +-----------------------------+----------+-------+---------+ | Name | Status | AEAD? | Comment | +-----------------------------+----------+-------+---------+ | ENCR_AES_CBC | MUST | No | [1] | | ENCR_CHACHA20_POLY1305 | SHOULD | Yes | | | AES-GCM with a 16 octet ICV | SHOULD | Yes | [1] | | ENCR_AES_CCM_8 | SHOULD | Yes | [1] | | ENCR_3DES | MAY | No | | | ENCR_DES | MUST NOT | No | | +-----------------------------+----------+-------+---------+ [1] - This requirement level is for 128-bit keys. 256-bit keys are at MAY. 192-bit keys can safely be ignored. Explanation about AES-CBC is TBD. Explanation about ChaCha20 is TBD. Explanation about AES-GCM is TBD. Explanation about AES-CCM is TBD. Explanation about 3DES is TBD. Explanation about DES is TBD. 3.2. IKEv2 Transform Type 3 Algorithms The algorithms in the below table are negotiated in the SA payload and used in the ENCR payload. References to the specifications defining these algorithms are in the IANA registry. When an AEAD algorithm (see Section 3.1) is used, no algorithm from this table needs to be used. +------------------------+---------+ | Name | Status | +------------------------+---------+ | AUTH_HMAC_SHA2_256_128 | MUST | | AUTH_HMAC_SHA2_512_256 | SHOULD+ | | AUTH_HMAC_SHA1_96 | MUST- | | AUTH_AES_XCBC_96 | MAY | +------------------------+---------+ Nir, et al. Expires May 12, 2016 [Page 4] Internet-Draft IKEv2 Cryptographic Algorithms November 2015 Explanation about SHA-256 is TBD. Explanation about SHA-512 is TBD. Explanation about SHA-1 is TBD. Explanation about AES-XCBC is TBD. 3.3. IKEv2 Transform Type 2 Algorithms Transform Type 2 Algorithms are pseudo-random functions used to generate random values when needed. +-------------------+---------+ | Name | Status | +-------------------+---------+ | PRF_HMAC_SHA2_256 | MUST | | PRF_HMAC_SHA2_512 | SHOULD+ | | PRF_HMAC_SHA1 | MUST- | | PRF_AES128_CBC | MAY | +-------------------+---------+ Explanation about SHA-256 is TBD. Explanation about SHA-512 is TBD. Explanation about SHA-1 is TBD. Explanation about AES-XCBC is TBD. 3.4. Diffie-Hellman Groups There are several Modular Exponential (MODP) groups and several Elliptic Curve groups (ECC) that are defined for use in IKEv2. They are defined in both the [IKEv2] base document and in extensions documents. They are identified by group number. +--------+--------------------------+------------+ | Number | Description | Status | +--------+--------------------------+------------+ | 14 | 2048-bit MODP Group | MUST | | 19 | 256-bit random ECP group | SHOULD | | 2 | 1024-bit MODP Group | SHOULD NOT | | 1 | 768-bit MODP Group | MUST NOT | +--------+--------------------------+------------+ Explanation about Group 14 is TBD. Nir, et al. Expires May 12, 2016 [Page 5] Internet-Draft IKEv2 Cryptographic Algorithms November 2015 Explanation about Group 19 is TBD. Explanation about Group 2 is TBD. Explanation about Group 1 is TBD. 4. Security Considerations The security of cryptographic-based systems depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system. This document concerns itself with the selection of cryptographic algorithms for the use of IKEv2, specifically with the selection of "mandatory-to-implement" algorithms. The algorithms identified in this document as "MUST implement" or "SHOULD implement" are not known to be broken at the current time, and cryptographic research so far leads us to believe that they will likely remain secure into the foreseeable future. However, this isn't necessarily forever. We would therefore expect that new revisions of this document will be issued from time to time that reflect the current best practice in this area. 5. IANA Considerations This document makes no requests of IANA. 6. Acknowledgements The first version of this document was RFC 4307 by Jeffrey I. Schiller of the Massachusetts Institute of Technology (MIT). Much of the original text has been copied verbatim. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Nir, et al. Expires May 12, 2016 [Page 6] Internet-Draft IKEv2 Cryptographic Algorithms November 2015 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", RFC 5282, DOI 10.17487/RFC5282, August 2008, . 7.2. Informative References [IKEV2-IANA] "Internet Key Exchange Version 2 (IKEv2) Parameters", . Authors' Addresses Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim st. Tel Aviv 6789735 Israel EMail: ynir.ietf@gmail.com Tero Kivinen INSIDE Secure Eerikinkatu 28 HELSINKI FI-00180 FI EMail: kivinen@iki.fi Paul Wouters Red Hat EMail: pwouters@redhat.com Nir, et al. Expires May 12, 2016 [Page 7] Internet-Draft IKEv2 Cryptographic Algorithms November 2015 Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada Phone: +1 514-452-2160 EMail: daniel.migault@ericsson.com Nir, et al. Expires May 12, 2016 [Page 8]