idnits 2.17.1 draft-ietf-krb-wg-crypto-04.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. ** The abstract seems to contain references ([RFC2026], [Kerb]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 677 has weird spacing: '...unction tmp...' == Line 704 has weird spacing: '...osystem as d...' == Line 742 has weird spacing: '...osystem any...' == Line 760 has weird spacing: '...osystem any...' == Line 796 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 (September 19, 2003) is 7523 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 2027 == Missing Reference: 'K' is mentioned on line 237, but not defined -- Looks like a reference, but probably isn't: '2' on line 2032 -- Looks like a reference, but probably isn't: '3' on line 2041 -- Looks like a reference, but probably isn't: '4' on line 2045 -- Looks like a reference, but probably isn't: '5' on line 2052 -- Looks like a reference, but probably isn't: '6' on line 2058 -- Looks like a reference, but probably isn't: '0' on line 947 -- Looks like a reference, but probably isn't: '7' on line 2065 -- Looks like a reference, but probably isn't: '8' on line 2074 == Missing Reference: 'RFC1851' is mentioned on line 1544, 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: 8 errors (**), 0 flaws (~~), 11 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-04.txt March 19, 2003 5 expires September 19, 2003 7 Encryption and Checksum Specifications 8 for Kerberos 5 10 Abstract 12 This document describes a framework for defining encryption and 13 checksum mechanisms for use with the Kerberos protocol [Kerb], 14 defining an abstraction layer between the Kerberos protocol and 15 related protocols, and the actual mechanisms themselves. Several 16 mechanisms are also defined in this document. Some are taken from 17 RFC 1510, modified in form to fit this new framework, and 18 occasionally modified in content when the old specification was 19 incorrect. New mechanisms are presented here as well. This document 20 does NOT indicate which mechanisms may be considered "required to 21 implement". 23 Comments should be sent to the editor, or to the IETF Kerberos 24 working group (ietf-krb-wg@anl.gov). 26 Status 28 This document is an Internet-Draft and is in full conformance with 29 all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts 30 are working documents of the Internet Engineering Task Force (IETF), 31 its areas, and its working groups. Note that other groups may also 32 distribute working documents as Internet-Drafts. Internet-Drafts are 33 draft documents valid for a maximum of six months and may be updated, 34 replaced, or obsoleted by other documents at any time. It is 35 inappropriate to use Internet-Drafts as reference material or to cite 36 them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.html. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Table of Contents 46 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 47 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 48 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2 49 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Encryption algorithm profile . . . . . . . . . . . . . . . . . . 4 52 3. Checksum algorithm profile . . . . . . . . . . . . . . . . . . . 9 53 4. Simplified profile for CBC ciphers with key derivation . . . . . 10 54 4.1. A key derivation function . . . . . . . . . . . . . . . . . . . 10 55 4.2. Simplified profile parameters . . . . . . . . . . . . . . . . . 12 56 4.3. Cryptosystem profile based on simplified profile . . . . . . . 14 57 4.4. Checksum profiles based on simplified profile . . . . . . . . . 16 58 5. Profiles for Kerberos encryption and checksum algorithms . . . . 16 59 5.1. Unkeyed checksums . . . . . . . . . . . . . . . . . . . . . . . 16 60 5.2. DES-based encryption and checksum types . . . . . . . . . . . . 18 61 5.3. Triple-DES based encryption and checksum types . . . . . . . . 28 62 6. Use of Kerberos encryption outside this specification . . . . . . 30 63 7. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . . . 31 64 8. Implementation Notes . . . . . . . . . . . . . . . . . . . . . . 32 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 33 66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 34 67 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 35 68 12. Editor's address . . . . . . . . . . . . . . . . . . . . . . . . 35 69 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 36 70 A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . . . 36 71 A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 72 A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . . . . . 38 73 A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . . . . . 42 74 A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . . . . . 43 75 A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . . . . . 44 76 B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . . . 44 77 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 78 Normative References . . . . . . . . . . . . . . . . . . . . . . . . 46 79 Informative References . . . . . . . . . . . . . . . . . . . . . . . 48 80 Introduction 82 The Kerberos protocols are designed to encrypt messages of arbitrary 83 sizes, using block encryption ciphers, or less commonly, stream 84 encryption ciphers. Encryption is used to prove the identities of 85 the network entities participating in message exchanges. However, 86 nothing in the Kerberos protocol requires any specific encryption 87 algorithm be used, as long as certain operations are available in the 88 algorithm that is used. 90 The following sections specify the encryption and checksum mechanisms 91 currently defined for Kerberos, as well as a framework for defining 92 future mechanisms. The encoding, chaining, padding and other 93 requirements for each are described. Test vectors for several 94 functions are given in appendix A. 96 1. Concepts 98 Both encryption and checksum mechanisms are defined in terms of 99 profiles, detailed in later sections. Each specifies a collection of 100 operations and attributes that must be defined for a mechanism. A 101 Kerberos encryption or checksum mechanism specification is not 102 complete if it does not define all of these operations and 103 attributes. 105 An encryption mechanism must provide for confidentiality and 106 integrity of the original plaintext. (Integrity checking may be 107 achieved by incorporating a checksum, if the encryption mode does not 108 provide an integrity check itself.) It must also provide non- 109 malleability [Bellare98, Dolev91]. Use of a random confounder 110 prepended to the plaintext is recommended. It should not be possible 111 to determine if two ciphertexts correspond to the same plaintext, 112 without knowledge of the key. 114 A checksum mechanism [1] must provide proof of the integrity of the 115 associated message, and must preserve the confidentiality of the 116 message in case it is not sent in the clear. It should be infeasible 117 to find two plaintexts which have the same checksum. It is NOT 118 required that an eavesdropper be unable to determine if two checksums 119 are for the same message; it is assumed that the messages themselves 120 will be visible to any such eavesdropper. 122 Due to advances in cryptography, it is considered unwise by some 123 cryptographers to use the same key for multiple purposes. Since keys 124 are used in performing a number of different functions in Kerberos, 125 it is desirable to use different keys for each of these purposes, 126 even though we start with a single long-term or session key. 128 We do this by enumerating the different uses of keys within Kerberos, 129 and making the "usage number" an input to the encryption or checksum 130 mechanisms; this enumeration is outside the scope of this document. 131 Later sections of this document define simplified profile templates 132 for encryption and checksum mechanisms that use a key derivation 133 function applied to a CBC mode (or similar) cipher and a checksum or 134 hash algorithm. 136 We distinguish the "base key" specified by other documents from the 137 "specific key" to be used for a particular instance of encryption or 138 checksum operations. It is expected but not required that the 139 specific key will be one or more separate keys derived from the 140 original protocol key and the key usage number. The specific key 141 should not be explicitly referenced outside of this document. The 142 typical language used in other documents should be something like, 143 "encrypt this octet string using this key and this usage number"; 144 generation of the specific key and cipher state (described in the 145 next section) are implicit. The creation of a new cipher-state 146 object, or the re-use of one from a previous encryption operation, 147 may also be explicit. 149 New protocols defined in terms of the Kerberos encryption and 150 checksum types should use their own key usage values. Key usages are 151 unsigned 32 bit integers; zero is not permitted. 153 All data is assumed to be in the form of strings of octets or 8-bit 154 bytes. Environments with other byte sizes will have to emulate this 155 behavior in order to get correct results. 157 Each algorithm is assigned an encryption type (or "etype") or 158 checksum type number, for algorithm identification within the 159 Kerberos protocol. The full list of current type number assignments 160 is given in section 7. 162 2. Encryption algorithm profile 164 An encryption mechanism profile must define the following attributes 165 and operations. The operations must be defined as functions in the 166 mathematical sense: no additional or implicit inputs (such as 167 Kerberos principal names or message sequence numbers) are permitted. 169 protocol key format 170 This describes what octet string values represent valid keys. For 171 encryption mechanisms that don't have perfectly dense key spaces, 172 this will describe the representation used for encoding keys. It 173 need not describe specific values that are not valid or desirable 174 for use; such values should be avoid by all key generation 175 routines. 177 specific key structure 178 This is not a protocol format at all, but a description of the 179 keying material derived from the chosen key and used to encrypt or 180 decrypt data or compute or verify a checksum. It may, for 181 example, be a single key, a set of keys, or a combination of the 182 original key with additional data. The authors recommend using 183 one or more keys derived from the original key via one-way 184 functions. 186 required checksum mechanism 187 This indicates a checksum mechanism that must be available when 188 this encryption mechanism is used. Since Kerberos has no built in 189 mechanism for negotiating checksum mechanisms, once an encryption 190 mechanism has been decided upon, the corresponding checksum 191 mechanism can simply be used. 193 key-generation seed length, K 194 This is the length of the random bitstring needed to generate a 195 key with the encryption scheme's random-to-key function (described 196 below). This must be a fixed value so that various techniques for 197 producing a random bitstring of a given length may be used with 198 key generation functions. 200 key generation functions 201 Keys must be generated in a number of cases, from different types 202 of inputs. All function specifications must indicate how to 203 generate keys in the proper wire format, and must avoid generation 204 of keys that significantly compromise the confidentiality of 205 encrypted data, if the cryptosystem has such. Entropy from each 206 source should be preserved as much as possible. Many of the 207 inputs, while unknown, may be at least partly predictable (e.g., a 208 password string is likely to be entirely in the ASCII subset and 209 of fairly short length in many environments; a semi-random string 210 may include timestamps); the benefit of such predictability to an 211 attacker must be minimized. 213 string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key) 214 This function generates a key from two UTF-8 strings and an 215 opaque octet string. One of the strings is normally the 216 principal's pass phrase, but is in general merely a secret 217 string. The other string is a "salt" string intended to 218 produce different keys from the same password for different 219 users or realms. While the strings provided will use UTF-8 220 encoding, no specific version of Unicode should be assumed; all 221 valid UTF-8 strings should be allowed. 223 The third argument, the octet string, may be used to pass 224 mechanism-specific parameters in to this function. Since doing 225 so implies knowledge of the specific encryption system, it is 226 intended that generating non-default parameter values be an 227 uncommon operation, and that normal Kerberos applications be 228 able to treat this parameter block as an opaque object supplied 229 by the KDC or defaulted to some mechanism-specific constant 230 value. 232 This should be a one-way function, so that compromising a 233 user's key in one realm does not compromise the user's key in 234 another realm, even if the same password (but a different salt) 235 is used. 237 random-to-key (bitstring[K])->(protocol-key) 238 This function generates a key from a random bit string of a 239 specific size. It may be assumed that all the bits of the 240 input string are equally random, even though the entropy 241 present in the random source may be limited. 243 key-derivation (protocol-key, integer)->(specific-key) 244 In this function, the integer input is the key usage value as 245 described above; the usage values must be assumed to be known 246 to an attacker. The specific-key output value was described in 247 section 1. 249 string-to-key parameter format 250 This describes the format of the block of data that can be passed 251 to the string-to-key function above to configure additional 252 parameters for that function. Along with the mechanism of 253 encoding parameter values, bounds on the allowed parameters should 254 also be described to avoid allowing a spoofed KDC to compromise 255 the user's password. It may be desirable to construct the 256 encoding such that values weakening the resulting key unacceptably 257 cannot be encoded, if practical. 259 Tighter bounds might be permitted by local security policy, or to 260 avoid excess resource consumption; if so, recommended defaults for 261 those bounds should be given in the specification. The 262 description should also outline possible weaknesses that may be 263 caused by not applying bounds checks or other validation to a 264 parameter string received from the network. 266 As mentioned above, this should be considered opaque to most 267 normal applications. 269 default string-to-key parameters (octet string) 270 This default value for the "params" argument to the string-to-key 271 function is to be used when the application protocol (Kerberos or 272 otherwise) does not explicitly set the parameter value. As 273 indicated above, this parameter block should be treated as an 274 opaque object in most cases. 276 cipher state 277 This describes any information that can be carried over from one 278 encryption or decryption operation to the next, for use in 279 conjunction with a given specific key. For example, a block 280 cipher used in CBC mode may put an initial vector of one block in 281 the cipher state. Other encryption modes may track nonces or 282 other data. 284 This state must be non-empty, and must influence encryption so as 285 to require that messages be decrypted in the same order they were 286 encrypted, if the cipher state is carried over from one encryption 287 to the next. Distinguishing out-of-order or missing messages from 288 corrupted messages is not required; if desired, this can be done 289 at a higher level by including sequence numbers and not "chaining" 290 the cipher state between encryption operations. 292 The cipher state may not be reused in multiple encryption or 293 decryption operations; these operations all generate a new cipher 294 state that may be used for following operations using the same key 295 and operation. 297 The contents of the cipher state must be treated as opaque outside 298 of encryption system specifications. 300 initial cipher state (specific-key, direction)->(state) 301 This describes the generation of the initial value for the cipher 302 state if it is not being carried over from a previous encryption 303 or decryption operation. 305 This describes any initial state setup needed before encrypting 306 arbitrary amounts of data with a given specific key; the specific 307 key and the direction of operations to be performed (encrypt 308 versus decrypt) must be the only input needed for this 309 initialization. 311 This state should be treated as opaque in any uses outside of an 312 encryption algorithm definition. 314 IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what 315 degree an application protocol could exercise control over the 316 initial vector used in DES CBC operations. Some existing 317 implementations permit the setting of the initial vector. This 318 new specification does not permit application control of the 319 cipher state (beyond "initialize" and "carry over from previous 320 encryption"), since the form and content of the initial cipher 321 state can vary between encryption systems, and may not always be a 322 single block of random data. 324 New Kerberos application protocols should not assume that they can 325 control the initial vector, or that one even exists. However, a 326 general-purpose implementation may wish to provide the capability, 327 in case applications explicitly setting it are encountered. 329 encrypt (specific-key, state, octet string)->(state, octet string) 330 This function takes the specific key, cipher state, and a non- 331 empty plaintext string as input, and generates ciphertext and a 332 new cipher state as outputs. If the basic encryption algorithm 333 itself does not provide for integrity protection (as DES in CBC 334 mode does not do), then some form of MAC or checksum must be 335 included that can be verified by the receiver. Some random factor 336 such as a confounder should be included so that an observer cannot 337 know if two messages contain the same plaintext, even if the 338 cipher state and specific keys are the same. The exact length of 339 the plaintext need not be encoded, but if it is not and if padding 340 is required, the padding must be added at the end of the string so 341 that the decrypted version may be parsed from the beginning. 343 The specification of the encryption function must not only 344 indicate the precise contents of the output octet string, but also 345 the output cipher state. The application protocol may carry 346 forward the output cipher state from one encryption with a given 347 specific key to another; the effect of this "chaining" must be 348 defined. [2] 350 Assuming correctly-produced values for the specific key and cipher 351 state, no input octet string may result in an error indication. 353 decrypt (specific-key, state, octet string)->(state, octet string) 354 This function takes the specific key, cipher state, and ciphertext 355 as inputs, and verifies the integrity of the supplied ciphertext. 356 If the ciphertext's integrity is intact, this function produces 357 the plaintext and a new cipher state as outputs; otherwise, an 358 error indication must be returned, and the data discarded. 360 The result of the decryption may be longer than the original 361 plaintext, for example if the encryption mode adds padding to 362 reach a multiple of a block size. If this is the case, any extra 363 octets must be after the decoded plaintext. An application 364 protocol which needs to know the exact length of the message must 365 encode a length or recognizable "end of message" marker within the 366 plaintext. [3] 368 As with the encryption function, a correct specification for this 369 function must indicate not only the contents of the output octet 370 string, but also the resulting cipher state. 372 pseudo-random (protocol-key, octet-string)->(octet-string) 373 This pseudo-random function should generate an octet string of 374 some size that independent of the octet string input. The PRF 375 output string should be suitable for use in key generation, even 376 if the octet string input is public. It should not reveal the 377 input key, even if the output is made public. 379 These operations and attributes are all that should be required to 380 support Kerberos and various proposed preauthentication schemes. 382 A document defining a new encryption type should also describe known 383 weaknesses or attacks, so that its security may be fairly assessed, 384 and should include test vectors or other validation procedures for 385 the operations defined. Specific references to information readily 386 available elsewhere are sufficient. 388 3. Checksum algorithm profile 390 A checksum mechanism profile must define the following attributes and 391 operations: 393 associated encryption algorithm(s) 394 This indicates the types of encryption keys this checksum 395 mechanism can be used with. 397 A keyed checksum mechanism may have more than one associated 398 encryption algorithm if they share the same wire key format, 399 string-to-key function, and key derivation function. (This 400 combination means that, for example, a checksum type, key usage 401 value and password are adequate to get the specific key used to 402 compute a checksum.) 404 An unkeyed checksum mechanism can be used in conjunction with any 405 encryption type, since the key is ignored, but its use must be 406 limited to cases where the checksum itself is protected, to avoid 407 trivial attacks. 409 get_mic function 410 This function generates a MIC token for a given specific key (see 411 section 2), and message (represented as an octet string), that may 412 be used to verify the integrity of the associated message. This 413 function is not required to return the same deterministic result 414 on every use; it need only generate a token that the verify_mic 415 routine can check. 417 The output of this function will also dictate the size of the 418 checksum. 420 verify_mic function 421 Given a specific key, message, and MIC token, this function 422 ascertains whether the message integrity has been compromised. 423 For a deterministic get_mic routine, the corresponding verify_mic 424 may simply generate another checksum and compare them. 426 The get_mic and verify_mic operations must be able to handle inputs 427 of arbitrary length; if any padding is needed, the padding scheme 428 must be specified as part of these functions. 430 These operations and attributes are all that should be required to 431 support Kerberos and various proposed preauthentication schemes. 433 As with encryption mechanism definition documents, documents defining 434 new checksum mechanisms should indicate validation processes and 435 known weaknesses. 437 4. Simplified profile for CBC ciphers with key derivation 439 The profile outlines in sections 2 and 3 describes a large number of 440 operations that must be defined for encryption and checksum 441 algorithms to be used with Kerberos. We describe here a simpler 442 profile from which both encryption and checksum mechanism definitions 443 can be generated, filling in uses of key derivation in appropriate 444 places, providing integrity protection, and defining multiple 445 operations for the cryptosystem profile based on a smaller set of 446 operations given in the simplified profile. Not all of the existing 447 cryptosystems for Kerberos fit into this simplified profile, but we 448 recommend that future cryptosystems use it or something based on it. 449 [4] 451 Not all of the operations in the complete profiles are defined 452 through this mechanism; several must still be defined for each new 453 algorithm pair. 455 4.1. A key derivation function 457 Rather than define some scheme by which a "protocol key" is composed 458 of a large number of encryption keys, we use keys derived from a base 459 key to perform cryptographic operations. The base key must be used 460 only for generating the derived keys, and this derivation must be 461 non-invertible and entropy-preserving. Given these restrictions, 462 compromise of one derived key does not compromise the other subkeys. 463 Attack of the base key is limited, since it is only used for 464 derivation, and is not exposed to any user data. 466 Since the derived key has as much entropy as the base keys (if the 467 cryptosystem is good), password-derived keys have the full benefit of 468 all the entropy in the password. 470 To generate a derived key from a base key, we generate a pseudorandom 471 octet string, using an algorithm DR described below, and generate a 472 key from that octet string using a function dependent on the 473 encryption algorithm; the input length needed for that function, 474 which is also dependent on the encryption algorithm, dictates the 475 length of the string to be generated by the DR algorithm (the value 476 "k" below). These procedures are based on the key derivation in 477 [Blumenthal96]. 479 Derived Key = DK(Base Key, Well-Known Constant) 481 DK(Key, Constant) = random-to-key(DR(Key, Constant)) 483 DR(Key, Constant) = k-truncate(E(Key, Constant, 484 initial-cipher-state)) 486 Here DR is the random-octet generation function described below, and 487 DK is the key-derivation function produced from it. In this 488 construction, E(Key, Plaintext, CipherState) is a cipher, Constant is 489 a well-known constant determined by the specific usage of this 490 function, and k-truncate truncates its argument by taking the first k 491 bits. Here, k is the key generation seed length needed for the 492 encryption system. 494 The output of the DR function is a string of bits; the actual key is 495 produced by applying the cryptosystem's random-to-key operation on 496 this bitstring. 498 If the Constant is smaller than the cipher block size of E, then it 499 must be expanded with n-fold() so it can be encrypted. If the output 500 of E is shorter than k bits it is fed back into the encryption as 501 many times as necessary. The construct is as follows (where | 502 indicates concatentation): 504 K1 = E(Key, n-fold(Constant), initial-cipher-state) 505 K2 = E(Key, K1, initial-cipher-state) 506 K3 = E(Key, K2, initial-cipher-state) 507 K4 = ... 509 DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...) 511 n-fold is an algorithm which takes m input bits and ``stretches'' 512 them to form n output bits with equal contribution from each input 513 bit to the output, as described in [Blumenthal96]: 515 We first define a primitive called n-folding, which takes a 516 variable-length input block and produces a fixed-length output 517 sequence. The intent is to give each input bit approximately 518 equal weight in determining the value of each output bit. Note 519 that whenever we need to treat a string of octets as a number, the 520 assumed representation is Big-Endian -- Most Significant Byte 521 first. 523 To n-fold a number X, replicate the input value to a length that 524 is the least common multiple of n and the length of X. Before 525 each repetition, the input is rotated to the right by 13 bit 526 positions. The successive n-bit chunks are added together using 527 1's-complement addition (that is, with end-around carry) to yield 528 a n-bit result.... 530 Test vectors for n-fold are supplied in Appendix A. [5] 532 In this section, n-fold is always used to produce c bits of output, 533 where c is the cipher block size of E. 535 The size of the Constant must not be larger than c, because reducing 536 the length of the Constant by n-folding can cause collisions. 538 If the size of the Constant is smaller than c, then the Constant must 539 be n-folded to length c. This string is used as input to E. If the 540 block size of E is less than the random-to-key input size, then the 541 output from E is taken as input to a second invocation of E. This 542 process is repeated until the number of bits accumulated is greater 543 than or equal to the random-to-key input size. When enough bits have 544 been computed, the first k are taken as the random data used to 545 create the key with the algorithm-dependent random-to-key function. 547 Since the derived key is the result of one or more encryptions in the 548 base key, deriving the base key from the derived key is equivalent to 549 determining the key from a very small number of plaintext/ciphertext 550 pairs. Thus, this construction is as strong as the cryptosystem 551 itself. 553 4.2. Simplified profile parameters 555 These are the operations and attributes that must be defined: 557 protocol key format 558 string-to-key function 559 default string-to-key parameters 560 key-generation seed length, k 561 random-to-key function 562 As above for the normal encryption mechanism profile. 564 unkeyed hash algorithm, H 565 This should be a collision-resistant hash algorithm with fixed- 566 size output, suitable for use in an HMAC [HMAC]. It must support 567 inputs of arbitrary length. Its output must be at least the 568 message block size (below). 570 HMAC output size, h 571 This indicates the size of the leading substring output by the 572 HMAC function that should be used in transmitted messages. It 573 should be at least half the output size of the hash function H, 574 and at least 80 bits; it need not match the output size. 576 message block size, m 577 This is the size of the smallest units the cipher can handle in 578 the mode in which it is being used. Messages will be padded to a 579 multiple of this size. If a block cipher is used in a mode that 580 can handle messages that are not multiples of the cipher block 581 size, such as CBC mode with cipher text stealing (CTS, see [RC5]), 582 this value would be one octet. For traditional CBC mode with 583 padding, it will be the underlying cipher's block size. 585 This value must be a multiple of 8 bits (one octet). 587 encryption/decryption functions, E and D 588 These are basic encryption and decryption functions for messages 589 of sizes that are multiples of the message block size. No 590 integrity checking or confounder should be included here. These 591 functions take as input the IV or similar data, a protocol-format 592 key, and a octet string, returning a new IV and octet string. 594 The encryption function is not required to use CBC mode, but is 595 assumed to be using something with similar properties. In 596 particular, prepending a cipher-block-size confounder to the 597 plaintext should alter the entire ciphertext (comparable to 598 choosing and including a random initial vector for CBC mode). 600 The result of encrypting one cipher block (of size c, above) must 601 be deterministic, for the random octet generation function DR in 602 the previous section to work. For best security, it should also 603 be no larger than c. 605 cipher block size, c 606 This is the block size of the block cipher underlying the 607 encryption and decryption functions indicated above, used for key 608 derivation and for the size of the message confounder and initial 609 vector. (If a block cipher is not in use, some comparable 610 parameter should be determined.) It must be at least 5 octets. 612 This is not actually an independent parameter; rather, it is a 613 property of the functions E and D. It is listed here to clarify 614 the distinction between it and the message block size, m. 616 While there are still a number of properties to specify, they are 617 fewer and simpler than in the full profile. 619 4.3. Cryptosystem profile based on simplified profile 621 The above key derivation function is used to produce three 622 intermediate keys. One is used for computing checksums of 623 unencrypted data. The other two are used for encrypting and 624 checksumming plaintext to be sent encrypted. 626 The ciphertext output is the concatenation of the output of the basic 627 encryption function E and a (possibly truncated) HMAC using the 628 specified hash function H, both applied to the plaintext with a 629 random confounder prefix and sufficient padding to bring it to a 630 multiple of the message block size. When the HMAC is computed, the 631 key is used in the protocol key form. 633 Decryption is performed by removing the (partial) HMAC, decrypting 634 the remainder, and verifying the HMAC. The cipher state is an 635 initial vector, initialized to zero. 637 The substring notation "[1..h]" in the following table should be read 638 as using 1-based indexing; leading substrings are used. 640 cryptosystem from simplified profile 641 ---------------------------------------------------------------------------- 642 protocol key format As given. 644 specific key structure Three protocol-format keys: { Kc, Ke, Ki }. 646 key-generation seed As given. 647 length 649 required checksum As defined below in section 4.4. 650 mechanism 651 cryptosystem from simplified profile 652 ---------------------------------------------------------------------------- 654 cipher state initial vector (usually of length c) 656 initial cipher state all bits zero 658 encryption function conf = random string of length c 659 pad = shortest string to bring confounder 660 and plaintext to a length that's a 661 multiple of m 662 C1 = E(Ke, conf | plaintext | pad, 663 oldstate.ivec) 664 H1 = HMAC(Ki, conf | plaintext | pad) 665 ciphertext = C1 | H1[1..h] 666 newstate.ivec = last c of C1 668 decryption function (C1,H1) = ciphertext 669 P1 = D(Ke, C1, oldstate.ivec) 670 if (H1 != HMAC(Ki, P1)[1..h]) 671 report error 672 newstate.ivec = last c of C1 674 default string-to-key As given. 675 params 677 pseudo-random function tmp1 = H(octet-string) 678 tmp2 = truncate tmp1 to multiple of m 679 PRF = E(protocol-key, tmp2, initial-cipher-state) 681 key generation functions: 683 string-to-key function As given. 685 random-to-key function As given. 687 key-derivation function The "well-known constant" used for the DK 688 function is the key usage number, expressed as 689 four octets in big-endian order, followed by one 690 octet indicated below. 692 Kc = DK(base-key, usage | 0x99); 693 Ke = DK(base-key, usage | 0xAA); 694 Ki = DK(base-key, usage | 0x55); 696 4.4. Checksum profiles based on simplified profile 698 When an encryption system is defined using the simplified profile 699 given in section 4.2, a checksum algorithm may be defined for it as 700 follows: 702 checksum mechanism from simplified profile 703 -------------------------------------------------- 704 associated cryptosystem as defined above 706 get_mic HMAC(Kc, message)[1..h] 708 verify_mic get_mic and compare 710 The HMAC function and key Kc are as described in section 4.3. 712 5. Profiles for Kerberos encryption and checksum algorithms 714 These profiles describe the encryption and checksum systems defined 715 for Kerberos. The astute reader will notice that some of them do not 716 fulfull all of the requirements outlined in previous sections. These 717 systems are defined for backward compatibility; newer implementations 718 should (whenever possible) attempt to make use of encryption systems 719 which satisfy all of the profile requirements. 721 The full list of current encryption and checksum type number 722 assignments, including values currently reserved but not defined in 723 this document, is given in section 7. 725 5.1. Unkeyed checksums 727 These checksum types use no encryption keys, and thus can be used in 728 combination with any encryption type, but may only be used with 729 caution, in limited circumstances where the lack of a key does not 730 provide a window for an attack, preferably as part of an encrypted 731 message. [6] Keyed checksum algorithms are recommended. 733 5.1.1. The RSA MD5 Checksum 735 The RSA-MD5 checksum calculates a checksum using the RSA MD5 736 algorithm [MD5-92]. The algorithm takes as input an input message of 737 arbitrary length and produces as output a 128-bit (16 octet) 738 checksum. RSA-MD5 is believed to be collision-proof. 740 rsa-md5 741 ---------------------------------------------- 742 associated cryptosystem any 744 get_mic rsa-md5(msg) 746 verify_mic get_mic and compare 748 The rsa-md5 checksum algorithm is assigned a checksum type number of 749 seven (7). 751 5.1.2. The RSA MD4 Checksum 753 The RSA-MD4 checksum calculates a checksum using the RSA MD4 754 algorithm [MD4-92]. The algorithm takes as input an input message of 755 arbitrary length and produces as output a 128-bit (16 octet) 756 checksum. RSA-MD4 is believed to be collision-proof. 758 rsa-md4 759 ---------------------------------------------- 760 associated cryptosystem any 762 get_mic md4(msg) 764 verify_mic get_mic and compare 766 The rsa-md4 checksum algorithm is assigned a checksum type number of 767 two (2). 769 5.1.3. CRC-32 Checksum 771 This CRC-32 checksum calculates a checksum based on a cyclic 772 redundancy check as described in ISO 3309 [CRC], modified as 773 described below. The resulting checksum is four (4) octets in 774 length. The CRC-32 is neither keyed nor collision-proof; thus, the 775 use of this checksum is not recommended. An attacker using a 776 probabilistic chosen-plaintext attack as described in [SG92] might be 777 able to generate an alternative message that satisfies the checksum. 779 The CRC-32 checksum used in the des-cbc-crc encryption mode is 780 identical to the 32-bit FCS described in ISO 3309 with two 781 exceptions: the sum with the all-ones polynomial times x**k is 782 omitted, and the final remainder is not ones-complemented. ISO 3309 783 describes the FCS in terms of bits, while this document describes the 784 Kerberos protocol in terms of octets. To disambiguate the ISO 3309 785 definition for the purpose of computing the CRC-32 in the des-cbc-crc 786 encryption mode, the ordering of bits in each octet shall be assumed 787 to be LSB-first. Given this assumed ordering of bits within an 788 octet, the mapping of bits to polynomial coefficients shall be 789 identical to that specified in ISO 3309. 791 Test values for this modified CRC function are included in appendix 792 A.5. 794 crc32 795 ---------------------------------------------- 796 associated cryptosystem any 798 get_mic crc32(msg) 800 verify_mic get_mic and compare 802 The crc32 checksum algorithm is assigned a checksum type number of 803 one (1). 805 5.2. DES-based encryption and checksum types 807 These encryption systems encrypt information under the Data 808 Encryption Standard [DES77] using the cipher block chaining mode 809 [DESM80]. A checksum is computed as described below and placed in 810 the cksum field. DES blocks are 8 bytes. As a result, the data to 811 be encrypted (the concatenation of confounder, checksum, and message) 812 must be padded to an 8 byte boundary before encryption. The values 813 of the padding bytes are unspecified. 815 Plaintext and DES ciphertext are encoded as blocks of 8 octets which 816 are concatenated to make the 64-bit inputs for the DES algorithms. 817 The first octet supplies the 8 most significant bits (with the 818 octet's MSB used as the DES input block's MSB, etc.), the second 819 octet the next 8 bits, ..., and the eighth octet supplies the 8 least 820 significant bits. 822 Encryption under DES using cipher block chaining requires an 823 additional input in the form of an initialization vector; this vector 824 is specified for each encryption system, below. 826 The DES specifications [DESI81] identify four 'weak' and twelve 827 'semi-weak' keys; those keys shall not be used for encrypting 828 messages for use in Kerberos. The "variant keys" generated for the 829 RSA-MD5-DES, RSA-MD4-DES and DES-MAC checksum types by an exclusive- 830 or of a DES key with a hexadecimal constant are not checked for this 831 property. 833 A DES key is 8 octets of data. This consists of 56 bits of actual 834 key data, and 8 parity bits, one per octet. The key is encoded as a 835 series of 8 octets written in MSB-first order. The bits within the 836 key are also encoded in MSB order. For example, if the encryption 837 key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) 838 where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 839 are the parity bits, the first octet of the key would be 840 B1,B2,...,B7,P1 (with B1 as the most significant bit). See the 841 [DESM80] introduction for reference. 843 Encryption data format 845 The format for the data to be encrypted includes a one-block 846 confounder, a checksum, the encoded plaintext, and any necessary 847 padding, as described in the following diagram. The msg-seq field 848 contains the part of the protocol message which is to be encrypted. 850 +-----------+----------+---------+-----+ 851 |confounder | checksum | msg-seq | pad | 852 +-----------+----------+---------+-----+ 854 One generates a random confounder of one block, placing it in 855 'confounder'; zeroes out the 'checksum' field (of length appropriate 856 to exactly hold the checksum to be computed); calculates the 857 appropriate checksum over the whole sequence, placing the result in 858 'checksum'; adds the necessary padding; then encrypts using the 859 specified encryption type and the appropriate key. 861 String or random-data to key transformation 863 To generate a DES key from two UTF-8 text strings (password and 864 salt), the two strings are concatenated, password first, and the 865 result is then padded with zero-valued octets to a multiple of 8 866 octets. 868 The top bit of each octet (always zero if the password is plain 869 ASCII, as was assumed when the original specification was written) is 870 discarded, and a bitstring is formed of the remaining seven bits of 871 each octet. This bitstring is then fan-folded and eXclusive-ORed 872 with itself to produce a 56-bit string. An eight-octet key is formed 873 from this string, each octet using seven bits from the bit string, 874 leaving the least significant bit unassigned. The key is then 875 "corrected" by correcting the parity on the key, and if the key 876 matches a 'weak' or 'semi-weak' key as described in the DES 877 specification, it is eXclusive-ORed with the constant 878 0x00000000000000F0. This key is then used to generate a DES CBC 879 checksum on the initial string with the salt appended. The result of 880 the CBC checksum is then "corrected" as described above to form the 881 result which is returned as the key. 883 For purposes of the string-to-key function, the DES CBC checksum is 884 calculated by CBC encrypting a string using the key as IV and using 885 the final 8 byte block as the checksum. 887 Pseudocode follows: 889 removeMSBits(8byteblock) { 890 /* Treats a 64 bit block as 8 octets and remove the MSB in 891 each octect (in big endian mode) and concatenates the 892 result. E.g., input octet string: 893 01110000 01100001 11110011 01110011 11110111 01101111 894 11110010 01100100 895 results in output bit string: 896 1110000 1100001 1110011 1110011 1110111 1101111 897 1110010 1100100 */ 898 } 900 reverse(56bitblock) { 901 /* Treats a 56-bit block as a binary string and reverse it. 902 E.g., input string: 903 1000001 1010100 1001000 1000101 1001110 1000001 904 0101110 1001101 905 results in output string: 906 1011001 0111010 1000001 0111001 1010001 0001001 907 0010101 1000001 */ 908 } 910 add_parity_bits(56bitblock) { 911 /* Copies a 56-bit block into a 64-bit block, left shift 912 content in each octet and add DES parity bit. 913 E.g., input string: 914 1100000 0001111 0011100 0110100 1000101 1100100 915 0110110 0010111 916 results in output string: 917 11000001 00011111 00111000 01101000 10001010 11001000 918 01101101 00101111 */ 919 } 920 key_correction(key) { 921 fixparity(key); 922 if (is_weak_key(key)) 923 key = key XOR 0xF0; 924 return(key); 925 } 927 mit_des_string_to_key(string,salt) { 928 odd = 1; 929 s = string | salt; 930 tempstring = 0; /* 56-bit string */ 931 pad(s); /* with nulls to 8 byte boundary */ 932 for (8byteblock in s) { 933 56bitstring = removeMSBits(8byteblock); 934 if (odd == 0) reverse(56bitstring); 935 odd = ! odd; 936 tempstring = tempstring XOR 56bitstring; 937 } 938 tempkey = key_correction(add_parity_bits(tempstring)); 939 key = key_correction(DES-CBC-check(s,tempkey)); 940 return(key); 941 } 943 des_string_to_key(string,salt,params) { 944 if (length(params) == 0) 945 type = 0; 946 else if (length(params) == 1) 947 type = params[0]; 948 else 949 error("invalid params"); 950 if (type == 0) 951 mit_des_string_to_key(string,salt); 952 else 953 error("invalid params"); 954 } 956 One common extension is to support the "AFS string-to-key" algorithm, 957 which is not defined here, if the type value above is one (1). 959 For generation of a key from a random bit-string, we start with a 960 56-bit string, and as with the string-to-key operation above, insert 961 parity bits, and if the result is a weak or semi-weak key, modify it 962 by exclusive-OR with the constart 0x00000000000000F0: 964 des_random_to_key(bitstring) { 965 return key_correction(add_parity_bits(bitstring)); 966 } 968 5.2.1. DES with MD5 970 The des-cbc-md5 encryption mode encrypts information under DES in CBC 971 mode with an all-zero initial vector, with an MD5 checksum (described 972 in [MD5-92]) computed and placed in the checksum field. 974 The encryption system parameters for des-cbc-md5 are: 976 des-cbc-md5 977 -------------------------------------------------------------------- 978 protocol key format 8 bytes, parity in low bit of each 980 specific key structure copy of original key 982 required checksum rsa-md5-des 983 mechanism 985 key-generation seed 8 bytes 986 length 988 cipher state 8 bytes (CBC initial vector) 990 initial cipher state all-zero 992 encryption function des-cbc(confounder | checksum | msg | pad, 993 ivec=oldstate) 994 where 995 checksum = md5(confounder | 0000... 996 | msg | pad) 998 newstate = last block of des-cbc output 1000 decryption function decrypt encrypted text and verify checksum 1002 newstate = last block of ciphertext 1004 default string-to-key empty string 1005 params 1007 pseudo-random function des-cbc(md5(input-string), ivec=0) 1009 key generation functions: 1011 string-to-key des_string_to_key 1013 random-to-key des_random_to_key 1014 des-cbc-md5 1015 -------------------------------------------------------------------- 1016 key-derivation identity 1018 The des-cbc-md5 encryption type is assigned the etype value three 1019 (3). 1021 5.2.2. DES with MD4 1023 The des-cbc-md4 encryption mode also encrypts information under DES 1024 in CBC mode, with an all-zero initial vector. An MD4 checksum 1025 (described in [MD4-92]) is computed and placed in the checksum field. 1027 des-cbc-md4 1028 -------------------------------------------------------------------- 1029 protocol key format 8 bytes, parity in low bit of each 1031 specific key structure copy of original key 1033 required checksum rsa-md4-des 1034 mechanism 1036 key-generation seed 8 bytes 1037 length 1039 cipher state 8 bytes (CBC initial vector) 1041 initial cipher state all-zero 1043 encryption function des-cbc(confounder | checksum | msg | pad, 1044 ivec=oldstate) 1045 where 1046 checksum = md4(confounder | 0000... 1047 | msg | pad) 1049 newstate = last block of des-cbc output 1051 decryption function decrypt encrypted text and verify checksum 1053 newstate = last block of ciphertext 1055 default string-to-key empty string 1056 params 1058 pseudo-random function des-cbc(md5(input-string), ivec=0) 1060 key generation functions: 1062 des-cbc-md4 1063 -------------------------------------------------------------------- 1065 string-to-key des_string_to_key 1067 random-to-key copy input, then fix parity bits 1069 key-derivation identity 1071 Note that des-cbc-md4 uses md5, not md4, in the PRF definition. 1073 The des-cbc-md4 encryption algorithm is assigned the etype value two 1074 (2). 1076 5.2.3. DES with CRC 1078 The des-cbc-crc encryption type uses DES in CBC mode with the key 1079 used as the initialization vector, with a 4-octet CRC-based checksum 1080 computed as described in section 5.1.3. Note that this is not a 1081 standard CRC-32 checksum, but a slightly modified one. 1083 des-cbc-crc 1084 -------------------------------------------------------------------- 1085 protocol key format 8 bytes, parity in low bit of each 1087 specific key structure copy of original key 1089 required checksum rsa-md5-des 1090 mechanism 1092 key-generation seed 8 bytes 1093 length 1095 cipher state 8 bytes (CBC initial vector) 1097 initial cipher state copy of original key 1099 encryption function des-cbc(confounder | checksum | msg | pad, 1100 ivec=oldstate) 1101 where 1102 checksum = crc(confounder | 00000000 1103 | msg | pad) 1105 newstate = last block of des-cbc output 1106 des-cbc-crc 1107 -------------------------------------------------------------------- 1108 decryption function decrypt encrypted text and verify checksum 1110 newstate = last block of ciphertext 1112 default string-to-key empty string 1113 params 1115 pseudo-random function des-cbc(md5(input-string), ivec=0) 1117 key generation functions: 1119 string-to-key des_string_to_key 1121 random-to-key copy input, then fix parity bits 1123 key-derivation identity 1125 The des-cbc-crc encryption algorithm is assigned the etype value one 1126 (1). 1128 5.2.4. RSA MD5 Cryptographic Checksum Using DES 1130 The RSA-MD5-DES checksum calculates a keyed collision-proof checksum 1131 by prepending an 8 octet confounder before the text, applying the RSA 1132 MD5 checksum algorithm, and encrypting the confounder and the 1133 checksum using DES in cipher-block-chaining (CBC) mode using a 1134 variant of the key, where the variant is computed by eXclusive-ORing 1135 the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0. The 1136 initialization vector should be zero. The resulting checksum is 24 1137 octets long. This checksum is tamper-proof and believed to be 1138 collision-proof. 1140 rsa-md5-des 1141 ---------------------------------------------------------------- 1142 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1144 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, 1145 conf | rsa-md5(conf | msg)) 1147 verify_mic decrypt and verify rsa-md5 checksum 1149 The rsa-md5-des checksum algorithm is assigned a checksum type number 1150 of eight (8). 1152 5.2.5. RSA MD4 Cryptographic Checksum Using DES 1154 The RSA-MD4-DES checksum calculates a keyed collision-proof checksum 1155 by prepending an 8 octet confounder before the text, applying the RSA 1156 MD4 checksum algorithm [MD4-92], and encrypting the confounder and 1157 the checksum using DES in cipher-block-chaining (CBC) mode using a 1158 variant of the key, where the variant is computed by eXclusive-ORing 1159 the key with the constant 0xF0F0F0F0F0F0F0F0. [7] The initialization 1160 vector should be zero. The resulting checksum is 24 octets long. 1161 This checksum is tamper-proof and believed to be collision-proof. 1163 rsa-md4-des 1164 ---------------------------------------------------------------- 1165 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1167 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, 1168 conf | rsa-md4(conf | msg), 1169 ivec=0) 1171 verify_mic decrypt and verify rsa-md4 checksum 1173 The rsa-md4-des checksum algorithm is assigned a checksum type number 1174 of three (3). 1176 5.2.6. RSA MD4 Cryptographic Checksum Using DES alternative 1178 The RSA-MD4-DES-K checksum calculates a keyed collision-proof 1179 checksum by applying the RSA MD4 checksum algorithm and encrypting 1180 the results using DES in cipher block chaining (CBC) mode using a DES 1181 key as both key and initialization vector. The resulting checksum is 1182 16 octets long. This checksum is tamper-proof and believed to be 1183 collision-proof. Note that this checksum type is the old method for 1184 encoding the RSA-MD4-DES checksum and it is no longer recommended. 1186 rsa-md4-des-k 1187 ---------------------------------------------------------------- 1188 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1190 get_mic des-cbc(key, md4(msg), ivec=key) 1192 verify_mic decrypt, compute checksum and compare 1194 The rsa-md4-des-k checksum algorithm is assigned a checksum type 1195 number of six (6). 1197 5.2.7. DES CBC checksum 1199 The DES-MAC checksum is computed by prepending an 8 octet confounder 1200 to the plaintext, padding with zero-valued octets if necessary to 1201 bring the length to a multiple of 8 octets, performing a DES CBC-mode 1202 encryption on the result using the key and an initialization vector 1203 of zero, taking the last block of the ciphertext, prepending the same 1204 confounder and encrypting the pair using DES in cipher-block-chaining 1205 (CBC) mode using a variant of the key, where the variant is computed 1206 by eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0. The 1207 initialization vector should be zero. The resulting checksum is 128 1208 bits (16 octets) long, 64 bits of which are redundant. This checksum 1209 is tamper-proof and collision-proof. 1211 des-mac 1212 ---------------------------------------------------------------------- 1213 associated des-cbc-md5, des-cbc-md4, des-cbc-crc 1214 cryptosystem 1216 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, 1217 conf | des-mac(key, conf | msg | pad, ivec=0), 1218 ivec=0) 1220 verify_mic decrypt, compute DES MAC using confounder, compare 1222 The des-mac checksum algorithm is assigned a checksum type number of 1223 four (4). 1225 5.2.8. DES CBC checksum alternative 1227 The DES-MAC-K checksum is computed by performing a DES CBC-mode 1228 encryption of the plaintext, with zero-valued padding bytes if 1229 necessary to bring the length to a multiple of 8 octets, and using 1230 the last block of the ciphertext as the checksum value. It is keyed 1231 with an encryption key which is also used as the initialization 1232 vector. The resulting checksum is 64 bits (8 octets) long. This 1233 checksum is tamper-proof and collision-proof. Note that this 1234 checksum type is the old method for encoding the DESMAC checksum and 1235 it is no longer recommended. 1237 des-mac-k 1238 ---------------------------------------------------------------- 1239 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1241 get_mic des-mac(key, msg | pad, ivec=key) 1243 verify_mic compute MAC and compare 1245 The des-mac-k checksum algorithm is assigned a checksum type number 1246 of five (5). 1248 5.3. Triple-DES based encryption and checksum types 1250 This encryption and checksum type pair is based on the Triple DES 1251 cryptosystem in Outer-CBC mode, and the HMAC-SHA1 message 1252 authentication algorithm. 1254 A Triple DES key is the concatenation of three DES keys as described 1255 above for des-cbc-md5. A Triple DES key is generated from random 1256 data by creating three DES keys from separate sequences of random 1257 data. 1259 Encrypted data using this type must be generated as described in 1260 section 4.3. If the length of the input data is not a multiple of 1261 the block size, zero-valued octets must be used to pad the plaintext 1262 to the next eight-octet boundary. The confounder must be eight 1263 random octets (one block). 1265 The simplified profile for Triple DES, with key derivation as defined 1266 in section 4, is as follows: 1268 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd 1269 ------------------------------------------------ 1270 protocol key format 24 bytes, parity in low 1271 bit of each 1273 key-generation seed 21 bytes 1274 length 1276 hash function SHA-1 1278 HMAC output size 160 bits 1280 message block size 8 bytes 1281 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd 1282 ------------------------------------------------ 1283 default string-to-key empty string 1284 params 1286 encryption and triple-DES encrypt and 1287 decryption functions decrypt, in outer-CBC 1288 mode (cipher block size 1289 8 octets) 1291 key generation functions: 1293 random-to-key DES3random-to-key (see 1294 below) 1296 string-to-key DES3string-to-key (see 1297 below) 1299 The des3-cbc-hmac-sha1-kd encryption type is assigned the value 1300 sixteen (16). The hmac-sha1-des3-kd checksum algorithm is assigned a 1301 checksum type number of twelve (12). 1303 5.3.1. Triple DES Key Production (random-to-key, string-to-key) 1305 The 168 bits of random key data are converted to a protocol key value 1306 as follows. First, the 168 bits are divided into three groups of 56 1307 bits, which are expanded individually into 64 bits as follows: 1309 DES3random-to-key: 1310 1 2 3 4 5 6 7 p 1311 9 10 11 12 13 14 15 p 1312 17 18 19 20 21 22 23 p 1313 25 26 27 28 29 30 31 p 1314 33 34 35 36 37 38 39 p 1315 41 42 43 44 45 46 47 p 1316 49 50 51 52 53 54 55 p 1317 56 48 40 32 24 16 8 p 1319 The "p" bits are parity bits computed over the data bits. The output 1320 of the three expansions, each corrected to avoid "weak" and "semi- 1321 weak" keys as in section 5.2, are concatenated to form the protocol 1322 key value. 1324 The string-to-key function is used to transform UTF-8 passwords into 1325 DES3 keys. The DES3 string-to-key function relies on the "N-fold" 1326 algorithm and DK function, described in section 4. 1328 The n-fold algorithm is applied to the password string concatenated 1329 with a salt value. For 3-key triple DES, the operation will involve 1330 a 168-fold of the input password string, to generate an intermediate 1331 key, from which the user's long-term key will be derived with the DK 1332 function. The DES3 string-to-key function is shown here in 1333 pseudocode: 1335 DES3string-to-key(passwordString, salt, params) 1336 if (params != emptyString) 1337 error("invalid params"); 1338 s = passwordString + salt 1339 tmpKey = random-to-key(168-fold(s)) 1340 key = DK (tmpKey, KerberosConstant) 1342 Weak key checking is performed in the random-to-key and DK 1343 operations. The KerberosConstant value is the byte string {0x6b 0x65 1344 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the ASCII 1345 encoding for the string "kerberos". 1347 6. Use of Kerberos encryption outside this specification 1349 Several Kerberos-based application protocols and preauthentication 1350 systems have been designed and deployed that perform encryption and 1351 message integrity checks in various ways. While in some cases there 1352 may be good reason for specifying these protocols in terms of 1353 specific encryption or checksum algorithms, we anticipate that in 1354 many cases this will not be true, and more generic approaches 1355 independent of particular algorithms will be desirable. Rather than 1356 having each protocol designer reinvent schemes for protecting data, 1357 using multiple keys, etc, we have attempted to present in this 1358 section a general framework that should be sufficient not only for 1359 the Kerberos protocol itself but also for many preauthentication 1360 systems and application protocols, while trying to avoid some of the 1361 assumptions that can work their way into such protocol designs. 1363 Some problematic assumptions we've seen (and sometimes made) include: 1364 that a random bitstring is always valid as a key (not true for DES 1365 keys with parity); that the basic block encryption chaining mode 1366 provides no integrity checking, or can easily be separated from such 1367 checking (not true for many modes in development that do both 1368 simultaneously); that a checksum for a message always results in the 1369 same value (not true if a confounder is incorporated); that an 1370 initial vector is used (may not be true if a block cipher in CBC mode 1371 is not in use). 1373 Such assumptions, while they may hold for any given set of encryption 1374 and checksum algorithms, may not be true of the next algorithms to be 1375 defined, leaving the application protocol unable to make use of those 1376 algorithms without updates to its specification. 1378 The Kerberos protocol uses only the attributes and operations 1379 described in sections 2 and 3. Preauthentication systems and 1380 application protocols making use of Kerberos are encouraged to use 1381 them as well. The specific key and string-to-key parameters should 1382 generally be treated as opaque. While the string-to-key parameters 1383 are manipulated as an octet string, the representation for the 1384 specific key structure is implementation-defined; it may not even be 1385 a single object. 1387 While we don't recommend it, some application protocols will 1388 undoubtedly continue to use the key data directly, even if only in 1389 some of the currently existing protocol specifications. An 1390 implementation intended to support general Kerberos applications may 1391 therefore need to make the key data available, as well as the 1392 attributes and operations described in sections 2 and 3. [8] 1394 7. Assigned Numbers 1396 The following encryption type numbers are already assigned or 1397 reserved for use in Kerberos and related protocols. 1399 encryption type etype section or comment 1400 ----------------------------------------------------------------- 1401 des-cbc-crc 1 5.2.3 1402 des-cbc-md4 2 5.2.2 1403 des-cbc-md5 3 5.2.1 1404 [reserved] 4 1405 des3-cbc-md5 5 1406 [reserved] 6 1407 des3-cbc-sha1 7 1408 dsaWithSHA1-CmsOID 9 (pkinit) 1409 md5WithRSAEncryption-CmsOID 10 (pkinit) 1410 sha1WithRSAEncryption-CmsOID 11 (pkinit) 1411 rc2CBC-EnvOID 12 (pkinit) 1412 rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5) 1413 rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0) 1414 des-ede3-cbc-Env-OID 15 (pkinit) 1415 des3-cbc-sha1-kd 16 5.3 1416 aes128-cts-hmac-sha1-96 17 [KRB5-AES] 1417 aes256-cts-hmac-sha1-96 18 [KRB5-AES] 1418 rc4-hmac 23 (Microsoft) 1419 rc4-hmac-exp 24 (Microsoft) 1420 subkey-keymaterial 65 (opaque; PacketCable) 1422 (The "des3-cbc-sha1" assignment is a deprecated version using no key 1423 derivation. It should not be confused with des3-cbc-sha1-kd.) 1424 Several numbers have been reserved for use in encryption systems not 1425 defined here. Encryption type numbers have unfortunately been 1426 overloaded on occasion in Kerberos-related protocols, so some of the 1427 reserved numbers do not and will not correspond to encryption systems 1428 fitting the profile presented here. 1430 The following checksum type numbers are assigned or reserved. As 1431 with encryption type numbers, some overloading of checksum numbers 1432 has occurred. 1434 Checksum type sumtype checksum section or 1435 value size reference 1436 ---------------------------------------------------------------------- 1437 CRC32 1 4 5.1.3 1438 rsa-md4 2 16 5.1.2 1439 rsa-md4-des 3 24 5.2.5 1440 des-mac 4 16 5.2.7 1441 des-mac-k 5 8 5.2.8 1442 rsa-md4-des-k 6 16 5.2.6 1443 rsa-md5 7 16 5.1.1 1444 rsa-md5-des 8 24 5.2.4 1445 rsa-md5-des3 9 24 ?? 1446 sha1 (unkeyed) 10 20 ?? 1447 hmac-sha1-des3-kd 12 20 5.3 1448 hmac-sha1-des3 13 20 ?? 1449 sha1 (unkeyed) 14 20 ?? 1450 hmac-sha1-96-aes128 15 20 [KRB5-AES] 1451 hmac-sha1-96-aes256 16 20 [KRB5-AES] 1452 [reserved] 0x8003 ? [GSS-KRB5] 1454 Encryption and checksum type numbers are signed 32-bit values. Zero 1455 is invalid, and negative numbers are reserved for local use. All 1456 standardized values must be positive. 1458 8. Implementation Notes 1460 The "interface" described here is the minimal information that must 1461 be defined to make a cryptosystem useful within Kerberos in an 1462 interoperable fashion. Despite the functional notation used in some 1463 places, it is not an attempt to define an API for cryptographic 1464 functionality within Kerberos. Actual implementations providing 1465 clean APIs will probably find it useful to make additional 1466 information available, which should be possible to derive from a 1467 specification written to the framework given here. For example, an 1468 application designer may wish to determine the largest number of 1469 bytes that can be encrypted without overflowing a certain size output 1470 buffer, or conversely, the maximum number of bytes that might be 1471 obtained by decrypting a ciphertext message of a given size. (In 1472 fact, an implementation of the GSS-API Kerberos mechanism [GSS-KRB5] 1473 will require some of these.) 1475 The presence of a mechanism in this document should not be taken as 1476 an indication that it must be implemented for compliance with any 1477 specification; required mechanisms will be specified elsewhere. 1478 Indeed, some of the mechanisms described here for backwards 1479 compatibility are now considered rather weak for protecting critical 1480 data. 1482 9. Security Considerations 1484 Recent years have brought advancements in the ability to perform 1485 large-scale attacks against DES, to such a degree that it is not 1486 considered a strong encryption mechanism any longer; triple-DES is 1487 generally preferred in its place, despite the poorer performance. 1488 See [ESP-DES] for a summary of some of the potential attacks, and 1489 [EFF-DES] for a detailed discussion of the implementation of 1490 particular attack. However, most Kerberos implementations still have 1491 DES as their primary interoperable encryption type. 1493 DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of 1494 single-DES here avoids them. However, DES also has 48 'possibly-weak' 1495 keys [Schneier96] (note that the tables in many editions of the 1496 reference contains errors) which are not avoided. 1498 DES weak keys are keys with the property that E1(E1(P)) = P (where E1 1499 denotes encryption of a single block with key 1). DES semi-weak keys 1500 or "dual" keys are pairs of keys with the property that E1(P) = 1501 D2(P), and thus E2(E1(P)) = P. Because of the use of CBC mode and 1502 leading random confounder, however, these properties are unlikely to 1503 present a security problem. 1505 Many of the choices concerning when weak-key corrections are 1506 performed relate more to compatibility with existing implementations 1507 than to any risk analysis. 1509 While checks are also done for the component DES keys in a triple-DES 1510 key, the nature of the weak keys is such that it is extremely 1511 unlikely that they will weaken the triple-DES encryption -- only 1512 slightly more likely than having the middle of the three sub-keys 1513 match one of the other two, which effectively converts the encryption 1514 to single-DES, which is a case we make no effort to avoid. 1516 The true CRC-32 checksum is not collision-proof; an attacker could 1517 use a probabilistic chosen-plaintext attack to generate a valid 1518 message even if a confounder is used [SG92]. The use of collision- 1519 proof checksums is of course recommended for environments where such 1520 attacks represent a significant threat. The "simplifications" (read: 1521 bugs) introduced when CRC-32 was implemented for Kerberos cause 1522 leading zeros to effectively be ignored, so messages differing only 1523 in leading zero bits will have the same checksum. 1525 [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm. 1526 Unlike [IPSEC-HMAC], the triple-DES specification here does not use 1527 the suggested truncation of the HMAC output. As pointed out in 1528 [IPSEC-HMAC], SHA-1 was not developed to be used as a keyed hash 1529 function, which is a criterion of HMAC. [HMAC-TEST] contains test 1530 vectors for HMAC-SHA-1. 1532 The mit_des_string_to_key function was originally constructed with 1533 the assumption that all input would be ASCII; it ignores the top bit 1534 of each input byte. Folding with XOR is also not an especially good 1535 mixing mechanism in terms of preserving randomness. 1537 The n-fold function used in the string-to-key operation for des3-cbc- 1538 hmac-sha1-kd was designed to cause each bit of input to contribute 1539 equally to the output; it was not designed to maximize or equally 1540 distribute randomness in the input, and there are conceivable cases 1541 of partially structured input where randomness may be lost. This 1542 should only be an issue for highly structured passwords, however. 1544 [RFC1851] discusses the relative strength of triple-DES encryption. 1545 The relative slow speed of triple-DES encryption may also be an issue 1546 for some applications. 1548 This document, like the Kerberos protocol, completely ignores the 1549 notion of limiting the amount of data a key may be used with to a 1550 quantity based on the robustness of the algorithm or size of the key. 1551 It is assumed that any defined algorithms and key sizes will be 1552 strong enough to support very large amounts of data, or they will be 1553 deprecated once significant attacks are known. 1555 This document also places no bounds on the amount of data that can be 1556 handled in various operations. In order to avoid denial of service 1557 attacks, implementations will probably want to restrict message sizes 1558 at some higher level. 1560 10. IANA Considerations 1562 None at present. The management of encryption and checksum type 1563 number assignments may be transferred to IANA at some future time. 1565 11. Acknowledgments 1567 This document is an extension of the encryption specification 1568 included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much 1569 of the text of the background, concepts, and DES specifications are 1570 drawn directly from that document. 1572 The abstract framework presented in this document was put together by 1573 Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn, 1574 and Tom Yu, and the details were refined several times based on 1575 comments from John Brezak and others. 1577 Marc Horowitz wrote the original specification of triple-DES and key 1578 derivation in a pair of Internet Drafts (under the names draft- 1579 horowitz-key-derivation and draft-horowitz-kerb-key-derivation) which 1580 were later folded into a draft revision of [Kerb1510], from which 1581 this document was later split off. 1583 Tom Yu provided the text describing the modifications to the standard 1584 CRC algorithm as Kerberos implementations actually use it. 1586 Miroslav Jurisic provided information for one of the UTF-8 test cases 1587 for the string-to-key functions. 1589 Marcus Watts noticed some errors in earlier drafts, and pointed out 1590 that the simplified profile could easily be modified to support 1591 cipher text stealing modes. 1593 Simon Josefsson contributed some clarifications to the DES "CBC 1594 checksum", string-to-key and weak key descriptions, and some test 1595 vectors. 1597 Simon Josefsson, Louis LeVay and others also caught some errors in 1598 earlier drafts. 1600 12. Editor's address 1602 Kenneth Raeburn 1603 Massachusetts Institute of Technology 1604 77 Massachusetts Avenue 1605 Cambridge, MA 02139 1606 raeburn@mit.edu 1608 13. Full Copyright Statement 1610 Copyright (C) The Internet Society (2003). All Rights Reserved. 1612 This document and translations of it may be copied and furnished to 1613 others, and derivative works that comment on or otherwise explain it 1614 or assist in its implementation may be prepared, copied, published 1615 and distributed, in whole or in part, without restriction of any 1616 kind, provided that the above copyright notice and this paragraph are 1617 included on all such copies and derivative works. However, this 1618 document itself may not be modified in any way, such as by removing 1619 the copyright notice or references to the Internet Society or other 1620 Internet organizations, except as needed for the purpose of 1621 developing Internet standards in which case the procedures for 1622 copyrights defined in the Internet Standards process must be 1623 followed, or as required to translate it into languages other than 1624 English. 1626 The limited permissions granted above are perpetual and will not be 1627 revoked by the Internet Society or its successors or assigns. 1629 This document and the information contained herein is provided on an 1630 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1631 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1632 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1633 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1634 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1636 A. Test vectors 1638 This section provides test vectors for various functions defined or 1639 described in this document. For convenience, most inputs are ASCII 1640 strings, though some UTF-8 samples are be provided for string-to-key 1641 functions. Keys and other binary data are specified as hexadecimal 1642 strings. 1644 A.1. n-fold 1646 The n-fold function is defined in section 4.1. As noted there, the 1647 sample vector in the original paper defining the algorithm appears to 1648 be incorrect. Here are some test cases provided by Marc Horowitz and 1649 Simon Josefsson: 1651 64-fold("012345") = 1652 64-fold(303132333435) = be072631276b1955 1654 56-fold("password") = 1655 56-fold(70617373776f7264) = 78a07b6caf85fa 1657 64-fold("Rough Consensus, and Running Code") = 1658 64-fold(526f75676820436f6e73656e7375732c20616e642052756e 1659 6e696e6720436f6465) = bb6ed30870b7f0e0 1661 168-fold("password") = 1662 168-fold(70617373776f7264) = 1663 59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e 1665 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY" 1666 192-fold(4d41535341434856534554545320494e5354495456544520 1667 4f4620544543484e4f4c4f4759) = 1668 db3b0d8f0b061e603282b308a50841229ad798fab9540c1b 1670 168-fold("Q") = 1671 168-fold(51) = 1672 518a54a2 15a8452a 518a54a2 15a8452a 1673 518a54a2 15 1675 168-fold("ba") = 1676 168-fold(6261) = 1677 fb25d531 ae897449 9f52fd92 ea9857c4 1678 ba24cf29 7e 1680 Here are some additional values corresponding to folded values of the 1681 string "kerberos"; the 64-bit form is used in the des3 string-to-key 1682 (section 5.3.1). 1684 64-fold("kerberos") = 1685 6b657262 65726f73 1686 128-fold("kerberos") = 1687 6b657262 65726f73 7b9b5b2b 93132b93 1688 168-fold("kerberos") = 1689 8372c236 344e5f15 50cd0747 e15d62ca 1690 7a5a3bce a4 1691 256-fold("kerberos") = 1692 6b657262 65726f73 7b9b5b2b 93132b93 1693 5c9bdcda d95c9899 c4cae4de e6d6cae4 1695 Note that the initial octets exactly match the input string when the 1696 output length is a multiple of the input length. 1698 A.2. mit_des_string_to_key 1700 The function mit_des_string_to_key is defined in section 5.2. We 1701 present here several test values, with some of the intermediate 1702 results. The fourth test demonstrates the use of UTF-8 with three 1703 characters. The last two tests are specifically constructed so as to 1704 trigger the weak-key fixups for the intermediate key produced by fan- 1705 folding; we have no test cases that cause such fixups for the final 1706 key. 1708 UTF-8 encodings used in test vector: 1709 eszett C3 9F s-caron C5 A1 c-acute C4 87 1710 g-clef F0 9D 84 9E 1712 Test vector: 1714 salt: "ATHENA.MIT.EDUraeburn" 1715 415448454e412e4d49542e4544557261656275726e 1716 password: "password" 70617373776f7264 1717 fan-fold result: c01e38688ac86c2e 1718 intermediate key: c11f38688ac86d2f 1719 DES key: cbc22fae235298e3 1721 salt: "WHITEHOUSE.GOVdanny" 5748495445484f5553452e474f5664616e6e79 1722 password: "potatoe" 706f7461746f65 1723 fan-fold result: a028944ee63c0416 1724 intermediate key: a129944fe63d0416 1725 DES key: df3d32a74fd92a01 1727 salt: "EXAMPLE.COMpianist" 4558414D504C452E434F4D7069616E697374 1728 password: g-clef f09d849e 1729 fan-fold result: 3c4a262c18fab090 1730 intermediate key: 3d4a262c19fbb091 1731 DES key: 4ffb26bab0cd9413 1732 salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute 1733 415448454e412e4d49542e4544554a757269c5a169c487 1734 password: eszett c39f 1735 fan-fold result: b8f6c40e305afc9e 1736 intermediate key: b9f7c40e315bfd9e 1737 DES key: 62c81a5232b5e69d 1739 salt: "AAAAAAAA" 4141414141414141 1740 password: "11119999" 3131313139393939 1741 fan-fold result: e0e0e0e0f0f0f0f0 1742 intermediate key: e0e0e0e0f1f1f101 1743 DES key: 984054d0f1a73e31 1745 salt: "FFFFAAAA" 4646464641414141 1746 password: "NNNN6666" 4e4e4e4e36363636 1747 fan-fold result: 1e1e1e1e0e0e0e0e 1748 intermediate key: 1f1f1f1f0e0e0efe 1749 DES key: c4bf6b25adf7a4f8 1751 This trace provided by Simon Josefsson shows the intermediate 1752 processing stages of one of the test inputs: 1754 string_to_key (des-cbc-md5, string, salt) 1755 ;; string: 1756 ;; `password' (length 8 bytes) 1757 ;; 70 61 73 73 77 6f 72 64 1758 ;; salt: 1759 ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes) 1760 ;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61 1761 ;; 65 62 75 72 6e 1762 des_string_to_key (string, salt) 1763 ;; String: 1764 ;; `password' (length 8 bytes) 1765 ;; 70 61 73 73 77 6f 72 64 1766 ;; Salt: 1767 ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes) 1768 ;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61 1769 ;; 65 62 75 72 6e 1770 odd = 1; 1771 s = string | salt; 1772 tempstring = 0; /* 56-bit string */ 1773 pad(s); /* with nulls to 8 byte boundary */ 1774 ;; s = pad(string|salt): 1775 ;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00' 1776 ;; (length 32 bytes) 1777 ;; 70 61 73 73 77 6f 72 64 41 54 48 45 4e 41 2e 4d 1778 ;; 49 54 2e 45 44 55 72 61 65 62 75 72 6e 00 00 00 1779 for (8byteblock in s) { 1780 ;; loop iteration 0 1781 ;; 8byteblock: 1782 ;; `password' (length 8 bytes) 1783 ;; 70 61 73 73 77 6f 72 64 1784 ;; 01110000 01100001 01110011 01110011 01110111 01101111 1785 ;; 01110010 01100100 1786 56bitstring = removeMSBits(8byteblock); 1787 ;; 56bitstring: 1788 ;; 1110000 1100001 1110011 1110011 1110111 1101111 1789 ;; 1110010 1100100 1790 if (odd == 0) reverse(56bitstring); ;; odd=1 1791 odd = ! odd 1792 tempstring = tempstring XOR 56bitstring; 1793 ;; tempstring 1794 ;; 1110000 1100001 1110011 1110011 1110111 1101111 1795 ;; 1110010 1100100 1797 for (8byteblock in s) { 1798 ;; loop iteration 1 1799 ;; 8byteblock: 1800 ;; `ATHENA.M' (length 8 bytes) 1801 ;; 41 54 48 45 4e 41 2e 4d 1802 ;; 01000001 01010100 01001000 01000101 01001110 01000001 1803 ;; 00101110 01001101 1804 56bitstring = removeMSBits(8byteblock); 1805 ;; 56bitstring: 1806 ;; 1000001 1010100 1001000 1000101 1001110 1000001 1807 ;; 0101110 1001101 1808 if (odd == 0) reverse(56bitstring); ;; odd=0 1809 reverse(56bitstring) 1810 ;; 56bitstring after reverse 1811 ;; 1011001 0111010 1000001 0111001 1010001 0001001 1812 ;; 0010101 1000001 1813 odd = ! odd 1814 tempstring = tempstring XOR 56bitstring; 1815 ;; tempstring 1816 ;; 0101001 1011011 0110010 1001010 0100110 1100110 1817 ;; 1100111 0100101 1819 for (8byteblock in s) { 1820 ;; loop iteration 2 1821 ;; 8byteblock: 1822 ;; `IT.EDUra' (length 8 bytes) 1823 ;; 49 54 2e 45 44 55 72 61 1824 ;; 01001001 01010100 00101110 01000101 01000100 01010101 1825 ;; 01110010 01100001 1826 56bitstring = removeMSBits(8byteblock); 1827 ;; 56bitstring: 1828 ;; 1001001 1010100 0101110 1000101 1000100 1010101 1829 ;; 1110010 1100001 1830 if (odd == 0) reverse(56bitstring); ;; odd=1 1831 odd = ! odd 1832 tempstring = tempstring XOR 56bitstring; 1833 ;; tempstring 1834 ;; 1100000 0001111 0011100 0001111 1100010 0110011 1835 ;; 0010101 1000100 1837 for (8byteblock in s) { 1838 ;; loop iteration 3 1839 ;; 8byteblock: 1840 ;; `eburn\x00\x00\x00' (length 8 bytes) 1841 ;; 65 62 75 72 6e 00 00 00 1842 ;; 01100101 01100010 01110101 01110010 01101110 00000000 1843 ;; 00000000 00000000 1844 56bitstring = removeMSBits(8byteblock); 1845 ;; 56bitstring: 1846 ;; 1100101 1100010 1110101 1110010 1101110 0000000 1847 ;; 0000000 0000000 1848 if (odd == 0) reverse(56bitstring); ;; odd=0 1849 reverse(56bitstring) 1850 ;; 56bitstring after reverse 1851 ;; 0000000 0000000 0000000 0111011 0100111 1010111 1852 ;; 0100011 1010011 1853 odd = ! odd 1854 tempstring = tempstring XOR 56bitstring; 1855 ;; tempstring 1856 ;; 1100000 0001111 0011100 0110100 1000101 1100100 1857 ;; 0110110 0010111 1859 for (8byteblock in s) { 1860 } 1861 ;; for loop terminated 1863 tempkey = key_correction(add_parity_bits(tempstring)); 1864 ;; tempkey 1865 ;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes) 1866 ;; c1 1f 38 68 8a c8 6d 2f 1867 ;; 11000001 00011111 00111000 01101000 10001010 11001000 1868 ;; 01101101 00101111 1870 key = key_correction(DES-CBC-check(s,tempkey)); 1871 ;; key 1872 ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes) 1873 ;; cb c2 2f ae 23 52 98 e3 1874 ;; 11001011 11000010 00101111 10101110 00100011 01010010 1875 ;; 10011000 11100011 1877 ;; string_to_key key: 1878 ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes) 1879 ;; cb c2 2f ae 23 52 98 e3 1881 A.3. DES3 DR and DK 1883 These tests show the derived-random and derived-key values for the 1884 des3-hmac-sha1-kd encryption scheme, using the DR and DK functions 1885 defined in section 5.3.1. The input keys were randomly generated; 1886 the usage values are from this specification. 1888 key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92 1889 usage: 0000000155 1890 DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705 1891 DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd 1893 key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2 1894 usage: 00000001aa 1895 DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2 1896 DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207 1898 key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc 1899 usage: 0000000155 1900 DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb 1901 DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf 1903 key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5 1904 usage: 00000001aa 1905 DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70 1906 DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e 1907 key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb 1908 usage: 6b65726265726f73 ("kerberos") 1909 DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da 1910 DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43 1912 key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da 1913 usage: 0000000155 1914 DR: 348056ec98fcc517171d2b4d7a9493af482d999175 1915 DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7 1917 key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c 1918 usage: 00000001aa 1919 DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5 1920 DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1 1922 key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443 1923 usage: 0000000155 1924 DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a 1925 DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49 1927 key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016 1928 usage: 00000001aa 1929 DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec 1930 DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d 1932 A.4. DES3string_to_key 1934 These are the keys generated for some of the above input strings for 1935 triple-DES with key derivation as defined in section 5.3.1. 1937 salt: "ATHENA.MIT.EDUraeburn" 1938 passwd: "password" 1939 key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e 1941 salt: "WHITEHOUSE.GOVdanny" 1942 passwd: "potatoe" 1943 key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a 1945 salt: "EXAMPLE.COMbuckaroo" 1946 passwd: "penny" 1947 key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a 1949 salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute 1950 passwd: eszett 1951 key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0 1952 salt: "EXAMPLE.COMpianist" 1953 passwd: g-clef 1954 key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19 1956 A.5. Modified CRC-32 1958 Below are modified-CRC32 values for various ASCII and octet strings. 1959 Only the printable ASCII characters are checksummed, no C-style 1960 trailing zero-valued octet. The 32-bit modified CRC and the sequence 1961 of output bytes as used in Kerberos are shown. (The octet values are 1962 separated here to emphasize that they are octet values and not 32-bit 1963 numbers, which will be the most convenient form for manipulation in 1964 some implementations. The bit and byte order used internally for 1965 such a number is irrelevant; the octet sequence generated is what is 1966 important.) 1968 mod-crc-32("foo") = 33 bc 32 73 1969 mod-crc-32("test0123456789") = d6 88 3e b8 1970 mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3 1971 mod-crc-32(8000) = 4b 98 83 3b 1972 mod-crc-32(0008) = 32 88 db 0e 1973 mod-crc-32(0080) = 20 83 b8 ed 1974 mod-crc-32(80) = 20 83 b8 ed 1975 mod-crc-32(80000000) = 3b b6 59 ed 1976 mod-crc-32(00000001) = 96 30 07 77 1978 B. Significant Changes from RFC 1510 1980 The encryption and checksum mechanism profiles are new. The old 1981 specification defined a few operations for various mechanisms, but 1982 didn't outline what should be required of new mechanisms in terms of 1983 abstract properties, nor how to ensure that a mechanism specification 1984 is complete enough for interoperability between implementations. The 1985 new profiles do differ from the old specification in a few ways: 1987 Some message definitions in [Kerb1510] could be read as permitting 1988 the initial vector to be specified by the application; the text 1989 was too vague. It is specifically not permitted in this 1990 specification. Some encryption algorithms may not use 1991 initialization vectors, so relying on chosen, secret 1992 initialization vectors for security is unwise. Also, the 1993 prepended confounder in the existing algorithms is roughly 1994 equivalent to a per-message initialization vector that is revealed 1995 in encrypted form. However, carrying state across from one 1996 encryption to another is explicitly permitted through the opaque 1997 "cipher state" object. 1999 The use of key derivation is new. 2001 Several new methods are introduced, including generation of a key 2002 in wire-protocol format from random input data. 2004 The means for influencing the string-to-key algorithm are laid out 2005 more clearly. 2007 Triple-DES support is new. 2009 The pseudo-random function is new. 2011 The des-cbc-crc, DES string-to-key and CRC descriptions have been 2012 updated to align them with existing implementations. 2014 [Kerb1510] had no indication what character set or encoding might be 2015 used for pass phrases and salts. 2017 In [Kerb1510], key types, encryption algorithms and checksum 2018 algorithms were only loosely associated, and the association was not 2019 well described. In this specification, key types and encryption 2020 algorithms have a one-to-one correspondence, and associations between 2021 encryption and checksum algorithms are described so that checksums 2022 can be computed given negotiated keys, without requiring further 2023 negotiation for checksum types. 2025 Notes 2027 [1] While Message Authentication Code (MAC) or Message Integrity 2028 Check (MIC) would be more appropriate terms for many of the 2029 uses in this document, we continue to use the term "checksum" 2030 for historical reasons. 2032 [2] Extending CBC mode across messages would be one obvious 2033 example of this chaining. Another might be the use of 2034 counter mode, with a counter randomly initialized and 2035 attached to the ciphertext; a second message could continue 2036 incrementing the counter when chaining the cipher state, thus 2037 avoiding having to transmit another counter value. However, 2038 this chaining is only useful for uninterrupted, ordered 2039 sequences of messages. 2041 [3] In the case of Kerberos, the encrypted objects will generally 2042 be ASN.1 DER encodings, which contain indications of their 2043 length in the first few octets. 2045 [4] As of the time of this writing, some new modes of operation 2046 have been proposed, some of which may permit encryption and 2047 integrity protection simultaneously. After some of these 2048 proposals have been subjected to adequate analysis, we may 2049 wish to formulate a new simplified profile based on one of 2050 them. 2052 [5] It should be noted that the sample vector in Appendix B.2 of 2053 the original paper appears to be incorrect. Two independent 2054 implementations from the specification (one in C by Marc 2055 Horowitz, and another in Scheme by Bill Sommerfeld) agree on 2056 a value different from that in [Blumenthal96]. 2058 [6] For example, in MIT's implementation of [Kerb1510], the rsa- 2059 md5 unkeyed checksum of application data may be included in 2060 an authenticator encrypted in a service's key; since rsa-md5 2061 is believed to be collision-proof, even if the application 2062 data is exposed to an attacker, it cannot be modified without 2063 causing the checksum verification to fail. 2065 [7] A variant of the key is used to limit the use of a key to a 2066 particular function, separating the functions of generating a 2067 checksum from other encryption performed using the session 2068 key. The constant 0xF0F0F0F0F0F0F0F0 was chosen because it 2069 maintains key parity. The properties of DES precluded the 2070 use of the complement. The same constant is used for similar 2071 purpose in the Message Integrity Check in the Privacy 2072 Enhanced Mail standard. 2074 [8] Perhaps one of the more common reasons for directly 2075 performing encryption is direct control over the negotiation 2076 and to select a "sufficiently strong" encryption algorithm 2077 (whatever that means in the context of a given application). 2078 While Kerberos directly provides no facility for negotiating 2079 encryption types between the application client and server, 2080 there are other means for accomplishing similar goals. For 2081 example, requesting only "strong" session key types from the 2082 KDC, and assuming that the type actually returned by the KDC 2083 will be understood and supported by the application server. 2085 Normative References 2087 [Bellare98] 2088 Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway, 2089 "Relations Among Notions of Security for Public-Key Encryption 2090 Schemes". Extended abstract published in Advances in Cryptology- 2091 Crypto 98 Proceedings, Lecture Notes in Computer Science Vol. 2092 1462, H. Krawcyzk ed., Springer-Verlag, 1998. 2094 [Blumenthal96] 2095 Blumenthal, U., and S. Bellovin, "A Better Key Schedule for DES- 2096 Like Ciphers", Proceedings of PRAGOCRYPT '96, 1996. 2097 [CRC] 2098 International Organization for Standardization, "ISO Information 2099 Processing Systems - Data Communication - High-Level Data Link 2100 Control Procedure - Frame Structure," IS 3309, 3rd Edition, 2101 October 1984. 2102 [DES77] 2103 National Bureau of Standards, U.S. Department of Commerce, "Data 2104 Encryption Standard," Federal Information Processing Standards 2105 Publication 46, Washington, DC, 1977. 2106 [DESI81] 2107 National Bureau of Standards, U.S. Department of Commerce, 2108 "Guidelines for implementing and using NBS Data Encryption 2109 Standard," Federal Information Processing Standards Publication 2110 74, Washington, DC, 1981. 2111 [DESM80] 2112 National Bureau of Standards, U.S. Department of Commerce, "DES 2113 Modes of Operation," Federal Information Processing Standards 2114 Publication 81, Springfield, VA, December 1980. 2115 [Dolev91] 2116 Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography", 2117 Proceedings of the 23rd Annual Symposium on Theory of Computing, 2118 ACM, 1991. 2119 [HMAC] 2120 Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 2121 for Message Authentication", RFC 2104, February 1997. 2122 [KRB5-AES] 2123 Raeburn, K., "AES Encyrption for Kerberos 5", RFC XXXX, Xxxxxxxx 2124 2003. 2125 [MD4-92] 2126 Rivest, R., "The MD4 Message Digest Algorithm," RFC 1320, MIT 2127 Laboratory for Computer Science, April 1992. 2128 [MD5-92] 2129 Rivest, R., "The MD5 Message Digest Algorithm," RFC 1321, MIT 2130 Laboratory for Computer Science, April 1992. 2131 [RFC2026] 2132 Bradner, S., "The Internet Standards Process -- Revisions 3," RFC 2133 2026, October 1996. 2134 [SG92] 2135 Stubblebine, S., and V. D. Gligor, "On Message Integrity in 2136 Cryptographic Protocols," in Proceedings of the IEEE Symposium on 2137 Research in Security and Privacy, Oakland, California, May 1992. 2139 Informative References 2141 [EFF-DES] 2142 Electronic Frontier Foundation, "Cracking DES: Secrets of 2143 Encryption Research, Wiretap Politics, and Chip Design", O'Reilly 2144 & Associates, Inc., May 1998. 2145 [ESP-DES] 2146 Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm 2147 With Explicit IV", RFC 2405, November 1998. 2148 [GSS-KRB5] 2149 Linn, J., "The Kerberos Version 5 GSS-API Mechanism," RFC 1964, 2150 June 1996. 2151 [HMAC-TEST] 2152 Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", 2153 RFC 2202, September 1997. 2154 [IPSEC-HMAC] 2155 Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and 2156 AH", RFC 2404, November 1998. 2157 [Kerb] 2158 Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K. 2159 Raeburn, "The Kerberos Network Authentication Service (V5)", 2160 draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22, 2161 2002. Work in progress. 2162 [Kerb1510] 2163 Kohl, J., and C. Neuman, "The Kerberos Network Authentication 2164 Service (V5)", RFC 1510, September 1993. 2165 [RC5] 2166 Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and 2167 RC5-CTS Algorithms", RFC 2040, October 1996. 2168 [Schneier96] 2169 Schneier, B., "Applied Cryptography Second Edition", John Wiley & 2170 Sons, New York, NY, 1996. ISBN 0-471-12845-7. 2172 Notes to RFC Editor 2174 Before publication of this document as an RFC, the following changes 2175 are needed: 2177 Change the reference "[KRB5-AES]" in Normative References to indicate 2178 the AES draft (draft-raeburn-krb-rijndael-krb-XX) that should be 2179 advancing to RFC at the same time. The RFC number and publication 2180 date are needed. 2182 If draft-ietf-krb-wg-kerberos-clarifications advances to RFC at the 2183 same time as this document, change the information for [Kerb] in the 2184 Informative References section as well. 2186 Delete this section.