idnits 2.17.1 draft-ietf-ipsec-esp-des-cbc-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-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. ** There are 12 instances of too long lines in the document, the longest one being 3 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 53: '...load specification MUST implement this...' RFC 2119 keyword, line 104: '... The failure SHOULD be recorded in t...' RFC 2119 keyword, line 132: '...datagram. The value MUST NOT be zero....' RFC 2119 keyword, line 140: '... The field size MUST be a multiple of...' RFC 2119 keyword, line 148: '... implementations MUST also correctly p...' (2 more instances...) 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 (March 1995) is 10627 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) == Unused Reference: 'FIPS-46' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'FIPS-46-1' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'FIPS-74' is defined on line 345, but no explicit reference was found in the text == Unused Reference: 'FIPS-81' is defined on line 351, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'A-SA' -- Possible downref: Non-RFC (?) normative reference: ref. 'A-ESP' -- 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. 'Matsui94' ** Downref: Normative reference to an Historic RFC: RFC 1446 ** 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. 'Weiner94' Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 13 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 March 1995 6 The ESP DES-CBC Transform 7 draft-ietf-ipsec-esp-des-cbc-03.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 DES-CBC security transform for the IP | 41 Encapsulating Security Payload (ESP). 43 1. Introduction 45 The Encapsulating Security Payload (ESP) [A-ESP] provides 46 confidentiality and integrity by encrypting the data to be protected. 48 This specification describes the ESP use of the Cipher Block Chaining 49 (CBC) mode of the US Data Encryption Standard (DES) algorithm [FIPS- 50 46, FIPS-46-1, FIPS-74, FIPS-81]. 52 All implementations that claim conformance or compliance with the 53 Encapsulating Security Payload specification MUST implement this 54 DES-CBC transform. 56 Implementors should consult the most recent version of the IAB 57 Standards [RFC-1610] for further guidance on the status of this 58 document. 60 This document assumes that the reader is familiar with the related 61 document "Security Architecture for the Internet Protocol" [A-SA], 62 which defines the overall security plan for IP, and provides 63 important background for this specification. 65 1.1. Keys 67 The secret DES key shared between the communicating parties is eight | 68 octets in length. This key consists of a 56-bit quantity used by the 69 DES algorithm. The 56-bit key is stored as a 64-bit (eight octet) 70 quantity, with the least significant bit of each octet used as a 71 parity bit. 73 1.2. Initialization Vector 75 This mode of DES requires an Initialization Vector (IV) that is eight | 76 octets in length. 78 Each datagram contains its own IV. Including the IV in each datagram 79 ensures that decryption of each received datagram can be performed, 80 even when other datagrams are dropped, or datagrams are re-ordered in 81 transit. 83 The method for selection of the IV values is implementation 84 dependent. 86 Note: A common technique is simply a counter, beginning with a 87 randomly chosen value. Other implementations also exhibit 88 unpredictability, usually through a pseudo-random number 89 generator. Care should be taken that the periodicity of the 90 number generator is long enough to prevent repetition during the 91 lifetime of the session key. 93 1.3. Data Size 95 The DES algorithm operates on blocks of eight octets. This often | 96 requires padding after the end of the unencrypted payload data. 98 Both input and output result in the same number of octets, which 99 facilitates in-place encryption and decryption. 101 On receipt, if the length of the data to be decrypted is not an 102 integral multiple of 8 octets, then an error is indicated. The 103 datagram is discarded, and an appropriate ICMP message is returned. 104 The failure SHOULD be recorded in the system or audit log, including | 105 the cleartext values for the Security Parameters Index (SPI), 106 date/time, Source, Destination, and other identifying information. 108 1.4. Performance 110 At the time of writing, at least one hardware implementation can 111 encrypt or decrypt at about 1 Gbps [Schneier94, p. 231]. 113 2. Payload Format 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Security Parameters Index (SPI) | | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | | 119 ~ Initialization Vector (IV) ~ 120 | | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | | 123 ~ Payload Data ~ 124 | | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 ... Padding | Pad Length | Data Type | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 Security Parameters Index (SPI) | 131 A 32-bit value identifying the Security Parameters for this 132 datagram. The value MUST NOT be zero. 134 Initialization Vector 136 The size of this field is variable, though for any given SPI it 137 has a particular known size. Its position and size are constant 138 for all DES-CBC datagrams of the same SPI and IP Destination. 140 The field size MUST be a multiple of 32-bits. Octets are sent in 141 network order. 143 When the size is 32-bits, a 64-bit value is formed from the 32-bit 144 value followed by (concatentated with) the bit-wise complement of 145 the 32-bit value. This field size is most common, as it aligns 146 the Payload Data for both 32-bit and 64-bit processing. 148 All conformant implementations MUST also correctly process a 64- 149 bit field size. This provides strict compatibility with existing 150 hardware implementations. 152 It is the intent that the value not repeat during the lifetime 153 of the encryption session key. Even when a full 64-bit IV is 154 used, the session key SHOULD be changed at least as frequently 155 as 2**32 datagrams. 157 This field is considered to be transparent, though most users will 158 not be able to make sense of its contents. 160 Payload Data 162 The size of this field is variable. This field is opaque. 164 Prior to encryption and after decryption, the contents of this 165 field begins with an entire IP datagram (Tunnel-Mode), or another 166 IP Protocol/Payload header (Transport-Mode). 168 Padding 170 The size of this field is variable. This field is opaque. 172 Prior to encryption, it is filled with unspecified implementation 173 dependent (preferably random) values. 175 After decryption, it MUST be ignored. 177 Pad Length 179 This field indicates the size of the Padding field. It does not 180 include the Pad Length and Data Type fields. The value typically 181 ranges from 0 to 7, but may be up to 255 to permit hiding of the 182 actual data length. 184 This field is opaque. That is, the value is set prior to 185 encryption, and is examined only after decryption. 187 Data Type 189 This field indicates the contents of the Payload Data field, using 190 the IP Protocol/Payload value. Up-to-date values of the IP 191 Protocol/Payload are specified in the most recent "Assigned 192 Numbers" [RFC-1700]. 194 This field is opaque. That is, the value is set prior to 195 encryption, and is examined only after decryption. 197 For example, when encrypting an entire IP datagram (Tunnel- 198 Mode), this field will contain the value 4, which indicates 199 IP-in-IP encapsulation. 201 3. Algorithm 203 In DES-CBC, the base DES encryption function is applied to the XOR of 204 each plaintext block with the previous ciphertext block to yield the 205 ciphertext for the current block. In formalized notation, 206 DES-CBC: C[n] = E[k](P[n] XOR C[n-1]) 207 P[n] = C[n-1] XOR D[k](C[n]) 209 E[k](X) indicates the DES encryption function with key k performed 210 upon block X. 212 D[k](X) indicates the DES decryption function with key k upon 213 block X. 215 P[n] indicates plaintext block n. 217 C[n] indicates ciphertext block n. 219 A XOR B indicates the bitwise exclusive-or of blocks A and B. 221 For more explanation and implementation information for DES, see 222 [Schneier94]. 224 3.1. Encryption 226 Append zero or more octets of (preferably random) padding to the 227 plaintext, to make its modulo 8 length equal to 6. For example, if 228 the plaintext length is 41, 5 octets of padding are added. 230 Append a Pad Length octet containing the number of padding octets 231 just added. 233 Append a Data Type octet containing the IP Protocol/Payload value 234 which identifies the protocol header that begins the payload. 236 Provide an Initialization Vector (IV) of the size indicated by the 237 SPI. 239 Encrypt the payload with DES in CBC mode, producing a ciphertext of 240 the same length. 242 Octets are mapped to DES blocks in network order. Octet 0 (modulo 8) 243 of the payload corresponds to bits 1-8 of the 64-bit DES input block, 244 while octet 7 (modulo 8) corresponds to bits 57-64 of the DES input 245 block. 247 Contruct a new IP datagram for the target Destination, with the 248 indicated SPI, IV, and payload. 250 The Total/Payload Length in the IP Header reflects the length of the 251 encrypted data, plus the SPI, IV, padding, pad length, and data type 252 octets. 254 3.2. Decryption 256 First, the SPI field is removed and examined. This is used as an | 257 index into the local Security Parameter table to find the negotiated | 258 parameters and decryption key. 260 The negotiated form of the IV determines the size of the IV field. 261 These octets are removed, and an appropriate 64-bit IV value is 262 constructed. 264 The encrypted part of the payload is decrypted using DES in the CBC 265 mode. 267 The Data Type is removed and examined. If it is unrecognized, the 268 payload is discarded with an appropriate ICMP message. 270 The Pad Length is removed and examined. The specified number of pad 271 octets are removed from the end of the decrypted payload, and the IP 272 Total/Payload Length is adjusted accordingly. 274 The IP Header(s) and the remaining portion of the decrypted payload 275 are passed to the protocol receive routine specified by the Data Type 276 field. 278 Security Considerations 280 Users need to understand that the quality of the security provided by 281 this specification depends completely on the strength of the DES 282 algorithm, the correctness of that algorithm's implementation, the 283 security of the key management mechanism and its implementation, the 284 strength of the key [CN94], and upon the correctness of the 285 implementations in all of the participating nodes. 287 Among other considerations, applications may wish to take care not to 288 select weak keys, although the odds of picking one at random are low 289 [Schneier94, p 233]. 291 At the time of writing of this document, [BS93] demonstrated a * 292 differential cryptanalysis based chosen-plaintext attack requiring 293 2^47 plaintext-ciphertext pairs, and [Matsui94] demonstrated a linear 294 cryptanalysis based known-plaintext attack requiring only 2^43 295 plaintext-ciphertext pairs. Although these attacks are not 296 considered practical, they must be taken into account. 298 More disturbingly, [Weiner94] has shown the design of a DES cracking 299 machine costing $1 Million that can crack one key every 3.5 hours. 300 This is an extremely practical attack. The Unicity distance for DES 301 is only a couple of blocks, and changing the session key frequently 302 will not mitigate the brute force attack. 304 It is suggested that DES is not a good encryption algorithm for the 305 protection of even moderate value information in the face of such 306 equipment. Triple DES is probably a better choice for such purposes. 308 Acknowledgements 310 Some of the text of this specification was derived from work by | 311 Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups. 313 The use of DES for confidentiality is closely modeled on the work 314 done for SNMPv2 [RFC-1446]. 316 Steve Bellovin, Steve Deering, Charles Lynn, and Dave Mihelcic 317 provided useful critiques of earlier versions of this draft. 319 References 321 [A-SA] Randall Atkinson, "Security Architecture for the Internet 322 Protocol", work in progress. 324 [A-ESP] Randall Atkinson, "IP Encapsulating Security Protocol 325 (ESP)", work in progress. 327 [BS93] Biham, E., and Shamir, A., "Differential Cryptanalysis of 328 the Data Encryption Standard", Berlin: Springer-Verlag, 329 1993. 331 [CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data: 332 Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 333 253-280, July 1994. 335 [FIPS-46] 336 US National Bureau of Standards, "Data Encryption Standard", 337 Federal Information Processing Standard (FIPS) Publication 338 46, January 1977. 340 [FIPS-46-1] 341 US National Bureau of Standards, "Data Encryption Standard", 342 Federal Information Processing Standard (FIPS) Publication 343 46-1, January 1988. 345 [FIPS-74] 346 US National Bureau of Standards, "Guidelines for 347 Implementing and Using the Data Encryption Standard", 348 Federal Information Processing Standard (FIPS) Publication 349 74, April 1981. 351 [FIPS-81] 352 US National Bureau of Standards, "DES Modes of Operation" 353 Federal Information Processing Standard (FIPS) Publication 354 81, December 1980. 356 [Matsui94] 357 Matsui, M., "Linear Cryptanalysis method dor DES Cipher," 358 Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin: 359 Springer-Verlag, 1994. 361 [RFC-1446] 362 Galvin, J., and McCloghrie, K., "Security Protocols for 363 Version 2 of the Simple Network Management Protocol 364 (SNMPv2)", RFC-1446, DDN Network Information Center, April 365 1993. 367 [RFC-1610] 368 Postel, J., "Internet Official Protocol Standards", STD 1, 369 RFC 1610, USC/Information Sciences Institute, July 1994. 371 [RFC-1700] 372 Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 373 1700, USC/Information Sciences Institute, October 1994. 375 [Schneier94] 376 Schneier, B., "Applied Cryptography", John Wiley & Sons, New 377 York, NY, 1994. ISBN 0-471-59756-2 379 [Weiner94] 380 Wiener, M.J., "Efficient DES Key Search", School of Computer 381 Science, Carleton University, Ottawa, Canada, TR-244, May 382 1994. Presented at the Rump Session of Crypto '93. 384 Author's Address 386 Questions about this memo can also be directed to: 388 Perry Metzger 389 Piermont Information Systems Inc. 390 160 Cabrini Blvd., Suite #2 391 New York, NY 10033 393 perry@piermont.com 395 Phil Karn 396 Qualcomm, Inc. 397 6455 Lusk Blvd. 398 San Diego, California 92121-2779 400 karn@unix.ka9q.ampr.org 402 William Allen Simpson 403 Daydreamer 404 Computer Systems Consulting Services 405 1384 Fontaine 406 Madison Heights, Michigan 48071 408 Bill.Simpson@um.cc.umich.edu 409 bsimpson@MorningStar.com 410 Table of Contents 412 1. Introduction .......................................... 1 413 1.1 Keys ............................................ 1 414 1.2 Initialization Vector ........................... 1 415 1.3 Data Size ....................................... 2 416 1.4 Performance ..................................... 2 418 2. Payload Format ........................................ 3 420 3. Algorithm ............................................. 4 421 3.1 Encryption ...................................... 5 422 3.2 Decryption ...................................... 6 424 SECURITY CONSIDERATIONS ...................................... 6 426 ACKNOWLEDGEMENTS ............................................. 7 428 REFERENCES ................................................... 7 430 AUTHOR'S ADDRESS ............................................. 8