idnits 2.17.1 draft-ietf-ipsecme-esp-ah-reqts-06.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 (April 18, 2014) is 3654 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) -- Obsolete informational reference (is this intentional?): RFC 4835 (Obsoleted by RFC 7321) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 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 Obsoletes: 4835 (if approved) P. Hoffman 5 Intended status: Standards Track VPN Consortium 6 Expires: October 20, 2014 April 18, 2014 8 Cryptographic Algorithm Implementation Requirements and Usage Guidance 9 for Encapsulating Security Payload (ESP) and Authentication Header (AH) 10 draft-ietf-ipsecme-esp-ah-reqts-06 12 Abstract 14 This Internet Draft is standards track proposal to update to the 15 Cryptographic Algorithm Implementation Requirements for ESP and AH; 16 it also adds usage guidance to help in the selection of these 17 algorithms. 19 The Encapsulating Security Payload (ESP) and Authentication Header 20 (AH) protocols makes use of various cryptographic algorithms to 21 provide confidentiality and/or data origin authentication to 22 protected data communications in the IP Security (IPsec) 23 architecture. To ensure interoperability between disparate 24 implementations, the IPsec standard specifies a set of mandatory-to- 25 implement algorithms. This document specifies the current set of 26 mandatory-to-implement algorithms for ESP and AH, specifies 27 algorithms that should be implemented because they may be promoted to 28 mandatory at some future time, and also recommends against the 29 implementation of some obsolete algorithms. Usage guidance is also 30 provided to help the user of ESP and AH best achieve their security 31 goals through appropriate choices of cryptographic algorithms. 33 This document obsoletes RFC 4835. 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 October 20, 2014. 51 Copyright Notice 53 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . 8 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 87 9.2. Informative References . . . . . . . . . . . . . . . . . 9 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", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in 135 [RFC2119]. 137 Following [RFC4835], we define some additional key words: 139 MUST- This term means the same as MUST. However, we expect that at 140 some point in the future this algorithm will no longer be a MUST. 142 SHOULD+ This term means the same as SHOULD. However, it is likely 143 that an algorithm marked as SHOULD+ will be promoted at some 144 future time to be a MUST. 146 SHOULD- This term means the same as SHOULD. However, it is likely 147 that an algorithm marked as SHOULD- will be deprecated to a MAY or 148 worse in a future version of this document. 150 2. Implementation Requirements 152 This section specifies the cryptographic algorithms that MUST be 153 implemented, and provides guidance about ones that SHOULD or SHOULD 154 NOT be implemented. 156 In the following sections, all AES modes are for 128-bit AES. 192-bit 157 and 256-bit AES MAY be supported for those modes, but the 158 requirements here are for 128-bit AES. 160 2.1. ESP Authenticated Encryption (Combined Mode Algorithms) 162 ESP combined mode algorithms provide both confidentiality and 163 authentication services; in cryptographic terms, these are 164 authenticated encryption algorithms [RFC5116]. Authenticated 165 encryption transforms are listed in the ESP encryption transforms 166 IANA registry. 168 Requirement Authenticated Encryption Algorithm 169 ----------- ---------------------------------- 170 SHOULD+ AES-GCM with a 16 octet ICV [RFC4106] 171 MAY AES-CCM [RFC4309] 173 2.2. ESP Encryption Algorithms 175 Requirement Encryption Algorithm 176 ----------- -------------------------- 177 MUST NULL [RFC2410] 178 MUST AES-CBC [RFC3602] 179 MAY AES-CTR [RFC3686] 180 MAY TripleDES-CBC [RFC2451] 181 MUST NOT DES-CBC [RFC2405] 183 2.3. ESP Authentication Algorithms 185 Requirement Authentication Algorithm (notes) 186 ----------- ----------------------------- 187 MUST HMAC-SHA1-96 [RFC2404] 188 SHOULD+ AES-GMAC with AES-128 [RFC4543] 189 SHOULD AES-XCBC-MAC-96 [RFC3566] 190 MAY NULL [RFC4303] 192 Note that the requirement level for NULL authentication depends on 193 the type of encryption used. When using authenticated encryption 194 from Section 2.1, the requirement for NULL encryption is the same as 195 the requirement for the authenticated encryption itself. When using 196 the encryption from Section 2.2, the requirement for NULL encryption 197 is truly "MAY"; see Section 3 for more detail. 199 2.4. AH Authentication Algorithms 201 The requirements for AH are the same as for ESP Authentication 202 Algorithms, except that NULL authentication is inapplicable. 204 2.5. Summary of Changes 206 Old New 207 Requirement Requirement Algorithm (notes) 208 ---- ----------- ----------------- 209 MAY SHOULD+ AES-GCM with a 16 octet ICV [RFC4106] 210 MAY SHOULD+ AES-GMAC with AES-128 [RFC4543] 211 MUST- MAY TripleDES-CBC [RFC2451] 212 SHOULD NOT MUST NOT DES-CBC [RFC2405] 213 SHOULD+ SHOULD AES-XCBC-MAC-96 [RFC3566] 214 SHOULD MAY AES-CTR [RFC3686] 216 3. Usage Guidance 218 Since ESP and AH can be used in several different ways, this document 219 provides guidance on the best way to utilize these mechanisms. 221 ESP can provide confidentiality, data origin authentication, or the 222 combination of both of those security services. AH provides only 223 data origin authentication. Background information on those security 224 services is available [RFC4949]. In the following, we shorten "data 225 origin authentication" to "authentication". 227 Both confidentiality and authentication SHOULD be provided. If 228 confidentiality is not needed, then authentication MAY be provided. 229 Confidentiality without authentication is not effective [DP07] and 230 SHOULD NOT be used. We describe each of these cases in more detail 231 below. 233 To provide both confidentiality and authentication, an authenticated 234 encryption transform from Section 2.1 SHOULD be used in ESP, in 235 conjunction with NULL authentication. Alternatively, an ESP 236 encryption transform and ESP authentication transform MAY be used 237 together. It is NOT RECOMMENDED to use ESP with NULL authentication 238 in conjunction with AH; some configurations of this combination of 239 services have been shown to be insecure [PD10]. 241 To provide authentication without confidentiality, an authentication 242 transform MUST be used in either ESP or AH. The IPsec community 243 generally prefers ESP with NULL encryption over AH. AH is still 244 required in some protocols and operational environments when there 245 are security-sensitive options in the IP header, such as source 246 routing headers; ESP inherently cannot protect those IP options. It 247 is not possible to provide effective confidentiality without 248 authentication, because the lack of authentication undermines the 249 trustworthiness of encryption [B96][V02]. Therefore, an encryption 250 transform MUST NOT be used with a NULL authentication transform 251 (unless the encryption transform is an authenticated encryption 252 transform from Section 2.1). 254 Triple-DES SHOULD NOT be used in any scenario in which multiple 255 gigabytes of data will be encrypted with a single key. As a 64-bit 256 block cipher, it leaks information about plaintexts above that 257 "birthday bound" [M13]. Triple-DES CBC is listed as a MAY implement 258 for the sake of backwards compatibility, but its use is discouraged. 260 4. Rationale 262 This section explains the principles behind the implementation 263 requirements described above. 265 The algorithms listed as MAY-implement are not meant to be endorsed 266 over other non-standard alternatives. All of the algorithms that 267 appeared in [RFC4835] are included in this document, for the sake of 268 continuity. In some cases, these algorithms have moved from being 269 SHOULD-implement to MAY-implement algorithms. 271 4.1. Authenticated Encryption 273 This document encourages the use of authenticated encryption 274 algorithms because they can provide significant efficiency and 275 throughput advantages, and the tight binding between authentication 276 and encryption can be a security advantage [RFC5116]. 278 AES-GCM [RFC4106] brings significant performance benefits [KKGEGD], 279 has been incorporated into IPsec recommendations [RFC6379] and has 280 emerged as the preferred authenticated encryption method in IPsec and 281 other standards. 283 4.2. Encryption Transforms 285 Since ESP encryption is optional, support for the "NULL" algorithm is 286 required to maintain consistency with the way services are 287 negotiated. Note that while authentication and encryption can each 288 be "NULL", they MUST NOT both be "NULL" [RFC4301] [H10]. 290 AES Counter Mode (AES-CTR) is an efficient encryption method, but it 291 provides no authentication capability. The AES-GCM authenticated 292 encryption method has all of the advantages of AES-CTR, while also 293 providing authentication. Thus this document moves AES-CTR from a 294 SHOULD to a MAY. 296 The Triple Data Encryption Standard (TDES) is obsolete because of its 297 small block size; as with all 64-bit block ciphers, it SHOULD NOT be 298 used to encrypt more than one gigabyte of data with a single key 299 [M13]. Its key size is smaller than that of the Advanced Encryption 300 Standard (AES), while at the same time its performance and efficiency 301 is worse. Thus, its use in new implementations is discouraged. 303 The Data Encryption Standard (DES) is obsolete because of its small 304 key size and small block size. There have been publicly demonstrated 305 and open-design special-purpose cracking hardware. Therefore, its 306 use is has been changed to MUST NOT in this document. 308 4.3. Authentication Transforms 310 AES-GMAC provides good security along with performance advantages, 311 even over HMAC-MD5. In addition, it uses the same internal 312 components as AES-GCM and is easy to implement in a way that shares 313 components with that authenticated encryption algorithm. 315 The MD5 hash function has been found to not meet its goal of 316 collision resistance; it is so weak that its use in digital 317 signatures is highly discouraged [RFC6151]. There have been 318 theoretical results against HMAC-MD5, but that message authentication 319 code does not seem to have a practical vulnerability. Thus, it may 320 not be urgent to remove HMAC-MD5 from the existing protocols. 322 SHA-1 has been found to not meet its goal of collision resistance. 323 However, HMAC-SHA-1 does not rely on this property, and HMAC-SHA-1 is 324 believed to be secure. 326 The HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 are believed to 327 provide a good security margin, and they perform adequately on many 328 platforms. However, these algorithms are not recommended for 329 implementation in this document, because HMAC-SHA-1 support is 330 widespread and its security is good, AES-GMAC provides good security 331 with better performance, and Authenticated Encryption algorithms do 332 not need any authentication methods. 334 AES-XCBC has not seen widespread deployment, despite being previously 335 being recommended as a SHOULD+ in RFC 4835. Thus this draft lists it 336 only as a SHOULD. 338 5. Algorithm Diversity 340 When the AES cipher was first adopted, it was decided to continue 341 encouraging the implementation of Triple-DES, in order to provide 342 algorithm diversity. But the passage of time has eroded the 343 viability of Triple-DES as an alternative to AES. As it is a 64-bit 344 block cipher, its security is inadequate at high data rates (see 345 Section 4.2). Its performance in software and FPGAs is considerably 346 worse than that of AES. Since it would not be possible to use 347 Triple-DES as an alternative to AES in high data rate environments, 348 or in environments where its performance could not keep up the 349 requirements, the rationale of retaining Triple-DES to provide 350 algorithm diversity is disappearing. (Of course, this does not 351 change the rationale of retaining Triple-DES in IPsec implementations 352 for backwards compability.) 354 Recent discussions in the IETF have started considering how to make 355 the selection of a different cipher that could provide algorithm 356 diversity in IPsec and other IETF standards. That work is expected 357 to take a long time and involve discussions among many participants 358 and organizations. 360 It is important to bear in mind that it is very highly unlikely that 361 an exploitable flaw will be found in AES (e.g., a flaw that required 362 less than a terabyte of known plaintext, when AES is used in a 363 conventional mode of operation). The only reason that algorithm 364 diversity deserves any consideration is because the problems that 365 would be caused if such a flaw were found would be so large. 367 6. Acknowledgements 369 Much of the wording herein was adapted from [RFC4835], the parent 370 document of this document. That RFC itself borrows from earlier 371 RFCs, notably RFC 4305 and 4307. RFC 4835, RFC 4305, and RFC 4307 372 were authored by Vishwas Manral, Donald Eastlake, and Jeffrey 373 Schiller respectively. 375 Thanks are due to Wajdi Feghali, Brian Weis, Cheryl Madson, Dan 376 Harkins, Paul Wouters, Ran Atkinson, Scott Fluhrer, Tero Kivinen, and 377 Valery Smyslov for insightful feedback on this draft. 379 [[[ This paragraph exists so that the nits checker doesn't barf. It 380 is to be removed before this is published as an RFC. [RFC2404] 381 [RFC2405] [RFC2410] [RFC2451] [RFC3566] [RFC3602] [RFC3686] [RFC4309] 382 [RFC4543] ]]] 384 7. IANA Considerations 385 None. 387 8. Security Considerations 389 The security of a system that uses cryptography depends on both the 390 strength of the cryptographic algorithms chosen and the strength of 391 the keys used with those algorithms. The security also depends on 392 the engineering and administration of the protocol used by the system 393 to ensure that there are no non-cryptographic ways to bypass the 394 security of the overall system. 396 This document concerns itself with the selection of cryptographic 397 algorithms for the use of ESP and AH, specifically with the selection 398 of mandatory-to-implement algorithms. The algorithms identified in 399 this document as "MUST implement" or "SHOULD implement" are not known 400 to be broken at the current time, and cryptographic research so far 401 leads us to believe that they will likely remain secure into the 402 foreseeable future. However, this is not necessarily forever. We 403 would therefore expect that new revisions of this document will be 404 issued from time to time that reflect the current best practice in 405 this area. 407 9. References 409 9.1. Normative References 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, March 1997. 414 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 415 Internet Protocol", RFC 4301, December 2005. 417 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 418 2005. 420 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 421 4303, December 2005. 423 9.2. Informative References 425 [B96] Bellovin, S., "Problem areas for the IP security protocols 426 (Proceedings of the Sixth Usenix Unix Security 427 Symposium)", 1996. 429 [DP07] Degabriele, J. and K. Paterson, "Attacking the IPsec 430 Standards in Encryption-only Configurations (IEEE 431 Symposium on Privacy and Security)", 2007. 433 [H10] Hoban, A., "Using Intel AES New Instructions and PCLMULQDQ 434 to Significantly Improve IPSec Performance on Linux", 435 2010. 437 [KKGEGD] Kounavis, M., Kang, X., Grewal, K., Eszenyi, M., Gueron, 438 S., and D. Durham, "Encrypting the Internet (SIGCOMM)", 439 2010. 441 [M13] McGrew, D., "Impossible plaintext cryptanalysis and 442 probable-plaintext collision attacks of 64-bit block 443 cipher modes", 2012. 445 [PD10] Paterson, K. and J. Degabriele, "On the (in)security of 446 IPsec in MAC-then-encrypt configurations (ACM Conference 447 on Computer and Communications Security, ACM CCS)", 2010. 449 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 450 ESP and AH", RFC 2404, November 1998. 452 [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 453 Algorithm With Explicit IV", RFC 2405, November 1998. 455 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 456 Its Use With IPsec", RFC 2410, November 1998. 458 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 459 Algorithms", RFC 2451, November 1998. 461 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 462 and Its Use With IPsec", RFC 3566, September 2003. 464 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 465 Algorithm and Its Use with IPsec", RFC 3602, September 466 2003. 468 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 469 Counter Mode With IPsec Encapsulating Security Payload 470 (ESP)", RFC 3686, January 2004. 472 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 473 (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 474 4106, June 2005. 476 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 477 Mode with IPsec Encapsulating Security Payload (ESP)", RFC 478 4309, December 2005. 480 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 481 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 482 May 2006. 484 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 485 Requirements for Encapsulating Security Payload (ESP) and 486 Authentication Header (AH)", RFC 4835, April 2007. 488 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 489 4949, August 2007. 491 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 492 Encryption", RFC 5116, January 2008. 494 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 495 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 496 RFC 6151, March 2011. 498 [RFC6379] Law, L. and J. Solinas, "Suite B Cryptographic Suites for 499 IPsec", RFC 6379, October 2011. 501 [V02] Vaudenay, S., "Security Flaws Induced by CBC Padding - 502 Applications to SSL, IPSEC, WTLS ... (EUROCRYPT)", 2002. 504 Authors' Addresses 506 David McGrew 507 Cisco Systems 509 Email: mcgrew@cisco.com 511 Paul Hoffman 512 VPN Consortium 514 Email: paul.hoffman@vpnc.org