idnits 2.17.1 draft-housley-aes-key-wrap-with-pad-01.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 (23 February 2009) is 5541 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'AES-KW1' on line 143 looks like a reference -- Missing reference section? 'AES-KW2' on line 172 looks like a reference -- Missing reference section? 'AES' on line 137 looks like a reference -- Missing reference section? 'AESKW2' on line 192 looks like a reference -- Missing reference section? '0' on line 195 looks like a reference -- Missing reference section? 'OLD-KW' on line 283 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: 23 August 2009 23 February 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 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 length of the key to be wrapped is a multiple of 48 64 bits, 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 of the Advanced Encryption 58 Standard (AES) Key Wrap algorithm [AES-KW1,AES-KW2]. Without this 59 extension, the input to the AES Key Wrap algorithm, called the key 60 data, must be a sequence of two or more 64-bit blocks. 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-encryption key (KEK) 64 must be 128, 192, or 256 bits. The input key data may be as short as 65 9 octets, which will result in an output of two 64-bit blocks or 16 66 octets. Although the AES Key Wrap algorithm does not place a maximum 67 bound on the size of the key data that can be wrapped, this extension 68 does so. The use of a 32-bit fixed field to carry the octet length 69 of the key data bounds the size of the input at 2^32 octets. Most 70 systems will have other factors that limit the practical size of key 71 data to much less than 2^32 octets. 73 A message length indicator (MLI) is defined as part of an 74 "Alternative Initial Value" in keeping with the statement in 2.2.3.2 75 of [AES-KW1], which says: 77 Also, if the key data is not just an AES key, it may not always be 78 a multiple of 64 bits. Alternative definitions of the initial 79 value can be used to address such problems. 81 2. Notation and Definitions 83 The following notation is used in the algorithm descriptions: 85 MSB(j, W) Return the most significant j bits of W 86 LSB(j, W) Return the least significant j bits of W 87 B1 | B2 Concatenate B1 and B2 88 K The key-encryption key 89 m The number of octets in the key data 90 n The number of 64-bit blocks in the padded key data 91 Q[i] The ith plaintext octet in the key data 92 P[i] The ith 64-bit plaintext block in the padded key data 93 C[i] The ith 64-bit ciphertext data block 94 A The 64-bit integrity check register 96 3. Alternative Initial Value 98 The Alternative Initial Value (AIV) required by this specification is 99 a 32-bit constant concatenated to a 32-bit MLI. The constant is (in 100 hexadecimal) A65959A6 and occupies the high-order half of the AIV. 101 Note that this differs from the high order 32 bits of the default IV 102 in [AES-KW1] Section 2.2.3.1, so there is no ambiguity between the 103 two. The 32-bit MLI, which occupies the low-order half of the AIV, 104 is an unsigned binary integer equal to the octet length of the 105 plaintext key data, in network order, that is with the most 106 significant octet first. When the MLI is not a multiple of 8, the 107 key data is padded on the right with the least number of octets 108 sufficient to make a multiple of 8. The value of each padding octet 109 shall be 0 (eight binary zeros). 111 Notice that for a given number of 64-bit plaintext blocks, there are 112 only eight values of MLI that can have that outcome. For example, 113 the only MLI values that are valid with four 64-bit plaintext blocks 114 are 32 (with no padding octets), 31 (with one padding octet), 30, 29, 115 28, 27, 26, and 25 (with seven padding octets). When the AES Key 116 Unwrap yields n 64-bit blocks of key data with an AIV, the eight 117 valid values for the MLI are 8*n, (8*n)-1, ..., and (8*n)-7. 118 Therefore, the integrity check for the AIV requires the following 119 steps: 121 1) Check that MSB(32,A) = A65959A6. 123 2) Check that 8*(n-1) < LSB(32,A) <= 8*n. If so, let 124 MLI = LSB(32,A). 126 3) Let b = (8*n)-MLI, and then check that the rightmost b octets of 127 the plaintext are zero. 129 If all three checks pass, then the AIV is valid. If any of the 130 checks fail, then the AIV is invalid and the AES Key Unwrap operation 131 must return an error. 133 4. Specification of the AES Key Wrap with Padding Algorithm 135 The AES Key Wrap with Padding algorithm consists of a wrapping 136 process and an unwrapping process, both based on the AES codebook 137 [AES]. It provides an extension to the AES Key Wrap algorithm 138 [AES-KW1,AES-KW2] that eliminates the requirement that the length of 139 the key to be wrapped is a multiple of 64 bits. The next two 140 sections specify the wrapping and unwrapping processes, called the 141 Extended Key Wrapping process and the Extended Key Unwrapping 142 process, respectively. These names distinguish these processes from 143 the ones specified in [AES-KW1,AES-KW2]. 145 4.1. Extended Key Wrapping Process 147 The inputs to the extended key wrapping process are the KEK and the 148 plaintext to be wrapped. The plaintext consists of between 9 and 149 2^32 octets, containing the key data being wrapped. The key wrapping 150 process is described below. 152 Inputs: Plaintext, m octets {Q1, Q2, ..., Qm}, and 153 Key, K (the KEK). 154 Outputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}. 156 1) Append padding 158 If m is not a multiple of 8, pad the plaintext octet string on 159 the right with octets {Qm+1, ..., Qr} of zeros, where r is the 160 smallest multiple of 8 that is greater than m. If m is a 161 multiple of 8, then there is no padding, and r = m. 163 Set n = r/8, which is the same as CEILING(m/8). 165 For i = 1, ..., n 166 j = 8*(i-1) 167 P[i] = Q[j+1] | Q[j+2] | ... | Q[j+8] . 169 2) Wrapping 171 Apply the wrapping process specified in Section 2.2.1 of 172 [AES-KW2] to the padded plaintext {P1, ..., Pn} and K (the KEK), 173 with the AIV as defined in Section 3 above as the initial value. 174 The result is n+1 64-bit blocks {C0, C1, ..., Cn}. 176 4.2 Extended Key Unwrapping Process 178 The inputs to the extended key unwrapping process are the KEK and n+1 179 64-bit ciphertext blocks consisting of a previously wrapped key. If 180 the ciphertext is a validly wrapped key, then the (original) 181 unwrapping process returns n 64-bit plaintext blocks, which are then 182 mapped in this extension to m octets of decrypted key data, as 183 indicated by the MLI embedded in the AIV. 185 Inputs: Ciphertext, (n+1) 64-bit blocks {C0, C1, ..., Cn}, and 186 Key, K (the KEK). 187 Outputs: Plaintext, m octets {Q1, Q2, ..., Qm}, or an error. 189 1) Key unwrapping 191 Apply Steps 1 and 2 of the unwrapping process specified in 192 Section 2.2.2 of [AESKW2] to the n+1 64-bit ciphertext blocks, 193 {C0, C1, ..., Cn}, and the KEK, K. Define the padded plaintext 194 blocks, {P1, ..., Pn}, as specified in Step 3 of that process, 195 with A[0] as the A value. Note that checking "If A[0] is an 196 appropriate value" is slightly delayed to Step 2 below since the 197 padded plaintext is needed to perform this verification when the 198 AIV is used. 200 2) AIV verification 202 Perform the three checks described in Section 3 above on the 203 padded plaintext and the A value. If any of the checks fail, 204 then return an error. 206 3) Remove padding 208 Let m = the MLI value extracted from A. 210 Let P = P1 | P2 | ... | Pn. 212 For i = 1, ... , m 213 Q[i] = LSB(8, MSB(8*i, P)) 215 5. Algorithm Identifiers 217 Some security protocols employ ASN.1 [X.690], and these protocols 218 employ algorithm identifiers to name cryptographic algorithms. To 219 support these protocols, the AES Key Wrap with Padding algorithm has 220 been assigned the following algorithm identifiers, one for each AES 221 KEK size. The AES Key Wrap (without padding) algorithm identifiers 222 are also included here for convenience. 224 aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 225 us(840) organization(1) gov(101) csor(3) 226 nistAlgorithm(4) 1 } 228 id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 } 229 id-aes128-wrap-pad OBJECT IDENTIFIER ::= { aes TBD } 231 id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 } 232 id-aes192-wrap-pad OBJECT IDENTIFIER ::= { aes TBD } 233 id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 } 234 id-aes256-wrap-pad OBJECT IDENTIFIER ::= { aes TBD } 236 In all cases, the AlgorithmIdentifier parameter field must be absent. 238 6. Padded Key Wrap Example 240 The example in this section was generated using the index-based 241 implementation of the AES Key Wrap algorithm along with the padding 242 approach specified in Section 4 of this document. The example wraps 243 20 octets of Key Data with a 192-bit KEK. All values are shown in 244 hexadecimal. 246 KEK : 5840df6e29b02af1 ab493b705bf16ea1 ae8338f4dcc176a8 248 Key : c37b7e6492584340 bed1220780894115 5068f738 250 Wrap : 138bdeaa9b8fa7fc 61f97742e72248ee 5ae6ae5360d1ae6a 251 : 5f54f373fa543b6a 253 7. Security Considerations 255 Implementations must protect the key-encryption key (KEK). 256 Compromise of the KEK may result in the disclosure of all keys that 257 have been wrapped with the KEK, which may lead to the compromise of 258 all traffic protected with those wrapped keys. 260 If the KEK and wrapped key are associated with different 261 cryptographic algorithms, the effective security provided to data 262 protected with the wrapped key is determined by the weaker of the two 263 algorithms. If, for example, data is encrypted with 128-bit AES and 264 that AES key is wrapped with a 256-bit AES key, then at most 128 bits 265 of protection is provided to the data. If, for another example, a 266 128-bit AES key is used to wrap a 4096-bit RSA private key, then at 267 most 128 bits of protection is provided to any data that depends on 268 that private key. Thus, implementers must ensure that key-encryption 269 algorithms are as strong or stronger than other cryptographic 270 algorithms employed in an overall system. 272 The AES Key Wrap and the AES Key Wrap with Padding algorithms use 273 different constants in the initial value. The use of different 274 values ensures that the recipient of padded key data cannot 275 successfully unwrap it as unpadded key data, or vice versa. This 276 remains true when the key data is wrapped using the AES Key Wrap with 277 Padding algorithm but no padding is needed. 279 The AES Key Wrap with Padding algorithm provides almost the same 280 amount of integrity protection as the AES Key Wrap algorithm. 282 A previous padding technique was specified for wrapping HMAC keys 283 with AES [OLD-KW]. The technique in this document is preferred, and 284 the technique in this document is not limited to wrapping HMAC keys. 286 The key wrapping technique specified in this document requires the 287 length of the key data to be at least nine octets because a single 288 application of the AES codebook is sufficient to protect up to eight 289 octets of key data. In particular, if the key data consists of eight 290 or fewer octets, then a 64-bit integrity check value could be 291 prepended to the key data to form a single 128-bit block. For 292 example, the integrity check value could consist of a fixed seven 293 octet value followed by a single octet length value. The wrapping 294 and unwrapping processes employing such an integrity check value and 295 a single AES codebook operation could be defined analogous to those 296 in Section 4 if there is a need to wrap keys that are smaller than 297 nine octets. 299 8. References 301 8.1. Normative References 303 AES National Institute of Standards and Technology. FIPS Pub 304 197: Advanced Encryption Standard (AES). 26 November 2001. 306 AES-KW1 National Institute of Standards and Technology. AES Key 307 Wrap Specification. 17 November 2001. 308 [http://csrc.nist.gov/encryption/kms/key-wrap.pdf] 310 AES-KW2 J. Schaad and R. Housley, "Advanced Encryption Standard 311 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 313 X.680 ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 314 Information technology - Abstract Syntax Notation One 315 (ASN.1): Specification of basic notation. 317 8.2. Informative References 319 OLD-KW J. Schaad and R. Housley, "Wrapping a Hashed Message 320 Authentication Code (HMAC) key with a Triple-Data 321 Encryption Standard (DES) Key or an Advanced 322 Encryption Standard (AES) Key", RFC 3537, May 2003. 324 9. Acknowledgments 326 Paul Timmel should be credited with the MLI and padding technique 327 described in this document. 329 Authors Addresses 331 Russell Housley 332 Vigil Security, LLC 333 918 Spring Knoll Drive 334 Herndon, VA 20170 335 USA 336 EMail: housley@vigilsec.com 338 Morris Dworkin 339 National Institute of Standards and Technology 340 100 Bureau Drive, Mail Stop 8930 341 Gaithersburg, MD 20899-8930 342 USA 343 EMail: dworkin@nist.gov