idnits 2.17.1 draft-ietf-ipsec-ciph-des-derived-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-19) 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. ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 144 has weird spacing: '...fe fefe fefe ...' == Line 148 has weird spacing: '...fe 01fe fe0...' == Line 151 has weird spacing: '...fe 0efe fe1...' == Line 153 has weird spacing: '...fe e0fe f1fe ...' == Line 162 has weird spacing: '...01 01fe fe01 ...' == (5 more instances...) == 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 (July 1997) is 9775 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: 'Piermont' is mentioned on line 2, but not defined == Missing Reference: 'DayDreamer' is mentioned on line 4, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellovin96' -- Possible downref: Non-RFC (?) normative reference: ref. 'BS93' -- Possible downref: Non-RFC (?) normative reference: ref. 'CN94' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-46' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-46-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-74' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-81' -- Possible downref: Non-RFC (?) normative reference: ref. 'IB93' -- Possible downref: Non-RFC (?) normative reference: ref. 'IBK93' -- Possible downref: Non-RFC (?) normative reference: ref. 'Matsui94' ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-wwww' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Weiner94' Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P Metzger 2 Internet Draft [Piermont] 3 W A Simpson 4 [DayDreamer] 5 expires in six months July 1997 7 The ESP DES-CBC Transform 8 draft-ietf-ipsec-ciph-des-derived-00.txt 10 Status of this Memo 12 Follows draft-simpson-esp-des1-v2-00.txt. 14 This document is an Internet-Draft. Internet Drafts are working doc- 15 uments of the Internet Engineering Task Force (IETF), its Areas, and 16 its Working Groups. Note that other groups may also distribute work- 17 ing documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months, and may be updated, replaced, or obsoleted by other documents 21 at any time. It is not appropriate to use Internet Drafts as refer- 22 ence material, or to cite them other than as a ``working draft'' or 23 ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 27 Directories on: 29 ftp.is.co.za (Africa) 30 nic.nordu.net (Europe) 31 ds.internic.net (US East Coast) 32 ftp.isi.edu (US West Coast) 33 munnari.oz.au (Pacific Rim) 35 Distribution of this memo is unlimited. 37 Abstract 39 This document describes the DES-CBC block cipher transform interface 40 used with the IP Encapsulating Security Payload (ESP). It provides 41 compatible migration from RFC-1829. 43 1. Introduction 45 The Encapsulating Security Payload (ESP) [RFC-1827x] provides confi- 46 dentiality for IP datagrams by encrypting the payload data to be pro- 47 tected. This specification describes the ESP use of the Cipher Block 48 Chaining (CBC) mode of the US Data Encryption Standard (DES) algo- 49 rithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81]. 51 The level of privacy provided by use of ESP DES-CBC in the Internet 52 environment is far greater than sending the datagram as cleartext. 53 However, in view of the current analysis of DES, it is suggested that 54 DES is not a good encryption algorithm for the protection of even 55 moderate value information for any length of time. 57 For an explanation of the use of CBC mode with this cipher, see [RFC- 58 wwww]. 60 For more explanation and implementation information for DES, see 61 [Schneier95]. 63 This document assumes that the reader is familiar with the related 64 document "Security Architecture for the Internet Protocol" 65 [RFC-1825x], that defines the overall security plan for IP, and pro- 66 vides important background for this specification. 68 In this document, the key words "MAY", "MUST", "recommended", 69 "required", and "SHOULD", are to be interpreted as described in 70 [RFC-2119]. 72 1.1. Availability 74 There were a number of US patents (see [Schneier95] for listing). 75 All patents have expired. Several freely available implementations 76 have been published world-wide. 78 1.2. Performance 80 Phil Karn has tuned DES-CBC software to achieve 10.45 Mbps with a 90 81 MHz Pentium, scaling to 15.9 Mbps with a 133 MHz Pentium. Other DES 82 speed estimates may be found at [Schneier95, page 279]. Your milage 83 may vary. 85 2. Description 86 2.1. Block Size 88 The US Data Encryption Standard (DES) algorithm operates on blocks of 89 64-bits (8 bytes). This often requires padding before encrypting, 90 and subsequent removal of padding after decrypting. 92 The output is the same number of bytes that are input. This facili- 93 tates in-place encryption and decryption. 95 2.2. Interaction with Authentication 97 There is no known interaction of DES with any currently specified 98 Authenticator algorithm. Never-the-less, any Authenticator MUST use 99 a separate and independently generated key. 101 3. Initialization Vector 103 DES-CBC requires an Initialization Vector (IV) that is 64-bits (8 104 bytes) in length [RFC-wwww]. 106 By default, the 64-bit IV is generated from the 32-bit ESP Sequence 107 Number field followed by (concatenated with) the bit-wise complement 108 of the same 32-bit value: 110 SN || -SN 112 Alternative IV generation techniques MAY be specified when dynami- 113 cally configured via a key management protocol. 115 Security Notes: 117 Using the Sequence Number provides an easy method for preventing 118 IV repetition, and is sufficiently robust for practical use with 119 the DES algorithm. But, when used alone, cryptanalysis might be 120 aided by the rare serendipitous occurrence when the Sequence Num- 121 ber increments in exactly the same fashion as a corresponding bit 122 position in the first block. 124 No commonly used IP (Next Header) Protocols exhibit this property. 125 Never-the-less, inclusion of the bit-wise complement ensures that 126 Sequence Number bit changes are reflected twice in the IV. 128 4. Keys 130 DES-CBC is a symmetric secret key algorithm. The secret DES key 131 shared between the communicating parties is 56-bits in length. The 132 56-bit key is stored as a 64-bit (8 byte) quantity, with the least 133 significant bit of each byte used as a parity bit. 135 4.1. Weak Keys 137 DES has 64 known weak keys, including so-called semi-weak keys and 138 possibly-weak keys [Schneier95, pp 280-282] (shown in hex with parity 139 bits): 141 0101 0101 0101 0101 142 1f1f 1f1f 0e0e 0e0e 143 e0e0 e0e0 f1f1 f1f1 144 fefe fefe fefe fefe 146 semi-weak key pairs: 148 01fe 01fe 01fe 01fe fe01 fe01 fe01 fe01 149 1fe0 1fe0 0ef1 0ef1 e0f1 e0f1 f10e f10e 150 01e0 01e0 01f1 01f1 e001 e001 f101 f101 151 1ffe 1ffe 0efe 0efe fe1f fe1f fe0e fe0e 152 011f 011f 010e 010e 1f01 1f01 0e01 0e01 153 e0fe e0fe f1fe f1fe fee0 fee0 fef1 fef1 155 possibly-weak keys: 157 1f1f 0101 0e0e 0101 e001 01e0 f101 01f1 158 011f 1f01 010e 0e01 fe1f 01e0 fe0e 01f1 159 1f01 011f 0e01 010e fe01 1fe0 fe01 0ef1 160 0101 1f1f 0101 0e0e e01f 1fe0 f10e 0ef1 161 -------------------- 162 e0e0 0101 f1f1 0101 fe01 01fe fe01 01fe 163 fefe 0101 fefe 0101 e01f 01fe f10e 01fe 164 fee0 1f01 fef1 0e01 e001 1ffe f101 0efe 165 e0fe 1f01 f1fe 0e01 fe1f 1ffe fe0e 0efe 166 -------------------- 167 fee0 011f fef1 010e 1ffe 01e0 0efe 01f1 168 e0fe 011f f1fe 010e 01fe 1fe0 01fe 0ef1 169 e0e0 1f1f f1f1 0e0e 1fe0 01fe 0ef1 01fe 170 fefe 1f1f fefe 0e0e 01e0 1ffe 01f1 0efe 171 fe1f e001 fe0e f101 0101 e0e0 0101 f1f1 172 e01f fe01 f10e fe01 1f1f e0e0 0e0e f1f1 173 fe01 e01f fe01 f1e0 1f01 fee0 0e01 fef1 174 e001 fe1f f101 fe0e 011f fee0 010e fef1 175 -------------------- 176 01e0 e001 01f1 f101 1f01 e0fe 0e01 f1fe 177 1ffe e001 0efe f101 011f e0fe 010e f1fe 178 1fe0 fe01 0ef1 fe01 0101 fefe 0101 fefe 179 01fe fe01 01fe fe01 1f1f fefe 0e0e fefe 180 -------------------- 181 1fe0 e01f 0ef1 f10e fefe e0e0 fefe f1f1 182 01fe e01f 01fe f10e e0fe fee0 f1fe fef1 183 01e0 fe1f 01f1 fe0e fee0 e0fe fef1 f1fe 184 1ffe fe1f 0efe fe0e e0e0 fefe f1f1 fefe 186 Implementations SHOULD take care not to select weak keys [CN94], 187 although the likelihood of picking one at random is negligible. 189 4.2. Manual Key Management 191 When configured manually, 64-bits (8 bytes) are configured. 193 Keys with incorrect parity SHOULD be rejected by the configuration 194 utility, ensuring that the keys have been correctly configured. 196 The 64 known weak keys SHOULD be rejected. 198 4.3. Automated Key Management 200 When configured via a Security Association management protocol, 201 64-bits (8 bytes) are returned for the key. 203 The key manager MAY be required to generate the correct parity. 204 Alternatively, the least significant bit of each key byte is ignored, 205 or locally set to parity by the DES implementation. 207 The 64 known weak keys MUST be rejected. 209 4.4. Refresh Rate 211 To prevent differential and linear cryptanalysis of collisions [RFC- 212 wwww], no more than 2**32 plaintext blocks SHOULD be encrypted with 213 the same key. Depending on the average size of the datagrams, the 214 key SHOULD be changed at least as frequently as 2**30 datagrams. 216 5. ESP Alterations 217 5.1. ESP Sequence Number 219 The Sequence Number is a 32-bit (4 byte) unsigned counter. This 220 field protects against replay attacks, and may also be used for syn- 221 chronization by stream or block-chaining ciphers. 223 When configured manually, the first value sent SHOULD be a random 224 number. The limited anti-replay security of the sequence of data- 225 grams depends upon the unpredictability of the values. 227 When configured via an automated Security Association management pro- 228 tocol, the first value sent is 1, unless otherwise negotiated. 230 Thereafter, the value is monotonically increased for each datagram 231 sent. A replacement SPI SHOULD be established before the value 232 repeats. That is, no more than 2**32 datagrams SHOULD be sent with 233 any single key. 235 5.2. ESP Padding 237 The Padding field may be zero or more bytes in length. 239 Prior to encryption, this field is filled with a series of integer 240 values to align the Pad Length and Payload Type fields at the end of 241 a 64-bit (8 byte) block boundary (measured from the beginning of the 242 Transform Data). 244 By default, each byte contains the index of the byte. For example, 245 three pad bytes would contain the values 1, 2, 3. 247 After decryption, this field MAY be examined for a valid series of 248 integer values. Verification of the sequence of values is at the 249 discretion of the receiver. 251 Operational Considerations 253 The specification provides only a few manually configurable parame- 254 ters: 256 SPI 257 Manually configured SPIs are limited in range to aid operations. 258 Automated SPIs are pseudo-randomly distributed throughout the 259 remaining 2**32 values. 261 Default: 0 (none). Range: 256 to 65,535. 263 SPI LifeTime (SPILT) 264 Manually configured LifeTimes are generally measured in days. 265 Automated LifeTimes are specified in seconds. 267 Default: 32 days (2,764,800 seconds). Maximum: 182 days 268 (15,724,800 seconds). 270 Replay Window 271 Long term replay prevention requires automated configuration. 272 Also, some earlier implementations used pseudo-random values. 273 This check must only be used with those peers that have imple- 274 mented this feature. 276 Default: 0 (checking off). Range: 32 to 256. 278 Pad Values 279 New implementations use verifiable values. However, some earlier 280 implementations used pseudo-random values. This check must only 281 be used with those peers that have implemented this feature. 283 Also, some operations desire additional padding to inhibit traffic 284 analysis. 286 Default: 0 (checking off). Range: 7 to 255. 288 Key 289 The 56-bit key is configured as a 64-bit quantity, with parity 290 included as appropriate. 292 Each party configures a list of known SPIs and symmetric secret-keys. 294 In addition, each party configures local policy that determines what 295 access (if any) is granted to the holder of a particular SPI. For 296 example, a party might allow FTP, but prohibit Telnet. Such consid- 297 erations are outside the scope of this document. 299 Security Considerations 301 Users need to understand that the quality of the security provided by 302 this specification depends completely on the strength of the DES 303 algorithm, the correctness of that algorithm's implementation, the 304 security of the Security Association management mechanism and its 305 implementation, the strength of the key [CN94], and upon the correct- 306 ness of the implementations in all of the participating nodes. 308 The padding bytes have a predictable value. They provide a small 309 measure of tamper detection on their own block and the previous block 310 in CBC mode. This makes it somewhat harder to perform splicing 311 attacks, and avoids a possible covert channel. This small amount of 312 known plaintext does not create any problems for modern ciphers. 314 At the time of writing of this document, [BS93] demonstrated a dif- 315 ferential cryptanalysis based chosen-plaintext attack requiring 2**47 316 plaintext-ciphertext block pairs, and [Matsui94] demonstrated a lin- 317 ear cryptanalysis based known-plaintext attack requiring only 2**43 318 plaintext-ciphertext block pairs. Although these attacks are not 319 considered practical, they must be taken into account. 321 More disturbingly, [Weiner94] has shown the design of a DES cracking 322 machine costing $1 Million that can crack one key every 3.5 hours. 323 This is an extremely practical attack. 325 One or two blocks of known plaintext suffice to recover a DES key. 326 Because IP datagrams typically begin with a block of known and/or 327 guessable header text, frequent key changes will not protect against 328 this attack. 330 Changes from RFC-1829: 332 This specification results in the same default bits-on-the-wire as 333 the 32-bit IV calculation method of RFC-1829. The 32-bit field is 334 semantically identical to a Sequence Number when implemented as a 335 counter (the recommended method). 337 The 64-bit explicit IV option is deprecated, as no hardware manufac- 338 turers were found that required it. It does not meet 64-bit field 339 alignment expectations of IPv6, it is a cryptographically weaker con- 340 struct than a calculated IV [Bellovin96], and it conflicts with the 341 use of a Sequence Number immediately following the SPI. 343 Padding is a known series of integers, that may be checked upon 344 receipt. 346 Many implementation details by Karn were found to be common to all 347 ESP Ciphers, and are awaiting consolidation in the ESP specification. 349 Added an operational section. 351 Updated acknowledgements, references, and contacts. 353 Reorganized according to the new "road map" document. 355 Acknowledgements 357 The basic field naming and layout is based on "swIPe" [IBK93, IB93]. 359 Participants in the IP Security Working Group modified this to a 360 variable number of variable length fields. After a digression span- 361 ning 4 years, actual implementors mandated a return to these fewer 362 well-known fields. 364 Some of the text of this specification was derived from work by Ran- 365 dall Atkinson for the SIP, SIPP, and IPv6 Working Groups. 367 Perry Metzger provided the original Security Considerations text, 368 some of which is distributed throughout the document. 370 William Allen Simpson was responsible for the name and semantics of 371 the SPI, the IV calculation technique(s), editing and formatting. 373 The use of known padding values was suggested in various forms by 374 Robert Baldwin, Phil Karn, and David Wagner. This specification uses 375 Self-Describing-Padding [RFC-1570]. 377 Robert Baldwin, Steve Bellovin, Steve Deering, Karl Fox, Charles 378 Lynn, Cheryl Madson, Craig Metz, Dave Mihelcic, Jeffrey Schiller, 379 Norman Shulman and David Wagner provided useful critiques of earlier 380 versions of this document. 382 References 384 [Bellovin96] 385 Bellovin, S., "Problem Areas for the IP Security Protocols", 386 Proceedings of the Sixth Usenix Security Symposium, July 387 1996. 389 [BS93] Biham, E., and Shamir, A., "Differential Cryptanalysis of 390 the Data Encryption Standard", Berlin: Springer-Verlag, 391 1993. 393 [CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data: 394 Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 395 253-280, July 1994. 397 [FIPS-46] 398 US National Bureau of Standards, "Data Encryption Standard", 399 Federal Information Processing Standard (FIPS) Publication 400 46, January 1977. 402 [FIPS-46-1] 403 US National Bureau of Standards, "Data Encryption Standard", 404 Federal Information Processing Standard (FIPS) Publication 405 46-1, January 1988. 407 [FIPS-74] 408 US National Bureau of Standards, "Guidelines for Implement- 409 ing and Using the Data Encryption Standard", Federal Infor- 410 mation Processing Standard (FIPS) Publication 74, April 411 1981. 413 [FIPS-81] 414 US National Bureau of Standards, "DES Modes of Operation" 415 Federal Information Processing Standard (FIPS) Publication 416 81, December 1980. 418 [IB93] Ioannidis, J., and Blaze, M., "The Architecture and Imple- 419 mentation of Network-Layer Security Under Unix", Proceedings 420 of the Fourth Usenix Security Symposium, Santa Clara Cali- 421 fornia, October 1993. 423 [IBK93] Ioannidis, J., Blaze, M., and Karn, P., "swIPe: Network- 424 Layer Security for IP", Presentation at the 26th Internet 425 Engineering Task Force, Columbus Ohio, March 1993. 427 [Matsui94] 428 Matsui, M., "Linear Cryptanalysis method for DES Cipher," 429 Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin: 431 Springer-Verlag, 1994. 433 [RFC-1570] 434 Simpson, W., "PPP LCP Extensions", DayDreamer, January 1994. 436 [RFC-1825x] 437 Atkinson, R., "Security Architecture for the Internet Proto- 438 col", Naval Research Laboratory, July 1995. 440 [RFC-1827x] 441 Simpson, W., "IP Encapsulating Security Protocol (ESP) for 442 implementors", work in progress. 444 [RFC-2119] 445 Bradner, S., "Key words for use in RFCs to Indicate Require- 446 ment Levels", BCP 14, Harvard University, March 1997. 448 [RFC-wwww] 449 Simpson, W.A, "ESP with Cipher Block Chaining (CBC)", work 450 in progress. 452 [Schneier95] 453 Schneier, B., "Applied Cryptography Second Edition", John 454 Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. 456 [Weiner94] 457 Wiener, M.J., "Efficient DES Key Search", School of Computer 458 Science, Carleton University, Ottawa, Canada, TR-244, May 459 1994. Presented at the Rump Session of Crypto '93. 461 Contacts 463 Comments about this document should be discussed on the ipsec@tis.com 464 mailing list. 466 Questions about this document can also be directed to: 468 Perry Metzger 469 Piermont Information Systems Inc. 470 160 Cabrini Blvd., Suite #2 471 New York, NY 10033 473 perry@piermont.com 475 William Allen Simpson 476 DayDreamer 477 Computer Systems Consulting Services 478 1384 Fontaine 479 Madison Heights, Michigan 48071 481 wsimpson@UMich.edu 482 wsimpson@GreenDragon.com (preferred) 483 bsimpson@MorningStar.com