idnits 2.17.1 draft-simpson-desx-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. 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. 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 -- 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. 'Kaliski96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kilian96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Matsui94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Rogaway96' ** 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' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 16 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 R Baldwin [RSA Data Security] 4 expires in six months July 1998 6 The ESP DES-XEX3-CBC Transform 7 draft-simpson-desx-02.txt 9 Status of this Memo 11 This document is an Internet-Draft. Internet Drafts are working doc- 12 uments of the Internet Engineering Task Force (IETF), its Areas, and 13 its Working Groups. Note that other groups may also distribute work- 14 ing documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is not appropriate to use Internet Drafts as refer- 19 ence material, or to cite them other than as a ``working draft'' or 20 ``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: 26 ftp.is.co.za (Africa) 27 nic.nordu.net (Northern Europe) 28 ftp.nis.garr.it (Southern Europe) 29 ftp.ietf.org (Eastern USA) 30 ftp.isi.edu (Western USA) 31 munnari.oz.au (Pacific Rim) 33 Distribution of this memo is unlimited. 35 Copyright Notice 37 Copyright (C) William Allen Simpson (1995-1996). Copyright (C) 38 William Allen Simpson and Robert Baldwin (1997-1998). All Rights 39 Reserved. 41 Abstract 43 This document describes the "DESX" DES-XEX3-CBC block cipher trans- 44 form interface used with the IP Encapsulating Security Payload (ESP). 46 1. Introduction 48 The Encapsulating Security Payload (ESP) [RFC-1827x] provides confi- 49 dentiality for IP datagrams by encrypting the payload data to be pro- 50 tected. This specification describes the ESP use of a variant of the 51 Cipher Block Chaining (CBC) mode of the US Data Encryption Standard 52 (DES) algorithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81]. 54 This variant, also known as "DESX", processes each block three times, 55 each time with a different key [Kaliski96]. The first and last pass 56 are a simple and fast XOR. This was originally proposed by Ron 57 Rivest in May of 1984 as a computationally cheap mechanism to protect 58 DES against exhaustive key-search attacks. 60 Although XOR of a constant value over multiple blocks would not nor- 61 mally be considered cryptographically secure, the use of DES-CBC in 62 the middle provides a background of highly random internal chaining. 63 The XOR values are combined with these random blocks to provide a 64 modest improvement in strength. 66 For an explanation of the use of CBC mode with this cipher, see [RFC- 67 wwww]. 69 For more explanation and implementation information for DESX, see 70 [Schneier95]. 72 This document assumes that the reader is familiar with the related 73 document "Security Architecture for the Internet Protocol" 74 [RFC-1825x], that defines the overall security plan for IP, and pro- 75 vides important background for this specification. 77 In this document, the key words "MAY", "MUST", "recommended", 78 "required", and "SHOULD", are to be interpreted as described in 79 [RFC-2119]. 81 1.1. Availability 83 The DESX algorithm has been previously described in [Kaliski96, 84 Schneier95]. This algorithm is not protected by either patent or 85 trade secret laws, though the DESX name is a trademark of RSA Data 86 Security, a wholly owned subsidary of Security Dynamics Inc. Trade- 87 mark fair-use laws allow vendors to label a product as being compati- 88 ble with DESX. An implementation of DESX is available in RSA's BSAFE 89 cryptography toolkit and interoperable implementations have been cre- 90 ated outside of the United States. 92 1.2. Performance 94 The additional computational cost beyond DES is negligible. 96 2. Description 97 2.1. Block Size 99 The US Data Encryption Standard (DES) algorithm operates on blocks of 100 64-bits (8 bytes). This often requires padding before encrypting, 101 and subsequent removal of padding after decrypting. 103 The output is the same number of bytes that are input. This facili- 104 tates in-place encryption and decryption. 106 2.2. Mode 108 The DES-XEX3-CBC algorithm is a simple variant of the DES-CBC algo- 109 rithm [RFC-wwww, RFC-1829]. 111 In DES-XEX3-CBC, the algorithms are an XOR (Xk1), followed by a DES 112 encryption (Ek2), followed by another XOR (Xk3), which generates the 113 ciphertext (C1) for the block. Each step uses an independant key: 114 k1, k2 and k3. 116 To decrypt, the order of the functions is reversed: XOR with k3, DES 117 decrypt with k2, XOR with k1. 119 Note that when the XOR keys (k1 and k3) are zero, DES-XEX3-CBC is 120 equivalent to DES-CBC. This property allows the DES-XEX3 hardware 121 implementations to operate in DES mode without modification. 123 2.3. Interaction with Authentication 125 There is no known interaction of DES with any currently specified 126 Authenticator algorithm. Never-the-less, any Authenticator MUST use 127 a separate and independently generated key. 129 3. Initialization Vector 131 DES-XEX3-CBC requires an Initialization Vector (IV) that is 64-bits 132 (8 bytes) in length. By default, the IV is carried immediately fol- 133 lowing the ESP Sequence Number. 135 4. Keys 137 The secret DES-XEX3 keys shared between the communicating parties are 138 effectively 184-bits long, but are represented as a 192-bit (24 byte) 139 quantity. 141 The keys consist of three independent quantities: a 64-bit key used 142 by an XOR, a 56-bit key used by the DES algorithm, and another 64-bit 143 key used by an XOR. The middle 56-bit key is stored as a 64-bit (8 144 byte) quantity, with the least significant bit of each byte used as a 145 parity bit. 147 4.1. Weak Keys 149 DES has 64 known weak keys, including so-called semi-weak keys and 150 possibly-weak keys [Schneier95, pp 280-282]. The likelihood of pick- 151 ing one at random is negligible. 153 However, since checking for weak keys is quite easy, conformant 154 implementations MUST test for weak DES keys. 156 Moreover, the XOR keys MUST NOT be zero. 158 4.2. Manual Key Management 160 When configured manually, three independently generated keys are 161 required, in the order used for encryption, and 64-bits (8 bytes) are 162 configured for each individual key. 164 Keys with incorrect parity SHOULD be rejected by the configuration 165 utility, ensuring that the keys have been correctly configured. 167 Each key is examined sequentially, in the order used for encryption. 168 A key that is identical to a previous key MUST be rejected. The 64 169 known weak DES keys MUST be rejected. 171 4.3. Automated Key Management 173 When configured via a Security Association management protocol, three 174 independently generated keys are required, in the order used for 175 encryption, and 64-bits (8 bytes) are returned for each individual 176 key. 178 The key manager MAY be required to generate the correct parity for 179 the DES key. Alternatively, the least significant bit of each key 180 byte is ignored, or locally set to parity by the DES implementation. 182 Each key is examined sequentially, in the order used for encryption. 183 A key that is identical to a previous key MUST be rejected. The 64 184 known weak DES keys (for the DES key) MUST be rejected. 186 4.4. Refresh Rate 188 To prevent differential and linear cryptanalysis of collisions [RFC- 189 wwww], no more than 2**32 plaintext blocks SHOULD be encrypted with 190 the same keys. Depending on the average size of the datagrams, the 191 keys SHOULD be changed at least as frequently as 2**30 datagrams. 193 Operational Considerations 195 The specification provides only a few manually configurable parame- 196 ters: 198 SPI 199 Manually configured SPIs are limited in range to aid operations. 200 Automated SPIs are pseudo-randomly distributed throughout the 201 remaining 2**32 values. 203 Default: 0 (none). Range: 256 to 65,535. 205 SPI LifeTime (SPILT) 206 Manually configured LifeTimes are generally measured in days. 207 Automated LifeTimes are specified in seconds. 209 Default: 32 days (2,764,800 seconds). Maximum: 182 days 210 (15,724,800 seconds). 212 Key 213 A 64-bit key, a 56-bit key with parity included as appropriate, 214 and another 64-bit key, are configured in order as a 192-bit quan- 215 tity. 217 Each party configures a list of known SPIs and symmetric secret-keys. 219 In addition, each party configures local policy that determines what 220 access (if any) is granted to the holder of a particular SPI. For 221 example, a party might allow FTP, but prohibit Telnet. Such consid- 222 erations are outside the scope of this document. 224 Security Considerations 226 Users need to understand that the quality of the security provided by 227 this specification depends completely on the strength of the DESX 228 algorithm, the correctness of that algorithm's implementation, the 229 security of the Security Association management mechanism and its 230 implementation, the strength of the key [CN94], and upon the correct- 231 ness of the implementations in all of the participating nodes. 233 The padding bytes have a predictable value. They provide a small 234 measure of tamper detection on their own block and the previous block 235 in CBC mode. This makes it somewhat harder to perform splicing 236 attacks, and avoids a possible covert channel. This small amount of 237 known plaintext does not create any problems for modern ciphers. 239 It has been shown that DES-XEX3 is substantially stronger than DES 240 alone, as it is less amenable to brute force attack with an exhaus- 241 tive key search. When the number of plaintext blocks are limited to 242 2**32 as recommended, the time complexity of the idealized random 243 permutation block cipher model is increased from an order 2**86 (for 244 DES) to 2**134 [Kilian96, Rogaway96]. 246 It should be noted that real cryptanalysis of DES-XEX3 might not use 247 brute force methods at all. Instead, it might be performed using 248 variants on differential [BS93] or linear [Matsui94] cryptanalysis. 249 It has been estimated that differential cryptanalysis is increased 250 from 2**47 (for DES) to 2**61 chosen-plaintext blocks, and linear 251 cryptanalysis is increased from 2**43 (for DES) to 2**60 known- 252 plaintext blocks [Kaliski96]. Although these attacks are not consid- 253 ered practical, this offers only a small improvement over DES alone. 255 It should also be noted that no encryption algorithm is permanently 256 safe from brute force attack, because of the increasing speed of mod- 257 ern computers. 259 As with all cryptosystems, those responsible for applications with 260 substantial risk when security is breeched should pay close attention 261 to developments in cryptology, and especially cryptanalysis, and 262 switch to other transforms should DES-XEX3 prove weak. 264 Acknowledgements 266 The basic field naming and layout is based on "swIPe" [IBK93, IB93]. 268 Most of the text of this specification was derived from earlier work 269 by William Allen Simpson and Perry Metzger in multiple Request for 270 Comments. 272 Use of DES-XEX3 was proposed by William Allen Simpson and various 273 other participants in the IETF IP Security Working Group in 1995 and 274 1996, but was prevented from publication through disregard of the 275 IETF Standards Process. 277 References 279 [BS93] Biham, E., and Shamir, A., "Differential Cryptanalysis of 280 the Data Encryption Standard", Berlin: Springer-Verlag, 281 1993. 283 [CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak 284 Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 285 23 pp. 253-280, July 1994. 287 [FIPS-46] US National Bureau of Standards, "Data Encryption Stan- 288 dard", Federal Information Processing Standard (FIPS) 289 Publication 46, January 1977. 291 [FIPS-46-1] US National Bureau of Standards, "Data Encryption Stan- 292 dard", Federal Information Processing Standard (FIPS) 293 Publication 46-1, January 1988. 295 [FIPS-74] US National Bureau of Standards, "Guidelines for Imple- 296 menting and Using the Data Encryption Standard", Federal 297 Information Processing Standard (FIPS) Publication 74, 298 April 1981. 300 [FIPS-81] US National Bureau of Standards, "DES Modes of Operation" 301 Federal Information Processing Standard (FIPS) Publica- 302 tion 81, December 1980. 304 [IB93] Ioannidis, J., and Blaze, M., "The Architecture and 305 Implementation of Network-Layer Security Under Unix", 306 Proceedings of the Fourth Usenix Security Symposium, 307 Santa Clara California, October 1993. 309 [IBK93] Ioannidis, J., Blaze, M., and Karn, P., "swIPe: Network- 310 Layer Security for IP", Presentation at the 26th Internet 311 Engineering Task Force, Columbus Ohio, March 1993. 313 [Kaliski96] Kaliski, B., and Robshaw, M., "Multiple Encryption: 314 Weighing Security and Performance", Dr. Dobbs Journal, 315 January 1996. 317 [Kilian96] Kilian J., and Rogaway, P., "How to protect DES against 318 exhaustive key search", Advances in Cryptology -- Crypto 319 '96 Proceedings, Berlin: Springer-Verlag, 1996, 320 http://wwwcsif.cs.ucdavis.edu/~rogaway. 322 [Matsui94] Matsui, M., "Linear Cryptanalysis method for DES Cipher," 323 Advances in Cryptology -- Eurocrypt '93 Proceedings, 324 Berlin: Springer-Verlag, 1994. 326 [Rogaway96] Rogaway, P., "The Security of DESX", CryptoBytes, v 2 n 327 2, RSA Laboratories, Redwood City, CA, USA, Summer 1996. 329 [RFC-1825x] Atkinson, R., "Security Architecture for the Internet 330 Protocol", Naval Research Laboratory, July 1995. 332 [RFC-1827x] Simpson, W., "IP Encapsulating Security Protocol (ESP) 333 for implementors", work in progress. 335 [RFC-1829] Karn, P., Metzger, P., Simpson, W.A., "The ESP DES-CBC 336 Transform", August 1995. 338 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, Harvard University, March 340 1997. 342 [RFC-wwww] Simpson, W.A, "ESP with Cipher Block Chaining (CBC)", 343 work in progress. 345 [Schneier95] 346 Schneier, B., "Applied Cryptography Second Edition", John 347 Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. 349 Contacts 351 Comments about this document should be discussed on the ipsec@tis.com 352 mailing list. 354 Questions about this document can also be directed to: 356 William Allen Simpson 357 DayDreamer 358 Computer Systems Consulting Services 359 1384 Fontaine 360 Madison Heights, Michigan 48071 362 wsimpson@UMich.edu 363 wsimpson@GreenDragon.com (preferred) 365 Robert Baldwin 366 RSA Data Security Inc. 367 100 Marine Parkway 368 Redwood City, California 94065 370 baldwin@rsa.com 372 Full Copyright Statement 374 Copyright (C) William Allen Simpson (1995-1996). Copyright (C) 375 William Allen Simpson and Robert Baldwin (1997-1998). All Rights 376 Reserved. 378 This document and translations of it may be copied and furnished to 379 others, and derivative works that comment on or otherwise explain it 380 or assist in its implementation may be prepared, copied, published 381 and distributed, in whole or in part, without restriction of any 382 kind, provided that the above copyright notice and this paragraph are 383 included on all such copies and derivative works. However, this doc- 384 ument itself may not be modified in any way, except as required to 385 translate it into languages other than English. 387 This document and the information contained herein is provided on an 388 "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR 389 IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF 390 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 391 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.