idnits 2.17.1 draft-ietf-ipsec-doc-roadmap-00.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-18) 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 19 instances of too long lines in the document, the longest one being 4 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 341: '...ents. The reader SHOULD follow all the...' 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 9774 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'AH' is mentioned on line 77, but not defined == Missing Reference: 'Arch' is mentioned on line 78, but not defined == Missing Reference: 'ISAKMP' is mentioned on line 138, but not defined == Missing Reference: 'Oakley' is mentioned on line 138, but not defined == Missing Reference: 'Resolution' is mentioned on line 138, but not defined == Unused Reference: 'ARCH' is defined on line 378, but no explicit reference was found in the text == Unused Reference: 'HMAC' is defined on line 394, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1825 (ref. 'ARCH') (Obsoleted by RFC 2401) -- No information found for draft-ietf-ipsec-ff-auth-hmac-sha-1 - is the name correct? -- No information found for draft-ietf-ipsec-ff-auth-hmac-sha-1 - is the name correct? -- Duplicate reference: draft-ietf-ipsec-ff-auth-hmac-sha-1, mentioned in 'HMAC-SHA-1', was also mentioned in 'HMAC-MD5'. Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Thayer 3 Internet Draft N. Doraswamy 4 Category: Informational R. Glenn 5 Expire in six months July 1997 7 IP Security 8 Document Roadmap 9 11 Status of This Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 This memo provides information for the Internet community. This memo 30 does not specify an Internet standard. Distribution of this memo is 31 unlimited. 33 Abstract 35 The IPsec protocol suite is used to provide privacy and 36 authentication services at the IP layer. Several documents are used 37 to describe this protocol suite. The interrelationship and 38 organization of the various documents covering the IPsec protocol are 39 discussed here. An explanation of what to find in which document, 40 and what to include in new Cipher and Authenticator documents are 41 described. 43 Contents 45 Status of This Memo .................................................1 47 Abstract ............................................................1 49 Contents ............................................................2 51 1. Introduction .....................................................3 53 2. Interrelationship of IPsec Documents .............................3 55 3. Keying Material ..................................................5 57 4. Recommended Content of Cipher and Authenticator Documents ........5 59 4.1 Cipher and Authenticator ........................................5 60 4.2 Cipher ..........................................................6 61 4.3 Authenticator ...................................................7 63 5. Security Considerations ..........................................8 65 6. Acknowledgments ..................................................8 67 7. References .......................................................9 69 8. Author's Addresses ...............................................9 71 1. Introduction 73 This document is intended to provide guidelines for the development 74 of collateral specifications describing the use of new Cipher and 75 Authenticator algorithms with the ESP protocol, described in [ESP] 76 and new Authenticator algorithms used with the AH protocol, described 77 in [AH]. ESP and AH are part of the IP Security architecture 78 described in [Arch]. There is a requirement for a well-known 79 procedure that can be used to add new cipher algorithms or 80 authenticator algorithms to ESP and AH, not only while the initial 81 document set is undergoing development but after the base documents 82 have achieved RFC status. Following the guidelines discussed below 83 simplifies adding new algorithms and reduces that amount of redundant 84 documentation. 86 The goal in writing a new ESP or AH algorithm document is to 87 concentrate on the application of the specific algorithm. General 88 ESP and AH concepts, definitions, and issues are covered in the ESP 89 and AH documents. The algorithms themselves are not described in 90 these documents. This gives us the capability to add new algorithms 91 and also specify how any given algorithm might interact with other 92 algorithms. The intent is to achieve the goal of avoiding duplication 93 of information and excessive numbers of documents, the so-called 94 "draft explosion" 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 "Cipher" document set, shown on the left, is the set of documents 115 describing how various ciphers are used for ESP. These documents are 116 intended to fit in this roadmap, and should avoid overlap with the 117 ESP protocol document and with the Authenticator documents. Examples 118 of this document are the [DES-1829], [DES-Detroit], [3DES], or [CAST] 119 documents. When these or other Ciphers are used for ESP, the DOI 120 document has to indicate certain values, such as Cipher type, so 121 these documents provide input to the DOI. 123 The "Authenticator" document set, shown on the right, is the set of 124 documents describing how various authenticator algorithms are used 125 for both ESP and AH. These documents are intended to fit in this 126 roadmap, and should avoid overlap with the AH protocol document and 127 with the Cipher documents. Examples of this document are the [HMAC- 128 MD5], and [HMAC-SHA-1] documents. When these or other algorithms are 129 used for either ESP or AH, the DOI document has to indicate certain 130 values, such as algorithm type, so these documents provide input to 131 the DOI. 133 The "Key Management Documents", shown at the bottom, are the 134 documents describing the IETF standards-track key management schemes. 135 These documents provide certain values for the DOI also. Note that 136 issues of key management should be indicated here and not in, for 137 example, the ESP and AH protocol documents. Currently this box 138 represents [ISAKMP], [Oakley], and [Resolution]. 140 The DOI document, shown in the middle, contains values needed for the 141 other documents to relate to each other. This includes for example 142 Cipher algorithms, Authenticator algorithms, and operational 143 parameters such as key lifetimes. 145 +--------------+ 146 | Architecture | 147 +--------------+ 148 v v 149 +<-<-<-<-+ +->->->->+ 150 v v 151 +----------+ +----------+ 152 | ESP | | AH | 153 | PROTOCOL | | PROTOCOL | 154 +----------+ +----------+ 155 v v v v 156 v +->->->->->->->->+ v v 157 v v v v v 158 v v v v v 159 v +--------+ +---------------+ v 160 v | +--------+ | +---------------+ v 161 v | | | | | | v 162 v +-| Cipher | +-| Authenticator | v 163 v +--------+ +---------------+ v 164 v v v v 165 v v +-----+ v v 166 +>->->->-+->->->->| DOI |<-<-<-<-+-<-<-<-<-+ 167 +-----+ 168 ^ 169 ^ 170 +------------+ 171 | KEY | 172 | MANAGEMENT | 173 +------------+ 175 Figure 1. IPsec Document Roadmap. 177 3. Keying Material 179 Describing the cipher and authenticator algorithms in different docu- 180 ments raises the issue of how the key management protocols knows the 181 required keying material length for the desired algorithms when used 182 together with ESP. It also raises the issue of how to divide the 183 keying material. This is known as the "slicing and dicing" informa- 184 tion. 186 Each cipher and authenticator document should specify their respec- 187 tive key lengths. The key management protocols should use the length 188 of the keys specified in the cipher and authenticator documents to 189 generate the keying material of required length. 191 The ESP protocol document is responsible for specifying how the keys 192 are extracted from the keying material (sliced and diced). For exam- 193 ple, it should specify if the cipher or the authenticator algorithm 194 uses the first n-bits in the provided keying material. The AH proto- 195 col document has no such requirement. [Editor's Note: This paragraph 196 is still under contention and will be modified once the location of 197 the key derivation mechanism is known]. 199 4. Recommended Content of Cipher and Authenticator Documents 201 The document describing how a specific cipher or authenticator is 202 used should contain information appropriate to that cipher or authen- 203 ticator. This section enumerates what information should be pro- 204 vided. It is the intention of the document roadmap that: 206 . General protocol information goes in the respective ESP or AH protocol 207 documents. 208 . Key management information goes in the key management documents. 209 . Assigned values and constants go in the DOI document. 211 Cipher and Authenticator algorithms require some set of optional 212 parameters or have optional modes of operation (e.g. IVs, authentica- 213 tor lengths, and key lengths). To help eliminate some complexity 214 involved with key management having to negotiate large numbers of 215 algorithm-specific parameters, Cipher and Authenticator documents will 216 select fixed values for these parameters when it is deemed technically 217 reasonable and feasible. 219 Note, the following information is intended as a general guideline 220 only. 222 4.1 Cipher and Authenticator 224 This section describes the information that should be included in 225 both Cipher and Authenticator documents. 227 Keying Material 228 . Size of keys, including minimum, maximum, recommended and/or 229 required sizes. Note: the security considerations section should 230 address any weakness in specific sizes. 232 . Format of keying material. 233 . Known weak keys or references to documentation on known weak keys. 234 . Recommended or required processing of input keying material such as 235 parity generation or checking. 236 . Requirements and/or recommendations on how often the keying 237 material should be refreshed. 239 Performance Considerations 240 . Any available estimates on performance of this algorithm. 241 . Any available comparison data (e.g., compared against DES or 242 MD5). 243 . Input size or other considerations that could improve or degrade 244 performance. 246 ESP Environmental Considerations 247 . Any known issues regarding interactions between this algorithm and 248 other aspects of ESP, such as use of certain authentication 249 schemes. Note: As new authentication and cipher algorithms are 250 applied to ESP, the later documents will be required to address 251 interactions with previously specified algorithms. 253 Payload Content and Format Description 254 . Specification of size, placement, and content of algorithm-specific 255 fields not defined in the ESP or AH protocol documents (e.g., IV). 257 Security Considerations 258 . Discuss any known attacks. 259 . Discuss any known common implementation pitfalls, such as use of 260 weak random number generators. 261 . Discuss any relevant validation procedures, such as test vectors. 263 4.2 Cipher 265 This section describes the information that should be included in 266 Cipher documents. 268 Cipher Description 269 . General information how this cipher algorithm is to be used in 270 ESP. 271 . Description of background material and formal algorithm 272 description. 273 . Features of this cipher to be used by ESP, including encryption 274 and/or authentication. 275 . Mention of any availability issues such as Intellectual Property 276 considerations. 277 . References, in IETF style, to background material such as FIPS 278 documents. 280 Algorithm Modes of Operation 281 . Description of how the algorithm is operated, whether it is block 282 mode or streaming mode or other. 283 . Requirements for input or output block format. 284 . Padding requirements of this algorithm. Note: there is a default 285 for padding, specified in the base ESP document, so this is only 286 needed if the default cannot be used. 287 . Any algorithm-specific operating parameters, such as number of 288 rounds. 289 . Identify optional parameters and optional methods of operation and 290 pick reasonable fixed values and methods with explicit technical 291 explanations. 292 . Identify those optional parameters in which values and methods 293 should remain optional with explicit technical explanations on why 294 fixed values and methods should not be used. 295 . Defaults and mandatory ranges on algorithm-specific optional 296 parameters that could not be fixed. 298 4.3 Authenticator 300 This section describes the information that should be included in 301 Authenticator documents. In most cases, an authenticator algorithm 302 will operate the same whether it is used for ESP or AH. This should 303 be represented in a single authenticator algorithm document. 305 Authenticator Description 306 . General information on how this authenticator algorithm is to be 307 used with ESP and AH. 308 . Description of background material and formal algorithm 309 description. 310 . Features of this authenticator. 311 . Mention of any availability issues such as Intellectual Property 312 considerations. 313 . References, in IETF style, to background material such as 314 FIPS documents and definitive descriptions of underlying 315 algorithms. 317 Algorithm Modes of Operation 318 . Description of how the algorithm is operated. 319 . Algorithm-specific operating parameters, such as number of 320 rounds, and input or output block format. 321 . Implicit and explicit padding requirements of this algorithm. Note: 322 There is a default method for padding of the authenticator field 323 specified in the AH protocol document. This is only needed if the 324 default cannot be used. 325 . Identify optional parameters and optional methods of operation and 326 pick reasonable fixed values and methods with explicit technical 327 explanations. 328 . Identify those optional parameters in which values and methods 329 should remain optional with explicit technical explanations on why 330 fixed values and methods should not be used. 331 . Defaults and mandatory ranges on algorithm-specific optional 332 parameters that could not be fixed. 333 . Authenticator comparison criteria for this algorithm. Note: There 334 is a default method for verifying the authenticator specified 335 in the AH protocol document. This is only needed if the default 336 cannot be used (e.g. when using a signed hash). 338 5. Security Considerations 340 This document provides a roadmap and guidelines for writing cipher 341 and authenticator documents. The reader SHOULD follow all the secu- 342 rity procedures and guidelines described in the IPsec Architecture, 343 ESP, AH, cipher and authenticator documents. Note that many cipher 344 algorithms are not considered secure if they are not used with some 345 sort of authentication mechanism. 347 6. Acknowledgments 349 Several Internet drafts were referenced in writing this document. 350 Depending on where the documents are on (or off) the IETF standards 351 track these may not be available through the IETF RFC repositories. 352 In certain cases the reader may want to know what version of these 353 documents were referenced. These documents are: 355 . ARCH: draft-ietf-ipsec-arch-sec-01.txt. 356 . DES-Detroit: this is the ANX Workshop style of ESP, based on the 357 Hughes draft as modified by Cheryl Madson and published on the ANX 358 mailing list. 359 . DES-1829: this is Bill Simpson's DES-CBC for ESP document, to be 360 published as draft-simpson-esp-des1-v2-01.txt. 361 . 3DES: this is . 362 . CAST: this is draft-ietf-ipsec-esp-cast-128-cbc-00.txt, as revised 363 to relate to this document. 364 . DOI: draft-ietf-ietf-doi-02.txt. 365 . ESP: draft-ietf-ipsec-esp-04.txt, mailed to the IETF mailing list 366 in May/June 1997. 367 . AH: draft-ietf-ipsec-auth-05.txt, mailed to the IETF mailing list 368 in May/June 1997. 369 . HUGHES: this is draft-ietf-ipsec-esp-des-md5-03.txt 370 . ISAKMP: There are three documents describing ISAKMP. These are 371 draft-ietf-ipsec-isakmp-07.txt, draft-ietf-ipsec-isakmp-oakley- 372 03.txt, and draft-ietf-ipsec-ipsec-doi-02.txt. 374 7. References 376 [3DES] Triple-DES for ESP, RFC-xxxx. 378 [ARCH] Atkinson, R., "Security Architecture for the Internet 379 Protocol", RFC-1825, Naval Research Laboratory, 380 July 1995. 382 [CAST] CAST for ESP, RFC-xxxx. 384 [DES-Detroit] DES for ESP, Detroit dialect, RFC-xxxx. 386 [DES-1829] DES for ESP, 1829-Compatible mode, RFC-xxxx. 388 [DOI] IP Security Domain of Interpretation, RFC-xxxx. 390 [ESP] Karn, P., Metzger, P., and W. Simpson, "The ESP DES-CBC 391 Transform", RFC 1829, Qualcomm, Inc., Piermont, 392 Daydreamer, August 1995. 394 [HMAC] Krawczyk, K., Bellare, M., and Canetti R., "HMAC: 395 Keyed-Hashing for Message Authentication", RFC-2104, 396 February 1997. 398 [HMAC-MD5] Madson, C., Glenn, R., "The Use of HMAC-MD5 within ESP 399 and AH", draft-ietf-ipsec-ff-auth-hmac-sha-1-00.txt, 400 June 1997. 402 [HMAC-SHA-1] Madson, C., Glenn, R., "The Use of HMAC-SHA-1 within 403 ESP and AH", draft-ietf-ipsec-ff-auth-hmac-sha-1-00.txt, 404 June 1997. 406 8. Author's Addresses 408 Rodney Thayer 409 Sable Technology Corporation 410 246 Walnut Street 411 Newton, Massachusetts 02160 412 414 Naganand Doraswamy 415 Bay Networks 416 e-mail: naganand@baynetworks.com 418 Rob Glenn 419 NIST 420 e-mail: rob.glenn@nist.gov