idnits 2.17.1 draft-ietf-ipsec-doc-roadmap-01.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. Expected boilerplate is as follows today (2024-04-20) 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 21 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 351: '...hm documents. The reader SHOULD follow...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 1997) is 9776 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ISAKMP' is mentioned on line 139, but not defined == Missing Reference: 'Oakley' is mentioned on line 139, but not defined == Missing Reference: 'Resolution' is mentioned on line 139, but not defined == Unused Reference: 'HMAC' is defined on line 414, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1825 (ref. 'Arch') (Obsoleted by RFC 2401) == Outdated reference: A later version (-01) exists of draft-ietf-ipsec-ciph-des-expiv-00 == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-auth-header-01 == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-esp-v2-00 -- No information found for draft-ietf-ipsec-hmac-md5-96 - is the name correct? == Outdated reference: A later version (-02) exists of draft-ietf-ipsec-auth-hmac-sha196-00 ** Obsolete normative reference: RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Thayer 2 Internet Draft N. Doraswamy 3 Category: Informational R. Glenn 4 Expire in six months July 1997 6 IP Security 7 Document Roadmap 8 10 Status of This Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 This memo provides information for the Internet community. This memo 29 does not specify an Internet standard. Distribution of this memo is 30 unlimited. 32 Abstract 34 The IPsec protocol suite is used to provide privacy and 35 authentication services at the IP layer. Several documents are used 36 to describe this protocol suite. The interrelationship and 37 organization of the various documents covering the IPsec protocol are 38 discussed here. An explanation of what to find in which document, 39 and what to include in new Encryption Algorithm and Authentication 40 Algorithm documents are described. 42 Contents 44 Status of This Memo .................................................1 46 Abstract ............................................................1 48 Contents ............................................................2 50 1. Introduction .....................................................3 52 2. Interrelationship of IPsec Documents .............................3 54 3. Keying Material ..................................................5 56 4. Recommended Content of Algorithm Documents .......................6 58 4.1 Encryption and Authentication Algorithms ........................6 59 4.2 Encryption Algorithms ...........................................7 60 4.3 Authentication Algorithms .......................................8 62 5. Security Considerations ..........................................8 64 6. Acknowledgments ..................................................9 66 7. References .......................................................9 68 8. Author's Addresses ..............................................10 70 1. Introduction 72 This document is intended to provide guidelines for the development 73 of collateral specifications describing the use of new encryption and 74 authentication algorithms with the ESP protocol, described in [ESP] 75 and new authentication algorithms used with the AH protocol, 76 described in [AH]. ESP and AH are part of the IP Security 77 architecture described in [Arch]. There is a requirement for a well- 78 known procedure that can be used to add new encryption algorithms or 79 authentication algorithms to ESP and AH, not only while the initial 80 document set is undergoing development but after the base documents 81 have achieved RFC status. Following the guidelines discussed below 82 simplifies adding new algorithms and reduces that amount of redundant 83 documentation. 85 The goal in writing a new Encryption Algorithm or Authentication 86 Algorithm document is to concentrate on the application of the 87 specific algorithm within ESP and AH. General ESP and AH concepts, 88 definitions, and issues are covered in the ESP and AH documents. The 89 algorithms themselves are not described in these documents. This 90 gives us the capability to add new algorithms and also specify how 91 any given algorithm might interact with other algorithms. The intent 92 is to achieve the goal of avoiding duplication of information and 93 excessive numbers of documents, the so-called "draft explosion" 94 effect. 96 2. Interrelationship of IPsec Documents 98 The documents describing the set of IPsec protocols are divided into 99 seven groups. This is illustrated in Figure 1. There is a main 100 Architecture document which broadly covers the general concepts, 101 security requirements, definitions, and mechanisms defining IPsec 102 technology. 104 There is an ESP Protocol document and an AH Protocol document which 105 covers the packet format and general issues regarding the respective 106 protocols. These protocol documents also contain default values if 107 appropriate, such as the default padding contents, and mandatory to 108 implement algorithms. These documents dictate some of the values in 109 the Domain Of Interpretation document [DOI]. Note the DOI document 110 is itself part of the IANA Assigned Numbers mechanism and so the 111 values described in the DOI are well-known. See [DOI] for more 112 information on the mechanism. 114 The "Encryption Algorithm" document set, shown on the left, is the 115 set of documents describing how various encryption algorithms are 116 used for ESP. These documents are intended to fit in this roadmap, 117 and should avoid overlap with the ESP protocol document and with the 118 Authentication Algorithm documents. Examples of this document are 119 the [DES-1829], [DES-Detroit], [3DES], or [CAST] documents. When 120 these or other encryption algorithms are used for ESP, the DOI 121 document has to indicate certain values, such as an encryption 122 algorithm identifier, so these documents provide input to the DOI. 124 The "Authentication Algorithm" document set, shown on the right, is 125 the set of documents describing how various authentication algorithms 126 are used for both ESP and AH. These documents are intended to fit in 127 this roadmap, and should avoid overlap with the AH protocol document 128 and with the Encryption Algorithm documents. Examples of this 129 document are the [HMAC-MD5], and [HMAC-SHA-1] documents. When these 130 or other algorithms are used for either ESP or AH, the DOI document 131 has to indicate certain values, such as algorithm type, so these 132 documents provide input to the DOI. 134 The "Key Management Documents", shown at the bottom, are the 135 documents describing the IETF standards-track key management schemes. 136 These documents provide certain values for the DOI also. Note that 137 issues of key management should be indicated here and not in, for 138 example, the ESP and AH protocol documents. Currently this box 139 represents [ISAKMP], [Oakley], and [Resolution]. 141 The DOI document, shown in the middle, contains values needed for the 142 other documents to relate to each other. This includes for example 143 encryption algorithms, authentication algorithms, and operational 144 parameters such as key lifetimes. 146 +--------------+ 147 | Architecture | 148 +--------------+ 149 v v 150 +<-<-<-<-+ +->->->->+ 151 v v 152 +----------+ +----------+ 153 | ESP | | AH | 154 | Protocol | | Protocol | 155 +----------+ +----------+ 156 v v v v 157 v +->->->->->->->->+ v v 158 v v v v v 159 v v v v v 160 v +------------+ +----------------+ v 161 v | +------------+ | +----------------+ v 162 v | | Encryption | | | Authentication | v 163 v +-| Algorithm | +-| Algorithm | v 164 v +------------+ +----------------+ v 165 v v v v 166 v v +-----+ v v 167 +>->->->-+->->->->| DOI |<-<-<-<-+-<-<-<-<-+ 168 +-----+ 169 ^ 170 ^ 171 +------------+ 172 | KEY | 173 | MANAGEMENT | 174 +------------+ 176 Figure 1. IPsec Document Roadmap. 178 3. Keying Material 180 Describing the encryption and authentication algorithms in different 181 documents raises the issue of how the key management protocols knows 182 the required keying material length for the desired algorithms when 183 used together with ESP. It also raises the issue of how to divide 184 the keying material. This is known as the "slicing and dicing" 185 information. 187 Each Encryption Algorithm and Authentication Algorithm document 188 should specify their respective key lengths. The key management pro- 189 tocols should use the length of the keys specified in the respective 190 Algorithm documents to generate the keying material of required 191 length. 193 The key management protocol generates keying material with enough 194 strength and size to generate keys for individual algorithms. The ESP 195 protocol document is responsible for specifying how the keys are 196 extracted from the keying material (sliced and diced). The Encryption 197 Algorithm and Authentication Algorithm documents are responsible for 198 specifying the key sizes and strengths for each algorithm. However, 199 whether the entire keying material is passed down to the kernel to 200 perform slicing and dicing or if the keys are sliced and diced by key 201 management protocol is an implementation issue. The AH protocol docu- 202 ment has no such requirement. 204 4. Recommended Content of Algorithm Documents 206 The document describing how a specific encryption or authentication 207 algorithm is used should contain information appropriate to that 208 encryption or authentication algorithm. This section enumerates what 209 information should be provided. It is the intention of the document 210 roadmap that: 212 . General protocol information goes in the respective ESP or AH protocol 213 documents. 214 . Key management information goes in the key management documents. 215 . Assigned values and constants go in the DOI document. 217 Encryption and authentication algorithms require some set of optional 218 parameters or have optional modes of operation (e.g. IVs, authentica- 219 tion data lengths, and key lengths). To help eliminate some complex- 220 ity involved with key management having to negotiate large numbers of 221 algorithm-specific parameters, encryption and authentication algorithm 222 documents will select fixed values for these parameters when it is 223 deemed technically reasonable and feasible. 225 Note, the following information is intended as a general guideline 226 only. 228 4.1 Encryption and Authentication Algorithms 230 This section describes the information that should be included in 231 both Encryption Algorithm and Authentication Algorithm documents. 233 Keying Material 234 . Size of keys, including minimum, maximum, recommended and/or 235 required sizes. Note: the security considerations section should 236 address any weakness in specific sizes. 237 . Recommended or required pseudo-random number generator techniques 238 and attributes to provide sufficiently strong keys. [RANDOM] 239 provides recommendations on generating strong randomness for use 240 with security. 241 . Format of keying material. 242 . Known weak keys or references to documentation on known weak keys. 243 . Recommended or required processing of input keying material such as 244 parity generation or checking. 245 . Requirements and/or recommendations on how often the keying 246 material should be refreshed. 248 Performance Considerations 249 . Any available estimates on performance of this algorithm. 250 . Any available comparison data (e.g., compared against DES or 251 MD5). 252 . Input size or other considerations that could improve or degrade 253 performance. 255 ESP Environmental Considerations 256 . Any known issues regarding interactions between this algorithm and 257 other aspects of ESP, such as use of certain authentication 258 schemes. Note: As new encryption and authentication algorithms are 259 applied to ESP, the later documents will be required to address 260 interactions with previously specified algorithms. 262 Payload Content and Format Description 263 . Specification of size, placement, and content of algorithm-specific 264 fields not defined in the ESP or AH protocol documents (e.g., IV). 266 Security Considerations 267 . Discuss any known attacks. 268 . Discuss any known common implementation pitfalls, such as use of 269 weak random number generators. 270 . Discuss any relevant validation procedures, such as test vectors. 272 4.2 Encryption Algorithms 274 This section describes the information that should be included in the 275 Encryption Algorithm documents. 277 Encryption Algorithm Description 278 . General information how this encryption algorithm is to be used in 279 ESP. 280 . Description of background material and formal algorithm 281 description. 282 . Features of this encryption algorithm to be used by ESP, including encryption 283 and/or authentication. 284 . Mention of any availability issues such as Intellectual Property 285 considerations. 286 . References, in IETF style, to background material such as FIPS 287 documents. 289 Algorithm Modes of Operation 290 . Description of how the algorithm is operated, whether it is block 291 mode or streaming mode or other. 292 . Requirements for input or output block format. 293 . Padding requirements of this algorithm. Note: there is a default 294 for padding, specified in the base ESP document, so this is only 295 needed if the default cannot be used. 296 . Any algorithm-specific operating parameters, such as number of 297 rounds. 298 . Identify optional parameters and optional methods of operation and 299 pick reasonable fixed values and methods with explicit technical 300 explanations. 301 . Identify those optional parameters in which values and methods 302 should remain optional with explicit technical explanations on why 303 fixed values and methods should not be used. 304 . Defaults and mandatory ranges on algorithm-specific optional 305 parameters that could not be fixed. 307 4.3 Authentication Algorithms 309 This section describes the information that should be included in the 310 Authentication Algorithm documents. In most cases, an authentication 311 algorithm will operate the same whether it is used for ESP or AH. 312 This should be represented in a single Authentication Algorithm docu- 313 ment. 315 Authentication Algorithm Description 316 . General information on how this authentication algorithm is to be 317 used with ESP and AH. 318 . Description of background material and formal algorithm 319 description. 320 . Features of this authentication algorithm. 321 . Mention of any availability issues such as Intellectual Property 322 considerations. 323 . References, in IETF style, to background material such as 324 FIPS documents and definitive descriptions of underlying 325 algorithms. 327 Algorithm Modes of Operation 328 . Description of how the algorithm is operated. 329 . Algorithm-specific operating parameters, such as number of 330 rounds, and input or output block format. 331 . Implicit and explicit padding requirements of this algorithm. Note: 332 There is a default method for padding of the authentication data field 333 specified in the AH protocol document. This is only needed if the 334 default cannot be used. 335 . Identify optional parameters and optional methods of operation and 336 pick reasonable fixed values and methods with explicit technical 337 explanations. 338 . Identify those optional parameters in which values and methods 339 should remain optional with explicit technical explanations on why 340 fixed values and methods should not be used. 341 . Defaults and mandatory ranges on algorithm-specific optional 342 parameters that could not be fixed. 343 . Authentication data comparison criteria for this algorithm. Note: 344 There is a default method for verifying the authentication data 345 specified in the AH protocol document. This is only needed if the 346 default cannot be used (e.g. when using a signed hash). 348 5. Security Considerations 350 This document provides a roadmap and guidelines for writing Encryp- 351 tion and Authentication Algorithm documents. The reader SHOULD follow 352 all the security procedures and guidelines described in the IPsec 353 Architecture, ESP Protocol, AH Protocol, Encryption Algorithm, and 354 Authentication Algorithm documents. Note that many encryption algo- 355 rithms are not considered secure if they are not used with some sort 356 of authentication mechanism. 358 6. Acknowledgments 360 Several Internet drafts were referenced in writing this document. 361 Depending on where the documents are on (or off) the IETF standards 362 track these may not be available through the IETF RFC repositories. 363 In certain cases the reader may want to know what version of these 364 documents were referenced. These documents are: 366 . ARCH: draft-ietf-ipsec-arch-sec-01.txt. 367 . DES-Detroit: this is the ANX Workshop style of ESP, based on the 368 Hughes draft as modified by Cheryl Madson and published on the ANX 369 mailing list. 370 . DOI: draft-ietf-ipsec-ipsec-doi-02.txt. 371 . 3DES: this is . 372 . CAST: this is draft-ietf-ipsec-esp-cast-128-cbc-00.txt, as revised 373 to relate to this document. 374 . ESP: draft-ietf-ipsec-esp-04.txt, mailed to the IETF mailing list 375 in May/June 1997. 376 . AH: draft-ietf-ipsec-auth-05.txt, mailed to the IETF mailing list 377 in May/June 1997. 378 . HUGHES: this is draft-ietf-ipsec-esp-des-md5-03.txt 379 . ISAKMP: There are three documents describing ISAKMP. These are 380 draft-ietf-ipsec-isakmp-07.txt, draft-ietf-ipsec-isakmp-oakley- 381 03.txt, and draft-ietf-ipsec-ipsec-doi-02.txt. 383 7. References 385 [3DES] Doraswamy, N., Metzger, P., Simpson, W.A., "The ESP 386 Triple DES Transform", 387 draft-ietf-ipsec-ciph-des3-00.txt, July 1997. 389 [Arch] Atkinson, R., "Security Architecture for the Internet 390 Protocol", RFC-1825, Naval Research Laboratory, 391 July 1995. 393 [CAST] Pereira, R., Carter, G., "The ESP CAST128-CBC 394 Algorithm", draft-ietf-ipsec-ciph-cast128-cbc-00.txt, 395 July 1997. 397 [DES-Detroit] Madson, C., "The ESP DES-CBC Cipher Algorithm With 398 Explicit IV", draft-ietf-ipsec-ciph-des-expiv-00.txt, 399 July 1997. 401 [DES-1829] Metzger, P., Simpson, W.A., "The ESP DES-CBC 402 Transform", draft-ietf-ipsec-ciph-des-derived-00.txt, 403 July 1997. 405 [DOI] IP Security Domain of Interpretation, RFC-xxxx. 407 [AH] Kent, S., Atkinson, R., "IP Authentication Header", 408 draft-ietf-ipsec-auth-header-01.txt, July 1997. 410 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security 411 Payload (ESP)", draft-ietf-ipsec-esp-v2-00.txt, 412 July 1997. 414 [HMAC] Krawczyk, K., Bellare, M., and Canetti R., "HMAC: 415 Keyed-Hashing for Message Authentication", RFC-2104, 416 February 1997. 418 [HMAC-MD5] Madson, C., Glenn, R., "The Use of HMAC-MD5 within ESP 419 and AH", draft-ietf-ipsec-hmac-md5-96-00.txt, 420 July 1997. 422 [HMAC-SHA-1] Madson, C., Glenn, R., "The Use of HMAC-SHA-1 within 423 ESP and AH", draft-ietf-ipsec-auth-hmac-sha196-00.txt, 424 July 1997. 426 [RANDOM] Eastlake, D., Crocker, S., Schiller, J., "Randomness 427 Recommendations for Security", RFC-1750, 428 December 1994. 430 8. Author's Addresses 432 Rodney Thayer 433 Sable Technology Corporation 434 246 Walnut Street 435 Newton, Massachusetts 02160 436 438 Naganand Doraswamy 439 Bay Networks 440 e-mail: naganand@baynetworks.com 442 Rob Glenn 443 NIST 444 e-mail: rob.glenn@nist.gov