idnits 2.17.1 draft-baldwin-esp-rc5-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-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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** Bad filename characters: the document name given in the document, 'draft-baldwin-esp-rc5-00.txt.', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-baldwin-esp-rc5-00.txt.', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-baldwin-esp-rc5-00.txt.', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-baldwin-esp-rc5-00.txt.', but the file name used is 'draft-baldwin-esp-rc5-00' == 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 Abstract section. ** The document seems to lack a Security Considerations section. ** 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. ** 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 170: '...The value MUST NOT be zero....' RFC 2119 keyword, line 180: '...The IV size MUST be a multiple of 32-b...' RFC 2119 keyword, line 192: '...session key SHOULD be changed at least...' RFC 2119 keyword, line 212: '...After decryption, it MUST be ignored....' Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (March 1996) is 10268 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: 'Bell95' is defined on line 331, but no explicit reference was found in the text == Unused Reference: 'BS93' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'CN94' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'FIPS-46' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'FIPS-46-1' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'FIPS-74' is defined on line 350, but no explicit reference was found in the text == Unused Reference: 'FIPS-81' is defined on line 354, but no explicit reference was found in the text == Unused Reference: 'Matsui94' is defined on line 358, but no explicit reference was found in the text == Unused Reference: 'RFC-1446' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'RFC-1800' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'RFC-1826' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'RFC-1829' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'Weiner94' is defined on line 387, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Baldwin96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bell95' -- 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 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1800 (Obsoleted by RFC 1880) ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) -- Duplicate reference: RFC1827, mentioned in 'RFC-1829', was also mentioned in 'RFC-1827'. ** Obsolete normative reference: RFC 1827 (ref. 'RFC-1829') (Obsoleted by RFC 2406) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Weiner94' Summary: 21 errors (**), 1 flaw (~~), 16 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT B. W. Howard 2 Expires September 1, 1996 TimeStep Corporation 4 R. W. Baldwin 5 RSA Data Security, Inc. 6 March 1996 8 The ESP RC5-CBC Transform 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as ``work 21 in progress.'' 23 To learn the current status of any Internet-Draft, please check 24 the ``1id-abstracts.txt'' listing contained in the Internet- 25 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 26 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 27 Coast), or ftp.isi.edu (US West Coast). 29 The filename for this document is draft-baldwin-esp-rc5-00.txt. 31 Acknowledgments 33 This document was based on Karn, P. , Metzger., P., and Simpson, 34 W. "The ESP DES-CBC Transform" [RFC-1827]. Much of the original 35 text remains, with the RC5 specific portions added. We would 36 also like to thank Paul Kierstead and Stephane Lacelle for their 37 contributions. 39 Table of Contents 41 Executive Summary 42 1. Introduction 43 2. Payload Format 44 3. Algorithms 45 4. Security and Performance Considerations 46 References & Addresses of Authors 48 Executive Summary 50 This document describes the RC5-CBC security transform for the IP 51 Encapsulating Security Payload (ESP) based on the DES-CBC 52 transform described in RFC-1829 and RFC-1827. The RC5 cipher 53 allows for greater performance, security and exportability than 54 the DES cipher. A companion document [Baldwin96] describes RC5 55 1. Introduction 57 The Encapsulating Security Payload (ESP) [RFC-1827] provides 58 confidentiality for IP datagrams by encrypting the payload data to be 59 protected. This specification describes the use of the Cipher Block 60 Chaining (CBC) mode of RC5 which is described in [Baldwin96]. Much of 61 the text and ideas in this document were lifted directly from RFC 1829 62 by P. Karn, P. Metzger and W. Simpson. 64 Implementation of this transform is optional within the context of ESP 65 as only the DES-CBC transform is mandatory (RFC 1829). 67 This document assumes that the reader is familiar with the related 68 document "Security Architecture for the Internet Protocol" [RFC-1825], 69 which defines the overall security plan for IP, and provides important 70 background for this specification. 72 1.1 Background on RC5 74 The RC5 encryption algorithm was developed by Ron Rivest of RSA Data 75 Security Inc. in order to address the need for a high-performance 76 software ciphering alternative to DES. [Baldwin96] describes RC5-CBC 77 algorithm which expects the data size to be a multiple of the block 78 size. A second option, referred to as RC5-CBC-Pad proposes a standard 79 way of padding input such that arbitrary input sizes can be encrypted. 81 For the purposes of this proposal, the RC5-CBC algorithm is used, and 82 padding is added in a similar way as proposed in RFC-1829 for DES-CBC. 84 1.2 RC5 Parameters 86 Unlike the Data Encryption Standard, RC5 can be configured for varying 87 levels of security. The key size is variable, as are the number of 88 rounds and the data block size. In general, greater key sizes and 89 more rounds lead to greater security. Data block size is a parameter 90 intended to be used to efficiently accommodate various machine 91 architectures. 93 1.3. Initialization Vector (IV) 95 The CBC mode requires an IV for its operation. Each datagram contains 96 its own IV. Including the IV in each datagram ensures that decryption 97 of each received datagram can be performed, even when other datagrams 98 are dropped, or datagrams are reordered in transit. 100 The IV size depends on the data block size chosen (see 1.4 below). 101 Although IVs may exceed 64 bits, only 64-bit IVs and padded 32-bit IVs 102 are supported by this proposal. 104 The method for selection of IV values is implementation dependent. 106 1.4 RC5 Parameter Selection 108 Although it is recognized that essentially any combination of 109 parameters is possible, in order to simplify this proposal, this draft 110 offers two options, one for export, and one for domestic use. For 111 reference in this document, RC5_keySize, RC5_rounds and 112 RC5_dataBlockSize refer to each of the three parameter choices of key 113 bits, cipher rounds and data block size in octets respectively. 115 It is assumed that the key management mechanism negotiates the three 116 parameters. Although any parameter choices could be supported and 117 negotiated, compliant implementations must support the domestic and 118 export versions as follows: 120 Export: 121 RC5_keySize: 40 bits 122 RC5_rounds: 12 123 RC5_dataBlockSize: 8 octets 125 Domestic: 126 RC5_keySize: 128 bits 127 RC5_rounds: 12 128 RC5_dataBlockSize: 8 octets 130 1.4. Payload Length 132 The RC5 algorithm operates on blocks of a specific size, designated by 133 the RC5_dataBlockSize parameter. This often requires padding after 134 the end of the unencrypted payload data. 136 Both input and output result in the same number of octets, which 137 facilitates in-place encryption and decryption. 139 On receipt, if the length of the data to be decrypted is not an 140 integral multiple of RC5_dataBlockSize octets, then an error is 141 indicated, as described in [RFC-1825]. 143 1.5. Performance 145 RC5 shines above DES and many other encryption algorithms with respect 146 to software performance. As such, it is an excellent candidate since 147 IP security will often be from workstations or laptops where hardware 148 accelerators are an unlikely option. Performance figures may be added 149 in future revisions of this document. 151 2. Payload Format 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---+-+-+-+ 154 | Security Parameters Index (SPI) | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | | 157 ~ Initialization Vector (IV) ~ 158 | | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | | 161 ~ Payload Data ~ 162 | | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 ... Padding | Pad Length | Payload Type | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Security Parameters Index (SPI) 169 A 32-bit value identifying the Security Parameters for this datagram. 170 The value MUST NOT be zero. 172 Initialization Vector (IV) 174 The size of this field is variable, although its size is constant for 175 all RC5-CBC datagrams with the same SPI and IP Destination. Octets 176 are sent in network order such that the octet of the IV that is 177 transmitted first is XOR'ed with the octet of the payload data that is 178 transmitted first, and so on [RFC-1700]. 180 The IV size MUST be a multiple of 32-bits. Sizes of 32 and 64 bits 181 are required to be supported. The use of other sizes is beyond the 182 scope of this specification. The size is expected to be indicated by 183 the key management mechanism. 185 When the size is 32-bits, a 64-bit IV is formed from the 32-bit value 186 followed by (concatenated with) the bit-wise complement of the 32-bit 187 value. This field size is most common, as it aligns the Payload Data 188 for both 32-bit and 64-bit processing. 190 It is the intent that the value not repeat during the lifetime of the 191 encryption session key. Even when a full 64-bit IV is used, the 192 session key SHOULD be changed at least as frequently as 2**32 193 datagrams. 195 Payload Data 197 The size of this field is variable. 199 Prior to encryption and after decryption, this field begins with the 200 IP Protocol/Payload header specified in the Payload Type field. Note 201 that in the case of IP-in-IP encapsulation (Payload Type 4), this will 202 be another IP header. 204 Padding 206 The size of this field is variable. 208 Prior to encryption, it is filled with unspecified implementation 209 dependent (preferably random) values, to align the Pad Length and 210 Payload Type fields at an RC5_dataBlockSize octet boundary. 212 After decryption, it MUST be ignored. 214 Pad Length 216 This field indicates the size of the Padding field. It does not 217 include the Pad Length and Payload Type fields. The value typically 218 ranges from 0 to (RC5_dataBlockSize-1), but may be up to 255 to permit 219 hiding of the actual data length. 221 This field is opaque. That is, the value is set prior to encryption, 222 and is examined only after decryption. 224 Payload Type 226 This field indicates the contents of the Payload Data field, using the 227 IP Protocol/Payload value. Up-to-date values of the IP 228 Protocol/Payload are specified in the most recent "Assigned Numbers" 229 [RFC-1700]. 231 This field is opaque. That is, the value is set prior to encryption, 232 and is examined only after decryption. 234 For example, when encrypting an entire IP datagram (Tunnel- Mode), 235 this field will contain the value 4, which indicates IP-in-IP 236 encapsulation. 238 3. Algorithms 240 Block Ciphers (such as DES and RC5) can be used in a Cipher-Block 241 Chaining mode where the base encryption function is applied to the XOR 242 of each plaintext block with the previous ciphertext block to yield 243 the ciphertext for the current block. This provides for re- 244 synchronization when datagrams are lost. 246 For more explanation, see [Schneier94]; or see [Baldwin96] for more 247 specific details of CBC as it relates to RC5. 249 3.1. Encryption 251 Append zero or more octets of (preferably random) padding to the 252 plaintext, to make its length modulo RC5_dataBlockSize equal to 6. 253 For example if the RC5_dataBlockSize were 8 and the plaintext length 254 is 41, 5 octets of padding are added. 256 Append a Pad Length octet containing the number of padding octets just 257 added. 259 Append a Payload Type octet containing the IP Protocol/Payload value 260 which identifies the protocol header that begins the payload. 262 Provide an Initialization Vector (IV) of the size indicated by the 263 SPI. 265 Encrypt the payload with RC5 in CBC mode, producing a ciphertext of 266 the same length. 268 Octets are encrypted in network order [RFC-1700]. Octet 0 (modulo 8) 269 of the payload corresponds to first byte of input to an RC5-CBC block, 270 while octet 7 (modulo 8) corresponds to the last byte of input to an 271 RC5 block. See [baldwin96] for details on RC5-CBC. 273 Construct an appropriate IP datagram for the target Destination, with 274 the indicated SPI, IV, and payload. 276 The Total/Payload Length in the encapsulating IP Header reflects the 277 length of the encrypted data, plus the SPI, IV, padding, Pad Length, 278 and Payload Type octets. 280 3.2. Decryption 282 First, the SPI field is removed and examined. This is used as an 283 index into the local Security Parameter table to find the negotiated 284 parameters and decryption key. 286 The negotiated form of the IV determines the size of the IV field. 287 These octets are removed, and an appropriate 64-bit IV value is 288 constructed. 290 The encrypted part of the payload is decrypted using RC5 in the CBC 291 mode. 293 The Payload Type is removed and examined. If it is unrecognized, the 294 payload is discarded with an appropriate ICMP message. 296 The Pad Length is removed and examined. The specified number of pad 297 octets are removed from the end of the decrypted payload, and the IP 298 Total/Payload Length is adjusted accordingly. 300 The IP Header(s) and the remaining portion of the decrypted payload 301 are passed to the protocol receive routine specified by the Payload 302 Type field. 304 4. Security and Performance Considerations 306 The security of RC5 is dependent on the key length and number of 307 rounds. In general, twelve rounds are adequate for RC5 with 64 bit 308 blocks for any given key length. The performance of RC5 is in 309 proportion to the number of rounds, and is not affected by the key 310 size. 312 In the case of a 40-bit key, [Baldwin96] recommends the use of salt 313 bits and a strong digesting algorithm to produce 128-bit keys (in a 314 2^40 element key-space). This has the advantage of thwarting attacks 315 which precompute key-search tables based on 40 bits. This option is 316 not used in this proposal since the mechanism for agreeing upon such 317 keys would be handled by the key-negotiation phase, not during the 318 encapsulation phase. 320 As of March 1996, RC5 using a 40-bit key had not yet been approved for 321 general export from the United States or Canada. There is reason for 322 optimism, however, judging from past approvals of other 40-bit 323 algorithms. 325 References 327 [Baldwin96] Baldwin, R.W., and Rivest R.L., "The RC5, RC5-CBC, RC5- 328 CBC-Pad, and RC5-CTS Algorithms", RSA Data Security Inc., March 329 1996. 331 [Bell95] Bellovin, S., "An Issue With DES-CBC When Used Without 332 Strong Integrity", Proceedings of the 32nd IETF, Danvers, MA, 333 April 1995. 335 [BS93] Biham, E., and Shamir, A., "Differential Cryptanalysis of the 336 Data Encryption Standard", Berlin: Springer-Verlag, 1993. 338 [CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data: 339 Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 253-280, 340 July 1994. 342 [FIPS-46] US National Bureau of Standards, "Data Encryption Standard", 343 Federal Information Processing Standard (FIPS) Publication 46, 344 January 1977. 346 [FIPS-46-1] US National Bureau of Standards, "Data Encryption 347 Standard", Federal Information Processing Standard (FIPS) 348 Publication 46-1, January 1988. 350 [FIPS-74] US National Bureau of Standards, "Guidelines for 351 Implementing and Using the Data Encryption Standard", Federal 352 Information Processing Standard (FIPS) Publication 74, April 1981. 354 [FIPS-81] US National Bureau of Standards, "DES Modes of Operation" 355 Federal Information Processing Standard (FIPS) Publication 81, 356 December 1980. 358 [Matsui94] Matsui, M., "Linear Cryptanalysis method dor DES Cipher," 359 Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin: 360 Springer-Verlag, 1994. 362 [RFC-1446] Galvin, J., and McCloghrie, K., "Security Protocols for 363 Version 2 of the Simple Network Management Protocol (SNMPv2)", 364 RFC-1446, DDN Network Information Center, April 1993. 366 [RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, 367 RFC-1700, USC/Information Sciences Institute, October 1994. 369 [RFC-1800] Postel, J., "Internet Official Protocol Standards", STD 1, 370 RFC-1800, USC/Information Sciences Institute, July 1995. 372 [RFC-1825] Atkinson, R., "Security Architecture for the Internet 373 Protocol", RFC-1825, Naval Research Laboratory, July 1995. 375 [RFC-1826] Atkinson, R., "IP Authentication Header", RFC-1826, Naval 376 Research Laboratory, July 1995. 378 [RFC-1827] Atkinson, R., "IP Encapsulating Security Protocol (ESP)", 379 RFC-1827, Naval Research Laboratory, July 1995. 381 [RFC-1829] Karn, P. , Metzger., P., and Simpson, W. "The ESP DES-CBC 382 Transform" RFC-1827, Naval Research Laboratory, August 1995. 384 [Schneier94] Schneier, B., "Applied Cryptography", John Wiley & Sons, 385 New York, NY, 1994. ISBN 0-471-59756-2 387 [Weiner94] Wiener, M.J., "Efficient DES Key Search", School of 388 Computer Science, Carleton University, Ottawa, Canada, TR-244, May 389 1994. Presented at the Rump Session of Crypto '93. 391 Addresses of Authors 393 Brett W. Howard 394 TimeStep Corporation 395 359 Terry Fox Drive 396 Nepean, Ontario 397 Canada K2H 6K3 399 Phone: (613) 599-3610 x4554 400 Fax: (613) 599-3617 401 Email: bretth@timestep.com 403 Robert W. Baldwin 404 RSA Data Security, Inc. 405 100 Marine Parkway 406 Redwood City, CA 94065 408 Phone: (415) 595-8782 409 Fax: (415) 595-1873 410 Email: baldwin@rsa.com, or baldwin@lcs.mit.edu 412 This internet-draft that expires on September 1, 1996.