idnits 2.17.1 draft-ietf-ipsec-esp-ah-algorithms-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 348 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (August 2004) is 7194 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: 'RFC 2451' is mentioned on line 162, but not defined == Missing Reference: 'CCM' is mentioned on line 195, but not defined == Unused Reference: 'AES CCM' is defined on line 314, but no explicit reference was found in the text == Unused Reference: 'RFC 791' is defined on line 321, but no explicit reference was found in the text -- No information found for draft-ietf-ipsec-rfc2402bis- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'AH' -- No information found for draft-ietf-ipsec-esp-v3- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ESP' -- No information found for draft-ietf-ipsec-rfc2401bis- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IPsec' -- No information found for draft-ietf-ipsec-ikev2- - is the name correct? -- 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) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake 3rd 2 Obsoletes RFCs 2402 and 2406 Motorola Laboratories 3 Expires: February 2005 August 2004 5 Cryptographic Algorithm Implementation Requirements For ESP And AH 6 ------------- --------- -------------- ------------ --- --- --- -- 7 9 Status of This Document 11 Distribution of this draft is unlimited. Comments should be sent to 12 the authors. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than a "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Copyright (C) The Internet Society (2004). All Rights Reserved. 32 Abstract 34 The IPsec series of protocols makes use of various cryptographic 35 algorithms in order to provide security services. The Encapsulating 36 Security Payload (ESP) and the Authentication Header (AH) provide two 37 mechanisms for protecting data being sent over an IPsec Security 38 Association (SA). To ensure interoperability between disparate 39 implementations it is necessary to specify a set of mandatory-to- 40 implement algorithms to ensure at least one algorithm that all 41 implementations will have available. This document defines the 42 current set of mandatory-to-implement algorithms for ESP and AH as 43 well as specifying algorithms that should be implemented because they 44 may be promoted to mandatory at some future time. 46 Acknowledgement 48 Much of the wording herein was adapted from "Cryptographic Algorithms 49 for use in the Internet Key Exchange Version 2" by Jeffrey I. Schiller. 52 Table of Contents 54 Status of This Document....................................1 55 Abstract...................................................1 57 Acknowledgement............................................2 58 Table of Contents..........................................2 60 1. Introduction............................................3 61 2. Requirements Terminology................................3 62 3. Algorithm Selection.....................................4 63 3.1 Encapsulating Security Payload.........................4 64 3.1.1 ESP Encryption and Authentication Algorithms.........4 65 3.1.2 ESP Combined Mode Algorithms.........................5 66 3.2 Authentication Header..................................5 67 4. Security Considerations.................................6 68 5. IANA Considerations.....................................6 69 6. Changes from RFC 2402 and 2406..........................6 71 Normative References.......................................8 72 Informative References.....................................8 74 Authors Address...........................................10 76 Full Copyright Statement..................................11 77 Expiration and File Name..................................11 79 1. Introduction 81 The Encapsulating Security Payload (ESP) and the Authentication 82 Header (AH) provide two mechanisms for protecting data being sent 83 over an IPsec Security Association (SA) [IPsec, ESP, AH]. To ensure 84 interoperability between disparate implementations it is necessary to 85 specify a set of mandatory-to-implement algorithms to ensure at least 86 one algorithm that all implementations will have available. This 87 document defines the current set of mandatory-to-implement algorithms 88 for ESP and AH as well as specifying algorithms that should be 89 implemented because they may be promoted to mandatory at some future 90 time. 92 The nature of cryptography is that new algorithms surface 93 continuously and existing algorithms are continuously attacked. An 94 algorithm believed to be strong today may be demonstrated to be weak 95 tomorrow. Given this, the choice of mandatory-to-implement algorithm 96 should be conservative so as to minimize the likelihood of it being 97 compromised quickly. Thought should also be given to performance 98 considerations as many uses of IPsec will be in environments where 99 performance is a concern. 101 Finally we need to recognize that the mandatory-to-implement 102 algorithm(s) may need to change over time to adapt to the changing 103 world. For this reason the selection of mandatory-to-implement 104 algorithms is not included the main IPsec, ESP, or AH specifications. 105 It is instead placed in this document. As the choice of algorithm 106 changes, only this document should need to be updated. 108 Ideally the mandatory-to-implement algorithm of tomorrow should 109 already be available in most implementations of IPsec by the time it 110 is made mandatory. To facilitate this we will attempt to identify 111 such algorithms as they are known today in this document. There is no 112 guarantee that the algorithms we believe today may be mandatory in 113 the future will in fact become so. All algorithms known today are 114 subject to cryptographic attack, and may be broken in the future. 116 2. Requirements Terminology 118 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 119 "MAY" that appear in this document are to be interpreted as described 120 in [RFC 2119]. 122 In addition we will define some additional terms here: 124 SHOULD+ This term means the same as SHOULD. However it is likely 125 that an algorithm marked as SHOULD+ will be promoted at 126 some future time to be a MUST. 128 SHOULD- This terms means the same as SHOULD. However it is likely 129 that an algorithm marked as SHOULD- will be deprecated to 130 a MAY or worse in a future version of this document. 131 MUST- This term means the same as MUST. However we expect at 132 some point in the future this algorithm will no longer be 133 a MUST. 135 3. Algorithm Selection 137 For IPsec implementations to interoperate, they must support one or 138 more security algorithms in common. This section specifies the 139 security algorithm implementation requirements for standards 140 comformant ESP and AH implementations. The security algorithms 141 actually used for any particular ESP or AH security association is 142 determined by a negotiation mechahism, such as the Internet Key 143 Exchange (IKE [RFC 2409, IKEv2]), or pre-establishment. 145 Of course, additional standard and proprietary algorithms beyond 146 those listed below can be implemented. 148 3.1 Encapsulating Security Payload 150 The implementation conformance requirements for security algorithms 151 for ESP are given in the tables below. See section 2 for definitions 152 of the values in the "Requirement" column. 154 3.1.1 ESP Encryption and Authentication Algorithms 156 These tables list encryption and authentication algorithms for the 157 IPsec Encapsulating Security Payload protocol. 159 Requirement Encryption Algorithm (notes) 160 ----------- -------------------- 161 MUST NULL (1) 162 MUST- TripleDES-CBC [RFC 2451] 163 SHOULD+ AES-CBC with 128-bit keys [RFC 3602] 164 SHOULD AES-CTR [RFC 3686] 165 SHOULD NOT DES-CBC [RFC 2405] (3) 167 Requirement Authentication Algorithm (notes) 168 ----------- ------------------------ 169 MUST HMAC-SHA1-96 [RFC 2404] 170 MUST NULL (1) 171 SHOULD+ AES-XCBC-MAC-96 [RFC 3566] 172 MAY HMAC-MD5-96 [RFC 2403] (2) 174 Notes: 176 1. Since ESP encryption and authentication are optional, support for 177 the two "NULL" algorithms is required to maintain consistency with 178 the way these services are negotiated. NOTE that while 179 authentication and encryption can each be "NULL", they MUST NOT 180 both be "NULL". 181 2. Weaknesses have become apparent in MD5, however these should not 182 effect the use of MD5 with HMAC. 183 3. DES, with its small key size and publicly demonstrated and open 184 design special purpose cracking hardware, is of questionable 185 security for general use. 187 3.1.2 ESP Combined Mode Algorithms 189 As specified in [ESP], combined mode algorithms are supported which 190 provide both confidentiality and authentication services. Support of 191 such algorithms will require proper structuring of ESP 192 implementations. Under many circumstances, combined mode algorithms 193 provide significant efficiency and throughput advantages. Although 194 there are no suggested or required combined algorithms at this time, 195 AES-CCM [CCM], which has been adopted as the prefered mode for 196 security in IEEE 802.11 [802.11i], is expected to be of interest in 197 the near future. 199 3.2 Authentication Header 201 The implementation conformance requirements for security algorithms 202 for AH are given below. See section 2 for definitions of the values 203 in the "Requirement" column. As you would suspect, all of these 204 algorithms are authentication algorithms. 206 Requirement Algorithm (notes) 207 ----------- --------- 208 MUST HMAC-SHA1-96 [RFC 2404] 209 SHOULD+ AES-XCBC-MAC-96 [RFC 3566] 210 MAY HMAC-MD5-96 [RFC 2403] (1) 212 Notes: 214 1. Weaknesses have become apparent in MD5, however these should not 215 effect the use of MD5 with HMAC. 217 4. Security Considerations 219 The security of cryptographic based systems depends on both the 220 strength of the cryptographic algorithms chosen, the strength of the 221 keys used with those algorithms and the engineering and 222 administration of the protocol used by the system to ensure that 223 there are no non-cryptographic ways to bypass the security of the 224 overall system. 226 This document concerns itself with the selection of cryptographic 227 algorithms for the use of ESP and AH, specifically with the selection 228 of "Mandatory-to-Implement" algorithms. The algorithms identified in 229 this document as MUST implement or SHOULD implement are not known to 230 be broken at the current time and cryptographic research so far leads 231 us to believe that they will likely remain secure into the 232 foreseeable future. However, this is not necessarily forever. We 233 would therefore expect that new revisions of this document will be 234 issued from time to time that reflect the current best practice in 235 this area. 237 5. IANA Considerations 239 This document does not define any new registries nor elements in 240 existing registries. 242 6. Changes from RFC 2402 and 2406 244 [RFC 2402] and [RFC 2406] defined the IPsec Authentication Header and 245 IPsec Encapsulating Security Payload. Each specified the 246 implementation requirements for cryptogrpahic algorithms for their 247 respectively protocols. They have now been replaced with [AH] and 248 [ESP], which do not specify cryptographic algorithm implementation 249 requirements, and this document which specifies such requirements for 250 both [AH] and [ESP]. 252 The implementation requirements are compared below: 254 Old Old New 255 Req. RFC(s) Requirement Algorithm (notes) 256 --- ------ ----------- --------- 257 MUST 2406 SHOULD NOT DES-CBC [RFC 2405] (1) 258 MUST 2402 2406 MAY HMAC-MD5-96 [RFC 2403] 259 MUST 2402 2406 MUST HMAC-SHA1-96 [RFC 2404] 261 Notes: 262 1. The IETF deprecated the use of single DES years ago and has not 263 included it in any new standard for some time (see IESG note on 264 the first page of [RFC 2407]). But this document represents the 265 first standards track recognition of that deprecation by 266 specifying that implementations SHOULD NOT provide single DES. The 267 US Government National Institute of Standards and Technology 268 (NIST) has formally recognized the weakness of single DES by a 269 notice published in the 26 July 2004 US Government Federal 270 Register (Docket No. 040602169-4169-01) proposing to withdraw it 271 as a US Government Standard. Triple DES remains approved by both 272 the IETF and NIST. 274 Normative References 276 [AH] - "IP Authentication Header", draft-ietf-ipsec-rfc2402bis-*.txt, 277 S. Kent, work in progress. 279 [ESP] - "IP Encapsulating Security Payload (ESP)", draft-ietf-ipsec- 280 esp-v3-*.txt, S. Kent, work in progress. 282 [IPsec] - "Security Architecture for the Internet Protocol", draft- 283 ietf-ipsec-rfc2401bis-*.txt, S. Kent, work in progress. 285 [RFC 2119] - "Key words for use in RFCs to Indicate Requirement 286 Levels", S. Bradner, March 1997. 288 [RFC 2403] - "The Use of HMAC-MD5-96 within ESP and AH", C. Madson, 289 and R. Glenn, November 1998. 291 [RFC 2404] - "The Use of HMAC-SHA-1-96 within ESP and AH", C. Madson, 292 and R. Glenn, November 1998. 294 [RFC 2405] - "The ESP DES-CBC Cipher Algorithm With Explicit IV", C. 295 Madson, and N. Doraswamy, November 1998. 297 [RFC 3566] - "The AES-XCBC-MAC-96 Algorithm and Its Use With IPSec", 298 S. Frankel. H. Herbert, September 2003. 300 [RFC 3602] - "The AES-CBC Cipher Algorithm and Its Use with IPsec", 301 S. Frankel, R. Glenn, S. Kelly, September 2003. 303 [RFC 3686] - "Using Advanced Encryption Standard (AES) Counter Mode 304 With IPsec Encapsulating Security Payload (ESP)", R. Housley, July 305 2003. 307 Informative References 309 [802.11i] - LAN/MAN Specific Requirements - Part 11: Wireless Medium 310 Access Control (MAC) and physical layer (PHY) specifications: Medium 311 Access Control (MAC) Security Enhancements, IEEE Std 802.11i, June 312 2004. 314 [AES CCM] - "Using AES CCM Mode With IPsec ESP", draft-ietf-ipsec- 315 ciph-aes-ccm-05.txt which is in the RFC Editor Queue, R. Housley, 316 November 2003. 318 [IKEv2] - "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec- 319 ikev2-*.txt, C. Kaufman, October 2003. 321 [RFC 791] - "Internet Protocol", J. Postel, September 1981. 323 [RFC 2402] - "IP Authentication Header", S. Kent, R. Atkinson, 324 November 1998. 326 [RFC 2406] - "IP Encapsulating Security Payload (ESP)", S. Kent, R. 327 Atkinson, November 1998. 329 [RFC 2407] - "The Internet IP Security Domain of Interpretation for 330 ISAKMP", D. Piper, november 1998. 332 [RFC 2409] - "The Internet Key Exchange (IKE)", D. Harkins, D. 333 Carrel, November 1998. 335 Authors Address 337 Donald E. Eastlake 3rd 338 Motorola Laboratories 339 155 Beaver Street 340 Milford, MA 01757 USA 342 Telephone: +1-508-786-7554 (w) 343 +1-508-634-2066 (h) 344 EMail: Donald.Eastlake@Motorola.com 346 Full Copyright Statement 348 Copyright (C) The Internet Society (2004). All Rights Reserved. 350 This document is subject to the rights, licenses and restrictions 351 contained in BCP 78 and except as set forth therein, the authors 352 retain all their rights. 354 Expiration and File Name 356 This draft expires February 2005. 358 Its file name is draft-ietf-ipsec-esp-ah-algorithms-02.txt.