1 2 3 4 5 6 7 8 9 10Kerberos Working Group K. Raeburn 11Document: draft-raeburn-krb-rijndael-krb-05.txt MIT 12 June 20, 2003 13 expires December 20, 2003 14 15 AES Encryption for Kerberos 5 16 17Status of this Memo 18 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts 21 are working documents of the Internet Engineering Task Force (IETF), 22 its areas, and its working groups. Note that other groups may also 23 distribute working documents as Internet-Drafts. Internet-Drafts are 24 draft documents valid for a maximum of six months and may be updated, 25 replaced, or obsoleted by other documents at any time. It is 26 inappropriate to use Internet-Drafts as reference material or to cite 27 them other than as "work in progress." 28 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 34 35Abstract 36 37 Recently the US National Institute of Standards and Technology chose 38 a new Advanced Encryption Standard, which is significantly faster and 39 (it is believed) more secure than the old DES algorithm. This 40 document is a specification for the addition of this algorithm to the 41 Kerberos cryptosystem suite. 42 43 Comments should be sent to the author, or to the IETF Kerberos 44 working group (ietf-krb-wg@anl.gov). 45 461. Introduction 47 48 This document defines encryption key and checksum types for Kerberos 49 5 using the AES algorithm recently chosen by NIST. These new types 50 support 128-bit block encryption, and key sizes of 128 or 256 bits. 51 52 53 54 55 56 57 58Raeburn [Page 1] 59 60INTERNET DRAFT June 2003 61 62 63 Using the "simplified profile" of [KCRYPTO], we can define a pair of 64 encryption and checksum schemes. AES is used with cipher text 65 stealing to avoid message expansion, and SHA-1 [SHA1] is the 66 associated checksum function. 67 682. Conventions Used in this Document 69 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC 2119. 73 743. Protocol Key Representation 75 76 The profile in [KCRYPTO] treats keys and random octet strings as 77 conceptually different. But since the AES key space is dense, we can 78 use any bit string of appropriate length as a key. We use the byte 79 representation for the key described in [AES], where the first bit of 80 the bit string is the high bit of the first byte of the byte string 81 (octet string) representation. 82 834. Key Generation From Pass Phrases or Random Data 84 85 Given the above format for keys, we can generate keys from the 86 appropriate amounts of random data (128 or 256 bits) by simply 87 copying the input string. 88 89 To generate an encryption key from a pass phrase and salt string, we 90 use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters 91 indicated below, to generate an intermediate key (of the same length 92 as the desired final key), which is then passed into the DK function 93 with the 8-octet ASCII string "kerberos" as is done for des3-cbc- 94 hmac-sha1-kd in [KCRYPTO]. (In [KCRYPTO] terms, the PBKDF2 function 95 produces a "random octet string", hence the application of the 96 random-to-key function even though it's effectively a simple identity 97 operation.) The resulting key is the user's long-term key for use 98 with the encryption algorithm in question. 99 100 tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength)) 101 key = DK(tkey, "kerberos") 102 103 The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the 104 passphrase and salt, as described in Appendix B.1 to PKCS#5. 105 106 The number of iterations is specified by the string-to-key parameters 107 supplied. The parameter string is four octets indicating an unsigned 108 number in big-endian order. This is the number of iterations to be 109 performed. If the value is 00 00 00 00, the number of iterations to 110 be performed is 4294967296 (2**32). (Thus the minimum expressable 111 112 113 114Raeburn [Page 2] 115 116INTERNET DRAFT June 2003 117 118 119 iteration count is 1.) 120 121 For environments where slower hardware is the norm, implementations 122 may wish to limit the number of iterations to prevent a spoofed 123 response from consuming lots of client-side CPU time; it is 124 recommended that this bound be no less than 50000. Even for 125 environments with fast hardware, 4 billion iterations is likely to 126 take a fairly long time; much larger bounds might still be enforced, 127 and it might be wise for implementations to permit interruption of 128 this operation by the user if the environment allows for it. 129 130 If the string-to-key parameters are not supplied, the value used is 131 00 00 10 00 (decimal 4096, indicating 4096 iterations). 132 133 Note that this is NOT a requirement, nor even a recommendation, for 134 this value to be used in "optimistic preauthentication" (e.g., 135 attempting timestamp-based preauthentication using the user's long- 136 term key, without having first communicated with the KDC) in the 137 absence of additional information, nor as a default value for sites 138 to use for their principals' long-term keys in their Kerberos 139 database. It is simply the interpretation of the absence of the 140 string-to-key parameter field when the KDC has had an opportunity to 141 provide it. 142 143 Sample test vectors are given in the appendix. 144 1455. Cipher Text Stealing 146 147 Cipher block chaining is used to encrypt messages. Unlike previous 148 Kerberos cryptosystems, we use cipher text stealing to handle the 149 possibly partial final block of the message. 150 151 Cipher text stealing is described on pages 195-196 of [AC], and 152 section 8 of [RC5]; it has the advantage that no message expansion is 153 done during encryption of messages of arbitrary sizes as is typically 154 done in CBC mode with padding. 155 156 Cipher text stealing, as defined in [RC5], assumes that more than one 157 block of plain text is available. If exactly one block is to be 158 encrypted, that block is simply encrypted with AES (also known as ECB 159 mode). Input of less than one block is padded at the end to one 160 block; the values of the padding bits are unspecified. 161 (Implementations may use all-zero padding, but protocols should not 162 rely on the result being deterministic. Implementations may use 163 random padding, but protocols should not rely on the result not being 164 deterministic. Note that in most cases, the Kerberos encryption 165 profile will add a random confounder independent of this padding.) 166 167 168 169 170Raeburn [Page 3] 171 172INTERNET DRAFT June 2003 173 174 175 For consistency, cipher text stealing is always used for the last two 176 blocks of the data to be encrypted, as in [RC5]. If the data length 177 is a multiple of the block size, this is equivalent to plain CBC mode 178 with the last two cipher text blocks swapped. 179 180 A test vector is given in the appendix. 181 1826. Kerberos Algorithm Profile Parameters 183 184 This is a summary of the parameters to be used with the simplified 185 algorithm profile described in [KCRYPTO]: 186 187 +--------------------------------------------------------------------+ 188 | protocol key format 128- or 256-bit string | 189 | | 190 | string-to-key function PBKDF2+DK with variable | 191 | iteration count (see | 192 | above) | 193 | | 194 | default string-to-key parameters 00 00 10 00 | 195 | | 196 | key-generation seed length key size | 197 | | 198 | random-to-key function identity function | 199 | | 200 | hash function, H SHA-1 | 201 | | 202 | HMAC output size, h 12 octets (96 bits) | 203 | | 204 | message block size, m 1 octet | 205 | | 206 | encryption/decryption functions, AES in CBC-CTS mode with | 207 | E and D zero ivec (cipher block | 208 | size 16 octets) | 209 +--------------------------------------------------------------------+ 210 211 Using this profile with each key size gives us two each of encryption 212 and checksum algorithm definitions. 213 2147. Assigned Numbers 215 216 The following encryption type numbers are assigned: 217 218 219 220 221 222 223 224 225 226Raeburn [Page 4] 227 228INTERNET DRAFT June 2003 229 230 231 +--------------------------------------------------------------------+ 232 | encryption types | 233 +--------------------------------------------------------------------+ 234 | type name etype value key size | 235 +--------------------------------------------------------------------+ 236 | aes128-cts-hmac-sha1-96 17 128 | 237 | aes256-cts-hmac-sha1-96 18 256 | 238 +--------------------------------------------------------------------+ 239 240 The following checksum type numbers are assigned: 241 242 +--------------------------------------------------------------------+ 243 | checksum types | 244 +--------------------------------------------------------------------+ 245 | type name sumtype value length | 246 +--------------------------------------------------------------------+ 247 | hmac-sha1-96-aes128 15 96 | 248 | hmac-sha1-96-aes256 16 96 | 249 +--------------------------------------------------------------------+ 250 251 These checksum types will be used with the corresponding encryption 252 types defined above. 253 2548. Security Considerations 255 256 This new algorithm has not been around long enough to receive the 257 decades of intense analysis that DES has received. It is possible 258 that some weakness exists that has not been found by the 259 cryptographers analyzing these algorithms before and during the AES 260 selection process. 261 262 The use of the HMAC function has drawbacks for certain pass phrase 263 lengths. For example, a pass phrase longer than the hash function 264 block size (64 bytes, for SHA-1) is hashed to a smaller size (20 265 bytes) before applying the main HMAC algorithm. However, entropy is 266 generally sparse in pass phrases, especially in long ones, so this 267 may not be a problem in the rare cases of users with long pass 268 phrases. 269 270 Also, generating a 256-bit key from a pass phrase of any length may 271 be deceptive, since the effective entropy in pass-phrase-derived key 272 cannot be nearly that large. 273 274 The iteration count in PBKDF2 appears to be useful primarily as a 275 constant multiplier for the amount of work required for an attacker 276 using brute-force methods. Unfortunately, it also multiplies, by the 277 same amount, the work needed by a legitimate user with a valid 278 password. Thus the work factor imposed on an attacker (who may have 279 280 281 282Raeburn [Page 5] 283 284INTERNET DRAFT June 2003 285 286 287 many powerful workstations at his disposal) must be balanced against 288 the work factor imposed on the legitimate user (who may have a PDA or 289 cell phone); the available computing power on either side increases 290 as time goes on, as well. A better way to deal with the brute-force 291 attack is through preauthentication mechanisms that provide better 292 protection of the user's long-term key. Use of such mechanisms is 293 out of scope for this document. 294 295 If a site does wish to use this means of protection against a brute- 296 force attack, the iteration count should be chosen based on the 297 facilities expected to be available to an attacker, and the amount of 298 work the attacker should be required to perform to acquire the key or 299 password. 300 301 As an example: 302 303 The author's tests on a 2GHz Pentium 4 system indicated that in 304 one second, nearly 90000 iterations could be done, producing a 305 256-bit key. This was using the SHA-1 assembly implementation 306 from OpenSSL, and a pre-release version of the PBKDF2 code for 307 MIT's Kerberos package, on a single system. No attempt was made 308 to do multiple hashes in parallel, so we assume an attacker doing 309 so can probably do at least 100000 iterations per second -- 310 rounded up to 2**17, for ease of calculation. For simplicity, we 311 also assume the final AES encryption step costs nothing. 312 313 Paul Leach estimates [LEACH] that a password-cracking dictionary 314 may have on the order of 2**21 entries, with capitalization, 315 punctuation, and other variations contributing perhaps a factor of 316 2**11, giving a ballpark estimate of 2**32. 317 318 Thus, for a known iteration count N and a known salt string, an 319 attacker with some number of computers comparable to the author's 320 would need roughly N*2**15 CPU seconds to convert the entire 321 dictionary plus variations into keys. 322 323 An attacker using a dozen such computers for a month would have 324 roughly 2**25 CPU seconds available. So using 2**12 (4096) 325 iterations would mean an attacker with a dozen such computers 326 dedicated to a brute-force attack against a single key (actually, 327 any password-derived keys sharing the same salt and iteration 328 count) would process all the variations of the dictionary entries 329 in four months, and on average, would likely find the user's 330 password in two months. 331 332 Thus, if this form of attack is of concern, an iteration count a 333 few orders of magnitude higher should be chosen, and users should 334 be required to change their passwords every few months. Perhaps 335 336 337 338Raeburn [Page 6] 339 340INTERNET DRAFT June 2003 341 342 343 several orders of magnitude, since many users will tend to use the 344 shorter and simpler passwords (as much as they can get away with, 345 given a site's password quality checks) that the attacker would 346 likely try first. 347 348 Since this estimate is based on currently available CPU power, the 349 iteration counts used for this mode of defense should be increased 350 over time, at perhaps 40%-60% each year or so. 351 352 Note that if the attacker has a large amount of storage available, 353 intermediate results could be cached, saving a lot of work for the 354 next attack with the same salt and a greater number of iterations 355 than had been run at the point where the intermediate results were 356 saved. Thus, it would be wise to generate a new random salt 357 string when passwords are changed. The default salt string, 358 derived from the principal name, only protects against the use of 359 one dictionary of keys against multiple users. 360 361 If the PBKDF2 iteration count can be spoofed by an intruder on the 362 network, and the limit on the accepted iteration count is very high, 363 the intruder may be able to introduce a form of denial of service 364 attack against the client by sending a very high iteration count, 365 causing the client to spend a great deal of CPU time computing an 366 incorrect key. 367 368 An intruder spoofing the KDC reply, providing a low iteration count, 369 and reading the client's reply from the network may be able to reduce 370 the work needed in the brute-force attack outlined above. Thus, 371 implementations may wish to enforce lower bounds on the number of 372 iterations that will be used. 373 374 Since threat models and typical end-user equipment will vary widely 375 from site to site, allowing site-specific configuration of such 376 bounds is recommended. 377 378 Any benefit against other attacks specific to the HMAC or SHA-1 379 algorithms is probably achieved with a fairly small number of 380 iterations. 381 382 In the "optimistic preauthentication" case mentioned in section 3, 383 the client may attempt to produce a key without first communicating 384 with the KDC. If the client has no additional information, it can 385 only guess as to the iteration count to be used. Even such 386 heuristics as "iteration count X was used to acquire tickets for the 387 same principal only N hours ago" can be wrong. Given the 388 recommendation above for increasing the iteration counts used over 389 time, it is impossible to recommend any specific default value for 390 this case; allowing site-local configuration is recommended. (If the 391 392 393 394Raeburn [Page 7] 395 396INTERNET DRAFT June 2003 397 398 399 lower and upper bound checks described above are implemented, the 400 default count for optimistic preauthentication should be between 401 those bounds.) 402 403 Cipher text stealing mode, since it requires no additional padding in 404 most cases, will reveal the exact length of each message being 405 encrypted, rather than merely bounding it to a small range of 406 possible lengths as in CBC mode. Such obfuscation should not be 407 relied upon at higher levels in any case; if the length must be 408 obscured from an outside observer, it should be done by intentionally 409 varying the length of the message to be encrypted. 410 411 The author is not a cryptographer. Caveat emptor. 412 4139. IANA Considerations 414 415 None. 416 41710. Acknowledgements 418 419 Thanks to John Brezak, Gerardo Diaz Cuellar, Ken Hornstein, Paul 420 Leach, Marcus Watts and others for feedback on earlier versions of 421 this document. 422 423A. Sample test vectors 424 425 Sample values for the PBKDF2 HMAC-SHA1 string-to-key function are 426 included below. 427 428 Iteration count = 1 429 Pass phrase = "password" 430 Salt = "ATHENA.MIT.EDUraeburn" 431 128-bit PBKDF2 output: 432 cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15 433 128-bit AES key: 434 42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15 435 256-bit PBKDF2 output: 436 cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15 437 0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37 438 256-bit AES key: 439 fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b 440 bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61 441 442 443 444 445 446 447 448 449 450Raeburn [Page 8] 451 452INTERNET DRAFT June 2003 453 454 455 Iteration count = 2 456 Pass phrase = "password" 457 Salt="ATHENA.MIT.EDUraeburn" 458 128-bit PBKDF2 output: 459 01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d 460 128-bit AES key: 461 c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13 462 256-bit PBKDF2 output: 463 01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d 464 a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86 465 256-bit AES key: 466 a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61 467 02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff 468 469 Iteration count = 1200 470 Pass phrase = "password" 471 Salt = "ATHENA.MIT.EDUraeburn" 472 128-bit PBKDF2 output: 473 5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b 474 128-bit AES key: 475 4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a 476 256-bit PBKDF2 output: 477 5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b 478 a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13 479 256-bit AES key: 480 55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7 481 54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a 482 483 Iteration count = 5 484 Pass phrase = "password" 485 Salt=0x1234567878563412 486 128-bit PBKDF2 output: 487 d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49 488 128-bit AES key: 489 e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e 490 256-bit PBKDF2 output: 491 d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49 492 3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee 493 256-bit AES key: 494 97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c 495 ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31 496 (This test is based on values given in [PECMS].) 497 498 499 500 501 502 503 504 505 506Raeburn [Page 9] 507 508INTERNET DRAFT June 2003 509 510 511 Iteration count = 1200 512 Pass phrase = (64 characters) 513 "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" 514 Salt="pass phrase equals block size" 515 128-bit PBKDF2 output: 516 13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9 517 128-bit AES key: 518 59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed 519 256-bit PBKDF2 output: 520 13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9 521 c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1 522 256-bit AES key: 523 89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0 524 56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34 525 526 Iteration count = 1200 527 Pass phrase = (65 characters) 528 "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" 529 Salt = "pass phrase exceeds block size" 530 128-bit PBKDF2 output: 531 9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61 532 128-bit AES key: 533 cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d 534 256-bit PBKDF2 output: 535 9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61 536 1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a 537 256-bit AES key: 538 d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2 539 14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b 540 541 Iteration count = 50 542 Pass phrase = g-clef (0xf09d849e) 543 Salt = "EXAMPLE.COMpianist" 544 128-bit PBKDF2 output: 545 6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39 546 128-bit AES key: 547 f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5 548 256-bit PBKDF2 output: 549 6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39 550 e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52 551 256-bit AES key: 552 4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c 553 57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e 554 555 Some test vectors for CBC with cipher text stealing, using an initial 556 vector of all-zero. 557 558 559 560 561 562Raeburn [Page 10] 563 564INTERNET DRAFT June 2003 565 566 567 AES 128-bit key: 568 63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69 569 570 Input: 571 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 572 20 573 Output: 574 c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f 575 97 576 577 Input: 578 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 579 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 580 Output: 581 fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22 582 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 583 584 Input: 585 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 586 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 587 Output: 588 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 589 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 590 591 Input: 592 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 593 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 594 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 595 Output: 596 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 597 b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e 598 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 599 600 Input: 601 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 602 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 603 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 604 Output: 605 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 606 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 607 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 608 609 610 611 612 613 614 615 616 617 618Raeburn [Page 11] 619 620INTERNET DRAFT June 2003 621 622 623 Input: 624 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 625 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 626 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 627 61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e 628 Output: 629 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 630 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 631 48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40 632 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 633 634Normative References 635 636 [AC] Schneier, B., "Applied Cryptography", second edition, John Wiley 637 and Sons, New York, 1996. 638 639 [AES] National Institute of Standards and Technology, U.S. Department 640 of Commerce, "Advanced Encryption Standard", Federal Information 641 Processing Standards Publication 197, Washington, DC, November 2001. 642 643 [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for 644 Kerberos 5", draft-ietf-krb-wg-crypto-01.txt, May, 2002. Work in 645 progress. 646 647 [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography 648 Specification Version 2.0", RFC 2898, September 2000. 649 650 [RC5] Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and 651 RC5-CTS Algorithms", RFC 2040, October 1996. 652 653 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 654 3", RFC 2026, October 1996. 655 656 [SHA1] National Institute of Standards and Technology, U.S. 657 Department of Commerce, "Secure Hash Standard", Federal Information 658 Processing Standards Publication 180-1, Washington, DC, April 1995. 659 660Informative References 661 662 [LEACH] Leach, P., email to IETF Kerberos working group mailing list, 663 5 May 2003, ftp://ftp.ietf.org/ietf-mail-archive/krb-wg/2003-05.mail. 664 665 [PECMS] Gutmann, P., "Password-based Encryption for CMS", RFC 3211, 666 December 2001. 667 668 669 670 671 672 673 674Raeburn [Page 12] 675 676INTERNET DRAFT June 2003 677 678 679Author's Address 680 681 Kenneth Raeburn 682 Massachusetts Institute of Technology 683 77 Massachusetts Avenue 684 Cambridge, MA 02139 685 raeburn@mit.edu 686 687Full Copyright Statement 688 689 Copyright (C) The Internet Society (2003). All Rights Reserved. 690 691 This document and translations of it may be copied and furnished to 692 others, and derivative works that comment on or otherwise explain it 693 or assist in its implementation may be prepared, copied, published 694 and distributed, in whole or in part, without restriction of any 695 kind, provided that the above copyright notice and this paragraph are 696 included on all such copies and derivative works. However, this 697 document itself may not be modified in any way, such as by removing 698 the copyright notice or references to the Internet Society or other 699 Internet organizations, except as needed for the purpose of 700 developing Internet standards in which case the procedures for 701 copyrights defined in the Internet Standards process must be 702 followed, or as required to translate it into languages other than 703 English. 704 705 The limited permissions granted above are perpetual and will not be 706 revoked by the Internet Society or its successors or assigns. 707 708 This document and the information contained herein is provided on an 709 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 710 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 711 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 712 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 713 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 714 715Notes to RFC Editor 716 717 Assuming this document goes through Last Call along with the Kerberos 718 crypto framework draft, the reference entry for [KCRYPTO] will list 719 the draft name, not the RFC number. This should be replaced with the 720 RFC info. 721 722 Remove Kerberos working group contact info from the Abstract; it's 723 right for the draft, but not the final RFC. 724 725 726 727 728 729 730Raeburn [Page 13] 731