idnits 2.17.1 draft-ietf-krb-wg-crypto-00.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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 8 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 661 has weird spacing: '...osystem as d...' == Line 696 has weird spacing: '...ructure empt...' == Line 713 has weird spacing: '...-to-key non...' == Line 859 has weird spacing: '...ructure copy...' == Line 882 has weird spacing: '...-to-key emp...' == (15 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 (July 5, 2002) is 7963 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) == Missing Reference: 'Kerb' is mentioned on line 12, but not defined == Missing Reference: 'RFC2026' is mentioned on line 39, but not defined -- Looks like a reference, but probably isn't: '1' on line 1708 == Missing Reference: 'K' is mentioned on line 276, but not defined -- Looks like a reference, but probably isn't: '2' on line 1713 -- Looks like a reference, but probably isn't: '3' on line 1717 == Missing Reference: 'Horowitz' is mentioned on line 422, but not defined -- Looks like a reference, but probably isn't: '4' on line 1724 -- Looks like a reference, but probably isn't: '0' on line 833 -- Looks like a reference, but probably isn't: '5' on line 1730 == Unused Reference: 'MNSS87' is defined on line 1785, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Blumenthal96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellare98' -- Possible downref: Non-RFC (?) normative reference: ref. 'DES77' -- Possible downref: Non-RFC (?) normative reference: ref. 'DESM80' -- Possible downref: Non-RFC (?) normative reference: ref. 'Dolev91' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3309' -- Unexpected draft version: The latest known version of draft-ietf-ipsec-hmac-md5 is -00, but you're referring to -01. ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-hmac-md5 (ref. 'Krawczyk96') ** 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. 'MNSS87' -- Possible downref: Non-RFC (?) normative reference: ref. 'SG92' Summary: 10 errors (**), 0 flaws (~~), 13 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Kerberos Working Group K. Raeburn 3 Document: draft-ietf-krb-wg-crypto-00.txt MIT 4 January 5, 2002 5 expires July 5, 2002 7 Encryption and Checksum Specifications 8 for Kerberos 5 10 Abstract 12 The Kerberos protocol [Kerb] uses cryptography to protect messages of 13 various sizes, using stream encryption ciphers, or more commonly, 14 block encryption ciphers with block chaining. 16 This document describes a framework for defining encryption and 17 checksum mechanisms, defining an abstraction layer between the 18 Kerberos protocol and related protocols, and the actual mechanism 19 specifications. This should allow either side to be extended more 20 cleanly without requiring changes to the other. 22 Several mechanisms are also defined in this document. Some are taken 23 from RFC 1510, modified in form to fit this new framework, and 24 occasionally modified in content when the old specification was 25 incorrect. Some new mechanisms are presented here as well. No 26 requirements for implementation of specific mechanisms are made here. 28 Status 30 This document is an Internet-Draft and is in full conformance with 31 all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts 32 are working documents of the Internet Engineering Task Force (IETF), 33 its areas, and its working groups. Note that other groups may also 34 distribute working documents as Internet-Drafts. Internet-Drafts are 35 draft documents valid for a maximum of six months and may be updated, 36 replaced, or obsoleted by other documents at any time. It is 37 inappropriate to use Internet-Drafts as reference material or to cite 38 them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.html. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Table of Contents 48 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 49 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 50 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 Work Still Needed . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Encryption mechanism attributes . . . . . . . . . . . . . . . . . 5 55 3. Checksum mechanism attributes . . . . . . . . . . . . . . . . . . 8 56 4. Simplified profile for CBC-mode ciphers with key derivation . . . 9 57 4.1. A key derivation function [Horowitz] . . . . . . . . . . . . . 10 58 4.2. Simplified profile parameters . . . . . . . . . . . . . . . . . 12 59 4.3. Cryptosystem profile based on simplified profile . . . . . . . 13 60 4.4. Checksum profiles based on simplified profile . . . . . . . . . 15 61 5. Profiles for Kerberos encryption systems . . . . . . . . . . . . 15 62 5.1. null . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 63 5.2. DES-based encryption systems . . . . . . . . . . . . . . . . . 17 64 5.3. Triple-DES Encryption with Key Derivation . . . . . . . . . . . 23 65 6. Profiles for Kerberos checksums . . . . . . . . . . . . . . . . . 25 66 6.1. RSA MD4 Cryptographic Checksum Using DES . . . . . . . . . . . 25 67 6.2. The RSA MD5 Checksum . . . . . . . . . . . . . . . . . . . . . 26 68 6.3. RSA MD5 Cryptographic Checksum Using DES . . . . . . . . . . . 26 69 6.4. The CRC-32 Checksum . . . . . . . . . . . . . . . . . . . . . . 27 70 6.5. The RSA MD4 Checksum . . . . . . . . . . . . . . . . . . . . . 28 71 6.6. DES CBC checksum . . . . . . . . . . . . . . . . . . . . . . . 28 72 6.7. RSA MD4 Cryptographic Checksum Using DES alternative . . . . . 29 73 6.8. DES CBC checksum alternative . . . . . . . . . . . . . . . . . 30 74 6.9. The HMAC-SHA1-DES3-KD Checksum . . . . . . . . . . . . . . . . 30 75 7. Use of Kerberos encryption outside this specification . . . . . . 30 76 8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . . . 31 77 9. Notes to Implementors . . . . . . . . . . . . . . . . . . . . . . 33 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 33 79 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 33 80 12. Editor's address . . . . . . . . . . . . . . . . . . . . . . . . 34 81 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 34 82 A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . . . 35 83 A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 84 A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . . . . . 35 85 A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . . . . . 37 86 A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . . . . . 38 87 A.5. DES3 combine-keys . . . . . . . . . . . . . . . . . . . . . . . 39 88 A.6. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . . . . . 39 89 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 90 Normative References . . . . . . . . . . . . . . . . . . . . . . . . 40 91 Informative References . . . . . . . . . . . . . . . . . . . . . . . 41 92 Work Still Needed 94 More talking with cryptographers about the "combine-keys" function in 95 the simplified profile. I've been talking a little with Uri 96 Blumenthal, but he hasn't had a lot of time for this. 98 More detailed list of differences from RFC 1510, to update the 99 "Significant changes" appendix. 101 Are sections 2 and 3 what we want to recommend for external use in 102 section 7, or just a subset? 104 Look up reference to Bellovin paper on CBC mode use of key as IV 105 being a bad idea. 107 Fix anything marked with "@@". 109 Fix up references section. 111 Encoding of strings? 113 Someone remind me, why does get_mic have to produce a fixed-size 114 output? 116 Guidelines for mechanism designers for what to document -- something 117 akin to section 4 of RFC 2411 would make sense. 119 Introduction 121 @@ needs update for separation from kerberos-revisions 123 The Kerberos protocols are designed to encrypt blocks of arbitrary 124 sizes, using stream encryption ciphers, or more commonly, block 125 encryption ciphers such as the Data Encryption Standard [DES77] in 126 conjunction with block chaining and checksum methods [DESM80]. 127 Encryption is used to prove the identities of the network entities 128 participating in message exchanges. The Key Distribution Center for 129 each realm is trusted by all principals registered in that realm to 130 store a secret key in confidence. Proof of knowledge of this secret 131 key is used to verify the authenticity of a principal. 133 The Kerberos protocols generally assume that the encryption used is 134 secure from cryptanalysis; however, in some cases, the order of 135 fields in the encrypted portions of messages as defined in this 136 section is chosen to mitigate somewhat the effects of poorly chosen 137 keys under certain types of cryptographic attacks. It is still 138 important to choose good keys. If keys are derived from user-typed 139 passwords, those passwords need to be well chosen to make brute force 140 attacks more difficult. Poorly chosen keys still make easy targets 141 for intruders. 143 The following sections specify the encryption and checksum mechanisms 144 currently defined for Kerberos, as well as a framework for defining 145 future mechanisms. The encodings, chaining, padding and other 146 requirements for each are described. Test vectors for several 147 functions are given in appendix A. 149 1. Concepts 151 Both encryption and checksum mechanisms are defined in terms of 152 profiles, detailed in later sections. Each specifies a collection of 153 operations and attributes that must be defined for a mechanism. A 154 Kerberos encryption or checksum mechanism specification is not 155 complete if it does not define all of these operations and 156 attributes. 158 An encryption mechanism must provide for confidentiality and 159 integrity of the original plaintext. (Integrity checking may be 160 achieved by incorporating a checksum, if the encryption mode does not 161 provide an integrity check itself.) It must also provide non- 162 malleability [Bellare98, Dolev91]. Use of a random confounder 163 prepended to the plaintext is recommended. It should not be possible 164 to determine if two ciphertexts correspond to the same plaintext, 165 without knowledge of the key. 167 A checksum mechanism [1] must provide proof of the integrity of the 168 associated message, and must preserve the confidentiality of the 169 message in case it is not sent in the clear. It should be infeasible 170 to find two plaintexts which have the same checksum. It is NOT 171 required that an eavesdropper be unable to determine if two checksums 172 are for the same message; it is assumed that the messages themselves 173 will be visible to any such eavesdropper. 175 Due to advances in cryptography, it is considered unwise by some 176 cryptographers to use the same key for multiple purposes 177 [@@reference??]. Since keys are used in performing a number of 178 different functions in Kerberos, it is desirable to use different 179 keys for each of these purposes, even though we start with a single 180 long-term or session key. 182 We do this by enumerating the different uses of keys within Kerberos, 183 and making the "usage number" an input to the encryption or checksum 184 mechanisms; this enumeration is outside the scope of this document. 185 Later sections of this document define simplified profile templates 186 for encryption and checksum mechanisms that use a key derivation 187 function applied to a CBC mode (or similar) cipher and a checksum or 188 hash algorithm. 190 We distinguish the "base key" specified by other documents from the 191 "specific key" to be used for a particular instance of encryption or 192 checksum operations. It is expected but not required that the 193 specific key will be one or more separate keys derived from the 194 original protocol key and the key usage number. The specific key 195 should not be explicitly referenced outside of this document. The 196 typical language used in other documents should be something like, 197 "encrypt this octet string using this key and this usage number"; 198 generation of the specific key and cipher state (described in the 199 next section) are implicit. (The creation of a new cipher-state 200 object, or the re-use of one from a previous encryption operation, 201 may also be explicit.) 203 New protocols defined in terms of the Kerberos encryption and 204 checksum types should use their own key usage values. Key usages are 205 unsigned 32 bit integers; zero is not permitted. 207 2. Encryption mechanism attributes 209 An encryption mechanism profile must define the following attributes 210 and operations. The operations must be defined as functions in the 211 mathematical sense: no additional or implicit inputs (such as 212 Kerberos principal names or message sequence numbers) are permitted. 214 protocol key format 215 This describes what octet string values represent valid keys. For 216 encryption mechanisms that don't have perfectly dense key spaces, 217 this will describe the representation used for encoding keys. It 218 need not describe specific values that are not valid or desirable 219 for use; such values should be avoid by all key generation 220 routines. 222 specific key structure 223 This is not a protocol format at all, but a description of the 224 keying material derived from the chosen key and used to encrypt or 225 decrypt data or compute or verify a checksum. It may, for 226 example, be a single key, a set of keys, or a combination of the 227 original key with additional data. The authors recommend using 228 one or more keys derived from the original key via one-way 229 functions. 231 required checksum mechanism 232 This indicates a checksum mechanism that must be available when 233 this encryption mechanism is used. Since Kerberos has no built in 234 mechanism for negotiating checksum mechanisms, once an encryption 235 mechanism has been decided upon, the corresponding checksum 236 mechanism can simply be used. 238 key-generation seed length, K 239 This is the length of the random bitstring needed to generate a 240 key with the encryption scheme's random-to-key function (described 241 below). This must be a fixed value so that various techniques for 242 producing a random bitstring of a given length may be used with 243 key generation functions. 245 key generation functions 246 Keys must be generated in a number of cases, from different types 247 of inputs. All function specifications must indicate how to 248 generate keys in the proper wire format, and must avoid generation 249 of "weak" keys if the cryptosystem has such. Entropy from each 250 source should be preserved as much as possible. Many of the 251 inputs, while unknown, may be at least partly predictable (e.g., a 252 password string is likely to be entirely in the ASCII subset and 253 of fairly short length in many environments; a semi-random string 254 may include timestamps); the benefit of such predictability to an 255 attacker must be minimized. 257 string-to-key (UTF8String, UTF8String, params)->(protocol-key) 258 This function generates a key from two UTF-8 strings and an 259 integer. One of the strings is normally the principal's 260 password, but is in general merely a secret string. The other 261 string is a "salt" string intended to produce different keys 262 from the same password for different users or realms. The 263 third argument, "params", may be used to pass mechanism- 264 specific parameters in to this function. Since doing so 265 implies knowledge of the specific encryption system, it is 266 intended that this be an uncommon operation done only through 267 special administrative interfaces, and that normal Kerberos 268 applications be able to treat this parameter block as an opaque 269 object. 271 This should be a one-way function, so that compromising a 272 user's key in one realm does not compromise the user's key in 273 another realm, even if the same password (but a different salt 274 string) is used. 276 random-to-key (bitstring[K])->(protocol-key) 277 This function generates a key from a random bit string of a 278 specific size. It may be assumed that all the bits of the 279 input string are equally random, even though the entropy 280 present in the random source may be limited. 282 combine-keys (protocol-key, protocol-key)->(protocol-key) 283 This function takes two input keys and produces a new key. 284 This function is not used in the basic Kerberos protocol, but 285 may be used by preauthentication methods or other applications 286 to be defined later. This operation must be commutative; this 287 requirement lets us specify "combine keys A and B" in other 288 documents without worrying about ordering. 290 key-derivation (protocol-key, integer)->(specific-key) 291 In this function, the integer input is the key usage value as 292 described above; the usage values must be assumed to be known 293 to an attacker. For cryptosystems with dense key spaces, this 294 function should be something like the key derivation function 295 outlined in section 1. 297 default string-to-key parameters (octet string) 298 This default value for the "params" argument to the string-to-key 299 function is to be used when the application protocol (Kerberos or 300 otherwise) does not explicitly set the parameter value. As 301 indicated above, this parameter block should be treated as an 302 opaque object in most cases. 304 cipher state 305 initial cipher state (specific-key)->(state) 306 This describes any initial state setup needed before encrypting 307 arbitrary amounts of data with a given specific key; the specific 308 key must be the only input needed for this initialization. For 309 example, a block cipher used in CBC mode must specify an initial 310 vector. (For security reasons, the key itself should not be used 311 as the IVEC.) This data may be carried over from one encryption 312 or decryption operation to another. Unless otherwise specified, 313 however, each encryption or decryption operation in this RFC uses 314 a freshly initialized state and is thus independent of all other 315 encryptions and decryptions. 317 This state should be treated as opaque in any uses outside of an 318 encryption algorithm definition. 320 encrypt (specific-key, state, bytestring)->(state, bytestring) 321 This function takes the specific key, cipher state, and plaintext 322 as input, and generates ciphertext and a new cipher state as 323 outputs. If the basic encryption algorithm itself does not 324 provide for integrity protection (as DES in CBC mode does not do), 325 then some form of MAC or checksum must be included that can be 326 verified by the receiver. Some random factor such as a confounder 327 should be included so that an observer cannot know if two messages 328 contain the same plaintext, even if the cipher state and specific 329 keys are the same. The exact length of the plaintext need not be 330 encoded, but if it is not and if padding is required, the padding 331 must be added at the end of the string so that the decrypted 332 version may be parsed from the beginning. 334 The specification of the encryption function must not only 335 indicate the precise contents of the output bytestring, but also 336 the output cipher state, if that state is not empty. The 337 application protocol may carry forward the output cipher state 338 from one encryption with a given specific key to another; the 339 effect of this "chaining" must be defined, even if only to say 340 that it has no effect. 342 Assuming correctly-produced values for the specific key and cipher 343 state, no input byte string may result in an error indication. 345 decrypt (specific-key, state, bytestring)->(state, bytestring) 346 This function takes the specific key, cipher state, and ciphertext 347 as inputs, and verifies the integrity of the supplied ciphertext. 348 If the ciphertext's integrity is intact, this function produces 349 the plaintext and a new cipher state as outputs; otherwise, an 350 error indication must be returned, and the data discarded. 352 The result of the decryption may be longer than the original 353 plaintext, if the encryption mode requires padding to a multiple 354 of a block size. If this is the case, any extra padding will be 355 after the decoded plaintext. An application protocol which needs 356 to know the exact length of the message must encode a length or 357 recognizable "end of message" marker within the plaintext. [2] 359 As with the encryption function, a correct specification for this 360 function must indicate not only the contents of the output byte 361 string, but also the resulting cipher state. 363 These operations and attributes are all that should be required to 364 support Kerberos and various proposed preauthentication schemes. 366 3. Checksum mechanism attributes 368 A checksum mechanism profile must define the following attributes and 369 operations: 371 associated encryption algorithm(s) 372 This essentially indicates the type of encryption key this 373 checksum mechanism can be used with. A single checksum mechanism 374 may have more than one associated encryption algorithm if they 375 share the same wire key format, string-to-key function, and key 376 derivation function. (This combination means that, for example, a 377 checksum type and password are adequate to get the specific key 378 used to compute a checksum.) 380 get_mic function 381 This function generates a MIC token for a given specific key (see 382 section 2), and message (represented as an octet string), that may 383 be used to verify the integrity of the associated message. This 384 function is not required to return the same deterministic result 385 on every use; it need only generate a token that the verify_mic 386 routine can check. 388 The output of this function will also dictate the size of the 389 checksum. It must be a fixed size. 391 verify_mic function 392 Given a specific key, message, and MIC token, this function 393 ascertains whether the message integrity has been compromised. 394 For a deterministic get_mic routine, the corresponding verify_mic 395 may simply generate another checksum and compare them. 397 The get_mic and verify_mic operations must be able to handle inputs 398 of arbitrary length; if any padding is needed, the padding scheme 399 must be specified as part of these functions. 401 These operations and attributes are all that should be required to 402 support Kerberos and various proposed preauthentication schemes. 404 4. Simplified profile for CBC-mode ciphers with key derivation 406 The profile outlines in sections 2 and 3 describes a large number of 407 operations that must be defined for encryption and checksum 408 algorithms to be used with Kerberos. We describe here a simpler 409 profile from which both encryption and checksum mechanism definitions 410 can be generated, filling in uses of key derivation in appropriate 411 places, providing integrity protection, and defining multiple 412 operations for the cryptosystem profile based on a smaller set of 413 operations given in the simplified profile. Not all of the existing 414 cryptosystems for Kerberos fit into this simplified profile, but we 415 recommend that future cryptosystems use it or something based on it. 416 [3] 418 Not all of the operations in the complete profiles are defined 419 through this mechanism; several must still be defined for each new 420 algorithm pair. 422 4.1. A key derivation function [Horowitz] 424 Rather than define some scheme by which a "protocol key" is composed 425 of a large number of encryption keys, we use keys derived from a base 426 key to perform cryptographic operations. The base key must be used 427 only for generating the derived keys, and this derivation must be 428 non-invertible and entropy-preserving. Given these restrictions, 429 compromise of one derived key does not compromise the other subkeys. 430 Attack of the base key is limited, since it is only used for 431 derivation, and is not exposed to any user data. 433 Since the derived key has as much entropy as the base keys (if the 434 cryptosystem is good), password-derived keys have the full benefit of 435 all the entropy in the password. 437 To generate a derived key from a base key, we generate a pseudorandom 438 byte string, using an algorithm DR described below, and generate a 439 key from that byte string using a function dependent on the 440 encryption algorithm; the input length needed for that function, 441 which is also dependent on the encryption algorithm, dictates the 442 length of the string to be generated by the DR algorithm (the value 443 "k" below). 445 Derived Key = DK(Base Key, Well-Known Constant) 447 DK(Key, Constant) = random-to-key(DR(Key, Constant)) 449 DR(Key, Constant) = k-truncate(E(Key, Constant)) 451 Here DR is the random-byte generation function described below, and 452 DK is the key-derivation function produced from it. In this 453 construction, E(Key, Plaintext) is a block cipher, Constant is a 454 well-known constant determined by the specific usage of this 455 function, and k-truncate truncates its argument by taking the first k 456 bits. Here, k is the key generation seed length needed for the 457 encryption system. 459 The output of the DR function is a string of bits; the actual key is 460 produced by applying the cryptosystem's random-to-key operation on 461 this bitstring. 463 If the output of E is shorter than k bits, then some entropy in the 464 key will be lost. If the Constant is smaller than the block size of 465 E, then it must be padded so it may be encrypted. 467 In either of these situations, a variation of the above construction 468 is used, where the folded Constant is encrypted, and the resulting 469 output is fed back into the encryption as necessary (the | indicates 470 concatentation): 472 K1 = E(Key, n-fold(Constant)) 473 K2 = E(Key, K1) 474 K3 = E(Key, K2) 475 K4 = ... 477 DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...) 479 n-fold is an algorithm which takes m input bits and ``stretches'' 480 them to form n output bits with equal contribution from each input 481 bit to the output, as described in [Blumenthal96]: 483 We first define a primitive called n-folding, which takes a 484 variable-length input block and produces a fixed-length output 485 sequence. The intent is to give each input bit approximately 486 equal weight in determining the value of each output bit. Note 487 that whenever we need to treat a string of bytes as a number, the 488 assumed representation is Big-Endian -- Most Significant Byte 489 first. 491 To n-fold a number X, replicate the input value to a length that 492 is the least common multiple of n and the length of X. Before 493 each repetition, the input is rotated to the right by 13 bit 494 positions. The successive n-bit chunks are added together using 495 1's-complement addition (that is, with end-around carry) to yield 496 a n-bit result.... 498 Test vectors for n-fold are supplied in Appendix A. [4] 500 In this document, n-fold is always used to produce n bits of output, 501 where n is the block size of E. 503 The size of the Constant must not be larger than the block size of E, 504 because reducing the length of the Constant by n-folding can cause 505 collisions. 507 If the size of the Constant is smaller than the block size of E, then 508 the Constant must be n-folded to the block size of E. This string is 509 used as input to E. If the block size of E is less than the key 510 size, then the output from E is taken as input to a second invocation 511 of E. This process is repeated until the number of bits accumulated 512 is greater than or equal to the key size of E. When enough bits have 513 been computed, the first k are taken as the derived key. 515 Since the derived key is the result of one or more encryptions in the 516 base key, deriving the base key from the derived key is equivalent to 517 determining the key from a very small number of plaintext/ciphertext 518 pairs. Thus, this construction is as strong as the cryptosystem 519 itself. 521 4.2. Simplified profile parameters 523 These are the operations and attributes that must be defined: 525 protocol key format 526 string-to-key function 527 default string-to-key parameters 528 key-generation seed length, k 529 random-to-key function 530 As above for the normal encryption mechanism profile. 532 unkeyed hash algorithm, H 533 This should be a collision-resistant hash algorithm such as SHA-1, 534 suitable for use in an HMAC. It must support inputs of arbitrary 535 length. 537 encryption block size, n 538 encryption/decryption functions, E and D 539 These are basic encryption and decryption functions for messages 540 of sizes that are multiples of the block size. No integrity 541 checking or confounder should be included here. They take as 542 input the IV or similar data, a protocol-format key, and a byte 543 string, returning a new IV and byte string. 545 The encryption function is not required to use CBC mode, but is 546 assumed to be using something with similar properties. In 547 particular, prepending a one-block confounder to the plaintext 548 should alter the entire ciphertext (comparable to choosing and 549 including a random initial vector for CBC mode). 551 While there are still a number of properties to specify, they are 552 fewer and simpler than in the full profile. 554 4.3. Cryptosystem profile based on simplified profile 556 cryptosystem from simplified profile 557 ---------------------------------------------------------------------- 558 protocol key format As given. 560 specific key structure Three protocol-format keys: { Kc, Ke, Ki }. 562 key-generation seed As given. 563 length 565 required checksum The checksum mechanism defined by the 566 mechanism simplified checksum profile given later. 568 cipher state CBC initial vector (one block), initialized 569 to all zero. 571 encryption function The ciphertext output is the concatenation 572 of the output of the basic encryption 573 function E and an HMAC using the specified 574 hash function H, both applied to the padded 575 plaintext with a confounder: 577 C1 = E(Ke, conf | plaintext | pad) 578 H1 = HMAC(Ki, conf | plaintext | pad) 579 ciphertext = C1 | H1 580 newstate.ivec = last block of C1 582 One block of random confounder data is 583 prepended to the plaintext, and padding 584 added to the end to bring the length to a 585 multiple of the encryption algorithm's 586 block size. The initial vector for 587 encryption is supplied by the cipher state, 588 and the last block of the output of E is 589 the new IVEC for the new cipher state. 591 cryptosystem from simplified profile 592 ---------------------------------------------------------------------- 593 decryption function Decryption is performed by extracting the 594 encrypted portion of the ciphertext, 595 decrypting using key Ke from the specific 596 key, and verifying the HMAC. If the HMAC 597 is incorrect, an error must be reported. 598 Otherwise, the confounder and padding are 599 discarded and the remaining plaintext 600 returned. As with encryption, the cipher 601 state input indicates the IVEC to use, and 602 the last block of the encrypted portion of 603 the ciphertext is put into the new cipher 604 state to be used as the next IVEC. 606 default string-to-key As given. 607 params 609 key generation functions: 611 string-to-key function As given. 613 random-to-key function As given. 615 combine-keys function @@ Needs to be specified. How about: 617 combine-keys(K1,K2) 618 /* First, protect original keys against 619 exposure with DR. */ 620 R1 = DR(K1, n-fold(K2)) /* length k */ 621 R2 = DR(K2, n-fold(K1)) /* length k */ 622 /* Using k-fold on length 2k means 623 just add with wrap-around carry. */ 624 rnd = k-fold(R1 | R2) 625 tkey = random-to-key(rnd) 626 key = DK(tkey, CombineConstant) 628 Here CombineConstant is the byte string 629 {0x63 0x6f 0x6d 0x62 0x69 0x6e 0x65} 630 corresponding to the ASCII encoding of the 631 string "combine". 633 @@ Need a cryptographer to review this. 634 Asked Uri Blumenthal, he said he'd look it 635 over when he has time. Have some 636 suggestions from him, not incorporated yet. 638 cryptosystem from simplified profile 639 ---------------------------------------------------------------------- 640 key-derivation function Three keys are generated, using the DK 641 function described above, and the key usage 642 number, represented as a 32-bit integer in 643 big-endian byte order. One is used for 644 generating checksums only; the other two 645 are used for encrypting and integrity 646 protection for ciphertext. These keys are 647 generated as follows: 649 Kc = DK(base-key, usage | 0x99); 650 Ke = DK(base-key, usage | 0xAA); 651 Ki = DK(base-key, usage | 0x55); 653 4.4. Checksum profiles based on simplified profile 655 When an encryption system is defined using the simplified profile 656 given in section 4.2, a checksum algorithm may be defined for it as 657 follows: 659 checksum mechanism from simplified profile 660 ---------------------------------------------- 661 associated cryptosystem as defined above 663 get_mic HMAC(Kc, message) 665 verify_mic get_mic and compare 667 The HMAC function and key Kc are as described in section 4.3. 669 5. Profiles for Kerberos encryption systems 671 These are the currently defined encryption systems for Kerberos. The 672 astute reader will notice that some of them do not fulfill all of the 673 requirements outlined above. These weaker encryption systems are 674 defined for backwards compatibility; newer implementations should 675 attempt to make use of the stronger encryption systems when possible. 677 The full list of current encryption type number assignments is given 678 in section 8. 680 5.1. null 682 If no encryption is in use, the encryption system is said to be the 683 NULL encryption system. In the NULL encryption system there is no 684 checksum, confounder or padding. The ciphertext is simply the 685 plaintext. The null Key is used by the null encryption system and is 686 zero octets in length. 688 This encryption system should not be used for protection of data. It 689 exists primarily to associate with the rsa-md5 checksum type, but may 690 also be useful for testing protocol implementations. 692 null 693 ------------------------------------------------ 694 protocol key format zero-length bit string 696 specific key structure empty 698 required checksum rsa-md5 699 mechanism 701 key-generation seed 0 702 length 704 cipher state none 706 initial cipher state none 708 encryption function identity 710 decryption function identity, no integrity 711 check 713 default string-to-key none 714 params 716 key generation functions: 718 string-to-key empty string 720 random-to-key empty string 722 combine-keys empty string 724 key-derivation empty string 726 The null encryption algorithm is assigned the etype value zero (0). 728 5.2. DES-based encryption systems 730 These encryption systems encrypt information under the Data 731 Encryption Standard [DES77] using the cipher block chaining mode 732 [DESM80]. A checksum is computed as described below and placed in 733 the cksum field. DES blocks are 8 bytes. As a result, the data to 734 be encrypted (the concatenation of confounder, checksum, and message) 735 must be padded to an 8 byte boundary before encryption. The values 736 of the padding bytes are unspecified. 738 Plaintext and DES ciphtertext are encoded as blocks of 8 octets which 739 are concatenated to make the 64-bit inputs for the DES algorithms. 740 The first octet supplies the 8 most significant bits (with the 741 octet's MSbit used as the DES input block's MSbit, etc.), the second 742 octet the next 8 bits, ..., and the eighth octet supplies the 8 least 743 significant bits. 745 Encryption under DES using cipher block chaining requires an 746 additional input in the form of an initialization vector; this vector 747 is specified for each encryption system, below. 749 The DES specifications identify some 'weak' and 'semi-weak' keys; 750 those keys shall not be used for encrypting messages for use in 751 Kerberos. Additionally, because of the way that keys are derived for 752 the encryption of checksums, keys shall not be used that yield 'weak' 753 or 'semi-weak' keys when eXclusive-ORed with the hexadecimal constant 754 0xF0F0F0F0F0F0F0F0. 756 A DES key is 8 octets of data. This consists of 56 bits of actual 757 key data, and 8 parity bits, one per octet. The key is encoded as a 758 series of 8 octets written in MSB-first order. The bits within the 759 key are also encoded in MSB order. For example, if the encryption 760 key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) 761 where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 762 are the parity bits, the first octet of the key would be 763 B1,B2,...,B7,P1 (with B1 as the MSbit). See the [DESM80] 764 introduction for reference. 766 Encryption data format 768 The format for the data to be encrypted includes a one-block 769 confounder, a checksum, the encoded plaintext, and any necessary 770 padding, as described in the following diagram. The msg-seq field 771 contains the part of the protocol message described in section 5 772 which is to be encrypted. 774 +-----------+----------+---------+-----+ 775 |confounder | checksum | msg-seq | pad | 776 +-----------+----------+---------+-----+ 778 One generates a random confounder of one block, placing it in 779 confounder; zeroes out the checksum field (of length appropriate to 780 exactly hold the checksum to be computed); calculates the appropriate 781 checksum over confounder, check, and msg-seq, placing the result in 782 check; adds the necessary padding; then encrypts using the specified 783 encryption type and the appropriate key. 785 String to key transformation 787 To generate a DES key from a UTF-8 text string (password), a "salt" 788 is concatenated to the text string, and then padded with ASCII nulls 789 to an 8 byte boundary. 791 This string is then fan-folded and eXclusive-ORed with itself to form 792 an 8 byte DES key. Before eXclusive-ORing a block, every byte is 793 shifted one bit to the left to leave the lowest bit zero. The key is 794 the "corrected" by correcting the parity on the key, and if the key 795 matches a 'weak' or 'semi-weak' key as described in the DES 796 specification, it is eXclusive-ORed with the constant 797 0x00000000000000F0. This key is then used to generate a DES CBC 798 checksum on the initial string (with the salt appended). The result 799 of the CBC checksum is the "corrected" as described above to form the 800 result which is return as the key. 802 Pseudocode follows: 804 key_correction(key) { 805 fixparity(key); 806 if (is_weak_key_key(key)) 807 key = key XOR 0xF0; 808 return(key); 809 } 810 mit_des_string_to_key(string,salt) { 811 odd = 1; 812 s = string | salt; 813 tempkey = NULL; 814 pad(s); /* with nulls to 8 byte boundary */ 815 for (8byteblock in s) { 816 if (odd == 0) { 817 odd = 1; 818 reverse(8byteblock) 819 } 820 else odd = 0; 821 left shift every byte in 8byteblock one bit; 822 tempkey = tempkey XOR 8byteblock; 823 } 824 tempkey = key_correction(tempkey); 825 key = key_correction(DES-CBC-check(s,tempkey)); 826 return(key); 827 } 829 des_string_to_key(string,salt,params) { 830 if (length(params) == 0) 831 type = 0; 832 else if (length(params) == 1) 833 type = params[0]; 834 else 835 error("invalid params"); 836 if (type == 0) 837 mit_des_string_to_key(string,salt); 838 else if (type == 1) 839 afs_des_string_to_key(string,salt); 840 else 841 error("invalid params"); 842 } 844 The AFS string-to-key algorithm is not defined here, but a parameter 845 block containing a byte value of one (1) is reserved for its use. 847 5.2.1. DES with MD5 849 The des-cbc-md5 encryption mode encrypts information under DES in CBC 850 mode with an all-zero initial vector, with an MD5 checksum (described 851 in [MD5-92]) computed and placed in the checksum field. 853 The encryption system parameters for des-cbc-md5 are: 855 des-cbc-md5 856 -------------------------------------------------------------------- 857 protocol key format 8 bytes, parity in low bit of each 859 specific key structure copy of original key 861 required checksum rsa-md5-des 862 mechanism 864 key-generation seed 8 bytes 865 length 867 cipher state 8 bytes (CBC initial vector) 869 initial cipher state all-zero 871 encryption function des-cbc(confounder | checksum | msg | pad, 872 ivec=oldstate) 873 where 874 checksum = md5(confounder | 0000... | msg) 876 newstate = last block of des-cbc output 878 decryption function decrypt encrypted text and verify checksum 880 newstate = last block of ciphertext 882 default string-to-key empty string 883 params 885 key generation functions: 887 string-to-key des_string_to_key 889 random-to-key copy input, then fix parity bits (discards 890 low bit of each input byte) 892 combine-keys bitwise XOR, then fix parity bits 894 key-derivation identity 896 The des-cbc-md5 encryption type is assigned the etype value three 897 (3). 899 5.2.2. DES with MD4 901 The des-cbc-md4 encryption mode also encrypts information under DES 902 in CBC mode, with an all-zero initial vector. An MD4 checksum 903 (described in [MD4-92]) is computed and placed in the checksum field. 905 des-cbc-md4 906 -------------------------------------------------------------------- 907 protocol key format 8 bytes, parity in low bit of each 909 specific key structure copy of original key 911 required checksum rsa-md4-des 912 mechanism 914 key-generation seed 8 bytes 915 length 917 cipher state 8 bytes (CBC initial vector) 919 initial cipher state all-zero 921 encryption function des-cbc(confounder | checksum | msg | pad, 922 ivec=oldstate) 923 where 924 checksum = md4(confounder | 0000... | msg) 926 newstate = last block of des-cbc output 928 decryption function decrypt encrypted text and verify checksum 930 newstate = last block of ciphertext 932 default string-to-key empty string 933 params 935 key generation functions: 937 string-to-key des_string_to_key 939 random-to-key copy input, then fix parity bits 941 combine-keys bitwise XOR, then fix parity bits 943 key-derivation identity 945 The des-cbc-md4 encryption algorithm is assigned the etype value two 946 (2). 948 5.2.3. DES with CRC 950 The des-cbc-crc encryption type uses DES in CBC mode, with a 4-octet 951 CRC-based checksum computed as described in section 6.4. (Note that 952 this is not a standard CRC-32 checksum, but a slightly modified one.) 954 Unless otherwise specified, the key should be used as the 955 initialization vector, unlike for the other Kerberos DES encryption 956 schemes. The other details of the encryption of this data are 957 identical to those for the des-cbc-md5 encryption mode. 959 Note that, since the CRC-32 checksum is not collision-proof, an 960 attacker could use a probabilistic chosen-plaintext attack to 961 generate a valid message even if a confounder is used [SG92]. The 962 use of collision-proof checksums is recommended for environments 963 where such attacks represent a significant threat. 965 des-cbc-crc 966 -------------------------------------------------------------------- 967 protocol key format 8 bytes, parity in low bit of each 969 specific key structure copy of original key 971 required checksum rsa-md5-des 972 mechanism 974 key-generation seed 8 bytes 975 length 977 cipher state 8 bytes (CBC initial vector) 979 initial cipher state copy of original key 981 encryption function des-cbc(confounder | checksum | msg | pad, 982 ivec=oldstate) 983 where 984 checksum = crc(confounder | 00000000 985 | msg) 987 newstate = last block of des-cbc output 989 decryption function decrypt encrypted text and verify checksum 991 newstate = last block of ciphertext 992 des-cbc-crc 993 -------------------------------------------------------------------- 995 default string-to-key empty string 996 params 998 key generation functions: 1000 string-to-key des_string_to_key 1002 random-to-key copy input, then fix parity bits 1004 combine-keys bitwise XOR, then fix parity bits 1006 key-derivation identity 1008 The des-cbc-crc encryption algorithm is assigned the etype value one 1009 (1). 1011 5.3. Triple-DES Encryption with Key Derivation 1013 This encryption type is based on the Triple DES cryptosystem in 1014 Outer-CBC mode, and the HMAC-SHA1 [Krawczyk96] message authentication 1015 algorithm. 1017 A Triple DES key is the concatenation of three DES keys as described 1018 above for des-cbc-md5. A Triple DES key is generated from random 1019 data by creating three DES keys from separate sequences of random 1020 data. 1022 EncryptedData using this type must be generated as described in 1023 section 4.3. If the length of the input data is not a multiple of 1024 the block size, zero octets must be used to pad the plaintext to the 1025 next eight-octet boundary. The counfounder must be eight random 1026 octets (one block). 1028 The simplified profile for Triple DES, with key derivation as defined 1029 in section 4, is as follows: 1031 des3-cbc-hmac-sha1-kd 1032 ------------------------------------------------ 1033 protocol key format 24 bytes, parity in low 1034 bit of each 1036 key-generation seed 21 bytes 1037 length 1038 des3-cbc-hmac-sha1-kd 1039 ------------------------------------------------ 1041 hash function SHA-1 1043 block size 8 bytes 1045 default string-to-key none 1046 params 1048 encryption decryption functions 1050 key generation functions: 1052 random-to-key see below 1054 string-to-key DES3string-to-key (see 1055 below) 1057 The des3-cbc-hmac-sha1-kd encryption type is assigned the value 1058 sixteen (16). 1060 5.3.1. Triple DES Key Production (random-to-key, string-to-key) 1062 The 168 bits of random key data are converted to a protocol key value 1063 as follows. First, the 168 bits are divided into three groups of 56 1064 bits, which are expanded individually into 64 bits as follows: 1066 1 2 3 4 5 6 7 p 1067 9 10 11 12 13 14 15 p 1068 17 18 19 20 21 22 23 p 1069 25 26 27 28 29 30 31 p 1070 33 34 35 36 37 38 39 p 1071 41 42 43 44 45 46 47 p 1072 49 50 51 52 53 54 55 p 1073 56 48 40 32 24 16 8 p 1075 The "p" bits are parity bits computed over the data bits. The output 1076 of the three expansions are concatenated to form the protocol key 1077 value. 1079 When the HMAC-SHA1 of a string is computed, the key is used in the 1080 protocol key form. 1082 The string-to-key function is used to tranform UTF-8 passwords into 1083 DES3 keys. The DES3 string-to-key function relies on the "N-fold" 1084 algorithm and DK function, described in section 4. 1086 The n-fold algorithm is applied to the password string concatenated 1087 with a salt value. For 3-key triple DES, the operation will involve 1088 a 168-fold of the input password string, to generate an intermediate 1089 key, from which the user's long-term key will be derived with the DK 1090 function. The DES3 string-to-key function is shown here in 1091 pseudocode: 1093 DES3string-to-key(passwordString, salt, params) 1094 if (params != emptyString) 1095 error("invalid params"); 1096 s = passwordString + salt 1097 tmpKey = random-to-key(168-fold(s)) 1098 key = DK (tmpKey, KerberosConstant) 1100 No weak-key checking is performed. The KerberosConstant value is the 1101 byte string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values 1102 correspond to the ASCII encoding for the string "kerberos". 1104 6. Profiles for Kerberos checksums 1106 These are the checksum types currently defined for Kerberos. The 1107 full list of current checksum type number assignments is given in 1108 section 8. 1110 6.1. RSA MD4 Cryptographic Checksum Using DES 1112 The RSA-MD4-DES checksum calculates a keyed collision-proof checksum 1113 by prepending an 8 octet confounder before the text, applying the RSA 1114 MD4 checksum algorithm [MD4-92], and encrypting the confounder and 1115 the checksum using DES in cipher-block-chaining (CBC) mode using a 1116 variant of the key, where the variant is computed by eXclusive-ORing 1117 the key with the constant 0xF0F0F0F0F0F0F0F0 [@@REF 39]. The 1118 initialization vector should be zero. The resulting checksum is 24 1119 octets long. This checksum is tamper-proof and believed to be 1120 collision-proof. 1122 The DES specifications identify some weak keys' and 'semi-weak keys'; 1123 those keys shall not be used for generating RSA-MD4 checksums for use 1124 in Kerberos. 1126 rsa-md4-des 1127 ---------------------------------------------------------------- 1128 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1130 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, 1131 conf | rsa-md4(conf | msg), 1132 ivec=0) 1134 rsa-md4-des 1135 ---------------------------------------------------------------- 1137 verify_mic decrypt and verify rsa-md4 checksum 1139 The rsa-md4-des checksum algorithm is assigned a checksum type number 1140 of three (3). 1142 6.2. The RSA MD5 Checksum 1144 The RSA-MD5 checksum calculates a checksum using the RSA MD5 1145 algorithm [MD5-92]. The algorithm takes as input an input message of 1146 arbitrary length and produces as output a 128-bit (16 octet) 1147 checksum. RSA-MD5 is believed to be collision-proof. However, since 1148 it is unkeyed, it must be used with caution. Currently it is used by 1149 some implementations in places where the checksum itself is part of a 1150 larger message that will be encrypted. Its use is not recommended. 1152 rsa-md5 1153 ---------------------------------------------- 1154 associated cryptosystem null 1156 get_mic rsa-md5(msg) 1158 verify_mic get_mic and compare 1160 The rsa-md5 checksum algorithm is assigned a checksum type number of 1161 seven (7). 1163 6.3. RSA MD5 Cryptographic Checksum Using DES 1165 The RSA-MD5-DES checksum calculates a keyed collision-proof checksum 1166 by prepending an 8 octet confounder before the text, applying the RSA 1167 MD5 checksum algorithm, and encrypting the confounder and the 1168 checksum using DES in cipher-block-chaining (CBC) mode using a 1169 variant of the key, where the variant is computed by eXclusive-ORing 1170 the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0. The 1171 initialization vector should be zero. The resulting checksum is 24 1172 octets long. This checksum is tamper-proof and believed to be 1173 collision-proof. 1175 The DES specifications identify some 'weak keys' and 'semi-weak 1176 keys'; those keys shall not be used for encrypting RSA-MD5 checksums 1177 for use in Kerberos. 1179 The format for the checksum is described in the following diagram: 1181 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1182 | des-cbc(confounder+rsa-md5(confounder+msg), key=var(key), iv=0) | 1183 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1185 rsa-md5-des 1186 ---------------------------------------------------------------- 1187 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1189 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, 1190 conf | rsa-md5(conf | msg)) 1192 verify_mic decrypt and verify rsa-md5 checksum 1194 The rsa-md5-des checksum algorithm is assigned a checksum type number 1195 of eight (8). 1197 6.4. The CRC-32 Checksum 1199 This CRC-32 checksum calculates a checksum based on a cyclic 1200 redundancy check as described in ISO 3309 [ISO3309], modified as 1201 described below. The resulting checksum is four (4) octets in 1202 length. The CRC-32 is neither keyed nor collision-proof; thus, the 1203 use of this checksum is not recommended. An attacker using a 1204 probabilistic chosen-plaintext attack as described in [@@REF 13??] 1205 might be able to generate an alternative message that satisfies the 1206 checksum. The use of collision-proof checksums is recommended for 1207 environments where such attacks represent a significant threat. 1209 The CRC-32 checksum used in the des-cbc-crc encryption mode is 1210 identical to the 32-bit FCS described in ISO 3309 with two 1211 exceptions: the sum with the all-ones polynomial times x**k is 1212 omitted, and the final remainder is not ones-complemented. ISO 3309 1213 describes the FCS in terms of bits, while this document describes the 1214 Kerberos protocol in terms of octets. To disambiguate the ISO 3309 1215 definition for the purpose of computing the CRC-32 in the des-cbc-crc 1216 encryption mode, the ordering of bits in each octet shall be assumed 1217 to be LSB-first. Given this assumed ordering of bits within an 1218 octet, the mapping of bits to polynomial coefficients shall be 1219 identical to that specified in ISO 3309. 1221 crc32 1222 ------------------------------------------------ 1223 associated cryptosystem des-cbc-md5, des-cbc- 1224 md4, des-cbc-crc 1226 get_mic crc32(msg) 1228 verify_mic compute checksum and 1229 compare 1231 The crc32 checksum algorithm is assigned a checksum type number of 1232 one (1). 1234 6.5. The RSA MD4 Checksum 1236 The RSA-MD4 checksum calculates a checksum using the RSA MD4 1237 algorithm [MD4-92]. The algorithm takes as input an input message of 1238 arbitrary length and produces as output a 128-bit (16 octet) 1239 checksum. RSA-MD4 is believed to be collision-proof. 1241 rsa-md4 1242 ------------------------------------------------ 1243 associated cryptosystem des-cbc-md5, des-cbc- 1244 md4, des-cbc-crc 1246 get_mic md4(msg) 1248 verify_mic compute checksum and 1249 compare 1251 The rsa-md4 checksum algorithm is assigned a checksum type number of 1252 two (2). 1254 6.6. DES CBC checksum 1256 The DES-MAC checksum is computed by prepending an 8 octet confounder 1257 to the plaintext, performing a DES CBC-mode encryption on the result 1258 using the key and an initialization vector of zero, taking the last 1259 block of the ciphertext, prepending the same confounder and 1260 encrypting the pair using DES in cipher-block-chaining (CBC) mode 1261 using a a variant of the key, where the variant is computed by 1262 eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0. The 1263 initialization vector should be zero. The resulting checksum is 128 1264 bits (16 octets) long, 64 bits of which are redundant. This checksum 1265 is tamper-proof and collision-proof. 1267 The DES specifications identify some "weak" and "semiweak" keys; 1268 those keys shall not be used for generating DES-MAC checksums for use 1269 in Kerberos, nor shall a key be used whose variant is "weak" or 1270 "semi-weak". 1272 des-mac 1273 ---------------------------------------------------------------- 1274 associated des-cbc-md5, des-cbc-md4, des-cbc-crc 1275 cryptosystem 1277 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, 1278 conf | des-mac(key, conf | msg, ivec=0), 1279 ivec=0) 1281 verify_mic decrypt, compute DES MAC using confounder, 1282 compare 1284 The des-mac checksum algorithm is assigned a checksum type number of 1285 four (4). 1287 6.7. RSA MD4 Cryptographic Checksum Using DES alternative 1289 The RSA-MD4-DES-K checksum calculates a keyed collision-proof 1290 checksum by applying the RSA MD4 checksum algorithm and encrypting 1291 the results using DES in cipherblock-chaining (CBC) mode using a DES 1292 key as both key and initialization vector. The resulting checksum is 1293 16 octets long. This checksum is tamper-proof and believed to be 1294 collision-proof. Note that this checksum type is the old method for 1295 encoding the RSA-MD4-DES checksum and it is no longer recommended. 1297 rsa-md4-des-k 1298 ---------------------------------------------------------------- 1299 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1301 get_mic des-cbc(key, md4(msg), ivec=key) 1303 verify_mic compute CRC-32 and compare 1305 The rsa-md4-des-k checksum algorithm is assigned a checksum type 1306 number of six (6). 1308 6.8. DES CBC checksum alternative 1310 The DES-MAC-K checksum is computed by performing a DES CBC-mode 1311 encryption of the plaintext, and using the last block of the 1312 ciphertext as the checksum value. It is keyed with an encryption key 1313 and an initialization vector; any uses which do not specify an 1314 additional initialization vector will use the key as both key and 1315 initialization vector. The resulting checksum is 64 bits (8 octets) 1316 long. This checksum is tamper-proof and collision-proof. Note that 1317 this checksum type is the old method for encoding the DESMAC checksum 1318 and it is no longer recommended. 1320 The DES specifications identify some "weak keys"; those keys shall 1321 not be used for generating DES-MAC checksums for use in Kerberos. 1323 des-mac-k 1324 ---------------------------------------------------------------- 1325 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc 1327 get_mic des-mac(key, msg, ivec=key or given) 1329 verify_mic compute MAC and compare 1331 The des-mac-k checksum algorithm is assigned a checksum type number 1332 of five (5). 1334 6.9. The HMAC-SHA1-DES3-KD Checksum 1336 This checksum type is defined as outlined in section 3 above, using 1337 the des3-hmac-sha1-kd encryption algorithm parameters from section 1338 5.3. The checksum is thus a SHA-1 HMAC using the computed key Kc 1339 over the message to be protected. 1341 The hmac-sha1-des3-kd checksum algorithm is assigned a checksum type 1342 number of twelve (12). 1344 7. Use of Kerberos encryption outside this specification 1346 Several Kerberos-based application protocols and preauthentication 1347 systems have been designed and deployed that perform encryption and 1348 message integrity checks in various ways. While in some cases there 1349 may be good reason for specifying these protocols in terms of 1350 specific encryption or checksum algorithms, we anticipate that in 1351 many cases this will not be true, and more generic approaches 1352 independent of particular algorithms will be desirable. Rather than 1353 having each protocol designer reinvent schemes for protecting data, 1354 using multiple keys, etc, we have attempted to present in this 1355 section a general framework that should be sufficient not only for 1356 the Kerberos protocol itself but also for many preauthentication 1357 systems and application protocols, while trying to avoid some of the 1358 assumptions that can work their way into such protocol designs. 1360 Some problematic assumptions we've seen, and sometimes made, include: 1361 that a random bitstring is always valid as a key (not true for DES 1362 keys with parity); that the basic block encryption chaining mode 1363 provides no integrity checking, or can easily be separated from such 1364 checking (not true for many modes in development that do both 1365 simultaneously); that a checksum for a message always results in the 1366 same value (not true if a confounder is incorporated); that an 1367 initial vector is used (may not be true if a block cipher in CBC mode 1368 is not in use); that the key is a clever thing to use as the initial 1369 vector for CBC mode encryption (not true @@REF Bellovin paper). 1371 Such assumptions, while they may hold for any given set of encryption 1372 and checksum algorithms, may not be true of the next algorithms to be 1373 defined, leaving the application protocol unable to make use of those 1374 algorithms without updates to its specification. 1376 The Kerberos protocol uses only the attributes and operations 1377 described in sections 2 and 3. Preauthentication systems and 1378 application protocols making use of Kerberos are encouraged to use 1379 them as well. The specific key and string-to-key parameters should 1380 generally be treated as opaque. While the string-to-key parameters 1381 are manipulated as an octet string, the representation for the 1382 specific key structure is implementation-defined; it may not even be 1383 a single object. 1385 While we don't recommend it, some application protocols will 1386 undoubtedly continue to use the key data directly, even if only in 1387 some of the currently existing protocol specifications. An 1388 implementation intended to support general Kerberos applications may 1389 therefore need to make the key data available, as well as the 1390 attributes and operations described in sections 2 and 3. [5] 1392 8. Assigned Numbers 1394 The following encryption type numbers are already assigned or 1395 reserved for use in Kerberos and related protocols. 1397 Encryption type etype block minimum confounder section 1398 value size pad size size 1399 ---------------------------------------------------------------------- 1400 NULL 0 1 0 0 5.1 1401 des-cbc-crc 1 8 4 8 5.2.3 1402 des-cbc-md4 2 8 0 8 5.2.2 1403 des-cbc-md5 3 8 0 8 5.2.1 1404 des3-cbc-sha1-kd 16 8 0 8 5.3 1406 Other numbers have been reserved for use in encryption systems not 1407 defined here. Encryption type numbers are unfortunately overloaded 1408 on occasion in Kerberos-related protocols, so some of the reserved 1409 numbers do not and will not correspond to encryption systems fitting 1410 the profile presented here. 1412 Encryption type etype value comment 1413 ---------------------------------------------------------------------- 1414 [reserved] 4 1415 des3-cbc-md5 5 1416 [reserved] 6 1417 des3-cbc-sha1 7 1418 dsaWithSHA1-CmsOID 9 (pkinit) 1419 md5WithRSAEncryption-CmsOID 10 (pkinit) 1420 sha1WithRSAEncryption-CmsOID 11 (pkinit) 1421 rc2CBC-EnvOID 12 (pkinit) 1422 rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5) 1423 rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0) 1424 des-ede3-cbc-Env-OID 15 (pkinit) 1425 rc4-hmac 23 (swift) 1426 rc4-hmac-exp 24 (swift) 1427 subkey-keynaterial 65 (opaque mhur) 1429 The following checksum type numbers are assigned or reserved. As 1430 with encryption type numbers, some overloading of checksum numbers 1431 has occurred. 1433 Checksum type sumtype checksum section 1434 value size 1435 ---------------------------------------------------------------------- 1436 CRC32 1 4 6.4 1437 rsa-md4 2 16 6.5 1438 rsa-md4-des 3 24 6.1 1439 des-mac 4 16 6.6 1440 des-mac-k 5 8 6.8 1441 rsa-md4-des-k 6 16 6.7 1442 rsa-md5 7 16 6.2 1443 rsa-md5-des 8 24 6.3 1444 rsa-md5-des3 9 24 1445 hmac-sha1-des3-kd 12 20 6.9 1446 hmac-sha1-des3 13 20 1447 sha1 (unkeyed) 14 20 1448 [reserved] 0x8003 ? [GSS-KRB5] 1450 9. Notes to Implementors 1452 The "interface" described here is the minimal information that must 1453 be defined to make a cryptosystem useful within Kerberos in an 1454 interoperable fashion. It is not an attempt to define a complete API 1455 for cryptographic functionality within Kerberos. Actual 1456 implementations providing clean APIs will probably find it useful to 1457 make additional information available, which should be possible to 1458 derive from a specification written to the framework given here. For 1459 example, an application designer may wish to determine the largest 1460 number of bytes that can be encrypted without overflowing a certain 1461 size output buffer, or conversely, the maximum number of bytes that 1462 might be obtained by decrypting a given ciphertext message. 1464 The presence of a mechanism in this document should not be taken as 1465 an indication that it must be implemented for compliance with any 1466 specification; required mechanisms will be specified elsewhere. 1467 Indeed, some of the mechanisms described here for backwards 1468 compatibility are now considered rather weak for protecting critical 1469 data. 1471 10. Security Considerations 1473 Well, sure... weak encryption or checksum algorithms. Warnings made 1474 in the various sections. Reference EFF book on DES cracking, RFC on 1475 DES for IPsec. 1477 11. Acknowledgements 1479 This document is an extension of the encryption specification 1480 included in RFC 1510 by B. Clifford Neuman and John Kohl, and much of 1481 the text of the background, concepts, and DES specifications are 1482 drawn directly from that document. 1484 Marc Horowitz wrote the original specification of triple-DES and key 1485 derivation in a pair of Internet Drafts (under the names draft- 1486 horowitz-key-derivation and draft-horowitz-kerb-key-derivation) which 1487 were later folded into a draft revision of RFC 1510, from which this 1488 document was later split off. 1490 The abstract framework presented in this document was put together by 1491 Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn, 1492 and Tom Yu, and the details were refined several times based on 1493 comments from John Brezak and others. 1495 Miroslav Jurisic provided one of the UTF-8 test cases for the string- 1496 to-key functions. 1498 Uri Blumenthal provided comments on the "combine-keys" function 1499 proposed for use with triple-DES. 1501 12. Editor's address 1503 Kenneth Raeburn 1504 Massachusetts Institute of Technology 1505 77 Massachusetts Avenue 1506 Cambridge, MA 02139 1507 raeburn@mit.edu 1509 13. Full Copyright Statement 1511 Copyright (C) The Internet Society (2002). All Rights Reserved. 1513 This document and translations of it may be copied and furnished to 1514 others, and derivative works that comment on or otherwise explain it 1515 or assist in its implementation may be prepared, copied, published 1516 and distributed, in whole or in part, without restriction of any 1517 kind, provided that the above copyright notice and this paragraph are 1518 included on all such copies and derivative works. However, this 1519 document itself may not be modified in any way, such as by removing 1520 the copyright notice or references to the Internet Society or other 1521 Internet organizations, except as needed for the purpose of 1522 developing Internet standards in which case the procedures for 1523 copyrights defined in the Internet Standards process must be 1524 followed, or as required to translate it into languages other than 1525 English. 1527 The limited permissions granted above are perpetual and will not be 1528 revoked by the Internet Society or its successors or assigns. 1530 This document and the information contained herein is provided on an 1531 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1532 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1533 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1534 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1535 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1537 A. Test vectors 1539 This section provides test vectors for various functions defined or 1540 described in section 6. For convenience, most inputs are ASCII 1541 strings, though some UTF-8 samples should be provided for string-to- 1542 key functions. Keys and other binary data are specified as 1543 hexadecimal strings. 1545 A.1. n-fold 1547 The n-fold function is defined in section 6.4. As noted there, the 1548 sample vector in the original paper defining the algorithm appears to 1549 be incorrect. Here are values provided by Marc Horowitz: 1551 64-fold("012345") = 1552 64-fold(303132333435) = be072631276b1955 1554 56-fold("password") = 1555 56-fold(70617373776f7264) = 78a07b6caf85fa 1557 64-fold("Rough Consensus, and Running Code") = 1558 64-fold(526f75676820436f6e73656e7375732c20616e642052756e 1559 6e696e6720436f6465) = bb6ed30870b7f0e0 1561 168-fold("password") = 1562 168-fold(70617373776f7264) = 1563 59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e 1565 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY" 1566 192-fold(4d41535341434856534554545320494e5354495456544520 1567 4f4620544543484e4f4c4f4759) = 1568 db3b0d8f0b061e603282b308a50841229ad798fab9540c1b 1570 A.2. mit_des_string_to_key 1572 The function mit_des_string_to_key is defined in section 6.5.2. We 1573 present here several test values, with some of the intermediate 1574 results. The fourth test demonstrates the use of UTF-8 with three 1575 characters. The last two tests are specifically constructed so as to 1576 trigger the weak-key fixups for the intermediate key produced by fan- 1577 folding; we have no test cases that cause such fixups for the final 1578 key. 1580 UTF-8 encodings used in test vector: 1581 eszett C3 9F s-caron C5 A1 c-acute C4 87 1583 Test vector: 1585 salt: "ATHENA.MIT.EDUraeburn" 1586 415448454e412e4d49542e4544557261656275726e 1587 password: "password" 70617373776f7264 1588 fan-fold result: c01e38688ac86c2e 1589 intermediate key: c11f38688ac86d2f 1590 DES key: cbc22fae235298e3 1592 salt: "WHITEHOUSE.GOVdanny" 5748495445484f5553452e474f5664616e6e79 1593 password: "potatoe" 706f7461746f65 1594 fan-fold result: a028944ee63c0416 1595 intermediate key: a129944fe63d0416 1596 DES key: df3d32a74fd92a01 1598 salt: "EXAMPLE.COMbuckaroo" 4558414d504c452e434f4d6275636b61726f6f 1599 password: "penny" 70656e6e79 1600 fan-fold result: 96d2d87e925c64ee 1601 intermediate key: 97d3d97f925d64ef 1602 DES key: 9443a2e532fdc4f1 1604 salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute 1605 415448454e412e4d49542e4544554a757269c5a169c487 1606 password: eszett c39f 1607 fan-fold result: b8f6c40e305afc9e 1608 intermediate key: b9f7c40e315bfd9e 1609 DES key: 62c81a5232b5e69d 1611 salt: "AAAAAAAA" 4141414141414141 1612 password: "11119999" 3131313139393939 1613 fan-fold result: e0e0e0e0f0f0f0f0 1614 intermediate key: e0e0e0e0f1f1f101 1615 DES key: 984054d0f1a73e31 1616 salt: "FFFFAAAA" 4646464641414141 1617 password: "NNNN6666" 4e4e4e4e36363636 1618 fan-fold result: 1e1e1e1e0e0e0e0e 1619 intermediate key: 1f1f1f1f0e0e0efe 1620 DES key: c4bf6b25adf7a4f8 1622 A.3. DES3 DR and DK 1624 These tests show the derived-random and derived-key values for the 1625 des3-hmac-sha1-kd encryption scheme, using the DR and DK functions 1626 defined in section 6.5.5. The input keys were randomly generated; 1627 the usage values are from this specification. 1629 key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92 1630 usage: 0000000155 1631 DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705 1632 DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd 1634 key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2 1635 usage: 00000001aa 1636 DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2 1637 DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207 1639 key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc 1640 usage: 0000000155 1641 DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb 1642 DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf 1644 key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5 1645 usage: 00000001aa 1646 DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70 1647 DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e 1649 key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb 1650 usage: 6b65726265726f73 1651 DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da 1652 DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43 1653 key: b55e983467e551b3e5d0e5b6c80d45769423a873dc62b30e 1654 usage: 636f6d62696e65 1655 DR: 0127398bacc81a2a62bc45f8d4c151bbcdd5cb788a 1656 DK: 0126388aadc81a1f2a62bc45f8d5c19151bacdd5cb798a3e 1658 key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da 1659 usage: 0000000155 1660 DR: 348056ec98fcc517171d2b4d7a9493af482d999175 1661 DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7 1663 key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c 1664 usage: 00000001aa 1665 DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5 1666 DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1 1668 key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443 1669 usage: 0000000155 1670 DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a 1671 DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49 1673 key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016 1674 usage: 00000001aa 1675 DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec 1676 DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d 1678 A.4. DES3string_to_key 1680 These are the keys generated for some of the above input strings for 1681 triple-DES with key derivation as defined in section 5.3.1. 1683 salt: "ATHENA.MIT.EDUraeburn" 1684 passwd: "password" 1685 key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e 1687 salt: "WHITEHOUSE.GOVdanny" 1688 passwd: "potatoe" 1689 key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a 1690 salt: "EXAMPLE.COMbuckaroo" 1691 passwd: "penny" 1692 key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a 1694 salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute 1695 passwd: eszett 1696 key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0 1698 A.5. DES3 combine-keys 1700 PLACEHOLDER, FILL IN BEFORE PUBLICATION 1702 A.6. Modified CRC-32 1704 PLACEHOLDER, GET DATA FROM TOM 1706 Notes 1708 [1] While Message Authentication Code (MAC) or Message Integrity 1709 Check (MIC) would be more appropriate terms for many of the 1710 uses in this section, we continue to use the term "checksum" 1711 for historical reasons. 1713 [2] In the case of Kerberos, the encrypted objects will generally 1714 be ASN.1 DER encodings, which contain indications of their 1715 length in the first few octets. 1717 [3] As of the time of this writing, some new modes of operation 1718 have been proposed, some of which may permit encryption and 1719 integrity protection simultaneously. After some of these 1720 proposals have been subjected to adequate analysis, we may 1721 wish to formulate a new simplified profile based on one of 1722 them. 1724 [4] It should be noted that the sample vector in Appendix B.2 of 1725 the original paper appears to be incorrect. Two independent 1726 implementations from the specification (one in C by Marc 1727 Horowitz, and another in Scheme by Bill Sommerfeld) agree on 1728 a value different from that in [Blumenthal96]. 1730 [5] Perhaps one of the more common reasons for directly 1731 performing encryption is direct control over the negotiation 1732 and to select a "sufficiently strong" encryption algorithm 1733 (whatever that means in the context of a given application). 1734 While Kerberos directly provides no facility for negotiating 1735 encryption types between the application client and server, 1736 there are other means for accomplishing similar goals. For 1737 example, requesting only "strong" session key types from the 1738 KDC, and assuming that the type actually returned by the KDC 1739 will be understood and supported by the application server. 1741 Normative References 1743 This section copied from kerberos-revisions draft. Drop the ones we 1744 don't need, add anything new that we do need. Move informational- 1745 only references to the next section. Update old I-D references to 1746 RFCs, or find other sources. 1748 [Blumenthal96] 1749 Blumenthal, U., "A Better Key Schedule for DES-Like Ciphers", 1750 Proceedings of PRAGOCRYPT '96, 1996. 1751 [Bellare98] 1752 Bellare, M., Desai, A., Pointcheval, D., Rogaway, P., "Relations 1753 Among Notions of Security for Public-Key Encryption Schemes". 1754 Extended abstract published in Advances in Cryptology- Crypto 98 1755 Proceedings, Lecture Notes in Computer Science Vol. 1462, H. 1756 Krawcyzk ed., Springer-Verlag, 1998. 1757 [DES77] 1758 National Bureau of Standards, U.S. Department of Commerce, "Data 1759 Encryption Standard," Federal Information Processing Standards 1760 Publication 46, Washington, DC (1977). 1761 [DESM80] 1762 National Bureau of Standards, U.S. Department of Commerce, "DES 1763 Modes of Operation," Federal Information Processing Standards 1764 Publication 81, Springfield, VA (December 1980). 1765 [Dolev91] 1766 Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography", 1767 Proceedings of the 23rd Annual Symposium on Theory of Computing, 1768 ACM, 1991. 1769 [ISO3309] 1770 International Organization for Standardization, "ISO Information 1771 Processing Systems - Data Communication - High-Level Data Link 1772 Control Procedure - Frame Structure," IS 3309 (October 1984). 3rd 1773 Edition. 1774 [Krawczyk96] 1775 Krawczyk, H., Bellare, and M., Canetti, R., "HMAC: Keyed-Hashing 1776 for Message Authentication", draft-ietf-ipsec-hmac-md5-01.txt, 1777 August, 1996. @@ Now RFC 2202. 1778 [MD4-92] 1779 R. Rivest, "The MD4 Message Digest Algorithm," RFC 1320, MIT 1780 Laboratory for Computer Science (April 1992). 1781 [MD5-92] 1782 R. Rivest, "The MD5 Message Digest Algorithm," RFC 1321, MIT 1783 Laboratory for Computer Science (April 1992). 1785 [MNSS87] 1786 S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, 1787 Section E.2.1: Kerberos Authentication and Authorization System, 1788 M.I.T. Project Athena, Cambridge, Massachusetts (December 21, 1789 1987). 1790 [SG92] 1791 Stuart G. Stubblebine and Virgil D. Gligor, "On Message Integrity 1792 in Cryptographic Protocols," in Proceedings of the IEEE Symposium 1793 on Research in Security and Privacy, Oakland, California (May 1794 1992). 1796 Informative References 1798 [GSS-KRB5] 1799 @@ blah blah blah, RFC 1964 1801 ... EFF DES-cracking book ...