idnits 2.17.1 draft-metzger-esp-3des-cbc-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. ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 55: '...ad specification SHOULD implement this...' RFC 2119 keyword, line 101: '... The failure SHOULD be recorded in t...' RFC 2119 keyword, line 140: '... The field size MUST be a multiple of...' RFC 2119 keyword, line 146: '... implementations MUST correctly proces...' RFC 2119 keyword, line 161: '...ession key. The session key SHOULD be...' (1 more instance...) 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 (January 1995) is 10686 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'AMS-esp' -- 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. 'Matsui94' -- 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. 'MH81' -- Possible downref: Non-RFC (?) normative reference: ref. 'OW91' ** Obsolete normative reference: RFC 1610 (Obsoleted by RFC 1720) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Tuchman79' Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 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 P Karn 3 W A Simpson 4 expires in six months January 1995 6 The ESP Triple DES-CBC Transform 7 draft-metzger-esp-3des-cbc-00.txt 9 Status of this Memo 11 This document is a submission to the IP Security Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the ipsec@ans.net mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its Areas, 19 and its Working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months, and may be updated, replaced, or obsoleted by other documents 24 at any time. It is not appropriate to use Internet Drafts as 25 reference material, or to cite them other than as a ``working draft'' 26 or ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 30 Directories on: 32 ftp.is.co.za (Africa) 33 nic.nordu.net (Europe) 34 ds.internic.net (US East Coast) 35 ftp.isi.edu (US West Coast) 36 munnari.oz.au (Pacific Rim) 38 Abstract 40 This document describes the Triple DES-CBC security transform for the 41 Encapsulating Security Payload (ESP). 43 1. Introduction 45 The Encapsulating Security Payload (ESP) [AMS-esp] provides 46 confidentiality and integrity by encrypting the data to be protected. 47 This specification describes the ESP use of a variant of of the 48 Cipher Block Chaining (CBC) mode of the US Data Encryption Standard 49 (DES) algorithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81]. This 50 variant, known as Triple DES (3DES), encrypts each block of the 51 plaintext three times, each time with a different key [Tuchman79]. A 52 recent book also provides information on 3DES [Schneier94]. 54 All implementations that claim conformance or compliance with the 55 Encapsulating Security Payload specification SHOULD implement this 56 Triple DES-CBC transform. 58 Implementors should consult the most recent version of the IAB 59 Standards [RFC-1610] for further guidance on the status of this 60 document. 62 1.1. Keys 64 The secret 3DES key shared between the communicating parties is 65 effectively 168 bits long. This key consists of three independent 66 56-bit quantities used by the DES algorithm. Each of the three 56- 67 bit subkeys is stored as a 64-bit (eight octet) quantity, with the 68 least significant bit of each octet used as a parity bit. 70 1.2. Initialization Vector 72 This mode of 3DES requires an Initialization Vector (IV) that is 8 73 octets in length. 75 Each datagram contains its own IV. Including the IV in each datagram 76 ensures that decryption of each received datagram can be performed, 77 even when other datagrams are dropped, or datagrams are re-ordered in 78 transit. 80 The method for selection of the IV values is implementation 81 dependent. 83 Note: A common technique is simply a counter, beginning with a 84 randomly chosen value. Other implementations also exhibit 85 unpredictability, usually through a pseudo-random number 86 generator. Care should be taken that the periodicity of the 87 number generator is long enough to prevent repetition during the 88 lifetime of the session key. 90 1.3. Data Size 92 The 3DES algorithm operates on blocks of 8 octets. This often 93 requires padding after the end of the unencrypted payload data. 95 Both input and output result in the same number of octets, which 96 facilitates in-place encryption and decryption. 98 On receipt, if the length of the data to be decrypted is not an 99 integral multiple of 8 octets, then an error is indicated. The 100 datagram is discarded, and an appropriate ICMP message is returned. 101 The failure SHOULD be recorded in the system or audit log, including 102 the cleartext values for the SAID, date/time, Source, Destination, 103 and other identifying information. 105 1.4. Performance 107 Three DES-CBC implementations may be pipelined in series to provide 108 parallel computation. At the time of writing, at least one hardware 109 implementation can encrypt or decrypt at about 1 Gbps [Schneier94, p. 110 231]. 112 2. Payload Format 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Security Association Identifier (SAID) | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | | 118 ~ Initialization Vector (IV) ~ 119 | | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | | 122 ~ Payload Data ~ 123 | | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 ... Padding | Pad Length | Data Type | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 Security Association Identifier (SAID) 129 A 32-bit value identifying the Security Association for this 130 datagram. If no Security Association has been established, the 131 value of this field is zero. 133 Initialization Vector 135 The size of this field is variable, though for any given Security 136 Association it has a particular known size. Its position and size 137 is constant for all 3DES-CBC datagrams of the same SAID and IP 138 Destination. 140 The field size MUST be a multiple of 32-bits. Octets are sent in 141 network order. 143 The field may be longer or shorter than the 64-bits used by 3DES, 144 to allow alignment of the Encrypted Data for convenient in-place 145 decryption by the receiver. However, all conformant 146 implementations MUST correctly process a 64-bit field size. 148 When the size is negotiated to 0-bits, no IV is used. This is 149 primarily useful for highly random data, such as voice. 151 When the size is negotiated to 32-bits, a 64-bit value is formed 152 from the 32-bit value followed by (concatentated with) the inverse 153 of the 32-bit value. 155 When the size is negotiated to 96-bits or greater, the alignment 156 of the actual 64-bit value within this field is negotiated by an 157 additional parameter. Unused octets are filled with unspecified 158 implementation dependent values, which are ignored on receipt. 160 It is the intent that the value not repeat during the lifetime 161 of the encryption session key. The session key SHOULD be 162 changed more frequently for shorter IVs. 164 This field is considered to be transparent, though most users will 165 not be able to make sense of its contents. 167 Payload Data 169 The size of this field is variable. This field is opaque. 171 Prior to encryption and after decryption, the contents of this 172 field begins with an entire IP datagram (IP-Mode), or an IP 173 Payload header (Transport-Mode). 175 Padding 177 The size of this field is variable. This field is opaque. 179 Prior to encryption, it is filled with unspecified implementation 180 dependent values. 182 After decryption, it MUST be ignored. 184 Pad Length 186 This field indicates the size of the Padding field. It does not 187 include the Pad Length and Data Type fields. The value typically 188 ranges from 0 to 7, but may be up to 255 to permit hiding of the 189 actual data length. 191 This field is opaque. That is, the value is set prior to 192 encryption, and is examined only after decryption. 194 Data Type 196 This field indicates the contents of the Payload Data field, using 197 the IP Protocol/Payload value. Up-to-date values of the IP 198 Protocol/Payload are specified in the most recent "Assigned 199 Numbers" [RFC-1700]. 201 This field is opaque. That is, the value is set prior to 202 encryption, and is examined only after decryption. 204 For example, when encrypting an entire IP datagram (IP-Mode), 205 this field will contain the value 4, which indicates IP-in-IP 206 encapsulation. 208 3. Calculation 210 3.1. Algorithm 212 The 3DES-CBC algorithm is a simple variant on the DES-CBC algorithm. 213 The DES function is replaced by three rounds of that function, an 214 encryption followed by a decryption followed by an encryption, each 215 with independant keys, k1, k2 and k3. Formally, 217 3DES-CBC: C[n] = E[k3]( D[k2]( E[k1]( P[n] XOR C[n-1] ))) 218 P[n] = C[n-1] XOR D[k1]( E[k2]( D[k3]( C[n] ))) 220 E[k](X) indicates the DES encryption function with key k performed 221 upon block X. 223 D[k](X) indicates the DES decryption function with key k upon 224 block X. 226 P[n] indicates plaintext block n. 228 C[n] indicates cyphertext block n. 230 A XOR B indicates the bitwise exclusive-or of blocks A and B. 232 Note that when all three keys (k1, k2 and k3) are the same, 3DES-CBC 233 is equivalent to DES-CBC. This property allows the 3DES hardware 234 implementations to operate in DES mode without modification. 236 3.2. Encryption 238 Append zero or more octets of padding to the plain text, to make its 239 modulo 8 length equal to 6. 241 Append a Pad Length octet containing the number of padding octets 242 just added. 244 Append a Data Type octet containing the IP Protocol/Payload value 245 which identifies the protocol header that begins the payload. 247 Provide an Initialization Vector (IV) of the form indicated. 249 Encrypt the payload with Triple DES in CBC mode, producing a cipher 250 text of the same length. 252 Octets are mapped to DES blocks in network order. Octet 0 (modulo 8) 253 of the payload corresponds to bits 1-8 of the 64-bit DES input block, 254 while octet 7 (modulo 8) corresponds to bits 57-64 of the DES input 255 block. 257 Contruct a new IP datagram for that Destination, with the indicated 258 SAID, IV, and payload. 260 The Total Length in the IP Header reflects the length of the 261 encrypted data, plus the SAID, IV, padding, pad length, and data type 262 octets. 264 3.3. Decryption 266 First, the SAID field is examined. This is used as an index into the 267 local Security Association table to find the encryption algorithm 268 identifier and decryption key. 270 The negotiated form of the IV determines the size of the IV field. 271 These octets are removed, and an appropriate 64-bit IV value is 272 constructed. 274 The encrypted part of the payload is decrypted using Triple DES in 275 the CBC mode. 277 The Data Type is removed and examined. If it is unrecognized, the 278 payload is discarded with an appropriate ICMP message. 280 The Pad Length is removed and examined. The specified number of pad 281 octets are removed from the end of the decrypted payload, and the IP 282 Total Length is adjusted accordingly. 284 The IP Header(s) and the remaining portion of the decrypted payload 285 are passed to the protocol receive routine specified by the Data Type 286 field. 288 Security Considerations 290 Users need to understand that the quality of the security provided by 291 this specification depends completely on the strength of the Triple 292 DES algorithm, the correctness of that algorithm's implementation, 293 the security of the key management mechanism and its implementation, 294 the strength of the key [CN94], and upon the correctness of the 295 implementations in all of the participating systems. 297 Among other considerations, applications may wish to take care not to 298 select weak keys for any of the three DES rounds, although the odds 299 of picking one at random are low [Schneier94, p. 233]. 301 It was originally thought that DES might be a group, but it has been 302 demonstrated that it is not [CW92]. Since DES is not a group, 303 composition of multiple rounds of DES is not equivalent to simply 304 using DES with a different key. 306 Triple DES with independent keys is not, as naively might be 307 expected, as difficult to break by brute force as a cryptosystem with 308 three times the keylength. A space/time tradeoff has been shown 309 which can brute-force break triple block encryptions in the time 310 naively expected for double encryption [MH81]. 312 However, 2DES can be broken with a meet-in-the-middle attack, without 313 significantly more complexity than breaking DES requires [ibid], so 314 3DES with independant keys is actually needed to provide this level 315 of security. An attack on 3DES using two independent keys that is 316 somewhat (sixteen times) faster than any known for independent keys 317 has been shown [OW91]. 319 Although it is widely believed that 3DES is substantially stronger 320 than DES, as it is less amenable to brute force attack, it should be 321 noted that real cryptanalysis of 3DES might not use brute force 322 methods at all. Instead, it might be performed using variants on 323 differential [BS93] or linear [Matsui94] cryptanalysis. It should 324 also be noted that no encryption algorithm is permanently safe from 325 brute force attack, because of the increasing speed of modern 326 computers. 328 As with all cryptosystems, those responsible for applications with 329 substantial risk when security is breeched should pay close attention 330 to developments in cryptography, and especially cryptanalysis, and 331 switch to other transforms should 3DES prove weak. 333 Acknowledgements 335 The original text of this specification was derived from work by Ran 336 Atkinson for the SIP, SIPP, and IPv6 Working Groups. 338 References 340 [AMS-esp] 341 Randall Atkinson, Perry Metzger, William Simpson, 342 "Encapsulating Security Protocol (ESP)", work in progress. 344 [BS93] Biham, E., and Shamir, A., "Differential Cryptanalysis of 345 the Data Encryption Standard", Berlin: Springer-Verlag, 346 1993. 348 [CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data: 349 Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 350 253-280, July 1994. 352 [CW92] Campbell, K.W., and Wiener, M.J., "Proof that DES Is Not a 353 Group", Advances in Cryptology -- Crypto '92 Proceedings, 354 Berlin: Springer-Verlag, 1993, pp 518-526. 356 [Matsui94] 357 Matsui, M., "Linear Cryptanalysis method dor DES Cipher," 358 Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin: 359 Springer-Verlag, 1994. 361 [FIPS-46] 362 US National Bureau of Standards, "Data Encryption Standard", 363 Federal Information Processing Standard (FIPS) Publication 364 46, January 1977. 366 [FIPS-46-1] 367 US National Bureau of Standards, "Data Encryption Standard", 368 Federal Information Processing Standard (FIPS) Publication 369 46-1, January 1988. 371 [FIPS-74] 372 US National Bureau of Standards, "Guidelines for 373 Implementing and Using the Data Encryption Standard", 374 Federal Information Processing Standard (FIPS) Publication 375 74, April 1981. 377 [FIPS-81] 378 US National Bureau of Standards, "DES Modes of Operation" 379 Federal Information Processing Standard (FIPS) Publication 380 81, December 1980. 382 [MH81] Merle, R.C., and Hellman, M., "On the Security of Multiple 383 Encryption", Communications of the ACM, v. 24 n. 7, 1981, 384 pp. 465-467. 386 [OW91] van Oorschot, P.C., and Weiner, M.J. "A Known-Plaintext 387 Attack on Two-Key Triple Encryption", Advances in Cryptology 388 -- Eurocrypt '90 Proceedings, Berlin: Springer-Verlag, 1991, 389 pp. 318-325. 391 [RFC-1610] 392 Postel, J., "Internet Official Protocol Standards", STD 1, 393 RFC 1610, USC/Information Sciences Institute, July 1994. 395 [RFC-1700] 396 Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 397 1700, USC/Information Sciences Institute, October 1994. 399 [Schneier94] 400 Schneier, B., "Applied Cryptography", John Wiley & Sons, New 401 York, NY, 1994. ISBN 0-471-59756-2 403 [Tuchman79] 404 Tuchman, W, "Hellman Presents No Shortcut Solutions to DES", 405 IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41. 407 Author's Address 409 Questions about this memo can also be directed to: 411 Randall Atkinson 412 Information Technology Division 413 Naval Research Laboratory 414 Washington, 415 DC 20375-5320 416 USA 418 Telephone: (DSN) 354-8590 419 Fax: (DSN) 354-7942 420 422 Perry Metzger 423 Piermont Information Systems Inc. 424 160 Cabrini Blvd., Suite #2 425 New York, NY 10033 427 perry@piermont.com 429 Phil Karn 430 Qualcomm, Inc. 431 6455 Lusk Blvd. 432 San Diego, California 92121-2779 434 karn@unix.ka9q.ampr.org 436 William Allen Simpson 437 Daydreamer 438 Computer Systems Consulting Services 439 1384 Fontaine 440 Madison Heights, Michigan 48071 442 Bill.Simpson@um.cc.umich.edu 443 bsimpson@MorningStar.com 444 Table of Contents 446 1. Introduction .......................................... 1 447 1.1 Keys ............................................ 1 448 1.2 Initialization Vector ........................... 1 449 1.3 Data Size ....................................... 2 450 1.4 Performance ..................................... 2 452 2. Payload Format ........................................ 2 454 3. Calculation ........................................... 4 455 3.1 Algorithm ....................................... 4 456 3.2 Encryption ...................................... 5 457 3.3 Decryption ...................................... 6 459 SECURITY CONSIDERATIONS ...................................... 6 461 ACKNOWLEDGEMENTS ............................................. 7 463 REFERENCES ................................................... 7 465 AUTHOR'S ADDRESS ............................................. 9