1 2 3 4 5 6 7 8 9 10INTERNET DRAFT K. Raeburn 11Kerberos Working Group MIT 12Document: draft-ietf-krb-wg-crypto-07.txt February 10, 2004 13 expires August 10, 2004 14 15 Encryption and Checksum Specifications 16 for Kerberos 5 17 18Status of this Memo 19 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts 22 are working documents of the Internet Engineering Task Force (IETF), 23 its areas, and its working groups. Note that other groups may also 24 distribute working documents as Internet-Drafts. Internet-Drafts are 25 draft documents valid for a maximum of six months and may be updated, 26 replaced, or obsoleted by other documents at any time. It is 27 inappropriate to use Internet-Drafts as reference material or to cite 28 them other than as "work in progress." 29 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.html. 32 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 35 36Abstract 37 38 This document describes a framework for defining encryption and 39 checksum mechanisms for use with the Kerberos protocol, defining an 40 abstraction layer between the Kerberos protocol and related 41 protocols, and the actual mechanisms themselves. Several mechanisms 42 are also defined in this document. Some are taken from RFC 1510, 43 modified in form to fit this new framework, and occasionally modified 44 in content when the old specification was incorrect. New mechanisms 45 are presented here as well. This document does NOT indicate which 46 mechanisms may be considered "required to implement". 47 48 Comments should be sent to the editor, or to the IETF Kerberos 49 working group (ietf-krb-wg@anl.gov). 50 51 52 53 54 55 56 57 58Raeburn [Page 1] 59 60INTERNET DRAFT February 2004 61 62 63 1mTable of Contents0m 64 65 66Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . . 1 67Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 68Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2 691. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 702. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 713. Encryption algorithm profile . . . . . . . . . . . . . . . . . . 4 724. Checksum algorithm profile . . . . . . . . . . . . . . . . . . . 9 735. Simplified profile for CBC ciphers with key derivation . . . . . 10 745.1. A key derivation function . . . . . . . . . . . . . . . . . . . 11 755.2. Simplified profile parameters . . . . . . . . . . . . . . . . . 13 765.3. Cryptosystem profile based on simplified profile . . . . . . . 14 775.4. Checksum profiles based on simplified profile . . . . . . . . . 16 786. Profiles for Kerberos encryption and checksum algorithms . . . . 16 796.1. Unkeyed checksums . . . . . . . . . . . . . . . . . . . . . . . 17 806.2. DES-based encryption and checksum types . . . . . . . . . . . . 18 816.3. Triple-DES based encryption and checksum types . . . . . . . . 28 827. Use of Kerberos encryption outside this specification . . . . . . 30 838. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . . . 31 849. Implementation Notes . . . . . . . . . . . . . . . . . . . . . . 33 8510. Security Considerations . . . . . . . . . . . . . . . . . . . . 33 8611. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 35 8712. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 36 88A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . . . 37 89A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 90A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . . . . . 39 91A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . . . . . 43 92A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . . . . . 44 93A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . . . . . 45 94B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . . . 45 95Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 96Intellectual Property Statement . . . . . . . . . . . . . . . . . . 47 97Normative References . . . . . . . . . . . . . . . . . . . . . . . . 48 98Informative References . . . . . . . . . . . . . . . . . . . . . . . 49 99Editor's address . . . . . . . . . . . . . . . . . . . . . . . . . . 50 100Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 50 101 102 103 104 105 106 107 108 109 110 111 112 113 114Raeburn [Page 2] 115 116INTERNET DRAFT February 2004 117 118 1191. Introduction 120 121 The Kerberos protocols [Kerb] are designed to encrypt messages of 122 arbitrary sizes, using block encryption ciphers, or less commonly, 123 stream encryption ciphers. Encryption is used to prove the 124 identities of the network entities participating in message 125 exchanges. However, nothing in the Kerberos protocol requires any 126 specific encryption algorithm be used, as long as certain operations 127 are available in the algorithm that is used. 128 129 The following sections specify the encryption and checksum mechanisms 130 currently defined for Kerberos, as well as a framework for defining 131 future mechanisms. The encoding, chaining, padding and other 132 requirements for each are described. Test vectors for several 133 functions are given in appendix A. 134 1352. Concepts 136 137 Both encryption and checksum mechanisms are defined in terms of 138 profiles, detailed in later sections. Each specifies a collection of 139 operations and attributes that must be defined for a mechanism. A 140 Kerberos encryption or checksum mechanism specification is not 141 complete if it does not define all of these operations and 142 attributes. 143 144 An encryption mechanism must provide for confidentiality and 145 integrity of the original plaintext. (Integrity checking may be 146 achieved by incorporating a checksum, if the encryption mode does not 147 provide an integrity check itself.) It must also provide non- 148 malleability [Bellare98, Dolev91]. Use of a random confounder 149 prepended to the plaintext is recommended. It should not be possible 150 to determine if two ciphertexts correspond to the same plaintext, 151 without knowledge of the key. 152 153 A checksum mechanism [1] must provide proof of the integrity of the 154 associated message, and must preserve the confidentiality of the 155 message in case it is not sent in the clear. It should be infeasible 156 to find two plaintexts which have the same checksum. It is NOT 157 required that an eavesdropper be unable to determine if two checksums 158 are for the same message; it is assumed that the messages themselves 159 will be visible to any such eavesdropper. 160 161 Due to advances in cryptography, it is considered unwise by some 162 cryptographers to use the same key for multiple purposes. Since keys 163 are used in performing a number of different functions in Kerberos, 164 it is desirable to use different keys for each of these purposes, 165 even though we start with a single long-term or session key. 166 167 168 169 170Raeburn [Page 3] 171 172INTERNET DRAFT February 2004 173 174 175 We do this by enumerating the different uses of keys within Kerberos, 176 and making the "usage number" an input to the encryption or checksum 177 mechanisms; this enumeration is outside the scope of this document. 178 Later sections of this document define simplified profile templates 179 for encryption and checksum mechanisms that use a key derivation 180 function applied to a CBC mode (or similar) cipher and a checksum or 181 hash algorithm. 182 183 We distinguish the "base key" specified by other documents from the 184 "specific key" to be used for a particular instance of encryption or 185 checksum operations. It is expected but not required that the 186 specific key will be one or more separate keys derived from the 187 original protocol key and the key usage number. The specific key 188 should not be explicitly referenced outside of this document. The 189 typical language used in other documents should be something like, 190 "encrypt this octet string using this key and this usage number"; 191 generation of the specific key and cipher state (described in the 192 next section) are implicit. The creation of a new cipher-state 193 object, or the re-use of one from a previous encryption operation, 194 may also be explicit. 195 196 New protocols defined in terms of the Kerberos encryption and 197 checksum types should use their own key usage values. Key usages are 198 unsigned 32 bit integers; zero is not permitted. 199 200 All data is assumed to be in the form of strings of octets or 8-bit 201 bytes. Environments with other byte sizes will have to emulate this 202 behavior in order to get correct results. 203 204 Each algorithm is assigned an encryption type (or "etype") or 205 checksum type number, for algorithm identification within the 206 Kerberos protocol. The full list of current type number assignments 207 is given in section 8. 208 2093. Encryption algorithm profile 210 211 An encryption mechanism profile must define the following attributes 212 and operations. The operations must be defined as functions in the 213 mathematical sense: no additional or implicit inputs (such as 214 Kerberos principal names or message sequence numbers) are permitted. 215 216 protocol key format 217 This describes what octet string values represent valid keys. For 218 encryption mechanisms that don't have perfectly dense key spaces, 219 this will describe the representation used for encoding keys. It 220 need not describe specific values that are not valid or desirable 221 for use; such values should be avoid by all key generation 222 routines. 223 224 225 226Raeburn [Page 4] 227 228INTERNET DRAFT February 2004 229 230 231 specific key structure 232 This is not a protocol format at all, but a description of the 233 keying material derived from the chosen key and used to encrypt or 234 decrypt data or compute or verify a checksum. It may, for 235 example, be a single key, a set of keys, or a combination of the 236 original key with additional data. The authors recommend using 237 one or more keys derived from the original key via one-way key 238 derivation functions. 239 240 required checksum mechanism 241 This indicates a checksum mechanism that must be available when 242 this encryption mechanism is used. Since Kerberos has no built in 243 mechanism for negotiating checksum mechanisms, once an encryption 244 mechanism has been decided upon, the corresponding checksum 245 mechanism can simply be used. 246 247 key-generation seed length, K 248 This is the length of the random bitstring needed to generate a 249 key with the encryption scheme's random-to-key function (described 250 below). This must be a fixed value so that various techniques for 251 producing a random bitstring of a given length may be used with 252 key generation functions. 253 254 key generation functions 255 Keys must be generated in a number of cases, from different types 256 of inputs. All function specifications must indicate how to 257 generate keys in the proper wire format, and must avoid generation 258 of keys that significantly compromise the confidentiality of 259 encrypted data, if the cryptosystem has such. Entropy from each 260 source should be preserved as much as possible. Many of the 261 inputs, while unknown, may be at least partly predictable (e.g., a 262 password string is likely to be entirely in the ASCII subset and 263 of fairly short length in many environments; a semi-random string 264 may include timestamps); the benefit of such predictability to an 265 attacker must be minimized. 266 267 string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key) 268 This function generates a key from two UTF-8 strings and an 269 opaque octet string. One of the strings is normally the 270 principal's pass phrase, but is in general merely a secret 271 string. The other string is a "salt" string intended to 272 produce different keys from the same password for different 273 users or realms. While the strings provided will use UTF-8 274 encoding, no specific version of Unicode should be assumed; all 275 valid UTF-8 strings should be allowed. Strings provided in 276 other encodings MUST first be converted to UTF-8 before 277 applying this function. 278 279 280 281 282Raeburn [Page 5] 283 284INTERNET DRAFT February 2004 285 286 287 The third argument, the octet string, may be used to pass 288 mechanism-specific parameters in to this function. Since doing 289 so implies knowledge of the specific encryption system, it is 290 intended that generating non-default parameter values be an 291 uncommon operation, and that normal Kerberos applications be 292 able to treat this parameter block as an opaque object supplied 293 by the Key Distribution Center or defaulted to some mechanism- 294 specific constant value. 295 296 The string-to-key function should be a one-way function, so 297 that compromising a user's key in one realm does not compromise 298 the user's key in another realm, even if the same password (but 299 a different salt) is used. 300 301 random-to-key (bitstring[K])->(protocol-key) 302 This function generates a key from a random bitstring of a 303 specific size. It may be assumed that all the bits of the 304 input string are equally random, even though the entropy 305 present in the random source may be limited. 306 307 key-derivation (protocol-key, integer)->(specific-key) 308 In this function, the integer input is the key usage value as 309 described above; the usage values must be assumed to be known 310 to an attacker. The specific-key output value was described in 311 section 2. 312 313 string-to-key parameter format 314 This describes the format of the block of data that can be passed 315 to the string-to-key function above to configure additional 316 parameters for that function. Along with the mechanism of 317 encoding parameter values, bounds on the allowed parameters should 318 also be described to avoid allowing a spoofed KDC to compromise 319 the user's password. It may be desirable to construct the 320 encoding such that values weakening the resulting key unacceptably 321 cannot be encoded, if practical. 322 323 Tighter bounds might be permitted by local security policy, or to 324 avoid excess resource consumption; if so, recommended defaults for 325 those bounds should be given in the specification. The 326 description should also outline possible weaknesses that may be 327 caused by not applying bounds checks or other validation to a 328 parameter string received from the network. 329 330 As mentioned above, this should be considered opaque to most 331 normal applications. 332 333 334 335 336 337 338Raeburn [Page 6] 339 340INTERNET DRAFT February 2004 341 342 343 default string-to-key parameters (octet string) 344 This default value for the "params" argument to the string-to-key 345 function is to be used when the application protocol (Kerberos or 346 otherwise) does not explicitly set the parameter value. As 347 indicated above, this parameter block should be treated as an 348 opaque object in most cases. 349 350 cipher state 351 This describes any information that can be carried over from one 352 encryption or decryption operation to the next, for use in 353 conjunction with a given specific key. For example, a block 354 cipher used in CBC mode may put an initial vector of one block in 355 the cipher state. Other encryption modes may track nonces or 356 other data. 357 358 This state must be non-empty, and must influence encryption so as 359 to require that messages be decrypted in the same order they were 360 encrypted, if the cipher state is carried over from one encryption 361 to the next. Distinguishing out-of-order or missing messages from 362 corrupted messages is not required; if desired, this can be done 363 at a higher level by including sequence numbers and not "chaining" 364 the cipher state between encryption operations. 365 366 The cipher state may not be reused in multiple encryption or 367 decryption operations; these operations all generate a new cipher 368 state that may be used for following operations using the same key 369 and operation. 370 371 The contents of the cipher state must be treated as opaque outside 372 of encryption system specifications. 373 374 initial cipher state (specific-key, direction)->(state) 375 This describes the generation of the initial value for the cipher 376 state if it is not being carried over from a previous encryption 377 or decryption operation. 378 379 This describes any initial state setup needed before encrypting 380 arbitrary amounts of data with a given specific key; the specific 381 key and the direction of operations to be performed (encrypt 382 versus decrypt) must be the only input needed for this 383 initialization. 384 385 This state should be treated as opaque in any uses outside of an 386 encryption algorithm definition. 387 388 IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what 389 degree an application protocol could exercise control over the 390 initial vector used in DES CBC operations. Some existing 391 392 393 394Raeburn [Page 7] 395 396INTERNET DRAFT February 2004 397 398 399 implementations permit the setting of the initial vector. This 400 framework does not provide for application control of the cipher 401 state (beyond "initialize" and "carry over from previous 402 encryption"), since the form and content of the initial cipher 403 state can vary between encryption systems, and may not always be a 404 single block of random data. 405 406 New Kerberos application protocols should not assume that they can 407 control the initial vector, or that one even exists. However, a 408 general-purpose implementation may wish to provide the capability, 409 in case applications explicitly setting it are encountered. 410 411 encrypt (specific-key, state, octet string)->(state, octet string) 412 This function takes the specific key, cipher state, and a non- 413 empty plaintext string as input, and generates ciphertext and a 414 new cipher state as outputs. If the basic encryption algorithm 415 itself does not provide for integrity protection (as DES in CBC 416 mode does not do), then some form of MAC or checksum must be 417 included that can be verified by the receiver. Some random factor 418 such as a confounder should be included so that an observer cannot 419 know if two messages contain the same plaintext, even if the 420 cipher state and specific keys are the same. The exact length of 421 the plaintext need not be encoded, but if it is not and if padding 422 is required, the padding must be added at the end of the string so 423 that the decrypted version may be parsed from the beginning. 424 425 The specification of the encryption function must not only 426 indicate the precise contents of the output octet string, but also 427 the output cipher state. The application protocol may carry 428 forward the output cipher state from one encryption with a given 429 specific key to another; the effect of this "chaining" must be 430 defined. [2] 431 432 Assuming correctly-produced values for the specific key and cipher 433 state, no input octet string may result in an error indication. 434 435 decrypt (specific-key, state, octet string)->(state, octet string) 436 This function takes the specific key, cipher state, and ciphertext 437 as inputs, and verifies the integrity of the supplied ciphertext. 438 If the ciphertext's integrity is intact, this function produces 439 the plaintext and a new cipher state as outputs; otherwise, an 440 error indication must be returned, and the data discarded. 441 442 The result of the decryption may be longer than the original 443 plaintext, for example if the encryption mode adds padding to 444 reach a multiple of a block size. If this is the case, any extra 445 octets must be after the decoded plaintext. An application 446 protocol which needs to know the exact length of the message must 447 448 449 450Raeburn [Page 8] 451 452INTERNET DRAFT February 2004 453 454 455 encode a length or recognizable "end of message" marker within the 456 plaintext. [3] 457 458 As with the encryption function, a correct specification for this 459 function must indicate not only the contents of the output octet 460 string, but also the resulting cipher state. 461 462 pseudo-random (protocol-key, octet-string)->(octet-string) 463 This pseudo-random function should generate an octet string of 464 some size that independent of the octet string input. The PRF 465 output string should be suitable for use in key generation, even 466 if the octet string input is public. It should not reveal the 467 input key, even if the output is made public. 468 469 These operations and attributes are all that is required to support 470 Kerberos and various proposed preauthentication schemes. 471 472 For convenience of certain application protocols that may wish to use 473 the encryption profile, we add the constraint that, for any given 474 plaintext input size, there must be a message size between that given 475 size and that size plus 65535 such that the length of such that the 476 decrypted version of the ciphertext for any message of that size will 477 never have extra octets added at the end. 478 479 Expressed mathematically, for every message length L1, there exists a 480 message size L2 such that: 481 482 L2 >= L1 483 L2 < L1 + 65536 484 for every message M with |M| = L2, decrypt(encrypt(M)) = M 485 486 A document defining a new encryption type should also describe known 487 weaknesses or attacks, so that its security may be fairly assessed, 488 and should include test vectors or other validation procedures for 489 the operations defined. Specific references to information readily 490 available elsewhere are sufficient. 491 4924. Checksum algorithm profile 493 494 A checksum mechanism profile must define the following attributes and 495 operations: 496 497 associated encryption algorithm(s) 498 This indicates the types of encryption keys this checksum 499 mechanism can be used with. 500 501 A keyed checksum mechanism may have more than one associated 502 encryption algorithm if they share the same wire key format, 503 504 505 506Raeburn [Page 9] 507 508INTERNET DRAFT February 2004 509 510 511 string-to-key function, and key derivation function. (This 512 combination means that, for example, a checksum type, key usage 513 value and password are adequate to get the specific key used to 514 compute a checksum.) 515 516 An unkeyed checksum mechanism can be used in conjunction with any 517 encryption type, since the key is ignored, but its use must be 518 limited to cases where the checksum itself is protected, to avoid 519 trivial attacks. 520 521 get_mic function 522 This function generates a MIC token for a given specific key (see 523 section 3), and message (represented as an octet string), that may 524 be used to verify the integrity of the associated message. This 525 function is not required to return the same deterministic result 526 on every use; it need only generate a token that the verify_mic 527 routine can check. 528 529 The output of this function will also dictate the size of the 530 checksum. It must be no larger than 65535 octets. 531 532 verify_mic function 533 Given a specific key, message, and MIC token, this function 534 ascertains whether the message integrity has been compromised. 535 For a deterministic get_mic routine, the corresponding verify_mic 536 may simply generate another checksum and compare them. 537 538 The get_mic and verify_mic operations must be able to handle inputs 539 of arbitrary length; if any padding is needed, the padding scheme 540 must be specified as part of these functions. 541 542 These operations and attributes are all that should be required to 543 support Kerberos and various proposed preauthentication schemes. 544 545 As with encryption mechanism definition documents, documents defining 546 new checksum mechanisms should indicate validation processes and 547 known weaknesses. 548 5495. Simplified profile for CBC ciphers with key derivation 550 551 The profile outlines in sections 3 and 4 describes a large number of 552 operations that must be defined for encryption and checksum 553 algorithms to be used with Kerberos. We describe here a simpler 554 profile from which both encryption and checksum mechanism definitions 555 can be generated, filling in uses of key derivation in appropriate 556 places, providing integrity protection, and defining multiple 557 operations for the cryptosystem profile based on a smaller set of 558 operations given in the simplified profile. Not all of the existing 559 560 561 562Raeburn [Page 10] 563 564INTERNET DRAFT February 2004 565 566 567 cryptosystems for Kerberos fit into this simplified profile, but we 568 recommend that future cryptosystems use it or something based on it. 569 [4] 570 571 Not all of the operations in the complete profiles are defined 572 through this mechanism; several must still be defined for each new 573 algorithm pair. 574 5755.1. A key derivation function 576 577 Rather than define some scheme by which a "protocol key" is composed 578 of a large number of encryption keys, we use keys derived from a base 579 key to perform cryptographic operations. The base key must be used 580 only for generating the derived keys, and this derivation must be 581 non-invertible and entropy-preserving. Given these restrictions, 582 compromise of one derived key does not compromise the other subkeys. 583 Attack of the base key is limited, since it is only used for 584 derivation, and is not exposed to any user data. 585 586 Since the derived key has as much entropy as the base keys (if the 587 cryptosystem is good), password-derived keys have the full benefit of 588 all the entropy in the password. 589 590 To generate a derived key from a base key, we generate a pseudorandom 591 octet string, using an algorithm DR described below, and generate a 592 key from that octet string using a function dependent on the 593 encryption algorithm; the input length needed for that function, 594 which is also dependent on the encryption algorithm, dictates the 595 length of the string to be generated by the DR algorithm (the value 596 "k" below). These procedures are based on the key derivation in 597 [Blumenthal96]. 598 599 Derived Key = DK(Base Key, Well-Known Constant) 600 601 DK(Key, Constant) = random-to-key(DR(Key, Constant)) 602 603 DR(Key, Constant) = k-truncate(E(Key, Constant, 604 initial-cipher-state)) 605 606 Here DR is the random-octet generation function described below, and 607 DK is the key-derivation function produced from it. In this 608 construction, E(Key, Plaintext, CipherState) is a cipher, Constant is 609 a well-known constant determined by the specific usage of this 610 function, and k-truncate truncates its argument by taking the first k 611 bits. Here, k is the key generation seed length needed for the 612 encryption system. 613 614 The output of the DR function is a string of bits; the actual key is 615 616 617 618Raeburn [Page 11] 619 620INTERNET DRAFT February 2004 621 622 623 produced by applying the cryptosystem's random-to-key operation on 624 this bitstring. 625 626 If the Constant is smaller than the cipher block size of E, then it 627 must be expanded with n-fold() so it can be encrypted. If the output 628 of E is shorter than k bits it is fed back into the encryption as 629 many times as necessary. The construct is as follows (where | 630 indicates concatentation): 631 632 K1 = E(Key, n-fold(Constant), initial-cipher-state) 633 K2 = E(Key, K1, initial-cipher-state) 634 K3 = E(Key, K2, initial-cipher-state) 635 K4 = ... 636 637 DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...) 638 639 n-fold is an algorithm which takes m input bits and ``stretches'' 640 them to form n output bits with equal contribution from each input 641 bit to the output, as described in [Blumenthal96]: 642 643 We first define a primitive called n-folding, which takes a 644 variable-length input block and produces a fixed-length output 645 sequence. The intent is to give each input bit approximately 646 equal weight in determining the value of each output bit. Note 647 that whenever we need to treat a string of octets as a number, the 648 assumed representation is Big-Endian -- Most Significant Byte 649 first. 650 651 To n-fold a number X, replicate the input value to a length that 652 is the least common multiple of n and the length of X. Before 653 each repetition, the input is rotated to the right by 13 bit 654 positions. The successive n-bit chunks are added together using 655 1's-complement addition (that is, with end-around carry) to yield 656 a n-bit result.... 657 658 659 Test vectors for n-fold are supplied in Appendix A. [5] 660 661 In this section, n-fold is always used to produce c bits of output, 662 where c is the cipher block size of E. 663 664 The size of the Constant must not be larger than c, because reducing 665 the length of the Constant by n-folding can cause collisions. 666 667 If the size of the Constant is smaller than c, then the Constant must 668 be n-folded to length c. This string is used as input to E. If the 669 block size of E is less than the random-to-key input size, then the 670 output from E is taken as input to a second invocation of E. This 671 672 673 674Raeburn [Page 12] 675 676INTERNET DRAFT February 2004 677 678 679 process is repeated until the number of bits accumulated is greater 680 than or equal to the random-to-key input size. When enough bits have 681 been computed, the first k are taken as the random data used to 682 create the key with the algorithm-dependent random-to-key function. 683 684 Since the derived key is the result of one or more encryptions in the 685 base key, deriving the base key from the derived key is equivalent to 686 determining the key from a very small number of plaintext/ciphertext 687 pairs. Thus, this construction is as strong as the cryptosystem 688 itself. 689 6905.2. Simplified profile parameters 691 692 These are the operations and attributes that must be defined: 693 694 protocol key format 695 string-to-key function 696 default string-to-key parameters 697 key-generation seed length, k 698 random-to-key function 699 As above for the normal encryption mechanism profile. 700 701 unkeyed hash algorithm, H 702 This should be a collision-resistant hash algorithm with fixed- 703 size output, suitable for use in an HMAC [HMAC]. It must support 704 inputs of arbitrary length. Its output must be at least the 705 message block size (below). 706 707 HMAC output size, h 708 This indicates the size of the leading substring output by the 709 HMAC function that should be used in transmitted messages. It 710 should be at least half the output size of the hash function H, 711 and at least 80 bits; it need not match the output size. 712 713 message block size, m 714 This is the size of the smallest units the cipher can handle in 715 the mode in which it is being used. Messages will be padded to a 716 multiple of this size. If a block cipher is used in a mode that 717 can handle messages that are not multiples of the cipher block 718 size, such as CBC mode with cipher text stealing (CTS, see [RC5]), 719 this value would be one octet. For traditional CBC mode with 720 padding, it will be the underlying cipher's block size. 721 722 This value must be a multiple of 8 bits (one octet). 723 724 725 726 727 728 729 730Raeburn [Page 13] 731 732INTERNET DRAFT February 2004 733 734 735 encryption/decryption functions, E and D 736 These are basic encryption and decryption functions for messages 737 of sizes that are multiples of the message block size. No 738 integrity checking or confounder should be included here. These 739 functions take as input the IV or similar data, a protocol-format 740 key, and a octet string, returning a new IV and octet string. 741 742 The encryption function is not required to use CBC mode, but is 743 assumed to be using something with similar properties. In 744 particular, prepending a cipher-block-size confounder to the 745 plaintext should alter the entire ciphertext (comparable to 746 choosing and including a random initial vector for CBC mode). 747 748 The result of encrypting one cipher block (of size c, above) must 749 be deterministic, for the random octet generation function DR in 750 the previous section to work. For best security, it should also 751 be no larger than c. 752 753 cipher block size, c 754 This is the block size of the block cipher underlying the 755 encryption and decryption functions indicated above, used for key 756 derivation and for the size of the message confounder and initial 757 vector. (If a block cipher is not in use, some comparable 758 parameter should be determined.) It must be at least 5 octets. 759 760 This is not actually an independent parameter; rather, it is a 761 property of the functions E and D. It is listed here to clarify 762 the distinction between it and the message block size, m. 763 764 While there are still a number of properties to specify, they are 765 fewer and simpler than in the full profile. 766 7675.3. Cryptosystem profile based on simplified profile 768 769 The above key derivation function is used to produce three 770 intermediate keys. One is used for computing checksums of 771 unencrypted data. The other two are used for encrypting and 772 checksumming plaintext to be sent encrypted. 773 774 The ciphertext output is the concatenation of the output of the basic 775 encryption function E and a (possibly truncated) HMAC using the 776 specified hash function H, both applied to the plaintext with a 777 random confounder prefix and sufficient padding to bring it to a 778 multiple of the message block size. When the HMAC is computed, the 779 key is used in the protocol key form. 780 781 Decryption is performed by removing the (partial) HMAC, decrypting 782 the remainder, and verifying the HMAC. The cipher state is an 783 784 785 786Raeburn [Page 14] 787 788INTERNET DRAFT February 2004 789 790 791 initial vector, initialized to zero. 792 793 The substring notation "[1..h]" in the following table should be read 794 as using 1-based indexing; leading substrings are used. 795 796 797 cryptosystem from simplified profile 798---------------------------------------------------------------------------- 799protocol key format As given. 800 801specific key structure Three protocol-format keys: { Kc, Ke, Ki }. 802 803key-generation seed As given. 804length 805 806required checksum As defined below in section 5.4. 807mechanism 808 809cipher state initial vector (usually of length c) 810 811initial cipher state all bits zero 812 813encryption function conf = random string of length c 814 pad = shortest string to bring confounder 815 and plaintext to a length that's a 816 multiple of m 817 (C1, newIV) = E(Ke, conf | plaintext | pad, 818 oldstate.ivec) 819 H1 = HMAC(Ki, conf | plaintext | pad) 820 ciphertext = C1 | H1[1..h] 821 newstate.ivec = newIV 822 823decryption function (C1,H1) = ciphertext 824 (P1, newIV) = D(Ke, C1, oldstate.ivec) 825 if (H1 != HMAC(Ki, P1)[1..h]) 826 report error 827 newstate.ivec = newIV 828 829default string-to-key As given. 830params 831 832pseudo-random function tmp1 = H(octet-string) 833 tmp2 = truncate tmp1 to multiple of m 834 PRF = E(protocol-key, tmp2, initial-cipher-state) 835 836key generation functions: 837 838 839 840 841 842Raeburn [Page 15] 843 844INTERNET DRAFT February 2004 845 846 847 cryptosystem from simplified profile 848---------------------------------------------------------------------------- 849string-to-key function As given. 850 851random-to-key function As given. 852 853key-derivation function The "well-known constant" used for the DK 854 function is the key usage number, expressed as 855 four octets in big-endian order, followed by one 856 octet indicated below. 857 858 Kc = DK(base-key, usage | 0x99); 859 Ke = DK(base-key, usage | 0xAA); 860 Ki = DK(base-key, usage | 0x55); 861 862 8635.4. Checksum profiles based on simplified profile 864 865 When an encryption system is defined using the simplified profile 866 given in section 5.2, a checksum algorithm may be defined for it as 867 follows: 868 869 870 checksum mechanism from simplified profile 871 -------------------------------------------------- 872 associated cryptosystem as defined above 873 874 get_mic HMAC(Kc, message)[1..h] 875 876 verify_mic get_mic and compare 877 878 The HMAC function and key Kc are as described in section 5.3. 879 8806. Profiles for Kerberos encryption and checksum algorithms 881 882 These profiles describe the encryption and checksum systems defined 883 for Kerberos. The astute reader will notice that some of them do not 884 fulfull all of the requirements outlined in previous sections. These 885 systems are defined for backward compatibility; newer implementations 886 should (whenever possible) attempt to make use of encryption systems 887 which satisfy all of the profile requirements. 888 889 The full list of current encryption and checksum type number 890 assignments, including values currently reserved but not defined in 891 this document, is given in section 8. 892 893 894 895 896 897 898Raeburn [Page 16] 899 900INTERNET DRAFT February 2004 901 902 9036.1. Unkeyed checksums 904 905 These checksum types use no encryption keys, and thus can be used in 906 combination with any encryption type, but may only be used with 907 caution, in limited circumstances where the lack of a key does not 908 provide a window for an attack, preferably as part of an encrypted 909 message. [6] Keyed checksum algorithms are recommended. 910 9116.1.1. The RSA MD5 Checksum 912 913 The RSA-MD5 checksum calculates a checksum using the RSA MD5 914 algorithm [MD5-92]. The algorithm takes as input an input message of 915 arbitrary length and produces as output a 128-bit (16 octet) 916 checksum. RSA-MD5 is believed to be collision-proof. 917 918 rsa-md5 919 ---------------------------------------------- 920 associated cryptosystem any 921 922 get_mic rsa-md5(msg) 923 924 verify_mic get_mic and compare 925 926 The rsa-md5 checksum algorithm is assigned a checksum type number of 927 seven (7). 928 9296.1.2. The RSA MD4 Checksum 930 931 The RSA-MD4 checksum calculates a checksum using the RSA MD4 932 algorithm [MD4-92]. The algorithm takes as input an input message of 933 arbitrary length and produces as output a 128-bit (16 octet) 934 checksum. RSA-MD4 is believed to be collision-proof. 935 936 937 rsa-md4 938 ---------------------------------------------- 939 associated cryptosystem any 940 941 get_mic md4(msg) 942 943 verify_mic get_mic and compare 944 945 946 The rsa-md4 checksum algorithm is assigned a checksum type number of 947 two (2). 948 949 950 951 952 953 954Raeburn [Page 17] 955 956INTERNET DRAFT February 2004 957 958 9596.1.3. CRC-32 Checksum 960 961 This CRC-32 checksum calculates a checksum based on a cyclic 962 redundancy check as described in ISO 3309 [CRC], modified as 963 described below. The resulting checksum is four (4) octets in 964 length. The CRC-32 is neither keyed nor collision-proof; thus, the 965 use of this checksum is not recommended. An attacker using a 966 probabilistic chosen-plaintext attack as described in [SG92] might be 967 able to generate an alternative message that satisfies the checksum. 968 969 The CRC-32 checksum used in the des-cbc-crc encryption mode is 970 identical to the 32-bit FCS described in ISO 3309 with two 971 exceptions: the sum with the all-ones polynomial times x**k is 972 omitted, and the final remainder is not ones-complemented. ISO 3309 973 describes the FCS in terms of bits, while this document describes the 974 Kerberos protocol in terms of octets. To disambiguate the ISO 3309 975 definition for the purpose of computing the CRC-32 in the des-cbc-crc 976 encryption mode, the ordering of bits in each octet shall be assumed 977 to be LSB-first. Given this assumed ordering of bits within an 978 octet, the mapping of bits to polynomial coefficients shall be 979 identical to that specified in ISO 3309. 980 981 Test values for this modified CRC function are included in appendix 982 A.5. 983 984 985 crc32 986 ---------------------------------------------- 987 associated cryptosystem any 988 989 get_mic crc32(msg) 990 991 verify_mic get_mic and compare 992 993 994 The crc32 checksum algorithm is assigned a checksum type number of 995 one (1). 996 9976.2. DES-based encryption and checksum types 998 999 These encryption systems encrypt information under the Data 1000 Encryption Standard [DES77] using the cipher block chaining mode 1001 [DESM80]. A checksum is computed as described below and placed in 1002 the cksum field. DES blocks are 8 bytes. As a result, the data to 1003 be encrypted (the concatenation of confounder, checksum, and message) 1004 must be padded to an 8 byte boundary before encryption. The values 1005 of the padding bytes are unspecified. 1006 1007 1008 1009 1010Raeburn [Page 18] 1011 1012INTERNET DRAFT February 2004 1013 1014 1015 Plaintext and DES ciphertext are encoded as blocks of 8 octets which 1016 are concatenated to make the 64-bit inputs for the DES algorithms. 1017 The first octet supplies the 8 most significant bits (with the 1018 octet's MSB used as the DES input block's MSB, etc.), the second 1019 octet the next 8 bits, ..., and the eighth octet supplies the 8 least 1020 significant bits. 1021 1022 Encryption under DES using cipher block chaining requires an 1023 additional input in the form of an initialization vector; this vector 1024 is specified for each encryption system, below. 1025 1026 The DES specifications [DESI81] identify four 'weak' and twelve 1027 'semi-weak' keys; those keys SHALL NOT be used for encrypting 1028 messages for use in Kerberos. The "variant keys" generated for the 1029 RSA-MD5-DES, RSA-MD4-DES and DES-MAC checksum types by an exclusive- 1030 or of a DES key with a constant are not checked for this property. 1031 1032 A DES key is 8 octets of data. This consists of 56 bits of actual 1033 key data, and 8 parity bits, one per octet. The key is encoded as a 1034 series of 8 octets written in MSB-first order. The bits within the 1035 key are also encoded in MSB order. For example, if the encryption 1036 key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) 1037 where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 1038 are the parity bits, the first octet of the key would be 1039 B1,B2,...,B7,P1 (with B1 as the most significant bit). See the 1040 [DESM80] introduction for reference. 1041 1042 Encryption data format 1043 1044 The format for the data to be encrypted includes a one-block 1045 confounder, a checksum, the encoded plaintext, and any necessary 1046 padding, as described in the following diagram. The msg-seq field 1047 contains the part of the protocol message which is to be encrypted. 1048 1049 +-----------+----------+---------+-----+ 1050 |confounder | checksum | msg-seq | pad | 1051 +-----------+----------+---------+-----+ 1052 1053 One generates a random confounder of one block, placing it in 1054 'confounder'; zeroes out the 'checksum' field (of length appropriate 1055 to exactly hold the checksum to be computed); calculates the 1056 appropriate checksum over the whole sequence, placing the result in 1057 'checksum'; adds the necessary padding; then encrypts using the 1058 specified encryption type and the appropriate key. 1059 1060 String or random-data to key transformation 1061 1062 To generate a DES key from two UTF-8 text strings (password and 1063 1064 1065 1066Raeburn [Page 19] 1067 1068INTERNET DRAFT February 2004 1069 1070 1071 salt), the two strings are concatenated, password first, and the 1072 result is then padded with zero-valued octets to a multiple of 8 1073 octets. 1074 1075 The top bit of each octet (always zero if the password is plain 1076 ASCII, as was assumed when the original specification was written) is 1077 discarded, and a bitstring is formed of the remaining seven bits of 1078 each octet. This bitstring is then fan-folded and eXclusive-ORed 1079 with itself to produce a 56-bit string. An eight-octet key is formed 1080 from this string, each octet using seven bits from the bitstring, 1081 leaving the least significant bit unassigned. The key is then 1082 "corrected" by correcting the parity on the key, and if the key 1083 matches a 'weak' or 'semi-weak' key as described in the DES 1084 specification, it is eXclusive-ORed with the constant 1085 0x00000000000000F0. This key is then used to generate a DES CBC 1086 checksum on the initial string with the salt appended. The result of 1087 the CBC checksum is then "corrected" as described above to form the 1088 result which is returned as the key. 1089 1090 For purposes of the string-to-key function, the DES CBC checksum is 1091 calculated by CBC encrypting a string using the key as IV and using 1092 the final 8 byte block as the checksum. 1093 1094 Pseudocode follows: 1095 1096 removeMSBits(8byteblock) { 1097 /* Treats a 64 bit block as 8 octets and remove the MSB in 1098 each octect (in big endian mode) and concatenates the 1099 result. E.g., input octet string: 1100 01110000 01100001 11110011 01110011 11110111 01101111 1101 11110010 01100100 1102 results in output bitstring: 1103 1110000 1100001 1110011 1110011 1110111 1101111 1104 1110010 1100100 */ 1105 } 1106 1107 reverse(56bitblock) { 1108 /* Treats a 56-bit block as a binary string and reverse it. 1109 E.g., input string: 1110 1000001 1010100 1001000 1000101 1001110 1000001 1111 0101110 1001101 1112 results in output string: 1113 1011001 0111010 1000001 0111001 1010001 0001001 1114 0010101 1000001 */ 1115 } 1116 1117 1118 1119 1120 1121 1122Raeburn [Page 20] 1123 1124INTERNET DRAFT February 2004 1125 1126 1127 add_parity_bits(56bitblock) { 1128 /* Copies a 56-bit block into a 64-bit block, left shift 1129 content in each octet and add DES parity bit. 1130 E.g., input string: 1131 1100000 0001111 0011100 0110100 1000101 1100100 1132 0110110 0010111 1133 results in output string: 1134 11000001 00011111 00111000 01101000 10001010 11001000 1135 01101101 00101111 */ 1136 } 1137 1138 key_correction(key) { 1139 fixparity(key); 1140 if (is_weak_key(key)) 1141 key = key XOR 0xF0; 1142 return(key); 1143 } 1144 1145 mit_des_string_to_key(string,salt) { 1146 odd = 1; 1147 s = string | salt; 1148 tempstring = 0; /* 56-bit string */ 1149 pad(s); /* with nulls to 8 byte boundary */ 1150 for (8byteblock in s) { 1151 56bitstring = removeMSBits(8byteblock); 1152 if (odd == 0) reverse(56bitstring); 1153 odd = ! odd; 1154 tempstring = tempstring XOR 56bitstring; 1155 } 1156 tempkey = key_correction(add_parity_bits(tempstring)); 1157 key = key_correction(DES-CBC-check(s,tempkey)); 1158 return(key); 1159 } 1160 1161 des_string_to_key(string,salt,params) { 1162 if (length(params) == 0) 1163 type = 0; 1164 else if (length(params) == 1) 1165 type = params[0]; 1166 else 1167 error("invalid params"); 1168 if (type == 0) 1169 mit_des_string_to_key(string,salt); 1170 else 1171 error("invalid params"); 1172 } 1173 1174 One common extension is to support the "AFS string-to-key" algorithm, 1175 1176 1177 1178Raeburn [Page 21] 1179 1180INTERNET DRAFT February 2004 1181 1182 1183 which is not defined here, if the type value above is one (1). 1184 1185 For generation of a key from a random bitstring, we start with a 1186 56-bit string, and as with the string-to-key operation above, insert 1187 parity bits, and if the result is a weak or semi-weak key, modify it 1188 by exclusive-OR with the constart 0x00000000000000F0: 1189 1190 des_random_to_key(bitstring) { 1191 return key_correction(add_parity_bits(bitstring)); 1192 } 1193 11946.2.1. DES with MD5 1195 1196 The des-cbc-md5 encryption mode encrypts information under DES in CBC 1197 mode with an all-zero initial vector, with an MD5 checksum (described 1198 in [MD5-92]) computed and placed in the checksum field. 1199 1200 The encryption system parameters for des-cbc-md5 are: 1201 1202 des-cbc-md5 1203 -------------------------------------------------------------------- 1204 protocol key format 8 bytes, parity in low bit of each 1205 1206 specific key structure copy of original key 1207 1208 required checksum rsa-md5-des 1209 mechanism 1210 1211 key-generation seed 8 bytes 1212 length 1213 1214 cipher state 8 bytes (CBC initial vector) 1215 1216 initial cipher state all-zero 1217 1218 encryption function des-cbc(confounder | checksum | msg | pad, 1219 ivec=oldstate) 1220 where 1221 checksum = md5(confounder | 0000... 1222 | msg | pad) 1223 1224 newstate = last block of des-cbc output 1225 1226 decryption function decrypt encrypted text and verify checksum 1227 1228 newstate = last block of ciphertext 1229 1230 1231 1232 1233 1234Raeburn [Page 22] 1235 1236INTERNET DRAFT February 2004 1237 1238 1239 des-cbc-md5 1240 -------------------------------------------------------------------- 1241 default string-to-key empty string 1242 params 1243 1244 pseudo-random function des-cbc(md5(input-string), ivec=0) 1245 1246 key generation functions: 1247 1248 string-to-key des_string_to_key 1249 1250 random-to-key des_random_to_key 1251 1252 key-derivation identity 1253 1254 The des-cbc-md5 encryption type is assigned the etype value three 1255 (3). 1256 12576.2.2. DES with MD4 1258 1259 The des-cbc-md4 encryption mode also encrypts information under DES 1260 in CBC mode, with an all-zero initial vector. An MD4 checksum 1261 (described in [MD4-92]) is computed and placed in the checksum field. 1262 1263 des-cbc-md4 1264 -------------------------------------------------------------------- 1265 protocol key format 8 bytes, parity in low bit of each 1266 1267 specific key structure copy of original key 1268 1269 required checksum rsa-md4-des 1270 mechanism 1271 1272 key-generation seed 8 bytes 1273 length 1274 1275 cipher state 8 bytes (CBC initial vector) 1276 1277 initial cipher state all-zero 1278 1279 encryption function des-cbc(confounder | checksum | msg | pad, 1280 ivec=oldstate) 1281 where 1282 checksum = md4(confounder | 0000... 1283 | msg | pad) 1284 1285 newstate = last block of des-cbc output 1286 1287 1288 1289 1290Raeburn [Page 23] 1291 1292INTERNET DRAFT February 2004 1293 1294 1295 des-cbc-md4 1296 -------------------------------------------------------------------- 1297 1298 decryption function decrypt encrypted text and verify checksum 1299 1300 newstate = last block of ciphertext 1301 1302 default string-to-key empty string 1303 params 1304 1305 pseudo-random function des-cbc(md5(input-string), ivec=0) 1306 1307 key generation functions: 1308 1309 string-to-key des_string_to_key 1310 1311 random-to-key copy input, then fix parity bits 1312 1313 key-derivation identity 1314 1315 Note that des-cbc-md4 uses md5, not md4, in the PRF definition. 1316 1317 The des-cbc-md4 encryption algorithm is assigned the etype value two 1318 (2). 1319 13206.2.3. DES with CRC 1321 1322 The des-cbc-crc encryption type uses DES in CBC mode with the key 1323 used as the initialization vector, with a 4-octet CRC-based checksum 1324 computed as described in section 6.1.3. Note that this is not a 1325 standard CRC-32 checksum, but a slightly modified one. 1326 1327 1328 des-cbc-crc 1329 -------------------------------------------------------------------- 1330 protocol key format 8 bytes, parity in low bit of each 1331 1332 specific key structure copy of original key 1333 1334 required checksum rsa-md5-des 1335 mechanism 1336 1337 key-generation seed 8 bytes 1338 length 1339 1340 cipher state 8 bytes (CBC initial vector) 1341 1342 1343 1344 1345 1346Raeburn [Page 24] 1347 1348INTERNET DRAFT February 2004 1349 1350 1351 des-cbc-crc 1352 -------------------------------------------------------------------- 1353 initial cipher state copy of original key 1354 1355 encryption function des-cbc(confounder | checksum | msg | pad, 1356 ivec=oldstate) 1357 where 1358 checksum = crc(confounder | 00000000 1359 | msg | pad) 1360 1361 newstate = last block of des-cbc output 1362 1363 decryption function decrypt encrypted text and verify checksum 1364 1365 newstate = last block of ciphertext 1366 1367 default string-to-key empty string 1368 params 1369 1370 pseudo-random function des-cbc(md5(input-string), ivec=0) 1371 1372 key generation functions: 1373 1374 string-to-key des_string_to_key 1375 1376 random-to-key copy input, then fix parity bits 1377 1378 key-derivation identity 1379 1380 The des-cbc-crc encryption algorithm is assigned the etype value one 1381 (1). 1382 13836.2.4. RSA MD5 Cryptographic Checksum Using DES 1384 1385 The RSA-MD5-DES checksum calculates a keyed collision-proof checksum 1386 by prepending an 8 octet confounder before the text, applying the RSA 1387 MD5 checksum algorithm, and encrypting the confounder and the 1388 checksum using DES in cipher-block-chaining (CBC) mode using a 1389 variant of the key, where the variant is computed by eXclusive-ORing 1390 the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0. The 1391 initialization vector should be zero. The resulting checksum is 24 1392 octets long. This checksum is tamper-proof and believed to be 1393 collision-proof. 1394 1395 1396 1397 1398 1399 1400 1401 1402Raeburn [Page 25] 1403 1404INTERNET DRAFT February 2004 1405 1406 1407 rsa-md5-des 1408 ---------------------------------------------------------------- 1409 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1410 1411 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, 1412 conf | rsa-md5(conf | msg)) 1413 1414 verify_mic decrypt and verify rsa-md5 checksum 1415 1416 1417 The rsa-md5-des checksum algorithm is assigned a checksum type number 1418 of eight (8). 1419 14206.2.5. RSA MD4 Cryptographic Checksum Using DES 1421 1422 The RSA-MD4-DES checksum calculates a keyed collision-proof checksum 1423 by prepending an 8 octet confounder before the text, applying the RSA 1424 MD4 checksum algorithm [MD4-92], and encrypting the confounder and 1425 the checksum using DES in cipher-block-chaining (CBC) mode using a 1426 variant of the key, where the variant is computed by eXclusive-ORing 1427 the key with the constant 0xF0F0F0F0F0F0F0F0. [7] The initialization 1428 vector should be zero. The resulting checksum is 24 octets long. 1429 This checksum is tamper-proof and believed to be collision-proof. 1430 1431 rsa-md4-des 1432 ---------------------------------------------------------------- 1433 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1434 1435 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, 1436 conf | rsa-md4(conf | msg), 1437 ivec=0) 1438 1439 verify_mic decrypt and verify rsa-md4 checksum 1440 1441 The rsa-md4-des checksum algorithm is assigned a checksum type number 1442 of three (3). 1443 14446.2.6. RSA MD4 Cryptographic Checksum Using DES alternative 1445 1446 The RSA-MD4-DES-K checksum calculates a keyed collision-proof 1447 checksum by applying the RSA MD4 checksum algorithm and encrypting 1448 the results using DES in cipher block chaining (CBC) mode using a DES 1449 key as both key and initialization vector. The resulting checksum is 1450 16 octets long. This checksum is tamper-proof and believed to be 1451 collision-proof. Note that this checksum type is the old method for 1452 encoding the RSA-MD4-DES checksum and it is no longer recommended. 1453 1454 1455 1456 1457 1458Raeburn [Page 26] 1459 1460INTERNET DRAFT February 2004 1461 1462 1463 rsa-md4-des-k 1464 ---------------------------------------------------------------- 1465 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1466 1467 get_mic des-cbc(key, md4(msg), ivec=key) 1468 1469 verify_mic decrypt, compute checksum and compare 1470 1471 1472 The rsa-md4-des-k checksum algorithm is assigned a checksum type 1473 number of six (6). 1474 14756.2.7. DES CBC checksum 1476 1477 The DES-MAC checksum is computed by prepending an 8 octet confounder 1478 to the plaintext, padding with zero-valued octets if necessary to 1479 bring the length to a multiple of 8 octets, performing a DES CBC-mode 1480 encryption on the result using the key and an initialization vector 1481 of zero, taking the last block of the ciphertext, prepending the same 1482 confounder and encrypting the pair using DES in cipher-block-chaining 1483 (CBC) mode using a variant of the key, where the variant is computed 1484 by eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0. The 1485 initialization vector should be zero. The resulting checksum is 128 1486 bits (16 octets) long, 64 bits of which are redundant. This checksum 1487 is tamper-proof and collision-proof. 1488 1489 1490 des-mac 1491 ---------------------------------------------------------------------- 1492 associated des-cbc-md5, des-cbc-md4, des-cbc-crc 1493 cryptosystem 1494 1495 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, 1496 conf | des-mac(key, conf | msg | pad, ivec=0), 1497 ivec=0) 1498 1499 verify_mic decrypt, compute DES MAC using confounder, compare 1500 1501 1502 The des-mac checksum algorithm is assigned a checksum type number of 1503 four (4). 1504 15056.2.8. DES CBC checksum alternative 1506 1507 The DES-MAC-K checksum is computed by performing a DES CBC-mode 1508 encryption of the plaintext, with zero-valued padding bytes if 1509 necessary to bring the length to a multiple of 8 octets, and using 1510 the last block of the ciphertext as the checksum value. It is keyed 1511 1512 1513 1514Raeburn [Page 27] 1515 1516INTERNET DRAFT February 2004 1517 1518 1519 with an encryption key which is also used as the initialization 1520 vector. The resulting checksum is 64 bits (8 octets) long. This 1521 checksum is tamper-proof and collision-proof. Note that this 1522 checksum type is the old method for encoding the DESMAC checksum and 1523 it is no longer recommended. 1524 1525 1526 des-mac-k 1527 ---------------------------------------------------------------- 1528 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1529 1530 get_mic des-mac(key, msg | pad, ivec=key) 1531 1532 verify_mic compute MAC and compare 1533 1534 1535 The des-mac-k checksum algorithm is assigned a checksum type number 1536 of five (5). 1537 15386.3. Triple-DES based encryption and checksum types 1539 1540 This encryption and checksum type pair is based on the Triple DES 1541 cryptosystem in Outer-CBC mode, and the HMAC-SHA1 message 1542 authentication algorithm. 1543 1544 A Triple DES key is the concatenation of three DES keys as described 1545 above for des-cbc-md5. A Triple DES key is generated from random 1546 data by creating three DES keys from separate sequences of random 1547 data. 1548 1549 Encrypted data using this type must be generated as described in 1550 section 5.3. If the length of the input data is not a multiple of 1551 the block size, zero-valued octets must be used to pad the plaintext 1552 to the next eight-octet boundary. The confounder must be eight 1553 random octets (one block). 1554 1555 The simplified profile for Triple DES, with key derivation as defined 1556 in section 5, is as follows: 1557 1558 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd 1559 ------------------------------------------------ 1560 protocol key format 24 bytes, parity in low 1561 bit of each 1562 1563 key-generation seed 21 bytes 1564 length 1565 1566 1567 1568 1569 1570Raeburn [Page 28] 1571 1572INTERNET DRAFT February 2004 1573 1574 1575 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd 1576 ------------------------------------------------ 1577 hash function SHA-1 1578 1579 HMAC output size 160 bits 1580 1581 message block size 8 bytes 1582 1583 default string-to-key empty string 1584 params 1585 1586 encryption and triple-DES encrypt and 1587 decryption functions decrypt, in outer-CBC 1588 mode (cipher block size 1589 8 octets) 1590 1591 key generation functions: 1592 1593 random-to-key DES3random-to-key (see 1594 below) 1595 1596 string-to-key DES3string-to-key (see 1597 below) 1598 1599 The des3-cbc-hmac-sha1-kd encryption type is assigned the value 1600 sixteen (16). The hmac-sha1-des3-kd checksum algorithm is assigned a 1601 checksum type number of twelve (12). 1602 16036.3.1. Triple DES Key Production (random-to-key, string-to-key) 1604 1605 The 168 bits of random key data are converted to a protocol key value 1606 as follows. First, the 168 bits are divided into three groups of 56 1607 bits, which are expanded individually into 64 bits as follows: 1608 1609 DES3random-to-key: 1610 1 2 3 4 5 6 7 p 1611 9 10 11 12 13 14 15 p 1612 17 18 19 20 21 22 23 p 1613 25 26 27 28 29 30 31 p 1614 33 34 35 36 37 38 39 p 1615 41 42 43 44 45 46 47 p 1616 49 50 51 52 53 54 55 p 1617 56 48 40 32 24 16 8 p 1618 1619 The "p" bits are parity bits computed over the data bits. The output 1620 of the three expansions, each corrected to avoid "weak" and "semi- 1621 weak" keys as in section 6.2, are concatenated to form the protocol 1622 key value. 1623 1624 1625 1626Raeburn [Page 29] 1627 1628INTERNET DRAFT February 2004 1629 1630 1631 The string-to-key function is used to transform UTF-8 passwords into 1632 DES3 keys. The DES3 string-to-key function relies on the "N-fold" 1633 algorithm and DK function, described in section 5. 1634 1635 The n-fold algorithm is applied to the password string concatenated 1636 with a salt value. For 3-key triple DES, the operation will involve 1637 a 168-fold of the input password string, to generate an intermediate 1638 key, from which the user's long-term key will be derived with the DK 1639 function. The DES3 string-to-key function is shown here in 1640 pseudocode: 1641 1642 DES3string-to-key(passwordString, salt, params) 1643 if (params != emptyString) 1644 error("invalid params"); 1645 s = passwordString + salt 1646 tmpKey = random-to-key(168-fold(s)) 1647 key = DK (tmpKey, KerberosConstant) 1648 1649 Weak key checking is performed in the random-to-key and DK 1650 operations. The KerberosConstant value is the byte string {0x6b 0x65 1651 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the ASCII 1652 encoding for the string "kerberos". 1653 16547. Use of Kerberos encryption outside this specification 1655 1656 Several Kerberos-based application protocols and preauthentication 1657 systems have been designed and deployed that perform encryption and 1658 message integrity checks in various ways. While in some cases there 1659 may be good reason for specifying these protocols in terms of 1660 specific encryption or checksum algorithms, we anticipate that in 1661 many cases this will not be true, and more generic approaches 1662 independent of particular algorithms will be desirable. Rather than 1663 having each protocol designer reinvent schemes for protecting data, 1664 using multiple keys, etc, we have attempted to present in this 1665 section a general framework that should be sufficient not only for 1666 the Kerberos protocol itself but also for many preauthentication 1667 systems and application protocols, while trying to avoid some of the 1668 assumptions that can work their way into such protocol designs. 1669 1670 Some problematic assumptions we've seen (and sometimes made) include: 1671 that a random bitstring is always valid as a key (not true for DES 1672 keys with parity); that the basic block encryption chaining mode 1673 provides no integrity checking, or can easily be separated from such 1674 checking (not true for many modes in development that do both 1675 simultaneously); that a checksum for a message always results in the 1676 same value (not true if a confounder is incorporated); that an 1677 initial vector is used (may not be true if a block cipher in CBC mode 1678 is not in use). 1679 1680 1681 1682Raeburn [Page 30] 1683 1684INTERNET DRAFT February 2004 1685 1686 1687 Such assumptions, while they may hold for any given set of encryption 1688 and checksum algorithms, may not be true of the next algorithms to be 1689 defined, leaving the application protocol unable to make use of those 1690 algorithms without updates to its specification. 1691 1692 The Kerberos protocol uses only the attributes and operations 1693 described in sections 3 and 4. Preauthentication systems and 1694 application protocols making use of Kerberos are encouraged to use 1695 them as well. The specific key and string-to-key parameters should 1696 generally be treated as opaque. While the string-to-key parameters 1697 are manipulated as an octet string, the representation for the 1698 specific key structure is implementation-defined; it may not even be 1699 a single object. 1700 1701 While we don't recommend it, some application protocols will 1702 undoubtedly continue to use the key data directly, even if only in 1703 some of the currently existing protocol specifications. An 1704 implementation intended to support general Kerberos applications may 1705 therefore need to make the key data available, as well as the 1706 attributes and operations described in sections 3 and 4. [8] 1707 17088. Assigned Numbers 1709 1710 The following encryption type numbers are already assigned or 1711 reserved for use in Kerberos and related protocols. 1712 1713 1714 encryption type etype section or comment 1715 ----------------------------------------------------------------- 1716 des-cbc-crc 1 6.2.3 1717 des-cbc-md4 2 6.2.2 1718 des-cbc-md5 3 6.2.1 1719 [reserved] 4 1720 des3-cbc-md5 5 1721 [reserved] 6 1722 des3-cbc-sha1 7 1723 dsaWithSHA1-CmsOID 9 (pkinit) 1724 md5WithRSAEncryption-CmsOID 10 (pkinit) 1725 sha1WithRSAEncryption-CmsOID 11 (pkinit) 1726 rc2CBC-EnvOID 12 (pkinit) 1727 rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5) 1728 rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0) 1729 des-ede3-cbc-Env-OID 15 (pkinit) 1730 des3-cbc-sha1-kd 16 6.3 1731 aes128-cts-hmac-sha1-96 17 [KRB5-AES] 1732 aes256-cts-hmac-sha1-96 18 [KRB5-AES] 1733 rc4-hmac 23 (Microsoft) 1734 1735 1736 1737 1738Raeburn [Page 31] 1739 1740INTERNET DRAFT February 2004 1741 1742 1743 rc4-hmac-exp 24 (Microsoft) 1744 subkey-keymaterial 65 (opaque; PacketCable) 1745 1746 1747 (The "des3-cbc-sha1" assignment is a deprecated version using no key 1748 derivation. It should not be confused with des3-cbc-sha1-kd.) 1749 1750 Several numbers have been reserved for use in encryption systems not 1751 defined here. Encryption type numbers have unfortunately been 1752 overloaded on occasion in Kerberos-related protocols, so some of the 1753 reserved numbers do not and will not correspond to encryption systems 1754 fitting the profile presented here. 1755 1756 The following checksum type numbers are assigned or reserved. As 1757 with encryption type numbers, some overloading of checksum numbers 1758 has occurred. 1759 1760 1761 Checksum type sumtype checksum section or 1762 value size reference 1763 ---------------------------------------------------------------------- 1764 CRC32 1 4 6.1.3 1765 rsa-md4 2 16 6.1.2 1766 rsa-md4-des 3 24 6.2.5 1767 des-mac 4 16 6.2.7 1768 des-mac-k 5 8 6.2.8 1769 rsa-md4-des-k 6 16 6.2.6 1770 rsa-md5 7 16 6.1.1 1771 rsa-md5-des 8 24 6.2.4 1772 rsa-md5-des3 9 24 ?? 1773 sha1 (unkeyed) 10 20 ?? 1774 hmac-sha1-des3-kd 12 20 6.3 1775 hmac-sha1-des3 13 20 ?? 1776 sha1 (unkeyed) 14 20 ?? 1777 hmac-sha1-96-aes128 15 20 [KRB5-AES] 1778 hmac-sha1-96-aes256 16 20 [KRB5-AES] 1779 [reserved] 0x8003 ? [GSS-KRB5] 1780 1781 1782 Encryption and checksum type numbers are signed 32-bit values. Zero 1783 is invalid, and negative numbers are reserved for local use. All 1784 standardized values must be positive. 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794Raeburn [Page 32] 1795 1796INTERNET DRAFT February 2004 1797 1798 17999. Implementation Notes 1800 1801 The "interface" described here is the minimal information that must 1802 be defined to make a cryptosystem useful within Kerberos in an 1803 interoperable fashion. Despite the functional notation used in some 1804 places, it is not an attempt to define an API for cryptographic 1805 functionality within Kerberos. Actual implementations providing 1806 clean APIs will probably find it useful to make additional 1807 information available, which should be possible to derive from a 1808 specification written to the framework given here. For example, an 1809 application designer may wish to determine the largest number of 1810 bytes that can be encrypted without overflowing a certain size output 1811 buffer, or conversely, the maximum number of bytes that might be 1812 obtained by decrypting a ciphertext message of a given size. (In 1813 fact, an implementation of the GSS-API Kerberos mechanism [GSS-KRB5] 1814 will require some of these.) 1815 1816 The presence of a mechanism in this document should not be taken as 1817 an indication that it must be implemented for compliance with any 1818 specification; required mechanisms will be specified elsewhere. 1819 Indeed, some of the mechanisms described here for backwards 1820 compatibility are now considered rather weak for protecting critical 1821 data. 1822 182310. Security Considerations 1824 1825 Recent years have brought advancements in the ability to perform 1826 large-scale attacks against DES, to such a degree that it is not 1827 considered a strong encryption mechanism any longer; triple-DES is 1828 generally preferred in its place, despite the poorer performance. 1829 See [ESP-DES] for a summary of some of the potential attacks, and 1830 [EFF-DES] for a detailed discussion of the implementation of 1831 particular attack. However, most Kerberos implementations still have 1832 DES as their primary interoperable encryption type. 1833 1834 DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of 1835 single-DES here avoids them. However, DES also has 48 'possibly- 1836 weak' keys [Schneier96] (note that the tables in many editions of the 1837 reference contains errors) which are not avoided. 1838 1839 DES weak keys are keys with the property that E1(E1(P)) = P (where E1 1840 denotes encryption of a single block with key 1). DES semi-weak keys 1841 or "dual" keys are pairs of keys with the property that E1(P) = 1842 D2(P), and thus E2(E1(P)) = P. Because of the use of CBC mode and 1843 leading random confounder, however, these properties are unlikely to 1844 present a security problem. 1845 1846 Many of the choices concerning when weak-key corrections are 1847 1848 1849 1850Raeburn [Page 33] 1851 1852INTERNET DRAFT February 2004 1853 1854 1855 performed relate more to compatibility with existing implementations 1856 than to any risk analysis. 1857 1858 While checks are also done for the component DES keys in a triple-DES 1859 key, the nature of the weak keys is such that it is extremely 1860 unlikely that they will weaken the triple-DES encryption -- only 1861 slightly more likely than having the middle of the three sub-keys 1862 match one of the other two, which effectively converts the encryption 1863 to single-DES, which is a case we make no effort to avoid. 1864 1865 The true CRC-32 checksum is not collision-proof; an attacker could 1866 use a probabilistic chosen-plaintext attack to generate a valid 1867 message even if a confounder is used [SG92]. The use of collision- 1868 proof checksums is of course recommended for environments where such 1869 attacks represent a significant threat. The "simplifications" (read: 1870 bugs) introduced when CRC-32 was implemented for Kerberos cause 1871 leading zeros to effectively be ignored, so messages differing only 1872 in leading zero bits will have the same checksum. 1873 1874 [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm. 1875 Unlike [IPSEC-HMAC], the triple-DES specification here does not use 1876 the suggested truncation of the HMAC output. As pointed out in 1877 [IPSEC-HMAC], SHA-1 was not developed to be used as a keyed hash 1878 function, which is a criterion of HMAC. [HMAC-TEST] contains test 1879 vectors for HMAC-SHA-1. 1880 1881 The mit_des_string_to_key function was originally constructed with 1882 the assumption that all input would be ASCII; it ignores the top bit 1883 of each input byte. Folding with XOR is also not an especially good 1884 mixing mechanism in terms of preserving randomness. 1885 1886 The n-fold function used in the string-to-key operation for des3-cbc- 1887 hmac-sha1-kd was designed to cause each bit of input to contribute 1888 equally to the output; it was not designed to maximize or equally 1889 distribute randomness in the input, and there are conceivable cases 1890 of partially structured input where randomness may be lost. This 1891 should only be an issue for highly structured passwords, however. 1892 1893 [RFC1851] discusses the relative strength of triple-DES encryption. 1894 The relative slow speed of triple-DES encryption may also be an issue 1895 for some applications. 1896 1897 In [Bellovin91], there is a suggestion that analyses of encryption 1898 schemes should include a model of an attacker capable of submitting 1899 known plaintexts to be encrypted with an unknown key, as well as 1900 being able to perform many types of operations on known protocol 1901 messages. Recent experiences with the chosen-plaintext attacks on 1902 Kerberos version 4 bear out the value of this suggestion. 1903 1904 1905 1906Raeburn [Page 34] 1907 1908INTERNET DRAFT February 2004 1909 1910 1911 The use of unkeyed encrypted checksums, such as those used in the 1912 single-DES cryptosystems specified in [Kerb1510], allows for cut-and- 1913 paste attacks, especially if a confounder is not used. In addition, 1914 unkeyed encrypted checksums are vulnerable to chosen-plaintext 1915 attacks: an attacker with access to an encryption oracle can easily 1916 encrypt the required unkeyed checksum along with the chosen 1917 plaintext. [Bellovin99] These weaknesses, combined with a common 1918 implementation design choice described below, allow for a cross- 1919 protocol attack from version 4 to version 5. 1920 1921 The use of a random confounder is an important means of preventing an 1922 attacker from making effective use of protocol exchanges as an 1923 encryption oracle. In Kerberos version 4, the encryption of constant 1924 plaintext to constant ciphertext makes an effective encryption oracle 1925 for an attacker. The use of random confounders in [Kerb1510] 1926 frustrates this sort of chosen-plaintext attack. 1927 1928 Using the same key for multiple purposes can enable or increase the 1929 scope of chosen-plaintext attacks. Some software which implements 1930 both versions 4 and 5 of the Kerberos protocol uses the same keys for 1931 both versions of the protocol. This enables the encryption oracle of 1932 version 4 to be used to attack version 5. Vulnerabilities such as 1933 this cross-protocol attack reinforce the wisdom of not using a key 1934 for multiple purposes. 1935 1936 This document, like the Kerberos protocol, completely ignores the 1937 notion of limiting the amount of data a key may be used with to a 1938 quantity based on the robustness of the algorithm or size of the key. 1939 It is assumed that any defined algorithms and key sizes will be 1940 strong enough to support very large amounts of data, or they will be 1941 deprecated once significant attacks are known. 1942 1943 This document also places no bounds on the amount of data that can be 1944 handled in various operations. In order to avoid denial of service 1945 attacks, implementations will probably want to restrict message sizes 1946 at some higher level. 1947 194811. IANA Considerations 1949 1950 Two registries for numeric values should be created: Kerberos 1951 Encryption Type Numbers and Kerberos Checksum Type Numbers. These 1952 are signed values ranging from -2147483648 to 2147483647. Positive 1953 values should be assigned only for algorithms specified in accordance 1954 with this specification for use with Kerberos or related protocols. 1955 Negative values are for private use; local and experimental 1956 algorithms should use these values. Zero is reserved and may not be 1957 assigned. 1958 1959 1960 1961 1962Raeburn [Page 35] 1963 1964INTERNET DRAFT February 2004 1965 1966 1967 Positive encryption and checksum type numbers may be assigned 1968 following either of two policies described in [BCP26]. 1969 1970 Standards-track specifications may be assigned values under the 1971 Standards Action policy. 1972 1973 Specifications in non-standards track RFCs may be assigned values 1974 after Expert Review. A non-IETF specification may be assigned values 1975 by publishing an Informational or standards-track RFC referencing the 1976 external specification; that specification must be public and 1977 published in some permanent record much like the IETF RFCs. It is 1978 highly desirable, though not required, that the full specification be 1979 published as an IETF RFC. 1980 1981 Smaller encryption type values should be used for IETF standards- 1982 track mechanisms, and much higher values (16777216 and above) for 1983 other mechanisms. (Rationale: In the Kerberos ASN.1 encoding, 1984 smaller numbers encode to smaller octet sequences, so this favors 1985 standards-track mechanisms with slightly smaller messages.) Aside 1986 from that guideline, IANA may choose numbers as it sees fit. 1987 1988 Internet-Draft specifications should not include values for 1989 encryption and checksum type numbers. Instead, they should indicate 1990 that values would be assigned by IANA when the document is approved 1991 as an RFC. For development and interoperability testing, values in 1992 the private-use range (negative values) may be used, but should not 1993 be included in the draft specification. 1994 1995 Each registered value should have an associated unique name to refer 1996 to it by. The lists given in section 8 should be used as an initial 1997 registry; they include reservations for specifications in progress in 1998 parallel with this document, and for certain other values believed to 1999 be in use already. 2000 200112. Acknowledgments 2002 2003 This document is an extension of the encryption specification 2004 included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much 2005 of the text of the background, concepts, and DES specifications are 2006 drawn directly from that document. 2007 2008 The abstract framework presented in this document was put together by 2009 Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn, 2010 and Tom Yu, and the details were refined several times based on 2011 comments from John Brezak and others. 2012 2013 Marc Horowitz wrote the original specification of triple-DES and key 2014 derivation in a pair of Internet Drafts (under the names draft- 2015 2016 2017 2018Raeburn [Page 36] 2019 2020INTERNET DRAFT February 2004 2021 2022 2023 horowitz-key-derivation and draft-horowitz-kerb-key-derivation) which 2024 were later folded into a draft revision of [Kerb1510], from which 2025 this document was later split off. 2026 2027 Tom Yu provided the text describing the modifications to the standard 2028 CRC algorithm as Kerberos implementations actually use it, and some 2029 of the Security Considerations section. 2030 2031 Miroslav Jurisic provided information for one of the UTF-8 test cases 2032 for the string-to-key functions. 2033 2034 Marcus Watts noticed some errors in earlier drafts, and pointed out 2035 that the simplified profile could easily be modified to support 2036 cipher text stealing modes. 2037 2038 Simon Josefsson contributed some clarifications to the DES "CBC 2039 checksum", string-to-key and weak key descriptions, and some test 2040 vectors. 2041 2042 Simon Josefsson, Louis LeVay and others also caught some errors in 2043 earlier drafts. 2044 2045A. Test vectors 2046 2047 This section provides test vectors for various functions defined or 2048 described in this document. For convenience, most inputs are ASCII 2049 strings, though some UTF-8 samples are be provided for string-to-key 2050 functions. Keys and other binary data are specified as hexadecimal 2051 strings. 2052 2053A.1. n-fold 2054 2055 The n-fold function is defined in section 5.1. As noted there, the 2056 sample vector in the original paper defining the algorithm appears to 2057 be incorrect. Here are some test cases provided by Marc Horowitz and 2058 Simon Josefsson: 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074Raeburn [Page 37] 2075 2076INTERNET DRAFT February 2004 2077 2078 2079 64-fold("012345") = 2080 64-fold(303132333435) = be072631276b1955 2081 2082 56-fold("password") = 2083 56-fold(70617373776f7264) = 78a07b6caf85fa 2084 2085 64-fold("Rough Consensus, and Running Code") = 2086 64-fold(526f75676820436f6e73656e7375732c20616e642052756e 2087 6e696e6720436f6465) = bb6ed30870b7f0e0 2088 2089 168-fold("password") = 2090 168-fold(70617373776f7264) = 2091 59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e 2092 2093 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY" 2094 192-fold(4d41535341434856534554545320494e5354495456544520 2095 4f4620544543484e4f4c4f4759) = 2096 db3b0d8f0b061e603282b308a50841229ad798fab9540c1b 2097 2098 168-fold("Q") = 2099 168-fold(51) = 2100 518a54a2 15a8452a 518a54a2 15a8452a 2101 518a54a2 15 2102 2103 168-fold("ba") = 2104 168-fold(6261) = 2105 fb25d531 ae897449 9f52fd92 ea9857c4 2106 ba24cf29 7e 2107 2108 Here are some additional values corresponding to folded values of the 2109 string "kerberos"; the 64-bit form is used in the des3 string-to-key 2110 (section 6.3.1). 2111 2112 64-fold("kerberos") = 2113 6b657262 65726f73 2114 128-fold("kerberos") = 2115 6b657262 65726f73 7b9b5b2b 93132b93 2116 168-fold("kerberos") = 2117 8372c236 344e5f15 50cd0747 e15d62ca 2118 7a5a3bce a4 2119 256-fold("kerberos") = 2120 6b657262 65726f73 7b9b5b2b 93132b93 2121 5c9bdcda d95c9899 c4cae4de e6d6cae4 2122 2123 Note that the initial octets exactly match the input string when the 2124 output length is a multiple of the input length. 2125 2126 2127 2128 2129 2130Raeburn [Page 38] 2131 2132INTERNET DRAFT February 2004 2133 2134 2135A.2. mit_des_string_to_key 2136 2137 The function mit_des_string_to_key is defined in section 6.2. We 2138 present here several test values, with some of the intermediate 2139 results. The fourth test demonstrates the use of UTF-8 with three 2140 characters. The last two tests are specifically constructed so as to 2141 trigger the weak-key fixups for the intermediate key produced by fan- 2142 folding; we have no test cases that cause such fixups for the final 2143 key. 2144 2145 UTF-8 encodings used in test vector: 2146 eszett U+00DF C3 9F s-caron U+0161 C5 A1 2147 c-acute U+0107 C4 87 g-clef U+1011E F0 9D 84 9E 2148 2149 Test vector: 2150 2151 salt: "ATHENA.MIT.EDUraeburn" 2152 415448454e412e4d49542e4544557261656275726e 2153 password: "password" 70617373776f7264 2154 fan-fold result: c01e38688ac86c2e 2155 intermediate key: c11f38688ac86d2f 2156 DES key: cbc22fae235298e3 2157 2158 2159 salt: "WHITEHOUSE.GOVdanny" 2160 5748495445484f5553452e474f5664616e6e79 2161 password: "potatoe" 706f7461746f65 2162 fan-fold result: a028944ee63c0416 2163 intermediate key: a129944fe63d0416 2164 DES key: df3d32a74fd92a01 2165 2166 2167 salt: "EXAMPLE.COMpianist" 4558414D504C452E434F4D7069616E697374 2168 password: g-clef (U+1011E) f09d849e 2169 fan-fold result: 3c4a262c18fab090 2170 intermediate key: 3d4a262c19fbb091 2171 DES key: 4ffb26bab0cd9413 2172 2173 2174 salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" + c-acute(U+0107) 2175 415448454e412e4d49542e4544554a757269c5a169c487 2176 password: eszett(U+00DF) 2177 c39f 2178 fan-fold result:b8f6c40e305afc9e 2179 intermediate key: b9f7c40e315bfd9e 2180 DES key: 62c81a5232b5e69d 2181 2182 2183 2184 2185 2186Raeburn [Page 39] 2187 2188INTERNET DRAFT February 2004 2189 2190 2191 salt: "AAAAAAAA" 4141414141414141 2192 password: "11119999" 3131313139393939 2193 fan-fold result: e0e0e0e0f0f0f0f0 2194 intermediate key: e0e0e0e0f1f1f101 2195 DES key: 984054d0f1a73e31 2196 2197 2198 salt: "FFFFAAAA" 4646464641414141 2199 password: "NNNN6666" 4e4e4e4e36363636 2200 fan-fold result: 1e1e1e1e0e0e0e0e 2201 intermediate key: 1f1f1f1f0e0e0efe 2202 DES key: c4bf6b25adf7a4f8 2203 2204 2205 This trace provided by Simon Josefsson shows the intermediate 2206 processing stages of one of the test inputs: 2207 2208 string_to_key (des-cbc-md5, string, salt) 2209 ;; string: 2210 ;; `password' (length 8 bytes) 2211 ;; 70 61 73 73 77 6f 72 64 2212 ;; salt: 2213 ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes) 2214 ;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61 2215 ;; 65 62 75 72 6e 2216 des_string_to_key (string, salt) 2217 ;; String: 2218 ;; `password' (length 8 bytes) 2219 ;; 70 61 73 73 77 6f 72 64 2220 ;; Salt: 2221 ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes) 2222 ;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61 2223 ;; 65 62 75 72 6e 2224 odd = 1; 2225 s = string | salt; 2226 tempstring = 0; /* 56-bit string */ 2227 pad(s); /* with nulls to 8 byte boundary */ 2228 ;; s = pad(string|salt): 2229 ;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00' 2230 ;; (length 32 bytes) 2231 ;; 70 61 73 73 77 6f 72 64 41 54 48 45 4e 41 2e 4d 2232 ;; 49 54 2e 45 44 55 72 61 65 62 75 72 6e 00 00 00 2233 for (8byteblock in s) { 2234 ;; loop iteration 0 2235 ;; 8byteblock: 2236 ;; `password' (length 8 bytes) 2237 ;; 70 61 73 73 77 6f 72 64 2238 ;; 01110000 01100001 01110011 01110011 01110111 01101111 2239 2240 2241 2242Raeburn [Page 40] 2243 2244INTERNET DRAFT February 2004 2245 2246 2247 ;; 01110010 01100100 2248 56bitstring = removeMSBits(8byteblock); 2249 ;; 56bitstring: 2250 ;; 1110000 1100001 1110011 1110011 1110111 1101111 2251 ;; 1110010 1100100 2252 if (odd == 0) reverse(56bitstring); ;; odd=1 2253 odd = ! odd 2254 tempstring = tempstring XOR 56bitstring; 2255 ;; tempstring 2256 ;; 1110000 1100001 1110011 1110011 1110111 1101111 2257 ;; 1110010 1100100 2258 2259 for (8byteblock in s) { 2260 ;; loop iteration 1 2261 ;; 8byteblock: 2262 ;; `ATHENA.M' (length 8 bytes) 2263 ;; 41 54 48 45 4e 41 2e 4d 2264 ;; 01000001 01010100 01001000 01000101 01001110 01000001 2265 ;; 00101110 01001101 2266 56bitstring = removeMSBits(8byteblock); 2267 ;; 56bitstring: 2268 ;; 1000001 1010100 1001000 1000101 1001110 1000001 2269 ;; 0101110 1001101 2270 if (odd == 0) reverse(56bitstring); ;; odd=0 2271 reverse(56bitstring) 2272 ;; 56bitstring after reverse 2273 ;; 1011001 0111010 1000001 0111001 1010001 0001001 2274 ;; 0010101 1000001 2275 odd = ! odd 2276 tempstring = tempstring XOR 56bitstring; 2277 ;; tempstring 2278 ;; 0101001 1011011 0110010 1001010 0100110 1100110 2279 ;; 1100111 0100101 2280 2281 for (8byteblock in s) { 2282 ;; loop iteration 2 2283 ;; 8byteblock: 2284 ;; `IT.EDUra' (length 8 bytes) 2285 ;; 49 54 2e 45 44 55 72 61 2286 ;; 01001001 01010100 00101110 01000101 01000100 01010101 2287 ;; 01110010 01100001 2288 56bitstring = removeMSBits(8byteblock); 2289 ;; 56bitstring: 2290 ;; 1001001 1010100 0101110 1000101 1000100 1010101 2291 ;; 1110010 1100001 2292 if (odd == 0) reverse(56bitstring); ;; odd=1 2293 2294 2295 2296 2297 2298Raeburn [Page 41] 2299 2300INTERNET DRAFT February 2004 2301 2302 2303 odd = ! odd 2304 tempstring = tempstring XOR 56bitstring; 2305 ;; tempstring 2306 ;; 1100000 0001111 0011100 0001111 1100010 0110011 2307 ;; 0010101 1000100 2308 2309 for (8byteblock in s) { 2310 ;; loop iteration 3 2311 ;; 8byteblock: 2312 ;; `eburn\x00\x00\x00' (length 8 bytes) 2313 ;; 65 62 75 72 6e 00 00 00 2314 ;; 01100101 01100010 01110101 01110010 01101110 00000000 2315 ;; 00000000 00000000 2316 56bitstring = removeMSBits(8byteblock); 2317 ;; 56bitstring: 2318 ;; 1100101 1100010 1110101 1110010 1101110 0000000 2319 ;; 0000000 0000000 2320 if (odd == 0) reverse(56bitstring); ;; odd=0 2321 reverse(56bitstring) 2322 ;; 56bitstring after reverse 2323 ;; 0000000 0000000 0000000 0111011 0100111 1010111 2324 ;; 0100011 1010011 2325 odd = ! odd 2326 tempstring = tempstring XOR 56bitstring; 2327 ;; tempstring 2328 ;; 1100000 0001111 0011100 0110100 1000101 1100100 2329 ;; 0110110 0010111 2330 2331 for (8byteblock in s) { 2332 } 2333 ;; for loop terminated 2334 2335 tempkey = key_correction(add_parity_bits(tempstring)); 2336 ;; tempkey 2337 ;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes) 2338 ;; c1 1f 38 68 8a c8 6d 2f 2339 ;; 11000001 00011111 00111000 01101000 10001010 11001000 2340 ;; 01101101 00101111 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354Raeburn [Page 42] 2355 2356INTERNET DRAFT February 2004 2357 2358 2359 key = key_correction(DES-CBC-check(s,tempkey)); 2360 ;; key 2361 ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes) 2362 ;; cb c2 2f ae 23 52 98 e3 2363 ;; 11001011 11000010 00101111 10101110 00100011 01010010 2364 ;; 10011000 11100011 2365 2366 ;; string_to_key key: 2367 ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes) 2368 ;; cb c2 2f ae 23 52 98 e3 2369 2370 2371A.3. DES3 DR and DK 2372 2373 These tests show the derived-random and derived-key values for the 2374 des3-hmac-sha1-kd encryption scheme, using the DR and DK functions 2375 defined in section 6.3.1. The input keys were randomly generated; 2376 the usage values are from this specification. 2377 2378 2379 key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92 2380 usage: 0000000155 2381 DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705 2382 DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd 2383 2384 key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2 2385 usage: 00000001aa 2386 DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2 2387 DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207 2388 2389 key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc 2390 usage: 0000000155 2391 DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb 2392 DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf 2393 2394 key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5 2395 usage: 00000001aa 2396 DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70 2397 DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e 2398 2399 key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb 2400 usage: 6b65726265726f73 ("kerberos") 2401 DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da 2402 DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43 2403 2404 key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da 2405 usage: 0000000155 2406 2407 2408 2409 2410Raeburn [Page 43] 2411 2412INTERNET DRAFT February 2004 2413 2414 2415 DR: 348056ec98fcc517171d2b4d7a9493af482d999175 2416 DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7 2417 2418 key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c 2419 usage: 00000001aa 2420 DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5 2421 DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1 2422 2423 key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443 2424 usage: 0000000155 2425 DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a 2426 DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49 2427 2428 key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016 2429 usage: 00000001aa 2430 DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec 2431 DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d 2432 2433 2434A.4. DES3string_to_key 2435 2436 These are the keys generated for some of the above input strings for 2437 triple-DES with key derivation as defined in section 6.3.1. 2438 2439 salt: "ATHENA.MIT.EDUraeburn" 2440 passwd: "password" 2441 key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e 2442 2443 salt: "WHITEHOUSE.GOVdanny" 2444 passwd: "potatoe" 2445 key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a 2446 2447 salt: "EXAMPLE.COMbuckaroo" 2448 passwd: "penny" 2449 key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a 2450 2451 salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" 2452 + c-acute(U+0107) 2453 passwd: eszett(U+00DF) 2454 key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0 2455 2456 salt: "EXAMPLE.COMpianist" 2457 passwd: g-clef(U+1011E) 2458 key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19 2459 2460 2461 2462 2463 2464 2465 2466Raeburn [Page 44] 2467 2468INTERNET DRAFT February 2004 2469 2470 2471A.5. Modified CRC-32 2472 2473 Below are modified-CRC32 values for various ASCII and octet strings. 2474 Only the printable ASCII characters are checksummed, no C-style 2475 trailing zero-valued octet. The 32-bit modified CRC and the sequence 2476 of output bytes as used in Kerberos are shown. (The octet values are 2477 separated here to emphasize that they are octet values and not 32-bit 2478 numbers, which will be the most convenient form for manipulation in 2479 some implementations. The bit and byte order used internally for 2480 such a number is irrelevant; the octet sequence generated is what is 2481 important.) 2482 2483 2484 mod-crc-32("foo") = 33 bc 32 73 2485 mod-crc-32("test0123456789") = d6 88 3e b8 2486 mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3 2487 mod-crc-32(8000) = 4b 98 83 3b 2488 mod-crc-32(0008) = 32 88 db 0e 2489 mod-crc-32(0080) = 20 83 b8 ed 2490 mod-crc-32(80) = 20 83 b8 ed 2491 mod-crc-32(80000000) = 3b b6 59 ed 2492 mod-crc-32(00000001) = 96 30 07 77 2493 2494 2495B. Significant Changes from RFC 1510 2496 2497 The encryption and checksum mechanism profiles are new. The old 2498 specification defined a few operations for various mechanisms, but 2499 didn't outline what should be required of new mechanisms in terms of 2500 abstract properties, nor how to ensure that a mechanism specification 2501 is complete enough for interoperability between implementations. The 2502 new profiles do differ from the old specification in a few ways: 2503 2504 Some message definitions in [Kerb1510] could be read as permitting 2505 the initial vector to be specified by the application; the text 2506 was too vague. It is specifically not permitted in this 2507 specification. Some encryption algorithms may not use 2508 initialization vectors, so relying on chosen, secret 2509 initialization vectors for security is unwise. Also, the 2510 prepended confounder in the existing algorithms is roughly 2511 equivalent to a per-message initialization vector that is revealed 2512 in encrypted form. However, carrying state across from one 2513 encryption to another is explicitly permitted through the opaque 2514 "cipher state" object. 2515 2516 The use of key derivation is new. 2517 2518 Several new methods are introduced, including generation of a key 2519 2520 2521 2522Raeburn [Page 45] 2523 2524INTERNET DRAFT February 2004 2525 2526 2527 in wire-protocol format from random input data. 2528 2529 The means for influencing the string-to-key algorithm are laid out 2530 more clearly. 2531 2532 Triple-DES support is new. 2533 2534 The pseudo-random function is new. 2535 2536 The des-cbc-crc, DES string-to-key and CRC descriptions have been 2537 updated to align them with existing implementations. 2538 2539 [Kerb1510] had no indication what character set or encoding might be 2540 used for pass phrases and salts. 2541 2542 In [Kerb1510], key types, encryption algorithms and checksum 2543 algorithms were only loosely associated, and the association was not 2544 well described. In this specification, key types and encryption 2545 algorithms have a one-to-one correspondence, and associations between 2546 encryption and checksum algorithms are described so that checksums 2547 can be computed given negotiated keys, without requiring further 2548 negotiation for checksum types. 2549 2550Notes 2551 2552 [1] While Message Authentication Code (MAC) or Message Integrity 2553 Check (MIC) would be more appropriate terms for many of the 2554 uses in this document, we continue to use the term "checksum" 2555 for historical reasons. 2556 2557 [2] Extending CBC mode across messages would be one obvious 2558 example of this chaining. Another might be the use of 2559 counter mode, with a counter randomly initialized and 2560 attached to the ciphertext; a second message could continue 2561 incrementing the counter when chaining the cipher state, thus 2562 avoiding having to transmit another counter value. However, 2563 this chaining is only useful for uninterrupted, ordered 2564 sequences of messages. 2565 2566 [3] In the case of Kerberos, the encrypted objects will generally 2567 be ASN.1 DER encodings, which contain indications of their 2568 length in the first few octets. 2569 2570 [4] As of the time of this writing, some new modes of operation 2571 have been proposed, some of which may permit encryption and 2572 integrity protection simultaneously. After some of these 2573 proposals have been subjected to adequate analysis, we may 2574 wish to formulate a new simplified profile based on one of 2575 2576 2577 2578Raeburn [Page 46] 2579 2580INTERNET DRAFT February 2004 2581 2582 2583 them. 2584 2585 [5] It should be noted that the sample vector in Appendix B.2 of 2586 the original paper appears to be incorrect. Two independent 2587 implementations from the specification (one in C by Marc 2588 Horowitz, and another in Scheme by Bill Sommerfeld) agree on 2589 a value different from that in [Blumenthal96]. 2590 2591 [6] For example, in MIT's implementation of [Kerb1510], the rsa- 2592 md5 unkeyed checksum of application data may be included in 2593 an authenticator encrypted in a service's key; since rsa-md5 2594 is believed to be collision-proof, even if the application 2595 data is exposed to an attacker, it cannot be modified without 2596 causing the checksum verification to fail. 2597 2598 [7] A variant of the key is used to limit the use of a key to a 2599 particular function, separating the functions of generating a 2600 checksum from other encryption performed using the session 2601 key. The constant 0xF0F0F0F0F0F0F0F0 was chosen because it 2602 maintains key parity. The properties of DES precluded the 2603 use of the complement. The same constant is used for similar 2604 purpose in the Message Integrity Check in the Privacy 2605 Enhanced Mail standard. 2606 2607 [8] Perhaps one of the more common reasons for directly 2608 performing encryption is direct control over the negotiation 2609 and to select a "sufficiently strong" encryption algorithm 2610 (whatever that means in the context of a given application). 2611 While Kerberos directly provides no facility for negotiating 2612 encryption types between the application client and server, 2613 there are other means for accomplishing similar goals. For 2614 example, requesting only "strong" session key types from the 2615 KDC, and assuming that the type actually returned by the KDC 2616 will be understood and supported by the application server. 2617 2618Intellectual Property Statement 2619 2620 The IETF takes no position regarding the validity or scope of any 2621 intellectual property or other rights that might be claimed to 2622 pertain to the implementation or use of the technology described in 2623 this document or the extent to which any license under such rights 2624 might or might not be available; neither does it represent that it 2625 has made any effort to identify any such rights. Information on the 2626 IETF's procedures with respect to rights in standards-track and 2627 standards-related documentation can be found in BCP-11. Copies of 2628 claims of rights made available for publication and any assurances of 2629 licenses to be made available, or the result of an attempt made to 2630 obtain a general license or permission for the use of such 2631 2632 2633 2634Raeburn [Page 47] 2635 2636INTERNET DRAFT February 2004 2637 2638 2639 proprietary rights by implementors or users of this specification can 2640 be obtained from the IETF Secretariat. 2641 2642 The IETF invites any interested party to bring to its attention any 2643 copyrights, patents or patent applications, or other proprietary 2644 rights which may cover technology that may be required to practice 2645 this standard. Please address the information to the IETF Executive 2646 Director. 2647 2648Normative References 2649 2650 [Bellare98] 2651 Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway, 2652 "Relations Among Notions of Security for Public-Key Encryption 2653 Schemes". Extended abstract published in Advances in Cryptology- 2654 Crypto 98 Proceedings, Lecture Notes in Computer Science Vol. 2655 1462, H. Krawcyzk ed., Springer-Verlag, 1998. 2656 [Blumenthal96] 2657 Blumenthal, U., and S. Bellovin, "A Better Key Schedule for DES- 2658 Like Ciphers", Proceedings of PRAGOCRYPT '96, 1996. 2659 [CRC] 2660 International Organization for Standardization, "ISO Information 2661 Processing Systems - Data Communication - High-Level Data Link 2662 Control Procedure - Frame Structure," IS 3309, 3rd Edition, 2663 October 1984. 2664 [DES77] 2665 National Bureau of Standards, U.S. Department of Commerce, "Data 2666 Encryption Standard," Federal Information Processing Standards 2667 Publication 46, Washington, DC, 1977. 2668 [DESI81] 2669 National Bureau of Standards, U.S. Department of Commerce, 2670 "Guidelines for implementing and using NBS Data Encryption 2671 Standard," Federal Information Processing Standards Publication 2672 74, Washington, DC, 1981. 2673 [DESM80] 2674 National Bureau of Standards, U.S. Department of Commerce, "DES 2675 Modes of Operation," Federal Information Processing Standards 2676 Publication 81, Springfield, VA, December 1980. 2677 [Dolev91] 2678 Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography", 2679 Proceedings of the 23rd Annual Symposium on Theory of Computing, 2680 ACM, 1991. 2681 [HMAC] 2682 Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 2683 for Message Authentication", RFC 2104, February 1997. 2684 2685 2686 2687 2688 2689 2690Raeburn [Page 48] 2691 2692INTERNET DRAFT February 2004 2693 2694 2695 [KRB5-AES] 2696 Raeburn, K., "AES Encyrption for Kerberos 5", RFC XXXX, Xxxxxxxx 2697 2003. 2698 [MD4-92] 2699 Rivest, R., "The MD4 Message Digest Algorithm," RFC 1320, MIT 2700 Laboratory for Computer Science, April 1992. 2701 [MD5-92] 2702 Rivest, R., "The MD5 Message Digest Algorithm," RFC 1321, MIT 2703 Laboratory for Computer Science, April 1992. 2704 [RFC2026] 2705 Bradner, S., "The Internet Standards Process -- Revisions 3," RFC 2706 2026, October 1996. 2707 [SG92] 2708 Stubblebine, S., and V. D. Gligor, "On Message Integrity in 2709 Cryptographic Protocols," in Proceedings of the IEEE Symposium on 2710 Research in Security and Privacy, Oakland, California, May 1992. 2711 2712Informative References 2713 2714 [Bellovin91] 2715 Bellovin, S. M., and M. Merrit, "Limitations of the Kerberos 2716 Authentication System", in Proceedings of the Winter 1991 Usenix 2717 Security Conference, January, 1991. 2718 [Bellovin99] 2719 Bellovin, S. M., and D. Atkins, private communications, 1999. 2720 [EFF-DES] 2721 Electronic Frontier Foundation, "Cracking DES: Secrets of 2722 Encryption Research, Wiretap Politics, and Chip Design", O'Reilly 2723 & Associates, Inc., May 1998. 2724 [ESP-DES] 2725 Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm 2726 With Explicit IV", RFC 2405, November 1998. 2727 [GSS-KRB5] 2728 Linn, J., "The Kerberos Version 5 GSS-API Mechanism," RFC 1964, 2729 June 1996. 2730 [HMAC-TEST] 2731 Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", 2732 RFC 2202, September 1997. 2733 [IPSEC-HMAC] 2734 Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and 2735 AH", RFC 2404, November 1998. 2736 [Kerb] 2737 Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K. 2738 Raeburn, "The Kerberos Network Authentication Service (V5)", 2739 draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22, 2740 2002. Work in progress. 2741 2742 2743 2744 2745 2746Raeburn [Page 49] 2747 2748INTERNET DRAFT February 2004 2749 2750 2751 [Kerb1510] 2752 Kohl, J., and C. Neuman, "The Kerberos Network Authentication 2753 Service (V5)", RFC 1510, September 1993. 2754 [RC5] 2755 Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and 2756 RC5-CTS Algorithms", RFC 2040, October 1996. 2757 [Schneier96] 2758 Schneier, B., "Applied Cryptography Second Edition", John Wiley & 2759 Sons, New York, NY, 1996. ISBN 0-471-12845-7. 2760 2761Editor's address 2762 2763 Kenneth Raeburn 2764 Massachusetts Institute of Technology 2765 77 Massachusetts Avenue 2766 Cambridge, MA 02139 2767 raeburn@mit.edu 2768 2769 2770Full Copyright Statement 2771 2772 Copyright (C) The Internet Society (2004). All Rights Reserved. 2773 2774 This document and translations of it may be copied and furnished to 2775 others, and derivative works that comment on or otherwise explain it 2776 or assist in its implementation may be prepared, copied, published 2777 and distributed, in whole or in part, without restriction of any 2778 kind, provided that the above copyright notice and this paragraph are 2779 included on all such copies and derivative works. However, this 2780 document itself may not be modified in any way, such as by removing 2781 the copyright notice or references to the Internet Society or other 2782 Internet organizations, except as needed for the purpose of 2783 developing Internet standards in which case the procedures for 2784 copyrights defined in the Internet Standards process must be 2785 followed, or as required to translate it into languages other than 2786 English. 2787 2788 The limited permissions granted above are perpetual and will not be 2789 revoked by the Internet Society or its successors or assigns. 2790 2791 This document and the information contained herein is provided on an 2792 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2793 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2794 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2795 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2796 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2797 2798 2799 2800 2801 2802Raeburn [Page 50] 2803 2804INTERNET DRAFT February 2004 2805 2806 2807Notes to RFC Editor 2808 2809 Before publication of this document as an RFC, the following changes 2810 are needed: 2811 2812 Change the reference "[KRB5-AES]" in Normative References to indicate 2813 the AES draft (draft-raeburn-krb-rijndael-krb-XX) that should be 2814 advancing to RFC at the same time. The RFC number and publication 2815 date are needed. 2816 2817 If draft-ietf-krb-wg-kerberos-clarifications advances to RFC at the 2818 same time as this document, change the information for [Kerb] in the 2819 Informative References section as well. 2820 2821 Change the first-page headers to indicate the RFC number, network 2822 working group, etc, as appropriate for an RFC instead of an I-D. 2823 2824 Remove the contact-info paragraph from the Abstract. 2825 2826 Delete this section. 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858Raeburn [Page 51] 2859