idnits 2.17.00 (12 Aug 2021) /tmp/idnits23376/draft-ietf-ipsecme-rfc4307bis-01.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 (November 9, 2015) is 2385 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) -- Looks like a reference, but probably isn't: '1' on line 159 == Missing Reference: 'IKEv2' is mentioned on line 225, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: May 12, 2016 INSIDE Secure 6 P. Wouters 7 Red Hat 8 D. Migault 9 Ericsson 10 November 9, 2015 12 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 13 (IKEv2) 14 draft-ietf-ipsecme-rfc4307bis-01 16 Abstract 18 The IPsec series of protocols makes use of various cryptographic 19 algorithms in order to provide security services. The Internet Key 20 Exchange protocol provides a mechanism to negotiate which algorithms 21 should be used in any given association. However, to ensure 22 interoperability between disparate implementations, it is necessary 23 to specify a set of mandatory-to-implement algorithms to ensure that 24 there is at least one algorithm that all implementations will have 25 available. This document defines the current set of algorithms that 26 are mandatory to implement as part of IKEv2, as well as algorithms 27 that should be implemented because they may be promoted to mandatory 28 at some future time. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 12, 2016. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 66 3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. IKEv2 Transform Type 1 Algorithms . . . . . . . . . . . . 3 68 3.2. IKEv2 Transform Type 3 Algorithms . . . . . . . . . . . . 4 69 3.3. IKEv2 Transform Type 2 Algorithms . . . . . . . . . . . . 5 70 3.4. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 5 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 7.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 The Internet Key Exchange protocol [RFC7296] provides for the 82 negotiation of cryptographic algorithms between both endpoints of a 83 cryptographic association. Different implementations of IPsec and 84 IKE may provide different algorithms. However, the IETF desires that 85 all implementations should have some way to interoperate. In 86 particular, this requires that IKE define a set of mandatory-to- 87 implement algorithms because IKE itself uses such algorithms as part 88 of its own negotiations. This requires that some set of algorithms 89 be specified as "mandatory-to-implement" for IKE. 91 The nature of cryptography is that new algorithms surface 92 continuously and existing algorithms are continuously attacked. An 93 algorithm believed to be strong today may be demonstrated to be weak 94 tomorrow. Given this, the choice of mandatory-to-implement algorithm 95 should be conservative so as to minimize the likelihood of it being 96 compromised quickly. Thought should also be given to performance 97 considerations as many uses of IPsec will be in environments where 98 performance is a concern. 100 Finally, we need to recognize that the mandatory-to-implement 101 algorithm(s) may need to change over time to adapt to the changing 102 world. For this reason, the selection of mandatory-to-implement 103 algorithms was removed from the main IKEv2 specification and placed 104 in this document. As the choice of algorithm changes, only this 105 document should need to be updated. 107 Ideally, the mandatory-to-implement algorithm of tomorrow should 108 already be available in most implementations of IPsec by the time it 109 is made mandatory. To facilitate this, we will attempt to identify 110 those algorithms (that are known today) in this document. There is 111 no guarantee that the algorithms we believe today may be mandatory in 112 the future will in fact become so. All algorithms known today are 113 subject to cryptographic attack and may be broken in the future. 115 2. Conventions Used in This Document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 We define some additional terms here: 123 SHOULD+ This term means the same as SHOULD. However, it is likely 124 that an algorithm marked as SHOULD+ will be promoted at 125 some future time to be a MUST. 126 SHOULD- This term means the same as SHOULD. However, an algorithm 127 marked as SHOULD- may be deprecated to a MAY in a future 128 version of this document. 129 MUST- This term means the same as MUST. However, we expect at 130 some point that this algorithm will no longer be a MUST in 131 a future document. Although its status will be determined 132 at a later time, it is reasonable to expect that if a 133 future revision of a document alters the status of a MUST- 134 algorithm, it will remain at least a SHOULD or a SHOULD-. 136 3. Algorithm Selection 138 3.1. IKEv2 Transform Type 1 Algorithms 140 The algorithms in the below table are negotiated in the SA payload 141 and used in the ENCR payload. References to the specifications 142 defining these algorithms and the ones in the following subsections 143 are in the IANA registry [IKEV2-IANA]. Some of these algorithms are 144 Authenticated Encryption with Associated Data (AEAD - [RFC5282]). 145 Algorithms that are not AEAD MUST be used in conjunction with the 146 integrity algorithms in Section 3.2. 148 +-----------------------------+----------+-------+---------+ 149 | Name | Status | AEAD? | Comment | 150 +-----------------------------+----------+-------+---------+ 151 | ENCR_AES_CBC | MUST | No | [1] | 152 | ENCR_CHACHA20_POLY1305 | SHOULD | Yes | | 153 | AES-GCM with a 16 octet ICV | SHOULD | Yes | [1] | 154 | ENCR_AES_CCM_8 | SHOULD | Yes | [1] | 155 | ENCR_3DES | MAY | No | | 156 | ENCR_DES | MUST NOT | No | | 157 +-----------------------------+----------+-------+---------+ 159 [1] - This requirement level is for 128-bit keys. 256-bit keys are at 160 MAY. 192-bit keys can safely be ignored. 162 Explanation about AES-CBC is TBD. 164 Explanation about ChaCha20 is TBD. 166 Explanation about AES-GCM is TBD. 168 Explanation about AES-CCM is TBD. 170 Explanation about 3DES is TBD. 172 Explanation about DES is TBD. 174 3.2. IKEv2 Transform Type 3 Algorithms 176 The algorithms in the below table are negotiated in the SA payload 177 and used in the ENCR payload. References to the specifications 178 defining these algorithms are in the IANA registry. When an AEAD 179 algorithm (see Section 3.1) is used, no algorithm from this table 180 needs to be used. 182 +------------------------+---------+ 183 | Name | Status | 184 +------------------------+---------+ 185 | AUTH_HMAC_SHA2_256_128 | MUST | 186 | AUTH_HMAC_SHA2_512_256 | SHOULD+ | 187 | AUTH_HMAC_SHA1_96 | MUST- | 188 | AUTH_AES_XCBC_96 | MAY | 189 +------------------------+---------+ 191 Explanation about SHA-256 is TBD. 193 Explanation about SHA-512 is TBD. 195 Explanation about SHA-1 is TBD. 197 Explanation about AES-XCBC is TBD. 199 3.3. IKEv2 Transform Type 2 Algorithms 201 Transform Type 2 Algorithms are pseudo-random functions used to 202 generate random values when needed. 204 +-------------------+---------+ 205 | Name | Status | 206 +-------------------+---------+ 207 | PRF_HMAC_SHA2_256 | MUST | 208 | PRF_HMAC_SHA2_512 | SHOULD+ | 209 | PRF_HMAC_SHA1 | MUST- | 210 | PRF_AES128_CBC | MAY | 211 +-------------------+---------+ 213 Explanation about SHA-256 is TBD. 215 Explanation about SHA-512 is TBD. 217 Explanation about SHA-1 is TBD. 219 Explanation about AES-XCBC is TBD. 221 3.4. Diffie-Hellman Groups 223 There are several Modular Exponential (MODP) groups and several 224 Elliptic Curve groups (ECC) that are defined for use in IKEv2. They 225 are defined in both the [IKEv2] base document and in extensions 226 documents. They are identified by group number. 228 +--------+--------------------------+------------+ 229 | Number | Description | Status | 230 +--------+--------------------------+------------+ 231 | 14 | 2048-bit MODP Group | MUST | 232 | 19 | 256-bit random ECP group | SHOULD | 233 | 2 | 1024-bit MODP Group | SHOULD NOT | 234 | 1 | 768-bit MODP Group | MUST NOT | 235 +--------+--------------------------+------------+ 237 Explanation about Group 14 is TBD. 239 Explanation about Group 19 is TBD. 241 Explanation about Group 2 is TBD. 243 Explanation about Group 1 is TBD. 245 4. Security Considerations 247 The security of cryptographic-based systems depends on both the 248 strength of the cryptographic algorithms chosen and the strength of 249 the keys used with those algorithms. The security also depends on 250 the engineering of the protocol used by the system to ensure that 251 there are no non-cryptographic ways to bypass the security of the 252 overall system. 254 This document concerns itself with the selection of cryptographic 255 algorithms for the use of IKEv2, specifically with the selection of 256 "mandatory-to-implement" algorithms. The algorithms identified in 257 this document as "MUST implement" or "SHOULD implement" are not known 258 to be broken at the current time, and cryptographic research so far 259 leads us to believe that they will likely remain secure into the 260 foreseeable future. However, this isn't necessarily forever. We 261 would therefore expect that new revisions of this document will be 262 issued from time to time that reflect the current best practice in 263 this area. 265 5. IANA Considerations 267 This document makes no requests of IANA. 269 6. Acknowledgements 271 The first version of this document was RFC 4307 by Jeffrey I. 272 Schiller of the Massachusetts Institute of Technology (MIT). Much of 273 the original text has been copied verbatim. 275 7. References 277 7.1. Normative References 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, 281 DOI 10.17487/RFC2119, March 1997, 282 . 284 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 285 Kivinen, "Internet Key Exchange Protocol Version 2 286 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 287 2014, . 289 [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption 290 Algorithms with the Encrypted Payload of the Internet Key 291 Exchange version 2 (IKEv2) Protocol", RFC 5282, 292 DOI 10.17487/RFC5282, August 2008, 293 . 295 7.2. Informative References 297 [IKEV2-IANA] 298 "Internet Key Exchange Version 2 (IKEv2) Parameters", 299 . 301 Authors' Addresses 303 Yoav Nir 304 Check Point Software Technologies Ltd. 305 5 Hasolelim st. 306 Tel Aviv 6789735 307 Israel 309 EMail: ynir.ietf@gmail.com 311 Tero Kivinen 312 INSIDE Secure 313 Eerikinkatu 28 314 HELSINKI FI-00180 315 FI 317 EMail: kivinen@iki.fi 319 Paul Wouters 320 Red Hat 322 EMail: pwouters@redhat.com 323 Daniel Migault 324 Ericsson 325 8400 boulevard Decarie 326 Montreal, QC H4P 2N2 327 Canada 329 Phone: +1 514-452-2160 330 EMail: daniel.migault@ericsson.com