idnits 2.17.1 draft-ietf-smime-hmac-key-wrap-01.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: ---------------------------------------------------------------------------- ** 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 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. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 6) being 59 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 abstract seems to contain references ([3DES-WRAP], [AES-WRAP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 228 has weird spacing: '...herwise call ...' == Unrecognized Status in 'Category: Standards', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (February 2003) is 7733 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? 'RFC2026' on line 14 looks like a reference -- Missing reference section? '3DES-WRAP' on line 129 looks like a reference -- Missing reference section? 'AES-WRAP' on line 226 looks like a reference -- Missing reference section? 'HMAC' on line 59 looks like a reference -- Missing reference section? 'STDWORDS' on line 56 looks like a reference -- Missing reference section? '3DES' on line 69 looks like a reference -- Missing reference section? 'RANDOM' on line 289 looks like a reference -- Missing reference section? 'DSS' on line 290 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 J. Schaad 3 Internet Draft Soaring Hawk Consulting 4 draft-ietf-smime-hmac-key-wrap-01.txt R. Housley 5 Category: Standards Vigil Security 6 February 2003 8 Wrapping an HMAC key with a Triple-DES Key or an AES Key 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]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- Drafts 21 as reference material or to cite them other than as "work in 22 progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The key wrap algorithms defined in [3DES-WRAP] and [AES-WRAP] cover 31 the of wrapping a Triple-DES key with another Triple-DES key and 32 wrapping an AES key with another AES key, respectively. This 33 document specifies two similar mechanisms. One specifies the 34 mechanism for wrapping an HMAC key with a Triple-DES key, and the 35 other specifies the mechanism for wrapping an HMAC key with an AES 36 key. 38 1. Introduction 40 Standard methods exist for encrypting a Triple-DES (3DES) content- 41 encryption key (CEK) with a 3DES key-encryption key (KEK) [3DES- 42 WRAP] and for encrypting an AES CEK with an AES KEK [AES-WRAP]. 43 Triple-DES key wrap imposes parity restrictions, and in both 44 instances there are restrictions on the size of the key being 45 wrapped that make the encryption of HMAC [HMAC] keying material 46 difficult. 48 This document specifies a mechanism for the encryption of an HMAC 49 key of arbitrary length by a 3DES KEK or an AES KEK. 51 HMAC Key Wrap February 2002 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [STDWORDS]. 57 2. HMAC Key Guidelines 59 [HMAC] suggests that the key be at least as long as the output (L) 60 of the hash function being used. When keys longer than the block 61 size of the hash algorithm are used, they are hashed and the 62 resulting hash value is used. Using keys much longer than L 63 provides no security benefit, unless the random function used to 64 create the key has low entropy output. 66 3. HMAC Key Wrapping and Unwrapping with Triple-DES 68 This section specifies the algorithms for wrapping and unwrapping an 69 HMAC key with a 3DES KEK [3DES]. 71 The 3DES wrapping of HMAC keys is based on the algorithm defined in 72 Section 3 of [3DES-WRAP]. The major differences are due to the fact 73 that an HMAC key is variable length and the HMAC key has no 74 particular parity. 76 3.1 Wrapping an HMAC Key with a Triple-DES Key-Encryption Key 78 This algorithm encrypts an HMAC key with a 3DES KEK. The algorithm 79 is: 81 1. Let the HMAC key be called KEY, and let the length of KEY in 82 octets be called LENGTH. LENGTH is a single octet. 83 2. Let LKEY = LENGTH || KEY. 84 3. Let LKEYPAD = LKEY || PAD. If the length of LKEY is a multiple 85 of 8, the PAD has a length of zero. If the length of LKEY is 86 not a multiple of 8, then PAD contains the fewest number of 87 random octets to make the length of LKEYPAD a multiple of 8. 88 4. Compute an 8 octet key checksum value on LKEYPAD as described 89 in Section 2 of [3DES-WRAP], call the result ICV. 90 5. Let LKEYPADICV = LKEYPAD || ICV. 91 6. Generate 8 octets at random, call the result IV. 92 7. Encrypt LKEYPADICV in CBC mode using the 3DES KEK. 93 Use the random value generated in the previous step as the 94 initialization vector (IV). Call the ciphertext TEMP1. 95 8. Let TEMP2 = IV || TEMP1. 96 9. Reverse the order of the octets in TEMP2. That is, the most 97 significant (first) octet is swapped with the least significant 98 (last) octet, and so on. Call the result TEMP3. 99 10. Encrypt TEMP3 in CBC mode using the 3DES KEK. Use 100 an initialization vector (IV) of 0x4adda22c79e82105. 102 HMAC Key Wrap February 2002 104 Note: When the same HMAC key is wrapped in different 3DES KEKs, a 105 fresh initialization vector (IV) must be generated for each 106 invocation of the HMAC key wrap algorithm. 108 3.2 Unwrapping an HMAC Key with a Triple-DES Key-Encryption Key 110 This algorithm decrypts an HMAC key using a 3DES KEK. The algorithm 111 is: 113 1. If the wrapped key is not a multiple of 8 octets, then error. 114 2. Decrypt the wrapped key in CBC mode using the 3DES KEK. 115 Use an initialization vector (IV) of 0x4adda22c79e82105. Call 116 the output TEMP3. 117 3. Reverse the order of the octets in TEMP3. That is, the most 118 significant (first) octet is swapped with the least significant 119 (last) octet, and so on. Call the result TEMP2. 120 4. Decompose the TEMP2 into IV and TEMP1. IV is the most 121 significant (first) 8 octets, and TEMP1 is the remaining octets. 122 5. Decrypt TEMP1 in CBC mode using the 3DES KEK. Use 123 the IV value from the previous step as the initialization 124 vector. Call the plaintext LKEYPADICV. 125 6. Decompose the LKEYPADICV into LKEYPAD, and ICV. ICV is the 126 least significant (last) octet 8 octets. LKEYPAD is the 127 remaining octets. 128 7. Compute an 8 octet key checksum value on LKEYPAD as described 129 in Section 2 of [3DES-WRAP]. If the computed key checksum value 130 does not match the decrypted key checksum value, ICV, then 131 error. 132 8. Decompose the LKEYPAD into LENGTH, KEY, and PAD. LENGTH is the 133 most significant (first) octet. KEY is the following LENGTH 134 octets. PAD is the remaining octets, if any. 135 9. If the length of PAD is more than 7 octets, then error. 136 10. Use KEY as an HMAC key. 138 3.3 HMAC Key Wrap with Triple-DES Algorithm Identifier 140 Some security protocols employ ASN.1 [X.208-88, X.209-88], and these 141 protocols employ algorithm identifiers to name cryptographic 142 algorithms. To support these protocols, the HMAC Key Wrap with 143 Triple-DES algorithm has been assigned the following algorithm 144 identifier: 146 id-alg-HMACwith3DESwrap OBJECT IDENTIFIER ::= { iso(1) 147 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 148 smime(16) alg(3) 11 } 150 The AlgorithmIdentifier parameter field MUST be NULL. 152 3.4 HMAC Key Wrap with Triple-DES Test Vector 154 KEK : 5840df6e 29b02af1 155 : ab493b70 5bf16ea1 156 : ae8338f4 dcc176a8 157 HMAC Key Wrap February 2002 159 HMAC_KEY : c37b7e64 92584340 160 : bed12207 80894115 161 : 5068f738 163 IV : 050d8c79 e0d56b75 165 PAD : 38be62 167 ICV : 1f363a31 cdaa9037 169 LKEYPADICV : 14c37b7e 64925843 170 : 40bed122 07808941 171 : 155068f7 38be62fe 172 : 1f363a31 cdaa9037 174 TEMP1 : 157a8210 f432836b 175 : a618b096 475c864b 176 : 6612969c dfa445b1 177 : 5646bd00 500b2cc1 179 TEMP3 : c12c0b50 00bd4656 180 : b145a4df 9c961266 181 : 4b865c47 96b018a6 182 : 6b8332f4 10827a15 183 : 756bd5e0 798c0d05 185 Wrapped Key : 0f1d715d 75a0aaf6 186 : 6f02e371 c08b79e2 187 : a1253dc4 3040136b 188 : dc161118 601f2863 189 : e2929b3b dd17697c 191 4. HMAC Key Wrapping and Unwrapping with AES 193 This section specifies the algorithms for wrapping and unwrapping an 194 HMAC key with an AES KEK [AES-WRAP]. 196 The AES wrapping of HMAC keys is based on the algorithm defined in 197 [AES-WRAP]. The major difference is inclusion of padding due to the 198 fact that the length of an HMAC key may not be a multiple of 64 199 bits. 201 4.1 Wrapping an HMAC Key with an AES Key-Encryption Key 203 This algorithm encrypts an HMAC key with an AES KEK. The algorithm 204 is: 206 1. Let the HMAC key be called KEY, and let the length of KEY in 207 octets be called LENGTH. LENGTH is a single octet. 208 2. Let LKEY = LENGTH || KEY. 209 3. Let LKEYPAD = LKEY || PAD. If the length of LKEY is a multiple 210 of 8, the PAD has a length of zero. If the length of LKEY is 211 HMAC Key Wrap February 2002 213 not a multiple of 8, then PAD contains the fewest number of 214 random octets to make the length of LKEYPAD a multiple of 8. 215 4. Encrypt LKEYPAD using the AES key wrap algorithm specified in 216 section 2.2.1 of [AES-WRAP], using the AES KEK as the encryption 217 key. The result is 8 octets longer than LKEYPAD. 219 4.2 Unwrapping an HMAC Key with an AES Key 221 The AES key unwrap algorithm decrypts an HMAC key using an AES KEK. 222 The AES key unwrap algorithm is: 224 1. If the wrapped key is not a multiple of 8 octets, then error. 225 2. Decrypt the wrapped key using the AES key unwrap algorithm 226 specified in section 2.2.2 of [AES-WRAP], using the AES KEK as 227 the decryption key. If the unwrap algorithm internal integrity 228 check fails, then error, otherwise call the result LKEYPAD. 229 3. Decompose the LKEYPAD into LENGTH, KEY, and PAD. LENGTH is the 230 most significant (first) octet. KEY is the following LENGTH 231 octets. PAD is the remaining octets, if any. 232 4. If the length of PAD is more than 7 octets, then error. 233 5. Use KEY as an HMAC key. 235 4.3 HMAC Key Wrap with AES 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 HMAC Key Wrap with AES 240 algorithm has been assigned the following algorithm identifier: 242 id-alg-HMACwithAESwrap OBJECT IDENTIFIER ::= { iso(1) 243 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 244 smime(16) alg(3) 12 } 246 The AlgorithmIdentifier parameter field MUST be NULL. 248 4.4 HMAC Key Wrap with AES Test Vector 250 KEK : 5840df6e 29b02af1 251 : ab493b70 5bf16ea1 252 : ae8338f4 dcc176a8 254 HMAC_KEY : c37b7e64 92584340 255 : bed12207 80894115 256 : 5068f738 258 PAD : 050d8c 260 LKEYPAD : 14c37b7e 64925843 261 : 40bed122 07808941 262 : 155068f7 38050d8c 264 Wrapped Key : 9fa0c146 5291ea6d 265 : b55360c6 cb95123c 266 HMAC Key Wrap February 2002 268 : d47b38cc e84dd804 269 : fbcec5e3 75c3cb13 271 5. Security Considerations 273 Implementations must protect the key-encryption key (KEK). 274 Compromise of the KEK may result in the disclosure of all HMAC keys 275 that have been wrapped with the KEK, which may lead to loss of data 276 integrity protection. 278 The use of these key wrap functions provide confidentiality and data 279 integrity, but they do not necessarily provide data origination 280 authentication. Anyone possessing the KEK can create a message that 281 passes the integrity check. If data origination authentication is 282 also desired, then the KEK distribution mechanism must provide data 283 origin authentication of the KEK. Alternatively, a digital 284 signature may be used. 286 Implementations must randomly generate initialization vectors (IVs) 287 and padding. The generation of quality random numbers is difficult. 289 RFC 1750 [RANDOM] offers important guidance in this area, and 290 Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG 291 technique. 293 The key wrap algorithms specified in this document have been 294 reviewed for use with Triple-DES and AES, and they have not been 295 reviewed for use with other encryption algorithms. 297 6. References 299 This section provides normative and informative references. 301 6.1 Normative References 303 3DES American National Standards Institute. ANSI X9.52-1998, 304 Triple Data Encryption Algorithm Modes of Operation. 305 1998. 307 3DES-WRAP Housley, R., Triple-DES and RC2 Key Wrapping. RFC 3217. 308 December 2001. 310 AES National Institute of Standards and Technology. 311 FIPS Pub 197: Advanced Encryption Standard (AES). 312 26 November 2001. 314 AES-WRAP Schaad, J., R. Housley, AES Key Wrap Algorithm, 315 draft-ietf-smime-aes-wrap-00.txt. 317 HMAC Krawczyk, H., M. Bellare, and R. Canetti. HMAC: Keyed- 318 Hashing for Message Authentication. RFC 2104. 319 February 1997. 321 STDWORDS Bradner, S., "Key words for use in RFCs to Indicate 322 HMAC Key Wrap February 2002 324 Requirement Levels", BCP 14, RFC 2119, March 1997 326 6.2 Informative References 328 DSS National Institute of Standards and Technology. 329 FIPS Pub 186: Digital Signature Standard. 19 May 1994. 331 RANDOM Eastlake, D., S. Crocker, and J. Schiller. Randomness 332 Recommendations for Security. RFC 1750. December 1994. 334 RFC2026 Bradner, S., "The Internet Standards Process - Revision 335 3", BCP 9, RFC 2026, October 1996. 337 X.208-88 CCITT. Recommendation X.208: Specification of Abstract 338 Syntax Notation One (ASN.1). 1988. 340 X.209-88 CCITT. Recommendation X.209: Specification of Basic 341 Encoding Rules for Abstract Syntax Notation One (ASN.1). 342 1988. 344 7. Author's Addresses 346 Jim Schaad 347 Soaring Hawk Consulting 349 Email: jimsch@exmsft.com 351 Russell Housley 352 Vigil Security 353 918 Spring Knoll Drive 354 Herndon, VA 20170 355 USA 357 Email: housley@vigilsec.com 358 HMAC Key Wrap February 2002 360 Full Copyright Statement 362 "Copyright (C) The Internet Society 2002. All Rights Reserved. 364 This document and translations of it may be copied and furnished to 365 others, and derivative works that comment on or otherwise explain it 366 or assist in its implementation may be prepared, copied, published 367 and distributed, in whole or in part, without restriction of any 368 kind, provided that the above copyright notice and this paragraph 369 are included on all such copies and derivative works. However, this 370 document itself may not be modified in any way, such as by removing 371 the copyright notice or references to the Internet Society or other 372 Internet organizations, except as needed for the purpose of 373 developing Internet standards in which case the procedures for 374 copyrights defined in the Internet Standards process must be 375 followed, or as required to translate it into languages other than 376 English. 378 The limited permissions granted above are perpetual and will not be 379 revoked by the Internet Society or its successors or assigns.