idnits 2.17.1 draft-manral-ipsec-rfc4305-bis-errata-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 428. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 439. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 452. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC4305, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 08, 2007) is 6289 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 normative reference: RFC 4305 (Obsoleted by RFC 4835) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2407 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4307 (Obsoleted by RFC 8247) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group V. Manral 2 Obsoletes: 4305 (if approved) IP Infusion 3 Intended status: Standards Track January 08, 2007 4 Expires: July 12, 2007 6 Cryptographic Algorithm Implementation Requirements for Encapsulating 7 Security Payload (ESP) and Authentication Header (AH) 8 draft-manral-ipsec-rfc4305-bis-errata-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 12, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The IPsec series of protocols makes use of various cryptographic 42 algorithms in order to provide security services. The Encapsulating 43 Security Payload (ESP) and the Authentication Header (AH) provide two 44 mechanisms for protecting data being sent over an IPsec Security 45 Association (SA). To ensure interoperability between disparate 46 implementations, it is necessary to specify a set of mandatory-to- 47 implement algorithms to ensure that there is at least one algorithm 48 that all implementations will have available. This document defines 49 the current set of mandatory-to-implement algorithms for ESP and AH 50 as well as specifying algorithms that should be implemented because 51 they may be promoted to mandatory at some future time. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4 57 3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Encapsulating Security Payload . . . . . . . . . . . . . . 5 59 3.1.1. ESP Encryption and Authentication Algorithms . . . . . 5 60 3.1.2. ESP Combined Mode Algorithms . . . . . . . . . . . . . 6 61 3.2. Authentication Header . . . . . . . . . . . . . . . . . . 6 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 65 7. Changes from RFC 2402 and RFC2406 to RFC4305 . . . . . . . . . 10 66 8. Changes from RFC4305 . . . . . . . . . . . . . . . . . . . . . 11 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 Intellectual Property and Copyright Statements . . . . . . . . . . 16 73 1. Introduction 75 The Encapsulating Security Payload (ESP) and the Authentication 76 Header (AH) provide two mechanisms for protecting data being sent 77 over an IPsec Security Association (SA) [RFC4301], [RFC4302]. To 78 ensure interoperability between disparate implementations, it is 79 necessary to specify a set of mandatory-to-implement algorithms to 80 ensure that there is at least one algorithm that all implementations 81 will have available. This document defines the current set of 82 mandatory-to-implement algorithms for ESP and AH as well as 83 specifying algorithms that should be implemented because they may be 84 promoted to mandatory at some future time. 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 is not included the main IPsec, ESP, or AH specifications. 99 It is instead placed in this document. As the choice of algorithm 100 changes, only this 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 such algorithms (as they 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. Requirements Terminology 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 119 likely that an algorithm marked as SHOULD+ will be 120 promoted at some future time to be a MUST. 121 SHOULD- This term means the same as SHOULD. However, it is 122 likely that an algorithm marked as SHOULD- will be 123 deprecated to a MAY or worse in a future version of 124 this document. 125 MUST- This term means the same as MUST. However, we 126 expect that at some point in the future this algorithm 127 will no longer be a MUST. 129 3. Algorithm Selection 131 For IPsec implementations to interoperate, they must support one or 132 more security algorithms in common. This section specifies the 133 security algorithm implementation requirements for standards- 134 conformant ESP and AH implementations. The security algorithms 135 actually used for any particular ESP or AH security association are 136 determined by a negotiation mechanism, such as the Internet Key 137 Exchange (IKE [RFC2409], [RFC4306]) or pre-establishment. 139 Of course, additional standard and proprietary algorithms beyond 140 those listed below can be implemented. 142 3.1. Encapsulating Security Payload 144 The implementation conformance requirements for security algorithms 145 for ESP are given in the tables below. See Section 2 for definitions 146 of the values in the "Requirement" column. 148 3.1.1. ESP Encryption and Authentication Algorithms 150 These tables list encryption and authentication algorithms for the 151 IPsec Encapsulating Security Payload protocol. 153 Requirement Encryption Algorithm (notes) 154 ----------- -------------------------- 155 MUST NULL [RFC2410] (1) 156 MUST AES-CBC with 128-bit keys [RFC3602] 157 MUST- TripleDES-CBC [RFC2451] 158 SHOULD AES-CTR [RFC3686] 159 SHOULD NOT DES-CBC [RFC2405] (2) 161 Requirement Authentication Algorithm (notes) 162 ----------- ----------------------------- 163 MUST HMAC-SHA1-96 [RFC2404] (3) 164 SHOULD+ AES-XCBC-MAC-96 [RFC3566] 165 MAY NULL (1) 166 MAY HMAC-MD5-96 [RFC2403] (4) 168 Notes: 170 (1) Since ESP encryption is optional, support for the "NULL" 171 algorithm is required to maintain consistency with the way 172 services are negotiated. Note that while authentication and 173 encryption can each be "NULL", they MUST NOT both be "NULL" 174 [RFC4301]. 176 (2) DES, with its small key size and publicly demonstrated and 177 open-design special-purpose cracking hardware, is of questionable 178 security for general use. 180 (3) Weaknesses have become apparent in SHA-1 [SHA1-COLL]; however, 181 these should not affect the use of SHA1 with HMAC. 183 (4) Weaknesses have become apparent in MD5 [MD5-COLL]; however, 184 these should not affect the use of MD5 with HMAC. 186 3.1.2. ESP Combined Mode Algorithms 188 As specified in [RFC4303], combined mode algorithms are supported 189 that provide both confidentiality and authentication services. 190 Support of such algorithms will require proper structuring of ESP 191 implementations. Under many circumstances, combined mode algorithms 192 provide significant efficiency and throughput advantages. Although 193 there are no suggested or required combined algorithms at this time, 194 AES-CCM [RFC4309] and AES-GCM [RFC4106] are of interest. AES-CCM has 195 been adopted as the preferred mode in IEEE 802.11 [802.11i], and AES- 196 GCM has been adopted as the preferred mode in IEEE 802.1ae [802.1ae]. 198 3.2. Authentication Header 200 The implementation conformance requirements for security algorithms 201 for AH are given below. See Section 2 for definitions of the values 202 in the "Requirement" column. As you would suspect, all of these 203 algorithms are authentication algorithms. 205 Requirement Algorithm (notes) 206 ----------- ---------------- 207 MUST HMAC-SHA1-96 [RFC2404] (1) 208 SHOULD+ AES-XCBC-MAC-96 [RFC3566] 209 MAY HMAC-MD5-96 [RFC2403] (2) 211 Note: 213 (1) Weaknesses have become apparent in SHA-1 [SHA1-COLL]; however, 214 these should not affect the use of SHA1 with HMAC. 216 (2) Weaknesses have become apparent in MD5 [MD5-COLL]; however, 217 these should not affect the use of MD5 with HMAC. 219 4. Security Considerations 221 The security of cryptography-based systems depends on both the 222 strength of the cryptographic algorithms chosen and the strength of 223 the keys used with those algorithms. The security also depends on 224 the engineering and administration of the protocol used by the system 225 to ensure that there are no non-cryptographic ways to bypass the 226 security of the overall system. 228 This document concerns itself with the selection of cryptographic 229 algorithms for the use of ESP and AH, specifically with the selection 230 of mandatory-to-implement algorithms. The algorithms identified in 231 this document as "MUST implement" or "SHOULD implement" are not known 232 to be broken at the current time, and cryptographic research so far 233 leads us to believe that they will likely remain secure into the 234 foreseeable future. However, this is not necessarily forever. We 235 would therefore expect that new revisions of this document will be 236 issued from time to time that reflect the current best practice in 237 this area. 239 5. IANA Considerations 241 No new IANA considerations are introduced in this RFC. 243 6. Acknowledgements 245 Much of the wording herein was adapted from RFC4305, the parent 246 document of this document. RFC4305 itself borrows text from 247 [RFC4307], "Cryptographic Algorithms for Use in the Internet Key 248 Exchange Version 2", by Jeffrey I. Schiller. 250 Thanks to the following people for reporting or responding to reports 251 of the errors in RFC4305: Paul Hoffman, Stephen Kent, Paul Koning and 252 Lars Volker. Helpful Last-Call comments were received from Russ 253 Housley, Elwyn Davies, Nicolas Williams and Alfred Hoenes. 255 7. Changes from RFC 2402 and RFC2406 to RFC4305 257 [RFC2402] and [RFC2406] defined the IPsec Authentication Header and 258 IPsec Encapsulating Security Payload. Each specified the 259 implementation requirements for cryptographic algorithms for their 260 respective protocols. They have now been replaced with [RFC4302] and 261 [RFC4303], which do not specify cryptographic algorithm 262 implementation requirements, and this document, which specifies such 263 requirements for both [RFC4302] and [RFC4303]. 265 The implementation requirements are compared below: 267 Old Old New 268 Req. RFC(s) Requirement Algorithm (notes) 269 ---- ------ ----------- ----------------- 270 MUST 2406 SHOULD NOT DES-CBC [RFC2405] (1) 271 MUST 2402 2406 MAY HMAC-MD5-96 [RFC2403] 272 MUST 2402 2406 MUST HMAC-SHA1-96 [RFC2404] 274 Note: 276 (1) The IETF deprecated the use of single DES years ago and has 277 not included it in any new standard for some time (see IESG note 278 on the first page of [RFC2407]). [RFC4305] represented the first 279 standards-track recognition of that deprecation by specifying that 280 implementations SHOULD NOT provide single DES. The US Government 281 National Institute of Standards and Technology (NIST) has formally 282 recognized the weakness of single DES by a notice published [DES- 283 WDRAW] proposing to withdraw it as a US Government Standard. 284 Triple DES remains approved by both the IETF and NIST. 286 8. Changes from RFC4305 288 This document obsoletes [RFC4305]. The document incorporates changes 289 for the support for the NULL Authentication Algorithm making the 290 support from a MUST to a MAY. This change is made to make this 291 document consistent with [RFC4301]. Text for SHA-1 collision attacks 292 as well as the future use of AES-GCM and AES-CCM is added. 294 The changed implementation requirement resulting from the above 295 changes is listed below: 297 Old Old New 298 Req. RFC(s) Requirement Algorithm (notes) 299 ---- ------ ----------- ----------------- 300 MUST 2406 MAY NULL Authentication 301 MUST 2406 MUST NULL Encryption 302 SHOULD+ 4305 MUST AES-CBC Encryption 304 9. References 306 9.1. Normative References 308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels", BCP14, RFC2119, March 1997. 311 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 312 ESP and AH", RFC 2403, November 1998. 314 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 315 ESP and AH", RFC 2404, November 1998. 317 [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 318 Algorithm With Explicit IV", RFC 2405, November 1998. 320 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 321 Its Use With IPsec", RFC 2410, November 1998. 323 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 324 Algorithms", RFC 2451, November 1998. 326 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 327 and Its Use With IPsec", RFC 3566, September 2003. 329 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 330 Algorithm and Its Use with IPsec", RFC 3602, 331 September 2003. 333 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 334 Counter Mode With IPsec Encapsulating Security Payload 335 (ESP)", RFC 3686, January 2004. 337 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 338 Internet Protocol", RFC 4301, December 2005. 340 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 341 December 2005. 343 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 344 RFC 4303, December 2005. 346 [RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation 347 Requirements for Encapsulating Security Payload (ESP) and 348 Authentication Header (AH)", RFC 4305, December 2005. 350 9.2. Informative References 352 [802.11i] "LAN/MAN Specific Requirements Part 11: Wireless Medium 353 Access Control (MAC) and physical layer (PHY) 354 specifications", IEEE Standard Medium Access Control (MAC) 355 Security, IEEE Std 802.11i, June 2004. 357 [802.1ae] "Media Access Control (MAC) Security", IEEE 358 Standard Medium Access Control (MAC) Security, IEEE Std 359 802.1ae, June 2006. 361 [DES-WDRAW] 362 "Announcing Proposed Withdrawal of Federal Information 363 Processing Standard (FIPS) for the Data Encryption 364 Standard (DES) and Request for Comments", FIPS 365 Notice Docket No. 040602169-4169-01, July 2004. 367 [MD5-COLL] 368 Klima, V., "Finding MD5 Collisions - a Toy For a 369 Notebook", Cryptology ePrint Archive Medium Report 2005/ 370 075, March 2005. 372 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", 373 RFC 2402, November 1998. 375 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 376 Payload (ESP)", RFC 2406, November 1998. 378 [RFC2407] Piper, D., "The Internet IP Security Domain of 379 Interpretation for ISAKMP", RFC 2407, November 1998. 381 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 382 (IKE)", RFC 2409, November 1998. 384 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 385 (GCM) in IPsec Encapsulating Security Payload (ESP)", 386 RFC 4106, June 2005. 388 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 389 RFC 4306, December 2005. 391 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 392 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 393 December 2005. 395 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 396 Mode with IPsec Encapsulating Security Payload (ESP)", 397 RFC 4309, December 2005. 399 [SHA1-COLL] 400 Rijmen, V. and E. Oswald, "Update on SHA-1", Cryptology 401 ePrint Archive Report 2005/010, January 2005. 403 Author's Address 405 Vishwas Manral 406 IP Infusion 407 #41 Ground Floor, 5th Cross Road, 8th Main Road, Vasanth Nagar 408 Bangalore, Karnataka 560052 409 India 411 Phone: +1-408-794-1580 412 Email: vishwas@ipinfusion.com 414 Full Copyright Statement 416 Copyright (C) The IETF Trust (2007). 418 This document is subject to the rights, licenses and restrictions 419 contained in BCP 78, and except as set forth therein, the authors 420 retain all their rights. 422 This document and the information contained herein are provided on an 423 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 424 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 425 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 426 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 427 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 428 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 430 Intellectual Property 432 The IETF takes no position regarding the validity or scope of any 433 Intellectual Property Rights or other rights that might be claimed to 434 pertain to the implementation or use of the technology described in 435 this document or the extent to which any license under such rights 436 might or might not be available; nor does it represent that it has 437 made any independent effort to identify any such rights. Information 438 on the procedures with respect to rights in RFC documents can be 439 found in BCP 78 and BCP 79. 441 Copies of IPR disclosures made to the IETF Secretariat and any 442 assurances of licenses to be made available, or the result of an 443 attempt made to obtain a general license or permission for the use of 444 such proprietary rights by implementers or users of this 445 specification can be obtained from the IETF on-line IPR repository at 446 http://www.ietf.org/ipr. 448 The IETF invites any interested party to bring to its attention any 449 copyrights, patents or patent applications, or other proprietary 450 rights that may cover technology that may be required to implement 451 this standard. Please address the information to the IETF at 452 ietf-ipr@ietf.org. 454 Acknowledgment 456 Funding for the RFC Editor function is provided by the IETF 457 Administrative Support Activity (IASA).