idnits 2.17.1 draft-nir-ipsecme-rfc4307bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 9, 2015) is 3115 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IKEv2' is mentioned on line 189, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Nir 3 Internet-Draft Check Point 4 Intended status: Standards Track T. Kivinen 5 Expires: April 11, 2016 INSIDE Secure 6 October 9, 2015 8 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 9 (IKEv2) 10 draft-nir-ipsecme-rfc4307bis-00 12 Abstract 14 The IPsec series of protocols makes use of various cryptographic 15 algorithms in order to provide security services. The Internet Key 16 Exchange protocol provides a mechanism to negotiate which algorithms 17 should be used in any given association. However, to ensure 18 interoperability between disparate implementations, it is necessary 19 to specify a set of mandatory-to-implement algorithms to ensure that 20 there is at least one algorithm that all implementations will have 21 available. This document defines the current set of algorithms that 22 are mandatory to implement as part of IKEv2, as well as algorithms 23 that should be implemented because they may be promoted to mandatory 24 at some future time. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 11, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 62 3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. IKEv2 Transform Type 1 Algorithms . . . . . . . . . . . . 3 64 3.2. IKEv2 Transform Type 3 Algorithms . . . . . . . . . . . . 4 65 3.3. IKEv2 Transform Type 2 Algorithms . . . . . . . . . . . . 4 66 3.4. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 4 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 72 7.2. Informative References . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 The Internet Key Exchange protocol [RFC7296] provides for the 77 negotiation of cryptographic algorithms between both endpoints of a 78 cryptographic association. Different implementations of IPsec and 79 IKE may provide different algorithms. However, the IETF desires that 80 all implementations should have some way to interoperate. In 81 particular, this requires that IKE define a set of mandatory-to- 82 implement algorithms because IKE itself uses such algorithms as part 83 of its own negotiations. This requires that some set of algorithms 84 be specified as "mandatory-to-implement" for IKE. 86 The nature of cryptography is that new algorithms surface 87 continuously and existing algorithms are continuously attacked. An 88 algorithm believed to be strong today may be demonstrated to be weak 89 tomorrow. Given this, the choice of mandatory-to-implement algorithm 90 should be conservative so as to minimize the likelihood of it being 91 compromised quickly. Thought should also be given to performance 92 considerations as many uses of IPsec will be in environments where 93 performance is a concern. 95 Finally, we need to recognize that the mandatory-to-implement 96 algorithm(s) may need to change over time to adapt to the changing 97 world. For this reason, the selection of mandatory-to-implement 98 algorithms was removed from the main IKEv2 specification and placed 99 in this document. As the choice of algorithm changes, only this 100 document should need to be updated. 102 Ideally, the mandatory-to-implement algorithm of tomorrow should 103 already be available in most implementations of IPsec by the time it 104 is made mandatory. To facilitate this, we will attempt to identify 105 those algorithms (that are known today) in this document. There is 106 no guarantee that the algorithms we believe today may be mandatory in 107 the future will in fact become so. All algorithms known today are 108 subject to cryptographic attack and may be broken in the future. 110 2. Conventions Used in This Document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 We define some additional terms here: 118 SHOULD+ This term means the same as SHOULD. However, it is likely 119 that an algorithm marked as SHOULD+ will be promoted at 120 some future time to be a MUST. 121 SHOULD- This term means the same as SHOULD. However, an algorithm 122 marked as SHOULD- may be deprecated to a MAY in a future 123 version of this document. 124 MUST- This term means the same as MUST. However, we expect at 125 some point that this algorithm will no longer be a MUST in 126 a future document. Although its status will be determined 127 at a later time, it is reasonable to expect that if a 128 future revision of a document alters the status of a MUST- 129 algorithm, it will remain at least a SHOULD or a SHOULD-. 131 3. Algorithm Selection 133 3.1. IKEv2 Transform Type 1 Algorithms 135 The algorithms in the below table are negotiated in the SA payload 136 and used in the ENCR payload. References to the specifications 137 defining these algorithms and the ones in the following subsections 138 are in the IANA registry [IKEV2-IANA]. Some of these algorithms are 139 Authenticated Encryption with Associated Data (AEAD - [RFC5282]). 140 Algorithms that are not AEAD MUST be used in conjunction with the 141 integrity algorithms in Section 3.2. 143 +----------------------------+----------+-------+ 144 | Name | Status | AEAD? | 145 +----------------------------+----------+-------+ 146 | ENCR_AES_CBC | MUST | No | 147 | ENCR_CHACHA20_POLY1305 | SHOULD | Yes | 148 | AES-GCM with a 8 octet ICV | SHOULD | Yes | 149 | ENCR_AES_CCM_8 | SHOULD | Yes | 150 | ENCR_3DES | MAY | No | 151 | ENCR_DES | MUST NOT | No | 152 +----------------------------+----------+-------+ 154 3.2. IKEv2 Transform Type 3 Algorithms 156 The algorithms in the below table are negotiated in the SA payload 157 and used in the ENCR payload. References to the specifications 158 defining these algorithms are in the IANA registry. When an AEAD 159 algorithm (see Section 3.1) is used, no algorithm from this table 160 needs to be used. 162 +------------------------+--------+ 163 | Name | Status | 164 +------------------------+--------+ 165 | AUTH_HMAC_SHA2_256_128 | MUST | 166 | AUTH_HMAC_SHA1_96 | MUST- | 167 | AUTH_AES_XCBC_96 | MAY | 168 | AUTH_HMAC_MD5_96 | MAY | 169 +------------------------+--------+ 171 3.3. IKEv2 Transform Type 2 Algorithms 173 Transform Type 2 Algorithms are pseudo-random functions used to 174 generate random values when needed. 176 +-------------------+--------+ 177 | Name | Status | 178 +-------------------+--------+ 179 | PRF_HMAC_SHA2_256 | MUST | 180 | PRF_HMAC_SHA1 | MUST- | 181 | PRF_AES128_CBC | MAY | 182 | PRF_HMAC_MD5 | MAY | 183 +-------------------+--------+ 185 3.4. Diffie-Hellman Groups 187 There are several Modular Exponential (MODP) groups and several 188 Elliptic Curve groups (ECC) that are defined for use in IKEv2. They 189 are defined in both the [IKEv2] base document and in extensions 190 documents. They are identified by group number. 192 +--------+--------------------------+------------+ 193 | Number | Description | Status | 194 +--------+--------------------------+------------+ 195 | 14 | 2048-bit MODP Group | MUST | 196 | 19 | 256-bit random ECP group | SHOULD | 197 | 20 | 384-bit random ECP group | MAY | 198 | 2 | 1024-bit MODP Group | SHOULD NOT | 199 +--------+--------------------------+------------+ 201 4. Security Considerations 203 The security of cryptographic-based systems depends on both the 204 strength of the cryptographic algorithms chosen and the strength of 205 the keys used with those algorithms. The security also depends on 206 the engineering of the protocol used by the system to ensure that 207 there are no non-cryptographic ways to bypass the security of the 208 overall system. 210 This document concerns itself with the selection of cryptographic 211 algorithms for the use of IKEv2, specifically with the selection of 212 "mandatory-to-implement" algorithms. The algorithms identified in 213 this document as "MUST implement" or "SHOULD implement" are not known 214 to be broken at the current time, and cryptographic research so far 215 leads us to believe that they will likely remain secure into the 216 foreseeable future. However, this isn't necessarily forever. We 217 would therefore expect that new revisions of this document will be 218 issued from time to time that reflect the current best practice in 219 this area. 221 5. IANA Considerations 223 This document makes no requests of IANA. 225 6. Acknowledgements 227 The first version of this document was RFC 4307 by Jeffrey I. 228 Schiller of the Massachusetts Institute of Technology (MIT). Much of 229 the text has been copied verbatim. 231 7. References 233 7.1. Normative References 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, March 1997. 238 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 239 Kivinen, "Internet Key Exchange Protocol Version 2 240 (IKEv2)", STD 79, RFC 7296, October 2014. 242 [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption 243 Algorithms with the Encrypted Payload of the Internet Key 244 Exchange version 2 (IKEv2) Protocol", RFC 5282, DOI 245 10.17487/RFC5282, August 2008, 246 . 248 7.2. Informative References 250 [IKEV2-IANA] 251 "Internet Key Exchange Version 2 (IKEv2) Parameters", 252 . 254 Authors' Addresses 256 Yoav Nir 257 Check Point Software Technologies Ltd. 258 5 Hasolelim st. 259 Tel Aviv 6789735 260 Israel 262 EMail: ynir.ietf@gmail.com 264 Tero Kivinen 265 INSIDE Secure 266 Eerikinkatu 28 267 HELSINKI FI-00180 268 FI 270 EMail: kivinen@iki.fi