idnits 2.17.1 draft-housley-aes-key-wrap-with-pad-04.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 254: '...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 (27 July 2009) is 5385 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 212 -- 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: 27 February 2010 27 July 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 51 Management of cryptographic keys often leads to situations where one 52 symmetric key is used to encrypt and integrity protect another key, 53 which can be either a symmetric key or an asymmetric key. The 54 operation is often called key wrapping. 56 This document specifies an extension of the Advanced Encryption 57 Standard (AES) Key Wrap algorithm [AES-KW1,AES-KW2]. Without this 58 extension, the input to the AES Key Wrap algorithm, called the key 59 data, must be a sequence of two or more 64-bit blocks. 61 The AES Key Wrap with Padding algorithm can be used to wrap a key of 62 any practical size with an AES key. The AES key-encryption key (KEK) 63 must be 128, 192, or 256 bits. The input key data may be as short as 64 one octet, which will result in an output of two 64-bit blocks or 16 65 octets. Although the AES Key Wrap algorithm does not place a maximum 66 bound on the size of the key data that can be wrapped, this extension 67 does so. The use of a 32-bit fixed field to carry the octet length 68 of the key data bounds the size of the input at 2^32 octets. Most 69 systems will have other factors that limit the practical size of key 70 data to much less than 2^32 octets. 72 A message length indicator (MLI) is defined as part of an 73 "Alternative Initial Value" in keeping with the statement in section 74 2.2.3.2 of [AES-KW1], which says: 76 Also, if the key data is not just an AES key, it may not always be 77 a multiple of 64 bits. Alternative definitions of the initial 78 value can be used to address such problems. 80 2. Notation and Definitions 82 The following notation is used in the algorithm descriptions: 84 MSB(j, W) Return the most significant j bits of W 85 LSB(j, W) Return the least significant j bits of W 86 ENC(K, B) AES Encrypt the 128-bit block B using key K 87 DEC(K, B) AES Decrypt the 128-bit block B using key K 88 V1 | V2 Concatenate V1 and V2 89 K The key-encryption key 90 m The number of octets in the key data 91 n The number of 64-bit blocks in the padded key data 92 Q[i] The ith plaintext octet in the key data 93 P[i] The ith 64-bit plaintext block in the padded key data 94 C[i] The ith 64-bit ciphertext data block 95 A The 64-bit integrity check register 97 3. Alternative Initial Value 99 The Alternative Initial Value (AIV) required by this specification is 100 a 32-bit constant concatenated to a 32-bit MLI. The constant is (in 101 hexadecimal) A65959A6 and occupies the high-order half of the AIV. 102 Note that this differs from the high order 32 bits of the default IV 103 in [AES-KW1] Section 2.2.3.1, so there is no ambiguity between the 104 two. The 32-bit MLI, which occupies the low-order half of the AIV, 105 is an unsigned binary integer equal to the octet length of the 106 plaintext key data, in network order, that is with the most 107 significant octet first. When the MLI is not a multiple of 8, the 108 key data is padded on the right with the least number of octets 109 sufficient to make the resulting octet length a multiple of 8. The 110 value of each padding octet shall be 0 (eight binary zeros). 112 Notice that for a given number of 64-bit plaintext blocks, there are 113 only eight values of MLI that can have that outcome. For example, 114 the only MLI values that are valid with four 64-bit plaintext blocks 115 are 32 (with no padding octets), 31 (with one padding octet), 30, 29, 116 28, 27, 26, and 25 (with seven padding octets). When the unwrapping 117 process specified below yields n 64-bit blocks of output data and an 118 AIV, the eight valid values for the MLI are 8*n, (8*n)-1, ..., and 119 (8*n)-7. Therefore, integrity checking of the AIV, which is 120 contained in a 64-bit register called A, requires the following 121 steps: 123 1) Check that MSB(32,A) = A65959A6. 125 2) Check that 8*(n-1) < LSB(32,A) <= 8*n. If so, let 126 MLI = LSB(32,A). 128 3) Let b = (8*n)-MLI, and then check that the rightmost b octets of 129 the output data are zero. 131 If all three checks pass, then the AIV is valid. If any of the 132 checks fail, then the AIV is invalid and the unwrapping operation 133 must return an error. 135 4. Specification of the AES Key Wrap with Padding Algorithm 137 The AES Key Wrap with Padding algorithm consists of a wrapping 138 process and an unwrapping process, both based on the AES codebook 139 [AES]. It provides an extension to the AES Key Wrap algorithm 140 [AES-KW1,AES-KW2] that eliminates the requirement that the length of 141 the key to be wrapped is a multiple of 64 bits. The next two 142 sections specify the wrapping and unwrapping processes, called the 143 Extended Key Wrapping process and the Extended Key Unwrapping 144 process, respectively. These names distinguish these processes from 145 the ones specified in [AES-KW1,AES-KW2]. 147 4.1. Extended Key Wrapping Process 149 The inputs to the extended key wrapping process are the KEK and the 150 plaintext to be wrapped. The plaintext consists of between one and 151 2^32 octets, containing the key data being wrapped. The key wrapping 152 process is described below. 154 Inputs: Plaintext, m octets {Q1, Q2, ..., Qm}, and 155 Key, K (the KEK). 156 Outputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}. 158 1) Append padding 160 If m is not a multiple of 8, pad the plaintext octet string on the 161 right with octets {Qm+1, ..., Qr} of zeros, where r is the 162 smallest multiple of 8 that is greater than m. If m is a multiple 163 of 8, then there is no padding, and r = m. 165 Set n = r/8, which is the same as CEILING(m/8). 167 For i = 1, ..., n 168 j = 8*(i-1) 169 P[i] = Q[j+1] | Q[j+2] | ... | Q[j+8] . 171 2) Wrapping 173 If the padded plaintext contains exactly eight octets, then 174 prepend the AIV as defined in Section 3 above to P1 and encrypt 175 the resulting 128-bit block using AES in ECB mode [Modes] with key 176 K (the KEK). In this case the output is two 64-bit blocks C0 and 177 C1: 179 C0 | C1 = ENC(K, A | P1). 181 Otherwise, apply the wrapping process specified in Section 2.2.1 182 of [AES-KW2] to the padded plaintext {P1, ..., Pn} and K (the 183 KEK), with the AIV as defined in Section 3 above as the initial 184 value. The result is n+1 64-bit blocks {C0, C1, ..., Cn}. 186 4.2 Extended Key Unwrapping Process 188 The inputs to the extended key unwrapping process are the KEK and 189 (n+1) 64-bit ciphertext blocks consisting of a previously wrapped 190 key. If the ciphertext is a validly wrapped key, then the unwrapping 191 process returns n 64-bit blocks of padded plaintext, which are then 192 mapped in this extension to m octets of decrypted key data, as 193 indicated by the MLI embedded in the AIV. 195 Inputs: Ciphertext, (n+1) 64-bit blocks {C0, C1, ..., Cn}, and 196 Key, K (the KEK). 197 Outputs: Plaintext, m octets {Q1, Q2, ..., Qm}, or an error. 199 1) Key unwrapping 201 When n is one (n=1), the ciphertext contains exactly two 64-bit 202 blocks (C0 and C1), and they are decrypted as a single AES block 203 using AES in ECB mode [Modes] and K (the KEK) to recover the AIV 204 and the padded plaintext key: 206 A | P1 = DEC(K, C0 | C1). 208 Otherwise, apply Steps 1 and 2 of the unwrapping process specified 209 in Section 2.2.2 of [AES-KW2] to the n+1 64-bit ciphertext blocks, 210 {C0, C1, ..., Cn}, and the KEK, K. Define the padded plaintext 211 blocks, {P1, ..., Pn}, as specified in Step 3 of that process, 212 with A[0] as the A value. Note that checking "If A[0] is an 213 appropriate value" is slightly delayed to Step 2 below since the 214 padded plaintext is needed to perform this verification when the 215 AIV is used. 217 2) AIV verification 219 Perform the three checks described in Section 3 above on the 220 padded plaintext and the A value. If any of the checks fail, then 221 return an error. 223 3) Remove padding 225 Let m = the MLI value extracted from A. 227 Let P = P1 | P2 | ... | Pn. 229 For i = 1, ... , m 230 Q[i] = LSB(8, MSB(8*i, P)) 232 5. Algorithm Identifiers 234 Some security protocols employ ASN.1 [X.680], and these protocols 235 employ algorithm identifiers to name cryptographic algorithms. To 236 support these protocols, the AES Key Wrap with Padding algorithm has 237 been assigned the following algorithm identifiers, one for each AES 238 KEK size. The AES Key Wrap (without padding) algorithm identifiers 239 are also included here for convenience. 241 aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 242 us(840) organization(1) gov(101) csor(3) 243 nistAlgorithm(4) 1 } 245 id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 } 246 id-aes128-wrap-pad OBJECT IDENTIFIER ::= { aes 8 } 248 id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 } 249 id-aes192-wrap-pad OBJECT IDENTIFIER ::= { aes 28 } 251 id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 } 252 id-aes256-wrap-pad OBJECT IDENTIFIER ::= { aes 48 } 254 In all cases, the AlgorithmIdentifier parameter field MUST be absent. 256 6. Padded Key Wrap Examples 258 The examples in this section were generated using the index-based 259 implementation of the AES Key Wrap algorithm along with the padding 260 approach specified in Section 4 of this document. All values are 261 shown in hexadecimal. 263 The first example wraps 20 octets of Key Data with a 192-bit KEK. 265 KEK : 5840df6e29b02af1 ab493b705bf16ea1 ae8338f4dcc176a8 267 Key : c37b7e6492584340 bed1220780894115 5068f738 269 Wrap : 138bdeaa9b8fa7fc 61f97742e72248ee 5ae6ae5360d1ae6a 270 : 5f54f373fa543b6a 272 The second example wraps 7 octets of Key Data with a 192-bit KEK. 274 KEK : 5840df6e29b02af1 ab493b705bf16ea1 ae8338f4dcc176a8 276 Key : 466f7250617369 278 Wrap : afbeb0f07dfbf541 9200f2ccb50bb24f 280 7. Security Considerations 282 Implementations must protect the key-encryption key (KEK). 283 Compromise of the KEK may result in the disclosure of all keys that 284 have been wrapped with the KEK, which may lead to the compromise of 285 all traffic protected with those wrapped keys. 287 The KEK must be at least as good as the keying material it is 288 protecting. 290 If the KEK and wrapped key are associated with different 291 cryptographic algorithms, the effective security provided to data 292 protected with the wrapped key is determined by the weaker of the two 293 algorithms. If, for example, data is encrypted with 128-bit AES and 294 that AES key is wrapped with a 256-bit AES key, then at most 128 bits 295 of protection is provided to the data. If, for another example, a 296 128-bit AES key is used to wrap a 4096-bit RSA private key, then at 297 most 128 bits of protection is provided to any data that depends on 298 that private key. Thus, implementers must ensure that key-encryption 299 algorithms are at least as strong as other cryptographic algorithms 300 employed in an overall system. 302 The AES Key Wrap and the AES Key Wrap with Padding algorithms use 303 different constants in the initial value. The use of different 304 values ensures that the recipient of padded key data cannot 305 successfully unwrap it as unpadded key data, or vice versa. This 306 remains true when the key data is wrapped using the AES Key Wrap with 307 Padding algorithm but no padding is needed. 309 The AES Key Wrap with Padding algorithm provides almost the same 310 amount of integrity protection as the AES Key Wrap algorithm. 312 A previous padding technique was specified for wrapping HMAC keys 313 with AES [OLD-KW]. The technique in this document is more general; 314 the technique in this document is not limited to wrapping HMAC keys. 316 In the design of some high assurance cryptographic modules, it is 317 desirable to segregate cryptographic keying material from other data. 318 The use of a specific cryptographic mechanism solely for the 319 protection of cryptographic keying material can assist in this goal. 320 The AES Key Wrap and the AES Key Wrap with Pad are such mechanisms. 321 System designers should not use these algorithms to encrypt anything 322 other than cryptographic keying material. 324 8. IANA Considerations 326 No IANA actions are required. 328 {{{ RFC Editor: Please remove this section prior to publication. }}} 330 9. References 332 9.1. Normative References 334 [AES] National Institute of Standards and Technology. FIPS Pub 335 197: Advanced Encryption Standard (AES). 26 November 2001. 337 [AES-KW1] National Institute of Standards and Technology. AES Key 338 Wrap Specification. 17 November 2001. 339 [http://csrc.nist.gov/groups/ST/toolkit/documents/kms/ 340 AES_key_wrap.pdf] 342 [AES-KW2] Schaad, J., and R. Housley, "Advanced Encryption Standard 343 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 345 [Modes] Dworkin, M., "Recommendation for Block Cipher Modes of 346 Operation -- Methods and Techniques", NIST Special 347 Publication 800-38A, 2001. 349 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 350 Information technology - Abstract Syntax Notation One 351 (ASN.1): Specification of basic notation. 353 9.2. Informative References 355 [AES-CMS] Schaad, J., "Use of the Advanced Encryption Standard (AES) 356 Encryption Algorithm in Cryptographic Message Syntax 357 (CMS)", RFC 3565, July 2003. 359 [CMS-ASN] Schaad, J., and P. Hoffman, "New ASN.1 Modules for CMS and 360 S/MIME", draft-smime-newasn1-05.txt, work-in-progress. 362 [OLD-KW] Schaad, J., and R. Housley, "Wrapping a Hashed Message 363 Authentication Code (HMAC) key with a Triple-Data 364 Encryption Standard (DES) Key or an Advanced 365 Encryption Standard (AES) Key", RFC 3537, May 2003. 367 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002, 368 Information Technology - Abstract Syntax Notation One: 369 Information Object Specification. 371 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002, 372 Information Technology - Abstract Syntax Notation One: 373 Constraint Specification. 375 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002, 376 Information Technology - Abstract Syntax Notation One: 377 Parameterization of ASN.1 Specifications. 379 10. Acknowledgments 381 Paul Timmel should be credited with the MLI and padding technique 382 described in this document. 384 Appendix A: ASN.1 Modules 386 This appendix includes two ASN.1 modules. The first one makes use of 387 the 1988 syntax, and the second one makes use of the 2002 ASN.1 388 syntax. 390 Appendix A.1 provides the normative ASN.1 definitions for the 391 algorithm identifiers included in this specification using ASN.1 as 392 defined in [X.680] using the 1988 ASN.1 syntax. 394 Appendix A.2 provides informative ASN.1 definitions for the algorithm 395 identifiers included in this specification using ASN.1 as defined in 396 [X.680], [X.681], [X.682], and [X.683] using the 2002 ASN.1 syntax. 397 This appendix contains the same information as Appendix A.1; however, 398 Appendix A.1 takes precedence in case of conflict. The content 399 encryption and key wrap algorithm objects are defined in [CMS-ASN]. 401 The id-aes128-wrap, id-aes192-wrap, and id-aes256-wrap algorithm 402 identifiers are defined in [AES-CMS]. 404 A.1. 1988 ASN.1 Module 406 AESKeyWrapWithPad-88 { iso(1) member-body(2) us(840) rsadsi(113549) 407 pkcs(1) pkcs-9(9) smime(16) modules(0) 47 } 409 DEFINITIONS IMPLICIT TAGS ::= 410 BEGIN 412 -- EXPORTS ALL -- 414 -- IMPORTS NONE -- 416 -- AES information object identifiers -- 418 aes OBJECT IDENTIFIER ::= { 419 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 420 csor(3) nistAlgorithms(4) 1 } 422 -- AES Key Wrap With Padding Algorithm Identifiers are to be used 423 -- with the Parameter field absent 425 id-aes128-wrap-pad OBJECT IDENTIFIER ::= { aes 8 } 426 id-aes192-wrap-pad OBJECT IDENTIFIER ::= { aes 28 } 427 id-aes256-wrap-pad OBJECT IDENTIFIER ::= { aes 48 } 429 END 431 A.2. 2002 ASN.1 Module 433 AESKeyWrapWithPad-02 { iso(1) member-body(2) us(840) rsadsi(113549) 434 pkcs(1) pkcs-9(9) smime(16) modules(0) 48 } 436 DEFINITIONS IMPLICIT TAGS ::= 437 BEGIN 439 -- EXPORTS ALL -- 441 IMPORTS 442 AlgorithmIdentifier{}, CONTENT-ENCRYPTION, KEY-WRAP, SMIME-CAPS 443 FROM AlgorithmInformation-2009 -- [CMS-ASN] 444 { iso(1) identified-organization(3) dod(6) internet(1) 445 security(5) mechanisms(5) pkix(7) id-mod(0) 446 id-mod-algorithmInformation-02(58) }; 448 AES-ContentEncryption CONTENT-ENCRYPTION ::= { 449 cea-aes128-wrap-pad | 450 cea-aes192-wrap-pad | 451 cea-aes256-wrap-pad, 452 ... } 454 AES-KeyWrap KEY-WRAP ::= { 455 kwa-aes128-wrap-pad | 456 kwa-aes192-wrap-pad | 457 kwa-aes256-wrap-pad, 458 ... } 460 SMimeCaps SMIME-CAPS ::= { 461 cea-aes128-wrap-pad.&smimeCaps | 462 cea-aes192-wrap-pad.&smimeCaps | 463 cea-aes256-wrap-pad.&smimeCaps | 464 kwa-aes128-wrap-pad.&smimeCaps | 465 kwa-aes192-wrap-pad.&smimeCaps | 466 kwa-aes256-wrap-pad.&smimeCaps, 467 ... } 469 -- AES object identifier 471 aes OBJECT IDENTIFIER ::= { 472 joint-iso-itu-t(2) country(16) us(840) organization(1) 473 gov(101) csor(3) nistAlgorithms(4) 1 } 475 -- Content Encryption Algorithms 477 cea-aes128-wrap-pad CONTENT-ENCRYPTION ::= { 478 IDENTIFIER id-aes128-wrap-pad 479 PARAMS ARE absent 480 SMIME-CAPS { IDENTIFIED BY id-aes128-wrap-pad } } 482 cea-aes192-wrap-pad CONTENT-ENCRYPTION ::= { 483 IDENTIFIER id-aes192-wrap-pad 484 PARAMS ARE absent 485 SMIME-CAPS { IDENTIFIED BY id-aes192-wrap-pad } } 487 cea-aes256-wrap-pad CONTENT-ENCRYPTION ::= { 488 IDENTIFIER id-aes256-wrap-pad 489 PARAMS ARE absent 490 SMIME-CAPS { IDENTIFIED BY id-aes256-wrap-pad } } 492 -- Key Wrap Algorithms 494 kwa-aes128-wrap-pad KEY-WRAP ::= { 495 IDENTIFIER id-aes128-wrap-pad 496 PARAMS ARE absent 497 SMIME-CAPS { IDENTIFIED BY id-aes128-wrap-pad } } 499 id-aes128-wrap-pad OBJECT IDENTIFIER ::= { aes 8 } 501 kwa-aes192-wrap-pad KEY-WRAP ::= { 502 IDENTIFIER id-aes192-wrap-pad 503 PARAMS ARE absent 504 SMIME-CAPS { IDENTIFIED BY id-aes192-wrap-pad } } 506 id-aes192-wrap-pad OBJECT IDENTIFIER ::= { aes 28 } 508 kwa-aes256-wrap-pad KEY-WRAP ::= { 509 IDENTIFIER id-aes256-wrap-pad 510 PARAMS ARE absent 511 SMIME-CAPS { IDENTIFIED BY id-aes256-wrap-pad } } 513 id-aes256-wrap-pad OBJECT IDENTIFIER ::= { aes 48 } 515 END 517 Authors' Addresses 519 Russell Housley 520 Vigil Security, LLC 521 918 Spring Knoll Drive 522 Herndon, VA 20170 523 USA 524 EMail: housley@vigilsec.com 526 Morris Dworkin 527 National Institute of Standards and Technology 528 100 Bureau Drive, Mail Stop 8930 529 Gaithersburg, MD 20899-8930 530 USA 531 EMail: dworkin@nist.gov