10 INTERNET DRAFT K. Raeburn
11 Kerberos Working Group MIT
12 Document: draft-ietf-krb-wg-crypto-06.txt October 27, 2003
13 expires April 27, 2004
15 Encryption and Checksum Specifications
20 This document is an Internet-Draft and is in full conformance with
21 all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts
22 are working documents of the Internet Engineering Task Force (IETF),
23 its areas, and its working groups. Note that other groups may also
24 distribute working documents as Internet-Drafts. Internet-Drafts are
25 draft documents valid for a maximum of six months and may be updated,
26 replaced, or obsoleted by other documents at any time. It is
27 inappropriate to use Internet-Drafts as reference material or to cite
28 them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at
31 http://www.ietf.org/ietf/1id-abstracts.html.
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
38 This document describes a framework for defining encryption and
39 checksum mechanisms for use with the Kerberos protocol, defining an
40 abstraction layer between the Kerberos protocol and related
41 protocols, and the actual mechanisms themselves. Several mechanisms
42 are also defined in this document. Some are taken from RFC 1510,
43 modified in form to fit this new framework, and occasionally modified
44 in content when the old specification was incorrect. New mechanisms
45 are presented here as well. This document does NOT indicate which
46 mechanisms may be considered "required to implement".
48 Comments should be sent to the editor, or to the IETF Kerberos
49 working group (ietf-krb-wg@anl.gov).
60 INTERNET DRAFT October 2003
66 Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . . 1
67 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
68 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . 2
69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
70 2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
71 3. Encryption algorithm profile . . . . . . . . . . . . . . . . . . 4
72 4. Checksum algorithm profile . . . . . . . . . . . . . . . . . . . 9
73 5. Simplified profile for CBC ciphers with key derivation . . . . . 10
74 5.1. A key derivation function . . . . . . . . . . . . . . . . . . . 11
75 5.2. Simplified profile parameters . . . . . . . . . . . . . . . . . 13
76 5.3. Cryptosystem profile based on simplified profile . . . . . . . 14
77 5.4. Checksum profiles based on simplified profile . . . . . . . . . 16
78 6. Profiles for Kerberos encryption and checksum algorithms . . . . 16
79 6.1. Unkeyed checksums . . . . . . . . . . . . . . . . . . . . . . . 16
80 6.2. DES-based encryption and checksum types . . . . . . . . . . . . 18
81 6.3. Triple-DES based encryption and checksum types . . . . . . . . 28
82 7. Use of Kerberos encryption outside this specification . . . . . . 30
83 8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . . . 31
84 9. Implementation Notes . . . . . . . . . . . . . . . . . . . . . . 33
85 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 33
86 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 35
87 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 36
88 A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . . . 37
89 A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
90 A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . . . . . 39
91 A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . . . . . 43
92 A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . . . . . 44
93 A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . . . . . 45
94 B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . . . 45
95 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
96 Normative References . . . . . . . . . . . . . . . . . . . . . . . . 47
97 Informative References . . . . . . . . . . . . . . . . . . . . . . . 49
98 Editor's address . . . . . . . . . . . . . . . . . . . . . . . . . . 49
99 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . . 50
116 INTERNET DRAFT October 2003
121 The Kerberos protocols are designed to encrypt messages of arbitrary
122 sizes, using block encryption ciphers, or less commonly, stream
123 encryption ciphers. Encryption is used to prove the identities of
124 the network entities participating in message exchanges. However,
125 nothing in the Kerberos protocol requires any specific encryption
126 algorithm be used, as long as certain operations are available in the
127 algorithm that is used.
129 The following sections specify the encryption and checksum mechanisms
130 currently defined for Kerberos, as well as a framework for defining
131 future mechanisms. The encoding, chaining, padding and other
132 requirements for each are described. Test vectors for several
133 functions are given in appendix A.
137 Both encryption and checksum mechanisms are defined in terms of
138 profiles, detailed in later sections. Each specifies a collection of
139 operations and attributes that must be defined for a mechanism. A
140 Kerberos encryption or checksum mechanism specification is not
141 complete if it does not define all of these operations and
144 An encryption mechanism must provide for confidentiality and
145 integrity of the original plaintext. (Integrity checking may be
146 achieved by incorporating a checksum, if the encryption mode does not
147 provide an integrity check itself.) It must also provide non-
148 malleability [Bellare98, Dolev91]. Use of a random confounder
149 prepended to the plaintext is recommended. It should not be possible
150 to determine if two ciphertexts correspond to the same plaintext,
151 without knowledge of the key.
153 A checksum mechanism [1] must provide proof of the integrity of the
154 associated message, and must preserve the confidentiality of the
155 message in case it is not sent in the clear. It should be infeasible
156 to find two plaintexts which have the same checksum. It is NOT
157 required that an eavesdropper be unable to determine if two checksums
158 are for the same message; it is assumed that the messages themselves
159 will be visible to any such eavesdropper.
161 Due to advances in cryptography, it is considered unwise by some
162 cryptographers to use the same key for multiple purposes. Since keys
163 are used in performing a number of different functions in Kerberos,
164 it is desirable to use different keys for each of these purposes,
165 even though we start with a single long-term or session key.
172 INTERNET DRAFT October 2003
175 We do this by enumerating the different uses of keys within Kerberos,
176 and making the "usage number" an input to the encryption or checksum
177 mechanisms; this enumeration is outside the scope of this document.
178 Later sections of this document define simplified profile templates
179 for encryption and checksum mechanisms that use a key derivation
180 function applied to a CBC mode (or similar) cipher and a checksum or
183 We distinguish the "base key" specified by other documents from the
184 "specific key" to be used for a particular instance of encryption or
185 checksum operations. It is expected but not required that the
186 specific key will be one or more separate keys derived from the
187 original protocol key and the key usage number. The specific key
188 should not be explicitly referenced outside of this document. The
189 typical language used in other documents should be something like,
190 "encrypt this octet string using this key and this usage number";
191 generation of the specific key and cipher state (described in the
192 next section) are implicit. The creation of a new cipher-state
193 object, or the re-use of one from a previous encryption operation,
194 may also be explicit.
196 New protocols defined in terms of the Kerberos encryption and
197 checksum types should use their own key usage values. Key usages are
198 unsigned 32 bit integers; zero is not permitted.
200 All data is assumed to be in the form of strings of octets or 8-bit
201 bytes. Environments with other byte sizes will have to emulate this
202 behavior in order to get correct results.
204 Each algorithm is assigned an encryption type (or "etype") or
205 checksum type number, for algorithm identification within the
206 Kerberos protocol. The full list of current type number assignments
207 is given in section 8.
209 3. Encryption algorithm profile
211 An encryption mechanism profile must define the following attributes
212 and operations. The operations must be defined as functions in the
213 mathematical sense: no additional or implicit inputs (such as
214 Kerberos principal names or message sequence numbers) are permitted.
217 This describes what octet string values represent valid keys. For
218 encryption mechanisms that don't have perfectly dense key spaces,
219 this will describe the representation used for encoding keys. It
220 need not describe specific values that are not valid or desirable
221 for use; such values should be avoid by all key generation
228 INTERNET DRAFT October 2003
231 specific key structure
232 This is not a protocol format at all, but a description of the
233 keying material derived from the chosen key and used to encrypt or
234 decrypt data or compute or verify a checksum. It may, for
235 example, be a single key, a set of keys, or a combination of the
236 original key with additional data. The authors recommend using
237 one or more keys derived from the original key via one-way key
238 derivation functions.
240 required checksum mechanism
241 This indicates a checksum mechanism that must be available when
242 this encryption mechanism is used. Since Kerberos has no built in
243 mechanism for negotiating checksum mechanisms, once an encryption
244 mechanism has been decided upon, the corresponding checksum
245 mechanism can simply be used.
247 key-generation seed length, K
248 This is the length of the random bitstring needed to generate a
249 key with the encryption scheme's random-to-key function (described
250 below). This must be a fixed value so that various techniques for
251 producing a random bitstring of a given length may be used with
252 key generation functions.
254 key generation functions
255 Keys must be generated in a number of cases, from different types
256 of inputs. All function specifications must indicate how to
257 generate keys in the proper wire format, and must avoid generation
258 of keys that significantly compromise the confidentiality of
259 encrypted data, if the cryptosystem has such. Entropy from each
260 source should be preserved as much as possible. Many of the
261 inputs, while unknown, may be at least partly predictable (e.g., a
262 password string is likely to be entirely in the ASCII subset and
263 of fairly short length in many environments; a semi-random string
264 may include timestamps); the benefit of such predictability to an
265 attacker must be minimized.
267 string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key)
268 This function generates a key from two UTF-8 strings and an
269 opaque octet string. One of the strings is normally the
270 principal's pass phrase, but is in general merely a secret
271 string. The other string is a "salt" string intended to
272 produce different keys from the same password for different
273 users or realms. While the strings provided will use UTF-8
274 encoding, no specific version of Unicode should be assumed; all
275 valid UTF-8 strings should be allowed.
277 The third argument, the octet string, may be used to pass
278 mechanism-specific parameters in to this function. Since doing
284 INTERNET DRAFT October 2003
287 so implies knowledge of the specific encryption system, it is
288 intended that generating non-default parameter values be an
289 uncommon operation, and that normal Kerberos applications be
290 able to treat this parameter block as an opaque object supplied
291 by the Key Distribution Center or defaulted to some mechanism-
292 specific constant value.
294 The string-to-key function should be a one-way function, so
295 that compromising a user's key in one realm does not compromise
296 the user's key in another realm, even if the same password (but
297 a different salt) is used.
299 random-to-key (bitstring[K])->(protocol-key)
300 This function generates a key from a random bitstring of a
301 specific size. It may be assumed that all the bits of the
302 input string are equally random, even though the entropy
303 present in the random source may be limited.
305 key-derivation (protocol-key, integer)->(specific-key)
306 In this function, the integer input is the key usage value as
307 described above; the usage values must be assumed to be known
308 to an attacker. The specific-key output value was described in
311 string-to-key parameter format
312 This describes the format of the block of data that can be passed
313 to the string-to-key function above to configure additional
314 parameters for that function. Along with the mechanism of
315 encoding parameter values, bounds on the allowed parameters should
316 also be described to avoid allowing a spoofed KDC to compromise
317 the user's password. It may be desirable to construct the
318 encoding such that values weakening the resulting key unacceptably
319 cannot be encoded, if practical.
321 Tighter bounds might be permitted by local security policy, or to
322 avoid excess resource consumption; if so, recommended defaults for
323 those bounds should be given in the specification. The
324 description should also outline possible weaknesses that may be
325 caused by not applying bounds checks or other validation to a
326 parameter string received from the network.
328 As mentioned above, this should be considered opaque to most
331 default string-to-key parameters (octet string)
332 This default value for the "params" argument to the string-to-key
333 function is to be used when the application protocol (Kerberos or
334 otherwise) does not explicitly set the parameter value. As
340 INTERNET DRAFT October 2003
343 indicated above, this parameter block should be treated as an
344 opaque object in most cases.
347 This describes any information that can be carried over from one
348 encryption or decryption operation to the next, for use in
349 conjunction with a given specific key. For example, a block
350 cipher used in CBC mode may put an initial vector of one block in
351 the cipher state. Other encryption modes may track nonces or
354 This state must be non-empty, and must influence encryption so as
355 to require that messages be decrypted in the same order they were
356 encrypted, if the cipher state is carried over from one encryption
357 to the next. Distinguishing out-of-order or missing messages from
358 corrupted messages is not required; if desired, this can be done
359 at a higher level by including sequence numbers and not "chaining"
360 the cipher state between encryption operations.
362 The cipher state may not be reused in multiple encryption or
363 decryption operations; these operations all generate a new cipher
364 state that may be used for following operations using the same key
367 The contents of the cipher state must be treated as opaque outside
368 of encryption system specifications.
370 initial cipher state (specific-key, direction)->(state)
371 This describes the generation of the initial value for the cipher
372 state if it is not being carried over from a previous encryption
373 or decryption operation.
375 This describes any initial state setup needed before encrypting
376 arbitrary amounts of data with a given specific key; the specific
377 key and the direction of operations to be performed (encrypt
378 versus decrypt) must be the only input needed for this
381 This state should be treated as opaque in any uses outside of an
382 encryption algorithm definition.
384 IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what
385 degree an application protocol could exercise control over the
386 initial vector used in DES CBC operations. Some existing
387 implementations permit the setting of the initial vector. This
388 new specification does not permit application control of the
389 cipher state (beyond "initialize" and "carry over from previous
390 encryption"), since the form and content of the initial cipher
396 INTERNET DRAFT October 2003
399 state can vary between encryption systems, and may not always be a
400 single block of random data.
402 New Kerberos application protocols should not assume that they can
403 control the initial vector, or that one even exists. However, a
404 general-purpose implementation may wish to provide the capability,
405 in case applications explicitly setting it are encountered.
407 encrypt (specific-key, state, octet string)->(state, octet string)
408 This function takes the specific key, cipher state, and a non-
409 empty plaintext string as input, and generates ciphertext and a
410 new cipher state as outputs. If the basic encryption algorithm
411 itself does not provide for integrity protection (as DES in CBC
412 mode does not do), then some form of MAC or checksum must be
413 included that can be verified by the receiver. Some random factor
414 such as a confounder should be included so that an observer cannot
415 know if two messages contain the same plaintext, even if the
416 cipher state and specific keys are the same. The exact length of
417 the plaintext need not be encoded, but if it is not and if padding
418 is required, the padding must be added at the end of the string so
419 that the decrypted version may be parsed from the beginning.
421 The specification of the encryption function must not only
422 indicate the precise contents of the output octet string, but also
423 the output cipher state. The application protocol may carry
424 forward the output cipher state from one encryption with a given
425 specific key to another; the effect of this "chaining" must be
428 Assuming correctly-produced values for the specific key and cipher
429 state, no input octet string may result in an error indication.
431 decrypt (specific-key, state, octet string)->(state, octet string)
432 This function takes the specific key, cipher state, and ciphertext
433 as inputs, and verifies the integrity of the supplied ciphertext.
434 If the ciphertext's integrity is intact, this function produces
435 the plaintext and a new cipher state as outputs; otherwise, an
436 error indication must be returned, and the data discarded.
438 The result of the decryption may be longer than the original
439 plaintext, for example if the encryption mode adds padding to
440 reach a multiple of a block size. If this is the case, any extra
441 octets must be after the decoded plaintext. An application
442 protocol which needs to know the exact length of the message must
443 encode a length or recognizable "end of message" marker within the
446 As with the encryption function, a correct specification for this
452 INTERNET DRAFT October 2003
455 function must indicate not only the contents of the output octet
456 string, but also the resulting cipher state.
458 pseudo-random (protocol-key, octet-string)->(octet-string)
459 This pseudo-random function should generate an octet string of
460 some size that independent of the octet string input. The PRF
461 output string should be suitable for use in key generation, even
462 if the octet string input is public. It should not reveal the
463 input key, even if the output is made public.
465 These operations and attributes are all that is required to support
466 Kerberos and various proposed preauthentication schemes.
468 For convenience of certain application protocols that may wish to use
469 the encryption profile, we add the constraint that, for any given
470 plaintext input size, there must be a message size between that given
471 size and that size plus 65535 such that the length of such that the
472 decrypted version of the ciphertext for any message of that size will
473 never have extra octets added at the end.
475 Expressed mathematically, for every message length L1, there exists a
476 message size L2 such that:
480 for every message M with |M| = L2, decrypt(encrypt(M)) = M
482 A document defining a new encryption type should also describe known
483 weaknesses or attacks, so that its security may be fairly assessed,
484 and should include test vectors or other validation procedures for
485 the operations defined. Specific references to information readily
486 available elsewhere are sufficient.
488 4. Checksum algorithm profile
490 A checksum mechanism profile must define the following attributes and
493 associated encryption algorithm(s)
494 This indicates the types of encryption keys this checksum
495 mechanism can be used with.
497 A keyed checksum mechanism may have more than one associated
498 encryption algorithm if they share the same wire key format,
499 string-to-key function, and key derivation function. (This
500 combination means that, for example, a checksum type, key usage
501 value and password are adequate to get the specific key used to
508 INTERNET DRAFT October 2003
511 An unkeyed checksum mechanism can be used in conjunction with any
512 encryption type, since the key is ignored, but its use must be
513 limited to cases where the checksum itself is protected, to avoid
517 This function generates a MIC token for a given specific key (see
518 section 3), and message (represented as an octet string), that may
519 be used to verify the integrity of the associated message. This
520 function is not required to return the same deterministic result
521 on every use; it need only generate a token that the verify_mic
524 The output of this function will also dictate the size of the
525 checksum. It must be no larger than 65535 octets.
528 Given a specific key, message, and MIC token, this function
529 ascertains whether the message integrity has been compromised.
530 For a deterministic get_mic routine, the corresponding verify_mic
531 may simply generate another checksum and compare them.
533 The get_mic and verify_mic operations must be able to handle inputs
534 of arbitrary length; if any padding is needed, the padding scheme
535 must be specified as part of these functions.
537 These operations and attributes are all that should be required to
538 support Kerberos and various proposed preauthentication schemes.
540 As with encryption mechanism definition documents, documents defining
541 new checksum mechanisms should indicate validation processes and
544 5. Simplified profile for CBC ciphers with key derivation
546 The profile outlines in sections 3 and 4 describes a large number of
547 operations that must be defined for encryption and checksum
548 algorithms to be used with Kerberos. We describe here a simpler
549 profile from which both encryption and checksum mechanism definitions
550 can be generated, filling in uses of key derivation in appropriate
551 places, providing integrity protection, and defining multiple
552 operations for the cryptosystem profile based on a smaller set of
553 operations given in the simplified profile. Not all of the existing
554 cryptosystems for Kerberos fit into this simplified profile, but we
555 recommend that future cryptosystems use it or something based on it.
558 Not all of the operations in the complete profiles are defined
564 INTERNET DRAFT October 2003
567 through this mechanism; several must still be defined for each new
570 5.1. A key derivation function
572 Rather than define some scheme by which a "protocol key" is composed
573 of a large number of encryption keys, we use keys derived from a base
574 key to perform cryptographic operations. The base key must be used
575 only for generating the derived keys, and this derivation must be
576 non-invertible and entropy-preserving. Given these restrictions,
577 compromise of one derived key does not compromise the other subkeys.
578 Attack of the base key is limited, since it is only used for
579 derivation, and is not exposed to any user data.
581 Since the derived key has as much entropy as the base keys (if the
582 cryptosystem is good), password-derived keys have the full benefit of
583 all the entropy in the password.
585 To generate a derived key from a base key, we generate a pseudorandom
586 octet string, using an algorithm DR described below, and generate a
587 key from that octet string using a function dependent on the
588 encryption algorithm; the input length needed for that function,
589 which is also dependent on the encryption algorithm, dictates the
590 length of the string to be generated by the DR algorithm (the value
591 "k" below). These procedures are based on the key derivation in
594 Derived Key = DK(Base Key, Well-Known Constant)
596 DK(Key, Constant) = random-to-key(DR(Key, Constant))
598 DR(Key, Constant) = k-truncate(E(Key, Constant,
599 initial-cipher-state))
601 Here DR is the random-octet generation function described below, and
602 DK is the key-derivation function produced from it. In this
603 construction, E(Key, Plaintext, CipherState) is a cipher, Constant is
604 a well-known constant determined by the specific usage of this
605 function, and k-truncate truncates its argument by taking the first k
606 bits. Here, k is the key generation seed length needed for the
609 The output of the DR function is a string of bits; the actual key is
610 produced by applying the cryptosystem's random-to-key operation on
613 If the Constant is smaller than the cipher block size of E, then it
614 must be expanded with n-fold() so it can be encrypted. If the output
620 INTERNET DRAFT October 2003
623 of E is shorter than k bits it is fed back into the encryption as
624 many times as necessary. The construct is as follows (where |
625 indicates concatentation):
627 K1 = E(Key, n-fold(Constant), initial-cipher-state)
628 K2 = E(Key, K1, initial-cipher-state)
629 K3 = E(Key, K2, initial-cipher-state)
632 DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...)
634 n-fold is an algorithm which takes m input bits and ``stretches''
635 them to form n output bits with equal contribution from each input
636 bit to the output, as described in [Blumenthal96]:
638 We first define a primitive called n-folding, which takes a
639 variable-length input block and produces a fixed-length output
640 sequence. The intent is to give each input bit approximately
641 equal weight in determining the value of each output bit. Note
642 that whenever we need to treat a string of octets as a number, the
643 assumed representation is Big-Endian -- Most Significant Byte
646 To n-fold a number X, replicate the input value to a length that
647 is the least common multiple of n and the length of X. Before
648 each repetition, the input is rotated to the right by 13 bit
649 positions. The successive n-bit chunks are added together using
650 1's-complement addition (that is, with end-around carry) to yield
654 Test vectors for n-fold are supplied in Appendix A. [5]
656 In this section, n-fold is always used to produce c bits of output,
657 where c is the cipher block size of E.
659 The size of the Constant must not be larger than c, because reducing
660 the length of the Constant by n-folding can cause collisions.
662 If the size of the Constant is smaller than c, then the Constant must
663 be n-folded to length c. This string is used as input to E. If the
664 block size of E is less than the random-to-key input size, then the
665 output from E is taken as input to a second invocation of E. This
666 process is repeated until the number of bits accumulated is greater
667 than or equal to the random-to-key input size. When enough bits have
668 been computed, the first k are taken as the random data used to
669 create the key with the algorithm-dependent random-to-key function.
676 INTERNET DRAFT October 2003
679 Since the derived key is the result of one or more encryptions in the
680 base key, deriving the base key from the derived key is equivalent to
681 determining the key from a very small number of plaintext/ciphertext
682 pairs. Thus, this construction is as strong as the cryptosystem
685 5.2. Simplified profile parameters
687 These are the operations and attributes that must be defined:
690 string-to-key function
691 default string-to-key parameters
692 key-generation seed length, k
693 random-to-key function
694 As above for the normal encryption mechanism profile.
696 unkeyed hash algorithm, H
697 This should be a collision-resistant hash algorithm with fixed-
698 size output, suitable for use in an HMAC [HMAC]. It must support
699 inputs of arbitrary length. Its output must be at least the
700 message block size (below).
703 This indicates the size of the leading substring output by the
704 HMAC function that should be used in transmitted messages. It
705 should be at least half the output size of the hash function H,
706 and at least 80 bits; it need not match the output size.
708 message block size, m
709 This is the size of the smallest units the cipher can handle in
710 the mode in which it is being used. Messages will be padded to a
711 multiple of this size. If a block cipher is used in a mode that
712 can handle messages that are not multiples of the cipher block
713 size, such as CBC mode with cipher text stealing (CTS, see [RC5]),
714 this value would be one octet. For traditional CBC mode with
715 padding, it will be the underlying cipher's block size.
717 This value must be a multiple of 8 bits (one octet).
719 encryption/decryption functions, E and D
720 These are basic encryption and decryption functions for messages
721 of sizes that are multiples of the message block size. No
722 integrity checking or confounder should be included here. These
723 functions take as input the IV or similar data, a protocol-format
724 key, and a octet string, returning a new IV and octet string.
726 The encryption function is not required to use CBC mode, but is
732 INTERNET DRAFT October 2003
735 assumed to be using something with similar properties. In
736 particular, prepending a cipher-block-size confounder to the
737 plaintext should alter the entire ciphertext (comparable to
738 choosing and including a random initial vector for CBC mode).
740 The result of encrypting one cipher block (of size c, above) must
741 be deterministic, for the random octet generation function DR in
742 the previous section to work. For best security, it should also
746 This is the block size of the block cipher underlying the
747 encryption and decryption functions indicated above, used for key
748 derivation and for the size of the message confounder and initial
749 vector. (If a block cipher is not in use, some comparable
750 parameter should be determined.) It must be at least 5 octets.
752 This is not actually an independent parameter; rather, it is a
753 property of the functions E and D. It is listed here to clarify
754 the distinction between it and the message block size, m.
756 While there are still a number of properties to specify, they are
757 fewer and simpler than in the full profile.
759 5.3. Cryptosystem profile based on simplified profile
761 The above key derivation function is used to produce three
762 intermediate keys. One is used for computing checksums of
763 unencrypted data. The other two are used for encrypting and
764 checksumming plaintext to be sent encrypted.
766 The ciphertext output is the concatenation of the output of the basic
767 encryption function E and a (possibly truncated) HMAC using the
768 specified hash function H, both applied to the plaintext with a
769 random confounder prefix and sufficient padding to bring it to a
770 multiple of the message block size. When the HMAC is computed, the
771 key is used in the protocol key form.
773 Decryption is performed by removing the (partial) HMAC, decrypting
774 the remainder, and verifying the HMAC. The cipher state is an
775 initial vector, initialized to zero.
777 The substring notation "[1..h]" in the following table should be read
778 as using 1-based indexing; leading substrings are used.
788 INTERNET DRAFT October 2003
791 cryptosystem from simplified profile
792 ----------------------------------------------------------------------------
793 protocol key format As given.
795 specific key structure Three protocol-format keys: { Kc, Ke, Ki }.
797 key-generation seed As given.
800 required checksum As defined below in section 5.4.
803 cipher state initial vector (usually of length c)
805 initial cipher state all bits zero
807 encryption function conf = random string of length c
808 pad = shortest string to bring confounder
809 and plaintext to a length that's a
811 (C1, newIV) = E(Ke, conf | plaintext | pad,
813 H1 = HMAC(Ki, conf | plaintext | pad)
814 ciphertext = C1 | H1[1..h]
815 newstate.ivec = newIV
817 decryption function (C1,H1) = ciphertext
818 (P1, newIV) = D(Ke, C1, oldstate.ivec)
819 if (H1 != HMAC(Ki, P1)[1..h])
821 newstate.ivec = newIV
823 default string-to-key As given.
826 pseudo-random function tmp1 = H(octet-string)
827 tmp2 = truncate tmp1 to multiple of m
828 PRF = E(protocol-key, tmp2, initial-cipher-state)
830 key generation functions:
832 string-to-key function As given.
834 random-to-key function As given.
844 INTERNET DRAFT October 2003
847 cryptosystem from simplified profile
848 ----------------------------------------------------------------------------
849 key-derivation function The "well-known constant" used for the DK
850 function is the key usage number, expressed as
851 four octets in big-endian order, followed by one
852 octet indicated below.
854 Kc = DK(base-key, usage | 0x99);
855 Ke = DK(base-key, usage | 0xAA);
856 Ki = DK(base-key, usage | 0x55);
859 5.4. Checksum profiles based on simplified profile
861 When an encryption system is defined using the simplified profile
862 given in section 5.2, a checksum algorithm may be defined for it as
866 checksum mechanism from simplified profile
867 --------------------------------------------------
868 associated cryptosystem as defined above
870 get_mic HMAC(Kc, message)[1..h]
872 verify_mic get_mic and compare
874 The HMAC function and key Kc are as described in section 5.3.
876 6. Profiles for Kerberos encryption and checksum algorithms
878 These profiles describe the encryption and checksum systems defined
879 for Kerberos. The astute reader will notice that some of them do not
880 fulfull all of the requirements outlined in previous sections. These
881 systems are defined for backward compatibility; newer implementations
882 should (whenever possible) attempt to make use of encryption systems
883 which satisfy all of the profile requirements.
885 The full list of current encryption and checksum type number
886 assignments, including values currently reserved but not defined in
887 this document, is given in section 8.
889 6.1. Unkeyed checksums
891 These checksum types use no encryption keys, and thus can be used in
892 combination with any encryption type, but may only be used with
893 caution, in limited circumstances where the lack of a key does not
894 provide a window for an attack, preferably as part of an encrypted
900 INTERNET DRAFT October 2003
903 message. [6] Keyed checksum algorithms are recommended.
905 6.1.1. The RSA MD5 Checksum
907 The RSA-MD5 checksum calculates a checksum using the RSA MD5
908 algorithm [MD5-92]. The algorithm takes as input an input message of
909 arbitrary length and produces as output a 128-bit (16 octet)
910 checksum. RSA-MD5 is believed to be collision-proof.
913 ----------------------------------------------
914 associated cryptosystem any
918 verify_mic get_mic and compare
920 The rsa-md5 checksum algorithm is assigned a checksum type number of
923 6.1.2. The RSA MD4 Checksum
925 The RSA-MD4 checksum calculates a checksum using the RSA MD4
926 algorithm [MD4-92]. The algorithm takes as input an input message of
927 arbitrary length and produces as output a 128-bit (16 octet)
928 checksum. RSA-MD4 is believed to be collision-proof.
932 ----------------------------------------------
933 associated cryptosystem any
937 verify_mic get_mic and compare
940 The rsa-md4 checksum algorithm is assigned a checksum type number of
943 6.1.3. CRC-32 Checksum
945 This CRC-32 checksum calculates a checksum based on a cyclic
946 redundancy check as described in ISO 3309 [CRC], modified as
947 described below. The resulting checksum is four (4) octets in
948 length. The CRC-32 is neither keyed nor collision-proof; thus, the
949 use of this checksum is not recommended. An attacker using a
950 probabilistic chosen-plaintext attack as described in [SG92] might be
956 INTERNET DRAFT October 2003
959 able to generate an alternative message that satisfies the checksum.
961 The CRC-32 checksum used in the des-cbc-crc encryption mode is
962 identical to the 32-bit FCS described in ISO 3309 with two
963 exceptions: the sum with the all-ones polynomial times x**k is
964 omitted, and the final remainder is not ones-complemented. ISO 3309
965 describes the FCS in terms of bits, while this document describes the
966 Kerberos protocol in terms of octets. To disambiguate the ISO 3309
967 definition for the purpose of computing the CRC-32 in the des-cbc-crc
968 encryption mode, the ordering of bits in each octet shall be assumed
969 to be LSB-first. Given this assumed ordering of bits within an
970 octet, the mapping of bits to polynomial coefficients shall be
971 identical to that specified in ISO 3309.
973 Test values for this modified CRC function are included in appendix
978 ----------------------------------------------
979 associated cryptosystem any
983 verify_mic get_mic and compare
986 The crc32 checksum algorithm is assigned a checksum type number of
989 6.2. DES-based encryption and checksum types
991 These encryption systems encrypt information under the Data
992 Encryption Standard [DES77] using the cipher block chaining mode
993 [DESM80]. A checksum is computed as described below and placed in
994 the cksum field. DES blocks are 8 bytes. As a result, the data to
995 be encrypted (the concatenation of confounder, checksum, and message)
996 must be padded to an 8 byte boundary before encryption. The values
997 of the padding bytes are unspecified.
999 Plaintext and DES ciphertext are encoded as blocks of 8 octets which
1000 are concatenated to make the 64-bit inputs for the DES algorithms.
1001 The first octet supplies the 8 most significant bits (with the
1002 octet's MSB used as the DES input block's MSB, etc.), the second
1003 octet the next 8 bits, ..., and the eighth octet supplies the 8 least
1006 Encryption under DES using cipher block chaining requires an
1012 INTERNET DRAFT October 2003
1015 additional input in the form of an initialization vector; this vector
1016 is specified for each encryption system, below.
1018 The DES specifications [DESI81] identify four 'weak' and twelve
1019 'semi-weak' keys; those keys shall not be used for encrypting
1020 messages for use in Kerberos. The "variant keys" generated for the
1021 RSA-MD5-DES, RSA-MD4-DES and DES-MAC checksum types by an exclusive-
1022 or of a DES key with a hexadecimal constant are not checked for this
1025 A DES key is 8 octets of data. This consists of 56 bits of actual
1026 key data, and 8 parity bits, one per octet. The key is encoded as a
1027 series of 8 octets written in MSB-first order. The bits within the
1028 key are also encoded in MSB order. For example, if the encryption
1029 key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8)
1030 where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8
1031 are the parity bits, the first octet of the key would be
1032 B1,B2,...,B7,P1 (with B1 as the most significant bit). See the
1033 [DESM80] introduction for reference.
1035 Encryption data format
1037 The format for the data to be encrypted includes a one-block
1038 confounder, a checksum, the encoded plaintext, and any necessary
1039 padding, as described in the following diagram. The msg-seq field
1040 contains the part of the protocol message which is to be encrypted.
1042 +-----------+----------+---------+-----+
1043 |confounder | checksum | msg-seq | pad |
1044 +-----------+----------+---------+-----+
1046 One generates a random confounder of one block, placing it in
1047 'confounder'; zeroes out the 'checksum' field (of length appropriate
1048 to exactly hold the checksum to be computed); calculates the
1049 appropriate checksum over the whole sequence, placing the result in
1050 'checksum'; adds the necessary padding; then encrypts using the
1051 specified encryption type and the appropriate key.
1053 String or random-data to key transformation
1055 To generate a DES key from two UTF-8 text strings (password and
1056 salt), the two strings are concatenated, password first, and the
1057 result is then padded with zero-valued octets to a multiple of 8
1060 The top bit of each octet (always zero if the password is plain
1061 ASCII, as was assumed when the original specification was written) is
1062 discarded, and a bitstring is formed of the remaining seven bits of
1068 INTERNET DRAFT October 2003
1071 each octet. This bitstring is then fan-folded and eXclusive-ORed
1072 with itself to produce a 56-bit string. An eight-octet key is formed
1073 from this string, each octet using seven bits from the bitstring,
1074 leaving the least significant bit unassigned. The key is then
1075 "corrected" by correcting the parity on the key, and if the key
1076 matches a 'weak' or 'semi-weak' key as described in the DES
1077 specification, it is eXclusive-ORed with the constant
1078 0x00000000000000F0. This key is then used to generate a DES CBC
1079 checksum on the initial string with the salt appended. The result of
1080 the CBC checksum is then "corrected" as described above to form the
1081 result which is returned as the key.
1083 For purposes of the string-to-key function, the DES CBC checksum is
1084 calculated by CBC encrypting a string using the key as IV and using
1085 the final 8 byte block as the checksum.
1089 removeMSBits(8byteblock) {
1090 /* Treats a 64 bit block as 8 octets and remove the MSB in
1091 each octect (in big endian mode) and concatenates the
1092 result. E.g., input octet string:
1093 01110000 01100001 11110011 01110011 11110111 01101111
1095 results in output bitstring:
1096 1110000 1100001 1110011 1110011 1110111 1101111
1100 reverse(56bitblock) {
1101 /* Treats a 56-bit block as a binary string and reverse it.
1103 1000001 1010100 1001000 1000101 1001110 1000001
1105 results in output string:
1106 1011001 0111010 1000001 0111001 1010001 0001001
1124 INTERNET DRAFT October 2003
1127 add_parity_bits(56bitblock) {
1128 /* Copies a 56-bit block into a 64-bit block, left shift
1129 content in each octet and add DES parity bit.
1131 1100000 0001111 0011100 0110100 1000101 1100100
1133 results in output string:
1134 11000001 00011111 00111000 01101000 10001010 11001000
1135 01101101 00101111 */
1138 key_correction(key) {
1140 if (is_weak_key(key))
1145 mit_des_string_to_key(string,salt) {
1148 tempstring = 0; /* 56-bit string */
1149 pad(s); /* with nulls to 8 byte boundary */
1150 for (8byteblock in s) {
1151 56bitstring = removeMSBits(8byteblock);
1152 if (odd == 0) reverse(56bitstring);
1154 tempstring = tempstring XOR 56bitstring;
1156 tempkey = key_correction(add_parity_bits(tempstring));
1157 key = key_correction(DES-CBC-check(s,tempkey));
1161 des_string_to_key(string,salt,params) {
1162 if (length(params) == 0)
1164 else if (length(params) == 1)
1167 error("invalid params");
1169 mit_des_string_to_key(string,salt);
1171 error("invalid params");
1174 One common extension is to support the "AFS string-to-key" algorithm,
1180 INTERNET DRAFT October 2003
1183 which is not defined here, if the type value above is one (1).
1185 For generation of a key from a random bitstring, we start with a
1186 56-bit string, and as with the string-to-key operation above, insert
1187 parity bits, and if the result is a weak or semi-weak key, modify it
1188 by exclusive-OR with the constart 0x00000000000000F0:
1190 des_random_to_key(bitstring) {
1191 return key_correction(add_parity_bits(bitstring));
1196 The des-cbc-md5 encryption mode encrypts information under DES in CBC
1197 mode with an all-zero initial vector, with an MD5 checksum (described
1198 in [MD5-92]) computed and placed in the checksum field.
1200 The encryption system parameters for des-cbc-md5 are:
1203 --------------------------------------------------------------------
1204 protocol key format 8 bytes, parity in low bit of each
1206 specific key structure copy of original key
1208 required checksum rsa-md5-des
1211 key-generation seed 8 bytes
1214 cipher state 8 bytes (CBC initial vector)
1216 initial cipher state all-zero
1218 encryption function des-cbc(confounder | checksum | msg | pad,
1221 checksum = md5(confounder | 0000...
1224 newstate = last block of des-cbc output
1226 decryption function decrypt encrypted text and verify checksum
1228 newstate = last block of ciphertext
1236 INTERNET DRAFT October 2003
1240 --------------------------------------------------------------------
1241 default string-to-key empty string
1244 pseudo-random function des-cbc(md5(input-string), ivec=0)
1246 key generation functions:
1248 string-to-key des_string_to_key
1250 random-to-key des_random_to_key
1252 key-derivation identity
1254 The des-cbc-md5 encryption type is assigned the etype value three
1259 The des-cbc-md4 encryption mode also encrypts information under DES
1260 in CBC mode, with an all-zero initial vector. An MD4 checksum
1261 (described in [MD4-92]) is computed and placed in the checksum field.
1264 --------------------------------------------------------------------
1265 protocol key format 8 bytes, parity in low bit of each
1267 specific key structure copy of original key
1269 required checksum rsa-md4-des
1272 key-generation seed 8 bytes
1275 cipher state 8 bytes (CBC initial vector)
1277 initial cipher state all-zero
1279 encryption function des-cbc(confounder | checksum | msg | pad,
1282 checksum = md4(confounder | 0000...
1285 newstate = last block of des-cbc output
1292 INTERNET DRAFT October 2003
1296 --------------------------------------------------------------------
1298 decryption function decrypt encrypted text and verify checksum
1300 newstate = last block of ciphertext
1302 default string-to-key empty string
1305 pseudo-random function des-cbc(md5(input-string), ivec=0)
1307 key generation functions:
1309 string-to-key des_string_to_key
1311 random-to-key copy input, then fix parity bits
1313 key-derivation identity
1315 Note that des-cbc-md4 uses md5, not md4, in the PRF definition.
1317 The des-cbc-md4 encryption algorithm is assigned the etype value two
1322 The des-cbc-crc encryption type uses DES in CBC mode with the key
1323 used as the initialization vector, with a 4-octet CRC-based checksum
1324 computed as described in section 6.1.3. Note that this is not a
1325 standard CRC-32 checksum, but a slightly modified one.
1329 --------------------------------------------------------------------
1330 protocol key format 8 bytes, parity in low bit of each
1332 specific key structure copy of original key
1334 required checksum rsa-md5-des
1337 key-generation seed 8 bytes
1340 cipher state 8 bytes (CBC initial vector)
1348 INTERNET DRAFT October 2003
1352 --------------------------------------------------------------------
1353 initial cipher state copy of original key
1355 encryption function des-cbc(confounder | checksum | msg | pad,
1358 checksum = crc(confounder | 00000000
1361 newstate = last block of des-cbc output
1363 decryption function decrypt encrypted text and verify checksum
1365 newstate = last block of ciphertext
1367 default string-to-key empty string
1370 pseudo-random function des-cbc(md5(input-string), ivec=0)
1372 key generation functions:
1374 string-to-key des_string_to_key
1376 random-to-key copy input, then fix parity bits
1378 key-derivation identity
1380 The des-cbc-crc encryption algorithm is assigned the etype value one
1383 6.2.4. RSA MD5 Cryptographic Checksum Using DES
1385 The RSA-MD5-DES checksum calculates a keyed collision-proof checksum
1386 by prepending an 8 octet confounder before the text, applying the RSA
1387 MD5 checksum algorithm, and encrypting the confounder and the
1388 checksum using DES in cipher-block-chaining (CBC) mode using a
1389 variant of the key, where the variant is computed by eXclusive-ORing
1390 the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0. The
1391 initialization vector should be zero. The resulting checksum is 24
1392 octets long. This checksum is tamper-proof and believed to be
1404 INTERNET DRAFT October 2003
1408 ----------------------------------------------------------------
1409 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
1411 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
1412 conf | rsa-md5(conf | msg))
1414 verify_mic decrypt and verify rsa-md5 checksum
1417 The rsa-md5-des checksum algorithm is assigned a checksum type number
1420 6.2.5. RSA MD4 Cryptographic Checksum Using DES
1422 The RSA-MD4-DES checksum calculates a keyed collision-proof checksum
1423 by prepending an 8 octet confounder before the text, applying the RSA
1424 MD4 checksum algorithm [MD4-92], and encrypting the confounder and
1425 the checksum using DES in cipher-block-chaining (CBC) mode using a
1426 variant of the key, where the variant is computed by eXclusive-ORing
1427 the key with the constant 0xF0F0F0F0F0F0F0F0. [7] The initialization
1428 vector should be zero. The resulting checksum is 24 octets long.
1429 This checksum is tamper-proof and believed to be collision-proof.
1432 ----------------------------------------------------------------
1433 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
1435 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
1436 conf | rsa-md4(conf | msg),
1439 verify_mic decrypt and verify rsa-md4 checksum
1441 The rsa-md4-des checksum algorithm is assigned a checksum type number
1444 6.2.6. RSA MD4 Cryptographic Checksum Using DES alternative
1446 The RSA-MD4-DES-K checksum calculates a keyed collision-proof
1447 checksum by applying the RSA MD4 checksum algorithm and encrypting
1448 the results using DES in cipher block chaining (CBC) mode using a DES
1449 key as both key and initialization vector. The resulting checksum is
1450 16 octets long. This checksum is tamper-proof and believed to be
1451 collision-proof. Note that this checksum type is the old method for
1452 encoding the RSA-MD4-DES checksum and it is no longer recommended.
1460 INTERNET DRAFT October 2003
1464 ----------------------------------------------------------------
1465 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
1467 get_mic des-cbc(key, md4(msg), ivec=key)
1469 verify_mic decrypt, compute checksum and compare
1472 The rsa-md4-des-k checksum algorithm is assigned a checksum type
1475 6.2.7. DES CBC checksum
1477 The DES-MAC checksum is computed by prepending an 8 octet confounder
1478 to the plaintext, padding with zero-valued octets if necessary to
1479 bring the length to a multiple of 8 octets, performing a DES CBC-mode
1480 encryption on the result using the key and an initialization vector
1481 of zero, taking the last block of the ciphertext, prepending the same
1482 confounder and encrypting the pair using DES in cipher-block-chaining
1483 (CBC) mode using a variant of the key, where the variant is computed
1484 by eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0. The
1485 initialization vector should be zero. The resulting checksum is 128
1486 bits (16 octets) long, 64 bits of which are redundant. This checksum
1487 is tamper-proof and collision-proof.
1491 ----------------------------------------------------------------------
1492 associated des-cbc-md5, des-cbc-md4, des-cbc-crc
1495 get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
1496 conf | des-mac(key, conf | msg | pad, ivec=0),
1499 verify_mic decrypt, compute DES MAC using confounder, compare
1502 The des-mac checksum algorithm is assigned a checksum type number of
1505 6.2.8. DES CBC checksum alternative
1507 The DES-MAC-K checksum is computed by performing a DES CBC-mode
1508 encryption of the plaintext, with zero-valued padding bytes if
1509 necessary to bring the length to a multiple of 8 octets, and using
1510 the last block of the ciphertext as the checksum value. It is keyed
1516 INTERNET DRAFT October 2003
1519 with an encryption key which is also used as the initialization
1520 vector. The resulting checksum is 64 bits (8 octets) long. This
1521 checksum is tamper-proof and collision-proof. Note that this
1522 checksum type is the old method for encoding the DESMAC checksum and
1523 it is no longer recommended.
1527 ----------------------------------------------------------------
1528 associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
1530 get_mic des-mac(key, msg | pad, ivec=key)
1532 verify_mic compute MAC and compare
1535 The des-mac-k checksum algorithm is assigned a checksum type number
1538 6.3. Triple-DES based encryption and checksum types
1540 This encryption and checksum type pair is based on the Triple DES
1541 cryptosystem in Outer-CBC mode, and the HMAC-SHA1 message
1542 authentication algorithm.
1544 A Triple DES key is the concatenation of three DES keys as described
1545 above for des-cbc-md5. A Triple DES key is generated from random
1546 data by creating three DES keys from separate sequences of random
1549 Encrypted data using this type must be generated as described in
1550 section 5.3. If the length of the input data is not a multiple of
1551 the block size, zero-valued octets must be used to pad the plaintext
1552 to the next eight-octet boundary. The confounder must be eight
1553 random octets (one block).
1555 The simplified profile for Triple DES, with key derivation as defined
1556 in section 5, is as follows:
1558 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
1559 ------------------------------------------------
1560 protocol key format 24 bytes, parity in low
1563 key-generation seed 21 bytes
1572 INTERNET DRAFT October 2003
1575 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
1576 ------------------------------------------------
1579 HMAC output size 160 bits
1581 message block size 8 bytes
1583 default string-to-key empty string
1586 encryption and triple-DES encrypt and
1587 decryption functions decrypt, in outer-CBC
1588 mode (cipher block size
1591 key generation functions:
1593 random-to-key DES3random-to-key (see
1596 string-to-key DES3string-to-key (see
1599 The des3-cbc-hmac-sha1-kd encryption type is assigned the value
1600 sixteen (16). The hmac-sha1-des3-kd checksum algorithm is assigned a
1601 checksum type number of twelve (12).
1603 6.3.1. Triple DES Key Production (random-to-key, string-to-key)
1605 The 168 bits of random key data are converted to a protocol key value
1606 as follows. First, the 168 bits are divided into three groups of 56
1607 bits, which are expanded individually into 64 bits as follows:
1611 9 10 11 12 13 14 15 p
1612 17 18 19 20 21 22 23 p
1613 25 26 27 28 29 30 31 p
1614 33 34 35 36 37 38 39 p
1615 41 42 43 44 45 46 47 p
1616 49 50 51 52 53 54 55 p
1617 56 48 40 32 24 16 8 p
1619 The "p" bits are parity bits computed over the data bits. The output
1620 of the three expansions, each corrected to avoid "weak" and "semi-
1621 weak" keys as in section 6.2, are concatenated to form the protocol
1628 INTERNET DRAFT October 2003
1631 The string-to-key function is used to transform UTF-8 passwords into
1632 DES3 keys. The DES3 string-to-key function relies on the "N-fold"
1633 algorithm and DK function, described in section 5.
1635 The n-fold algorithm is applied to the password string concatenated
1636 with a salt value. For 3-key triple DES, the operation will involve
1637 a 168-fold of the input password string, to generate an intermediate
1638 key, from which the user's long-term key will be derived with the DK
1639 function. The DES3 string-to-key function is shown here in
1642 DES3string-to-key(passwordString, salt, params)
1643 if (params != emptyString)
1644 error("invalid params");
1645 s = passwordString + salt
1646 tmpKey = random-to-key(168-fold(s))
1647 key = DK (tmpKey, KerberosConstant)
1649 Weak key checking is performed in the random-to-key and DK
1650 operations. The KerberosConstant value is the byte string {0x6b 0x65
1651 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the ASCII
1652 encoding for the string "kerberos".
1654 7. Use of Kerberos encryption outside this specification
1656 Several Kerberos-based application protocols and preauthentication
1657 systems have been designed and deployed that perform encryption and
1658 message integrity checks in various ways. While in some cases there
1659 may be good reason for specifying these protocols in terms of
1660 specific encryption or checksum algorithms, we anticipate that in
1661 many cases this will not be true, and more generic approaches
1662 independent of particular algorithms will be desirable. Rather than
1663 having each protocol designer reinvent schemes for protecting data,
1664 using multiple keys, etc, we have attempted to present in this
1665 section a general framework that should be sufficient not only for
1666 the Kerberos protocol itself but also for many preauthentication
1667 systems and application protocols, while trying to avoid some of the
1668 assumptions that can work their way into such protocol designs.
1670 Some problematic assumptions we've seen (and sometimes made) include:
1671 that a random bitstring is always valid as a key (not true for DES
1672 keys with parity); that the basic block encryption chaining mode
1673 provides no integrity checking, or can easily be separated from such
1674 checking (not true for many modes in development that do both
1675 simultaneously); that a checksum for a message always results in the
1676 same value (not true if a confounder is incorporated); that an
1677 initial vector is used (may not be true if a block cipher in CBC mode
1684 INTERNET DRAFT October 2003
1687 Such assumptions, while they may hold for any given set of encryption
1688 and checksum algorithms, may not be true of the next algorithms to be
1689 defined, leaving the application protocol unable to make use of those
1690 algorithms without updates to its specification.
1692 The Kerberos protocol uses only the attributes and operations
1693 described in sections 3 and 4. Preauthentication systems and
1694 application protocols making use of Kerberos are encouraged to use
1695 them as well. The specific key and string-to-key parameters should
1696 generally be treated as opaque. While the string-to-key parameters
1697 are manipulated as an octet string, the representation for the
1698 specific key structure is implementation-defined; it may not even be
1701 While we don't recommend it, some application protocols will
1702 undoubtedly continue to use the key data directly, even if only in
1703 some of the currently existing protocol specifications. An
1704 implementation intended to support general Kerberos applications may
1705 therefore need to make the key data available, as well as the
1706 attributes and operations described in sections 3 and 4. [8]
1710 The following encryption type numbers are already assigned or
1711 reserved for use in Kerberos and related protocols.
1714 encryption type etype section or comment
1715 -----------------------------------------------------------------
1723 dsaWithSHA1-CmsOID 9 (pkinit)
1724 md5WithRSAEncryption-CmsOID 10 (pkinit)
1725 sha1WithRSAEncryption-CmsOID 11 (pkinit)
1726 rc2CBC-EnvOID 12 (pkinit)
1727 rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5)
1728 rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0)
1729 des-ede3-cbc-Env-OID 15 (pkinit)
1730 des3-cbc-sha1-kd 16 6.3
1731 aes128-cts-hmac-sha1-96 17 [KRB5-AES]
1732 aes256-cts-hmac-sha1-96 18 [KRB5-AES]
1733 rc4-hmac 23 (Microsoft)
1740 INTERNET DRAFT October 2003
1743 rc4-hmac-exp 24 (Microsoft)
1744 subkey-keymaterial 65 (opaque; PacketCable)
1747 (The "des3-cbc-sha1" assignment is a deprecated version using no key
1748 derivation. It should not be confused with des3-cbc-sha1-kd.)
1750 Several numbers have been reserved for use in encryption systems not
1751 defined here. Encryption type numbers have unfortunately been
1752 overloaded on occasion in Kerberos-related protocols, so some of the
1753 reserved numbers do not and will not correspond to encryption systems
1754 fitting the profile presented here.
1756 The following checksum type numbers are assigned or reserved. As
1757 with encryption type numbers, some overloading of checksum numbers
1761 Checksum type sumtype checksum section or
1762 value size reference
1763 ----------------------------------------------------------------------
1766 rsa-md4-des 3 24 6.2.5
1769 rsa-md4-des-k 6 16 6.2.6
1771 rsa-md5-des 8 24 6.2.4
1772 rsa-md5-des3 9 24 ??
1773 sha1 (unkeyed) 10 20 ??
1774 hmac-sha1-des3-kd 12 20 6.3
1775 hmac-sha1-des3 13 20 ??
1776 sha1 (unkeyed) 14 20 ??
1777 hmac-sha1-96-aes128 15 20 [KRB5-AES]
1778 hmac-sha1-96-aes256 16 20 [KRB5-AES]
1779 [reserved] 0x8003 ? [GSS-KRB5]
1782 Encryption and checksum type numbers are signed 32-bit values. Zero
1783 is invalid, and negative numbers are reserved for local use. All
1784 standardized values must be positive.
1796 INTERNET DRAFT October 2003
1799 9. Implementation Notes
1801 The "interface" described here is the minimal information that must
1802 be defined to make a cryptosystem useful within Kerberos in an
1803 interoperable fashion. Despite the functional notation used in some
1804 places, it is not an attempt to define an API for cryptographic
1805 functionality within Kerberos. Actual implementations providing
1806 clean APIs will probably find it useful to make additional
1807 information available, which should be possible to derive from a
1808 specification written to the framework given here. For example, an
1809 application designer may wish to determine the largest number of
1810 bytes that can be encrypted without overflowing a certain size output
1811 buffer, or conversely, the maximum number of bytes that might be
1812 obtained by decrypting a ciphertext message of a given size. (In
1813 fact, an implementation of the GSS-API Kerberos mechanism [GSS-KRB5]
1814 will require some of these.)
1816 The presence of a mechanism in this document should not be taken as
1817 an indication that it must be implemented for compliance with any
1818 specification; required mechanisms will be specified elsewhere.
1819 Indeed, some of the mechanisms described here for backwards
1820 compatibility are now considered rather weak for protecting critical
1823 10. Security Considerations
1825 Recent years have brought advancements in the ability to perform
1826 large-scale attacks against DES, to such a degree that it is not
1827 considered a strong encryption mechanism any longer; triple-DES is
1828 generally preferred in its place, despite the poorer performance.
1829 See [ESP-DES] for a summary of some of the potential attacks, and
1830 [EFF-DES] for a detailed discussion of the implementation of
1831 particular attack. However, most Kerberos implementations still have
1832 DES as their primary interoperable encryption type.
1834 DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of
1835 single-DES here avoids them. However, DES also has 48 'possibly-
1836 weak' keys [Schneier96] (note that the tables in many editions of the
1837 reference contains errors) which are not avoided.
1839 DES weak keys are keys with the property that E1(E1(P)) = P (where E1
1840 denotes encryption of a single block with key 1). DES semi-weak keys
1841 or "dual" keys are pairs of keys with the property that E1(P) =
1842 D2(P), and thus E2(E1(P)) = P. Because of the use of CBC mode and
1843 leading random confounder, however, these properties are unlikely to
1844 present a security problem.
1846 Many of the choices concerning when weak-key corrections are
1852 INTERNET DRAFT October 2003
1855 performed relate more to compatibility with existing implementations
1856 than to any risk analysis.
1858 While checks are also done for the component DES keys in a triple-DES
1859 key, the nature of the weak keys is such that it is extremely
1860 unlikely that they will weaken the triple-DES encryption -- only
1861 slightly more likely than having the middle of the three sub-keys
1862 match one of the other two, which effectively converts the encryption
1863 to single-DES, which is a case we make no effort to avoid.
1865 The true CRC-32 checksum is not collision-proof; an attacker could
1866 use a probabilistic chosen-plaintext attack to generate a valid
1867 message even if a confounder is used [SG92]. The use of collision-
1868 proof checksums is of course recommended for environments where such
1869 attacks represent a significant threat. The "simplifications" (read:
1870 bugs) introduced when CRC-32 was implemented for Kerberos cause
1871 leading zeros to effectively be ignored, so messages differing only
1872 in leading zero bits will have the same checksum.
1874 [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm.
1875 Unlike [IPSEC-HMAC], the triple-DES specification here does not use
1876 the suggested truncation of the HMAC output. As pointed out in
1877 [IPSEC-HMAC], SHA-1 was not developed to be used as a keyed hash
1878 function, which is a criterion of HMAC. [HMAC-TEST] contains test
1879 vectors for HMAC-SHA-1.
1881 The mit_des_string_to_key function was originally constructed with
1882 the assumption that all input would be ASCII; it ignores the top bit
1883 of each input byte. Folding with XOR is also not an especially good
1884 mixing mechanism in terms of preserving randomness.
1886 The n-fold function used in the string-to-key operation for des3-cbc-
1887 hmac-sha1-kd was designed to cause each bit of input to contribute
1888 equally to the output; it was not designed to maximize or equally
1889 distribute randomness in the input, and there are conceivable cases
1890 of partially structured input where randomness may be lost. This
1891 should only be an issue for highly structured passwords, however.
1893 [RFC1851] discusses the relative strength of triple-DES encryption.
1894 The relative slow speed of triple-DES encryption may also be an issue
1895 for some applications.
1897 In [Bellovin91], there is a suggestion that analyses of encryption
1898 schemes should include a model of an attacker capable of submitting
1899 known plaintexts to be encrypted with an unknown key, as well as
1900 being able to perform many types of operations on known protocol
1901 messages. Recent experiences with the chosen-plaintext attacks on
1902 Kerberos version 4 bear out the value of this suggestion.
1908 INTERNET DRAFT October 2003
1911 The use of unkeyed encrypted checksums, such as those used in the
1912 single-DES cryptosystems specified in [Kerb1510], allows for cut-and-
1913 paste attacks, especially if a confounder is not used. In addition,
1914 unkeyed encrypted checksums are vulnerable to chosen-plaintext
1915 attacks: an attacker with access to an encryption oracle can easily
1916 encrypt the required unkeyed checksum along with the chosen
1917 plaintext. [Bellovin99] These weaknesses, combined with a common
1918 implementation design choice described below, allow for a cross-
1919 protocol attack from version 4 to version 5.
1921 The use of a random confounder is an important means of preventing an
1922 attacker from making effective use of protocol exchanges as an
1923 encryption oracle. In Kerberos version 4, the encryption of constant
1924 plaintext to constant ciphertext makes an effective encryption oracle
1925 for an attacker. The use of random confounders in [Kerb1510]
1926 frustrates this sort of chosen-plaintext attack.
1928 Using the same key for multiple purposes can enable or increase the
1929 scope of chosen-plaintext attacks. Some software which implements
1930 both versions 4 and 5 of the Kerberos protocol uses the same keys for
1931 both versions of the protocol. This enables the encryption oracle of
1932 version 4 to be used to attack version 5. Vulnerabilities such as
1933 this cross-protocol attack reinforce the wisdom of not using a key
1934 for multiple purposes.
1936 This document, like the Kerberos protocol, completely ignores the
1937 notion of limiting the amount of data a key may be used with to a
1938 quantity based on the robustness of the algorithm or size of the key.
1939 It is assumed that any defined algorithms and key sizes will be
1940 strong enough to support very large amounts of data, or they will be
1941 deprecated once significant attacks are known.
1943 This document also places no bounds on the amount of data that can be
1944 handled in various operations. In order to avoid denial of service
1945 attacks, implementations will probably want to restrict message sizes
1946 at some higher level.
1948 11. IANA Considerations
1950 Two registries for numeric values should be created: Kerberos
1951 Encryption Type Numbers and Kerberos Checksum Type Numbers. These
1952 are signed 32-bit values in twos-complement form. Positive values up
1953 to 2**31-1 inclusive should be assigned only for algorithms specified
1954 in accordance with this specification for use with Kerberos or
1955 related protocols. Negative values through -2**31 are for private
1956 use; local and experimental algorithms should use these values. Zero
1957 is reserved and may not be assigned.
1964 INTERNET DRAFT October 2003
1967 Positive encryption and checksum type numbers may be assigned
1968 following either of two policies described in [BCP26].
1970 Standards-track specifications may be assigned values under the
1971 Standards Action policy.
1973 Specifications in Informational RFCs may be assigned values after
1974 Expert Review. A non-IETF specification may be assigned values by
1975 publishing an Informational or standards-track RFC referencing the
1976 external specification; that specification must be public and
1977 published in some permanent record much like the IETF RFCs. It is
1978 highly desirable, though not required, that the full specification be
1979 published as an IETF RFC.
1981 Smaller encryption type values, which encode to smaller octet strings
1982 under ASN.1, should be used for IETF standards-track mechanisms, and
1983 much higher values (hex 0x1000000 and above) for other mechanisms.
1984 No other guidance into allocation order is given.
1986 Draft IETF specifications should not include values for encryption
1987 and checksum type numbers. Instead, they should indicate that values
1988 would be assigned by IANA when the document is approved as an RFC.
1989 For development and interoperability testing, values in the private-
1990 use range (negative values) may be used, but should not be included
1991 in the draft specification.
1993 Each registered value should have an associated unique name to refer
1994 to it by. The lists given in section 8 should be used as an initial
1995 registry; they include reservations for specifications in progress in
1996 parallel with this document, and for certain other values believed to
2001 This document is an extension of the encryption specification
2002 included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much
2003 of the text of the background, concepts, and DES specifications are
2004 drawn directly from that document.
2006 The abstract framework presented in this document was put together by
2007 Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn,
2008 and Tom Yu, and the details were refined several times based on
2009 comments from John Brezak and others.
2011 Marc Horowitz wrote the original specification of triple-DES and key
2012 derivation in a pair of Internet Drafts (under the names draft-
2013 horowitz-key-derivation and draft-horowitz-kerb-key-derivation) which
2014 were later folded into a draft revision of [Kerb1510], from which
2020 INTERNET DRAFT October 2003
2023 this document was later split off.
2025 Tom Yu provided the text describing the modifications to the standard
2026 CRC algorithm as Kerberos implementations actually use it, and some
2027 of the Security Considerations section.
2029 Miroslav Jurisic provided information for one of the UTF-8 test cases
2030 for the string-to-key functions.
2032 Marcus Watts noticed some errors in earlier drafts, and pointed out
2033 that the simplified profile could easily be modified to support
2034 cipher text stealing modes.
2036 Simon Josefsson contributed some clarifications to the DES "CBC
2037 checksum", string-to-key and weak key descriptions, and some test
2040 Simon Josefsson, Louis LeVay and others also caught some errors in
2045 This section provides test vectors for various functions defined or
2046 described in this document. For convenience, most inputs are ASCII
2047 strings, though some UTF-8 samples are be provided for string-to-key
2048 functions. Keys and other binary data are specified as hexadecimal
2053 The n-fold function is defined in section 5.1. As noted there, the
2054 sample vector in the original paper defining the algorithm appears to
2055 be incorrect. Here are some test cases provided by Marc Horowitz and
2076 INTERNET DRAFT October 2003
2080 64-fold(303132333435) = be072631276b1955
2082 56-fold("password") =
2083 56-fold(70617373776f7264) = 78a07b6caf85fa
2085 64-fold("Rough Consensus, and Running Code") =
2086 64-fold(526f75676820436f6e73656e7375732c20616e642052756e
2087 6e696e6720436f6465) = bb6ed30870b7f0e0
2089 168-fold("password") =
2090 168-fold(70617373776f7264) =
2091 59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e
2093 192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY"
2094 192-fold(4d41535341434856534554545320494e5354495456544520
2095 4f4620544543484e4f4c4f4759) =
2096 db3b0d8f0b061e603282b308a50841229ad798fab9540c1b
2100 518a54a2 15a8452a 518a54a2 15a8452a
2105 fb25d531 ae897449 9f52fd92 ea9857c4
2108 Here are some additional values corresponding to folded values of the
2109 string "kerberos"; the 64-bit form is used in the des3 string-to-key
2112 64-fold("kerberos") =
2114 128-fold("kerberos") =
2115 6b657262 65726f73 7b9b5b2b 93132b93
2116 168-fold("kerberos") =
2117 8372c236 344e5f15 50cd0747 e15d62ca
2119 256-fold("kerberos") =
2120 6b657262 65726f73 7b9b5b2b 93132b93
2121 5c9bdcda d95c9899 c4cae4de e6d6cae4
2123 Note that the initial octets exactly match the input string when the
2124 output length is a multiple of the input length.
2132 INTERNET DRAFT October 2003
2135 A.2. mit_des_string_to_key
2137 The function mit_des_string_to_key is defined in section 6.2. We
2138 present here several test values, with some of the intermediate
2139 results. The fourth test demonstrates the use of UTF-8 with three
2140 characters. The last two tests are specifically constructed so as to
2141 trigger the weak-key fixups for the intermediate key produced by fan-
2142 folding; we have no test cases that cause such fixups for the final
2146 UTF-8 encodings used in test vector:
2147 eszett C3 9F s-caron C5 A1 c-acute C4 87
2154 salt: "ATHENA.MIT.EDUraeburn"
2155 415448454e412e4d49542e4544557261656275726e
2156 password: "password" 70617373776f7264
2157 fan-fold result: c01e38688ac86c2e
2158 intermediate key: c11f38688ac86d2f
2159 DES key: cbc22fae235298e3
2163 salt: "WHITEHOUSE.GOVdanny" 5748495445484f5553452e474f5664616e6e79
2164 password: "potatoe" 706f7461746f65
2165 fan-fold result: a028944ee63c0416
2166 intermediate key: a129944fe63d0416
2167 DES key: df3d32a74fd92a01
2171 salt: "EXAMPLE.COMpianist" 4558414D504C452E434F4D7069616E697374
2172 password: g-clef f09d849e
2173 fan-fold result: 3c4a262c18fab090
2174 intermediate key: 3d4a262c19fbb091
2175 DES key: 4ffb26bab0cd9413
2188 INTERNET DRAFT October 2003
2191 salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute
2192 415448454e412e4d49542e4544554a757269c5a169c487
2193 password: eszett c39f
2194 fan-fold result: b8f6c40e305afc9e
2195 intermediate key: b9f7c40e315bfd9e
2196 DES key: 62c81a5232b5e69d
2200 salt: "AAAAAAAA" 4141414141414141
2201 password: "11119999" 3131313139393939
2202 fan-fold result: e0e0e0e0f0f0f0f0
2203 intermediate key: e0e0e0e0f1f1f101
2204 DES key: 984054d0f1a73e31
2208 salt: "FFFFAAAA" 4646464641414141
2209 password: "NNNN6666" 4e4e4e4e36363636
2210 fan-fold result: 1e1e1e1e0e0e0e0e
2211 intermediate key: 1f1f1f1f0e0e0efe
2212 DES key: c4bf6b25adf7a4f8
2215 This trace provided by Simon Josefsson shows the intermediate
2216 processing stages of one of the test inputs:
2218 string_to_key (des-cbc-md5, string, salt)
2220 ;; `password' (length 8 bytes)
2221 ;; 70 61 73 73 77 6f 72 64
2223 ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
2224 ;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61
2226 des_string_to_key (string, salt)
2228 ;; `password' (length 8 bytes)
2229 ;; 70 61 73 73 77 6f 72 64
2231 ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
2232 ;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61
2244 INTERNET DRAFT October 2003
2247 tempstring = 0; /* 56-bit string */
2248 pad(s); /* with nulls to 8 byte boundary */
2249 ;; s = pad(string|salt):
2250 ;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00'
2251 ;; (length 32 bytes)
2252 ;; 70 61 73 73 77 6f 72 64 41 54 48 45 4e 41 2e 4d
2253 ;; 49 54 2e 45 44 55 72 61 65 62 75 72 6e 00 00 00
2254 for (8byteblock in s) {
2257 ;; `password' (length 8 bytes)
2258 ;; 70 61 73 73 77 6f 72 64
2259 ;; 01110000 01100001 01110011 01110011 01110111 01101111
2260 ;; 01110010 01100100
2261 56bitstring = removeMSBits(8byteblock);
2263 ;; 1110000 1100001 1110011 1110011 1110111 1101111
2265 if (odd == 0) reverse(56bitstring); ;; odd=1
2267 tempstring = tempstring XOR 56bitstring;
2269 ;; 1110000 1100001 1110011 1110011 1110111 1101111
2272 for (8byteblock in s) {
2275 ;; `ATHENA.M' (length 8 bytes)
2276 ;; 41 54 48 45 4e 41 2e 4d
2277 ;; 01000001 01010100 01001000 01000101 01001110 01000001
2278 ;; 00101110 01001101
2279 56bitstring = removeMSBits(8byteblock);
2281 ;; 1000001 1010100 1001000 1000101 1001110 1000001
2283 if (odd == 0) reverse(56bitstring); ;; odd=0
2284 reverse(56bitstring)
2285 ;; 56bitstring after reverse
2286 ;; 1011001 0111010 1000001 0111001 1010001 0001001
2289 tempstring = tempstring XOR 56bitstring;
2291 ;; 0101001 1011011 0110010 1001010 0100110 1100110
2300 INTERNET DRAFT October 2003
2303 for (8byteblock in s) {
2306 ;; `IT.EDUra' (length 8 bytes)
2307 ;; 49 54 2e 45 44 55 72 61
2308 ;; 01001001 01010100 00101110 01000101 01000100 01010101
2309 ;; 01110010 01100001
2310 56bitstring = removeMSBits(8byteblock);
2312 ;; 1001001 1010100 0101110 1000101 1000100 1010101
2314 if (odd == 0) reverse(56bitstring); ;; odd=1
2316 tempstring = tempstring XOR 56bitstring;
2318 ;; 1100000 0001111 0011100 0001111 1100010 0110011
2321 for (8byteblock in s) {
2324 ;; `eburn\x00\x00\x00' (length 8 bytes)
2325 ;; 65 62 75 72 6e 00 00 00
2326 ;; 01100101 01100010 01110101 01110010 01101110 00000000
2327 ;; 00000000 00000000
2328 56bitstring = removeMSBits(8byteblock);
2330 ;; 1100101 1100010 1110101 1110010 1101110 0000000
2332 if (odd == 0) reverse(56bitstring); ;; odd=0
2333 reverse(56bitstring)
2334 ;; 56bitstring after reverse
2335 ;; 0000000 0000000 0000000 0111011 0100111 1010111
2338 tempstring = tempstring XOR 56bitstring;
2340 ;; 1100000 0001111 0011100 0110100 1000101 1100100
2343 for (8byteblock in s) {
2345 ;; for loop terminated
2356 INTERNET DRAFT October 2003
2359 tempkey = key_correction(add_parity_bits(tempstring));
2361 ;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes)
2362 ;; c1 1f 38 68 8a c8 6d 2f
2363 ;; 11000001 00011111 00111000 01101000 10001010 11001000
2364 ;; 01101101 00101111
2366 key = key_correction(DES-CBC-check(s,tempkey));
2368 ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
2369 ;; cb c2 2f ae 23 52 98 e3
2370 ;; 11001011 11000010 00101111 10101110 00100011 01010010
2371 ;; 10011000 11100011
2373 ;; string_to_key key:
2374 ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
2375 ;; cb c2 2f ae 23 52 98 e3
2380 These tests show the derived-random and derived-key values for the
2381 des3-hmac-sha1-kd encryption scheme, using the DR and DK functions
2382 defined in section 6.3.1. The input keys were randomly generated;
2383 the usage values are from this specification.
2386 key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92
2388 DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705
2389 DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd
2391 key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2
2393 DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2
2394 DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207
2396 key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc
2398 DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb
2399 DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf
2401 key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5
2403 DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70
2404 DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e
2412 INTERNET DRAFT October 2003
2415 key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb
2416 usage: 6b65726265726f73 ("kerberos")
2417 DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da
2418 DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43
2420 key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da
2422 DR: 348056ec98fcc517171d2b4d7a9493af482d999175
2423 DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
2425 key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c
2427 DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5
2428 DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
2430 key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443
2432 DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a
2433 DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49
2435 key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016
2437 DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec
2438 DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d
2441 A.4. DES3string_to_key
2443 These are the keys generated for some of the above input strings for
2444 triple-DES with key derivation as defined in section 6.3.1.
2446 salt: "ATHENA.MIT.EDUraeburn"
2448 key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
2450 salt: "WHITEHOUSE.GOVdanny"
2452 key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a
2454 salt: "EXAMPLE.COMbuckaroo"
2456 key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a
2458 salt: "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute
2460 key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0
2468 INTERNET DRAFT October 2003
2471 salt: "EXAMPLE.COMpianist"
2473 key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19
2475 A.5. Modified CRC-32
2477 Below are modified-CRC32 values for various ASCII and octet strings.
2478 Only the printable ASCII characters are checksummed, no C-style
2479 trailing zero-valued octet. The 32-bit modified CRC and the sequence
2480 of output bytes as used in Kerberos are shown. (The octet values are
2481 separated here to emphasize that they are octet values and not 32-bit
2482 numbers, which will be the most convenient form for manipulation in
2483 some implementations. The bit and byte order used internally for
2484 such a number is irrelevant; the octet sequence generated is what is
2488 mod-crc-32("foo") = 33 bc 32 73
2489 mod-crc-32("test0123456789") = d6 88 3e b8
2490 mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3
2491 mod-crc-32(8000) = 4b 98 83 3b
2492 mod-crc-32(0008) = 32 88 db 0e
2493 mod-crc-32(0080) = 20 83 b8 ed
2494 mod-crc-32(80) = 20 83 b8 ed
2495 mod-crc-32(80000000) = 3b b6 59 ed
2496 mod-crc-32(00000001) = 96 30 07 77
2499 B. Significant Changes from RFC 1510
2501 The encryption and checksum mechanism profiles are new. The old
2502 specification defined a few operations for various mechanisms, but
2503 didn't outline what should be required of new mechanisms in terms of
2504 abstract properties, nor how to ensure that a mechanism specification
2505 is complete enough for interoperability between implementations. The
2506 new profiles do differ from the old specification in a few ways:
2508 Some message definitions in [Kerb1510] could be read as permitting
2509 the initial vector to be specified by the application; the text
2510 was too vague. It is specifically not permitted in this
2511 specification. Some encryption algorithms may not use
2512 initialization vectors, so relying on chosen, secret
2513 initialization vectors for security is unwise. Also, the
2514 prepended confounder in the existing algorithms is roughly
2515 equivalent to a per-message initialization vector that is revealed
2516 in encrypted form. However, carrying state across from one
2517 encryption to another is explicitly permitted through the opaque
2518 "cipher state" object.
2524 INTERNET DRAFT October 2003
2527 The use of key derivation is new.
2529 Several new methods are introduced, including generation of a key
2530 in wire-protocol format from random input data.
2532 The means for influencing the string-to-key algorithm are laid out
2535 Triple-DES support is new.
2537 The pseudo-random function is new.
2539 The des-cbc-crc, DES string-to-key and CRC descriptions have been
2540 updated to align them with existing implementations.
2542 [Kerb1510] had no indication what character set or encoding might be
2543 used for pass phrases and salts.
2545 In [Kerb1510], key types, encryption algorithms and checksum
2546 algorithms were only loosely associated, and the association was not
2547 well described. In this specification, key types and encryption
2548 algorithms have a one-to-one correspondence, and associations between
2549 encryption and checksum algorithms are described so that checksums
2550 can be computed given negotiated keys, without requiring further
2551 negotiation for checksum types.
2555 [1] While Message Authentication Code (MAC) or Message Integrity
2556 Check (MIC) would be more appropriate terms for many of the
2557 uses in this document, we continue to use the term "checksum"
2558 for historical reasons.
2560 [2] Extending CBC mode across messages would be one obvious
2561 example of this chaining. Another might be the use of
2562 counter mode, with a counter randomly initialized and
2563 attached to the ciphertext; a second message could continue
2564 incrementing the counter when chaining the cipher state, thus
2565 avoiding having to transmit another counter value. However,
2566 this chaining is only useful for uninterrupted, ordered
2567 sequences of messages.
2569 [3] In the case of Kerberos, the encrypted objects will generally
2570 be ASN.1 DER encodings, which contain indications of their
2571 length in the first few octets.
2573 [4] As of the time of this writing, some new modes of operation
2574 have been proposed, some of which may permit encryption and
2580 INTERNET DRAFT October 2003
2583 integrity protection simultaneously. After some of these
2584 proposals have been subjected to adequate analysis, we may
2585 wish to formulate a new simplified profile based on one of
2588 [5] It should be noted that the sample vector in Appendix B.2 of
2589 the original paper appears to be incorrect. Two independent
2590 implementations from the specification (one in C by Marc
2591 Horowitz, and another in Scheme by Bill Sommerfeld) agree on
2592 a value different from that in [Blumenthal96].
2594 [6] For example, in MIT's implementation of [Kerb1510], the rsa-
2595 md5 unkeyed checksum of application data may be included in
2596 an authenticator encrypted in a service's key; since rsa-md5
2597 is believed to be collision-proof, even if the application
2598 data is exposed to an attacker, it cannot be modified without
2599 causing the checksum verification to fail.
2601 [7] A variant of the key is used to limit the use of a key to a
2602 particular function, separating the functions of generating a
2603 checksum from other encryption performed using the session
2604 key. The constant 0xF0F0F0F0F0F0F0F0 was chosen because it
2605 maintains key parity. The properties of DES precluded the
2606 use of the complement. The same constant is used for similar
2607 purpose in the Message Integrity Check in the Privacy
2608 Enhanced Mail standard.
2610 [8] Perhaps one of the more common reasons for directly
2611 performing encryption is direct control over the negotiation
2612 and to select a "sufficiently strong" encryption algorithm
2613 (whatever that means in the context of a given application).
2614 While Kerberos directly provides no facility for negotiating
2615 encryption types between the application client and server,
2616 there are other means for accomplishing similar goals. For
2617 example, requesting only "strong" session key types from the
2618 KDC, and assuming that the type actually returned by the KDC
2619 will be understood and supported by the application server.
2621 Normative References
2624 Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway,
2625 "Relations Among Notions of Security for Public-Key Encryption
2626 Schemes". Extended abstract published in Advances in Cryptology-
2627 Crypto 98 Proceedings, Lecture Notes in Computer Science Vol.
2628 1462, H. Krawcyzk ed., Springer-Verlag, 1998.
2636 INTERNET DRAFT October 2003
2640 Blumenthal, U., and S. Bellovin, "A Better Key Schedule for DES-
2641 Like Ciphers", Proceedings of PRAGOCRYPT '96, 1996.
2643 International Organization for Standardization, "ISO Information
2644 Processing Systems - Data Communication - High-Level Data Link
2645 Control Procedure - Frame Structure," IS 3309, 3rd Edition,
2648 National Bureau of Standards, U.S. Department of Commerce, "Data
2649 Encryption Standard," Federal Information Processing Standards
2650 Publication 46, Washington, DC, 1977.
2652 National Bureau of Standards, U.S. Department of Commerce,
2653 "Guidelines for implementing and using NBS Data Encryption
2654 Standard," Federal Information Processing Standards Publication
2655 74, Washington, DC, 1981.
2657 National Bureau of Standards, U.S. Department of Commerce, "DES
2658 Modes of Operation," Federal Information Processing Standards
2659 Publication 81, Springfield, VA, December 1980.
2661 Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography",
2662 Proceedings of the 23rd Annual Symposium on Theory of Computing,
2665 Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
2666 for Message Authentication", RFC 2104, February 1997.
2668 Raeburn, K., "AES Encyrption for Kerberos 5", RFC XXXX, Xxxxxxxx
2671 Rivest, R., "The MD4 Message Digest Algorithm," RFC 1320, MIT
2672 Laboratory for Computer Science, April 1992.
2674 Rivest, R., "The MD5 Message Digest Algorithm," RFC 1321, MIT
2675 Laboratory for Computer Science, April 1992.
2677 Bradner, S., "The Internet Standards Process -- Revisions 3," RFC
2680 Stubblebine, S., and V. D. Gligor, "On Message Integrity in
2681 Cryptographic Protocols," in Proceedings of the IEEE Symposium on
2682 Research in Security and Privacy, Oakland, California, May 1992.
2692 INTERNET DRAFT October 2003
2695 Informative References
2698 Bellovin, S. M., and M. Merrit, "Limitations of the Kerberos
2699 Authentication System", in Proceedings of the Winter 1991 Usenix
2700 Security Conference, January, 1991.
2702 Bellovin, S. M., and D. Atkins, private communications, 1999.
2704 Electronic Frontier Foundation, "Cracking DES: Secrets of
2705 Encryption Research, Wiretap Politics, and Chip Design", O'Reilly
2706 & Associates, Inc., May 1998.
2708 Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm
2709 With Explicit IV", RFC 2405, November 1998.
2711 Linn, J., "The Kerberos Version 5 GSS-API Mechanism," RFC 1964,
2714 Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",
2715 RFC 2202, September 1997.
2717 Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and
2718 AH", RFC 2404, November 1998.
2720 Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K.
2721 Raeburn, "The Kerberos Network Authentication Service (V5)",
2722 draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22,
2723 2002. Work in progress.
2725 Kohl, J., and C. Neuman, "The Kerberos Network Authentication
2726 Service (V5)", RFC 1510, September 1993.
2728 Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
2729 RC5-CTS Algorithms", RFC 2040, October 1996.
2731 Schneier, B., "Applied Cryptography Second Edition", John Wiley &
2732 Sons, New York, NY, 1996. ISBN 0-471-12845-7.
2737 Massachusetts Institute of Technology
2738 77 Massachusetts Avenue
2748 INTERNET DRAFT October 2003
2751 Full Copyright Statement
2753 Copyright (C) The Internet Society (2003). All Rights Reserved.
2755 This document and translations of it may be copied and furnished to
2756 others, and derivative works that comment on or otherwise explain it
2757 or assist in its implementation may be prepared, copied, published
2758 and distributed, in whole or in part, without restriction of any
2759 kind, provided that the above copyright notice and this paragraph are
2760 included on all such copies and derivative works. However, this
2761 document itself may not be modified in any way, such as by removing
2762 the copyright notice or references to the Internet Society or other
2763 Internet organizations, except as needed for the purpose of
2764 developing Internet standards in which case the procedures for
2765 copyrights defined in the Internet Standards process must be
2766 followed, or as required to translate it into languages other than
2769 The limited permissions granted above are perpetual and will not be
2770 revoked by the Internet Society or its successors or assigns.
2772 This document and the information contained herein is provided on an
2773 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2774 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2775 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2776 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2777 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
2781 Before publication of this document as an RFC, the following changes
2784 Change the reference "[KRB5-AES]" in Normative References to indicate
2785 the AES draft (draft-raeburn-krb-rijndael-krb-XX) that should be
2786 advancing to RFC at the same time. The RFC number and publication
2789 If draft-ietf-krb-wg-kerberos-clarifications advances to RFC at the
2790 same time as this document, change the information for [Kerb] in the
2791 Informative References section as well.
2793 Change the first-page headers to indicate the RFC number, network
2794 working group, etc, as appropriate for an RFC instead of an I-D.
2796 Remove the contact-info paragraph from the Abstract.
2798 Delete this section.
git.samba.org / samba.git / blob