idnits 2.17.1 draft-housley-aes-key-wrap-with-pad-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 234: '...tifier parameter field MUST be absent....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 June 2009) is 5423 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 193 -- No information found for draft-smime-newasn1 - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT R. Housley 3 Intended Status: Informational Vigil Security 4 M. Dworkin 5 NIST 6 Expires: 15 January 2010 15 June 2009 8 Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm 9 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Copyright Notice 33 Copyright (c) 2009 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents in effect on the date of 38 publication of this document (http://trustee.ietf.org/license-info). 39 Please review these documents carefully, as they describe your rights 40 and restrictions with respect to this document. 42 Abstract 44 This document specifies a padding convention for use with the AES Key 45 Wrap algorithm specified in RFC 3394. This convention eliminates the 46 requirement that the length of the key to be wrapped is a multiple of 47 64 bits, allowing a key of any practical length to be wrapped. 49 1. Introduction 50 Management of cryptographic keys often leads to situations where a 51 symmetric key is used to encrypt and integrity protect another key, 52 which can be either a symmetric key or an asymmetric key. The 53 operation is often called key wrapping. 55 This document specifies an extension of the Advanced Encryption 56 Standard (AES) Key Wrap algorithm [AES-KW1,AES-KW2]. Without this 57 extension, the input to the AES Key Wrap algorithm, called the key 58 data, must be a sequence of two or more 64-bit blocks. 60 The AES Key Wrap with Padding algorithm can be used to wrap a key of 61 any practical size with an AES key. The AES key-encryption key (KEK) 62 must be 128, 192, or 256 bits. The input key data may be as short as 63 9 octets, which will result in an output of two 64-bit blocks or 16 64 octets. Although the AES Key Wrap algorithm does not place a maximum 65 bound on the size of the key data that can be wrapped, this extension 66 does so. The use of a 32-bit fixed field to carry the octet length 67 of the key data bounds the size of the input at 2^32 octets. Most 68 systems will have other factors that limit the practical size of key 69 data to much less than 2^32 octets. 71 A message length indicator (MLI) is defined as part of an 72 "Alternative Initial Value" in keeping with the statement in section 73 2.2.3.2 of [AES-KW1], which says: 75 Also, if the key data is not just an AES key, it may not always be 76 a multiple of 64 bits. Alternative definitions of the initial 77 value can be used to address such problems. 79 2. Notation and Definitions 81 The following notation is used in the algorithm descriptions: 83 MSB(j, W) Return the most significant j bits of W 84 LSB(j, W) Return the least significant j bits of W 85 B1 | B2 Concatenate B1 and B2 86 K The key-encryption key 87 m The number of octets in the key data 88 n The number of 64-bit blocks in the padded key data 89 Q[i] The ith plaintext octet in the key data 90 P[i] The ith 64-bit plaintext block in the padded key data 91 C[i] The ith 64-bit ciphertext data block 92 A The 64-bit integrity check register 94 3. Alternative Initial Value 96 The Alternative Initial Value (AIV) required by this specification is 97 a 32-bit constant concatenated to a 32-bit MLI. The constant is (in 98 hexadecimal) A65959A6 and occupies the high-order half of the AIV. 99 Note that this differs from the high order 32 bits of the default IV 100 in [AES-KW1] Section 2.2.3.1, so there is no ambiguity between the 101 two. The 32-bit MLI, which occupies the low-order half of the AIV, 102 is an unsigned binary integer equal to the octet length of the 103 plaintext key data, in network order, that is with the most 104 significant octet first. When the MLI is not a multiple of 8, the 105 key data is padded on the right with the least number of octets 106 sufficient to make a multiple of 8. The value of each padding octet 107 shall be 0 (eight binary zeros). 109 Notice that for a given number of 64-bit plaintext blocks, there are 110 only eight values of MLI that can have that outcome. For example, 111 the only MLI values that are valid with four 64-bit plaintext blocks 112 are 32 (with no padding octets), 31 (with one padding octet), 30, 29, 113 28, 27, 26, and 25 (with seven padding octets). When the AES Key 114 Unwrap yields n 64-bit blocks of key data with an AIV, the eight 115 valid values for the MLI are 8*n, (8*n)-1, ..., and (8*n)-7. 116 Therefore, the integrity check for the AIV requires the following 117 steps: 119 1) Check that MSB(32,A) = A65959A6. 121 2) Check that 8*(n-1) < LSB(32,A) <= 8*n. If so, let 122 MLI = LSB(32,A). 124 3) Let b = (8*n)-MLI, and then check that the rightmost b octets of 125 the plaintext are zero. 127 If all three checks pass, then the AIV is valid. If any of the 128 checks fail, then the AIV is invalid and the AES Key Unwrap operation 129 must return an error. 131 4. Specification of the AES Key Wrap with Padding Algorithm 133 The AES Key Wrap with Padding algorithm consists of a wrapping 134 process and an unwrapping process, both based on the AES codebook 135 [AES]. It provides an extension to the AES Key Wrap algorithm 136 [AES-KW1,AES-KW2] that eliminates the requirement that the length of 137 the key to be wrapped is a multiple of 64 bits. The next two 138 sections specify the wrapping and unwrapping processes, called the 139 Extended Key Wrapping process and the Extended Key Unwrapping 140 process, respectively. These names distinguish these processes from 141 the ones specified in [AES-KW1,AES-KW2]. 143 4.1. Extended Key Wrapping Process 145 The inputs to the extended key wrapping process are the KEK and the 146 plaintext to be wrapped. The plaintext consists of between 9 and 147 2^32 octets, containing the key data being wrapped. The key wrapping 148 process is described below. 150 Inputs: Plaintext, m octets {Q1, Q2, ..., Qm}, and 151 Key, K (the KEK). 152 Outputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}. 154 1) Append padding 156 If m is not a multiple of 8, pad the plaintext octet string on 157 the right with octets {Qm+1, ..., Qr} of zeros, where r is the 158 smallest multiple of 8 that is greater than m. If m is a 159 multiple of 8, then there is no padding, and r = m. 161 Set n = r/8, which is the same as CEILING(m/8). 163 For i = 1, ..., n 164 j = 8*(i-1) 165 P[i] = Q[j+1] | Q[j+2] | ... | Q[j+8] . 167 2) Wrapping 169 Apply the wrapping process specified in Section 2.2.1 of 170 [AES-KW2] to the padded plaintext {P1, ..., Pn} and K (the KEK), 171 with the AIV as defined in Section 3 above as the initial value. 172 The result is n+1 64-bit blocks {C0, C1, ..., Cn}. 174 4.2 Extended Key Unwrapping Process 176 The inputs to the extended key unwrapping process are the KEK and 177 (n+1) 64-bit ciphertext blocks consisting of a previously wrapped 178 key. If the ciphertext is a validly wrapped key, then the (original) 179 unwrapping process returns n 64-bit plaintext blocks, which are then 180 mapped in this extension to m octets of decrypted key data, as 181 indicated by the MLI embedded in the AIV. 183 Inputs: Ciphertext, (n+1) 64-bit blocks {C0, C1, ..., Cn}, and 184 Key, K (the KEK). 185 Outputs: Plaintext, m octets {Q1, Q2, ..., Qm}, or an error. 187 1) Key unwrapping 189 Apply Steps 1 and 2 of the unwrapping process specified in 190 Section 2.2.2 of [AES-KW2] to the n+1 64-bit ciphertext blocks, 191 {C0, C1, ..., Cn}, and the KEK, K. Define the padded plaintext 192 blocks, {P1, ..., Pn}, as specified in Step 3 of that process, 193 with A[0] as the A value. Note that checking "If A[0] is an 194 appropriate value" is slightly delayed to Step 2 below since the 195 padded plaintext is needed to perform this verification when the 196 AIV is used. 198 2) AIV verification 200 Perform the three checks described in Section 3 above on the 201 padded plaintext and the A value. If any of the checks fail, 202 then return an error. 204 3) Remove padding 206 Let m = the MLI value extracted from A. 208 Let P = P1 | P2 | ... | Pn. 210 For i = 1, ... , m 211 Q[i] = LSB(8, MSB(8*i, P)) 213 5. Algorithm Identifiers 215 Some security protocols employ ASN.1 [X.690], and these protocols 216 employ algorithm identifiers to name cryptographic algorithms. To 217 support these protocols, the AES Key Wrap with Padding algorithm has 218 been assigned the following algorithm identifiers, one for each AES 219 KEK size. The AES Key Wrap (without padding) algorithm identifiers 220 are also included here for convenience. 222 aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 223 us(840) organization(1) gov(101) csor(3) 224 nistAlgorithm(4) 1 } 226 id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 } 227 id-aes128-wrap-pad OBJECT IDENTIFIER ::= { aes 8 } 229 id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 } 230 id-aes192-wrap-pad OBJECT IDENTIFIER ::= { aes 28 } 231 id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 } 232 id-aes256-wrap-pad OBJECT IDENTIFIER ::= { aes 48 } 234 In all cases, the AlgorithmIdentifier parameter field MUST be absent. 236 6. Padded Key Wrap Example 238 The example in this section was generated using the index-based 239 implementation of the AES Key Wrap algorithm along with the padding 240 approach specified in Section 4 of this document. The example wraps 241 20 octets of Key Data with a 192-bit KEK. All values are shown in 242 hexadecimal. 244 KEK : 5840df6e29b02af1 ab493b705bf16ea1 ae8338f4dcc176a8 246 Key : c37b7e6492584340 bed1220780894115 5068f738 248 Wrap : 138bdeaa9b8fa7fc 61f97742e72248ee 5ae6ae5360d1ae6a 249 : 5f54f373fa543b6a 251 7. Security Considerations 253 Implementations must protect the key-encryption key (KEK). 254 Compromise of the KEK may result in the disclosure of all keys that 255 have been wrapped with the KEK, which may lead to the compromise of 256 all traffic protected with those wrapped keys. 258 The KEK must be at least as good as the keying material it is 259 protecting. 261 If the KEK and wrapped key are associated with different 262 cryptographic algorithms, the effective security provided to data 263 protected with the wrapped key is determined by the weaker of the two 264 algorithms. If, for example, data is encrypted with 128-bit AES and 265 that AES key is wrapped with a 256-bit AES key, then at most 128 bits 266 of protection is provided to the data. If, for another example, a 267 128-bit AES key is used to wrap a 4096-bit RSA private key, then at 268 most 128 bits of protection is provided to any data that depends on 269 that private key. Thus, implementers must ensure that key-encryption 270 algorithms are as strong or stronger than other cryptographic 271 algorithms employed in an overall system. 273 The AES Key Wrap and the AES Key Wrap with Padding algorithms use 274 different constants in the initial value. The use of different 275 values ensures that the recipient of padded key data cannot 276 successfully unwrap it as unpadded key data, or vice versa. This 277 remains true when the key data is wrapped using the AES Key Wrap with 278 Padding algorithm but no padding is needed. 280 The AES Key Wrap with Padding algorithm provides almost the same 281 amount of integrity protection as the AES Key Wrap algorithm. 283 A previous padding technique was specified for wrapping HMAC keys 284 with AES [OLD-KW]. The technique in this document is preferred, and 285 the technique in this document is not limited to wrapping HMAC keys. 287 The key wrapping technique specified in this document requires the 288 length of the key data to be at least nine octets because a single 289 application of the AES codebook is sufficient to protect up to eight 290 octets of key data. In particular, if the key data consists of eight 291 or fewer octets, then a 64-bit integrity check value could be 292 prepended to the key data to form a single 128-bit block. For 293 example, the integrity check value could consist of a fixed seven 294 octet value followed by a single octet length value. The wrapping 295 and unwrapping processes employing such an integrity check value and 296 a single AES codebook operation could be defined analogous to those 297 in Section 4 if there is a need to wrap keys that are smaller than 298 nine octets. 300 In the design of some high assurance cryptographic modules, it is 301 desirable to segregate cryptographic keying material from other data. 302 The use of a specific cryptographic mechanism solely for the 303 protection of cryptographic keying material can assist in this goal. 304 The AES Key Wrap and the AES Key Wrap with Pad are such mechanisms. 305 System designers should not use these algorithms to encrypt anything 306 other than cryptographic keying material. 308 8. IANA Considerations 310 No IANA actions are required. 312 {{{ RFC Editor: Please remove this section prior to publication. }}} 314 9. References 316 9.1. Normative References 318 [AES] National Institute of Standards and Technology. FIPS Pub 319 197: Advanced Encryption Standard (AES). 26 November 2001. 321 [AES-KW1] National Institute of Standards and Technology. AES Key 322 Wrap Specification. 17 November 2001. 323 [http://csrc.nist.gov/groups/ST/toolkit/documents/kms/ 324 AES_key_wrap.pdf] 326 [AES-KW2] J. Schaad and R. Housley, "Advanced Encryption Standard 327 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 329 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 330 Information technology - Abstract Syntax Notation One 331 (ASN.1): Specification of basic notation. 333 9.2. Informative References 335 [AES-CMS] J. Schaad, "Use of the Advanced Encryption Standard (AES) 336 Encryption Algorithm in Cryptographic Message Syntax 337 (CMS)", RFC 3565, July 2003. 339 [CMS-ASN] J. Schaad and P. Hoffman, "New ASN.1 Modules for CMS and 340 S/MIME", draft-smime-newasn1-05.txt, work-in-progress. 342 [OLD-KW] J. Schaad and R. Housley, "Wrapping a Hashed Message 343 Authentication Code (HMAC) key with a Triple-Data 344 Encryption Standard (DES) Key or an Advanced 345 Encryption Standard (AES) Key", RFC 3537, May 2003. 347 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002, 348 Information Technology - Abstract Syntax Notation One: 349 Information Object Specification. 351 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002, 352 Information Technology - Abstract Syntax Notation One: 353 Constraint Specification. 355 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002, 356 Information Technology - Abstract Syntax Notation One: 357 Parameterization of ASN.1 Specifications. 359 10. Acknowledgments 361 Paul Timmel should be credited with the MLI and padding technique 362 described in this document. 364 Appendix A: ASN.1 Modules 366 This appendix includes two ASN.1 modules. The first one makes use of 367 the 1988 syntax, and the second one makes use of the 2002 ASN.1 368 syntax. 370 Appendix A.1 provides the normative ASN.1 definitions for the 371 algorithm identifiers included in this specification using ASN.1 as 372 defined in [X.680] using the 1988 ASN.1 syntax. 374 Appendix A.2 provides informative ASN.1 definitions for the algorithm 375 identifiers included in this specification using ASN.1 as defined in 376 [X.680], [X.681], [X.682], and [X.683] using the 2002 ASN.1 syntax. 377 This appendix contains the same information as Appendix A.1; however, 378 Appendix A.1 takes precedence in case of conflict. The content 379 encryption and key wrap algorithm objects are defined in [CMS-ASN]. 381 The id-aes128-wrap, id-aes192-wrap, and id-aes256-wrap algorithm 382 identifiers are defined in [AES-CMS]. 384 A.1. 1988 ASN.1 Module 386 AESKeyWrapWithPad-88 { iso(1) member-body(2) us(840) rsadsi(113549) 387 pkcs(1) pkcs-9(9) smime(16) modules(0) 47 } 389 DEFINITIONS IMPLICIT TAGS ::= 390 BEGIN 392 -- EXPORTS ALL -- 394 -- IMPORTS NONE -- 396 -- AES information object identifiers -- 398 aes OBJECT IDENTIFIER ::= { 399 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 400 csor(3) nistAlgorithms(4) 1 } 402 -- AES Key Wrap With Padding Algorithm Identifiers are to be used 403 -- with the Parameter field absent 405 id-aes128-wrap-pad OBJECT IDENTIFIER ::= { aes 8 } 406 id-aes192-wrap-pad OBJECT IDENTIFIER ::= { aes 28 } 407 id-aes256-wrap-pad OBJECT IDENTIFIER ::= { aes 48 } 409 END 411 A.2. 2002 ASN.1 Module 413 AESKeyWrapWithPad-02 { iso(1) member-body(2) us(840) rsadsi(113549) 414 pkcs(1) pkcs-9(9) smime(16) modules(0) 48 } 416 DEFINITIONS IMPLICIT TAGS ::= 417 BEGIN 419 -- EXPORTS ALL -- 420 IMPORTS 421 AlgorithmIdentifier{}, CONTENT-ENCRYPTION, KEY-WRAP, SMIME-CAPS 422 FROM AlgorithmInformation-2009 -- [CMS-ASN] 423 { iso(1) identified-organization(3) dod(6) internet(1) 424 security(5) mechanisms(5) pkix(7) id-mod(0) 425 id-mod-algorithmInformation-02(58) }; 427 AES-ContentEncryption CONTENT-ENCRYPTION ::= { 428 cea-aes128-wrap-pad | 429 cea-aes192-wrap-pad | 430 cea-aes256-wrap-pad, 431 ... } 433 AES-KeyWrap KEY-WRAP ::= { 434 kwa-aes128-wrap-pad | 435 kwa-aes192-wrap-pad | 436 kwa-aes256-wrap-pad, 437 ... } 439 SMimeCaps SMIME-CAPS ::= { 440 cea-aes128-wrap-pad.&smimeCaps | 441 cea-aes192-wrap-pad.&smimeCaps | 442 cea-aes256-wrap-pad.&smimeCaps | 443 kwa-aes128-wrap-pad.&smimeCaps | 444 kwa-aes192-wrap-pad.&smimeCaps | 445 kwa-aes256-wrap-pad.&smimeCaps, 446 ... } 448 -- AES object identifier 450 aes OBJECT IDENTIFIER ::= { 451 joint-iso-itu-t(2) country(16) us(840) organization(1) 452 gov(101) csor(3) nistAlgorithms(4) 1 } 454 -- Content Encryption Algorithms 456 cea-aes128-wrap-pad CONTENT-ENCRYPTION ::= { 457 IDENTIFIER id-aes128-wrap-pad 458 PARAMS ARE absent 459 SMIME-CAPS { IDENTIFIED BY id-aes128-wrap-pad } } 461 cea-aes192-wrap-pad CONTENT-ENCRYPTION ::= { 462 IDENTIFIER id-aes192-wrap-pad 463 PARAMS ARE absent 464 SMIME-CAPS { IDENTIFIED BY id-aes192-wrap-pad } } 466 cea-aes256-wrap-pad CONTENT-ENCRYPTION ::= { 467 IDENTIFIER id-aes256-wrap-pad 468 PARAMS ARE absent 469 SMIME-CAPS { IDENTIFIED BY id-aes256-wrap-pad } } 471 -- Key Wrap Algorithms 473 kwa-aes128-wrap-pad KEY-WRAP ::= { 474 IDENTIFIER id-aes128-wrap-pad 475 PARAMS ARE absent 476 SMIME-CAPS { IDENTIFIED BY id-aes128-wrap-pad } } 478 id-aes128-wrap-pad OBJECT IDENTIFIER ::= { aes 8 } 480 kwa-aes192-wrap-pad KEY-WRAP ::= { 481 IDENTIFIER id-aes192-wrap-pad 482 PARAMS ARE absent 483 SMIME-CAPS { IDENTIFIED BY id-aes192-wrap-pad } } 485 id-aes192-wrap-pad OBJECT IDENTIFIER ::= { aes 28 } 487 kwa-aes256-wrap-pad KEY-WRAP ::= { 488 IDENTIFIER id-aes256-wrap-pad 489 PARAMS ARE absent 490 SMIME-CAPS { IDENTIFIED BY id-aes256-wrap-pad } } 492 id-aes256-wrap-pad OBJECT IDENTIFIER ::= { aes 48 } 494 END 496 Authors' Addresses 498 Russell Housley 499 Vigil Security, LLC 500 918 Spring Knoll Drive 501 Herndon, VA 20170 502 USA 503 EMail: housley@vigilsec.com 505 Morris Dworkin 506 National Institute of Standards and Technology 507 100 Bureau Drive, Mail Stop 8930 508 Gaithersburg, MD 20899-8930 509 USA 510 EMail: dworkin@nist.gov