idnits 2.17.1 draft-burgin-kerberos-aes-cbc-hmac-sha2-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 234 has weird spacing: '...unction tke...' == Line 245 has weird spacing: '...unction ide...' == Line 295 has weird spacing: '... Etype encr...' -- The document date (October 19, 2012) is 4206 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Burgin 3 Internet Draft National Security Agency 4 Intended Status: Informational M. Peck 5 Expires: April 22, 2013 The MITRE Corporation 6 October 19, 2012 8 AES Encryption with HMAC-SHA2 for Kerberos 5 9 draft-burgin-kerberos-aes-cbc-hmac-sha2-02 11 Abstract 13 This document specifies two encryption types and two corresponding 14 checksum types for Kerberos 5. The new types use AES in CBC mode 15 with ciphertext stealing for confidentiality and HMAC with a SHA-2 16 hash for integrity. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 21, 2013. 35 Copyright and License Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions used in this Document . . . . . . . . . . . . . . 3 54 3. Protocol Key Representation . . . . . . . . . . . . . . . . . 3 55 4. Key Generation from Pass Phrases . . . . . . . . . . . . . . . 3 56 5. Key Derivation Function . . . . . . . . . . . . . . . . . . . 4 57 6. Kerberos Algorithm Protocol Parameters . . . . . . . . . . . . 5 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 62 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 63 Appendix A. AES-CBC Test Vectors . . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 This document defines two encryption types and two corresponding 69 checksum types for Kerberos 5 using AES with 128-bit or 256-bit keys. 70 The new types conform to the framework specified in [RFC3961], but do 71 not use the simplified profile. 73 The new encryption types use AES in CBC mode with ciphertext stealing 74 similar to [RFC3962] but with several variations. 76 The new types use the PBKDF2 algorithm for key generation from 77 strings, with a modification to the use in [RFC3962] that the hash 78 algorithm in the pseudorandom function used by PBKDF2 will be SHA-256 79 instead of SHA-1. 81 The new types use key derivation to produce keys for encryption, 82 integrity protection, and checksum operations as in [RFC3962]. 83 However, a key derivation function from [SP800-108] which uses the 84 SHA-256 or SHA-384 hash algorithm is used in place of the DK key 85 derivation function used in [RFC3961]. 87 The new types use the HMAC algorithm with a hash from the SHA-2 88 family for integrity protection and checksum operations. 90 2. Conventions used in this Document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 3. Protocol Key Representation 98 The AES key space is dense, so we can use random or pseudorandom 99 octet strings directly as keys. The byte representation for the key 100 is described in [FIPS197], where the first bit of the bit string is 101 the high bit of the first byte of the byte string (octet string). 103 4. Key Generation from Pass Phrases 105 We use a variation on the key generation algorithm specified in 106 Section 4 of [RFC3962] with the following changes: 108 * The pseudorandom function used by PBKDF2 will be the SHA-256 HMAC 109 of the passphrase and salt, instead of the SHA-1 HMAC of the 110 passphrase and salt. The salt SHOULD contain at least 128 random 111 bits as recommended in [SP800-132]. It MAY also contain other 112 information such as the principal's realm and name components. 114 * The final key derivation step uses the algorithm KDF-HMAC-SHA2 115 defined below in Section 5 instead of the DK function. 117 * If no string-to-key parameters are specified, the default number 118 of iterations is raised to 32,768. 120 To ensure that different long-term keys are used with different 121 enctypes, we prepend the enctype name to the salt string, separated 122 by a null byte. The enctype name is "aes128-cts-hmac-sha256-128" or 123 "aes256-cts-hmac-sha384-192" (without the quotes). The user's long- 124 term key is derived as follows 126 saltp = enctype-name | 0x00 | salt 127 tkey = random-to-key(PBKDF2(passphrase, saltp, 128 iter_count, keylength)) 129 key = KDF-HMAC-SHA2(tkey, "kerberos") where "kerberos" is the 130 byte string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. 132 where the pseudorandom function used by PBKDF2 is the SHA-256 HMAC of 133 the passphrase and salt, the value for keylength is the AES key 134 length, and the algorithm KDF-HMAC-SHA2 is defined in Section 5. 136 5. Key Derivation Function 138 We use a key derivation function from Section 5.1 of [SP800-108] 139 which uses the HMAC algorithm as the PRF. The counter i is expressed 140 as four octets in big-endian order. The length of the output key in 141 bits (denoted as k) is also represented as four octets in big-endian 142 order. The "Label" input to the KDF is the usage constant supplied 143 to the key derivation function, and the "Context" input is null. 145 When the encryption type is aes128-cts-hmac-sha256-128: 147 n = 1 148 K1 = HMAC-SHA-256(key, 00 00 00 01 | constant | 0x00 | 00 00 00 80) 149 DR(key, constant) = First 128 bits of K1 150 KDF-HMAC-SHA2(key, constant) = random-to-key(DR(key, constant)) 152 When the encryption type is aes256-cts-hmac-sha384-192: 154 n = 1 155 K1 = HMAC-SHA-384(key, 00 00 00 01 | constant | 0x00 | 00 00 01 00) 156 DR(key, constant) = First 256 bits of K1 157 KDF-HMAC-SHA2(key, constant) = random-to-key(DR(key, constant)) 159 6. Kerberos Algorithm Protocol Parameters 161 The following parameters apply to the encryption types aes128-cts- 162 hmac-sha256-128 and aes256-cts-hmac-sha384-192. 164 The key-derivation function described in the previous section is used 165 to produce the three intermediate keys. Typically, CBC mode [SP800- 166 38A] requires the input be padded to a multiple of the encryption 167 algorithm block size, which is 128 bits for AES. However, to avoid 168 ciphertext expansion, we use the CBC-CS3 variant to CBC mode defined 169 in [SP800-38A+]. 171 Each encryption will use a freshly generated 16-octet nonce generated 172 at random by the message originator. The initialization vector (IV) 173 used by AES is obtained by xoring the random nonce with the 174 cipherstate. 176 The ciphertext is the concatenation of the random nonce, the output 177 of AES in CBC-CS3 mode, and the HMAC of the initialization vector 178 concatenated with the AES output. The HMAC is computed using either 179 SHA-256 or SHA-384. The output of SHA-256 is truncated to 128 bits 180 and the output of SHA-384 is truncated to 192 bits. Sample test 181 vectors are given in Appendix A. 183 Decryption is performed by removing the HMAC, verifying the HMAC 184 against the remainder, and then decrypting the remainder if the HMAC 185 is correct. 187 The encryption and checksum mechanisms below use the following 188 notation from [RFC3961]. 190 HMAC output size, h 191 message block size, m 192 encryption/decryption functions, E and D 193 cipher block size, c 195 Encryption Mechanism for AES-CBC-HMAC-SHA2 196 ------------------------------------------------------------------------ 198 protocol key format 128- or 256-bit string 200 specific key structure Three protocol-format keys: { Kc, Ke, Ki }. 202 required checksum As defined below. 203 mechanism 205 key-generation seed key size (128 or 256 bits) 206 length 207 cipher state Random nonce of length c (128 bits) 209 initial cipher state All bits zero 211 encryption function N = random nonce of length c (128 bits) 212 IV = N + cipherState (+ denotes XOR) 213 C = E(Ke, plaintext, IV) 214 using CBC-CS3-Encrypt defined 215 in [SP800-38A+] 216 H = HMAC(Ki, N | C) 217 ciphertext = N | C | H[1..h] 218 cipherState = N 220 decryption function (N, C, H) = ciphertext 221 if (H != HMAC(Ki, N | C)[1..h]) 222 stop, report error 223 IV = N + cipherState (+ denotes XOR) 224 P = D(Ke, C, IV) 225 using CBC-CS3-Decrypt defined 226 in [SP800-38A+] 227 cipherState = N 229 pseudo-random function Kp = KDF-HMAC-SHA2(protocol-key, "prf") 230 PRF = HMAC(Kp, octet-string) 232 key generation functions: 234 string-to-key function tkey = random-to-key(PBKDF2(passphrase, saltp, 235 iter_count, 236 keylength)) 237 base-key = KDF-HMAC-SHA2(tkey, "kerberos") 239 where the pseudorandom function used by PBKDF2 240 is the SHA-256 HMAC of the passphrase and salt 242 default string-to-key 00 00 80 00 243 parameters 245 random-to-key function identity function 247 key-derivation function KDF-HMAC-SHA2 as defined in Section 5. The 248 key usage number is expressed as four octets 249 in big-endian order. 251 Kc = KDF-HMAC-SHA2(base-key, usage | 0x99) 252 Ke = KDF-HMAC-SHA2(base-key, usage | 0xAA) 253 Ki = KDF-HMAC-SHA2(base-key, usage | 0x55); 255 Checksum Mechanism for AES-CTS-HMAC-SHA2 256 ------------------------------------------------------------------------ 257 associated cryptosystem AES-128-CBC or AES-256-CBC as appropriate 259 get_mic HMAC(Kc, message)[1..h] 261 verify_mic get_mic and compare 263 Using this profile with each key size gives us two each of encryption 264 and checksum algorithm definitions. 266 +--------------------------------------------------------------------+ 267 | encryption types | 268 +--------------------------------------------------------------------+ 269 | type name etype value key size | 270 +--------------------------------------------------------------------+ 271 | aes128-cts-hmac-sha256-128 TBD1 128 | 272 | aes256-cts-hmac-sha384-192 TBD2 256 | 273 +--------------------------------------------------------------------+ 275 +--------------------------------------------------------------------+ 276 | checksum types | 277 +--------------------------------------------------------------------+ 278 | type name sumtype value length | 279 +--------------------------------------------------------------------+ 280 | hmac-sha256-128-aes128 TBD3 128 | 281 | hmac-sha384-192-aes256 TBD4 192 | 282 +--------------------------------------------------------------------+ 284 These checksum types will be used with the corresponding encryption 285 types defined above. 287 7. IANA Considerations 289 IANA is requested to assign: 291 1. Encryption type numbers for aes128-cts-hmac-sha256-128 and 292 aes256-cts-hmac-sha384-192 in the Kerberos Encryption Type 293 Numbers registry. 295 Etype encryption type Reference 296 ----- --------------- --------- 297 TBD1 aes128-cts-hmac-sha256-128 [I.D.burgin-kerberos-aes- 298 cbc-hmac-sha2] 299 TBD2 aes256-cts-hmac-sha384-192 [I.D.burgin-kerberos-aes- 300 cbc-hmac-sha2] 302 2. Checksum type numbers for hmac-sha256-128-aes128 and hmac-sha384- 303 192-aes256 in the Kerberos Checksum Type Numbers registry. 305 Sumtype Checksum type Size Reference 306 ------- ------------- ---- --------- 307 TBD3 hmac-sha256-128-aes128 16 [I.D.burgin-kerberos- 308 aes-cbc-hmac-sha2] 309 TBD4 hmac-sha384-192-aes256 24 [I.D.burgin-kerberos- 310 aes-cbc-hmac-sha2] 312 8. Security Considerations 314 This specification requires implementations to generate random 315 values. The use of inadequate pseudo-random number generators 316 (PRNGs) can result in little or no security. The generation of 317 quality random numbers is difficult. NIST Special Publication 800-90 318 [SP800-90] and [RFC4086] offer random number generation guidance. 320 This document specifies a mechanism for generating keys from pass 321 phrases or passwords. The salt and iteration count resist brute 322 force and dictionary attacks, however, it is still important to 323 choose or generate strong passphrases. 325 9. References 327 9.1. Normative References 329 [SP800-38A+] National Institute of Standards and Technology, 330 "Recommendation for Block Cipher Modes of Operation: 331 Three Variants of Ciphertext Stealing for CBC Mode", 332 Addendum to NIST Special Publication 800-38A, October 333 2010. 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, March 1997. 338 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 339 Kerberos 5", RFC 3961, February 2005. 341 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) 342 Encryption for Kerberos 5", RFC 3962, February 2005. 344 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 345 "Randomness Requirements for Security", BCP 106, 346 RFC 4086, June 2005. 348 [FIPS197] National Institute of Standards and Technology, 349 "Advanced Encryption Standard (AES)", FIPS PUB 197, 350 November 2001. 352 9.2. Informative References 354 [SP800-38A] National Institute of Standards and Technology, 355 "Recommendation for Block Cipher Modes of Operation - 356 Methods and Techniques", NIST Special Publication 800- 357 38A, February 2001. 359 [SP800-90] National Institute of Standards and Technology, 360 Recommendation for Random Number Generation Using 361 Deterministic Random Bit Generators (Revised), NIST 362 Special Publication 800-90, March 2007. 364 [SP800-108] National Institute of Standards and Technology, 365 "Recommendation for Key Derivation Using Pseudorandom 366 Functions", NIST Special Publication 800-108, October 367 2009. 369 [SP800-132] National Institute of Standards and Technology, 370 "Recommendation for Password-Based Key Derivation, Part 371 1: Storage Applications", NIST Special Publication 800- 372 132, June 2010. 374 Appendix A. AES-CBC Test Vectors 376 TBD 378 Authors' Addresses 380 Kelley W. Burgin 381 National Security Agency 383 EMail: kwburgi@tycho.ncsc.mil 385 Michael A. Peck 386 The MITRE Corporation 388 EMail: mpeck@mitre.org