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