3 Kerberos Working Group L. Zhu
4 Internet-Draft Microsoft Corporation
5 Updates: 4120 (if approved) S. Hartman
6 Intended status: Standards Track MIT
7 Expires: September 6, 2007 March 5, 2007
10 A Generalized Framework for Kerberos Pre-Authentication
11 draft-ietf-krb-wg-preauth-framework-05
15 By submitting this Internet-Draft, each author represents that any
16 applicable patent or other IPR claims of which he or she is aware
17 have been or will be disclosed, and any of which he or she becomes
18 aware will be disclosed, in accordance with Section 6 of BCP 79.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as Internet-
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite 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.txt.
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
36 This Internet-Draft will expire on September 6, 2007.
40 Copyright (C) The IETF Trust (2007).
44 Kerberos is a protocol for verifying the identity of principals
45 (e.g., a workstation user or a network server) on an open network.
46 The Kerberos protocol provides a mechanism called pre-authentication
47 for proving the identity of a principal and for better protecting the
48 long-term secret of the principal.
50 This document describes a model for Kerberos pre-authentication
54 Zhu & Hartman Expires September 6, 2007 [Page 1]
56 Internet-Draft Kerberos Preauth Framework March 2007
59 mechanisms. The model describes what state in the Kerberos request a
60 pre-authentication mechanism is likely to change. It also describes
61 how multiple pre-authentication mechanisms used in the same request
64 This document also provides common tools needed by multiple pre-
65 authentication mechanisms. One of these tools is a secure channel
66 between the client and the KDC with a reply key delivery mechanism;
67 this secure channel can be used to protect the authentication
68 exchange thus eliminate offline dictionary attacks. With these
69 tools, it is straightforward to chain multiple authentication
70 mechanisms, utilize a different key management system, or support a
71 new key agreement algorithm.
110 Zhu & Hartman Expires September 6, 2007 [Page 2]
112 Internet-Draft Kerberos Preauth Framework March 2007
117 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
118 2. Conventions and Terminologies Used in This Document . . . . . 5
119 3. Model for Pre-Authentication . . . . . . . . . . . . . . . . . 5
120 3.1. Information Managed by the Pre-authentication Model . . . 6
121 3.2. Initial Pre-authentication Required Error . . . . . . . . 8
122 3.3. Client to KDC . . . . . . . . . . . . . . . . . . . . . . 9
123 3.4. KDC to Client . . . . . . . . . . . . . . . . . . . . . . 10
124 4. Pre-Authentication Facilities . . . . . . . . . . . . . . . . 10
125 4.1. Client-authentication Facility . . . . . . . . . . . . . . 12
126 4.2. Strengthening-reply-key Facility . . . . . . . . . . . . . 12
127 4.3. Replacing-reply-key Facility . . . . . . . . . . . . . . . 13
128 4.4. KDC-authentication Facility . . . . . . . . . . . . . . . 14
129 5. Requirements for Pre-Authentication Mechanisms . . . . . . . . 14
130 6. Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 15
131 6.1. Combining Keys . . . . . . . . . . . . . . . . . . . . . . 15
132 6.2. Protecting Requests/Responses . . . . . . . . . . . . . . 16
133 6.3. Managing States for the KDC . . . . . . . . . . . . . . . 17
134 6.4. Pre-authentication Set . . . . . . . . . . . . . . . . . . 19
135 6.5. Definition of Kerberos FAST Padata . . . . . . . . . . . . 20
136 6.5.1. FAST and Encrypted Time Stamp . . . . . . . . . . . . 21
137 6.5.2. FAST Armors . . . . . . . . . . . . . . . . . . . . . 21
138 6.5.3. FAST Request . . . . . . . . . . . . . . . . . . . . . 22
139 6.5.4. FAST Response . . . . . . . . . . . . . . . . . . . . 26
140 6.5.5. Error Messages used with Kerberos FAST . . . . . . . . 28
141 6.6. Authentication Strength Indication . . . . . . . . . . . . 28
142 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
143 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
144 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
145 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
146 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30
147 10.2. Informative References . . . . . . . . . . . . . . . . . . 30
148 Appendix A. ASN.1 module . . . . . . . . . . . . . . . . . . . . 30
149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
150 Intellectual Property and Copyright Statements . . . . . . . . . . 34
166 Zhu & Hartman Expires September 6, 2007 [Page 3]
168 Internet-Draft Kerberos Preauth Framework March 2007
173 The core Kerberos specification [RFC4120] treats pre-authentication
174 data as an opaque typed hole in the messages to the KDC that may
175 influence the reply key used to encrypt the KDC reply. This
176 generality has been useful: pre-authentication data is used for a
177 variety of extensions to the protocol, many outside the expectations
178 of the initial designers. However, this generality makes designing
179 more common types of pre-authentication mechanisms difficult. Each
180 mechanism needs to specify how it interacts with other mechanisms.
181 Also, problems like combining a key with the long-term secret or
182 proving the identity of the user are common to multiple mechanisms.
183 Where there are generally well-accepted solutions to these problems,
184 it is desirable to standardize one of these solutions so mechanisms
185 can avoid duplication of work. In other cases, a modular approach to
186 these problems is appropriate. The modular approach will allow new
187 and better solutions to common pre-authentication problems to be used
188 by existing mechanisms as they are developed.
190 This document specifies a framework for Kerberos pre-authentication
191 mechanisms. It defines the common set of functions that pre-
192 authentication mechanisms perform as well as how these functions
193 affect the state of the request and reply. In addition several
194 common tools needed by pre-authentication mechanisms are provided.
195 Unlike [RFC3961], this framework is not complete--it does not
196 describe all the inputs and outputs for the pre-authentication
197 mechanisms. Pre-Authentication mechanism designers should try to be
198 consistent with this framework because doing so will make their
199 mechanisms easier to implement. Kerberos implementations are likely
200 to have plugin architectures for pre-authentication; such
201 architectures are likely to support mechanisms that follow this
202 framework plus commonly used extensions.
204 One of these common tools is the flexible authentication secure
205 tunneling (FAST) padata. FAST provides a protected channel between
206 the client and the KDC, and it also delivers a reply key within the
207 protected channel. Based on FAST, pre-authentication mechanisms can
208 extend Kerberos with ease, to support, for example, password
209 authenticated key exchange (PAKE) protocols with zero knowledge
210 password proof (ZKPP) [EKE] [IEEE1363.2]. Any pre-authentication
211 mechanism can be encapsulated in the FAST messages as defined in
212 Section 6.5. A pre-authentication type carried within FAST is called
213 a FAST factor. Creating a FAST factor is the easiest path to create
214 a new pre-authentication mechanism. FAST factors are significantly
215 easier to analyze from a security standpoint than other pre-
216 authentication mechanisms.
218 Mechanism designers should design FAST factors, instead of new pre-
222 Zhu & Hartman Expires September 6, 2007 [Page 4]
224 Internet-Draft Kerberos Preauth Framework March 2007
227 authentication mechanisms outside of FAST.
229 This document should be read only after reading the documents
230 describing the Kerberos cryptography framework [RFC3961] and the core
231 Kerberos protocol [RFC4120]. This document freely uses terminology
232 and notation from these documents without reference or further
236 2. Conventions and Terminologies Used in This Document
238 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
239 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
240 document are to be interpreted as described in [RFC2119].
242 The word padata is used as the shorthand of pre-authentication data.
244 A conversation is used to refer to all authentication messages
245 exchanged between the client and the KDCs in order to authenticate
246 the client principal. A conversation as defined here consists of all
247 messages that are necessary to complete the authentication between
248 the client and the KDC. It is the smallest logic unit for messages
249 exchanged between the client and the KDC.
252 3. Model for Pre-Authentication
254 When a Kerberos client wishes to obtain a ticket using the
255 authentication server, it sends an initial Authentication Service
256 (AS) request. If pre-authentication is required but not being used,
257 then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
258 Alternatively, if the client knows what pre-authentication to use, it
259 MAY optimize away a round-trip and send an initial request with
260 padata included in the initial request. If the client includes the
261 wrong padata, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
262 indication of what padata should have been included. In that case,
263 the client MUST retry with no padata and examine the error data of
264 the KDC_ERR_PREAUTH_REQUIRED error. If the KDC includes pre-
265 authentication information in the accompanying error data of
266 KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
269 The conventional KDC maintains no state between two requests;
270 subsequent requests may even be processed by a different KDC. On the
271 other hand, the client treats a series of exchanges with KDCs as a
272 single conversation. Each exchange accumulates state and hopefully
273 brings the client closer to a successful authentication.
278 Zhu & Hartman Expires September 6, 2007 [Page 5]
280 Internet-Draft Kerberos Preauth Framework March 2007
283 These models for state management are in apparent conflict. For many
284 of the simpler pre-authentication scenarios, the client uses one
285 round trip to find out what mechanisms the KDC supports. Then the
286 next request contains sufficient pre-authentication for the KDC to be
287 able to return a successful reply. For these simple scenarios, the
288 client only sends one request with pre-authentication data and so the
289 conversation is trivial. For more complex conversations, the KDC
290 needs to provide the client with a cookie to include in future
291 requests to capture the current state of the authentication session.
292 Handling of multiple round-trip mechanisms is discussed in
295 This framework specifies the behavior of Kerberos pre-authentication
296 mechanisms used to identify users or to modify the reply key used to
297 encrypt the KDC reply. The PA-DATA typed hole may be used to carry
298 extensions to Kerberos that have nothing to do with proving the
299 identity of the user or establishing a reply key. Such extensions
300 are outside the scope of this framework. However mechanisms that do
301 accomplish these goals should follow this framework.
303 This framework specifies the minimum state that a Kerberos
304 implementation needs to maintain while handling a request in order to
305 process pre-authentication. It also specifies how Kerberos
306 implementations process the padata at each step of the AS request
309 3.1. Information Managed by the Pre-authentication Model
311 The following information is maintained by the client and KDC as each
312 request is being processed:
314 o The reply key used to encrypt the KDC reply
316 o How strongly the identity of the client has been authenticated
318 o Whether the reply key has been used in this conversation
320 o Whether the reply key has been replaced in this conversation
322 o Whether the contents of the KDC reply can be verified by the
326 Conceptually, the reply key is initially the long-term key of the
327 principal. However, principals can have multiple long-term keys
328 because of support for multiple encryption types, salts and
329 string2key parameters. As described in Section 5.2.7.5 of the
330 Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
334 Zhu & Hartman Expires September 6, 2007 [Page 6]
336 Internet-Draft Kerberos Preauth Framework March 2007
339 the client what types of keys are available. Thus in full
340 generality, the reply key in the pre-authentication model is actually
341 a set of keys. At the beginning of a request, it is initialized to
342 the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
343 the KDC. If multiple reply keys are available, the client chooses
344 which one to use. Thus the client does not need to treat the reply
345 key as a set. At the beginning of a request, the client picks a
348 KDC implementations MAY choose to offer only one key in the PA-ETYPE-
349 INFO2 element. Since the KDC already knows the client's list of
350 supported enctypes from the request, no interoperability problems are
351 created by choosing a single possible reply key. This way, the KDC
352 implementation avoids the complexity of treating the reply key as a
355 When the padata in the request is verified by the KDC, then the
356 client is known to have that key, therefore the KDC SHOULD pick the
357 same key as the reply key.
359 At the beginning of handling a message on both the client and the
360 KDC, the client's identity is not authenticated. A mechanism may
361 indicate that it has successfully authenticated the client's
362 identity. This information is useful to keep track of on the client
363 in order to know what pre-authentication mechanisms should be used.
364 The KDC needs to keep track of whether the client is authenticated
365 because the primary purpose of pre-authentication is to authenticate
366 the client identity before issuing a ticket. The handling of
367 authentication strength using various authentication mechanisms is
368 discussed in Section 6.6.
370 Initially the reply key has not been used. A pre-authentication
371 mechanism that uses the reply key to encrypt or checksum some data in
372 the generation of new keys MUST indicate that the reply key is used.
373 This state is maintained by the client and the KDC to enforce the
374 security requirement stated in Section 4.3 that the reply key cannot
375 be replaced after it is used.
377 Initially the reply key has not been replaced. If a mechanism
378 implements the Replace Reply Key facility discussed in Section 4.3,
379 then the state MUST be updated to indicate that the reply key has
380 been replaced. Once the reply key has been replaced, knowledge of
381 the reply key is insufficient to authenticate the client. The reply
382 key is marked replaced in exactly the same situations as the KDC
383 reply is marked as not being verified to the client principal.
384 However, while mechanisms can verify the KDC reply to the client,
385 once the reply key is replaced, then the reply key remains replaced
386 for the remainder of the conversation.
390 Zhu & Hartman Expires September 6, 2007 [Page 7]
392 Internet-Draft Kerberos Preauth Framework March 2007
395 Without pre-authentication, the client knows that the KDC reply is
396 authentic and has not been modified because it is encrypted in a
397 long-term key of the client. Only the KDC and the client know that
398 key. So at the start of handling any message the KDC reply is
399 presumed to be verified using the client principal's long-term key.
400 Any pre-authentication mechanism that sets a new reply key not based
401 on the principal's long-term secret MUST either verify the KDC reply
402 some other way or indicate that the reply is not verified. If a
403 mechanism indicates that the reply is not verified then the client
404 implementation MUST return an error unless a subsequent mechanism
405 verifies the reply. The KDC needs to track this state so it can
406 avoid generating a reply that is not verified.
408 The typical Kerberos request does not provide a way for the client
409 machine to know that it is talking to the correct KDC. Someone who
410 can inject packets into the network between the client machine and
411 the KDC and who knows the password that the user will give to the
412 client machine can generate a KDC reply that will decrypt properly.
413 So, if the client machine needs to authenticate that the user is in
414 fact the named principal, then the client machine needs to do a TGS
415 request for itself as a service. Some pre-authentication mechanisms
416 may provide a way for the client to authenticate the KDC. Examples
417 of this include signing the reply that can be verified using a well-
418 known public key or providing a ticket for the client machine as a
421 3.2. Initial Pre-authentication Required Error
423 Typically a client starts a conversation by sending an initial
424 request with no pre-authentication. If the KDC requires pre-
425 authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
426 After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
427 the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
428 (defined in Section 6.3) for pre-authentication configurations that
429 use multi-round-trip mechanisms; see Section 3.4 for details of that
430 case. [[anchor3: Is it desirable to define a new error code for this?
431 Probably but we need to call out to the WG.]]
433 The KDC needs to choose which mechanisms to offer the client. The
434 client needs to be able to choose what mechanisms to use from the
435 first message. For example consider the KDC that will accept
436 mechanism A followed by mechanism B or alternatively the single
437 mechanism C. A client that supports A and C needs to know that it
438 should not bother trying A.
440 Mechanisms can either be sufficient on their own or can be part of an
441 authentication set--a group of mechanisms that all need to
442 successfully complete in order to authenticate a client. Some
446 Zhu & Hartman Expires September 6, 2007 [Page 8]
448 Internet-Draft Kerberos Preauth Framework March 2007
451 mechanisms may only be useful in authentication sets; others may be
452 useful alone or in authentication sets. For the second group of
453 mechanisms, KDC policy dictates whether the mechanism will be part of
454 an authentication set or offered alone. For each mechanism that is
455 offered alone, the KDC includes the pre-authentication type ID of the
456 mechanism in the padata sequence returned in the
457 KDC_ERR_PREAUTH_REQUIRED error.
459 The KDC SHOULD NOT send data that is encrypted in the long-term
460 password-based key of the principal. Doing so has the same security
461 exposures as the Kerberos protocol without pre-authentication. There
462 are few situations where pre-authentication is desirable and where
463 the KDC needs to expose cipher text encrypted in a weak key before
464 the client has proven knowledge of that key.
468 This description assumes that a client has already received a
469 KDC_ERR_PREAUTH_REQUIRED from the KDC. If the client performs
470 optimistic pre-authentication then the client needs to optimistically
471 choose the information it would normally receive from that error
474 The client starts by initializing the pre-authentication state as
475 specified. It then processes the padata in the
476 KDC_ERR_PREAUTH_REQUIRED.
478 When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
479 client MAY ignore any padata it chooses unless doing so violates a
480 specification to which the client conforms. Clients conforming to
481 this specification MUST NOT ignore the padata defined in Section 6.3.
482 Clients SHOULD process padata unrelated to this framework or other
483 means of authenticating the user. Clients SHOULD choose one
484 authentication set or mechanism that could lead to authenticating the
485 user and ignore the rest. Since the list of mechanisms offered by
486 the KDC is in the decreasing preference order, clients typically
487 choose the first mechanism or authentication set that the client can
488 usefully perform. If a client chooses to ignore a padata it MUST NOT
489 process the padata, allow the padata to affect the pre-authentication
490 state, nor respond to the padata.
492 For each padata the client chooses to process, the client processes
493 the padata and modifies the pre-authentication state as required by
494 that mechanism. Padata are processed in the order received from the
497 After processing the padata in the KDC error, the client generates a
498 new request. It processes the pre-authentication mechanisms in the
502 Zhu & Hartman Expires September 6, 2007 [Page 9]
504 Internet-Draft Kerberos Preauth Framework March 2007
507 order in which they will appear in the next request, updating the
508 state as appropriate. The request is sent when it is complete.
512 When a KDC receives an AS request from a client, it needs to
513 determine whether it will respond with an error or an AS reply.
514 There are many causes for an error to be generated that have nothing
515 to do with pre-authentication; they are discussed in the core
516 Kerberos specification.
518 From the standpoint of evaluating the pre-authentication, the KDC
519 first starts by initializing the pre-authentication state. It then
520 processes the padata in the request. As mentioned in Section 3.3,
521 the KDC MAY ignore padata that is inappropriate for the configuration
522 and MUST ignore padata of an unknown type.
524 At this point the KDC decides whether it will issue a pre-
525 authentication required error or a reply. Typically a KDC will issue
526 a reply if the client's identity has been authenticated to a
529 In the case of a KDC_ERR_MORE_PREAUTH_DATA_NEEDED error, the KDC
530 first starts by initializing the pre-authentication state. Then it
531 processes any padata in the client's request in the order provided by
532 the client. Mechanisms that are not understood by the KDC are
533 ignored. Mechanisms that are inappropriate for the client principal
534 or the request SHOULD also be ignored. Next, it generates padata for
535 the error response, modifying the pre-authentication state
536 appropriately as each mechanism is processed. The KDC chooses the
537 order in which it will generate padata (and thus the order of padata
538 in the response), but it needs to modify the pre-authentication state
539 consistently with the choice of order. For example, if some
540 mechanism establishes an authenticated client identity, then the
541 subsequent mechanisms in the generated response receive this state as
542 input. After the padata is generated, the error response is sent.
543 Typically the errors with the code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
544 in a converstation will include KDC state as discussed in
547 To generate a final reply, the KDC generates the padata modifying the
548 pre-authentication state as necessary. Then it generates the final
549 response, encrypting it in the current pre-authentication reply key.
552 4. Pre-Authentication Facilities
554 Pre-Authentication mechanisms can be thought of as providing various
558 Zhu & Hartman Expires September 6, 2007 [Page 10]
560 Internet-Draft Kerberos Preauth Framework March 2007
563 conceptual facilities. This serves two useful purposes. First,
564 mechanism authors can choose only to solve one specific small
565 problem. It is often useful for a mechanism designed to offer key
566 management not to directly provide client authentication but instead
567 to allow one or more other mechanisms to handle this need. Secondly,
568 thinking about the abstract services that a mechanism provides yields
569 a minimum set of security requirements that all mechanisms providing
570 that facility must meet. These security requirements are not
571 complete; mechanisms will have additional security requirements based
572 on the specific protocol they employ.
574 A mechanism is not constrained to only offering one of these
575 facilities. While such mechanisms can be designed and are sometimes
576 useful, many pre-authentication mechanisms implement several
577 facilities. By combining multiple facilities in a single mechanism,
578 it is often easier to construct a secure, simple solution than by
579 solving the problem in full generality. Even when mechanisms provide
580 multiple facilities, they need to meet the security requirements for
581 all the facilities they provide. If the FAST factor approach is
582 used, it is likely that one or a small number of facilities can be
583 provided by a single mechanism without complicating the security
586 According to Kerberos extensibility rules (Section 1.5 of the
587 Kerberos specification [RFC4120]), an extension MUST NOT change the
588 semantics of a message unless a recipient is known to understand that
589 extension. Because a client does not know that the KDC supports a
590 particular pre-authentication mechanism when it sends an initial
591 request, a pre-authentication mechanism MUST NOT change the semantics
592 of the request in a way that will break a KDC that does not
593 understand that mechanism. Similarly, KDCs MUST NOT send messages to
594 clients that affect the core semantics unless the client has
595 indicated support for the message.
597 The only state in this model that would break the interpretation of a
598 message is changing the expected reply key. If one mechanism changed
599 the reply key and a later mechanism used that reply key, then a KDC
600 that interpreted the second mechanism but not the first would fail to
601 interpret the request correctly. In order to avoid this problem,
602 extensions that change core semantics are typically divided into two
603 parts. The first part proposes a change to the core semantic--for
604 example proposes a new reply key. The second part acknowledges that
605 the extension is understood and that the change takes effect.
606 Section 4.2 discusses how to design mechanisms that modify the reply
607 key to be split into a proposal and acceptance without requiring
608 additional round trips to use the new reply key in subsequent pre-
609 authentication. Other changes in the state described in Section 3.1
610 can safely be ignored by a KDC that does not understand a mechanism.
614 Zhu & Hartman Expires September 6, 2007 [Page 11]
616 Internet-Draft Kerberos Preauth Framework March 2007
619 Mechanisms that modify the behavior of the request outside the scope
620 of this framework need to carefully consider the Kerberos
621 extensibility rules to avoid similar problems.
623 4.1. Client-authentication Facility
625 The client authentication facility proves the identity of a user to
626 the KDC before a ticket is issued. Examples of mechanisms
627 implementing this facility include the encrypted timestamp facility
628 defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
629 Mechanisms that provide this facility are expected to mark the client
632 Mechanisms implementing this facility SHOULD require the client to
633 prove knowledge of the reply key before transmitting a successful KDC
634 reply. Otherwise, an attacker can intercept the pre-authentication
635 exchange and get a reply to attack. One way of proving the client
636 knows the reply key is to implement the Replace Reply Key facility
637 along with this facility. The PKINIT mechanism [RFC4556] implements
638 Client Authentication alongside Replace Reply Key.
640 If the reply key has been replaced, then mechanisms such as
641 encrypted-timestamp that rely on knowledge of the reply key to
642 authenticate the client MUST NOT be used.
644 4.2. Strengthening-reply-key Facility
646 Particularly, when dealing with keys based on passwords, it is
647 desirable to increase the strength of the key by adding additional
648 secrets to it. Examples of sources of additional secrets include the
649 results of a Diffie-Hellman key exchange or key bits from the output
650 of a smart card [KRB-WG.SAM]. Typically these additional secrets can
651 be first combined with the existing reply key and then converted to a
652 protocol key using tools defined in Section 6.1.
654 If a mechanism implementing this facility wishes to modify the reply
655 key before knowing that the other party in the exchange supports the
656 mechanism, it proposes modifying the reply key. The other party then
657 includes a message indicating that the proposal is accepted if it is
658 understood and meets policy. In many cases it is desirable to use
659 the new reply key for client authentication and for other facilities.
660 Waiting for the other party to accept the proposal and actually
661 modify the reply key state would add an additional round trip to the
662 exchange. Instead, mechanism designers are encouraged to include a
663 typed hole for additional padata in the message that proposes the
664 reply key change. The padata included in the typed hole are
665 generated assuming the new reply key. If the other party accepts the
666 proposal, then these padata are considered as an inner level. As
670 Zhu & Hartman Expires September 6, 2007 [Page 12]
672 Internet-Draft Kerberos Preauth Framework March 2007
675 with the outer level, one authentication set or mechanism is
676 typically chosen for client authentication, along with auxiliary
677 mechanisms such as KDC cookies, and other mechanisms are ignored.
678 [[anchor6: Containers like this need more thought. For example if
679 you are constructing an authentication set do you expect to use a
680 strengthen reply key mechanism in conjunction with something else, do
681 you include the something else in the hint of the strengthen
682 mechanism or as its own entry. It's easier to configure and express
683 the authentication set as its own entry. However if you do that' the
684 composition of the mechanisms looks in practice than it appears in
685 the authentication set.]] The party generating the proposal can
686 determine whether the padata were processed based on whether the
687 proposal for the reply key is accepted.
689 The specific formats of the proposal message, including where padata
690 are included is a matter for the mechanism specification. Similarly,
691 the format of the message accepting the proposal is mechanism-
694 Mechanisms implementing this facility and including a typed hole for
695 additional padata MUST checksum that padata using a keyed checksum or
696 encrypt the padata. [[anchor7: Why? I suspect there's an obvious
697 attack here but I need to work through it and add detail. In
698 particular, it seems that a checksum at the end should be
699 sufficient.]]Typically the reply key is used to protect the padata.
700 If you are only minimally increasing the strength of the reply key,
701 this may give the attacker access to something too close to the
702 original reply key. However, binding the padata to the new reply key
703 seems potentially important from a security standpoint. There may
704 also be objections to this from a double encryption standpoint
705 because we also recommend client authentication facilities be tied to
708 4.3. Replacing-reply-key Facility
710 The Replace Reply Key facility replaces the key in which a successful
711 AS reply will be encrypted. This facility can only be used in cases
712 where knowledge of the reply key is not used to authenticate the
713 client. The new reply key MUST be communicated to the client and the
714 KDC in a secure manner. Mechanisms implementing this facility MUST
715 mark the reply key as replaced in the pre-authentication state.
716 Mechanisms implementing this facility MUST either provide a mechanism
717 to verify the KDC reply to the client or mark the reply as unverified
718 in the pre-authentication state. Mechanisms implementing this
719 facility SHOULD NOT be used if a previous mechanism has used the
722 As with the strengthening-reply-key facility, Kerberos extensibility
726 Zhu & Hartman Expires September 6, 2007 [Page 13]
728 Internet-Draft Kerberos Preauth Framework March 2007
731 rules require that the reply key not be changed unless both sides of
732 the exchange understand the extension. In the case of this facility
733 it will likely be more common for both sides to know that the
734 facility is available by the time that the new key is available to be
735 used. However, mechanism designers can use a container for padata in
736 a proposal message as discussed in Section 4.2 if appropriate.
738 4.4. KDC-authentication Facility
740 This facility verifies that the reply comes from the expected KDC.
741 In traditional Kerberos, the KDC and the client share a key, so if
742 the KDC reply can be decrypted then the client knows that a trusted
743 KDC responded. Note that the client machine cannot trust the client
744 unless the machine is presented with a service ticket for it
745 (typically the machine can retrieve this ticket by itself). However,
746 if the reply key is replaced, some mechanism is required to verify
747 the KDC. Pre-authentication mechanisms providing this facility allow
748 a client to determine that the expected KDC has responded even after
749 the reply key is replaced. They mark the pre-authentication state as
750 having been verified.
753 5. Requirements for Pre-Authentication Mechanisms
755 This section lists requirements for specifications of pre-
756 authentication mechanisms.
758 For each message in the pre-authentication mechanism, the
759 specification describes the pa-type value to be used and the contents
760 of the message. The processing of the message by the sender and
761 recipient is also specified. This specification needs to include all
762 modifications to the pre-authentication state.
764 Generally mechanisms have a message that can be sent in the error
765 data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
766 authentication set. If the client needs information such as trusted
767 certificate authorities in order to determine if it can use the
768 mechanism, then this information should be in that message. In
769 addition, such mechanisms should also define a pa-hint to be included
770 in authentication sets. Often, the same information included in the
771 padata-value is appropriate to include in the pa-hint (as defined in
774 In order to ease security analysis the mechanism specification should
775 describe what facilities from this document are offered by the
776 mechanism. For each facility, the security consideration section of
777 the mechanism specification should show that the security
778 requirements of that facility are met. This requirement is
782 Zhu & Hartman Expires September 6, 2007 [Page 14]
784 Internet-Draft Kerberos Preauth Framework March 2007
787 applicable to any FAST factor that provides authentication
790 Significant problems have resulted in the specification of Kerberos
791 protocols because much of the KDC exchange is not protected against
792 authentication. The security considerations section should discuss
793 unauthenticated plaintext attacks. It should either show that
794 plaintext is protected or discuss what harm an attacker could do by
795 modifying the plaintext. It is generally acceptable for an attacker
796 to be able to cause the protocol negotiation to fail by modifying
797 plaintext. More significant attacks should be evaluated carefully.
799 As discussed in Section 6.3, there is no guarantee that a client will
800 use the same KDCs for all messages in a conversation. The mechanism
801 specification needs to show why the mechanism is secure in this
802 situation. The hardest problem to deal with, especially for
803 challenge/response mechanisms is to make sure that the same response
804 cannot be replayed against two KDCs while allowing the client to talk
808 6. Tools for Use in Pre-Authentication Mechanisms
810 This section describes common tools needed by multiple pre-
811 authentication mechanisms. By using these tools mechanism designers
812 can use a modular approach to specify mechanism details and ease
817 Frequently a weak key need to be combined with a stronger key before
818 use. For example, passwords are typically limited in size and
819 insufficiently random, therefore it is desirable to increase the
820 strength of the keys based on passwords by adding additional secrets.
821 Additional source of secrecy may come from hardware tokens.
823 This section provides standard ways to combine two keys into one.
825 KRB-FX-CF1() is defined to combine two pass-phrases.
827 KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
828 KRB-FX-CF1(x, y) -> x || y
830 Where || denotes concatenation. The strength of the final key is
831 roughly the total strength of the individual keys being combined
832 assuming that the string_to_key() function [RFC3961] uses all its
838 Zhu & Hartman Expires September 6, 2007 [Page 15]
840 Internet-Draft Kerberos Preauth Framework March 2007
843 An example usage of KRB-FX-CF1() is when a device provides random but
844 short passwords, the password is often combined with a personal
845 identification number (PIN). The password and the PIN can be
846 combined using KRB-FX-CF1().
848 KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
849 function defined in [RFC3961].
851 Given two input keys, K1 and K2, where K1 and K2 can be of two
852 different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
855 KRB-FX-CF2(protocol key, protocol key, octet string,
856 octet string) -> (protocol key)
858 PRF+(K1, pepper1) -> octet-string-1
859 PRF+(K2, pepper2) -> octet-string-2
860 KRB-FX-CF2(K1, K2, pepper1, pepper2) ->
861 random-to-key(octet-string-1 ^ octet-string-2)
863 Where ^ denotes the exclusive-OR operation. PRF+() is defined as
866 PRF+(protocol key, octet string) -> (octet string)
868 PRF+(key, shared-info) -> pseudo-random( key, 1 || shared-info ) ||
869 pseudo-random( key, 2 || shared-info ) ||
870 pseudo-random( key, 3 || shared-info ) || ...
872 Here the counter value 1, 2, 3 and so on are encoded as a one-octet
873 integer. The pseudo-random() operation is specified by the enctype
874 of the protocol key. PRF+() uses the counter to generate enough bits
875 as needed by the random-to-key() [RFC3961] function for the
876 encryption type specified for the resulting key; unneeded bits are
877 removed from the tail.
879 Mechanism designers MUST specify the pepper values when combining two
880 keys using KRB-FX-CF2(). The pepper1 and pepper2 MUST be distinct so
881 that if the two keys being combined are the same, the resulting key
882 is not a trivial key.
884 6.2. Protecting Requests/Responses
886 Mechanism designers SHOULD protect clear text portions of pre-
887 authentication data. Various denial of service attacks and downgrade
888 attacks against Kerberos are possible unless plaintexts are somehow
889 protected against modification. An early design goal of Kerberos
890 Version 5 [RFC4120] was to avoid encrypting more of the
894 Zhu & Hartman Expires September 6, 2007 [Page 16]
896 Internet-Draft Kerberos Preauth Framework March 2007
899 authentication exchange that was required. (Version 4 doubly-
900 encrypted the encrypted part of a ticket in a KDC reply, for
901 example.) This minimization of encryption reduces the load on the
902 KDC and busy servers. Also, during the initial design of Version 5,
903 the existence of legal restrictions on the export of cryptography
904 made it desirable to minimize of the number of uses of encryption in
905 the protocol. Unfortunately, performing this minimization created
906 numerous instances of unauthenticated security-relevant plaintext
909 If there are more than one roundtrip for an authentication exchange,
910 mechanism designers need to allow either the client or the KDC to
911 provide a checksum of all the messages exchanged on the wire in the
912 conversation, and the checksum is then verified by the receiver.
914 Primitives defined in [RFC3961] are RECOMMENDED for integrity
915 protection and confidentiality. Mechanisms based on these primitives
916 have the benefit of crypto-agility provided by [RFC3961].
918 The advantage afforded by crypto-agility is the ability to avoid a
919 multi-year standardization and deployment cycle to fix a problem that
920 is specific to a particular algorithm, when real attacks do arise
921 against that algorithm.
923 New mechanisms MUST NOT be hard-wired to use a specific algorithm.
925 Note that data used by FAST factors (defined in Section 6.5) are
926 encrypted in a protected channel, in most cases, therefore no un-
927 authenticated-text issue is associated with these mechanisms.
928 However mechanism designers MUST consider the case carefully when the
929 KDC authentication is not provided by Kerberos FAST.
931 6.3. Managing States for the KDC
933 [[anchor11: Kerberos is stateless today. We can either maintain that
934 and store all the state in a cookie or change that and require
935 clients go to the same KDC for future requests. Consider how this
936 interacts with proxies. The rest of this section assumes we maintain
937 the current model.]] Kerberos KDCs are stateless. There is no
938 requirement that clients will choose the same KDC for the second
939 request in a conversation. Proxies or other intermediate nodes may
940 also influence KDC selection. So, each request from a client to a
941 KDC must include sufficient information that the KDC can regenerate
942 any needed state. This is accomplished by giving the client a
943 potentially long opaque cookie in responses to include in future
944 requests in the same conversation. The KDC MAY respond that a
945 conversation is too old and needs to restart by responding with a
946 KDC_ERR_PREAUTH_EXPIRED error.
950 Zhu & Hartman Expires September 6, 2007 [Page 17]
952 Internet-Draft Kerberos Preauth Framework March 2007
955 KDC_ERR_PREAUTH_EXPIRED TBA
957 When a client receives this error, the client MUST abort the existing
958 conversation, and restart a new one.
960 An example, where more than one message from the client is needed, is
961 when the client is authenticated based on a challenge-response
962 scheme. In that case, the KDC needs to keep track of the challenge
963 issued for a client authentication request.
965 The PA-FX-COOKIE pdata type is defined in this section to facilitate
966 state management. This padata is sent by the KDC when the KDC
967 requires state for a future transaction. The client includes this
968 opaque token in the next message in the conversation. The token may
969 be relatively large; clients MUST be prepared for tokens somewhat
970 larger than the size of all messages in a conversation.
973 -- Stateless cookie that is not tied to a specific KDC.
975 The corresponding padata-value field [RFC4120] contains the
976 Distinguished Encoding Rules (DER) [X60] [X690] encoding of the
977 following Abstract Syntax Notation One (ASN.1) type PA-FX-COOKIE:
979 PA-FX-COOKIE ::= SEQUENCE {
980 Cookie [1] OCTET STRING,
981 -- Opaque data, for use to associate all the messages in a
982 -- single conversation between the client and the KDC.
983 -- This can be generated by either the client or the KDC.
984 -- The receiver MUST copy the exact Cookie encapsulated in
985 -- a PA_FX_COOKIE data element into the next message of the
986 -- same conversation.
990 The content of the PA_FX_COOKIE padata is a local matter of the KDC.
991 However the KDC MUST construct the token in such a manner that a
992 malicious client cannot subvert the authentication process by
993 manipulating the token. The KDC implementation needs to consider
994 expiration of tokens, key rollover and other security issues in token
995 design. The content of the Cookie field is likely specific to the
996 pre-authentication mechanisms used to authenticate the client. In
997 order to compute the finished field in the KrbFastRespons structure
998 as defined in Section 6.5.4, all the previous messages in the
999 conversation MUST be included in the Cookie. If a client
1000 authentication response can be replayed to multiple KDCs via the
1001 PA_FX_COOKIE mechanism, an expiration in the Cookie is RECOMMENDED to
1002 prevent the response being presented indefinitely.
1006 Zhu & Hartman Expires September 6, 2007 [Page 18]
1008 Internet-Draft Kerberos Preauth Framework March 2007
1011 If at least one more message for a mechanism or a mechanism set is
1012 expected by the KDC, the KDC returns a
1013 KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA_FX_COOKIE to
1014 identify the conversation with the client.
1016 KDC_ERR_MORE_PREAUTH_DATA_NEEDED TBA
1018 6.4. Pre-authentication Set
1020 If all mechanisms in a group need to successfully complete in order
1021 to authenticate a client, the client and the KDC SHOULD use the
1022 PA_AUTHENTICATION_SET padata element.
1024 A PA_AUTHENTICATION_SET padata element contains the ASN.1 DER
1025 encoding of the PA-AUTHENTICATION-SET structure:
1027 PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
1029 PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
1031 -- same as padata-type.
1032 pa-hint [2] OCTET STRING,
1037 The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
1038 contains the corresponding value of padata-type in PA-DATA [RFC4120].
1039 Associated with the pa-type is a pa-hint, which is an octet-string
1040 specified by the pre-authentication mechanism. This hint may provide
1041 information for the client which helps it determine whether the
1042 mechanism can be used. For example a public-key mechanism might
1043 include the certificate authorities it trusts in the hint info. Most
1044 mechanisms today do not specify hint info; if a mechanism does not
1045 specify hint info the KDC MUST NOT send a hint for that mechanism.
1046 To allow future revisions of mechanism specifications to add hint
1047 info, clients MUST ignore hint info received for mechanisms that the
1048 client believes do not support hint info. [[anchor12: What if you
1049 have a padata type as the first member of a set that requires a
1050 challenge. For example SAM assumes that the KDC sends a challenge to
1051 the client initially. That's not a pa-hint; that's a pa-value. How
1052 do you convey that data with this?]] [[anchor13: The PA-SET appears
1053 only in the first message from the KDC to the client? In particular,
1054 the client should not be prepared for the future authentication
1055 mechanisms to change as the conversation progresses. I think this is
1056 correct; we should discuss and if the WG agrees the text should
1062 Zhu & Hartman Expires September 6, 2007 [Page 19]
1064 Internet-Draft Kerberos Preauth Framework March 2007
1067 When indicating which sets of padata are supported, the KDC includes
1068 a PA-AUTHENTICATION-SET padata element for each authentication set.
1070 The client sends the padata-value for the first mechanism it picks in
1071 the authentication set, when the first mechanism completes, the
1072 client and the KDC will proceed with the second mechanism, and so on
1073 until all mechanisms complete successfully. The PA_FX_COOKIE as
1074 defined in Section 6.3 MUST be sent by the KDC along with the first
1075 message that contains a PA-AUTHENTICATION-SET, in order to keep track
1078 [[anchor14: It's much easier to design UIs if you can determine ahead
1079 of time what all the elements of your dialogue will need to be. If
1080 we mandate that the pa-hints need to be sufficient that you can
1081 determine what information you will require from a user ahead of time
1082 we can simplify the UI for login. I propose that we make this
1083 requirement. WG agreement required.]]
1085 6.5. Definition of Kerberos FAST Padata
1087 The cipher text exposure when using the encrypted timestamp pre-
1088 authentication data is a security concern for Kerberos. Attackers
1089 can launch offline dictionary attack using the cipher text. The FAST
1090 pre-authentication padata is a tool to mitigate this threat. FAST
1091 also provides solutions to common problems for pre-authentication
1092 mechanisms such as binding of the request and the reply, freshness
1093 guarantee of the authentication. FAST itself, however, does not
1094 authenticate the client or the KDC, instead, it provides a typed hole
1095 to allow pre-authentication data be tunneled. A pre-authentication
1096 data element used within FAST is called a FAST factor. A FAST factor
1097 captures the minimal work required for extending Kerberos to support
1098 a new authentication scheme.
1100 A FAST factor MUST NOT be used outside of FAST unless its
1101 specification explicitly allows so. The typed holes in FAST messages
1102 can also be used as generic holes for other padata that are not
1103 intended to prove the client's identity, or establish the reply key.
1105 New pre-authentication mechanisms SHOULD be designed as FAST factors,
1106 instead of full-blown pre-authentication mechanisms.
1108 FAST factors that are pre-authentication mechanisms MUST meet the
1109 requirements in Section 5.
1111 FAST employs an armoring scheme. The armor can be a host Ticket
1112 Granting Ticket (TGT), or an anonymous TGT obtained based on
1113 anonymous PKINIT [KRB-ANON], or a pre-shared long term key such as a
1114 host key. The armoring TGT can be a cross-realm TGT. The rest of
1118 Zhu & Hartman Expires September 6, 2007 [Page 20]
1120 Internet-Draft Kerberos Preauth Framework March 2007
1123 this section describes the types of armors and the messages used by
1126 6.5.1. FAST and Encrypted Time Stamp
1128 FAST provides new behavior for encrypted time stamp [RFC4120]. When
1129 used as a FAST factor, this mechanism provides stronger security
1132 Implementations of the pre-authentication framework SHOULD use
1133 encrypted timestamp pre-authentication, if that is the mechanism to
1134 authenticate the client, as a FAST factor to avoid security exposure.
1136 The encrypted timestamp FAST factor MUST fill out the encrypted rep-
1137 key-package field as described in Section 6.5.4. It provides the
1138 following facilities: client-authentication, replacing-reply-key,
1139 KDC-authentication. It does not provide the strengthening-reply-key
1140 facility. The security considerations section of this document
1141 provides an explanation why the security requirements are met.
1145 An armor key is used to encrypt pre-authentication data in the FAST
1146 request and the response. The ArmorData structure is used to
1147 identify the armor key. It contains the following two fields: the
1148 armor-type identifies the type of armor data, and the armor-value as
1149 an OCTET STRING contains the data.
1151 KrbFastArmor ::= SEQUENCE {
1152 armor-type [1] Int32,
1153 -- Type of the armor.
1154 armor-value [2] OCTET STRING,
1155 -- Value of the armor.
1159 The value of the armor key is a matter of the armor type
1160 specification. The following armor types are currently defined :
1163 FX_FAST_ARMOR_AP_REQUEST 1
1164 FX_FAST_ARMOR_KEY_ID 2
1166 Conforming implementations MUST implement the
1167 FX_FAST_ARMOR_AP_REQUEST armor type.
1174 Zhu & Hartman Expires September 6, 2007 [Page 21]
1176 Internet-Draft Kerberos Preauth Framework March 2007
1179 6.5.2.1. Ticket-based Armors
1181 The FX_FAST_ARMOR_AP_REQUEST armor type is based on a Kerberos TGT.
1182 The armor-value field of an FX_FAST_ARMOR_AP_REQUEST armor contains
1183 an AP-REQ encoded in DER. The subkey field in the AP-REQ MUST be
1184 present. The armor key is the subkey in the AP-REQ authenticator.
1186 The ticket in the AP-REQ MUST be for the TGT service of the target
1187 KDC. Here are 3 ways in the decreasing preference order how an armor
1188 TGT SHOULD be obtained:
1190 1. If the client is authenticating from a host machine whose
1191 Kerberos realm has a trust path to the client's realm, the host
1192 machine obtains a TGT to the client's realm, and this ticket is
1195 2. Otherwise, the client's host machine cannot obtain a host ticket
1196 strictly based on RFC4120, but the KDC has a signing asymmetric
1197 key that the client can verify its binding with the expected KDC,
1198 the client then can use anonymous PKINIT to obtain a anonymous
1199 TGT, and use that TGT to as the armor ticket.
1201 3. Otherwise, the client uses anonymous PKINIT to get an anonymous
1202 TGT without KDC authentication. Note that this mode of operation
1203 is vulnerable to man-in-the-middle attacks at the time of
1204 obtaining the initial anonymous TGT.
1206 Because the KDC does not know if the client is able to trust the
1207 ticket it has, the KDC and client MUST initialize the pre-
1208 authentication state to an unverified KDC.
1210 6.5.2.2. Key-based Armors
1212 The FX_FAST_ARMOR_KEY_ID armor type is used to carry an identifier of
1213 a key that is shared between the client host and the KDC. The
1214 content and the encoding of the armor-data field of this armor type
1215 is a local matter of the communicating client and the expected KDC.
1216 The FX_FAST_ARMOR_KEY_ID armor is useful when the client host and the
1217 KDC does have a shared key and it is beneficial to minimize the
1218 number of messages exchanged between the client and the KDC, namely
1219 by eliminating the messages for obtaining a host ticket based on the
1220 host key. [[anchor19: Do we believe this has sufficient value to
1221 specify or do we want to assume all armor comes from tickets?]]
1225 A padata type PA_FX_FAST is defined for the Kerberos FAST pre-
1226 authentication padata. The corresponding padata-value field
1230 Zhu & Hartman Expires September 6, 2007 [Page 22]
1232 Internet-Draft Kerberos Preauth Framework March 2007
1235 [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
1239 -- Padata type for Kerberos FAST
1241 PA-FX-FAST-REQUEST ::= CHOICE {
1242 armored-data [1] KrbFastAmoredReq,
1246 KrbFastAmoredReq ::= SEQUENCE {
1247 armor [1] KrbFastArmor OPTIONAL,
1248 -- Contains the armor that determines the armor key.
1249 -- MUST be present in AS-REQ.
1250 -- MUST be absent in TGS-REQ.
1251 req-checksum [2] Checksum,
1252 -- Checksum performed over the type KDC-REQ-BODY.
1253 -- The checksum key is the armor key, the checksum
1254 -- type is the required checksum type for the enctype of
1255 -- the armor key, and the key usage number is
1256 -- KEY_USAGE_FAST_REA_CHKSUM.
1257 enc-fast-req [3] EncryptedData, -- KrbFastReq --
1258 -- The encryption key is the armor key, and the key usage
1259 -- number is KEY_USAGE_FAST_ENC.
1263 KEY_USAGE_FAST_REA_CHKSUM TBA
1264 KEY_USAGE_FAST_ENC TBA
1266 The PA-FX-FAST-REQUEST contains a KrbFastAmoredReq structure. The
1267 KrbFastAmoredReq encapsulates the encrypted padata.
1269 The armor key is used to encrypt the KrbFastReq structure, and the
1270 key usage number for that encryption is KEY_USAGE_FAST_ARMOR.
1272 KEY_USAGE_FAST_ARMOR TBA
1274 The armor key is identified as follows:
1276 o When a KrbFastAmoredReq is included in an AS request, the armor
1277 field MUST be present in the initial AS-REQ in a conversation,
1278 specifying the armor key being used. The armor field MUST be
1279 absent in any subsequent AS-REQ of the same conversation. In
1280 other words, the armor key is specified explicitly in the initial
1281 AS-REQ in a conversation, and implicitly thereafter.
1286 Zhu & Hartman Expires September 6, 2007 [Page 23]
1288 Internet-Draft Kerberos Preauth Framework March 2007
1291 o When a KrbFastAmoredReq is included in a TGS request, the armor
1292 field MUST be absent. In which case, the subkey in the AP-REQ
1293 authenticator in the PA-TGS-REQ PA-DATA MUST be present, and the
1294 armor key is implicitly that subkey.
1296 The req-checksum field contains a checksum that is performed over the
1297 type KDC-REQ-BODY of the containing message. The checksum key is the
1298 armor key, and the checksum type is the required checksum type for
1299 the enctype of the armor key.
1301 The enc-fast-req field contains an encrypted KrbFastReq structure.
1302 The KrbFastReq structure contains the following information:
1304 KrbFastReq ::= SEQUENCE {
1305 fast-options [0] FastOptions,
1306 -- Additional options.
1307 padata [1] SEQUENCE OF PA-DATA,
1308 -- padata typed holes.
1309 crealm [2] Realm OPTIONAL,
1310 cname [3] PrincipalName OPTIONAL,
1311 -- Contains the client realm and the client name.
1312 -- If present, the client name and realm in the
1313 -- AS_REQ KDC-REQ-BODY [RFC4120] MUST be ignored.
1317 The fast-options field indicates various options that are to modify
1318 the behavior of the KDC. The meanings of the options are as follows:
1320 FastOptions ::= KerberosFlags
1323 -- kdc-referrals(16)
1326 Bits Name Description
1327 -----------------------------------------------------------------
1328 0 RESERVED Reserved for future expansion of this field.
1329 1 anonymous Requesting the KDC to hide client names in
1330 the KDC response, as described next in this
1332 16 kdc-referrals Requesting the KDC to follow referrals, as
1333 described next in this section.
1335 Bits 1 through 15 (with bit 2 and bit 15 included) are critical
1336 options. If the KDC does not understand a critical option, it MUST
1337 fail the request. Bit 16 and onward (with bit 16 included) are non-
1338 critical options. KDCs conforming to this specification ignores
1342 Zhu & Hartman Expires September 6, 2007 [Page 24]
1344 Internet-Draft Kerberos Preauth Framework March 2007
1347 unknown non-critical options.
1349 The anonymous Option
1351 The Kerberos response defined in [RFC4120] contains the client
1352 identity in clear text, This makes traffic analysis
1353 straightforward. The anonymous option is designed to complicate
1354 traffic analysis performed over the messages exchanged between the
1355 client and the KDC. If the anonymous option is set, the KDC
1356 implementing PA_FX_FAST MUST identify the client as the anonymous
1357 principal in the KDC reply and the error response. Hence this
1358 option is set by the client if it wishes to conceal the client
1359 identity in the KDC response.
1361 The kdc-referrals Option
1363 The Kerberos client described in [RFC4120] has to request referral
1364 TGTs along the authentication path in order to get a service
1365 ticket for the target service. The Kerberos client described in
1366 the [REFERRALS] need to contact the AS specified in the error
1367 response in order to complete client referrals. The kdc-referrals
1368 option is designed to minimize the number of messages that need to
1369 be processed by the client. This option is useful when, for
1370 example, the client may contact the KDC via a satellite link that
1371 has high latency, or the client has limited computational
1372 capabilities. If the kdc-referrals option is set, the KDC that
1373 honors this option acts as the client to follow AS referrals and
1374 TGS referrals [REFERRALS], and return the ticket thus-obtained
1375 using the reply key expected by the client. The kdc-referrals
1376 option can be implemented when the KDC knows the reply key. The
1377 KDC can ignore kdc-referrals option when it does not understand it
1378 or it does not allow this option based on local policy. The
1379 client MUST be able to process the KDC responses when this option
1380 is not honored by the KDC, unless otherwise specified.
1382 The padata field contains a list of PA-DATA structures as described
1383 in Section 5.2.7 of [RFC4120]. These PA-DATA structures can contain
1384 FAST factors. They can also be used as generic typed-holes to
1385 contain data not intended for proving the client's identity or
1386 establishing a reply key, but for protocol extensibility.
1388 The crealm field and the cname field identify the client principal in
1389 the ticket request. If either the crealm field or the cname field is
1390 present, the corresponding crealm or cname field in the KDC-REQ-BODY
1391 [RFC4120] of an AS-REQ MUST be ignored. The client can fill in these
1392 fields in the KrbFastReq structure and leaves the cname field and the
1393 crealm field KDC-REQ-BODY absent, thus conceals its identity in the
1398 Zhu & Hartman Expires September 6, 2007 [Page 25]
1400 Internet-Draft Kerberos Preauth Framework March 2007
1403 6.5.4. FAST Response
1405 The KDC that supports the PA_FX_FAST padata MUST include a PA_FX_FAST
1406 padata element in the KDC reply and/or the error response, when the
1407 client and the KDC agreed upon the armor key. The corresponding
1408 padata-value field [RFC4120] in the KDC response is the DER encoding
1409 of the ASN.1 type PA-FX-FAST-REPLY.
1411 PA-FX-FAST-REPLY ::= CHOICE {
1412 armored-data [1] KrbFastArmoredRep,
1416 KrbFastArmoredRep ::= SEQUENCE {
1417 enc-fast-rep [1] EncryptedData, -- KrbFastResponse --
1418 -- The encryption key is the armor key in the request, and
1419 -- the key usage number is KEY_USAGE_FAST_REP.
1422 KEY_USAGE_FAST_REP TBA
1424 The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
1425 structure. The KrbFastArmoredRep structure encapsulates the padata
1426 in the KDC reply in the encrypted form. The KrbFastResponse is
1427 encrypted with the armor key used in the corresponding request, and
1428 the key usage number is KEY_USAGE_FAST_REP.
1430 The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
1431 KDC response MUST support a local policy that rejects the request.
1432 Clients MAY also support policies that fall back to other mechanisms
1433 or that do not use pre-authentication when FAST is unavailable. It
1434 is important to consider the potential downgrade attacks when
1435 deploying such a policy. The Kerberos client MAY process an error
1436 message without a PA-FX-FAST-REPLY, if that is only intended to
1437 return better error information to the application, typically for
1438 trouble-shooing purposes.
1440 The KrbFastResponse structure contains the following information:
1442 KrbFastResponse ::= SEQUENCE {
1443 padata [1] SEQUENCE OF PA-DATA,
1444 -- padata typed holes.
1445 finished [2] KrbFastFinished OPTIONAL,
1446 -- MUST be present if the client is authenticated,
1447 -- absent otherwise.
1448 -- Typically this is present if and only if the containing
1449 -- message is the last one in a conversation.
1454 Zhu & Hartman Expires September 6, 2007 [Page 26]
1456 Internet-Draft Kerberos Preauth Framework March 2007
1461 The padata field in the KrbFastResponse structure contains a list of
1462 PA-DATA structures as described in Section 5.2.7 of [RFC4120]. These
1463 PA-DATA structures are used to carry data advancing the exchange
1464 specific for the FAST factors. They can also be used as generic
1465 typed-holes for protocol extensibility.
1467 The finished field contains a KrbFastFinished structure. It is
1468 filled by the KDC in the final message in the conversation; it MUST
1469 be absent otherwise. Consequently this field can only be present in
1470 an AS-REP or a TGS-REP when a ticket is returned.
1472 The KrbFastFinished structure contains the following information:
1474 KrbFastFinished ::= SEQUENCE {
1475 timestamp [1] KerberosTime,
1476 usec [2] Microseconds,
1477 -- timestamp and usec represent the time on the KDC when
1478 -- the reply was generated.
1479 rep-key-package [3] EncryptedData OPTIONAL,
1481 -- This, if present, replaces the reply key for AS and TGS.
1482 -- The encryption key is the client key, unless otherwise
1483 -- specified. The key usage number is
1484 -- KEY_USAGE_FAST_FINISHED.
1486 cname [5] PrincipalName,
1487 -- Contains the client realm and the client name.
1488 checksum [6] Checksum,
1489 -- Checksum performed over all the messages in the
1490 -- conversation, except the containing message.
1491 -- The checksum key is the ticket session key of the reply
1492 -- ticket, and the checksum type is the required checksum
1493 -- type of that key.
1496 KEY_USAGE_FAST_REP_KEY TBA
1497 KEY_USAGE_FAST_FINISHED TBA
1499 The timestamp and usec fields represent the time on the KDC when the
1500 reply ticket was generated, these fields have the same semantics as
1501 the corresponding-identically-named fields in Section 5.6.1 of
1502 [RFC4120]. The client MUST use the KDC's time in these fields
1503 thereafter when using the returned ticket. Note that the KDC's time
1504 in AS-REP may not match the authtime in the reply ticket if the kdc-
1505 referrals option is requested and honored by the KDC.
1510 Zhu & Hartman Expires September 6, 2007 [Page 27]
1512 Internet-Draft Kerberos Preauth Framework March 2007
1515 The rep-key-package field, if present, contains the reply key
1516 encrypted using the client key unless otherwise specified. The key
1517 usage number is KEY_USAGE_FAST_REP_KEY.
1519 When the encrypted timestamp FAST factor is used in the request, the
1520 rep-key-package field MUST be present and the client key is used to
1521 encrypt the reply key enclosed in the KrbFastArmoredRep.
1523 The cname and crealm fields identify the authenticated client.
1525 The checksum field contains a checksum of all the messages in the
1526 conversation prior to the containing message (the containing message
1527 is excluded). The checksum key is the ticket session key of the
1528 reply ticket, the checksum type is the required checksum type of the
1529 enctype of that key, and the key usage number is
1530 KEY_USAGE_FAST_FINISHED.
1532 6.5.5. Error Messages used with Kerberos FAST
1534 If the Kerberos FAST padata was included in the request, unless
1535 otherwise specified, the e-data field of the KRB-ERROR message
1536 [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
1537 [RFC4120], where a PA_FX_FAST padata element is included and it
1538 contains the DER encoding of the type PA-FX-FAST-REPLY. If the
1539 e-data field of the KRB-ERROR message contains the DER encoding of a
1540 TYPED-DATA, a typed data element TD_FX_FAST SHOULD be included in the
1541 e-data if the Kerberos FAST padata is included in the request, and
1542 the corresponding data-value field [RFC4120] contains the ASN.1 DER
1543 encoding of the type PA-FX-FAST-REPLY. In other words, the typed
1544 data element type TD_FX_FAST is allocated to encapsulate the FAST
1545 reply message in the error responses. If a PA-FX-FAST-REPLY is not
1546 included in the error reply, it is a matter of the local policy on
1547 the client to accept the information in the error message without
1548 integrity protection. [[anchor21: Why do we want padata in arbitrary
1549 error responses? What if the KDC cannot generate a fast reply
1550 because for example no armor nor state cookie was included in a
1551 request? Also, we need to confirm that the WG is OK with a pre-
1552 authentication specification changing error returns for unrelated
1556 -- Typed data element type for Kerberos FAST
1558 6.6. Authentication Strength Indication
1560 Implementations that have pre-authentication mechanisms offering
1561 significantly different strengths of client authentication MAY choose
1562 to keep track of the strength of the authentication used as an input
1566 Zhu & Hartman Expires September 6, 2007 [Page 28]
1568 Internet-Draft Kerberos Preauth Framework March 2007
1571 into policy decisions. For example, some principals might require
1572 strong pre-authentication, while less sensitive principals can use
1573 relatively weak forms of pre-authentication like encrypted timestamp.
1575 An AuthorizationData data type AD-Authentication-Strength is defined
1578 AD-authentication-strength TBA
1580 The corresponding ad-data field contains the DER encoding of the pre-
1581 authentication data set as defined in Section 6.4. This set contains
1582 all the pre-authentication mechanisms that were used to authenticate
1583 the client. If only one pre-authentication mechanism was used to
1584 authenticate the client, the pre-authentication set contains one
1587 The AD-authentication-strength element MUST be included in the AD-IF-
1588 RELEVANT, thus it can be ignored if it is unknown to the receiver.
1591 7. IANA Considerations
1593 This document defines FAST factors, these are mini- and light-
1594 weighted- pre-authentication mechanisms. A new IANA registry should
1595 be setup for registering FAST factor IDs. The evaluation policy is
1596 "Specification Required".
1599 8. Security Considerations
1601 The kdc-referrals option in the Kerberos FAST padata requests the KDC
1602 to act as the client to follow referrals. This can overload the KDC.
1603 To limit the damages of denied of service using this option, KDCs MAY
1604 restrict the number of simultaneous active requests with this option
1605 for any given client principal.
1607 Because the client secrets are known only to the client and the KDC,
1608 the verification of the encrypted timestamp proves the client's
1609 identity, the verification of the encrypted rep-key-package in the
1610 KDC reply proves that the expected KDC responded. The encrypted
1611 reply key is contained in the rep-key-package in the PA-FX-FAST-
1612 REPLY. Therefore, the encrypted timestamp FAST factor as a pre-
1613 authentication mechanism offers the following facilities: client-
1614 authentication, replacing-reply-key, KDC-authentication. There is no
1615 un-authenticated clear text introduced by the encrypted timestamp
1622 Zhu & Hartman Expires September 6, 2007 [Page 29]
1624 Internet-Draft Kerberos Preauth Framework March 2007
1629 Several suggestions from Jeffery Hutzman based on early revisions of
1630 this documents led to significant improvements of this document.
1635 10.1. Normative References
1637 [KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity
1638 Support", draft-ietf-krb-wg-anon, work in progress.
1640 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1641 Requirement Levels", BCP 14, RFC 2119, March 1997.
1643 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
1644 Kerberos 5", RFC 3961, February 2005.
1646 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
1647 Kerberos Network Authentication Service (V5)", RFC 4120,
1650 [REFERALS] Raeburn, K. et al, "Generating KDC Referrals to Locate
1651 Kerberos Realms", draft-ietf-krb-wg-kerberos-referrals,
1654 [SHA2] National Institute of Standards and Technology, "Secure
1655 Hash Standard (SHS)", Federal Information Processing
1656 Standards Publication 180-2, August 2002.
1658 [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
1659 Information technology - Abstract Syntax Notation One
1660 (ASN.1): Specification of basic notation.
1662 [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
1663 Information technology - ASN.1 encoding Rules:
1664 Specification of Basic Encoding Rules (BER), Canonical
1665 Encoding Rules (CER) and Distinguished Encoding Rules
1668 10.2. Informative References
1670 [EKE] Bellovin, S. M. and M. Merritt. "Augmented
1671 Encrypted Key Exchange: A Password-Based Protocol Secure
1672 Against Dictionary Attacks and Password File Compromise".
1673 Proceedings of the 1st ACM Conference on Computer and
1674 Communications Security, ACM Press, November 1993.
1676 [HKDF] Dang, Q. and P. Polk, draft-dang-nistkdf, work in
1680 IEEE P1363.2: Password-Based Public-Key Cryptography,
1684 Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
1685 "Integrating Single-use Authentication Mechanisms with
1686 Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in
1687 progress), October 2003.
1689 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial
1690 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
1693 Appendix A. ASN.1 module
1695 KerberosPreauthFramework {
1696 iso(1) identified-organization(3) dod(6) internet(1)
1697 security(5) kerberosV5(2) modules(4) preauth-framework(3)
1698 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
1701 KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
1702 Int32, EncryptedData, PA-DATA
1703 FROM KerberosV5Spec2 { iso(1) identified-organization(3)
1704 dod(6) internet(1) security(5) kerberosV5(2)
1705 modules(4) krb5spec2(2) };
1706 -- as defined in RFC 4120.
1708 PA-FX-COOKIE ::= SEQUENCE {
1712 Zhu & Hartman Expires September 6, 2007 [Page 30]
1714 Internet-Draft Kerberos Preauth Framework March 2007
1717 Cookie [1] OCTET STRING,
1718 -- Opaque data, for use to associate all the messages in a
1719 -- single conversation between the client and the KDC.
1720 -- This can be generated by either the client or the KDC.
1721 -- The receiver MUST copy the exact Cookie encapsulated in
1722 -- a PA_FX_COOKIE data element into the next message of the
1723 -- same conversation.
1727 PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
1729 PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
1731 -- same as padata-type.
1732 pa-hint [2] OCTET STRING,
1737 PA-FX-FAST-REQUEST ::= CHOICE {
1738 armored-data [1] KrbFastAmoredReq,
1742 KrbFastAmoredReq ::= SEQUENCE {
1743 armor [1] KrbFastArmor OPTIONAL,
1744 -- Contains the armor that determines the armor key.
1745 -- MUST be present in AS-REQ.
1746 -- MUST be absent in TGS-REQ.
1747 req-checksum [2] Checksum,
1748 -- Checksum performed over the type KDC-REQ-BODY.
1749 -- The checksum key is the armor key, the checksum
1750 -- type is the required checksum type for the enctype of
1751 -- the armor key, and the key usage number is
1752 -- KEY_USAGE_FAST_REA_CHKSUM.
1753 enc-fast-req [3] EncryptedData, -- KrbFastReq --
1754 -- The encryption key is the armor key, and the key usage
1755 -- number is KEY_USAGE_FAST_ENC.
1759 KrbFastArmor ::= SEQUENCE {
1760 armor-type [1] Int32,
1761 -- Type of the armor.
1762 armor-value [2] OCTET STRING,
1763 -- Value of the armor.
1768 Zhu & Hartman Expires September 6, 2007 [Page 31]
1770 Internet-Draft Kerberos Preauth Framework March 2007
1775 KrbFastReq ::= SEQUENCE {
1776 fast-options [0] FastOptions,
1777 -- Additional options.
1778 padata [1] SEQUENCE OF PA-DATA,
1779 -- padata typed holes.
1780 crealm [2] Realm OPTIONAL,
1781 cname [3] PrincipalName OPTIONAL,
1782 -- Contains the client realm and the client name.
1783 -- If present, the client name and realm in the
1784 -- AS_REQ KDC-REQ-BODY [RFC4120] MUST be ignored.
1788 FastOptions ::= KerberosFlags
1791 -- kdc-referrals(16)
1793 PA-FX-FAST-REPLY ::= CHOICE {
1794 armored-data [1] KrbFastArmoredRep,
1798 KrbFastArmoredRep ::= SEQUENCE {
1799 enc-fast-rep [1] EncryptedData, -- KrbFastResponse --
1800 -- The encryption key is the armor key in the request, and
1801 -- the key usage number is KEY_USAGE_FAST_REP.
1805 KrbFastResponse ::= SEQUENCE {
1806 padata [1] SEQUENCE OF PA-DATA,
1807 -- padata typed holes.
1808 finished [2] KrbFastFinished OPTIONAL,
1809 -- MUST be present if the client is authenticated,
1810 -- absent otherwise.
1811 -- Typically this is present if and only if the containing
1812 -- message is the last one in a conversation.
1816 KrbFastFinished ::= SEQUENCE {
1817 timestamp [1] KerberosTime,
1818 usec [2] Microseconds,
1819 -- timestamp and usec represent the time on the KDC when
1820 -- the reply was generated.
1824 Zhu & Hartman Expires September 6, 2007 [Page 32]
1826 Internet-Draft Kerberos Preauth Framework March 2007
1829 rep-key-package [3] EncryptedData OPTIONAL,
1831 -- This, if present, replaces the reply key for AS and TGS.
1832 -- The encryption key is the client key, unless otherwise
1833 -- specified. The key usage number is
1834 -- KEY_USAGE_FAST_FINISHED.
1836 cname [5] PrincipalName,
1837 -- Contains the client realm and the client name.
1838 checksum [6] Checksum,
1839 -- Checksum performed over all the messages in the
1840 -- conversation, except the containing message.
1841 -- The checksum key is the ticket session key of the reply
1842 -- ticket, and the checksum type is the required checksum
1843 -- type of that key.
1852 Microsoft Corporation
1857 Email: lzhu@microsoft.com
1863 Email: hartmans@mit.edu
1880 Zhu & Hartman Expires September 6, 2007 [Page 33]
1882 Internet-Draft Kerberos Preauth Framework March 2007
1885 Full Copyright Statement
1887 Copyright (C) The IETF Trust (2007).
1889 This document is subject to the rights, licenses and restrictions
1890 contained in BCP 78, and except as set forth therein, the authors
1891 retain all their rights.
1893 This document and the information contained herein are provided on an
1894 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1895 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1896 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1897 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1898 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1899 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1902 Intellectual Property
1904 The IETF takes no position regarding the validity or scope of any
1905 Intellectual Property Rights or other rights that might be claimed to
1906 pertain to the implementation or use of the technology described in
1907 this document or the extent to which any license under such rights
1908 might or might not be available; nor does it represent that it has
1909 made any independent effort to identify any such rights. Information
1910 on the procedures with respect to rights in RFC documents can be
1911 found in BCP 78 and BCP 79.
1913 Copies of IPR disclosures made to the IETF Secretariat and any
1914 assurances of licenses to be made available, or the result of an
1915 attempt made to obtain a general license or permission for the use of
1916 such proprietary rights by implementers or users of this
1917 specification can be obtained from the IETF on-line IPR repository at
1918 http://www.ietf.org/ipr.
1920 The IETF invites any interested party to bring to its attention any
1921 copyrights, patents or patent applications, or other proprietary
1922 rights that may cover technology that may be required to implement
1923 this standard. Please address the information to the IETF at
1929 Funding for the RFC Editor function is provided by the IETF
1930 Administrative Support Activity (IASA).
1936 Zhu & Hartman Expires September 6, 2007 [Page 34]