idnits 2.17.1 draft-ietf-ipsecme-esp-ah-reqts-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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (September 06, 2013) is 3883 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: 'RFC2451' is mentioned on line 203, but not defined == Missing Reference: 'RFC4543' is mentioned on line 202, but not defined == Unused Reference: 'RFC2403' is defined on line 398, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4305 (Obsoleted by RFC 4835) -- Obsolete informational reference (is this intentional?): RFC 4307 (Obsoleted by RFC 8247) -- Obsolete informational reference (is this intentional?): RFC 4835 (Obsoleted by RFC 7321) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. McGrew 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track W. Feghali 5 Expires: March 10, 2014 Intel Corp. 6 P. Hoffman 7 VPN Consortium 8 September 06, 2013 10 Cryptographic Algorithm Implementation Requirements and Usage Guidance 11 for Encapsulating Security Payload (ESP) and Authentication Header (AH) 12 draft-ietf-ipsecme-esp-ah-reqts-01 14 Abstract 16 This Internet Draft is standards track proposal to update to the 17 Cryptographic Algorithm Implementation Requirements for ESP and AH; 18 it also adds usage guidance to help in the selection of these 19 algorithms. 21 The Encapsulating Security Payload (ESP) and Authentication Header 22 (AH) protocols makes use of various cryptographic algorithms to 23 provide confidentiality and/or data origin authentication to 24 protected data communications in the IP Security (IPsec) 25 architecture. To ensure interoperability between disparate 26 implementations, the IPsec standard specifies a set of mandatory-to- 27 implement algorithms. This document specifies the current set of 28 mandatory-to-implement algorithms for ESP and AH, specifies 29 algorithms that should be implemented because they may be promoted to 30 mandatory at some future time, and also recommends against the 31 implementation of some obsolete algorithms. Usage guidance is also 32 provided to help the user of ESP and AH best achieve their security 33 goals through appropriate choices of cryptographic algorithms. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on March 10, 2014. 51 Copyright Notice 53 Copyright (c) 2013 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 70 2. Implementation Requirements . . . . . . . . . . . . . . . . . 4 71 2.1. ESP Authenticated Encryption (Combined Mode Algorithms) . 4 72 2.2. ESP Encryption Algorithms . . . . . . . . . . . . . . . . 4 73 2.3. ESP Authentication Algorithms . . . . . . . . . . . . . . 4 74 2.4. AH Authentication Algorithms . . . . . . . . . . . . . . 5 75 2.5. Summary of Changes . . . . . . . . . . . . . . . . . . . 5 76 3. Usage Guidance . . . . . . . . . . . . . . . . . . . . . . . 5 77 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 4.1. Authenticated Encryption . . . . . . . . . . . . . . . . 6 79 4.2. Encryption Transforms . . . . . . . . . . . . . . . . . . 6 80 4.3. Authentication Transforms . . . . . . . . . . . . . . . . 7 81 5. Algorithm Diversity . . . . . . . . . . . . . . . . . . . . . 7 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 87 9.2. Informative References . . . . . . . . . . . . . . . . . 10 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 90 1. Introduction 92 The Encapsulating Security Payload (ESP) [RFC4303] and the 93 Authentication Header (AH) [RFC4302] are the mechanisms for applying 94 cryptographic protection to data being sent over an IPsec Security 95 Association (SA) [RFC4301]. 97 To ensure interoperability between disparate implementations, it is 98 necessary to specify a set of mandatory-to-implement algorithms. 99 This ensures that there is at least one algorithm that all 100 implementations will have in common. This document specifies the 101 current set of mandatory-to-implement algorithms for ESP and AH, 102 specifies algorithms that should be implemented because they may be 103 promoted to mandatory at some future time, and also recommends 104 against the implementation of some obsolete algorithms. Usage 105 guidance is also provided to help the user of ESP and AH best achieve 106 their security goals through appropriate choices of mechanisms. 108 The nature of cryptography is that new algorithms surface 109 continuously and existing algorithms are continuously attacked. An 110 algorithm believed to be strong today may be demonstrated to be weak 111 tomorrow. Given this, the choice of mandatory-to-implement algorithm 112 should be conservative so as to minimize the likelihood of it being 113 compromised quickly. Thought should also be given to performance 114 considerations as many uses of IPsec will be in environments where 115 performance is a concern. 117 The ESP and AH mandatory-to-implement algorithm(s) may need to change 118 over time to adapt to new developments in cryptography. For this 119 reason, the specification of the mandatory-to-implement algorithms is 120 not included in the main IPsec, ESP, or AH specifications, but is 121 instead placed in this document. Ideally, the mandatory-to-implement 122 algorithm of tomorrow should already be available in most 123 implementations of IPsec by the time it is made mandatory. To 124 facilitate this, this document identifies such algorithms, as they 125 are known today. There is no guarantee that the algorithms that we 126 believe today may be mandatory in the future will in fact become so. 127 All algorithms known today are subject to cryptographic attack and 128 may be broken in the future. 130 1.1. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 Following [RFC4835], we define some additional key words: 138 MUST- This term means the same as MUST. However, we expect that at 139 some point in the future this algorithm will no longer be a MUST. 141 SHOULD+ This term means the same as SHOULD. However, it is likely 142 that an algorithm marked as SHOULD+ will be promoted at some 143 future time to be a MUST. 145 SHOULD- This term means the same as SHOULD. However, it is likely 146 that an algorithm marked as SHOULD- will be deprecated to a MAY or 147 worse in a future version of this document. 149 SHOULD NOT+ This term means the same as SHOULD NOT. However, it is 150 likely that an algorithm marked as SHOULD NOT+ will be deprecated 151 to a MUST NOT in a future version of this document. 153 2. Implementation Requirements 155 This section specifies the cryptographic algorithms that MUST be 156 implemented, and provides guidance about ones that SHOULD or SHOULD 157 NOT be implemented. 159 2.1. ESP Authenticated Encryption (Combined Mode Algorithms) 161 ESP combined mode algorithms provide both confidentiality and 162 authentication services; in cryptographic terms, these are 163 authenticated encryption algorithms [RFC5116]. Authenticated 164 encryption transforms are listed in the ESP encryption transforms 165 IANA registry. 167 Requirement Authenticated Encryption Algorithm 168 ----------- ---------------------------------- 169 SHOULD+ AES-GCM [RFC4106] 170 MAY AES-CCM [RFC4309] 172 2.2. ESP Encryption Algorithms 174 Requirement Encryption Algorithm 175 ----------- -------------------------- 176 MUST NULL [RFC2410] 177 MUST AES-128-CBC [RFC3602] 178 MAY AES-CTR [RFC3686] 179 MAY TripleDES-CBC [RFC2451] 180 SHOULD NOT+ DES-CBC [RFC2405] 182 2.3. ESP Authentication Algorithms 184 Requirement Authentication Algorithm (notes) 185 ----------- ----------------------------- 186 MUST HMAC-SHA1-96 [RFC2404] 187 SHOULD+ AES-GMAC [RFC4543] 188 SHOULD AES-XCBC-MAC-96 [RFC3566] 189 MAY NULL [RFC4303] 191 2.4. AH Authentication Algorithms 193 The requirements for AH are the same as for ESP Authentication 194 Algorithms, except that NULL authentication is inapplicable. 196 2.5. Summary of Changes 198 Old New 199 Requirement Requirement Algorithm (notes) 200 ---- ----------- ----------------- 201 MAY SHOULD+ AES-GCM [RFC4106] 202 MAY SHOULD+ AES-GMAC [RFC4543] 203 MUST- MAY TripleDES-CBC [RFC2451] 204 SHOULD+ SHOULD AES-XCBC-MAC-96 [RFC3566] 205 SHOULD MAY AES-CTR [RFC3686] 207 3. Usage Guidance 209 Since ESP and AH can be used in several different ways, this document 210 provides guidance on the best way to utilize these mechanisms. 212 ESP can provide confidentiality, data origin authentication, or the 213 combination of both of those security services. AH provides only 214 data origin authentication. Background information on those security 215 services is available [RFC4949]. In the following, we shorten `data 216 origin authentication' to `authentication'. 218 Both confidentiality and authentication SHOULD be provided. If 219 confidentiality is not needed, then authentication MAY be provided. 220 Confidentiality without authentication is not effective [DP07] and 221 SHOULD NOT be used. We describe each of these cases in more detail 222 below. 224 To provide confidentiality and authentication, an authenticated 225 encryption transform SHOULD be used in ESP, in conjunction with NULL 226 authentication. Alternatively, an ESP encryption transform and ESP 227 authentication transform MAY be used together (provided that neither 228 transform is NULL). If authentication on the IP header is needed in 229 conjunction with confidentiality of higher-layer data, then AH SHOULD 230 be used in addition to the transforms recommended above. It is NOT 231 RECOMMENDED to use ESP with NULL authentication in conjunction with 232 AH; some configurations of this combination of services have been 233 shown to be insecure [PD10]. 235 To provide authentication without confidentiality, an authentication 236 transform MUST be used in either ESP or AH. It is not possible to 237 provide effective confidentiality without authentication, because the 238 lack of authentication undermines the efficacy of encryption 239 [B96][V02]. An encryption transform MUST NOT be used with a NULL 240 authentication transform (unless the encryption transform is an 241 authenticated encryption transform). 243 Triple-DES SHOULD NOT be used in any scenario in which multiple 244 gigabytes of data will be encrypted with a single key. As a 64-bit 245 block cipher, it leaks information about plaintexts above that 246 "birthday bound" [M13]. Triple-DES CBC is listed as a MAY implement 247 for the sake of backwards compatibility, but its use is discouraged. 249 4. Rationale 251 This section explains the principles behind the implementation 252 requirements described above. 254 The algorithms listed as MAY-implement are not meant to be endorsed 255 over other non-standard alternatives. All of the algorithms that 256 appeared in [RFC4835] are included in this document, for the sake of 257 continuity. In some cases, these algorithms have moved from being 258 SHOULD-implement to MAY-implement algorithms. 260 4.1. Authenticated Encryption 262 This document encourages the use of authenticated encryption 263 algorithms because they can provide significant efficiency and 264 throughput advantages, and the tight binding between authentication 265 and encryption can be a security advantage [RFC5116]. 267 AES-GCM [RFC4106] brings significant performance benefits [KKGEGD], 268 has been incorporated into IPsec recommendations [RFC6379] and has 269 emerged as the preferred authenticated encryption method in IPsec and 270 other standards. 272 4.2. Encryption Transforms 274 Since ESP encryption is optional, support for the "NULL" algorithm is 275 required to maintain consistency with the way services are 276 negotiated. Note that while authentication and encryption can each 277 be "NULL", they MUST NOT both be "NULL" [RFC4301] [H10]. 279 AES Counter Mode (AES-CTR) is an efficient encryption method, but it 280 provides no authentication capability. The AES-GCM authenticated 281 encryption method has all of the advantages of AES-CTR, while also 282 providing authentication. Thus this document moves AES-CTR from a 283 SHOULD to a MAY. 285 The Triple Data Encryption Standard (TDES) is obsolete because of its 286 small block size; as with all 64-bit block ciphers, it SHOULD NOT be 287 used to encrypt more than one gigabyte of data with a single key 288 [M13]. Its key size is smaller than that of the Advanced Encryption 289 Standard (AES), while at the same time its performance and efficiency 290 is worse. Thus, its use in new implementations is discouraged. 292 The Data Encryption Standard (DES) is obsolete because of its small 293 key size and small block size. There have been publicly demonstrated 294 and open-design special-purpose cracking hardware. Therefore, its 295 use is discouraged. 297 4.3. Authentication Transforms 299 AES-GMAC provides good security along with performance advantages, 300 even over HMAC-MD5. In addition, it uses the same internal 301 components as AES-GCM and is easy to implement in a way that shares 302 components with that authenticated encryption algorithm. 304 The MD5 hash function has been found to not meet its goal of 305 collision resistance; it is so weak that its use in digital 306 signatures is highly discouraged [RFC6151]. There have been 307 theoretical results against HMAC-MD5, but that message authentication 308 code does not seem to have a practical vulnerability. Thus, it may 309 not be urgent to remove HMAC-MD5 from the existing protocols. 311 SHA-1 has been found to not meet its goal of collision resistance. 312 However, HMAC-SHA-1 does not rely on this property, and HMAC-SHA-1 is 313 believed to be secure. 315 The HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 are believed to 316 provide a good security margin, and they perform adequately on many 317 platforms. However, these algorithms are not recommended for 318 implementation in this document, because HMAC-SHA-1 support is 319 widespread and its security is good, AES-GMAC provides good security 320 with better performance, and Authenticated Encryption algorithms do 321 not need any authentication methods. 323 AES-XCBC has not seen widespread deployment, despite being previously 324 being recommended as a SHOULD+ in RFC4305. Thus this draft lists it 325 only as a SHOULD. 327 5. Algorithm Diversity 329 When the AES cipher was first adopted, it was decided to continue 330 encouraging the implementation of Triple-DES, in order to provide 331 algorithm diversity. But the passage of time has eroded the 332 viability of Triple-DES as an alternative to AES. As it is a 64-bit 333 block cipher, its security is inadequate at high data rates (see 334 Section 4.2). Its performance in software and FPGAs is considerably 335 worse than that of AES. Since it would not be possible to use 336 Triple-DES as an alternative to AES in high data rate environments, 337 or in environments where its performance could not keep up the 338 requirements, the rationale of retaining Triple-DES to provide 339 algorithm diversity is disappearing. (Of course, this does not 340 change the rationale of retaining Triple-DES in IPsec implementations 341 for backwards compability.) 343 Recent discussions in the IETF have started considering how to make 344 the selection of a different cipher that could provide algorithm 345 diversity in IPsec and other IETF standards. That work is expected 346 to take a long time and involve discussions among many participants 347 and organizations. 349 It is important to bear in mind that it is very highly unlikely that 350 an exploitable flaw will be found in AES (e.g., a flaw that required 351 less than a terabyte of known plaintext, when AES is used in a 352 conventional mode of operation). The only reason that algorithm 353 diversity deserves any consideration is because the problems that 354 would be caused if such a flaw were found would be so large. 356 6. Acknowledgements 358 Much of the wording herein was adapted from [RFC4835], the parent 359 document of this document. That RFC itself borrows from [RFC4305], 360 which borrows in turn from [RFC4307]. RFC4835, RFC4305, and RFC4307 361 were authored by Vishwas Manral, Donald Eastlake, and Jeffrey 362 Schiller respectively. 364 Thanks are due to Scott Fluhrer, Dan Harkins, Brian Weis, and Cheryl 365 Madson for insightful feedback on this draft. 367 7. IANA Considerations 369 None. 371 8. Security Considerations 373 The security of a system that uses cryptography depends on both the 374 strength of the cryptographic algorithms chosen and the strength of 375 the keys used with those algorithms. The security also depends on 376 the engineering and administration of the protocol used by the system 377 to ensure that there are no non-cryptographic ways to bypass the 378 security of the overall system. 380 This document concerns itself with the selection of cryptographic 381 algorithms for the use of ESP and AH, specifically with the selection 382 of mandatory-to-implement algorithms. The algorithms identified in 383 this document as "MUST implement" or "SHOULD implement" are not known 384 to be broken at the current time, and cryptographic research so far 385 leads us to believe that they will likely remain secure into the 386 foreseeable future. However, this is not necessarily forever. We 387 would therefore expect that new revisions of this document will be 388 issued from time to time that reflect the current best practice in 389 this area. 391 9. References 393 9.1. Normative References 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, March 1997. 398 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 399 ESP and AH", RFC 2403, November 1998. 401 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 402 ESP and AH", RFC 2404, November 1998. 404 [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 405 Algorithm With Explicit IV", RFC 2405, November 1998. 407 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 408 Its Use With IPsec", RFC 2410, November 1998. 410 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 411 and Its Use With IPsec", RFC 3566, September 2003. 413 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 414 Algorithm and Its Use with IPsec", RFC 3602, September 415 2003. 417 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 418 Counter Mode With IPsec Encapsulating Security Payload 419 (ESP)", RFC 3686, January 2004. 421 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 422 (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 423 4106, June 2005. 425 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 426 Internet Protocol", RFC 4301, December 2005. 428 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 429 2005. 431 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 432 4303, December 2005. 434 9.2. Informative References 436 [B96] Bellovin, S., "Problem areas for the IP security protocols 437 (Proceedings of the Sixth Usenix Unix Security 438 Symposium)", 1996. 440 [DP07] Degabriele, J. and K. Paterson, "Attacking the IPsec 441 Standards in Encryption-only Configurations (IEEE 442 Symposium on Privacy and Security)", 2007. 444 [H10] Hoban, A., "Using Intel AES New Instructions and PCLMULQDQ 445 to Significantly Improve IPSec Performance on Linux ", 446 2010. 448 [KKGEGD] Kounavis, M., Kang, X., Grewal, K., Eszenyi, M., Gueron, 449 S., and D. Durham, "Encrypting the Internet (SIGCOMM)", 450 2010. 452 [M13] McGrew, D., "Impossible plaintext cryptanalysis and 453 probable-plaintext collision attacks of 64-bit block 454 cipher modes ", 2012. 456 [PD10] Paterson, K. and J. Degabriele, "On the (in)security of 457 IPsec in MAC-then-encrypt configurations (ACM Conference 458 on Computer and Communications Security, ACM CCS)", 2010. 460 [RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation 461 Requirements for Encapsulating Security Payload (ESP) and 462 Authentication Header (AH)", RFC 4305, December 2005. 464 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 465 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 466 December 2005. 468 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 469 Mode with IPsec Encapsulating Security Payload (ESP)", RFC 470 4309, December 2005. 472 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 473 Requirements for Encapsulating Security Payload (ESP) and 474 Authentication Header (AH)", RFC 4835, April 2007. 476 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 477 4949, August 2007. 479 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 480 Encryption", RFC 5116, January 2008. 482 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 483 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 484 RFC 6151, March 2011. 486 [RFC6379] Law, L. and J. Solinas, "Suite B Cryptographic Suites for 487 IPsec", RFC 6379, October 2011. 489 [V02] Vaudenay, S., "Security Flaws Induced by CBC Padding - 490 Applications to SSL, IPSEC, WTLS ... (EUROCRYPT)", 2002. 492 Authors' Addresses 494 David McGrew 495 Cisco Systems 496 13600 Dulles Technology Drive 497 Herndon, Virginia 20171 498 USA 500 Phone: 408 525 8651 501 Email: mcgrew@cisco.com 503 Wajdi Feghali 504 Intel Corp. 505 75 Reed Road 506 Hudson, Massachusetts 507 USA 509 Email: wajdi.k.feghali@intel.com 511 Paul Hoffman 512 VPN Consortium 514 Email: paul.hoffman@vpnc.org