idnits 2.17.1 draft-simpson-esp-des3v2-03.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-25) 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. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 1998) is 9416 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: 'DayDreamer' is mentioned on line 2, but not defined == Missing Reference: 'Piermont' is mentioned on line 3, but not defined == Missing Reference: 'Qualcomm' is mentioned on line 4, but not defined == Missing Reference: 'Bay' is mentioned on line 5, but not defined == Unused Reference: 'Bellovin96' is defined on line 325, but no explicit reference was found in the text == Unused Reference: 'RFC-1570' is defined on line 381, but no explicit reference was found in the text -- 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. 'CW92' -- 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'MH81' -- Possible downref: Non-RFC (?) normative reference: ref. 'OW91' ** 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. 'Tuchman79' Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W A Simpson [DayDreamer] 3 Internet Draft P Metzger [Piermont] 4 P Karn [Qualcomm] 5 Naganand Doraswamy [Bay] 6 expires in six months July 1998 8 The ESP Triple DES Transform 9 draft-simpson-esp-des3v2-03.txt 11 Status of this Memo 13 This document is an Internet-Draft. Internet Drafts are working doc- 14 uments of the Internet Engineering Task Force (IETF), its Areas, and 15 its Working Groups. Note that other groups may also distribute work- 16 ing documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months, and may be updated, replaced, or obsoleted by other documents 20 at any time. It is not appropriate to use Internet Drafts as refer- 21 ence material, or to cite them other than as a ``working draft'' or 22 ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 26 Directories on: 28 ftp.is.co.za (Africa) 29 nic.nordu.net (Northern Europe) 30 ftp.nis.garr.it (Southern Europe) 31 ftp.ietf.org (Eastern USA) 32 ftp.isi.edu (Western USA) 33 munnari.oz.au (Pacific Rim) 35 Distribution of this memo is unlimited. 37 Copyright Notice 39 Copyright (C) William Allen Simpson, Perry Metzger and Philip Karn 40 (1994-1995). Copyright (C) William Allen Simpson, Perry Metzger, 41 Philip Karn and Naganand Doraswamy (1997-1998). All Rights Reserved. 43 Abstract 45 This document describes the 'Triple' DES-EDE3-CBC block cipher trans- 46 form interface used with the IP Encapsulating Security Payload (ESP). 48 1. Introduction 50 The Encapsulating Security Payload (ESP) [RFC-1827x] provides confi- 51 dentiality for IP datagrams by encrypting the payload data to be pro- 52 tected. This specification describes the ESP use of a variant of the 53 Cipher Block Chaining (CBC) mode of the US Data Encryption Standard 54 (DES) algorithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81]. 56 This variant, colloquially known as "Triple DES", processes each 57 block three times, each time with a different key [Tuchman79]. 59 For an explanation of the use of CBC mode with this cipher, see [RFC- 60 wwww]. 62 For more explanation and implementation information for Triple DES, 63 see [Schneier95]. 65 This document assumes that the reader is familiar with the related 66 document "Security Architecture for the Internet Protocol" 67 [RFC-1825x], that defines the overall security plan for IP, and pro- 68 vides important background for this specification. 70 In this document, the key words "MAY", "MUST", "recommended", 71 "required", and "SHOULD", are to be interpreted as described in 72 [RFC-2119]. 74 1.1. Availability 76 There were a number of US patents (see [Schneier95] for listing). 77 All patents have expired. Several freely available implementations 78 have been published world-wide. 80 1.2. Performance 82 As this specification requires "outer" chaining, it is not possible 83 to provide parallel computation for the same data stream. 85 The DES "initial" and "final" permutations are inverses of each 86 other, so the permutations effectively cancel between the first and 87 second and the second and third steps. A significant performance 88 improvement can be obtained by removing these "inner" permutations 89 entirely. Thus, "triple DES" is approximately 2.5 times slower than 90 "single DES". 92 Phil Karn has tuned DES-EDE3-CBC software to achieve 6.22 Mbps with a 93 133 MHz Pentium, compared with 15.9 Mbps for "single" DES-CBC on the 94 same machine. This software is freely available on the 95 www.cryptography.org site. Other DES speed estimates may be found at 96 [Schneier95, page 279]. Your mileage may vary. 98 2. Description 99 2.1. Block Size 101 The US Data Encryption Standard (DES) algorithm operates on blocks of 102 64-bits (8 bytes). This often requires padding before encrypting, 103 and subsequent removal of padding after decrypting. 105 The output is the same number of bytes that are input. This facili- 106 tates in-place encryption and decryption. 108 2.2. Mode 110 The DES-EDE3-CBC algorithm is a simple variant of the DES-CBC algo- 111 rithm [RFC-wwww, RFC-1829]. 113 In DES-EDE3-CBC, the algorithms are an encryption (Ek1), followed by 114 a decryption (Dk2), followed by an encryption (Ek3). Each step uses 115 an independant key: k1, k2 and k3. 117 To decrypt, the order of the functions is reversed: decrypt with k3, 118 encrypt with k2, decrypt with k1. 120 Note that when a pair of keys (k1 and k2 or k2 and k3) are the same, 121 DES-EDE3-CBC is equivalent to DES-CBC. This property allows the DES- 122 EDE3 hardware implementations to operate in DES mode without modifi- 123 cation. 125 2.3. Interaction with Authentication 127 There is no known interaction of DES with any currently specified 128 Authenticator algorithm. Never-the-less, any Authenticator MUST use 129 a separate and independently generated key. 131 3. Initialization Vector 133 DES-EDE3-CBC requires an Initialization Vector (IV) that is 64-bits 134 (8 bytes) in length. By default, the IV is carried immediately fol- 135 lowing the ESP Sequence Number. 137 4. Keys 139 The secret DES-EDE3 keys shared between the communicating parties are 140 effectively 168-bits long, but are represented as a 192-bit (24 byte) 141 quantity. 143 The keys consist of three independent 56-bit quantities used by the 144 DES algorithm. Each of the three 56-bit keys is stored as a 64-bit 145 (8 byte) quantity, with the least significant bit of each byte used 146 as a parity bit. 148 4.1. Weak Keys 150 DES has 64 known weak keys, including so-called semi-weak keys and 151 possibly-weak keys [Schneier95, pp 280-282]. The likelihood of pick- 152 ing one at random is negligible. 154 For DES-EDE3, there is no known need to reject weak or complementa- 155 tion keys. Any weakness is likely to be obviated by the other keys. 157 However, since checking for weak keys is quite easy, conformant 158 implementations MUST test for weak DES keys. 160 Moreover, when operating as DES-EDE3, each key MUST NOT be the same 161 as the preceding key. 163 4.2. Manual Key Management 165 When configured manually, three independently generated keys are 166 required, in the order used for encryption, and 64-bits (8 bytes) are 167 configured for each individual key. 169 Keys with incorrect parity SHOULD be rejected by the configuration 170 utility, ensuring that the keys have been correctly configured. 172 Each key is examined sequentially, in the order used for encryption. 173 A key that is identical to a previous key MAY be rejected. The 64 174 known weak DES keys SHOULD be rejected. In either case, a warning 175 SHOULD be displayed. 177 4.3. Automated Key Management 179 When configured via a Security Association management protocol, three 180 independently generated keys are required, in the order used for 181 encryption, and 64-bits (8 bytes) are returned for each individual 182 key. 184 The key manager MAY be required to generate the correct parity for 185 each key. Alternatively, the least significant bit of each key byte 186 is ignored, or locally set to parity by the DES implementation. 188 Each key is examined sequentially, in the order used for encryption. 189 A key that is identical to a previous key MUST be rejected. The 64 190 known weak DES keys MUST be rejected. 192 4.4. Refresh Rate 194 To prevent differential and linear cryptanalysis of collisions [RFC- 195 wwww], no more than 2**32 plaintext blocks SHOULD be encrypted with 196 the same keys. Depending on the average size of the datagrams, the 197 keys SHOULD be changed at least as frequently as 2**30 datagrams. 199 Operational Considerations 201 The specification provides only a few manually configurable parame- 202 ters: 204 SPI 205 Manually configured SPIs are limited in range to aid operations. 206 Automated SPIs are pseudo-randomly distributed throughout the 207 remaining 2**32 values. 209 Default: 0 (none). Range: 256 to 65,535. 211 SPI LifeTime (SPILT) 212 Although automated LifeTimes are internally maintained in seconds, 213 manually configured LifeTimes are generally measured in days to 214 promote ease of configuration. 216 Default: 32 days (2,764,800 seconds). Maximum: 182 days 217 (15,724,800 seconds). 219 Key 220 Three 56-bit keys, with parity included as appropriate, are con- 221 figured in order as a 192-bit quantity. 223 Each party configures a list of known SPIs and symmetric secret-keys. 225 In addition, each party configures local policy that determines what 226 access (if any) is granted to the holder of a particular SPI. For 227 example, a party might allow FTP, but prohibit Telnet. Such consid- 228 erations are outside the scope of this document. 230 Security Considerations 232 Users need to understand that the quality of the security provided by 233 this specification depends completely on the strength of the Triple 234 DES algorithm, the correctness of that algorithm's implementation, 235 the security of the Security Association management mechanism and its 236 implementation, the strength of the key [CN94], and upon the correct- 237 ness of the implementations in all of the participating nodes. 239 The biggest practical vulnerability of any software security system 240 is protecting the memory containing the keys. No system can remain 241 secure when its key storage is insecure. If this key storage is man- 242 aged by an operating system, then the combination is no more secure 243 than the operating system itself. Even when the OS is secure against 244 external attack, there is always the possibility of physical compro- 245 mise. 247 It was originally thought that DES might be a group, but it has been 248 demonstrated that it is not [CW92]. Since DES is not a group, compo- 249 sition of multiple rounds of DES is not equivalent to simply using 250 DES with a different key. 252 Triple DES with independent keys is not, as naively might be 253 expected, as difficult to break by brute force as a cryptosystem with 254 three times the keylength. A space/time tradeoff has been shown 255 which can brute-force break triple block encryptions in the time 256 naively expected for double encryption [MH81]. 258 However, "double" DES (DES-EE2) can be broken with a meet-in-the- 259 middle attack, without significantly more complexity than breaking 260 DES requires [ibid]. DES-EDE3 with three independant keys is actu- 261 ally needed to provide significantly more security than "single" DES. 263 An attack has been shown on DES-EDE2 (using only two independent 264 keys) [Tuchman79] that is somewhat (sixteen times) faster than 265 exhaustive search [OW91]. Again, DES-EDE3 with three independant 266 keys is actually needed to provide the expected level of security. 268 Although it is widely believed that DES-EDE3 is substantially 269 stronger than single DES alone, as it is less amenable to brute force 270 attack, it should be noted that real cryptanalysis of DES-EDE3 might 271 not use brute force methods at all. Instead, it might be performed 272 using variants on differential [BS93] or linear [Matsui94] cryptanal- 273 ysis. 275 It should also be noted that no encryption algorithm is permanently 276 safe from brute force attack, because of the increasing speed of mod- 277 ern computers. 279 As with all cryptosystems, those responsible for applications with 280 substantial risk when security is breeched should pay close attention 281 to developments in cryptology, and especially cryptanalysis, and 282 switch to other transforms should DES-EDE3 prove weak. 284 Changes from RFC-1851: 286 Updated performance estimates. Replaced erroneous text about paral- 287 lel computation. 289 Details of CBC are moved to an informational document, to be used by 290 multiple algorithms. 292 The explicit 64-bit version of the IV is specified as a default. 293 Compatibility and enhancement options are moved to an informational 294 document. 296 Implementation details by Karn were found to be common to many ESP 297 Ciphers, and are awaiting consolidation in the ESP specification. 299 Updated security considerations. 301 Added an operational section. 303 Updated acknowledgements, references, and contacts. 305 Reorganized according to the "road map" document. 307 Acknowledgements 309 The basic field naming and layout is based on "swIPe" [IBK93, IB93]. 311 Some of the text of this specification was derived from work by Ran- 312 dall Atkinson for the SIP, SIPP, and IPv6 Working Groups. 314 Perry Metzger provided the original Security Considerations text, 315 some of which is distributed throughout the document. 317 William Allen Simpson was responsible for the name and semantics of 318 the SPI, editing and formatting. 320 Steve Bellovin, Angelos Keromytis, Holger Kummert, and Rodney Thayer 321 provided useful critiques of earlier versions of this document. 323 References 325 [Bellovin96] 326 Bellovin, S., "Problem Areas for the IP Security Proto- 327 cols", Proceedings of the Sixth Usenix Security Sympo- 328 sium, July 1996. 330 [BS93] Biham, E., and Shamir, A., "Differential Cryptanalysis of 331 the Data Encryption Standard", Berlin: Springer-Verlag, 332 1993. 334 [CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak 335 Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 336 23 pp. 253-280, July 1994. 338 [CW92] Campbell, K.W., and Wiener, M.J., "Proof that DES Is Not 339 a Group", Advances in Cryptology -- Crypto '92 Proceed- 340 ings, Berlin: Springer-Verlag, 1993, pp 518-526. 342 [FIPS-46] US National Bureau of Standards, "Data Encryption Stan- 343 dard", Federal Information Processing Standard (FIPS) 344 Publication 46, January 1977. 346 [FIPS-46-1] US National Bureau of Standards, "Data Encryption Stan- 347 dard", Federal Information Processing Standard (FIPS) 348 Publication 46-1, January 1988. 350 [FIPS-74] US National Bureau of Standards, "Guidelines for Imple- 351 menting and Using the Data Encryption Standard", Federal 352 Information Processing Standard (FIPS) Publication 74, 353 April 1981. 355 [FIPS-81] US National Bureau of Standards, "DES Modes of Operation" 356 Federal Information Processing Standard (FIPS) Publica- 357 tion 81, December 1980. 359 [IB93] Ioannidis, J., and Blaze, M., "The Architecture and 360 Implementation of Network-Layer Security Under Unix", 361 Proceedings of the Fourth Usenix Security Symposium, 362 Santa Clara California, October 1993. 364 [IBK93] Ioannidis, J., Blaze, M., and Karn, P., "swIPe: Network- 365 Layer Security for IP", Presentation at the 26th Internet 366 Engineering Task Force, Columbus Ohio, March 1993. 368 [Matsui94] Matsui, M., "Linear Cryptanalysis method for DES Cipher," 369 Advances in Cryptology -- Eurocrypt '93 Proceedings, 370 Berlin: Springer-Verlag, 1994. 372 [MH81] Merkle, R.C., and Hellman, M., "On the Security of Multi- 373 ple Encryption", Communications of the ACM, v. 24 n. 7, 374 1981, pp. 465-467. 376 [OW91] van Oorschot, P.C., and Weiner, M.J. "A Known-Plaintext 377 Attack on Two-Key Triple Encryption", Advances in Cryp- 378 tology -- Eurocrypt '90 Proceedings, Berlin: Springer- 379 Verlag, 1991, pp. 318-325. 381 [RFC-1570] Simpson, W., "PPP LCP Extensions", DayDreamer, January 382 1994. 384 [RFC-1825x] Atkinson, R., "Security Architecture for the Internet 385 Protocol", Naval Research Laboratory, July 1995. 387 [RFC-1827x] Simpson, W., "IP Encapsulating Security Protocol (ESP) 388 for implementors", work in progress. 390 [RFC-1829] Karn, P., Metzger, P., Simpson, W.A., "The ESP DES-CBC 391 Transform", August 1995. 393 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, Harvard University, March 395 1997. 397 [RFC-wwww] Simpson, W.A, "ESP with Cipher Block Chaining (CBC)", 398 work in progress. 400 [Schneier95] 401 Schneier, B., "Applied Cryptography Second Edition", John 402 Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. 404 [Tuchman79] Tuchman, W, "Hellman Presents No Shortcut Solutions to 405 DES", IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41. 407 Contacts 409 Comments about this document should be discussed on the ipsec@tis.com 410 mailing list. 412 Questions about this document can also be directed to: 414 William Allen Simpson 415 DayDreamer 416 Computer Systems Consulting Services 417 1384 Fontaine 418 Madison Heights, Michigan 48071 420 wsimpson@UMich.edu 421 wsimpson@GreenDragon.com (preferred) 423 Perry Metzger 424 Piermont Information Systems Inc. 425 160 Cabrini Blvd., Suite #2 426 New York, NY 10033 428 perry@piermont.com 430 Phil Karn 431 Qualcomm, Inc. 432 6455 Lusk Blvd. 433 San Diego, California 92121-2779 435 karn@qualcomm.com 436 karn@unix.ka9q.ampr.org (preferred) 438 Naganand Doraswamy 439 Bay Networks 440 3 Federal Street #BL3-04 441 Billerica, Massachusetts 01821 443 naganand@BayNetworks.Com 445 Full Copyright Statement 447 Copyright (C) William Allen Simpson, Perry Metzger and Philip Karn 448 (1994-1995). Copyright (C) William Allen Simpson, Perry Metzger, 449 Philip Karn and Naganand Doraswamy (1997-1998). All Rights Reserved. 451 This document and translations of it may be copied and furnished to 452 others, and derivative works that comment on or otherwise explain it 453 or assist in its implementation may be prepared, copied, published 454 and distributed, in whole or in part, without restriction of any 455 kind, provided that the above copyright notice and this paragraph are 456 included on all such copies and derivative works. However, this doc- 457 ument itself may not be modified in any way, except as required to 458 translate it into languages other than English. 460 This document and the information contained herein is provided on an 461 "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR 462 IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF 463 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 464 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.