idnits 2.17.1 draft-ietf-ipsecme-esp-ah-reqts-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 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 (March 11, 2013) is 4063 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 218, but not defined == Missing Reference: 'RFC4543' is mentioned on line 217, but not defined == Unused Reference: 'RFC2403' is defined on line 413, 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 Internet Engineering Task Force D. McGrew 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track W. Feghali 5 Expires: September 12, 2013 Intel Corp. 6 March 11, 2013 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-00 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 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 12, 2013. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 69 1.2. Document History . . . . . . . . . . . . . . . . . . . . . 4 70 2. Implementation Requirements . . . . . . . . . . . . . . . . . 5 71 2.1. ESP Authenticated Encryption (Combined Mode Algorithms) . 5 72 2.2. ESP Encryption Algorithms . . . . . . . . . . . . . . . . 5 73 2.3. ESP Authentication Algorithms . . . . . . . . . . . . . . 5 74 2.4. AH Authentication Algorithms . . . . . . . . . . . . . . . 5 75 2.5. Summary of Changes . . . . . . . . . . . . . . . . . . . . 5 76 3. Usage Guidance . . . . . . . . . . . . . . . . . . . . . . . . 7 77 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 4.1. Authenticated Encryption . . . . . . . . . . . . . . . . . 8 79 4.2. Encryption Transforms . . . . . . . . . . . . . . . . . . 8 80 4.3. Authentication Transforms . . . . . . . . . . . . . . . . 9 81 5. Algorithm Diversity . . . . . . . . . . . . . . . . . . . . . 10 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 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 1.2. Document History 155 This is the initial version of this draft. It is based on an earlier 156 individual submission [draft-mcgrew-ipsec-me-esp-ah-reqts], and 157 incorporates feedback provided during the last IPsec ME meeting at 158 IETF85. Triple-DES is now a MAY (instead of SHOULD NOT) and HMAC-MD5 159 is now ignored (instead of a SHOULD NOT), and "MAY" is no longer 160 called out, except for algorithms that were previously listed as 161 SHOULD, SHOULD+, or MUST. 163 This revision also adds a section discussing algorithm diversity, and 164 references to new work on the selection of future cryptographic 165 standards [draft-mcgrew-standby-cipher] and technical work showing 166 the insecurity of 64-bit block ciphers (such as the Triple-DES 167 algorithm) used to encrypt more than a gigabyte of data [M13]. 169 2. Implementation Requirements 171 This section specifies the cryptographic algorithms that MUST be 172 implemented, and provides guidance about ones that SHOULD or SHOULD 173 NOT be implemented. 175 2.1. ESP Authenticated Encryption (Combined Mode Algorithms) 177 ESP combined mode algorithms provide both confidentiality and 178 authentication services; in cryptographic terms, these are 179 authenticated encryption algorithms [RFC5116]. Authenticated 180 encryption transforms are listed in the ESP encryption transforms 181 IANA registry. 183 Requirement Authenticated Encryption Algorithm 184 ----------- ---------------------------------- 185 SHOULD+ AES-GCM [RFC4106] 186 MAY AES-CCM [RFC4309] 188 2.2. ESP Encryption Algorithms 190 Requirement Encryption Algorithm 191 ----------- -------------------------- 192 MUST NULL [RFC2410] 193 MUST AES-128-CBC [RFC3602] 194 MAY AES-CTR [RFC3686] 195 MAY TripleDES-CBC [RFC2451] 196 SHOULD NOT+ DES-CBC [RFC2405] 198 2.3. ESP Authentication Algorithms 200 Requirement Authentication Algorithm (notes) 201 ----------- ----------------------------- 202 MUST HMAC-SHA1-96 [RFC2404] 203 SHOULD+ AES-GMAC [RFC4543] 204 SHOULD AES-XCBC-MAC-96 [RFC3566] 205 MAY NULL [RFC4303] 207 2.4. AH Authentication Algorithms 209 The requirements for AH are the same as for ESP Authentication 210 Algorithms, except that NULL authentication is inapplicable. 212 2.5. Summary of Changes 213 Old New 214 Requirement Requirement Algorithm (notes) 215 ---- ----------- ----------------- 216 MAY SHOULD+ AES-GCM [RFC4106] 217 MAY SHOULD+ AES-GMAC [RFC4543] 218 MUST- MAY TripleDES-CBC [RFC2451] 219 SHOULD+ SHOULD AES-XCBC-MAC-96 [RFC3566] 220 SHOULD MAY AES-CTR [RFC3686] 222 3. Usage Guidance 224 Since ESP and AH can be used in several different ways, this note 225 provides guidance on the best way to utilize these mechanisms. 227 ESP can provide confidentiality, data origin authentication, or the 228 combination of both of those security services. AH provides only 229 data origin authentication. Background information on those security 230 services is available [RFC4949]. In the following, we shorten `data 231 origin authentication' to `authentication'. 233 Both confidentiality and authentication SHOULD be provided. If 234 confidentiality is not needed, then authentication MAY be provided. 235 Confidentiality without authentication is not effective [DP07] and 236 SHOULD NOT be used. We describe each of these cases in more detail 237 below. 239 To provide confidentiality and authentication, an authenticated 240 encryption transform SHOULD be used in ESP, in conjunction with NULL 241 authentication. Alternatively, an ESP encryption transform and ESP 242 authentication transform MAY be used together (provided that neither 243 transform is NULL). If authentication on the IP header is needed in 244 conjunction with confidentiality of higher-layer data, then AH SHOULD 245 be used in addition to the transforms recommended above. It is NOT 246 RECOMMENDED to use ESP with NULL authentication in conjunction with 247 AH; some configurations of this combination of services have been 248 shown to be insecure [PD10]. 250 To provide authentication without confidentiality, an authentication 251 transform MUST be used in either ESP or AH. It is not possible to 252 provide effective confidentiality without authentication, because the 253 lack of authentication undermines the efficacy of encryption 254 [B96][V02]. An encryption transform MUST NOT be used with a NULL 255 authentication transform (unless the encryption transform is an 256 authenticated encryption transform). 258 Triple-DES SHOULD NOT be used in any scenario in which multiple 259 gigabytes of data will be encrypted with a single key. As a 64-bit 260 block cipher, it leaks information about plaintexts above that 261 "birthday bound" [M13]. Triple-DES CBC is listed as a MAY implement 262 for the sake of backwards compatibility, but its use is discouraged. 264 4. Rationale 266 This section explains the principles behind the implementation 267 requirements described above. 269 The algorithms listed as MAY-implement are not meant to be endorsed 270 over other non-standard alternatives. All of the algorithms that 271 appeared in [RFC4835] are included in this note, for the sake of 272 continuity. In some cases, these algorithms have moved from being 273 SHOULD-implement to MAY-implement algorithms. 275 4.1. Authenticated Encryption 277 This note encourages the use of authenticated encryption algorithms 278 because they can provide significant efficiency and throughput 279 advantages, and the tight binding between authentication and 280 encryption can be a security advantage [RFC5116]. 282 AES-GCM [RFC4106] brings significant performance benefits [KKGEGD], 283 has been incorporated into IPsec recommendations [RFC6379] and has 284 emerged as the preferred authenticated encryption method in IPsec and 285 other standards. 287 4.2. Encryption Transforms 289 Since ESP encryption is optional, support for the "NULL" algorithm is 290 required to maintain consistency with the way services are 291 negotiated. Note that while authentication and encryption can each 292 be "NULL", they MUST NOT both be "NULL" [RFC4301] [H10]. 294 AES Counter Mode (AES-CTR) is an efficient encryption method, but it 295 provides no authentication capability. The AES-GCM authenticated 296 encryption method has all of the advantages of AES-CTR, while also 297 providing authentication. Thus this note moves AES-CTR from a SHOULD 298 to a MAY. 300 The Triple Data Encryption Standard (TDES) is obsolete because of its 301 small block size; as with all 64-bit block ciphers, it SHOULD NOT be 302 used to encrypt more than one gigabyte of data with a single key 303 [M13]. Its key size is smaller than that of the Advanced Encryption 304 Standard (AES), while at the same time its performance and efficiency 305 is worse. Thus, its use in new implementations is discouraged. 307 The Data Encryption Standard (DES) is obsolete because of its small 308 key size and small block size. There have been publicly demonstrated 309 and open-design special-purpose cracking hardware. Therefore, its 310 use is discouraged. 312 4.3. Authentication Transforms 314 AES-GMAC provides good security along with performance advantages, 315 even over HMAC-MD5. In addition, it uses the same internal 316 components as AES-GCM and is easy to implement in a way that shares 317 components with that authenticated encryption algorithm. 319 The MD5 hash function has been found to not meet its goal of 320 collision resistance; it is so weak that its use in digital 321 signatures is highly discouraged [RFC6151]. There have been 322 theoretical results against HMAC-MD5, but that message authentication 323 code does not seem to have a practical vulnerability. Thus, it may 324 not be urgent to remove HMAC-MD5 from the existing protocols. 326 SHA-1 has been found to not meet its goal of collision resistance. 327 However, HMAC-SHA-1 does not rely on this property, and HMAC-SHA-1 is 328 believed to be secure. 330 The HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 are believed to 331 provide a good security margin, and they perform adequately on many 332 platforms. However, these algorithms are not recommended for 333 implementation in this note, because HMAC-SHA-1 support is widespread 334 and its security is good, AES-GMAC provides good security with better 335 performance, and Authenticated Encryption algorithms do not need any 336 authentication methods. 338 AES-XCBC has not seen widespread deployment, despite being previously 339 being recommended as a SHOULD+ in RFC4305. Thus this draft lists it 340 only as a SHOULD. 342 5. Algorithm Diversity 344 When the AES cipher was first adopted, it was decided to continue 345 encouraging the implementation of Triple-DES, in order to provide 346 algorithm diversity. But the passage of time has eroded the 347 viability of Triple-DES as an alternative to AES. As it is a 64-bit 348 block cipher, its security is inadequate at high data rates (see 349 Section 4.2). Its performance in software and FPGAs is considerably 350 worse than that of AES. Since it would not be possible to use 351 Triple-DES as an alternative to AES in high data rate environments, 352 or in environments where its performance could not keep up the 353 requirements, the rationale of retaining Triple-DES to provide 354 algorithm diversity is disappearing. (Of course, this does not 355 change the rationale of retaining Triple-DES in IPsec implementations 356 for backwards compability.) 358 It may be prudent to begin considering the selection of a different 359 cipher that could provide algorithm diversity in IPsec and other IETF 360 standards. There are many important criteria to consider, which are 361 out of scope for this note. These issues have been taken up in 362 recent work [draft-mcgrew-standby-cipher]. 364 It is important to bear in mind that it is very highly unlikely that 365 an exploitable flaw will be found in AES (e.g., a flaw that required 366 less than a terabyte of known plaintext, when AES is used in a 367 conventional mode of operation). The only reason that algorithm 368 diversity deserves any consideration is because the problems that 369 would be caused if such a flaw were found would be so large. 371 6. Acknowledgements 373 Much of the wording herein was adapted from [RFC4835], the parent 374 document of this document. That RFC itself borrows from [RFC4305], 375 which borrows in turn from [RFC4307]. RFC4835, RFC4305, and RFC4307 376 were authored by Vishwas Manral, Donald Eastlake, and Jeffrey 377 Schiller respectively. 379 Thanks are due to Scott Fluhrer, Dan Harkins, Brian Weis, and Cheryl 380 Madson for insightful feedback on this draft. 382 7. IANA Considerations 384 This memo includes no request to IANA. 386 8. Security Considerations 388 The security of a system that uses cryptography depends on both the 389 strength of the cryptographic algorithms chosen and the strength of 390 the keys used with those algorithms. The security also depends on 391 the engineering and administration of the protocol used by the system 392 to ensure that there are no non-cryptographic ways to bypass the 393 security of the overall system. 395 This document concerns itself with the selection of cryptographic 396 algorithms for the use of ESP and AH, specifically with the selection 397 of mandatory-to-implement algorithms. The algorithms identified in 398 this document as "MUST implement" or "SHOULD implement" are not known 399 to be broken at the current time, and cryptographic research so far 400 leads us to believe that they will likely remain secure into the 401 foreseeable future. However, this is not necessarily forever. We 402 would therefore expect that new revisions of this document will be 403 issued from time to time that reflect the current best practice in 404 this area. 406 9. References 408 9.1. Normative References 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, March 1997. 413 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 414 ESP and AH", 1998. 416 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 417 ESP and AH", 1998. 419 [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 420 Algorithm With Explicit IV", 1998. 422 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 423 Its Use With IPsec", 1998. 425 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 426 and Its Use With IPsec", 2003. 428 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 429 Algorithm and Its Use with IPsec", 2003. 431 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 432 Counter Mode With IPsec Encapsulating Security Payload 433 (ESP)", 2004. 435 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 436 (GCM) in IPsec Encapsulating Security Payload (ESP)", 437 2005. 439 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 440 Internet Protocol", 2005. 442 [RFC4302] Kent, S., "IP Authentication Header", 2005. 444 [RFC4303] Kent, S., "IP Encapsulating Security Payload", 2005. 446 9.2. Informative References 448 [B96] Bellovin, S., "Problem areas for the IP security protocols 449 (Proceedings of the Sixth Usenix Unix Security 450 Symposium)", 1996. 452 [DP07] Degabriele, J. and K. Paterson, "Attacking the IPsec 453 Standards in Encryption-only Configurations (IEEE 454 Symposium on Privacy and Security)", 2007. 456 [H10] Hoban, A., "Using Intel AES New Instructions and PCLMULQDQ 457 to Significantly Improve IPSec Performance on Linux", 458 2010. 460 [KKGEGD] Kounavis, M., Kang, X., Grewal, K., Eszenyi, M., Gueron, 461 S., and D. Durham, "Encrypting the Internet (SIGCOMM)", 462 2010. 464 [M13] McGrew, D., "Impossible plaintext cryptanalysis and 465 probable-plaintext collision attacks of 64-bit block 466 cipher modes", 2012. 468 [PD10] Paterson, K. and J. Degabriele, "On the (in)security of 469 IPsec in MAC-then-encrypt configurations (ACM Conference 470 on Computer and Communications Security, ACM CCS)", 2010. 472 [RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation 473 Requirements for Encapsulating Security Payload (ESP) and 474 Authentication Header (AH)". 476 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 477 Internet Key Exchange Version 2 (IKEv2)", 2005. 479 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 480 Mode with IPsec Encapsulating Security Payload (ESP)", 481 2005. 483 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 484 Requirements for Encapsulating Security Payload (ESP) and 485 Authentication Header (AH)". 487 [RFC4949] Shirley, R., "Internet Security Glossary, Version 2", 488 2007. 490 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 491 Encryption", 2008. 493 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 494 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 495 2011. 497 [RFC6379] Law, L. and J. Solinas, "Suite B Cryptographic Suites for 498 IPsec", 2011. 500 [V02] Vaudenay, S., "Security Flaws Induced by CBC Padding - 501 Applications to SSL, IPSEC, WTLS ... (EUROCRYPT)", 2002. 503 [draft-mcgrew-ipsec-me-esp-ah-reqts] 504 McGrew, D., "Cryptographic Algorithm Implementation 505 Requirements and Usage Guidance for Encapsulating Security 506 Payload (ESP) and Authentication Header (AH)", 2012. 508 [draft-mcgrew-standby-cipher] 509 McGrew, D., Grieco, A., and Y. Sheffer, "Selection of 510 Future Cryptographic Standards", 2013. 512 Authors' Addresses 514 David McGrew 515 Cisco Systems 516 13600 Dulles Technology Drive 517 Herndon, Virginia 20171 518 USA 520 Phone: 408 525 8651 521 Email: mcgrew@cisco.com 523 Wajdi Feghali 524 Intel Corp. 525 75 Reed Road 526 Hudson, Massachusetts 527 USA 529 Phone: 530 Email: wajdi.k.feghali@intel.com