idnits 2.17.1 draft-housley-aes-key-wrap-with-pad-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document date (29 January 2009) is 5564 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'AES-KW1' on line 136 looks like a reference -- Missing reference section? 'AES-KW2' on line 136 looks like a reference -- Missing reference section? 'AES' on line 135 looks like a reference -- Missing reference section? 'OLD-KW' on line 268 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 5 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: 29 July 2009 29 January 2009 8 Advanced Encryption Standard (AES) Key Wrap Algorithm with Padding 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 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. 43 Abstract 45 This document specifies a padding convention for use with the AES Key 46 Wrap algorithm specified in RFC 3394. This convention eliminates the 47 requirement that the key to be wrapped is a multiple of 64 bits, 48 allowing a key of any practical length to be wrapped. 50 1. Introduction 52 Management of cryptographic keys often leads to situations where a 53 symmetric key is used to encrypt and integrity protect another key, 54 which can be either a symmetric key or an asymmetric key. The 55 operation is often called key wrapping. 57 This document specifies an extension the Advanced Encryption Standard 58 (AES) Key Wrap algorithm [AES-KW1,AES-KW2]. Without this extension, 59 the input to the AES Key Wrap algorithm must be a multiple of 64 60 bits. 62 The AES Key Wrap with Padding algorithm can be used to wrap a key of 63 any practical size with an AES key. The AES key-encrypting key (KEK) 64 can be 128, 192, or 256 bits. The AES Key Wrap algorithm requires 65 the input to be at least two 64-bit blocks. This specification 66 allows inputs as short as 9 octets, which will result in 16 output 67 octets or two 64-bit blocks. Although the AES Key Wrap algorithm 68 does not place a maximum bound on the number of blocks that can be 69 wrapped, this specification does so. The use of a 32-bit fixed field 70 to carry the key length bounds the size of the input octet string at 71 2^32 octets. Most systems will have other factors that limit the 72 practical size of key data to much less than 2^32 octets. 74 A message length indicator (MLI) is defined as an "Alternative 75 Initial Value" in keeping with the statement in 2.2.3.2 of [AES-KW1], 76 which says: 78 Also, if the key data is not just an AES key, it may not always be 79 a multiple of 64 bits. Alternative definitions of the initial 80 value can be used to address such problems. 82 2. Notation and Definitions 84 The following notation is used in the algorithm descriptions: 86 MSB(j, W) Return the most significant j bits of W 87 LSB(j, W) Return the least significant j bits of W 88 B1 | B2 Concatenate B1 and B2 89 K The key-encryption key 90 m The number of octets in the key data 91 n The number of 64-bit key data blocks 92 Q[i] The ith plaintext octet in the key data 93 P[i] The ith plaintext 64-bit block in the padded key data 94 C[i] The ith 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 100 comprises a 32-bit constant concatenated to a 32-bit MLI. The 101 constant is (in hexadecimal) A65959A6 and occupies the high-order 102 half of the AIV. Note that this differs from the high order 32 bits 103 of the default IV in [AES-KW1] Section 2.2.3.1, so there is no 104 ambiguity between the two. The 32-bit MLI, which occupies the low- 105 order half of the AIV, is a unsigned binary integer equal to the 106 number of octets in the key data being wrapped. When the MLI is not 107 a multiple of 8, the key data is padded on the right with the least 108 number of octets sufficient to make a multiple 8. The value of each 109 padding octet shall be 0 (eight binary zeros). 111 Notice that for a given number of 64-bit plaintext blocks, there are 112 only 8 values of MLI that can have that outcome. For example, the 113 only MLI values that are valid with 4 plaintext blocks are 32 (with 114 no padding octets), 31 (with one padding octet), 30, 29, 28, 27, 26, 115 and 25 (with seven padding octets). When the AES Key Unwrap yields n 116 64-bit blocks with an AIV, the eight valid values for the MLI are 117 8*n, (8*n)-1, ..., and (8*n)-7. Therefore, the integrity check for 118 the AIV requires the following steps: 120 1) Check that MSB(32,A) = A65959A6. 122 2) Check that 8*(n-1) < LSB(32,A) <= 8*n. If so, let 123 MLI = LSB(32,A). 125 3) Let b = (8*n)-MLI, and then check that the rightmost b octets of 126 the plaintext are zero. 128 If all three checks pass, then the AIV is valid. If any of the 129 checks fail, then the AIV is invalid and the AES Key Unwrap operation 130 must return an error. 132 4. Algorithms 134 The specification of the key wrap algorithm requires the use of the 135 AES codebook [AES] and provide a padding technique for use with the 136 AES Key Wrap [AES-KW1,AES-KW2]. The next two sections describe the 137 key wrap with padding algorithm and the key unwrap with padding 138 algorithm. 140 4.1. Key Wrap with Padding 142 The inputs to the key wrapping process are the KEK and the plaintext 143 to be wrapped. The plaintext consists of between 9 and 2^32 octets, 144 containing the key data being wrapped. The key wrapping process is 145 described below. 147 Inputs: Plaintext, m octets {Q1, Q2, ..., Qm}, and 148 Key, K (the KEK). 149 Outputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}. 151 1) Initialize variables 153 If m is not a multiple of 8, pad the plaintext octet string on 154 the right with octets {Qm+1, ..., Qr} of zeros, where r is the 155 smallest multiple of 8 that is greater than m. 157 Set n = r/8, which is the same as CEILING(m/8). 159 For i = 1, ..., n 160 j = 8*(i-1) 161 P[i] = Q[j+1] | Q[j+2] | ... | Q[j+8] . 163 Set A = AIV, the Alternative Initial Value as defined in 164 Section 3. 166 2) Key wrapping 168 Use the AES Key Wrap algorithm with the AIV as defined in 169 Section 3, the padded plaintext {P1, ..., Pn}, and K (the KEK). 170 The result is (n+1) 64-bit ciphertext blocks {C0, C1, ..., Cn}. 172 4.2 Key Unwrap with Padding 174 The inputs to the key unwrap algorithm are the KEK and (n+1) 64-bit 175 ciphertext blocks consisting of previously wrapped key. The AES Key 176 Unwrap returns n 64-bit plaintext blocks, which are then mapped to m 177 octets of decrypted key data, as indicated by the MLI embedded in the 178 AVI. 180 Inputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}, and 181 Key, K (the KEK). 182 Outputs: Plaintext, m octets {Q1, Q2, ..., Qm}. 184 1) Key unwrapping 186 Use the AES Key Unrap algorithm with the AIV as defined in 187 Section 3, (n+1) 64-bit ciphertext blocks {C0, C1, ..., Cn}, and 188 K (the KEK). The result is the padded plaintext blocks 189 {P1, ..., Pn}; also the A value is also needed to validate the 190 AIV and remove the padding. 192 2) AIV validation 194 Perform the three checks described in Section 3. If any of the 195 checks fail, then return an error. 197 3) Remove padding 199 Let m = the MLI value extracted from A. 201 For i = 1, ... , n 202 j = 8*(i-1) 203 Q[j+1] | Q[j+2] | ... | Q[j+8] = P[i] 205 5. Algorithm Identifiers 207 Some security protocols employ ASN.1 [X.690], and these protocols 208 employ algorithm identifiers to name cryptographic algorithms. To 209 support these protocols, the AES Key Wrap with Padding algorithm has 210 been assigned the following algorithm identifiers, one for each AES 211 KEK size. The AES Key Wrap (without padding) algorithm identifiers 212 are also included here for convenience. 214 aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 215 us(840) organization(1) gov(101) csor(3) 216 nistAlgorithm(4) 1 } 218 id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 } 219 id-aes128-wrap-pad OBJECT IDENTIFIER ::= { aes TBD } 221 id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 } 222 id-aes192-wrap-pad OBJECT IDENTIFIER ::= { aes TBD } 224 id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 } 225 id-aes256-wrap-pad OBJECT IDENTIFIER ::= { aes TBD } 227 In all cases, the AlgorithmIdentifier parameter field must be NULL. 229 6. Padded Key Wrap Example 231 The example in this section was generated using the index-based 232 implementation of the AES Key Wrap algorithm along with the padding 233 approach specified in Section 4 of this document. The example wraps 234 20 octets of Key Data with a 128-bit KEK. All values are shown in 235 hexadecimal. 237 KEK : 5840df6e29b02af1 ab493b705bf16ea1 ae8338f4dcc176a8 239 Key : c37b7e6492584340 bed1220780894115 5068f738 241 Wrap : 138bdeaa9b8fa7fc 61f97742e72248ee 5ae6ae5360d1ae6a 242 : 5f54f373fa543b6a 244 7. Security Considerations 246 Implementations must protect the key-encryption key (KEK). 247 Compromise of the KEK may result in the disclosure of all keys that 248 have been wrapped with the KEK, which may lead to the compromise of 249 all traffic protected with those wrapped key. 251 If the KEK and wrapped key are associated with different 252 cryptographic algorithms, the effective security provided to data 253 protected with the wrapped key is determined by the weaker of the two 254 algorithms. If, for example, data is encrypted with 128-bit AES and 255 that AES key is wrapped with a 256-bit AES key, then at most 128 bits 256 of protection is provided to the data. If, for another example, a 257 128-bit AES key is used to wrap a 4096-bit RSA private key, then at 258 most 128 bits of protection is provided to any data that depends on 259 that private key. Thus, implementers must ensure that key-encryption 260 algorithms are as strong or stronger than other cryptographic 261 algorithms employed in an overall system. 263 The use of different constants in the A value ensures that a padded 264 key will no be confused with an unpadded key. In addition, the two 265 algorithms provide roughly the same amount of integrity protection. 267 A previous padding technique was specified for wrapping HMAC keys 268 with AES [OLD-KW]. The technique in this document is preferred, and 269 the technique in this document is not limited to wrapping HMAC keys. 271 8. References 273 8.1. Normative References 275 AES National Institute of Standards and Technology. FIPS Pub 276 197: Advanced Encryption Standard (AES). 26 November 2001. 278 AES-KW1 National Institute of Standards and Technology. AES Key 279 Wrap Specification. 17 November 2001. 280 [http://csrc.nist.gov/encryption/kms/key-wrap.pdf] 282 AES-KW2 J. Schaad and R. Housley, "Advanced Encryption Standard 283 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 285 X.680 ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 286 Information technology - Abstract Syntax Notation One 287 (ASN.1): Specification of basic notation. 289 8.2. Informative References 291 OLD-KW J. Schaad and R. Housley, "Wrapping a Hashed Message 292 Authentication Code (HMAC) key with a Triple-Data 293 Encryption Standard (DES) Key or an Advanced 294 Encryption Standard (AES) Key", RFC 3537, May 2003. 296 9. Acknowledgments 298 Paul Timmel should be credited with the MLI and padding technique 299 described in this document. 301 Authors Addresses 303 Russell Housley 304 Vigil Security, LLC 305 918 Spring Knoll Drive 306 Herndon, VA 20170 307 USA 308 EMail: housley@vigilsec.com 310 Morris Dworkin 311 National Institute of Standards and Technology 312 100 Bureau Drive, Mail Stop 8930 313 Gaithersburg, MD 20899-8930 314 USA 315 EMail: dworkin@nist.gov