1 2 3 4 5 6 7Network Working Group K. Raeburn 8Request for Comments: 3962 MIT 9Category: Standards Track February 2005 10 11 12 Advanced Encryption Standard (AES) Encryption for Kerberos 5 13 14Status of This Memo 15 16 This document specifies an Internet standards track protocol for the 17 Internet community, and requests discussion and suggestions for 18 improvements. Please refer to the current edition of the "Internet 19 Official Protocol Standards" (STD 1) for the standardization state 20 and status of this protocol. Distribution of this memo is unlimited. 21 22Copyright Notice 23 24 Copyright (C) The Internet Society (2005). 25 26Abstract 27 28 The United States National Institute of Standards and Technology 29 (NIST) has chosen a new Advanced Encryption Standard (AES), which is 30 significantly faster and (it is believed) more secure than the old 31 Data Encryption Standard (DES) algorithm. This document is a 32 specification for the addition of this algorithm to the Kerberos 33 cryptosystem suite. 34 351. Introduction 36 37 This document defines encryption key and checksum types for Kerberos 38 5 using the AES algorithm recently chosen by NIST. These new types 39 support 128-bit block encryption and key sizes of 128 or 256 bits. 40 41 Using the "simplified profile" of [KCRYPTO], we can define a pair of 42 encryption and checksum schemes. AES is used with ciphertext 43 stealing to avoid message expansion, and SHA-1 [SHA1] is the 44 associated checksum function. 45 462. Conventions used in this Document 47 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in BCP 14, RFC 2119 51 [KEYWORDS]. 52 53 54 55 56 57 58Raeburn Standards Track [Page 1] 59 60RFC 3962 AES Encryption for Kerberos 5 February 2005 61 62 633. Protocol Key Representation 64 65 The profile in [KCRYPTO] treats keys and random octet strings as 66 conceptually different. But since the AES key space is dense, we can 67 use any bit string of appropriate length as a key. We use the byte 68 representation for the key described in [AES], where the first bit of 69 the bit string is the high bit of the first byte of the byte string 70 (octet string) representation. 71 724. Key Generation from Pass Phrases or Random Data 73 74 Given the above format for keys, we can generate keys from the 75 appropriate amounts of random data (128 or 256 bits) by simply 76 copying the input string. 77 78 To generate an encryption key from a pass phrase and salt string, we 79 use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters 80 indicated below, to generate an intermediate key (of the same length 81 as the desired final key), which is then passed into the DK function 82 with the 8-octet ASCII string "kerberos" as is done for des3-cbc- 83 hmac-sha1-kd in [KCRYPTO]. (In [KCRYPTO] terms, the PBKDF2 function 84 produces a "random octet string", hence the application of the 85 random-to-key function even though it's effectively a simple identity 86 operation.) The resulting key is the user's long-term key for use 87 with the encryption algorithm in question. 88 89 tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength)) 90 key = DK(tkey, "kerberos") 91 92 The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the 93 passphrase and salt, as described in Appendix B.1 to PKCS#5. 94 95 The number of iterations is specified by the string-to-key parameters 96 supplied. The parameter string is four octets indicating an unsigned 97 number in big-endian order. This is the number of iterations to be 98 performed. If the value is 00 00 00 00, the number of iterations to 99 be performed is 4,294,967,296 (2**32). (Thus the minimum expressible 100 iteration count is 1.) 101 102 For environments where slower hardware is the norm, implementations 103 of protocols such as Kerberos may wish to limit the number of 104 iterations to prevent a spoofed response supplied by an attacker from 105 consuming lots of client-side CPU time; if such a limit is 106 implemented, it SHOULD be no less than 50,000. Even for environments 107 with fast hardware, 4 billion iterations is likely to take a fairly 108 long time; much larger bounds might still be enforced, and it might 109 be wise for implementations to permit interruption of this operation 110 by the user if the environment allows for it. 111 112 113 114Raeburn Standards Track [Page 2] 115 116RFC 3962 AES Encryption for Kerberos 5 February 2005 117 118 119 If the string-to-key parameters are not supplied, the value used is 120 00 00 10 00 (decimal 4,096, indicating 4,096 iterations). 121 122 Note that this is not a requirement, nor even a recommendation, for 123 this value to be used in "optimistic preauthentication" (e.g., 124 attempting timestamp-based preauthentication using the user's long- 125 term key without having first communicated with the KDC) in the 126 absence of additional information, or as a default value for sites to 127 use for their principals' long-term keys in their Kerberos database. 128 It is simply the interpretation of the absence of the string-to-key 129 parameter field when the KDC has had an opportunity to provide it. 130 131 Sample test vectors are given in Appendix B. 132 1335. Ciphertext Stealing 134 135 Cipher block chaining is used to encrypt messages, with the initial 136 vector stored in the cipher state. Unlike previous Kerberos 137 cryptosystems, we use ciphertext stealing to handle the possibly 138 partial final block of the message. 139 140 Ciphertext stealing is described on pages 195-196 of [AC], and 141 section 8 of [RC5]; it has the advantage that no message expansion is 142 done during encryption of messages of arbitrary sizes as is typically 143 done in CBC mode with padding. Some errata for [RC5] are listed in 144 Appendix A and are considered part of the ciphertext stealing 145 technique as used here. 146 147 Ciphertext stealing, as defined in [RC5], assumes that more than one 148 block of plain text is available. If exactly one block is to be 149 encrypted, that block is simply encrypted with AES (also known as ECB 150 mode). Input smaller than one block is padded at the end to one 151 block; the values of the padding bits are unspecified. 152 (Implementations MAY use all-zero padding, but protocols MUST NOT 153 rely on the result being deterministic. Implementations MAY use 154 random padding, but protocols MUST NOT rely on the result not being 155 deterministic. Note that in most cases, the Kerberos encryption 156 profile will add a random confounder independent of this padding.) 157 158 For consistency, ciphertext stealing is always used for the last two 159 blocks of the data to be encrypted, as in [RC5]. If the data length 160 is a multiple of the block size, this is equivalent to plain CBC mode 161 with the last two ciphertext blocks swapped. 162 163 A test vector is given in Appendix B. 164 165 166 167 168 169 170Raeburn Standards Track [Page 3] 171 172RFC 3962 AES Encryption for Kerberos 5 February 2005 173 174 175 The initial vector carried out from one encryption for use in a 176 subsequent encryption is the next-to-last block of the encryption 177 output; this is the encrypted form of the last plaintext block. When 178 decrypting, the next-to-last block of the supplied ciphertext is 179 carried forward as the next initial vector. If only one ciphertext 180 block is available (decrypting one block, or encrypting one block or 181 less), then that one block is carried out instead. 182 1836. Kerberos Algorithm Profile Parameters 184 185 This is a summary of the parameters to be used with the simplified 186 algorithm profile described in [KCRYPTO]: 187 188 +--------------------------------------------------------------------+ 189 | protocol key format 128- or 256-bit string | 190 | | 191 | string-to-key function PBKDF2+DK with variable | 192 | iteration count (see | 193 | above) | 194 | | 195 | default string-to-key parameters 00 00 10 00 | 196 | | 197 | key-generation seed length key size | 198 | | 199 | random-to-key function identity function | 200 | | 201 | hash function, H SHA-1 | 202 | | 203 | HMAC output size, h 12 octets (96 bits) | 204 | | 205 | message block size, m 1 octet | 206 | | 207 | encryption/decryption functions, AES in CBC-CTS mode | 208 | E and D (cipher block size 16 | 209 | octets), with next-to- | 210 | last block (last block | 211 | if only one) as CBC-style | 212 | ivec | 213 +--------------------------------------------------------------------+ 214 215 Using this profile with each key size gives us two each of encryption 216 and checksum algorithm definitions. 217 218 219 220 221 222 223 224 225 226Raeburn Standards Track [Page 4] 227 228RFC 3962 AES Encryption for Kerberos 5 February 2005 229 230 2317. Assigned Numbers 232 233 The following encryption type numbers are assigned: 234 235 +--------------------------------------------------------------------+ 236 | encryption types | 237 +--------------------------------------------------------------------+ 238 | type name etype value key size | 239 +--------------------------------------------------------------------+ 240 | aes128-cts-hmac-sha1-96 17 128 | 241 | aes256-cts-hmac-sha1-96 18 256 | 242 +--------------------------------------------------------------------+ 243 244 The following checksum type numbers are assigned: 245 246 +--------------------------------------------------------------------+ 247 | checksum types | 248 +--------------------------------------------------------------------+ 249 | type name sumtype value length | 250 +--------------------------------------------------------------------+ 251 | hmac-sha1-96-aes128 15 96 | 252 | hmac-sha1-96-aes256 16 96 | 253 +--------------------------------------------------------------------+ 254 255 These checksum types will be used with the corresponding encryption 256 types defined above. 257 2588. Security Considerations 259 260 This new algorithm has not been around long enough to receive the 261 decades of intense analysis that DES has received. It is possible 262 that some weakness exists that has not been found by the 263 cryptographers analyzing these algorithms before and during the AES 264 selection process. 265 266 The use of the HMAC function has drawbacks for certain pass phrase 267 lengths. For example, a pass phrase longer than the hash function 268 block size (64 bytes, for SHA-1) is hashed to a smaller size (20 269 bytes) before applying the main HMAC algorithm. However, entropy is 270 generally sparse in pass phrases, especially in long ones, so this 271 may not be a problem in the rare cases of users with long pass 272 phrases. 273 274 Also, generating a 256-bit key from a pass phrase of any length may 275 be deceptive, as the effective entropy in pass-phrase-derived key 276 cannot be nearly that large given the properties of the string-to-key 277 function described here. 278 279 280 281 282Raeburn Standards Track [Page 5] 283 284RFC 3962 AES Encryption for Kerberos 5 February 2005 285 286 287 The iteration count in PBKDF2 appears to be useful primarily as a 288 constant multiplier for the amount of work required for an attacker 289 using brute-force methods. Unfortunately, it also multiplies, by the 290 same amount, the work needed by a legitimate user with a valid 291 password. Thus the work factor imposed on an attacker (who may have 292 many powerful workstations at his disposal) must be balanced against 293 the work factor imposed on the legitimate user (who may have a PDA or 294 cell phone); the available computing power on either side increases 295 as time goes on, as well. A better way to deal with the brute-force 296 attack is through preauthentication mechanisms that provide better 297 protection of the user's long-term key. Use of such mechanisms is 298 out of the scope of this document. 299 300 If a site does wish to use this means of protection against a brute- 301 force attack, the iteration count should be chosen based on the 302 facilities available to both attacker and legitimate user, and the 303 amount of work the attacker should be required to perform to acquire 304 the key or password. 305 306 As an example: 307 308 The author's tests on a 2GHz Pentium 4 system indicated that in 309 one second, nearly 90,000 iterations could be done, producing a 310 256-bit key. This was using the SHA-1 assembly implementation 311 from OpenSSL, and a pre-release version of the PBKDF2 code for 312 MIT's Kerberos package, on a single system. No attempt was made 313 to do multiple hashes in parallel, so we assume an attacker doing 314 so can probably do at least 100,000 iterations per second -- 315 rounded up to 2**17, for ease of calculation. For simplicity, we 316 also assume the final AES encryption step costs nothing. 317 318 Paul Leach estimates [LEACH] that a password-cracking dictionary 319 may have on the order of 2**21 entries, with capitalization, 320 punctuation, and other variations contributing perhaps a factor of 321 2**11, giving a ballpark estimate of 2**32. 322 323 Thus, for a known iteration count N and a known salt string, an 324 attacker with some number of computers comparable to the author's 325 would need roughly N*2**15 CPU seconds to convert the entire 326 dictionary plus variations into keys. 327 328 An attacker using a dozen such computers for a month would have 329 roughly 2**25 CPU seconds available. So using 2**12 (4,096) 330 iterations would mean an attacker with a dozen such computers 331 dedicated to a brute-force attack against a single key (actually, 332 any password-derived keys sharing the same salt and iteration 333 334 335 336 337 338Raeburn Standards Track [Page 6] 339 340RFC 3962 AES Encryption for Kerberos 5 February 2005 341 342 343 count) would process all the variations of the dictionary entries 344 in four months and, on average, would likely find the user's 345 password in two months. 346 347 Thus, if this form of attack is of concern, users should be 348 required to change their passwords every few months, and an 349 iteration count a few orders of magnitude higher should be chosen. 350 Perhaps several orders of magnitude, as many users will tend to 351 use the shorter and simpler passwords (to the extent they can, 352 given a site's password quality checks) that the attacker would 353 likely try first. 354 355 Since this estimate is based on currently available CPU power, the 356 iteration counts used for this mode of defense should be increased 357 over time, at perhaps 40%-60% each year or so. 358 359 Note that if the attacker has a large amount of storage available, 360 intermediate results could be cached, saving a lot of work for the 361 next attack with the same salt and a greater number of iterations 362 than had been run at the point where the intermediate results were 363 saved. Thus, it would be wise to generate a new random salt 364 string when passwords are changed. The default salt string, 365 derived from the principal name, only protects against the use of 366 one dictionary of keys against multiple users. 367 368 If the PBKDF2 iteration count can be spoofed by an intruder on the 369 network, and the limit on the accepted iteration count is very high, 370 the intruder may be able to introduce a form of denial of service 371 attack against the client by sending a very high iteration count, 372 causing the client to spend a great deal of CPU time computing an 373 incorrect key. 374 375 An intruder spoofing the KDC reply, providing a low iteration count 376 and reading the client's reply from the network, may be able to 377 reduce the work needed in the brute-force attack outlined above. 378 Thus, implementations may seek to enforce lower bounds on the number 379 of iterations that will be used. 380 381 Since threat models and typical end-user equipment will vary widely 382 from site to site, allowing site-specific configuration of such 383 bounds is recommended. 384 385 Any benefit against other attacks specific to the HMAC or SHA-1 386 algorithms is probably achieved with a fairly small number of 387 iterations. 388 389 390 391 392 393 394Raeburn Standards Track [Page 7] 395 396RFC 3962 AES Encryption for Kerberos 5 February 2005 397 398 399 In the "optimistic preauthentication" case mentioned in section 3, 400 the client may attempt to produce a key without first communicating 401 with the KDC. If the client has no additional information, it can 402 only guess as to the iteration count to be used. Even such 403 heuristics as "iteration count X was used to acquire tickets for the 404 same principal only N hours ago" can be wrong. Given the 405 recommendation above for increasing the iteration counts used over 406 time, it is impossible to recommend any specific default value for 407 this case; allowing site-local configuration is recommended. (If the 408 lower and upper bound checks described above are implemented, the 409 default count for optimistic preauthentication should be between 410 those bounds.) 411 412 Ciphertext stealing mode, as it requires no additional padding in 413 most cases, will reveal the exact length of each message being 414 encrypted rather than merely bounding it to a small range of possible 415 lengths as in CBC mode. Such obfuscation should not be relied upon 416 at higher levels in any case; if the length must be obscured from an 417 outside observer, this should be done by intentionally varying the 418 length of the message to be encrypted. 419 4209. IANA Considerations 421 422 Kerberos encryption and checksum type values used in section 7 were 423 previously reserved in [KCRYPTO] for the mechanisms defined in this 424 document. The registries have been updated to list this document as 425 the reference. 426 42710. Acknowledgements 428 429 Thanks to John Brezak, Gerardo Diaz Cuellar, Ken Hornstein, Paul 430 Leach, Marcus Watts, Larry Zhu, and others for feedback on earlier 431 versions of this document. 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450Raeburn Standards Track [Page 8] 451 452RFC 3962 AES Encryption for Kerberos 5 February 2005 453 454 455A. Errata for RFC 2040 Section 8 456 457 (Copied from the RFC Editor's errata web site on July 8, 2004.) 458 459 Reported By: Bob Baldwin; baldwin@plusfive.com 460 Date: Fri, 26 Mar 2004 06:49:02 -0800 461 462 In Section 8, Description of RC5-CTS, of the encryption method, 463 it says: 464 465 1. Exclusive-or Pn-1 with the previous ciphertext 466 block, Cn-2, to create Xn-1. 467 468 It should say: 469 470 1. Exclusive-or Pn-1 with the previous ciphertext 471 block, Cn-2, to create Xn-1. For short messages where 472 Cn-2 does not exist, use IV. 473 474 Reported By: Bob Baldwin; baldwin@plusfive.com 475 Date: Mon, 22 Mar 2004 20:26:40 -0800 476 477 In Section 8, first paragraph, second sentence says: 478 479 This mode handles any length of plaintext and produces ciphertext 480 whose length matches the plaintext length. 481 482 In Section 8, first paragraph, second sentence should read: 483 484 This mode handles any length of plaintext longer than one 485 block and produces ciphertext whose length matches the 486 plaintext length. 487 488 In Section 8, step 6 of the decryption method says: 489 490 6. Decrypt En to create Pn-1. 491 492 In Section 8, step 6 of the decryption method should read: 493 494 6. Decrypt En and exclusive-or with Cn-2 to create Pn-1. 495 For short messages where Cn-2 does not exist, use the IV. 496 497 498 499 500 501 502 503 504 505 506Raeburn Standards Track [Page 9] 507 508RFC 3962 AES Encryption for Kerberos 5 February 2005 509 510 511B. Sample Test Vectors 512 513 Sample values for the PBKDF2 HMAC-SHA1 string-to-key function are 514 included below. 515 516 Iteration count = 1 517 Pass phrase = "password" 518 Salt = "ATHENA.MIT.EDUraeburn" 519 128-bit PBKDF2 output: 520 cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15 521 128-bit AES key: 522 42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15 523 256-bit PBKDF2 output: 524 cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15 525 0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37 526 256-bit AES key: 527 fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b 528 bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61 529 530 Iteration count = 2 531 Pass phrase = "password" 532 Salt="ATHENA.MIT.EDUraeburn" 533 128-bit PBKDF2 output: 534 01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d 535 128-bit AES key: 536 c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13 537 256-bit PBKDF2 output: 538 01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d 539 a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86 540 256-bit AES key: 541 a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61 542 02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff 543 544 Iteration count = 1200 545 Pass phrase = "password" 546 Salt = "ATHENA.MIT.EDUraeburn" 547 128-bit PBKDF2 output: 548 5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b 549 128-bit AES key: 550 4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a 551 256-bit PBKDF2 output: 552 5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b 553 a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13 554 256-bit AES key: 555 55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7 556 54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a 557 558 559 560 561 562Raeburn Standards Track [Page 10] 563 564RFC 3962 AES Encryption for Kerberos 5 February 2005 565 566 567 Iteration count = 5 568 Pass phrase = "password" 569 Salt=0x1234567878563412 570 128-bit PBKDF2 output: 571 d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49 572 128-bit AES key: 573 e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e 574 256-bit PBKDF2 output: 575 d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49 576 3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee 577 256-bit AES key: 578 97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c 579 ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31 580 (This test is based on values given in [PECMS].) 581 582 Iteration count = 1200 583 Pass phrase = (64 characters) 584 "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" 585 Salt="pass phrase equals block size" 586 128-bit PBKDF2 output: 587 13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9 588 128-bit AES key: 589 59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed 590 256-bit PBKDF2 output: 591 13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9 592 c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1 593 256-bit AES key: 594 89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0 595 56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34 596 597 Iteration count = 1200 598 Pass phrase = (65 characters) 599 "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" 600 Salt = "pass phrase exceeds block size" 601 128-bit PBKDF2 output: 602 9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61 603 128-bit AES key: 604 cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d 605 256-bit PBKDF2 output: 606 9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61 607 1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a 608 256-bit AES key: 609 d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2 610 14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b 611 612 613 614 615 616 617 618Raeburn Standards Track [Page 11] 619 620RFC 3962 AES Encryption for Kerberos 5 February 2005 621 622 623 Iteration count = 50 624 Pass phrase = g-clef (0xf09d849e) 625 Salt = "EXAMPLE.COMpianist" 626 128-bit PBKDF2 output: 627 6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39 628 128-bit AES key: 629 f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5 630 256-bit PBKDF2 output: 631 6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39 632 e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52 633 256-bit AES key: 634 4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c 635 57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e 636 637 Some test vectors for CBC with ciphertext stealing, using an initial 638 vector of all-zero. 639 640 AES 128-bit key: 641 0000: 63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69 642 643 IV: 644 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 645 Input: 646 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 647 0010: 20 648 Output: 649 0000: c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f 650 0010: 97 651 Next IV: 652 0000: c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f 653 654 IV: 655 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 656 Input: 657 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 658 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 659 Output: 660 0000: fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22 661 0010: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 662 Next IV: 663 0000: fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22 664 665 666 667 668 669 670 671 672 673 674Raeburn Standards Track [Page 12] 675 676RFC 3962 AES Encryption for Kerberos 5 February 2005 677 678 679 IV: 680 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 681 Input: 682 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 683 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 684 Output: 685 0000: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 686 0010: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 687 Next IV: 688 0000: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 689 690 IV: 691 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 692 Input: 693 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 694 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 695 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 696 Output: 697 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 698 0010: b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e 699 0020: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 700 Next IV: 701 0000: b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e 702 703 IV: 704 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 705 Input: 706 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 707 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 708 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 709 Output: 710 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 711 0010: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 712 0020: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 713 Next IV: 714 0000: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730Raeburn Standards Track [Page 13] 731 732RFC 3962 AES Encryption for Kerberos 5 February 2005 733 734 735 IV: 736 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 737 Input: 738 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 739 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 740 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 741 0030: 61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e 742 Output: 743 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 744 0010: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 745 0020: 48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40 746 0030: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 747 Next IV: 748 0000: 48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40 749 750Normative References 751 752 [AC] Schneier, B., "Applied Cryptography", second edition, John 753 Wiley and Sons, New York, 1996. 754 755 [AES] National Institute of Standards and Technology, U.S. 756 Department of Commerce, "Advanced Encryption Standard", 757 Federal Information Processing Standards Publication 197, 758 Washington, DC, November 2001. 759 760 [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for 761 Kerberos 5", RFC 3961, February 2005. 762 763 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 764 Requirement Levels", BCP 14, RFC 2119, March 1997. 765 766 [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography 767 Specification Version 2.0", RFC 2898, September 2000. 768 769 [RC5] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, 770 and RC5-CTS Algorithms", RFC 2040, October 1996. 771 772 [SHA1] National Institute of Standards and Technology, U.S. 773 Department of Commerce, "Secure Hash Standard", Federal 774 Information Processing Standards Publication 180-1, 775 Washington, DC, April 1995. 776 777 778 779 780 781 782 783 784 785 786Raeburn Standards Track [Page 14] 787 788RFC 3962 AES Encryption for Kerberos 5 February 2005 789 790 791Informative References 792 793 [LEACH] Leach, P., email to IETF Kerberos working group mailing 794 list, 5 May 2003, ftp://ftp.ietf.org/ietf-mail- 795 archive/krb-wg/2003-05.mail. 796 797 [PECMS] Gutmann, P., "Password-based Encryption for CMS", RFC 798 3211, December 2001. 799 800Author's Address 801 802 Kenneth Raeburn 803 Massachusetts Institute of Technology 804 77 Massachusetts Avenue 805 Cambridge, MA 02139 806 807 EMail: raeburn@mit.edu 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842Raeburn Standards Track [Page 15] 843 844RFC 3962 AES Encryption for Kerberos 5 February 2005 845 846 847Full Copyright Statement 848 849 Copyright (C) The Internet Society (2005). 850 851 This document is subject to the rights, licenses and restrictions 852 contained in BCP 78, and except as set forth therein, the authors 853 retain all their rights. 854 855 This document and the information contained herein are provided on an 856 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 857 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 858 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 859 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 860 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 861 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 862 863Intellectual Property 864 865 The IETF takes no position regarding the validity or scope of any 866 Intellectual Property Rights or other rights that might be claimed to 867 pertain to the implementation or use of the technology described in 868 this document or the extent to which any license under such rights 869 might or might not be available; nor does it represent that it has 870 made any independent effort to identify any such rights. Information 871 on the IETF's procedures with respect to rights in IETF Documents can 872 be found in BCP 78 and BCP 79. 873 874 Copies of IPR disclosures made to the IETF Secretariat and any 875 assurances of licenses to be made available, or the result of an 876 attempt made to obtain a general license or permission for the use of 877 such proprietary rights by implementers or users of this 878 specification can be obtained from the IETF on-line IPR repository at 879 http://www.ietf.org/ipr. 880 881 The IETF invites any interested party to bring to its attention any 882 copyrights, patents or patent applications, or other proprietary 883 rights that may cover technology that may be required to implement 884 this standard. Please address the information to the IETF at ietf- 885 ipr@ietf.org. 886 887Acknowledgement 888 889 Funding for the RFC Editor function is currently provided by the 890 Internet Society. 891 892 893 894 895 896 897 898Raeburn Standards Track [Page 16] 899 900