idnits 2.17.1 draft-ietf-krb-wg-crypto-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 687 has weird spacing: '...unction tmp...' == Line 716 has weird spacing: '...osystem as d...' == Line 754 has weird spacing: '...osystem any...' == Line 772 has weird spacing: '...osystem any...' == Line 808 has weird spacing: '...osystem any...' == (16 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 27, 2004) is 7303 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 2074 == Missing Reference: 'K' is mentioned on line 236, but not defined -- Looks like a reference, but probably isn't: '2' on line 2079 -- Looks like a reference, but probably isn't: '3' on line 2088 -- Looks like a reference, but probably isn't: '4' on line 2092 -- Looks like a reference, but probably isn't: '5' on line 2099 -- Looks like a reference, but probably isn't: '6' on line 2105 -- Looks like a reference, but probably isn't: '0' on line 959 -- Looks like a reference, but probably isn't: '7' on line 2112 -- Looks like a reference, but probably isn't: '8' on line 2121 == Missing Reference: 'RFC1851' is mentioned on line 1556, but not defined == Missing Reference: 'BCP26' is mentioned on line 1616, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellare98' -- Possible downref: Non-RFC (?) normative reference: ref. 'Blumenthal96' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRC' -- Possible downref: Non-RFC (?) normative reference: ref. 'DES77' -- Possible downref: Non-RFC (?) normative reference: ref. 'DESI81' -- Possible downref: Non-RFC (?) normative reference: ref. 'DESM80' -- Possible downref: Non-RFC (?) normative reference: ref. 'Dolev91' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') -- Possible downref: Non-RFC (?) normative reference: ref. 'KRB5-AES' ** Obsolete normative reference: RFC 1320 (ref. 'MD4-92') (Obsoleted by RFC 6150) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5-92') -- Possible downref: Non-RFC (?) normative reference: ref. 'SG92' == Outdated reference: A later version (-07) exists of draft-ietf-krb-wg-kerberos-clarifications-00 -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT K. Raeburn 3 Kerberos Working Group MIT 4 Document: draft-ietf-krb-wg-crypto-06.txt October 27, 2003 5 expires April 27, 2004 7 Encryption and Checksum Specifications 8 for Kerberos 5 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts 14 are working documents of the Internet Engineering Task Force (IETF), 15 its areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. Internet-Drafts are 17 draft documents valid for a maximum of six months and may be updated, 18 replaced, or obsoleted by other documents at any time. It is 19 inappropriate to use Internet-Drafts as reference material or to cite 20 them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.html. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document describes a framework for defining encryption and 31 checksum mechanisms for use with the Kerberos protocol, defining an 32 abstraction layer between the Kerberos protocol and related 33 protocols, and the actual mechanisms themselves. Several mechanisms 34 are also defined in this document. Some are taken from RFC 1510, 35 modified in form to fit this new framework, and occasionally modified 36 in content when the old specification was incorrect. New mechanisms 37 are presented here as well. This document does NOT indicate which 38 mechanisms may be considered "required to implement". 40 Comments should be sent to the editor, or to the IETF Kerberos 41 working group (ietf-krb-wg@anl.gov). 43 Table of Contents 45 Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . . 1 46 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 47 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Encryption algorithm profile . . . . . . . . . . . . . . . . . . 4 51 4. Checksum algorithm profile . . . . . . . . . . . . . . . . . . . 9 52 5. Simplified profile for CBC ciphers with key derivation . . . . . 10 53 5.1. A key derivation function . . . . . . . . . . . . . . . . . . . 11 54 5.2. Simplified profile parameters . . . . . . . . . . . . . . . . . 13 55 5.3. Cryptosystem profile based on simplified profile . . . . . . . 14 56 5.4. Checksum profiles based on simplified profile . . . . . . . . . 16 57 6. Profiles for Kerberos encryption and checksum algorithms . . . . 16 58 6.1. Unkeyed checksums . . . . . . . . . . . . . . . . . . . . . . . 16 59 6.2. DES-based encryption and checksum types . . . . . . . . . . . . 18 60 6.3. Triple-DES based encryption and checksum types . . . . . . . . 28 61 7. Use of Kerberos encryption outside this specification . . . . . . 30 62 8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . . . 31 63 9. Implementation Notes . . . . . . . . . . . . . . . . . . . . . . 33 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 33 65 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 35 66 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 36 67 A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . . . 37 68 A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 69 A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . . . . . 39 70 A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . . . . . 43 71 A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . . . . . 44 72 A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . . . . . 45 73 B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . . . 45 74 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 75 Normative References . . . . . . . . . . . . . . . . . . . . . . . . 47 76 Informative References . . . . . . . . . . . . . . . . . . . . . . . 49 77 Editor's address . . . . . . . . . . . . . . . . . . . . . . . . . . 49 78 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 50 79 1. Introduction 81 The Kerberos protocols are designed to encrypt messages of arbitrary 82 sizes, using block encryption ciphers, or less commonly, stream 83 encryption ciphers. Encryption is used to prove the identities of 84 the network entities participating in message exchanges. However, 85 nothing in the Kerberos protocol requires any specific encryption 86 algorithm be used, as long as certain operations are available in the 87 algorithm that is used. 89 The following sections specify the encryption and checksum mechanisms 90 currently defined for Kerberos, as well as a framework for defining 91 future mechanisms. The encoding, chaining, padding and other 92 requirements for each are described. Test vectors for several 93 functions are given in appendix A. 95 2. Concepts 97 Both encryption and checksum mechanisms are defined in terms of 98 profiles, detailed in later sections. Each specifies a collection of 99 operations and attributes that must be defined for a mechanism. A 100 Kerberos encryption or checksum mechanism specification is not 101 complete if it does not define all of these operations and 102 attributes. 104 An encryption mechanism must provide for confidentiality and 105 integrity of the original plaintext. (Integrity checking may be 106 achieved by incorporating a checksum, if the encryption mode does not 107 provide an integrity check itself.) It must also provide non- 108 malleability [Bellare98, Dolev91]. Use of a random confounder 109 prepended to the plaintext is recommended. It should not be possible 110 to determine if two ciphertexts correspond to the same plaintext, 111 without knowledge of the key. 113 A checksum mechanism [1] must provide proof of the integrity of the 114 associated message, and must preserve the confidentiality of the 115 message in case it is not sent in the clear. It should be infeasible 116 to find two plaintexts which have the same checksum. It is NOT 117 required that an eavesdropper be unable to determine if two checksums 118 are for the same message; it is assumed that the messages themselves 119 will be visible to any such eavesdropper. 121 Due to advances in cryptography, it is considered unwise by some 122 cryptographers to use the same key for multiple purposes. Since keys 123 are used in performing a number of different functions in Kerberos, 124 it is desirable to use different keys for each of these purposes, 125 even though we start with a single long-term or session key. 127 We do this by enumerating the different uses of keys within Kerberos, 128 and making the "usage number" an input to the encryption or checksum 129 mechanisms; this enumeration is outside the scope of this document. 130 Later sections of this document define simplified profile templates 131 for encryption and checksum mechanisms that use a key derivation 132 function applied to a CBC mode (or similar) cipher and a checksum or 133 hash algorithm. 135 We distinguish the "base key" specified by other documents from the 136 "specific key" to be used for a particular instance of encryption or 137 checksum operations. It is expected but not required that the 138 specific key will be one or more separate keys derived from the 139 original protocol key and the key usage number. The specific key 140 should not be explicitly referenced outside of this document. The 141 typical language used in other documents should be something like, 142 "encrypt this octet string using this key and this usage number"; 143 generation of the specific key and cipher state (described in the 144 next section) are implicit. The creation of a new cipher-state 145 object, or the re-use of one from a previous encryption operation, 146 may also be explicit. 148 New protocols defined in terms of the Kerberos encryption and 149 checksum types should use their own key usage values. Key usages are 150 unsigned 32 bit integers; zero is not permitted. 152 All data is assumed to be in the form of strings of octets or 8-bit 153 bytes. Environments with other byte sizes will have to emulate this 154 behavior in order to get correct results. 156 Each algorithm is assigned an encryption type (or "etype") or 157 checksum type number, for algorithm identification within the 158 Kerberos protocol. The full list of current type number assignments 159 is given in section 8. 161 3. Encryption algorithm profile 163 An encryption mechanism profile must define the following attributes 164 and operations. The operations must be defined as functions in the 165 mathematical sense: no additional or implicit inputs (such as 166 Kerberos principal names or message sequence numbers) are permitted. 168 protocol key format 169 This describes what octet string values represent valid keys. For 170 encryption mechanisms that don't have perfectly dense key spaces, 171 this will describe the representation used for encoding keys. It 172 need not describe specific values that are not valid or desirable 173 for use; such values should be avoid by all key generation 174 routines. 176 specific key structure 177 This is not a protocol format at all, but a description of the 178 keying material derived from the chosen key and used to encrypt or 179 decrypt data or compute or verify a checksum. It may, for 180 example, be a single key, a set of keys, or a combination of the 181 original key with additional data. The authors recommend using 182 one or more keys derived from the original key via one-way key 183 derivation functions. 185 required checksum mechanism 186 This indicates a checksum mechanism that must be available when 187 this encryption mechanism is used. Since Kerberos has no built in 188 mechanism for negotiating checksum mechanisms, once an encryption 189 mechanism has been decided upon, the corresponding checksum 190 mechanism can simply be used. 192 key-generation seed length, K 193 This is the length of the random bitstring needed to generate a 194 key with the encryption scheme's random-to-key function (described 195 below). This must be a fixed value so that various techniques for 196 producing a random bitstring of a given length may be used with 197 key generation functions. 199 key generation functions 200 Keys must be generated in a number of cases, from different types 201 of inputs. All function specifications must indicate how to 202 generate keys in the proper wire format, and must avoid generation 203 of keys that significantly compromise the confidentiality of 204 encrypted data, if the cryptosystem has such. Entropy from each 205 source should be preserved as much as possible. Many of the 206 inputs, while unknown, may be at least partly predictable (e.g., a 207 password string is likely to be entirely in the ASCII subset and 208 of fairly short length in many environments; a semi-random string 209 may include timestamps); the benefit of such predictability to an 210 attacker must be minimized. 212 string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key) 213 This function generates a key from two UTF-8 strings and an 214 opaque octet string. One of the strings is normally the 215 principal's pass phrase, but is in general merely a secret 216 string. The other string is a "salt" string intended to 217 produce different keys from the same password for different 218 users or realms. While the strings provided will use UTF-8 219 encoding, no specific version of Unicode should be assumed; all 220 valid UTF-8 strings should be allowed. 222 The third argument, the octet string, may be used to pass 223 mechanism-specific parameters in to this function. Since doing 224 so implies knowledge of the specific encryption system, it is 225 intended that generating non-default parameter values be an 226 uncommon operation, and that normal Kerberos applications be 227 able to treat this parameter block as an opaque object supplied 228 by the Key Distribution Center or defaulted to some mechanism- 229 specific constant value. 231 The string-to-key function should be a one-way function, so 232 that compromising a user's key in one realm does not compromise 233 the user's key in another realm, even if the same password (but 234 a different salt) is used. 236 random-to-key (bitstring[K])->(protocol-key) 237 This function generates a key from a random bitstring of a 238 specific size. It may be assumed that all the bits of the 239 input string are equally random, even though the entropy 240 present in the random source may be limited. 242 key-derivation (protocol-key, integer)->(specific-key) 243 In this function, the integer input is the key usage value as 244 described above; the usage values must be assumed to be known 245 to an attacker. The specific-key output value was described in 246 section 2. 248 string-to-key parameter format 249 This describes the format of the block of data that can be passed 250 to the string-to-key function above to configure additional 251 parameters for that function. Along with the mechanism of 252 encoding parameter values, bounds on the allowed parameters should 253 also be described to avoid allowing a spoofed KDC to compromise 254 the user's password. It may be desirable to construct the 255 encoding such that values weakening the resulting key unacceptably 256 cannot be encoded, if practical. 258 Tighter bounds might be permitted by local security policy, or to 259 avoid excess resource consumption; if so, recommended defaults for 260 those bounds should be given in the specification. The 261 description should also outline possible weaknesses that may be 262 caused by not applying bounds checks or other validation to a 263 parameter string received from the network. 265 As mentioned above, this should be considered opaque to most 266 normal applications. 268 default string-to-key parameters (octet string) 269 This default value for the "params" argument to the string-to-key 270 function is to be used when the application protocol (Kerberos or 271 otherwise) does not explicitly set the parameter value. As 272 indicated above, this parameter block should be treated as an 273 opaque object in most cases. 275 cipher state 276 This describes any information that can be carried over from one 277 encryption or decryption operation to the next, for use in 278 conjunction with a given specific key. For example, a block 279 cipher used in CBC mode may put an initial vector of one block in 280 the cipher state. Other encryption modes may track nonces or 281 other data. 283 This state must be non-empty, and must influence encryption so as 284 to require that messages be decrypted in the same order they were 285 encrypted, if the cipher state is carried over from one encryption 286 to the next. Distinguishing out-of-order or missing messages from 287 corrupted messages is not required; if desired, this can be done 288 at a higher level by including sequence numbers and not "chaining" 289 the cipher state between encryption operations. 291 The cipher state may not be reused in multiple encryption or 292 decryption operations; these operations all generate a new cipher 293 state that may be used for following operations using the same key 294 and operation. 296 The contents of the cipher state must be treated as opaque outside 297 of encryption system specifications. 299 initial cipher state (specific-key, direction)->(state) 300 This describes the generation of the initial value for the cipher 301 state if it is not being carried over from a previous encryption 302 or decryption operation. 304 This describes any initial state setup needed before encrypting 305 arbitrary amounts of data with a given specific key; the specific 306 key and the direction of operations to be performed (encrypt 307 versus decrypt) must be the only input needed for this 308 initialization. 310 This state should be treated as opaque in any uses outside of an 311 encryption algorithm definition. 313 IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what 314 degree an application protocol could exercise control over the 315 initial vector used in DES CBC operations. Some existing 316 implementations permit the setting of the initial vector. This 317 new specification does not permit application control of the 318 cipher state (beyond "initialize" and "carry over from previous 319 encryption"), since the form and content of the initial cipher 320 state can vary between encryption systems, and may not always be a 321 single block of random data. 323 New Kerberos application protocols should not assume that they can 324 control the initial vector, or that one even exists. However, a 325 general-purpose implementation may wish to provide the capability, 326 in case applications explicitly setting it are encountered. 328 encrypt (specific-key, state, octet string)->(state, octet string) 329 This function takes the specific key, cipher state, and a non- 330 empty plaintext string as input, and generates ciphertext and a 331 new cipher state as outputs. If the basic encryption algorithm 332 itself does not provide for integrity protection (as DES in CBC 333 mode does not do), then some form of MAC or checksum must be 334 included that can be verified by the receiver. Some random factor 335 such as a confounder should be included so that an observer cannot 336 know if two messages contain the same plaintext, even if the 337 cipher state and specific keys are the same. The exact length of 338 the plaintext need not be encoded, but if it is not and if padding 339 is required, the padding must be added at the end of the string so 340 that the decrypted version may be parsed from the beginning. 342 The specification of the encryption function must not only 343 indicate the precise contents of the output octet string, but also 344 the output cipher state. The application protocol may carry 345 forward the output cipher state from one encryption with a given 346 specific key to another; the effect of this "chaining" must be 347 defined. [2] 349 Assuming correctly-produced values for the specific key and cipher 350 state, no input octet string may result in an error indication. 352 decrypt (specific-key, state, octet string)->(state, octet string) 353 This function takes the specific key, cipher state, and ciphertext 354 as inputs, and verifies the integrity of the supplied ciphertext. 355 If the ciphertext's integrity is intact, this function produces 356 the plaintext and a new cipher state as outputs; otherwise, an 357 error indication must be returned, and the data discarded. 359 The result of the decryption may be longer than the original 360 plaintext, for example if the encryption mode adds padding to 361 reach a multiple of a block size. If this is the case, any extra 362 octets must be after the decoded plaintext. An application 363 protocol which needs to know the exact length of the message must 364 encode a length or recognizable "end of message" marker within the 365 plaintext. [3] 367 As with the encryption function, a correct specification for this 368 function must indicate not only the contents of the output octet 369 string, but also the resulting cipher state. 371 pseudo-random (protocol-key, octet-string)->(octet-string) 372 This pseudo-random function should generate an octet string of 373 some size that independent of the octet string input. The PRF 374 output string should be suitable for use in key generation, even 375 if the octet string input is public. It should not reveal the 376 input key, even if the output is made public. 378 These operations and attributes are all that is required to support 379 Kerberos and various proposed preauthentication schemes. 381 For convenience of certain application protocols that may wish to use 382 the encryption profile, we add the constraint that, for any given 383 plaintext input size, there must be a message size between that given 384 size and that size plus 65535 such that the length of such that the 385 decrypted version of the ciphertext for any message of that size will 386 never have extra octets added at the end. 388 Expressed mathematically, for every message length L1, there exists a 389 message size L2 such that: 391 L2 >= L1 392 L2 < L1 + 65536 393 for every message M with |M| = L2, decrypt(encrypt(M)) = M 395 A document defining a new encryption type should also describe known 396 weaknesses or attacks, so that its security may be fairly assessed, 397 and should include test vectors or other validation procedures for 398 the operations defined. Specific references to information readily 399 available elsewhere are sufficient. 401 4. Checksum algorithm profile 403 A checksum mechanism profile must define the following attributes and 404 operations: 406 associated encryption algorithm(s) 407 This indicates the types of encryption keys this checksum 408 mechanism can be used with. 410 A keyed checksum mechanism may have more than one associated 411 encryption algorithm if they share the same wire key format, 412 string-to-key function, and key derivation function. (This 413 combination means that, for example, a checksum type, key usage 414 value and password are adequate to get the specific key used to 415 compute a checksum.) 416 An unkeyed checksum mechanism can be used in conjunction with any 417 encryption type, since the key is ignored, but its use must be 418 limited to cases where the checksum itself is protected, to avoid 419 trivial attacks. 421 get_mic function 422 This function generates a MIC token for a given specific key (see 423 section 3), and message (represented as an octet string), that may 424 be used to verify the integrity of the associated message. This 425 function is not required to return the same deterministic result 426 on every use; it need only generate a token that the verify_mic 427 routine can check. 429 The output of this function will also dictate the size of the 430 checksum. It must be no larger than 65535 octets. 432 verify_mic function 433 Given a specific key, message, and MIC token, this function 434 ascertains whether the message integrity has been compromised. 435 For a deterministic get_mic routine, the corresponding verify_mic 436 may simply generate another checksum and compare them. 438 The get_mic and verify_mic operations must be able to handle inputs 439 of arbitrary length; if any padding is needed, the padding scheme 440 must be specified as part of these functions. 442 These operations and attributes are all that should be required to 443 support Kerberos and various proposed preauthentication schemes. 445 As with encryption mechanism definition documents, documents defining 446 new checksum mechanisms should indicate validation processes and 447 known weaknesses. 449 5. Simplified profile for CBC ciphers with key derivation 451 The profile outlines in sections 3 and 4 describes a large number of 452 operations that must be defined for encryption and checksum 453 algorithms to be used with Kerberos. We describe here a simpler 454 profile from which both encryption and checksum mechanism definitions 455 can be generated, filling in uses of key derivation in appropriate 456 places, providing integrity protection, and defining multiple 457 operations for the cryptosystem profile based on a smaller set of 458 operations given in the simplified profile. Not all of the existing 459 cryptosystems for Kerberos fit into this simplified profile, but we 460 recommend that future cryptosystems use it or something based on it. 461 [4] 463 Not all of the operations in the complete profiles are defined 464 through this mechanism; several must still be defined for each new 465 algorithm pair. 467 5.1. A key derivation function 469 Rather than define some scheme by which a "protocol key" is composed 470 of a large number of encryption keys, we use keys derived from a base 471 key to perform cryptographic operations. The base key must be used 472 only for generating the derived keys, and this derivation must be 473 non-invertible and entropy-preserving. Given these restrictions, 474 compromise of one derived key does not compromise the other subkeys. 475 Attack of the base key is limited, since it is only used for 476 derivation, and is not exposed to any user data. 478 Since the derived key has as much entropy as the base keys (if the 479 cryptosystem is good), password-derived keys have the full benefit of 480 all the entropy in the password. 482 To generate a derived key from a base key, we generate a pseudorandom 483 octet string, using an algorithm DR described below, and generate a 484 key from that octet string using a function dependent on the 485 encryption algorithm; the input length needed for that function, 486 which is also dependent on the encryption algorithm, dictates the 487 length of the string to be generated by the DR algorithm (the value 488 "k" below). These procedures are based on the key derivation in 489 [Blumenthal96]. 491 Derived Key = DK(Base Key, Well-Known Constant) 493 DK(Key, Constant) = random-to-key(DR(Key, Constant)) 495 DR(Key, Constant) = k-truncate(E(Key, Constant, 496 initial-cipher-state)) 498 Here DR is the random-octet generation function described below, and 499 DK is the key-derivation function produced from it. In this 500 construction, E(Key, Plaintext, CipherState) is a cipher, Constant is 501 a well-known constant determined by the specific usage of this 502 function, and k-truncate truncates its argument by taking the first k 503 bits. Here, k is the key generation seed length needed for the 504 encryption system. 506 The output of the DR function is a string of bits; the actual key is 507 produced by applying the cryptosystem's random-to-key operation on 508 this bitstring. 510 If the Constant is smaller than the cipher block size of E, then it 511 must be expanded with n-fold() so it can be encrypted. If the output 512 of E is shorter than k bits it is fed back into the encryption as 513 many times as necessary. The construct is as follows (where | 514 indicates concatentation): 516 K1 = E(Key, n-fold(Constant), initial-cipher-state) 517 K2 = E(Key, K1, initial-cipher-state) 518 K3 = E(Key, K2, initial-cipher-state) 519 K4 = ... 521 DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...) 523 n-fold is an algorithm which takes m input bits and ``stretches'' 524 them to form n output bits with equal contribution from each input 525 bit to the output, as described in [Blumenthal96]: 527 We first define a primitive called n-folding, which takes a 528 variable-length input block and produces a fixed-length output 529 sequence. The intent is to give each input bit approximately 530 equal weight in determining the value of each output bit. Note 531 that whenever we need to treat a string of octets as a number, the 532 assumed representation is Big-Endian -- Most Significant Byte 533 first. 535 To n-fold a number X, replicate the input value to a length that 536 is the least common multiple of n and the length of X. Before 537 each repetition, the input is rotated to the right by 13 bit 538 positions. The successive n-bit chunks are added together using 539 1's-complement addition (that is, with end-around carry) to yield 540 a n-bit result.... 542 Test vectors for n-fold are supplied in Appendix A. [5] 544 In this section, n-fold is always used to produce c bits of output, 545 where c is the cipher block size of E. 547 The size of the Constant must not be larger than c, because reducing 548 the length of the Constant by n-folding can cause collisions. 550 If the size of the Constant is smaller than c, then the Constant must 551 be n-folded to length c. This string is used as input to E. If the 552 block size of E is less than the random-to-key input size, then the 553 output from E is taken as input to a second invocation of E. This 554 process is repeated until the number of bits accumulated is greater 555 than or equal to the random-to-key input size. When enough bits have 556 been computed, the first k are taken as the random data used to 557 create the key with the algorithm-dependent random-to-key function. 559 Since the derived key is the result of one or more encryptions in the 560 base key, deriving the base key from the derived key is equivalent to 561 determining the key from a very small number of plaintext/ciphertext 562 pairs. Thus, this construction is as strong as the cryptosystem 563 itself. 565 5.2. Simplified profile parameters 567 These are the operations and attributes that must be defined: 569 protocol key format 570 string-to-key function 571 default string-to-key parameters 572 key-generation seed length, k 573 random-to-key function 574 As above for the normal encryption mechanism profile. 576 unkeyed hash algorithm, H 577 This should be a collision-resistant hash algorithm with fixed- 578 size output, suitable for use in an HMAC [HMAC]. It must support 579 inputs of arbitrary length. Its output must be at least the 580 message block size (below). 582 HMAC output size, h 583 This indicates the size of the leading substring output by the 584 HMAC function that should be used in transmitted messages. It 585 should be at least half the output size of the hash function H, 586 and at least 80 bits; it need not match the output size. 588 message block size, m 589 This is the size of the smallest units the cipher can handle in 590 the mode in which it is being used. Messages will be padded to a 591 multiple of this size. If a block cipher is used in a mode that 592 can handle messages that are not multiples of the cipher block 593 size, such as CBC mode with cipher text stealing (CTS, see [RC5]), 594 this value would be one octet. For traditional CBC mode with 595 padding, it will be the underlying cipher's block size. 597 This value must be a multiple of 8 bits (one octet). 599 encryption/decryption functions, E and D 600 These are basic encryption and decryption functions for messages 601 of sizes that are multiples of the message block size. No 602 integrity checking or confounder should be included here. These 603 functions take as input the IV or similar data, a protocol-format 604 key, and a octet string, returning a new IV and octet string. 606 The encryption function is not required to use CBC mode, but is 607 assumed to be using something with similar properties. In 608 particular, prepending a cipher-block-size confounder to the 609 plaintext should alter the entire ciphertext (comparable to 610 choosing and including a random initial vector for CBC mode). 612 The result of encrypting one cipher block (of size c, above) must 613 be deterministic, for the random octet generation function DR in 614 the previous section to work. For best security, it should also 615 be no larger than c. 617 cipher block size, c 618 This is the block size of the block cipher underlying the 619 encryption and decryption functions indicated above, used for key 620 derivation and for the size of the message confounder and initial 621 vector. (If a block cipher is not in use, some comparable 622 parameter should be determined.) It must be at least 5 octets. 624 This is not actually an independent parameter; rather, it is a 625 property of the functions E and D. It is listed here to clarify 626 the distinction between it and the message block size, m. 628 While there are still a number of properties to specify, they are 629 fewer and simpler than in the full profile. 631 5.3. Cryptosystem profile based on simplified profile 633 The above key derivation function is used to produce three 634 intermediate keys. One is used for computing checksums of 635 unencrypted data. The other two are used for encrypting and 636 checksumming plaintext to be sent encrypted. 638 The ciphertext output is the concatenation of the output of the basic 639 encryption function E and a (possibly truncated) HMAC using the 640 specified hash function H, both applied to the plaintext with a 641 random confounder prefix and sufficient padding to bring it to a 642 multiple of the message block size. When the HMAC is computed, the 643 key is used in the protocol key form. 645 Decryption is performed by removing the (partial) HMAC, decrypting 646 the remainder, and verifying the HMAC. The cipher state is an 647 initial vector, initialized to zero. 649 The substring notation "[1..h]" in the following table should be read 650 as using 1-based indexing; leading substrings are used. 652 cryptosystem from simplified profile 653 ---------------------------------------------------------------------------- 654 protocol key format As given. 656 specific key structure Three protocol-format keys: { Kc, Ke, Ki }. 658 key-generation seed As given. 659 length 661 required checksum As defined below in section 5.4. 662 mechanism 664 cipher state initial vector (usually of length c) 666 initial cipher state all bits zero 668 encryption function conf = random string of length c 669 pad = shortest string to bring confounder 670 and plaintext to a length that's a 671 multiple of m 672 (C1, newIV) = E(Ke, conf | plaintext | pad, 673 oldstate.ivec) 674 H1 = HMAC(Ki, conf | plaintext | pad) 675 ciphertext = C1 | H1[1..h] 676 newstate.ivec = newIV 678 decryption function (C1,H1) = ciphertext 679 (P1, newIV) = D(Ke, C1, oldstate.ivec) 680 if (H1 != HMAC(Ki, P1)[1..h]) 681 report error 682 newstate.ivec = newIV 684 default string-to-key As given. 685 params 687 pseudo-random function tmp1 = H(octet-string) 688 tmp2 = truncate tmp1 to multiple of m 689 PRF = E(protocol-key, tmp2, initial-cipher-state) 691 key generation functions: 693 string-to-key function As given. 695 random-to-key function As given. 697 cryptosystem from simplified profile 698 ---------------------------------------------------------------------------- 699 key-derivation function The "well-known constant" used for the DK 700 function is the key usage number, expressed as 701 four octets in big-endian order, followed by one 702 octet indicated below. 704 Kc = DK(base-key, usage | 0x99); 705 Ke = DK(base-key, usage | 0xAA); 706 Ki = DK(base-key, usage | 0x55); 708 5.4. Checksum profiles based on simplified profile 710 When an encryption system is defined using the simplified profile 711 given in section 5.2, a checksum algorithm may be defined for it as 712 follows: 714 checksum mechanism from simplified profile 715 -------------------------------------------------- 716 associated cryptosystem as defined above 718 get_mic HMAC(Kc, message)[1..h] 720 verify_mic get_mic and compare 722 The HMAC function and key Kc are as described in section 5.3. 724 6. Profiles for Kerberos encryption and checksum algorithms 726 These profiles describe the encryption and checksum systems defined 727 for Kerberos. The astute reader will notice that some of them do not 728 fulfull all of the requirements outlined in previous sections. These 729 systems are defined for backward compatibility; newer implementations 730 should (whenever possible) attempt to make use of encryption systems 731 which satisfy all of the profile requirements. 733 The full list of current encryption and checksum type number 734 assignments, including values currently reserved but not defined in 735 this document, is given in section 8. 737 6.1. Unkeyed checksums 739 These checksum types use no encryption keys, and thus can be used in 740 combination with any encryption type, but may only be used with 741 caution, in limited circumstances where the lack of a key does not 742 provide a window for an attack, preferably as part of an encrypted 743 message. [6] Keyed checksum algorithms are recommended. 745 6.1.1. The RSA MD5 Checksum 747 The RSA-MD5 checksum calculates a checksum using the RSA MD5 748 algorithm [MD5-92]. The algorithm takes as input an input message of 749 arbitrary length and produces as output a 128-bit (16 octet) 750 checksum. RSA-MD5 is believed to be collision-proof. 752 rsa-md5 753 ---------------------------------------------- 754 associated cryptosystem any 756 get_mic rsa-md5(msg) 758 verify_mic get_mic and compare 760 The rsa-md5 checksum algorithm is assigned a checksum type number of 761 seven (7). 763 6.1.2. The RSA MD4 Checksum 765 The RSA-MD4 checksum calculates a checksum using the RSA MD4 766 algorithm [MD4-92]. The algorithm takes as input an input message of 767 arbitrary length and produces as output a 128-bit (16 octet) 768 checksum. RSA-MD4 is believed to be collision-proof. 770 rsa-md4 771 ---------------------------------------------- 772 associated cryptosystem any 774 get_mic md4(msg) 776 verify_mic get_mic and compare 778 The rsa-md4 checksum algorithm is assigned a checksum type number of 779 two (2). 781 6.1.3. CRC-32 Checksum 783 This CRC-32 checksum calculates a checksum based on a cyclic 784 redundancy check as described in ISO 3309 [CRC], modified as 785 described below. The resulting checksum is four (4) octets in 786 length. The CRC-32 is neither keyed nor collision-proof; thus, the 787 use of this checksum is not recommended. An attacker using a 788 probabilistic chosen-plaintext attack as described in [SG92] might be 789 able to generate an alternative message that satisfies the checksum. 791 The CRC-32 checksum used in the des-cbc-crc encryption mode is 792 identical to the 32-bit FCS described in ISO 3309 with two 793 exceptions: the sum with the all-ones polynomial times x**k is 794 omitted, and the final remainder is not ones-complemented. ISO 3309 795 describes the FCS in terms of bits, while this document describes the 796 Kerberos protocol in terms of octets. To disambiguate the ISO 3309 797 definition for the purpose of computing the CRC-32 in the des-cbc-crc 798 encryption mode, the ordering of bits in each octet shall be assumed 799 to be LSB-first. Given this assumed ordering of bits within an 800 octet, the mapping of bits to polynomial coefficients shall be 801 identical to that specified in ISO 3309. 803 Test values for this modified CRC function are included in appendix 804 A.5. 806 crc32 807 ---------------------------------------------- 808 associated cryptosystem any 810 get_mic crc32(msg) 812 verify_mic get_mic and compare 814 The crc32 checksum algorithm is assigned a checksum type number of 815 one (1). 817 6.2. DES-based encryption and checksum types 819 These encryption systems encrypt information under the Data 820 Encryption Standard [DES77] using the cipher block chaining mode 821 [DESM80]. A checksum is computed as described below and placed in 822 the cksum field. DES blocks are 8 bytes. As a result, the data to 823 be encrypted (the concatenation of confounder, checksum, and message) 824 must be padded to an 8 byte boundary before encryption. The values 825 of the padding bytes are unspecified. 827 Plaintext and DES ciphertext are encoded as blocks of 8 octets which 828 are concatenated to make the 64-bit inputs for the DES algorithms. 829 The first octet supplies the 8 most significant bits (with the 830 octet's MSB used as the DES input block's MSB, etc.), the second 831 octet the next 8 bits, ..., and the eighth octet supplies the 8 least 832 significant bits. 834 Encryption under DES using cipher block chaining requires an 835 additional input in the form of an initialization vector; this vector 836 is specified for each encryption system, below. 838 The DES specifications [DESI81] identify four 'weak' and twelve 839 'semi-weak' keys; those keys shall not be used for encrypting 840 messages for use in Kerberos. The "variant keys" generated for the 841 RSA-MD5-DES, RSA-MD4-DES and DES-MAC checksum types by an exclusive- 842 or of a DES key with a hexadecimal constant are not checked for this 843 property. 845 A DES key is 8 octets of data. This consists of 56 bits of actual 846 key data, and 8 parity bits, one per octet. The key is encoded as a 847 series of 8 octets written in MSB-first order. The bits within the 848 key are also encoded in MSB order. For example, if the encryption 849 key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) 850 where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 851 are the parity bits, the first octet of the key would be 852 B1,B2,...,B7,P1 (with B1 as the most significant bit). See the 853 [DESM80] introduction for reference. 855 Encryption data format 857 The format for the data to be encrypted includes a one-block 858 confounder, a checksum, the encoded plaintext, and any necessary 859 padding, as described in the following diagram. The msg-seq field 860 contains the part of the protocol message which is to be encrypted. 862 +-----------+----------+---------+-----+ 863 |confounder | checksum | msg-seq | pad | 864 +-----------+----------+---------+-----+ 866 One generates a random confounder of one block, placing it in 867 'confounder'; zeroes out the 'checksum' field (of length appropriate 868 to exactly hold the checksum to be computed); calculates the 869 appropriate checksum over the whole sequence, placing the result in 870 'checksum'; adds the necessary padding; then encrypts using the 871 specified encryption type and the appropriate key. 873 String or random-data to key transformation 875 To generate a DES key from two UTF-8 text strings (password and 876 salt), the two strings are concatenated, password first, and the 877 result is then padded with zero-valued octets to a multiple of 8 878 octets. 880 The top bit of each octet (always zero if the password is plain 881 ASCII, as was assumed when the original specification was written) is 882 discarded, and a bitstring is formed of the remaining seven bits of 883 each octet. This bitstring is then fan-folded and eXclusive-ORed 884 with itself to produce a 56-bit string. An eight-octet key is formed 885 from this string, each octet using seven bits from the bitstring, 886 leaving the least significant bit unassigned. The key is then 887 "corrected" by correcting the parity on the key, and if the key 888 matches a 'weak' or 'semi-weak' key as described in the DES 889 specification, it is eXclusive-ORed with the constant 890 0x00000000000000F0. This key is then used to generate a DES CBC 891 checksum on the initial string with the salt appended. The result of 892 the CBC checksum is then "corrected" as described above to form the 893 result which is returned as the key. 895 For purposes of the string-to-key function, the DES CBC checksum is 896 calculated by CBC encrypting a string using the key as IV and using 897 the final 8 byte block as the checksum. 899 Pseudocode follows: 901 removeMSBits(8byteblock) { 902 /* Treats a 64 bit block as 8 octets and remove the MSB in 903 each octect (in big endian mode) and concatenates the 904 result. E.g., input octet string: 905 01110000 01100001 11110011 01110011 11110111 01101111 906 11110010 01100100 907 results in output bitstring: 908 1110000 1100001 1110011 1110011 1110111 1101111 909 1110010 1100100 */ 910 } 912 reverse(56bitblock) { 913 /* Treats a 56-bit block as a binary string and reverse it. 914 E.g., input string: 915 1000001 1010100 1001000 1000101 1001110 1000001 916 0101110 1001101 917 results in output string: 918 1011001 0111010 1000001 0111001 1010001 0001001 919 0010101 1000001 */ 920 } 921 add_parity_bits(56bitblock) { 922 /* Copies a 56-bit block into a 64-bit block, left shift 923 content in each octet and add DES parity bit. 924 E.g., input string: 925 1100000 0001111 0011100 0110100 1000101 1100100 926 0110110 0010111 927 results in output string: 928 11000001 00011111 00111000 01101000 10001010 11001000 929 01101101 00101111 */ 930 } 932 key_correction(key) { 933 fixparity(key); 934 if (is_weak_key(key)) 935 key = key XOR 0xF0; 936 return(key); 937 } 939 mit_des_string_to_key(string,salt) { 940 odd = 1; 941 s = string | salt; 942 tempstring = 0; /* 56-bit string */ 943 pad(s); /* with nulls to 8 byte boundary */ 944 for (8byteblock in s) { 945 56bitstring = removeMSBits(8byteblock); 946 if (odd == 0) reverse(56bitstring); 947 odd = ! odd; 948 tempstring = tempstring XOR 56bitstring; 949 } 950 tempkey = key_correction(add_parity_bits(tempstring)); 951 key = key_correction(DES-CBC-check(s,tempkey)); 952 return(key); 953 } 955 des_string_to_key(string,salt,params) { 956 if (length(params) == 0) 957 type = 0; 958 else if (length(params) == 1) 959 type = params[0]; 960 else 961 error("invalid params"); 962 if (type == 0) 963 mit_des_string_to_key(string,salt); 964 else 965 error("invalid params"); 966 } 968 One common extension is to support the "AFS string-to-key" algorithm, 969 which is not defined here, if the type value above is one (1). 971 For generation of a key from a random bitstring, we start with a 972 56-bit string, and as with the string-to-key operation above, insert 973 parity bits, and if the result is a weak or semi-weak key, modify it 974 by exclusive-OR with the constart 0x00000000000000F0: 976 des_random_to_key(bitstring) { 977 return key_correction(add_parity_bits(bitstring)); 978 } 980 6.2.1. DES with MD5 982 The des-cbc-md5 encryption mode encrypts information under DES in CBC 983 mode with an all-zero initial vector, with an MD5 checksum (described 984 in [MD5-92]) computed and placed in the checksum field. 986 The encryption system parameters for des-cbc-md5 are: 988 des-cbc-md5 989 -------------------------------------------------------------------- 990 protocol key format 8 bytes, parity in low bit of each 992 specific key structure copy of original key 994 required checksum rsa-md5-des 995 mechanism 997 key-generation seed 8 bytes 998 length 1000 cipher state 8 bytes (CBC initial vector) 1002 initial cipher state all-zero 1004 encryption function des-cbc(confounder | checksum | msg | pad, 1005 ivec=oldstate) 1006 where 1007 checksum = md5(confounder | 0000... 1008 | msg | pad) 1010 newstate = last block of des-cbc output 1012 decryption function decrypt encrypted text and verify checksum 1014 newstate = last block of ciphertext 1015 des-cbc-md5 1016 -------------------------------------------------------------------- 1017 default string-to-key empty string 1018 params 1020 pseudo-random function des-cbc(md5(input-string), ivec=0) 1022 key generation functions: 1024 string-to-key des_string_to_key 1026 random-to-key des_random_to_key 1028 key-derivation identity 1030 The des-cbc-md5 encryption type is assigned the etype value three 1031 (3). 1033 6.2.2. DES with MD4 1035 The des-cbc-md4 encryption mode also encrypts information under DES 1036 in CBC mode, with an all-zero initial vector. An MD4 checksum 1037 (described in [MD4-92]) is computed and placed in the checksum field. 1039 des-cbc-md4 1040 -------------------------------------------------------------------- 1041 protocol key format 8 bytes, parity in low bit of each 1043 specific key structure copy of original key 1045 required checksum rsa-md4-des 1046 mechanism 1048 key-generation seed 8 bytes 1049 length 1051 cipher state 8 bytes (CBC initial vector) 1053 initial cipher state all-zero 1055 encryption function des-cbc(confounder | checksum | msg | pad, 1056 ivec=oldstate) 1057 where 1058 checksum = md4(confounder | 0000... 1059 | msg | pad) 1061 newstate = last block of des-cbc output 1062 des-cbc-md4 1063 -------------------------------------------------------------------- 1065 decryption function decrypt encrypted text and verify checksum 1067 newstate = last block of ciphertext 1069 default string-to-key empty string 1070 params 1072 pseudo-random function des-cbc(md5(input-string), ivec=0) 1074 key generation functions: 1076 string-to-key des_string_to_key 1078 random-to-key copy input, then fix parity bits 1080 key-derivation identity 1082 Note that des-cbc-md4 uses md5, not md4, in the PRF definition. 1084 The des-cbc-md4 encryption algorithm is assigned the etype value two 1085 (2). 1087 6.2.3. DES with CRC 1089 The des-cbc-crc encryption type uses DES in CBC mode with the key 1090 used as the initialization vector, with a 4-octet CRC-based checksum 1091 computed as described in section 6.1.3. Note that this is not a 1092 standard CRC-32 checksum, but a slightly modified one. 1094 des-cbc-crc 1095 -------------------------------------------------------------------- 1096 protocol key format 8 bytes, parity in low bit of each 1098 specific key structure copy of original key 1100 required checksum rsa-md5-des 1101 mechanism 1103 key-generation seed 8 bytes 1104 length 1106 cipher state 8 bytes (CBC initial vector) 1107 des-cbc-crc 1108 -------------------------------------------------------------------- 1109 initial cipher state copy of original key 1111 encryption function des-cbc(confounder | checksum | msg | pad, 1112 ivec=oldstate) 1113 where 1114 checksum = crc(confounder | 00000000 1115 | msg | pad) 1117 newstate = last block of des-cbc output 1119 decryption function decrypt encrypted text and verify checksum 1121 newstate = last block of ciphertext 1123 default string-to-key empty string 1124 params 1126 pseudo-random function des-cbc(md5(input-string), ivec=0) 1128 key generation functions: 1130 string-to-key des_string_to_key 1132 random-to-key copy input, then fix parity bits 1134 key-derivation identity 1136 The des-cbc-crc encryption algorithm is assigned the etype value one 1137 (1). 1139 6.2.4. RSA MD5 Cryptographic Checksum Using DES 1141 The RSA-MD5-DES checksum calculates a keyed collision-proof checksum 1142 by prepending an 8 octet confounder before the text, applying the RSA 1143 MD5 checksum algorithm, and encrypting the confounder and the 1144 checksum using DES in cipher-block-chaining (CBC) mode using a 1145 variant of the key, where the variant is computed by eXclusive-ORing 1146 the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0. The 1147 initialization vector should be zero. The resulting checksum is 24 1148 octets long. This checksum is tamper-proof and believed to be 1149 collision-proof. 1151 rsa-md5-des 1152 ---------------------------------------------------------------- 1153 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1155 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, 1156 conf | rsa-md5(conf | msg)) 1158 verify_mic decrypt and verify rsa-md5 checksum 1160 The rsa-md5-des checksum algorithm is assigned a checksum type number 1161 of eight (8). 1163 6.2.5. RSA MD4 Cryptographic Checksum Using DES 1165 The RSA-MD4-DES checksum calculates a keyed collision-proof checksum 1166 by prepending an 8 octet confounder before the text, applying the RSA 1167 MD4 checksum algorithm [MD4-92], and encrypting the confounder and 1168 the checksum using DES in cipher-block-chaining (CBC) mode using a 1169 variant of the key, where the variant is computed by eXclusive-ORing 1170 the key with the constant 0xF0F0F0F0F0F0F0F0. [7] The initialization 1171 vector should be zero. The resulting checksum is 24 octets long. 1172 This checksum is tamper-proof and believed to be collision-proof. 1174 rsa-md4-des 1175 ---------------------------------------------------------------- 1176 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1178 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, 1179 conf | rsa-md4(conf | msg), 1180 ivec=0) 1182 verify_mic decrypt and verify rsa-md4 checksum 1184 The rsa-md4-des checksum algorithm is assigned a checksum type number 1185 of three (3). 1187 6.2.6. RSA MD4 Cryptographic Checksum Using DES alternative 1189 The RSA-MD4-DES-K checksum calculates a keyed collision-proof 1190 checksum by applying the RSA MD4 checksum algorithm and encrypting 1191 the results using DES in cipher block chaining (CBC) mode using a DES 1192 key as both key and initialization vector. The resulting checksum is 1193 16 octets long. This checksum is tamper-proof and believed to be 1194 collision-proof. Note that this checksum type is the old method for 1195 encoding the RSA-MD4-DES checksum and it is no longer recommended. 1197 rsa-md4-des-k 1198 ---------------------------------------------------------------- 1199 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1201 get_mic des-cbc(key, md4(msg), ivec=key) 1203 verify_mic decrypt, compute checksum and compare 1205 The rsa-md4-des-k checksum algorithm is assigned a checksum type 1206 number of six (6). 1208 6.2.7. DES CBC checksum 1210 The DES-MAC checksum is computed by prepending an 8 octet confounder 1211 to the plaintext, padding with zero-valued octets if necessary to 1212 bring the length to a multiple of 8 octets, performing a DES CBC-mode 1213 encryption on the result using the key and an initialization vector 1214 of zero, taking the last block of the ciphertext, prepending the same 1215 confounder and encrypting the pair using DES in cipher-block-chaining 1216 (CBC) mode using a variant of the key, where the variant is computed 1217 by eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0. The 1218 initialization vector should be zero. The resulting checksum is 128 1219 bits (16 octets) long, 64 bits of which are redundant. This checksum 1220 is tamper-proof and collision-proof. 1222 des-mac 1223 ---------------------------------------------------------------------- 1224 associated des-cbc-md5, des-cbc-md4, des-cbc-crc 1225 cryptosystem 1227 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, 1228 conf | des-mac(key, conf | msg | pad, ivec=0), 1229 ivec=0) 1231 verify_mic decrypt, compute DES MAC using confounder, compare 1233 The des-mac checksum algorithm is assigned a checksum type number of 1234 four (4). 1236 6.2.8. DES CBC checksum alternative 1238 The DES-MAC-K checksum is computed by performing a DES CBC-mode 1239 encryption of the plaintext, with zero-valued padding bytes if 1240 necessary to bring the length to a multiple of 8 octets, and using 1241 the last block of the ciphertext as the checksum value. It is keyed 1242 with an encryption key which is also used as the initialization 1243 vector. The resulting checksum is 64 bits (8 octets) long. This 1244 checksum is tamper-proof and collision-proof. Note that this 1245 checksum type is the old method for encoding the DESMAC checksum and 1246 it is no longer recommended. 1248 des-mac-k 1249 ---------------------------------------------------------------- 1250 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1252 get_mic des-mac(key, msg | pad, ivec=key) 1254 verify_mic compute MAC and compare 1256 The des-mac-k checksum algorithm is assigned a checksum type number 1257 of five (5). 1259 6.3. Triple-DES based encryption and checksum types 1261 This encryption and checksum type pair is based on the Triple DES 1262 cryptosystem in Outer-CBC mode, and the HMAC-SHA1 message 1263 authentication algorithm. 1265 A Triple DES key is the concatenation of three DES keys as described 1266 above for des-cbc-md5. A Triple DES key is generated from random 1267 data by creating three DES keys from separate sequences of random 1268 data. 1270 Encrypted data using this type must be generated as described in 1271 section 5.3. If the length of the input data is not a multiple of 1272 the block size, zero-valued octets must be used to pad the plaintext 1273 to the next eight-octet boundary. The confounder must be eight 1274 random octets (one block). 1276 The simplified profile for Triple DES, with key derivation as defined 1277 in section 5, is as follows: 1279 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd 1280 ------------------------------------------------ 1281 protocol key format 24 bytes, parity in low 1282 bit of each 1284 key-generation seed 21 bytes 1285 length 1286 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd 1287 ------------------------------------------------ 1288 hash function SHA-1 1290 HMAC output size 160 bits 1292 message block size 8 bytes 1294 default string-to-key empty string 1295 params 1297 encryption and triple-DES encrypt and 1298 decryption functions decrypt, in outer-CBC 1299 mode (cipher block size 1300 8 octets) 1302 key generation functions: 1304 random-to-key DES3random-to-key (see 1305 below) 1307 string-to-key DES3string-to-key (see 1308 below) 1310 The des3-cbc-hmac-sha1-kd encryption type is assigned the value 1311 sixteen (16). The hmac-sha1-des3-kd checksum algorithm is assigned a 1312 checksum type number of twelve (12). 1314 6.3.1. Triple DES Key Production (random-to-key, string-to-key) 1316 The 168 bits of random key data are converted to a protocol key value 1317 as follows. First, the 168 bits are divided into three groups of 56 1318 bits, which are expanded individually into 64 bits as follows: 1320 DES3random-to-key: 1321 1 2 3 4 5 6 7 p 1322 9 10 11 12 13 14 15 p 1323 17 18 19 20 21 22 23 p 1324 25 26 27 28 29 30 31 p 1325 33 34 35 36 37 38 39 p 1326 41 42 43 44 45 46 47 p 1327 49 50 51 52 53 54 55 p 1328 56 48 40 32 24 16 8 p 1330 The "p" bits are parity bits computed over the data bits. The output 1331 of the three expansions, each corrected to avoid "weak" and "semi- 1332 weak" keys as in section 6.2, are concatenated to form the protocol 1333 key value. 1335 The string-to-key function is used to transform UTF-8 passwords into 1336 DES3 keys. The DES3 string-to-key function relies on the "N-fold" 1337 algorithm and DK function, described in section 5. 1339 The n-fold algorithm is applied to the password string concatenated 1340 with a salt value. For 3-key triple DES, the operation will involve 1341 a 168-fold of the input password string, to generate an intermediate 1342 key, from which the user's long-term key will be derived with the DK 1343 function. The DES3 string-to-key function is shown here in 1344 pseudocode: 1346 DES3string-to-key(passwordString, salt, params) 1347 if (params != emptyString) 1348 error("invalid params"); 1349 s = passwordString + salt 1350 tmpKey = random-to-key(168-fold(s)) 1351 key = DK (tmpKey, KerberosConstant) 1353 Weak key checking is performed in the random-to-key and DK 1354 operations. The KerberosConstant value is the byte string {0x6b 0x65 1355 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the ASCII 1356 encoding for the string "kerberos". 1358 7. Use of Kerberos encryption outside this specification 1360 Several Kerberos-based application protocols and preauthentication 1361 systems have been designed and deployed that perform encryption and 1362 message integrity checks in various ways. While in some cases there 1363 may be good reason for specifying these protocols in terms of 1364 specific encryption or checksum algorithms, we anticipate that in 1365 many cases this will not be true, and more generic approaches 1366 independent of particular algorithms will be desirable. Rather than 1367 having each protocol designer reinvent schemes for protecting data, 1368 using multiple keys, etc, we have attempted to present in this 1369 section a general framework that should be sufficient not only for 1370 the Kerberos protocol itself but also for many preauthentication 1371 systems and application protocols, while trying to avoid some of the 1372 assumptions that can work their way into such protocol designs. 1374 Some problematic assumptions we've seen (and sometimes made) include: 1375 that a random bitstring is always valid as a key (not true for DES 1376 keys with parity); that the basic block encryption chaining mode 1377 provides no integrity checking, or can easily be separated from such 1378 checking (not true for many modes in development that do both 1379 simultaneously); that a checksum for a message always results in the 1380 same value (not true if a confounder is incorporated); that an 1381 initial vector is used (may not be true if a block cipher in CBC mode 1382 is not in use). 1384 Such assumptions, while they may hold for any given set of encryption 1385 and checksum algorithms, may not be true of the next algorithms to be 1386 defined, leaving the application protocol unable to make use of those 1387 algorithms without updates to its specification. 1389 The Kerberos protocol uses only the attributes and operations 1390 described in sections 3 and 4. Preauthentication systems and 1391 application protocols making use of Kerberos are encouraged to use 1392 them as well. The specific key and string-to-key parameters should 1393 generally be treated as opaque. While the string-to-key parameters 1394 are manipulated as an octet string, the representation for the 1395 specific key structure is implementation-defined; it may not even be 1396 a single object. 1398 While we don't recommend it, some application protocols will 1399 undoubtedly continue to use the key data directly, even if only in 1400 some of the currently existing protocol specifications. An 1401 implementation intended to support general Kerberos applications may 1402 therefore need to make the key data available, as well as the 1403 attributes and operations described in sections 3 and 4. [8] 1405 8. Assigned Numbers 1407 The following encryption type numbers are already assigned or 1408 reserved for use in Kerberos and related protocols. 1410 encryption type etype section or comment 1411 ----------------------------------------------------------------- 1412 des-cbc-crc 1 6.2.3 1413 des-cbc-md4 2 6.2.2 1414 des-cbc-md5 3 6.2.1 1415 [reserved] 4 1416 des3-cbc-md5 5 1417 [reserved] 6 1418 des3-cbc-sha1 7 1419 dsaWithSHA1-CmsOID 9 (pkinit) 1420 md5WithRSAEncryption-CmsOID 10 (pkinit) 1421 sha1WithRSAEncryption-CmsOID 11 (pkinit) 1422 rc2CBC-EnvOID 12 (pkinit) 1423 rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5) 1424 rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0) 1425 des-ede3-cbc-Env-OID 15 (pkinit) 1426 des3-cbc-sha1-kd 16 6.3 1427 aes128-cts-hmac-sha1-96 17 [KRB5-AES] 1428 aes256-cts-hmac-sha1-96 18 [KRB5-AES] 1429 rc4-hmac 23 (Microsoft) 1430 rc4-hmac-exp 24 (Microsoft) 1431 subkey-keymaterial 65 (opaque; PacketCable) 1433 (The "des3-cbc-sha1" assignment is a deprecated version using no key 1434 derivation. It should not be confused with des3-cbc-sha1-kd.) 1436 Several numbers have been reserved for use in encryption systems not 1437 defined here. Encryption type numbers have unfortunately been 1438 overloaded on occasion in Kerberos-related protocols, so some of the 1439 reserved numbers do not and will not correspond to encryption systems 1440 fitting the profile presented here. 1442 The following checksum type numbers are assigned or reserved. As 1443 with encryption type numbers, some overloading of checksum numbers 1444 has occurred. 1446 Checksum type sumtype checksum section or 1447 value size reference 1448 ---------------------------------------------------------------------- 1449 CRC32 1 4 6.1.3 1450 rsa-md4 2 16 6.1.2 1451 rsa-md4-des 3 24 6.2.5 1452 des-mac 4 16 6.2.7 1453 des-mac-k 5 8 6.2.8 1454 rsa-md4-des-k 6 16 6.2.6 1455 rsa-md5 7 16 6.1.1 1456 rsa-md5-des 8 24 6.2.4 1457 rsa-md5-des3 9 24 ?? 1458 sha1 (unkeyed) 10 20 ?? 1459 hmac-sha1-des3-kd 12 20 6.3 1460 hmac-sha1-des3 13 20 ?? 1461 sha1 (unkeyed) 14 20 ?? 1462 hmac-sha1-96-aes128 15 20 [KRB5-AES] 1463 hmac-sha1-96-aes256 16 20 [KRB5-AES] 1464 [reserved] 0x8003 ? [GSS-KRB5] 1466 Encryption and checksum type numbers are signed 32-bit values. Zero 1467 is invalid, and negative numbers are reserved for local use. All 1468 standardized values must be positive. 1470 9. Implementation Notes 1472 The "interface" described here is the minimal information that must 1473 be defined to make a cryptosystem useful within Kerberos in an 1474 interoperable fashion. Despite the functional notation used in some 1475 places, it is not an attempt to define an API for cryptographic 1476 functionality within Kerberos. Actual implementations providing 1477 clean APIs will probably find it useful to make additional 1478 information available, which should be possible to derive from a 1479 specification written to the framework given here. For example, an 1480 application designer may wish to determine the largest number of 1481 bytes that can be encrypted without overflowing a certain size output 1482 buffer, or conversely, the maximum number of bytes that might be 1483 obtained by decrypting a ciphertext message of a given size. (In 1484 fact, an implementation of the GSS-API Kerberos mechanism [GSS-KRB5] 1485 will require some of these.) 1487 The presence of a mechanism in this document should not be taken as 1488 an indication that it must be implemented for compliance with any 1489 specification; required mechanisms will be specified elsewhere. 1490 Indeed, some of the mechanisms described here for backwards 1491 compatibility are now considered rather weak for protecting critical 1492 data. 1494 10. Security Considerations 1496 Recent years have brought advancements in the ability to perform 1497 large-scale attacks against DES, to such a degree that it is not 1498 considered a strong encryption mechanism any longer; triple-DES is 1499 generally preferred in its place, despite the poorer performance. 1500 See [ESP-DES] for a summary of some of the potential attacks, and 1501 [EFF-DES] for a detailed discussion of the implementation of 1502 particular attack. However, most Kerberos implementations still have 1503 DES as their primary interoperable encryption type. 1505 DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of 1506 single-DES here avoids them. However, DES also has 48 'possibly- 1507 weak' keys [Schneier96] (note that the tables in many editions of the 1508 reference contains errors) which are not avoided. 1510 DES weak keys are keys with the property that E1(E1(P)) = P (where E1 1511 denotes encryption of a single block with key 1). DES semi-weak keys 1512 or "dual" keys are pairs of keys with the property that E1(P) = 1513 D2(P), and thus E2(E1(P)) = P. Because of the use of CBC mode and 1514 leading random confounder, however, these properties are unlikely to 1515 present a security problem. 1517 Many of the choices concerning when weak-key corrections are 1518 performed relate more to compatibility with existing implementations 1519 than to any risk analysis. 1521 While checks are also done for the component DES keys in a triple-DES 1522 key, the nature of the weak keys is such that it is extremely 1523 unlikely that they will weaken the triple-DES encryption -- only 1524 slightly more likely than having the middle of the three sub-keys 1525 match one of the other two, which effectively converts the encryption 1526 to single-DES, which is a case we make no effort to avoid. 1528 The true CRC-32 checksum is not collision-proof; an attacker could 1529 use a probabilistic chosen-plaintext attack to generate a valid 1530 message even if a confounder is used [SG92]. The use of collision- 1531 proof checksums is of course recommended for environments where such 1532 attacks represent a significant threat. The "simplifications" (read: 1533 bugs) introduced when CRC-32 was implemented for Kerberos cause 1534 leading zeros to effectively be ignored, so messages differing only 1535 in leading zero bits will have the same checksum. 1537 [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm. 1538 Unlike [IPSEC-HMAC], the triple-DES specification here does not use 1539 the suggested truncation of the HMAC output. As pointed out in 1540 [IPSEC-HMAC], SHA-1 was not developed to be used as a keyed hash 1541 function, which is a criterion of HMAC. [HMAC-TEST] contains test 1542 vectors for HMAC-SHA-1. 1544 The mit_des_string_to_key function was originally constructed with 1545 the assumption that all input would be ASCII; it ignores the top bit 1546 of each input byte. Folding with XOR is also not an especially good 1547 mixing mechanism in terms of preserving randomness. 1549 The n-fold function used in the string-to-key operation for des3-cbc- 1550 hmac-sha1-kd was designed to cause each bit of input to contribute 1551 equally to the output; it was not designed to maximize or equally 1552 distribute randomness in the input, and there are conceivable cases 1553 of partially structured input where randomness may be lost. This 1554 should only be an issue for highly structured passwords, however. 1556 [RFC1851] discusses the relative strength of triple-DES encryption. 1557 The relative slow speed of triple-DES encryption may also be an issue 1558 for some applications. 1560 In [Bellovin91], there is a suggestion that analyses of encryption 1561 schemes should include a model of an attacker capable of submitting 1562 known plaintexts to be encrypted with an unknown key, as well as 1563 being able to perform many types of operations on known protocol 1564 messages. Recent experiences with the chosen-plaintext attacks on 1565 Kerberos version 4 bear out the value of this suggestion. 1567 The use of unkeyed encrypted checksums, such as those used in the 1568 single-DES cryptosystems specified in [Kerb1510], allows for cut-and- 1569 paste attacks, especially if a confounder is not used. In addition, 1570 unkeyed encrypted checksums are vulnerable to chosen-plaintext 1571 attacks: an attacker with access to an encryption oracle can easily 1572 encrypt the required unkeyed checksum along with the chosen 1573 plaintext. [Bellovin99] These weaknesses, combined with a common 1574 implementation design choice described below, allow for a cross- 1575 protocol attack from version 4 to version 5. 1577 The use of a random confounder is an important means of preventing an 1578 attacker from making effective use of protocol exchanges as an 1579 encryption oracle. In Kerberos version 4, the encryption of constant 1580 plaintext to constant ciphertext makes an effective encryption oracle 1581 for an attacker. The use of random confounders in [Kerb1510] 1582 frustrates this sort of chosen-plaintext attack. 1584 Using the same key for multiple purposes can enable or increase the 1585 scope of chosen-plaintext attacks. Some software which implements 1586 both versions 4 and 5 of the Kerberos protocol uses the same keys for 1587 both versions of the protocol. This enables the encryption oracle of 1588 version 4 to be used to attack version 5. Vulnerabilities such as 1589 this cross-protocol attack reinforce the wisdom of not using a key 1590 for multiple purposes. 1592 This document, like the Kerberos protocol, completely ignores the 1593 notion of limiting the amount of data a key may be used with to a 1594 quantity based on the robustness of the algorithm or size of the key. 1595 It is assumed that any defined algorithms and key sizes will be 1596 strong enough to support very large amounts of data, or they will be 1597 deprecated once significant attacks are known. 1599 This document also places no bounds on the amount of data that can be 1600 handled in various operations. In order to avoid denial of service 1601 attacks, implementations will probably want to restrict message sizes 1602 at some higher level. 1604 11. IANA Considerations 1606 Two registries for numeric values should be created: Kerberos 1607 Encryption Type Numbers and Kerberos Checksum Type Numbers. These 1608 are signed 32-bit values in twos-complement form. Positive values up 1609 to 2**31-1 inclusive should be assigned only for algorithms specified 1610 in accordance with this specification for use with Kerberos or 1611 related protocols. Negative values through -2**31 are for private 1612 use; local and experimental algorithms should use these values. Zero 1613 is reserved and may not be assigned. 1615 Positive encryption and checksum type numbers may be assigned 1616 following either of two policies described in [BCP26]. 1618 Standards-track specifications may be assigned values under the 1619 Standards Action policy. 1621 Specifications in Informational RFCs may be assigned values after 1622 Expert Review. A non-IETF specification may be assigned values by 1623 publishing an Informational or standards-track RFC referencing the 1624 external specification; that specification must be public and 1625 published in some permanent record much like the IETF RFCs. It is 1626 highly desirable, though not required, that the full specification be 1627 published as an IETF RFC. 1629 Smaller encryption type values, which encode to smaller octet strings 1630 under ASN.1, should be used for IETF standards-track mechanisms, and 1631 much higher values (hex 0x1000000 and above) for other mechanisms. 1632 No other guidance into allocation order is given. 1634 Draft IETF specifications should not include values for encryption 1635 and checksum type numbers. Instead, they should indicate that values 1636 would be assigned by IANA when the document is approved as an RFC. 1637 For development and interoperability testing, values in the private- 1638 use range (negative values) may be used, but should not be included 1639 in the draft specification. 1641 Each registered value should have an associated unique name to refer 1642 to it by. The lists given in section 8 should be used as an initial 1643 registry; they include reservations for specifications in progress in 1644 parallel with this document, and for certain other values believed to 1645 be in use already. 1647 12. Acknowledgments 1649 This document is an extension of the encryption specification 1650 included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much 1651 of the text of the background, concepts, and DES specifications are 1652 drawn directly from that document. 1654 The abstract framework presented in this document was put together by 1655 Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn, 1656 and Tom Yu, and the details were refined several times based on 1657 comments from John Brezak and others. 1659 Marc Horowitz wrote the original specification of triple-DES and key 1660 derivation in a pair of Internet Drafts (under the names draft- 1661 horowitz-key-derivation and draft-horowitz-kerb-key-derivation) which 1662 were later folded into a draft revision of [Kerb1510], from which 1663 this document was later split off. 1665 Tom Yu provided the text describing the modifications to the standard 1666 CRC algorithm as Kerberos implementations actually use it, and some 1667 of the Security Considerations section. 1669 Miroslav Jurisic provided information for one of the UTF-8 test cases 1670 for the string-to-key functions. 1672 Marcus Watts noticed some errors in earlier drafts, and pointed out 1673 that the simplified profile could easily be modified to support 1674 cipher text stealing modes. 1676 Simon Josefsson contributed some clarifications to the DES "CBC 1677 checksum", string-to-key and weak key descriptions, and some test 1678 vectors. 1680 Simon Josefsson, Louis LeVay and others also caught some errors in 1681 earlier drafts. 1683 A. Test vectors 1685 This section provides test vectors for various functions defined or 1686 described in this document. For convenience, most inputs are ASCII 1687 strings, though some UTF-8 samples are be provided for string-to-key 1688 functions. Keys and other binary data are specified as hexadecimal 1689 strings. 1691 A.1. n-fold 1693 The n-fold function is defined in section 5.1. As noted there, the 1694 sample vector in the original paper defining the algorithm appears to 1695 be incorrect. Here are some test cases provided by Marc Horowitz and 1696 Simon Josefsson: 1698 64-fold("012345") = 1699 64-fold(303132333435) = be072631276b1955 1701 56-fold("password") = 1702 56-fold(70617373776f7264) = 78a07b6caf85fa 1704 64-fold("Rough Consensus, and Running Code") = 1705 64-fold(526f75676820436f6e73656e7375732c20616e642052756e 1706 6e696e6720436f6465) = bb6ed30870b7f0e0 1708 168-fold("password") = 1709 168-fold(70617373776f7264) = 1710 59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e 1712 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY" 1713 192-fold(4d41535341434856534554545320494e5354495456544520 1714 4f4620544543484e4f4c4f4759) = 1715 db3b0d8f0b061e603282b308a50841229ad798fab9540c1b 1717 168-fold("Q") = 1718 168-fold(51) = 1719 518a54a2 15a8452a 518a54a2 15a8452a 1720 518a54a2 15 1722 168-fold("ba") = 1723 168-fold(6261) = 1724 fb25d531 ae897449 9f52fd92 ea9857c4 1725 ba24cf29 7e 1727 Here are some additional values corresponding to folded values of the 1728 string "kerberos"; the 64-bit form is used in the des3 string-to-key 1729 (section 6.3.1). 1731 64-fold("kerberos") = 1732 6b657262 65726f73 1733 128-fold("kerberos") = 1734 6b657262 65726f73 7b9b5b2b 93132b93 1735 168-fold("kerberos") = 1736 8372c236 344e5f15 50cd0747 e15d62ca 1737 7a5a3bce a4 1738 256-fold("kerberos") = 1739 6b657262 65726f73 7b9b5b2b 93132b93 1740 5c9bdcda d95c9899 c4cae4de e6d6cae4 1742 Note that the initial octets exactly match the input string when the 1743 output length is a multiple of the input length. 1745 A.2. mit_des_string_to_key 1747 The function mit_des_string_to_key is defined in section 6.2. We 1748 present here several test values, with some of the intermediate 1749 results. The fourth test demonstrates the use of UTF-8 with three 1750 characters. The last two tests are specifically constructed so as to 1751 trigger the weak-key fixups for the intermediate key produced by fan- 1752 folding; we have no test cases that cause such fixups for the final 1753 key. 1755 UTF-8 encodings used in test vector: 1756 eszett C3 9F s-caron C5 A1 c-acute C4 87 1757 g-clef F0 9D 84 9E 1759 Test vector: 1761 salt: "ATHENA.MIT.EDUraeburn" 1762 415448454e412e4d49542e4544557261656275726e 1763 password: "password" 70617373776f7264 1764 fan-fold result: c01e38688ac86c2e 1765 intermediate key: c11f38688ac86d2f 1766 DES key: cbc22fae235298e3 1768 salt: "WHITEHOUSE.GOVdanny" 5748495445484f5553452e474f5664616e6e79 1769 password: "potatoe" 706f7461746f65 1770 fan-fold result: a028944ee63c0416 1771 intermediate key: a129944fe63d0416 1772 DES key: df3d32a74fd92a01 1774 salt: "EXAMPLE.COMpianist" 4558414D504C452E434F4D7069616E697374 1775 password: g-clef f09d849e 1776 fan-fold result: 3c4a262c18fab090 1777 intermediate key: 3d4a262c19fbb091 1778 DES key: 4ffb26bab0cd9413 1779 salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute 1780 415448454e412e4d49542e4544554a757269c5a169c487 1781 password: eszett c39f 1782 fan-fold result: b8f6c40e305afc9e 1783 intermediate key: b9f7c40e315bfd9e 1784 DES key: 62c81a5232b5e69d 1786 salt: "AAAAAAAA" 4141414141414141 1787 password: "11119999" 3131313139393939 1788 fan-fold result: e0e0e0e0f0f0f0f0 1789 intermediate key: e0e0e0e0f1f1f101 1790 DES key: 984054d0f1a73e31 1792 salt: "FFFFAAAA" 4646464641414141 1793 password: "NNNN6666" 4e4e4e4e36363636 1794 fan-fold result: 1e1e1e1e0e0e0e0e 1795 intermediate key: 1f1f1f1f0e0e0efe 1796 DES key: c4bf6b25adf7a4f8 1798 This trace provided by Simon Josefsson shows the intermediate 1799 processing stages of one of the test inputs: 1801 string_to_key (des-cbc-md5, string, salt) 1802 ;; string: 1803 ;; `password' (length 8 bytes) 1804 ;; 70 61 73 73 77 6f 72 64 1805 ;; salt: 1806 ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes) 1807 ;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61 1808 ;; 65 62 75 72 6e 1809 des_string_to_key (string, salt) 1810 ;; String: 1811 ;; `password' (length 8 bytes) 1812 ;; 70 61 73 73 77 6f 72 64 1813 ;; Salt: 1814 ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes) 1815 ;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61 1816 ;; 65 62 75 72 6e 1817 odd = 1; 1818 s = string | salt; 1819 tempstring = 0; /* 56-bit string */ 1820 pad(s); /* with nulls to 8 byte boundary */ 1821 ;; s = pad(string|salt): 1822 ;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00' 1823 ;; (length 32 bytes) 1824 ;; 70 61 73 73 77 6f 72 64 41 54 48 45 4e 41 2e 4d 1825 ;; 49 54 2e 45 44 55 72 61 65 62 75 72 6e 00 00 00 1826 for (8byteblock in s) { 1827 ;; loop iteration 0 1828 ;; 8byteblock: 1829 ;; `password' (length 8 bytes) 1830 ;; 70 61 73 73 77 6f 72 64 1831 ;; 01110000 01100001 01110011 01110011 01110111 01101111 1832 ;; 01110010 01100100 1833 56bitstring = removeMSBits(8byteblock); 1834 ;; 56bitstring: 1835 ;; 1110000 1100001 1110011 1110011 1110111 1101111 1836 ;; 1110010 1100100 1837 if (odd == 0) reverse(56bitstring); ;; odd=1 1838 odd = ! odd 1839 tempstring = tempstring XOR 56bitstring; 1840 ;; tempstring 1841 ;; 1110000 1100001 1110011 1110011 1110111 1101111 1842 ;; 1110010 1100100 1844 for (8byteblock in s) { 1845 ;; loop iteration 1 1846 ;; 8byteblock: 1847 ;; `ATHENA.M' (length 8 bytes) 1848 ;; 41 54 48 45 4e 41 2e 4d 1849 ;; 01000001 01010100 01001000 01000101 01001110 01000001 1850 ;; 00101110 01001101 1851 56bitstring = removeMSBits(8byteblock); 1852 ;; 56bitstring: 1853 ;; 1000001 1010100 1001000 1000101 1001110 1000001 1854 ;; 0101110 1001101 1855 if (odd == 0) reverse(56bitstring); ;; odd=0 1856 reverse(56bitstring) 1857 ;; 56bitstring after reverse 1858 ;; 1011001 0111010 1000001 0111001 1010001 0001001 1859 ;; 0010101 1000001 1860 odd = ! odd 1861 tempstring = tempstring XOR 56bitstring; 1862 ;; tempstring 1863 ;; 0101001 1011011 0110010 1001010 0100110 1100110 1864 ;; 1100111 0100101 1866 for (8byteblock in s) { 1867 ;; loop iteration 2 1868 ;; 8byteblock: 1869 ;; `IT.EDUra' (length 8 bytes) 1870 ;; 49 54 2e 45 44 55 72 61 1871 ;; 01001001 01010100 00101110 01000101 01000100 01010101 1872 ;; 01110010 01100001 1873 56bitstring = removeMSBits(8byteblock); 1874 ;; 56bitstring: 1875 ;; 1001001 1010100 0101110 1000101 1000100 1010101 1876 ;; 1110010 1100001 1877 if (odd == 0) reverse(56bitstring); ;; odd=1 1878 odd = ! odd 1879 tempstring = tempstring XOR 56bitstring; 1880 ;; tempstring 1881 ;; 1100000 0001111 0011100 0001111 1100010 0110011 1882 ;; 0010101 1000100 1884 for (8byteblock in s) { 1885 ;; loop iteration 3 1886 ;; 8byteblock: 1887 ;; `eburn\x00\x00\x00' (length 8 bytes) 1888 ;; 65 62 75 72 6e 00 00 00 1889 ;; 01100101 01100010 01110101 01110010 01101110 00000000 1890 ;; 00000000 00000000 1891 56bitstring = removeMSBits(8byteblock); 1892 ;; 56bitstring: 1893 ;; 1100101 1100010 1110101 1110010 1101110 0000000 1894 ;; 0000000 0000000 1895 if (odd == 0) reverse(56bitstring); ;; odd=0 1896 reverse(56bitstring) 1897 ;; 56bitstring after reverse 1898 ;; 0000000 0000000 0000000 0111011 0100111 1010111 1899 ;; 0100011 1010011 1900 odd = ! odd 1901 tempstring = tempstring XOR 56bitstring; 1902 ;; tempstring 1903 ;; 1100000 0001111 0011100 0110100 1000101 1100100 1904 ;; 0110110 0010111 1906 for (8byteblock in s) { 1907 } 1908 ;; for loop terminated 1910 tempkey = key_correction(add_parity_bits(tempstring)); 1911 ;; tempkey 1912 ;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes) 1913 ;; c1 1f 38 68 8a c8 6d 2f 1914 ;; 11000001 00011111 00111000 01101000 10001010 11001000 1915 ;; 01101101 00101111 1917 key = key_correction(DES-CBC-check(s,tempkey)); 1918 ;; key 1919 ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes) 1920 ;; cb c2 2f ae 23 52 98 e3 1921 ;; 11001011 11000010 00101111 10101110 00100011 01010010 1922 ;; 10011000 11100011 1924 ;; string_to_key key: 1925 ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes) 1926 ;; cb c2 2f ae 23 52 98 e3 1928 A.3. DES3 DR and DK 1930 These tests show the derived-random and derived-key values for the 1931 des3-hmac-sha1-kd encryption scheme, using the DR and DK functions 1932 defined in section 6.3.1. The input keys were randomly generated; 1933 the usage values are from this specification. 1935 key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92 1936 usage: 0000000155 1937 DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705 1938 DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd 1940 key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2 1941 usage: 00000001aa 1942 DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2 1943 DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207 1945 key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc 1946 usage: 0000000155 1947 DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb 1948 DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf 1950 key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5 1951 usage: 00000001aa 1952 DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70 1953 DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e 1954 key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb 1955 usage: 6b65726265726f73 ("kerberos") 1956 DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da 1957 DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43 1959 key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da 1960 usage: 0000000155 1961 DR: 348056ec98fcc517171d2b4d7a9493af482d999175 1962 DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7 1964 key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c 1965 usage: 00000001aa 1966 DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5 1967 DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1 1969 key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443 1970 usage: 0000000155 1971 DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a 1972 DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49 1974 key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016 1975 usage: 00000001aa 1976 DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec 1977 DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d 1979 A.4. DES3string_to_key 1981 These are the keys generated for some of the above input strings for 1982 triple-DES with key derivation as defined in section 6.3.1. 1984 salt: "ATHENA.MIT.EDUraeburn" 1985 passwd: "password" 1986 key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e 1988 salt: "WHITEHOUSE.GOVdanny" 1989 passwd: "potatoe" 1990 key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a 1992 salt: "EXAMPLE.COMbuckaroo" 1993 passwd: "penny" 1994 key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a 1996 salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute 1997 passwd: eszett 1998 key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0 1999 salt: "EXAMPLE.COMpianist" 2000 passwd: g-clef 2001 key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19 2003 A.5. Modified CRC-32 2005 Below are modified-CRC32 values for various ASCII and octet strings. 2006 Only the printable ASCII characters are checksummed, no C-style 2007 trailing zero-valued octet. The 32-bit modified CRC and the sequence 2008 of output bytes as used in Kerberos are shown. (The octet values are 2009 separated here to emphasize that they are octet values and not 32-bit 2010 numbers, which will be the most convenient form for manipulation in 2011 some implementations. The bit and byte order used internally for 2012 such a number is irrelevant; the octet sequence generated is what is 2013 important.) 2015 mod-crc-32("foo") = 33 bc 32 73 2016 mod-crc-32("test0123456789") = d6 88 3e b8 2017 mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3 2018 mod-crc-32(8000) = 4b 98 83 3b 2019 mod-crc-32(0008) = 32 88 db 0e 2020 mod-crc-32(0080) = 20 83 b8 ed 2021 mod-crc-32(80) = 20 83 b8 ed 2022 mod-crc-32(80000000) = 3b b6 59 ed 2023 mod-crc-32(00000001) = 96 30 07 77 2025 B. Significant Changes from RFC 1510 2027 The encryption and checksum mechanism profiles are new. The old 2028 specification defined a few operations for various mechanisms, but 2029 didn't outline what should be required of new mechanisms in terms of 2030 abstract properties, nor how to ensure that a mechanism specification 2031 is complete enough for interoperability between implementations. The 2032 new profiles do differ from the old specification in a few ways: 2034 Some message definitions in [Kerb1510] could be read as permitting 2035 the initial vector to be specified by the application; the text 2036 was too vague. It is specifically not permitted in this 2037 specification. Some encryption algorithms may not use 2038 initialization vectors, so relying on chosen, secret 2039 initialization vectors for security is unwise. Also, the 2040 prepended confounder in the existing algorithms is roughly 2041 equivalent to a per-message initialization vector that is revealed 2042 in encrypted form. However, carrying state across from one 2043 encryption to another is explicitly permitted through the opaque 2044 "cipher state" object. 2046 The use of key derivation is new. 2048 Several new methods are introduced, including generation of a key 2049 in wire-protocol format from random input data. 2051 The means for influencing the string-to-key algorithm are laid out 2052 more clearly. 2054 Triple-DES support is new. 2056 The pseudo-random function is new. 2058 The des-cbc-crc, DES string-to-key and CRC descriptions have been 2059 updated to align them with existing implementations. 2061 [Kerb1510] had no indication what character set or encoding might be 2062 used for pass phrases and salts. 2064 In [Kerb1510], key types, encryption algorithms and checksum 2065 algorithms were only loosely associated, and the association was not 2066 well described. In this specification, key types and encryption 2067 algorithms have a one-to-one correspondence, and associations between 2068 encryption and checksum algorithms are described so that checksums 2069 can be computed given negotiated keys, without requiring further 2070 negotiation for checksum types. 2072 Notes 2074 [1] While Message Authentication Code (MAC) or Message Integrity 2075 Check (MIC) would be more appropriate terms for many of the 2076 uses in this document, we continue to use the term "checksum" 2077 for historical reasons. 2079 [2] Extending CBC mode across messages would be one obvious 2080 example of this chaining. Another might be the use of 2081 counter mode, with a counter randomly initialized and 2082 attached to the ciphertext; a second message could continue 2083 incrementing the counter when chaining the cipher state, thus 2084 avoiding having to transmit another counter value. However, 2085 this chaining is only useful for uninterrupted, ordered 2086 sequences of messages. 2088 [3] In the case of Kerberos, the encrypted objects will generally 2089 be ASN.1 DER encodings, which contain indications of their 2090 length in the first few octets. 2092 [4] As of the time of this writing, some new modes of operation 2093 have been proposed, some of which may permit encryption and 2094 integrity protection simultaneously. After some of these 2095 proposals have been subjected to adequate analysis, we may 2096 wish to formulate a new simplified profile based on one of 2097 them. 2099 [5] It should be noted that the sample vector in Appendix B.2 of 2100 the original paper appears to be incorrect. Two independent 2101 implementations from the specification (one in C by Marc 2102 Horowitz, and another in Scheme by Bill Sommerfeld) agree on 2103 a value different from that in [Blumenthal96]. 2105 [6] For example, in MIT's implementation of [Kerb1510], the rsa- 2106 md5 unkeyed checksum of application data may be included in 2107 an authenticator encrypted in a service's key; since rsa-md5 2108 is believed to be collision-proof, even if the application 2109 data is exposed to an attacker, it cannot be modified without 2110 causing the checksum verification to fail. 2112 [7] A variant of the key is used to limit the use of a key to a 2113 particular function, separating the functions of generating a 2114 checksum from other encryption performed using the session 2115 key. The constant 0xF0F0F0F0F0F0F0F0 was chosen because it 2116 maintains key parity. The properties of DES precluded the 2117 use of the complement. The same constant is used for similar 2118 purpose in the Message Integrity Check in the Privacy 2119 Enhanced Mail standard. 2121 [8] Perhaps one of the more common reasons for directly 2122 performing encryption is direct control over the negotiation 2123 and to select a "sufficiently strong" encryption algorithm 2124 (whatever that means in the context of a given application). 2125 While Kerberos directly provides no facility for negotiating 2126 encryption types between the application client and server, 2127 there are other means for accomplishing similar goals. For 2128 example, requesting only "strong" session key types from the 2129 KDC, and assuming that the type actually returned by the KDC 2130 will be understood and supported by the application server. 2132 Normative References 2134 [Bellare98] 2135 Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway, 2136 "Relations Among Notions of Security for Public-Key Encryption 2137 Schemes". Extended abstract published in Advances in Cryptology- 2138 Crypto 98 Proceedings, Lecture Notes in Computer Science Vol. 2139 1462, H. Krawcyzk ed., Springer-Verlag, 1998. 2141 [Blumenthal96] 2142 Blumenthal, U., and S. Bellovin, "A Better Key Schedule for DES- 2143 Like Ciphers", Proceedings of PRAGOCRYPT '96, 1996. 2144 [CRC] 2145 International Organization for Standardization, "ISO Information 2146 Processing Systems - Data Communication - High-Level Data Link 2147 Control Procedure - Frame Structure," IS 3309, 3rd Edition, 2148 October 1984. 2149 [DES77] 2150 National Bureau of Standards, U.S. Department of Commerce, "Data 2151 Encryption Standard," Federal Information Processing Standards 2152 Publication 46, Washington, DC, 1977. 2153 [DESI81] 2154 National Bureau of Standards, U.S. Department of Commerce, 2155 "Guidelines for implementing and using NBS Data Encryption 2156 Standard," Federal Information Processing Standards Publication 2157 74, Washington, DC, 1981. 2158 [DESM80] 2159 National Bureau of Standards, U.S. Department of Commerce, "DES 2160 Modes of Operation," Federal Information Processing Standards 2161 Publication 81, Springfield, VA, December 1980. 2162 [Dolev91] 2163 Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography", 2164 Proceedings of the 23rd Annual Symposium on Theory of Computing, 2165 ACM, 1991. 2166 [HMAC] 2167 Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 2168 for Message Authentication", RFC 2104, February 1997. 2169 [KRB5-AES] 2170 Raeburn, K., "AES Encyrption for Kerberos 5", RFC XXXX, Xxxxxxxx 2171 2003. 2172 [MD4-92] 2173 Rivest, R., "The MD4 Message Digest Algorithm," RFC 1320, MIT 2174 Laboratory for Computer Science, April 1992. 2175 [MD5-92] 2176 Rivest, R., "The MD5 Message Digest Algorithm," RFC 1321, MIT 2177 Laboratory for Computer Science, April 1992. 2178 [RFC2026] 2179 Bradner, S., "The Internet Standards Process -- Revisions 3," RFC 2180 2026, October 1996. 2181 [SG92] 2182 Stubblebine, S., and V. D. Gligor, "On Message Integrity in 2183 Cryptographic Protocols," in Proceedings of the IEEE Symposium on 2184 Research in Security and Privacy, Oakland, California, May 1992. 2186 Informative References 2188 [Bellovin91] 2189 Bellovin, S. M., and M. Merrit, "Limitations of the Kerberos 2190 Authentication System", in Proceedings of the Winter 1991 Usenix 2191 Security Conference, January, 1991. 2192 [Bellovin99] 2193 Bellovin, S. M., and D. Atkins, private communications, 1999. 2194 [EFF-DES] 2195 Electronic Frontier Foundation, "Cracking DES: Secrets of 2196 Encryption Research, Wiretap Politics, and Chip Design", O'Reilly 2197 & Associates, Inc., May 1998. 2198 [ESP-DES] 2199 Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm 2200 With Explicit IV", RFC 2405, November 1998. 2201 [GSS-KRB5] 2202 Linn, J., "The Kerberos Version 5 GSS-API Mechanism," RFC 1964, 2203 June 1996. 2204 [HMAC-TEST] 2205 Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", 2206 RFC 2202, September 1997. 2207 [IPSEC-HMAC] 2208 Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and 2209 AH", RFC 2404, November 1998. 2210 [Kerb] 2211 Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K. 2212 Raeburn, "The Kerberos Network Authentication Service (V5)", 2213 draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22, 2214 2002. Work in progress. 2215 [Kerb1510] 2216 Kohl, J., and C. Neuman, "The Kerberos Network Authentication 2217 Service (V5)", RFC 1510, September 1993. 2218 [RC5] 2219 Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and 2220 RC5-CTS Algorithms", RFC 2040, October 1996. 2221 [Schneier96] 2222 Schneier, B., "Applied Cryptography Second Edition", John Wiley & 2223 Sons, New York, NY, 1996. ISBN 0-471-12845-7. 2225 Editor's address 2227 Kenneth Raeburn 2228 Massachusetts Institute of Technology 2229 77 Massachusetts Avenue 2230 Cambridge, MA 02139 2231 raeburn@mit.edu 2233 Full Copyright Statement 2235 Copyright (C) The Internet Society (2003). All Rights Reserved. 2237 This document and translations of it may be copied and furnished to 2238 others, and derivative works that comment on or otherwise explain it 2239 or assist in its implementation may be prepared, copied, published 2240 and distributed, in whole or in part, without restriction of any 2241 kind, provided that the above copyright notice and this paragraph are 2242 included on all such copies and derivative works. However, this 2243 document itself may not be modified in any way, such as by removing 2244 the copyright notice or references to the Internet Society or other 2245 Internet organizations, except as needed for the purpose of 2246 developing Internet standards in which case the procedures for 2247 copyrights defined in the Internet Standards process must be 2248 followed, or as required to translate it into languages other than 2249 English. 2251 The limited permissions granted above are perpetual and will not be 2252 revoked by the Internet Society or its successors or assigns. 2254 This document and the information contained herein is provided on an 2255 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2256 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2257 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2258 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2259 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2261 Notes to RFC Editor 2263 Before publication of this document as an RFC, the following changes 2264 are needed: 2266 Change the reference "[KRB5-AES]" in Normative References to indicate 2267 the AES draft (draft-raeburn-krb-rijndael-krb-XX) that should be 2268 advancing to RFC at the same time. The RFC number and publication 2269 date are needed. 2271 If draft-ietf-krb-wg-kerberos-clarifications advances to RFC at the 2272 same time as this document, change the information for [Kerb] in the 2273 Informative References section as well. 2275 Change the first-page headers to indicate the RFC number, network 2276 working group, etc, as appropriate for an RFC instead of an I-D. 2278 Remove the contact-info paragraph from the Abstract. 2280 Delete this section.