idnits 2.17.1 draft-ietf-smime-key-wrap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 63 lines 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 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([3DES], [RC2], [CMS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 73: '...t, the key words MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 74: '... SHOULD NOT, RECOMMENDED, and MAY ar...' RFC 2119 keyword, line 81: '...y Triple-DES key MUST NOT be used to w...' RFC 2119 keyword, line 84: '...eys. RC2 128-bit keys MUST be used as...' RFC 2119 keyword, line 85: '...he wrapped RC2 key MAY be of any size....' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (September 2001) is 8258 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 section? '3DES' on line 100 looks like a reference -- Missing reference section? 'RC2' on line 174 looks like a reference -- Missing reference section? 'CMS' on line 40 looks like a reference -- Missing reference section? 'MODES' on line 324 looks like a reference -- Missing reference section? 'STDWORDS' on line 76 looks like a reference -- Missing reference section? 'SHA1' on line 92 looks like a reference -- Missing reference section? 'RANDOM' on line 306 looks like a reference -- Missing reference section? 'DSS' on line 307 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group R. Housley 3 Internet Draft RSA Laboratories 4 expires in six months September 2001 6 Triple-DES and RC2 Key Wrapping 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 To view the entire list of current Internet-Drafts, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 32 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 33 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 35 Abstract 37 This document specifies the algorithm for wrapping one Triple-DES 38 [3DES] key with another Triple-DES key and the algorithm for wrapping 39 one RC2 [RC2] key with another RC2 key. These key wrap algorithms 40 were originally published in section 12.6 of RFC 2630 [CMS]. They 41 are republished since these key wrap algorithms have been found to be 42 useful in contexts beyond those supported by RFC 2630. 44 This draft is being discussed on the "ietf-smime" mailing list. To 45 join the list, send a message to with 46 the single word "subscribe" in the body of the message. Also, there 47 is a Web site for the mailing list at . 50 1 Introduction 52 Management of symmetric cryptographic keys often leads to situations 53 where one symmetric key is used to encrypt (or wrap) another. Key 54 wrap algorithms are commonly used in two situations. First, key 55 agreement algorithms (such as Diffie-Hellman [DH-X9.42]) generate a 56 pairwise key-encryption key, and a key wrap algorithm is used to 57 encrypt the content-encryption key or a multicast key with the 58 pairwise key-encryption key. Second, a key wrap algorithm is used to 59 encrypt the content-encryption key, multicast key, or session key in 60 a locally generated storage key-encryption key or a key-encryption 61 key that was distributed out-of-band. 63 This document specifies the algorithm for wrapping one Triple-DES key 64 with another Triple-DES key [3DES] and specifies the algorithm for 65 wrapping one RC2 key with another RC2 key [RC2]. Encryption of a 66 Triple-DES key with another Triple-DES key uses the algorithm 67 specified in section 3. Encryption of a RC2 key with another RC2 key 68 uses the algorithm specified in section 4. Both of these algorithms 69 rely on the key checksum algorithm specified in section 2. Triple- 70 DES and RC2 content-encryption keys are encrypted in Cipher Block 71 Chaining (CBC) mode [MODES]. 73 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 74 SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described 75 by Scott Bradner in [STDWORDS]. 77 The same key wrap algorithm is used for both Two-key Triple-DES and 78 Three-key Triple-DES keys. When a Two-key Triple-DES key is to be 79 wrapped, a third DES key with the same value as the first DES key is 80 created. Thus, all wrapped Triple-DES keys include three DES keys. 81 However, a Two-key Triple-DES key MUST NOT be used to wrap a Three- 82 key Triple-DES key that is comprised of three unique DES keys. 84 RC2 supports variable length keys. RC2 128-bit keys MUST be used as 85 key-encryption keys; however, the wrapped RC2 key MAY be of any size. 87 2 Key Checksum 89 The key checksum algorithm is used to provide a key integrity check 90 value. The algorithm is: 92 1. Compute a 20 octet SHA-1 [SHA1] message digest on the key 93 that is to be wrapped. 94 2. Use the most significant (first) eight octets of the message 95 digest value as the checksum value. 97 3 Triple-DES Key Wrapping and Unwrapping 99 This section specifies the algorithms for wrapping and unwrapping one 100 Triple-DES key with another Triple-DES key [3DES]. 102 3.1 Triple-DES Key Wrap 104 The Triple-DES key wrap algorithm encrypts a Triple-DES key with a 105 Triple-DES key-encryption key. The Triple-DES key wrap algorithm is: 107 1. Set odd parity for each of the DES key octets comprising the 108 Three-Key Triple-DES key that is to be wrapped, call the result 109 CEK. 110 2. Compute an 8 octet key checksum value on CEK as described above 111 in Section 2, call the result ICV. 112 3. Let CEKICV = CEK || ICV. 113 4. Generate 8 octets at random, call the result IV. 114 5. Encrypt CEKICV in CBC mode using the key-encryption key. Use 115 the random value generated in the previous step as the 116 initialization vector (IV). Call the ciphertext TEMP1. 117 6. Let TEMP2 = IV || TEMP1. 118 7. Reverse the order of the octets in TEMP2. That is, the most 119 significant (first) octet is swapped with the least significant 120 (last) octet, and so on. Call the result TEMP3. 121 8. Encrypt TEMP3 in CBC mode using the key-encryption key. Use 122 an initialization vector (IV) of 0x4adda22c79e82105. 123 The ciphertext is 40 octets long. 125 Note: When the same Three-Key Triple-DES key is wrapped in different 126 key-encryption keys, a fresh initialization vector (IV) must be 127 generated for each invocation of the key wrap algorithm. 129 3.2 Triple-DES Key Unwrap 131 The Triple-DES key unwrap algorithm decrypts a Triple-DES key using a 132 Triple-DES key-encryption key. The Triple-DES key unwrap algorithm 133 is: 135 1. If the wrapped key is not 40 octets, then error. 136 2. Decrypt the wrapped key in CBC mode using the key-encryption 137 key. Use an initialization vector (IV) of 0x4adda22c79e82105. 138 Call the output TEMP3. 139 3. Reverse the order of the octets in TEMP3. That is, the most 140 significant (first) octet is swapped with the least significant 141 (last) octet, and so on. Call the result TEMP2. 142 4. Decompose TEMP2 into IV and TEMP1. IV is the most significant 143 (first) 8 octets, and TEMP1 is the least significant (last) 144 32 octets. 146 5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use 147 the IV value from the previous step as the initialization vector. 148 Call the ciphertext CEKICV. 149 6. Decompose CEKICV into CEK and ICV. CEK is the most significant 150 (first) 24 octets, and ICV is the least significant (last) 151 8 octets. 152 7. Compute an 8 octet key checksum value on CEK as described above 153 in Section 2. If the computed key checksum value does not 154 match the decrypted key checksum value, ICV, then error. 155 8. Check for odd parity each of the DES key octets comprising CEK. 156 If parity is incorrect, then error. 157 9. Use CEK as a Triple-DES key. 159 3.3 Triple-DES Key Wrap Algorithm Identifier 161 Some security protocols employ ASN.1 [X.208-88, X.209-88], and these 162 protocols employ algorithm identifiers to name cryptographic 163 algorithms. To support these protocols, the Triple-DES key wrap 164 algorithm has been assigned the following algorithm identifier: 166 id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 167 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } 169 The AlgorithmIdentifier parameter field MUST be NULL. 171 4 RC2 Key Wrapping and Unwrapping 173 This section specifies the algorithms for wrapping and unwrapping one 174 RC2 key with another RC2 key [RC2]. 176 4.1 RC2 Key Wrap 178 The RC2 key wrap algorithm encrypts a RC2 key with a RC2 key- 179 encryption key. The RC2 key wrap algorithm is: 181 1. Let the RC2 key be called CEK, and let the length of CEK in 182 octets be called LENGTH. LENGTH is a single octet. 183 2. Let LCEK = LENGTH || CEK. 184 3. Let LCEKPAD = LCEK || PAD. If the length of LCEK is a multiple 185 of 8, the PAD has a length of zero. If the length of LCEK is 186 not a multiple of 8, then PAD contains the fewest number of 187 random octets to make the length of LCEKPAD a multiple of 8. 188 4. Compute an 8 octet key checksum value on LCEKPAD as described 189 above in Section 2, call the result ICV. 190 5. Let LCEKPADICV = LCEKPAD || ICV. 191 6. Generate 8 octets at random, call the result IV. 192 7. Encrypt LCEKPADICV in CBC mode using the key-encryption key. 193 Use the random value generated in the previous step as the 194 initialization vector (IV). Call the ciphertext TEMP1. 195 8. Let TEMP2 = IV || TEMP1. 196 9. Reverse the order of the octets in TEMP2. That is, the most 197 significant (first) octet is swapped with the least significant 198 (last) octet, and so on. Call the result TEMP3. 199 10. Encrypt TEMP3 in CBC mode using the key-encryption key. Use 200 an initialization vector (IV) of 0x4adda22c79e82105. 202 Note: When the same RC2 key is wrapped in different key-encryption 203 keys, a fresh initialization vector (IV) must be generated for each 204 invocation of the key wrap algorithm. 206 4.2 RC2 Key Unwrap 208 The RC2 key unwrap algorithm decrypts a RC2 key using a RC2 key- 209 encryption key. The RC2 key unwrap algorithm is: 211 1. If the wrapped key is not a multiple of 8 octets, then error. 212 2. Decrypt the wrapped key in CBC mode using the key-encryption key. 213 Use an initialization vector (IV) of 0x4adda22c79e82105. Call 214 the output TEMP3. 215 3. Reverse the order of the octets in TEMP3. That is, the most 216 significant (first) octet is swapped with the least significant 217 (last) octet, and so on. Call the result TEMP2. 218 4. Decompose the TEMP2 into IV and TEMP1. IV is the most 219 significant (first) 8 octets, and TEMP1 is the remaining octets. 220 5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use 221 the IV value from the previous step as the initialization vector. 222 Call the plaintext LCEKPADICV. 223 6. Decompose the LCEKPADICV into LCEKPAD, and ICV. ICV is the 224 least significant (last) octet 8 octets. LCEKPAD is the 225 remaining octets. 226 7. Compute an 8 octet key checksum value on LCEKPAD as described 227 above in Section 2. If the computed key checksum value does 228 not match the decrypted key checksum value, ICV, then error. 229 8. Decompose the LCEKPAD into LENGTH, CEK, and PAD. LENGTH is the 230 most significant (first) octet. CEK is the following LENGTH 231 octets. PAD is the remaining octets, if any. 232 9. If the length of PAD is more than 7 octets, then error. 233 10. Use CEK as an RC2 key. 235 4.3 RC2 Key Wrap Algorithm Identifier 237 Some security protocols employ ASN.1 [X.208-88, X.209-88], and these 238 protocols employ algorithm identifiers to name cryptographic 239 algorithms. To support these protocols, the RC2 key wrap algorithm 240 has been assigned the following algorithm identifier: 242 id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) 243 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } 245 The AlgorithmIdentifier parameter field MUST be RC2wrapParameter: 247 RC2wrapParameter ::= RC2ParameterVersion 249 RC2ParameterVersion ::= INTEGER 251 The RC2 effective-key-bits (key size) greater than 32 and less than 252 256 is encoded in the RC2ParameterVersion. For the effective-key- 253 bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 254 and 58 respectively. These values are not simply the RC2 key length. 255 Note that the value 160 must be encoded as two octets (00 A0), 256 because the one octet (A0) encoding represents a negative number. 258 References 260 3DES American National Standards Institute. ANSI X9.52-1998, 261 Triple Data Encryption Algorithm Modes of Operation. 1998. 263 CMS Housley, R., "Cryptographic Message Syntax", RFC 2630, 264 June 1999. 266 DES American National Standards Institute. ANSI X3.106, 267 "American National Standard for Information Systems - Data 268 Link Encryption". 1983. 270 DH-X9.42 Rescorla, E. Diffie-Hellman Key Agreement Method. 271 RFC 2631. June 1999. 273 DSS National Institute of Standards and Technology. 274 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 276 MODES National Institute of Standards and Technology. 277 FIPS Pub 81: DES Modes of Operation. 2 December 1980. 279 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 280 Recommendations for Security. RFC 1750. December 1994. 282 RC2 Rivest, R. A Description of the RC2 (r) Encryption Algorithm. 283 RFC 2268. March 1998. 285 SHA1 National Institute of Standards and Technology. 286 FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. 288 STDWORDS Bradner, S. Key Words for Use in RFCs to Indicate 289 Requirement Levels. RFC2119. March 1997. 291 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 292 Syntax Notation One (ASN.1). 1988. 294 X.209-88 CCITT. Recommendation X.209: Specification of Basic Encoding 295 Rules for Abstract Syntax Notation One (ASN.1). 1988. 297 Security Considerations 299 Implementations must protect the key-encryption key. Compromise of 300 the key-encryption key may result in the disclosure of all keys that 301 have been wrapped with the key-encryption key, which may lead to the 302 disclosure of all traffic protected with those wrapped key. 304 Implementations must randomly generate initialization vectors (IVs) 305 and padding. The generation of quality random numbers is difficult. 306 RFC 1750 [RANDOM] offers important guidance in this area, and 307 Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique. 309 If the key-encryption key and wrapped key are associated with 310 different symmetric encryption algorithms, the effective security 311 provided to data encrypted with the wrapped key is determined by the 312 weaker of the two algorithms. If, for example, data is encrypted 313 with 168-bit Triple-DES and that Triple-DES key is wrapped with a 314 40-bit RC2 key, then at most 40 bits of protection is provided. A 315 trivial search to determine the value of the 40-bit RC2 key can 316 recover Triple-DES key, and then the Triple-DES key can be used to 317 decrypt the content. Therefore, implementers must ensure that key- 318 encryption algorithms are as strong or stronger than content- 319 encryption algorithms. 321 These key wrap algorithms specified in this document have been 322 reviewed for use with Triple-DES and RC2, and they have not been 323 reviewed for use with other encryption algorithms. Similarly, the 324 key wrap algorithms make use of CBC mode [MODES], and they have not 325 been reviewed for use with other cryptographic modes. 327 Acknowledgments 329 This document is the result of contributions from many professionals. 330 I appreciate the hard work of all members of the IETF S/MIME Working 331 Group. I extend a special thanks to Carl Ellison, Peter Gutmann, Bob 332 Jueneman, Don Johnson, and Burt Kaliski for their support in defining 333 these algorithms. 335 Author Address 337 Russell Housley 338 RSA Laboratories 339 918 Spring Knoll Drive 340 Herndon, VA 20170 341 USA 343 rhousley@rsasecurity.com 345 Full Copyright Statement 347 Copyright (C) The Internet Society (2001). All Rights Reserved. 349 This document and translations of it may be copied and furnished to 350 others, and derivative works that comment on or otherwise explain it 351 or assist in its implementation may be prepared, copied, published 352 and distributed, in whole or in part, without restriction of any 353 kind, provided that the above copyright notice and this paragraph are 354 included on all such copies and derivative works. In addition, the 355 ASN.1 module presented in Appendix A may be used in whole or in part 356 without inclusion of the copyright notice. However, this document 357 itself may not be modified in any way, such as by removing the 358 copyright notice or references to the Internet Society or other 359 Internet organizations, except as needed for the purpose of 360 developing Internet standards in which case the procedures for 361 copyrights defined in the Internet Standards process shall be 362 followed, or as required to translate it into languages other than 363 English. 365 The limited permissions granted above are perpetual and will not be 366 revoked by the Internet Society or its successors or assigns. This 367 document and the information contained herein is provided on an "AS 368 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 369 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 370 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 371 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 372 OR FITNESS FOR A PARTICULAR PURPOSE.