summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6113.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6113.txt')
-rw-r--r--doc/rfc/rfc6113.txt2691
1 files changed, 2691 insertions, 0 deletions
diff --git a/doc/rfc/rfc6113.txt b/doc/rfc/rfc6113.txt
new file mode 100644
index 0000000..e0a579e
--- /dev/null
+++ b/doc/rfc/rfc6113.txt
@@ -0,0 +1,2691 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Hartman
+Request for Comments: 6113 Painless Security
+Updates: 4120 L. Zhu
+Category: Standards Track Microsoft Corporation
+ISSN: 2070-1721 April 2011
+
+
+ A Generalized Framework for Kerberos Pre-Authentication
+
+Abstract
+
+ Kerberos is a protocol for verifying the identity of principals
+ (e.g., a workstation user or a network server) on an open network.
+ The Kerberos protocol provides a facility called pre-authentication.
+ Pre-authentication mechanisms can use this facility to extend the
+ Kerberos protocol and prove the identity of a principal.
+
+ This document describes a more formal model for this facility. The
+ model describes what state in the Kerberos request a pre-
+ authentication mechanism is likely to change. It also describes how
+ multiple pre-authentication mechanisms used in the same request will
+ interact.
+
+ This document also provides common tools needed by multiple pre-
+ authentication mechanisms. One of these tools is a secure channel
+ between the client and the key distribution center with a reply key
+ strengthening mechanism; this secure channel can be used to protect
+ the authentication exchange and thus eliminate offline dictionary
+ attacks. With these tools, it is relatively straightforward to chain
+ multiple authentication mechanisms, utilize a different key
+ management system, or support a new key agreement algorithm.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6113.
+
+
+
+
+
+
+Hartman & Zhu Standards Track [Page 1]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu Standards Track [Page 2]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Conventions and Terminology Used in This Document ..........5
+ 1.2. Conformance Requirements ...................................5
+ 2. Model for Pre-Authentication ....................................6
+ 2.1. Information Managed by the Pre-Authentication Model ........7
+ 2.2. Initial Pre-Authentication Required Error ..................9
+ 2.3. Client to KDC .............................................10
+ 2.4. KDC to Client .............................................11
+ 3. Pre-Authentication Facilities ..................................12
+ 3.1. Client Authentication Facility ............................13
+ 3.2. Strengthening Reply Key Facility ..........................13
+ 3.3. Replace Reply Key Facility ................................14
+ 3.4. KDC Authentication Facility ...............................15
+ 4. Requirements for Pre-Authentication Mechanisms .................15
+ 4.1. Protecting Requests/Responses .............................16
+ 5. Tools for Use in Pre-Authentication Mechanisms .................17
+ 5.1. Combining Keys ............................................17
+ 5.2. Managing States for the KDC ...............................19
+ 5.3. Pre-Authentication Set ....................................20
+ 5.4. Definition of Kerberos FAST Padata ........................23
+ 5.4.1. FAST Armors ........................................24
+ 5.4.2. FAST Request .......................................26
+ 5.4.3. FAST Response ......................................30
+ 5.4.4. Authenticated Kerberos Error Messages Using
+ Kerberos FAST ......................................33
+ 5.4.5. Outer and Inner Requests ...........................34
+ 5.4.6. The Encrypted Challenge FAST Factor ................34
+ 5.5. Authentication Strength Indication ........................36
+ 6. Assigned Constants .............................................37
+ 6.1. New Errors ................................................37
+ 6.2. Key Usage Numbers .........................................37
+ 6.3. Authorization Data Elements ...............................37
+ 6.4. New PA-DATA Types .........................................37
+ 7. IANA Considerations ............................................38
+ 7.1. Pre-Authentication and Typed Data .........................38
+ 7.2. Fast Armor Types ..........................................40
+ 7.3. FAST Options ..............................................40
+ 8. Security Considerations ........................................41
+ 9. Acknowledgements ...............................................42
+ 10. References ....................................................43
+ 10.1. Normative References .....................................43
+ 10.2. Informative References ...................................43
+ Appendix A. Test Vectors for KRB-FX-CF2 ...........................45
+ Appendix B. ASN.1 Module ..........................................46
+
+
+
+
+
+Hartman & Zhu Standards Track [Page 3]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+1. Introduction
+
+ The core Kerberos specification [RFC4120] treats pre-authentication
+ data (padata) as an opaque typed hole in the messages to the key
+ distribution center (KDC) that may influence the reply key used to
+ encrypt the KDC reply. This generality has been useful: pre-
+ authentication data is used for a variety of extensions to the
+ protocol, many outside the expectations of the initial designers.
+ However, this generality makes designing more common types of pre-
+ authentication mechanisms difficult. Each mechanism needs to specify
+ how it interacts with other mechanisms. Also, tasks such as
+ combining a key with the long-term secrets or proving the identity of
+ the user are common to multiple mechanisms. Where there are
+ generally well-accepted solutions to these problems, it is desirable
+ to standardize one of these solutions so mechanisms can avoid
+ duplication of work. In other cases, a modular approach to these
+ problems is appropriate. The modular approach will allow new and
+ better solutions to common pre-authentication problems to be used by
+ existing mechanisms as they are developed.
+
+ This document specifies a framework for Kerberos pre-authentication
+ mechanisms. It defines the common set of functions that pre-
+ authentication mechanisms perform as well as how these functions
+ affect the state of the request and reply. In addition, several
+ common tools needed by pre-authentication mechanisms are provided.
+ Unlike [RFC3961], this framework is not complete -- it does not
+ describe all the inputs and outputs for the pre-authentication
+ mechanisms. Pre-authentication mechanism designers should try to be
+ consistent with this framework because doing so will make their
+ mechanisms easier to implement. Kerberos implementations are likely
+ to have plug-in architectures for pre-authentication; such
+ architectures are likely to support mechanisms that follow this
+ framework plus commonly used extensions. This framework also
+ facilitates combining multiple pre-authentication mechanisms, each of
+ which may represent an authentication factor, into a single multi-
+ factor pre-authentication mechanism.
+
+ One of these common tools is the flexible authentication secure
+ tunneling (FAST) padata type. FAST provides a protected channel
+ between the client and the key distribution center (KDC), and it can
+ optionally deliver key material used to strengthen the reply key
+ within the protected channel. Based on FAST, pre-authentication
+ mechanisms can extend Kerberos with ease, to support, for example,
+ password-authenticated key exchange (PAKE) protocols with zero-
+ knowledge password proof (ZKPP) [EKE] [IEEE1363.2]. Any pre-
+ authentication mechanism can be encapsulated in the FAST messages as
+ defined in Section 5.4. A pre-authentication type carried within
+ FAST is called a "FAST factor". Creating a FAST factor is the
+
+
+
+Hartman & Zhu Standards Track [Page 4]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ easiest path to create a new pre-authentication mechanism. FAST
+ factors are significantly easier to analyze from a security
+ standpoint than other pre-authentication mechanisms.
+
+ Mechanism designers should design FAST factors, instead of new pre-
+ authentication mechanisms outside of FAST.
+
+1.1. Conventions and Terminology Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ This document should be read only after reading the documents
+ describing the Kerberos cryptography framework [RFC3961] and the core
+ Kerberos protocol [RFC4120]. This document may freely use
+ terminology and notation from these documents without reference or
+ further explanation.
+
+ The word padata is used as a shorthand for pre-authentication data.
+
+ A conversation is the set of all authentication messages exchanged
+ between the client and the client's Authentication Service (AS) in
+ order to authenticate the client principal. A conversation as
+ defined here consists of all messages that are necessary to complete
+ the authentication between the client and the client's AS. In the
+ Ticket Granting Service (TGS) exchange, a conversation consists of
+ the request message and the reply message. The term conversation is
+ defined here for both AS and TGS for convenience of discussion. See
+ Section 5.2 for specific rules on the extent of a conversation in the
+ AS-REQ case. Prior to this framework, implementations needed to use
+ implementation-specific heuristics to determine the extent of a
+ conversation.
+
+ If the KDC reply in an AS exchange is verified, the KDC is
+ authenticated by the client. In this document, verification of the
+ KDC reply is used as a synonym of authentication of the KDC.
+
+1.2. Conformance Requirements
+
+ This section summarizes the mandatory-to-implement subset of this
+ specification as a convenience to implementors. The actual
+ requirements and their context are stated in the body of the
+ document.
+
+ Clients conforming to this specification MUST support the padata
+ defined in Section 5.2.
+
+
+
+
+Hartman & Zhu Standards Track [Page 5]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ Conforming implementations MUST support Kerberos FAST padata
+ (Section 5.4). Conforming implementations MUST implement the
+ FX_FAST_ARMOR_AP_REQUEST armor type.
+
+ Conforming implementations MUST support the encrypted challenge FAST
+ factor (Section 5.4.6).
+
+2. Model for Pre-Authentication
+
+ When a Kerberos client wishes to obtain a ticket, it sends an initial
+ Authentication Service (AS) request to the KDC. If pre-
+ authentication is required but not being used, then the KDC will
+ respond with a KDC_ERR_PREAUTH_REQUIRED error [RFC4120].
+ Alternatively, if the client knows what pre-authentication to use, it
+ MAY optimize away a round trip and send an initial request with
+ padata included in the initial request. If the client includes the
+ padata computed using the wrong pre-authentication mechanism or
+ incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
+ indication of what padata should have been included. In that case,
+ the client MUST retry with no padata and examine the error data of
+ the KDC_ERR_PREAUTH_REQUIRED error. If the KDC includes pre-
+ authentication information in the accompanying error data of
+ KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data and
+ then retry.
+
+ The conventional KDC maintains no state between two requests;
+ subsequent requests may even be processed by a different KDC. On the
+ other hand, the client treats a series of exchanges with KDCs as a
+ single conversation. Each exchange accumulates state and hopefully
+ brings the client closer to a successful authentication.
+
+ These models for state management are in apparent conflict. For many
+ of the simpler pre-authentication scenarios, the client uses one
+ round trip to find out what mechanisms the KDC supports. Then, the
+ next request contains sufficient pre-authentication for the KDC to be
+ able to return a successful reply. For these simple scenarios, the
+ client only sends one request with pre-authentication data and so the
+ conversation is trivial. For more complex conversations, the KDC
+ needs to provide the client with a cookie to include in future
+ requests to capture the current state of the authentication session.
+ Handling of multiple round-trip mechanisms is discussed in
+ Section 5.2.
+
+ This framework specifies the behavior of Kerberos pre-authentication
+ mechanisms used to identify users or to modify the reply key used to
+ encrypt the KDC reply. The PA-DATA typed hole may be used to carry
+ extensions to Kerberos that have nothing to do with proving the
+
+
+
+
+Hartman & Zhu Standards Track [Page 6]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ identity of the user or establishing a reply key. Such extensions
+ are outside the scope of this framework. However, mechanisms that do
+ accomplish these goals should follow this framework.
+
+ This framework specifies the minimum state that a Kerberos
+ implementation needs to maintain while handling a request in order to
+ process pre-authentication. It also specifies how Kerberos
+ implementations process the padata at each step of the AS request
+ process.
+
+2.1. Information Managed by the Pre-Authentication Model
+
+ The following information is maintained by the client and KDC as each
+ request is being processed:
+
+ o The reply key used to encrypt the KDC reply
+
+ o How strongly the identity of the client has been authenticated
+
+ o Whether the reply key has been used in this conversation
+
+ o Whether the reply key has been replaced in this conversation
+
+ o Whether the origin of the KDC reply can be verified by the client
+ (i.e., whether the KDC is authenticated to the client)
+
+ Conceptually, the reply key is initially the long-term key of the
+ principal. However, principals can have multiple long-term keys
+ because of support for multiple encryption types, salts, and
+ string2key parameters. As described in Section 5.2.7.5 of the
+ Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
+ the client what types of keys are available. Thus, in full
+ generality, the reply key in the pre-authentication model is actually
+ a set of keys. At the beginning of a request, it is initialized to
+ the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
+ the KDC. If multiple reply keys are available, the client chooses
+ which one to use. Thus, the client does not need to treat the reply
+ key as a set. At the beginning of a request, the client picks a key
+ to use.
+
+ KDC implementations MAY choose to offer only one key in the PA-ETYPE-
+ INFO2 element. Since the KDC already knows the client's list of
+ supported enctypes from the request, no interoperability problems are
+
+
+
+
+
+
+
+
+Hartman & Zhu Standards Track [Page 7]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ created by choosing a single possible reply key. This way, the KDC
+ implementation avoids the complexity of treating the reply key as a
+ set.
+
+ When the padata in the request are verified by the KDC, then the
+ client is known to have that key; therefore, the KDC SHOULD pick the
+ same key as the reply key.
+
+ At the beginning of handling a message on both the client and the
+ KDC, the client's identity is not authenticated. A mechanism may
+ indicate that it has successfully authenticated the client's
+ identity. It is useful to keep track of this information on the
+ client in order to know what pre-authentication mechanisms should be
+ used. The KDC needs to keep track of whether the client is
+ authenticated because the primary purpose of pre-authentication is to
+ authenticate the client identity before issuing a ticket. The
+ handling of authentication strength using various authentication
+ mechanisms is discussed in Section 5.5.
+
+ Initially, the reply key is not used. A pre-authentication mechanism
+ that uses the reply key to encrypt or checksum some data in the
+ generation of new keys MUST indicate that the reply key is used.
+ This state is maintained by the client and the KDC to enforce the
+ security requirement stated in Section 3.3 that the reply key SHOULD
+ NOT be replaced after it is used.
+
+ Initially, the reply key is not replaced. If a mechanism implements
+ the Replace Reply Key facility discussed in Section 3.3, then the
+ state MUST be updated to indicate that the reply key has been
+ replaced. Once the reply key has been replaced, knowledge of the
+ reply key is insufficient to authenticate the client. The reply key
+ is marked as replaced in exactly the same situations as the KDC reply
+ is marked as not being verified to the client principal. However,
+ while mechanisms can verify the KDC reply to the client, once the
+ reply key is replaced, then the reply key remains replaced for the
+ remainder of the conversation.
+
+ Without pre-authentication, the client knows that the KDC reply is
+ authentic and has not been modified because it is encrypted in a
+ long-term key of the client. Only the KDC and the client know that
+ key. So, at the start of a conversation, the KDC reply is presumed
+ to be verified using the client's long-term key. It should be noted
+ that in this document, verifying the KDC reply means authenticating
+ the KDC, and these phrases are used interchangeably. Any pre-
+ authentication mechanism that sets a new reply key not based on the
+ principal's long-term secret MUST either verify the KDC reply some
+ other way or indicate that the reply is not verified. If a mechanism
+ indicates that the reply is not verified, then the client
+
+
+
+Hartman & Zhu Standards Track [Page 8]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ implementation MUST return an error unless a subsequent mechanism
+ verifies the reply. The KDC needs to track this state so it can
+ avoid generating a reply that is not verified.
+
+ In this specification, KDC verification/authentication refers to the
+ level of authentication of the KDC to the client provided by RFC
+ 4120. There is a stronger form of KDC verification that, while
+ sometimes important in Kerberos deployments, is not addressed in this
+ specification: the typical Kerberos request does not provide a way
+ for the client machine to know that it is talking to the correct KDC.
+ Someone who can inject packets into the network between the client
+ machine and the KDC and who knows the password that the user will
+ give to the client machine can generate a KDC reply that will decrypt
+ properly. So, if the client machine needs to authenticate that the
+ user is in fact the named principal, then the client machine needs to
+ do a TGS request for itself as a service. Some pre-authentication
+ mechanisms may provide a way for the client machine to authenticate
+ the KDC. Examples of this include signing the reply that can be
+ verified using a well-known public key or providing a ticket for the
+ client machine as a service.
+
+2.2. Initial Pre-Authentication Required Error
+
+ Typically, a client starts a conversation by sending an initial
+ request with no pre-authentication. If the KDC requires pre-
+ authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
+ After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
+ the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_REQUIRED
+ (defined in Section 5.2) for pre-authentication configurations that
+ use multi-round-trip mechanisms; see Section 2.4 for details of that
+ case.
+
+ The KDC needs to choose which mechanisms to offer the client. The
+ client needs to be able to choose what mechanisms to use from the
+ first message. For example, consider the KDC that will accept
+ mechanism A followed by mechanism B or alternatively the single
+ mechanism C. A client that supports A and C needs to know that it
+ should not bother trying A.
+
+ Mechanisms can either be sufficient on their own or can be part of an
+ authentication set -- a group of mechanisms that all need to
+ successfully complete in order to authenticate a client. Some
+ mechanisms may only be useful in authentication sets; others may be
+ useful alone or in authentication sets. For the second group of
+ mechanisms, KDC policy dictates whether the mechanism will be part of
+ an authentication set, offered alone, or both. For each mechanism
+ that is offered alone (even if it is also offered in an
+ authentication set), the KDC includes the pre-authentication type ID
+
+
+
+Hartman & Zhu Standards Track [Page 9]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ of the mechanism in the padata sequence returned in the
+ KDC_ERR_PREAUTH_REQUIRED error. Mechanisms that are only offered as
+ part of an authentication set are not directly represented in the
+ padata sequence returned in the KDC_ERR_PREAUTH_REQUIRED error,
+ although they are represented in the PA-AUTHENTICATION-SET sequence.
+
+ The KDC SHOULD NOT send data that is encrypted in the long-term
+ password-based key of the principal. Doing so has the same security
+ exposures as the Kerberos protocol without pre-authentication. There
+ are few situations where the KDC needs to expose cipher text
+ encrypted in a weak key before the client has proven knowledge of
+ that key, and where pre-authentication is desirable.
+
+2.3. Client to KDC
+
+ This description assumes that a client has already received a
+ KDC_ERR_PREAUTH_REQUIRED from the KDC. If the client performs
+ optimistic pre-authentication, then the client needs to guess values
+ for the information it would normally receive from that error
+ response or use cached information obtained in prior interactions
+ with the KDC.
+
+ The client starts by initializing the pre-authentication state as
+ specified. It then processes the padata in the
+ KDC_ERR_PREAUTH_REQUIRED.
+
+ When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
+ client MAY ignore any padata it chooses unless doing so violates a
+ specification to which the client conforms. Clients conforming to
+ this specification MUST NOT ignore the padata defined in Section 5.2.
+ Clients SHOULD choose one authentication set or mechanism that could
+ lead to authenticating the user and ignore other such mechanisms.
+ However, this rule does not affect the processing of padata unrelated
+ to this framework; clients SHOULD process such padata normally.
+ Since the list of mechanisms offered by the KDC is in the decreasing
+ preference order, clients typically choose the first mechanism or
+ authentication set that the client can usefully perform. If a client
+ chooses to ignore padata, it MUST NOT process the padata, allow the
+ padata to affect the pre-authentication state, or respond to the
+ padata.
+
+ For each instance of padata the client chooses to process, the client
+ processes the padata and modifies the pre-authentication state as
+ required by that mechanism.
+
+
+
+
+
+
+
+Hartman & Zhu Standards Track [Page 10]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ After processing the padata in the KDC error, the client generates a
+ new request. It processes the pre-authentication mechanisms in the
+ order in which they will appear in the next request, updating the
+ state as appropriate. The request is sent when it is complete.
+
+2.4. KDC to Client
+
+ When a KDC receives an AS request from a client, it needs to
+ determine whether it will respond with an error or an AS reply.
+ There are many causes for an error to be generated that have nothing
+ to do with pre-authentication; they are discussed in the core
+ Kerberos specification.
+
+ From the standpoint of evaluating the pre-authentication, the KDC
+ first starts by initializing the pre-authentication state. If a PA-
+ FX-COOKIE pre-authentication data item is present, it is processed
+ first; see Section 5.2 for a definition. It then processes the
+ padata in the request. As mentioned in Section 2.3, the KDC MAY
+ ignore padata that are inappropriate for the configuration and MUST
+ ignore padata of an unknown type. The KDC MUST NOT ignore padata of
+ types used in previous messages. For example, if a KDC issues a
+ KDC_ERR_PREAUTH_REQUIRED error including padata of type x, then the
+ KDC cannot ignore padata of type x received in an AS-REQ message from
+ the client.
+
+ At this point, the KDC decides whether it will issue an error or a
+ reply. Typically, a KDC will issue a reply if the client's identity
+ has been authenticated to a sufficient degree.
+
+ In the case of a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error, the KDC
+ first starts by initializing the pre-authentication state. Then, it
+ processes any padata in the client's request in the order provided by
+ the client. Mechanisms that are not understood by the KDC are
+ ignored. Next, it generates padata for the error response, modifying
+ the pre-authentication state appropriately as each mechanism is
+ processed. The KDC chooses the order in which it will generate
+ padata (and thus the order of padata in the response), but it needs
+ to modify the pre-authentication state consistently with the choice
+ of order. For example, if some mechanism establishes an
+ authenticated client identity, then the subsequent mechanisms in the
+ generated response receive this state as input. After the padata are
+ generated, the error response is sent. Typically, the errors with
+ the code KDC_ERR_MORE_PREAUTH_DATA_REQUIRED in a conversation will
+ include KDC state, as discussed in Section 5.2.
+
+ To generate a final reply, the KDC generates the padata modifying the
+ pre-authentication state as necessary. Then, it generates the final
+ response, encrypting it in the current pre-authentication reply key.
+
+
+
+Hartman & Zhu Standards Track [Page 11]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+3. Pre-Authentication Facilities
+
+ Pre-authentication mechanisms can be thought of as providing various
+ conceptual facilities. This serves two useful purposes. First,
+ mechanism authors can choose only to solve one specific small
+ problem. It is often useful for a mechanism designed to offer key
+ management not to directly provide client authentication but instead
+ to allow one or more other mechanisms to handle this need. Secondly,
+ thinking about the abstract services that a mechanism provides yields
+ a minimum set of security requirements that all mechanisms providing
+ that facility must meet. These security requirements are not
+ complete; mechanisms will have additional security requirements based
+ on the specific protocol they employ.
+
+ A mechanism is not constrained to only offering one of these
+ facilities. While such mechanisms can be designed and are sometimes
+ useful, many pre-authentication mechanisms implement several
+ facilities. It is often easier to construct a secure, simple
+ solution by combining multiple facilities in a single mechanism than
+ by solving the problem in full generality. Even when mechanisms
+ provide multiple facilities, they need to meet the security
+ requirements for all the facilities they provide. If the FAST factor
+ approach is used, it is likely that one or a small number of
+ facilities can be provided by a single mechanism without complicating
+ the security analysis.
+
+ According to Kerberos extensibility rules (Section 1.5 of the
+ Kerberos specification [RFC4120]), an extension MUST NOT change the
+ semantics of a message unless a recipient is known to understand that
+ extension. Because a client does not know that the KDC supports a
+ particular pre-authentication mechanism when it sends an initial
+ request, a pre-authentication mechanism MUST NOT change the semantics
+ of the request in a way that will break a KDC that does not
+ understand that mechanism. Similarly, KDCs MUST NOT send messages to
+ clients that affect the core semantics unless the client has
+ indicated support for the message.
+
+ The only state in this model that would break the interpretation of a
+ message is changing the expected reply key. If one mechanism changed
+ the reply key and a later mechanism used that reply key, then a KDC
+ that interpreted the second mechanism but not the first would fail to
+ interpret the request correctly. In order to avoid this problem,
+ extensions that change core semantics are typically divided into two
+ parts. The first part proposes a change to the core semantic -- for
+ example, proposes a new reply key. The second part acknowledges that
+ the extension is understood and that the change takes effect.
+ Section 3.2 discusses how to design mechanisms that modify the reply
+ key to be split into a proposal and acceptance without requiring
+
+
+
+Hartman & Zhu Standards Track [Page 12]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ additional round trips to use the new reply key in subsequent pre-
+ authentication. Other changes in the state described in Section 2.1
+ can safely be ignored by a KDC that does not understand a mechanism.
+ Mechanisms that modify the behavior of the request outside the scope
+ of this framework need to carefully consider the Kerberos
+ extensibility rules to avoid similar problems.
+
+3.1. Client Authentication Facility
+
+ The Client Authentication facility proves the identity of a user to
+ the KDC before a ticket is issued. Examples of mechanisms
+ implementing this facility include the encrypted timestamp facility,
+ defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
+ Mechanisms that provide this facility are expected to mark the client
+ as authenticated.
+
+ Mechanisms implementing this facility SHOULD require the client to
+ prove knowledge of the reply key before transmitting a successful KDC
+ reply. Otherwise, an attacker can intercept the pre-authentication
+ exchange and get a reply to attack. One way of proving the client
+ knows the reply key is to implement the Replace Reply Key facility
+ along with this facility. The Public Key Cryptography for Initial
+ Authentication in Kerberos (PKINIT) mechanism [RFC4556] implements
+ Client Authentication alongside Replace Reply Key.
+
+ If the reply key has been replaced, then mechanisms such as
+ encrypted-timestamp that rely on knowledge of the reply key to
+ authenticate the client MUST NOT be used.
+
+3.2. Strengthening Reply Key Facility
+
+ Particularly when dealing with keys based on passwords, it is
+ desirable to increase the strength of the key by adding additional
+ secrets to it. Examples of sources of additional secrets include the
+ results of a Diffie-Hellman key exchange or key bits from the output
+ of a smart card [KRB-WG.SAM]. Typically, these additional secrets
+ can be first combined with the existing reply key and then converted
+ to a protocol key using tools defined in Section 5.1.
+
+ Typically, a mechanism implementing this facility will know that the
+ other side of the exchange supports the facility before the reply key
+ is changed. For example, a mechanism might need to learn the
+ certificate for a KDC before encrypting a new key in the public key
+ belonging to that certificate. However, if a mechanism implementing
+ this facility wishes to modify the reply key before knowing that the
+ other party in the exchange supports the mechanism, it proposes
+ modifying the reply key. The other party then includes a message
+ indicating that the proposal is accepted if it is understood and
+
+
+
+Hartman & Zhu Standards Track [Page 13]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ meets policy. In many cases, it is desirable to use the new reply
+ key for client authentication and for other facilities. Waiting for
+ the other party to accept the proposal and actually modify the reply
+ key state would add an additional round trip to the exchange.
+ Instead, mechanism designers are encouraged to include a typed hole
+ for additional padata in the message that proposes the reply key
+ change. The padata included in the typed hole are generated assuming
+ the new reply key. If the other party accepts the proposal, then
+ these padata are considered as an inner level. As with the outer
+ level, one authentication set or mechanism is typically chosen for
+ client authentication, along with auxiliary mechanisms such as KDC
+ cookies, and other mechanisms are ignored. When mechanisms include
+ such a container, the hint provided for use in authentication sets
+ (as defined in Section 5.3) MUST contain a sequence of inner
+ mechanisms along with hints for those mechanisms. The party
+ generating the proposal can determine whether the padata were
+ processed based on whether the proposal for the reply key is
+ accepted.
+
+ The specific formats of the proposal message, including where padata
+ are included, is a matter for the mechanism specification.
+ Similarly, the format of the message accepting the proposal is
+ mechanism specific.
+
+ Mechanisms implementing this facility and including a typed hole for
+ additional padata MUST checksum that padata using a keyed checksum or
+ encrypt the padata. This requirement protects against modification
+ of the contents of the typed hole. By modifying these contents, an
+ attacker might be able to choose which mechanism is used to
+ authenticate the client, or to convince a party to provide text
+ encrypted in a key that the attacker had manipulated. It is
+ important that mechanisms strengthen the reply key enough that using
+ it to checksum padata is appropriate.
+
+3.3. Replace Reply Key Facility
+
+ The Replace Reply Key facility replaces the key in which a successful
+ AS reply will be encrypted. This facility can only be used in cases
+ where knowledge of the reply key is not used to authenticate the
+ client. The new reply key MUST be communicated to the client and the
+ KDC in a secure manner. This facility MUST NOT be used if there can
+ be a man-in-the-middle between the client and the KDC. Mechanisms
+ implementing this facility MUST mark the reply key as replaced in the
+ pre-authentication state. Mechanisms implementing this facility MUST
+ either provide a mechanism to verify the KDC reply to the client or
+ mark the reply as unverified in the pre-authentication state.
+ Mechanisms implementing this facility SHOULD NOT be used if a
+ previous mechanism has used the reply key.
+
+
+
+Hartman & Zhu Standards Track [Page 14]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ As with the Strengthening Reply Key facility, Kerberos extensibility
+ rules require that the reply key not be changed unless both sides of
+ the exchange understand the extension. In the case of this facility,
+ it will likely be the case for both sides to know that the facility
+ is available by the time that the new key is available to be used.
+ However, mechanism designers can use a container for padata in a
+ proposal message, as discussed in Section 3.2, if appropriate.
+
+3.4. KDC Authentication Facility
+
+ This facility verifies that the reply comes from the expected KDC.
+ In traditional Kerberos, the KDC and the client share a key, so if
+ the KDC reply can be decrypted, then the client knows that a trusted
+ KDC responded. Note that the client machine cannot trust the client
+ unless the machine is presented with a service ticket for it
+ (typically, the machine can retrieve this ticket by itself).
+ However, if the reply key is replaced, some mechanism is required to
+ verify the KDC. Pre-authentication mechanisms providing this
+ facility allow a client to determine that the expected KDC has
+ responded even after the reply key is replaced. They mark the pre-
+ authentication state as having been verified.
+
+4. Requirements for Pre-Authentication Mechanisms
+
+ This section lists requirements for specifications of pre-
+ authentication mechanisms.
+
+ For each message in the pre-authentication mechanism, the
+ specification describes the pa-type value to be used and the contents
+ of the message. The processing of the message by the sender and
+ recipient is also specified. This specification needs to include all
+ modifications to the pre-authentication state.
+
+ Generally, mechanisms have a message that can be sent in the error
+ data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
+ authentication set. If the client needs information, such as trusted
+ certificate authorities, in order to determine if it can use the
+ mechanism, then this information should be in that message. In
+ addition, such mechanisms should also define a pa-hint to be included
+ in authentication sets. Often, the same information included in the
+ padata-value is appropriate to include in the pa-hint (as defined in
+ Section 5.3).
+
+ In order to ease security analysis, the mechanism specification
+ should describe what facilities from this document are offered by the
+ mechanism. For each facility, the security considerations section of
+ the mechanism specification should show that the security
+
+
+
+
+Hartman & Zhu Standards Track [Page 15]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ requirements of that facility are met. This requirement is
+ applicable to any FAST factor that provides authentication
+ information.
+
+ Significant problems have resulted in the specification of Kerberos
+ protocols because much of the KDC exchange is not protected against
+ alteration. The security considerations section should discuss
+ unauthenticated plaintext attacks. It should either show that
+ plaintext is protected or discuss what harm an attacker could do by
+ modifying the plaintext. It is generally acceptable for an attacker
+ to be able to cause the protocol negotiation to fail by modifying
+ plaintext. More significant attacks should be evaluated carefully.
+
+ As discussed in Section 5.2, there is no guarantee that a client will
+ use the same KDCs for all messages in a conversation. The mechanism
+ specification needs to show why the mechanism is secure in this
+ situation. The hardest problem to deal with, especially for
+ challenge/response mechanisms is to make sure that the same response
+ cannot be replayed against two KDCs while allowing the client to talk
+ to any KDC.
+
+4.1. Protecting Requests/Responses
+
+ Mechanism designers SHOULD protect cleartext portions of pre-
+ authentication data. Various denial-of-service attacks and downgrade
+ attacks against Kerberos are possible unless plaintexts are somehow
+ protected against modification. An early design goal of Kerberos
+ Version 5 [RFC4120] was to avoid encrypting more of the
+ authentication exchange than was required. (Version 4 doubly-
+ encrypted the encrypted part of a ticket in a KDC reply, for
+ example). This minimization of encryption reduces the load on the
+ KDC and busy servers. Also, during the initial design of Version 5,
+ the existence of legal restrictions on the export of cryptography
+ made it desirable to minimize of the number of uses of encryption in
+ the protocol. Unfortunately, performing this minimization created
+ numerous instances of unauthenticated security-relevant plaintext
+ fields.
+
+ Mechanisms MUST guarantee that by the end of a successful
+ authentication exchange, both the client and the KDC have verified
+ all the plaintext sent by the other party. If there is more than one
+ round trip in the exchange, mechanisms MUST additionally guarantee
+ that no individual messages were reordered or replayed from a
+ previous exchange. Strategies for accomplishing this include using
+ message authentication codes (MACs) to protect the plaintext as it is
+ sent including some form of nonce or cookie to allow for the chaining
+ of state from one message to the next or exchanging a MAC of the
+ entire conversation after a key is established.
+
+
+
+Hartman & Zhu Standards Track [Page 16]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ Mechanism designers need to provide a strategy for updating
+ cryptographic algorithms, such as defining a new pre-authentication
+ type for each algorithm or taking advantage of the client's list of
+ supported RFC 3961 encryption types to indicate the client's support
+ for cryptographic algorithms.
+
+ Primitives defined in [RFC3961] are RECOMMENDED for integrity
+ protection and confidentiality. Mechanisms based on these primitives
+ are crypto-agile as the result of using [RFC3961] along with
+ [RFC4120]. The advantage afforded by crypto-agility is the ability
+ to incrementally deploy a fix specific to a particular algorithm thus
+ avoid a multi-year standardization and deployment cycle, when real
+ attacks do arise against that algorithm.
+
+ Note that data used by FAST factors (defined in Section 5.4) is
+ encrypted in a protected channel; thus, they do not share the un-
+ authenticated-text issues with mechanisms designed as full-blown pre-
+ authentication mechanisms.
+
+5. Tools for Use in Pre-Authentication Mechanisms
+
+ This section describes common tools needed by multiple pre-
+ authentication mechanisms. By using these tools, mechanism designers
+ can use a modular approach to specify mechanism details and ease
+ security analysis.
+
+5.1. Combining Keys
+
+ Frequently, a weak key needs to be combined with a stronger key
+ before use. For example, passwords are typically limited in size and
+ insufficiently random: therefore, it is desirable to increase the
+ strength of the keys based on passwords by adding additional secrets.
+ An additional source of secrecy may come from hardware tokens.
+
+ This section provides standard ways to combine two keys into one.
+
+ KRB-FX-CF1() is defined to combine two passphrases.
+
+ KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
+ KRB-FX-CF1(x, y) := x || y
+
+ Where || denotes concatenation. The strength of the final key is
+ roughly the total strength of the individual keys being combined,
+ assuming that the string_to_key() function [RFC3961] uses all its
+ input evenly.
+
+
+
+
+
+
+Hartman & Zhu Standards Track [Page 17]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ An example usage of KRB-FX-CF1() is when a device provides random but
+ short passwords, the password is often combined with a personal
+ identification number (PIN). The password and the PIN can be
+ combined using KRB-FX-CF1().
+
+ KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
+ function defined in [RFC3961].
+
+ Given two input keys, K1 and K2, where K1 and K2 can be of two
+ different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
+ follows:
+
+ KRB-FX-CF2(protocol key, protocol key, octet string,
+ octet string) -> (protocol key)
+
+ PRF+(K1, pepper1) -> octet-string-1
+ PRF+(K2, pepper2) -> octet-string-2
+ KRB-FX-CF2(K1, K2, pepper1, pepper2) :=
+ random-to-key(octet-string-1 ^ octet-string-2)
+
+ Where ^ denotes the exclusive-OR operation. PRF+() is defined as
+ follows:
+
+ PRF+(protocol key, octet string) -> (octet string)
+
+ PRF+(key, shared-info) := pseudo-random( key, 1 || shared-info ) ||
+ pseudo-random( key, 2 || shared-info ) ||
+ pseudo-random( key, 3 || shared-info ) || ...
+
+ Here the counter value 1, 2, 3, and so on are encoded as a one-octet
+ integer. The pseudo-random() operation is specified by the enctype
+ of the protocol key. PRF+() uses the counter to generate enough bits
+ as needed by the random-to-key() [RFC3961] function for the
+ encryption type specified for the resulting key; unneeded bits are
+ removed from the tail. Unless otherwise specified, the resulting
+ enctype of KRB-FX-CF2 is the enctype of k1. The pseudo-random()
+ operation is the RFC 3961 pseudo-random() operation for the
+ corresponding input key; the random-to-key() operation is the RFC
+ 3961 random-to-key operation for the resulting key.
+
+ Mechanism designers MUST specify the values for the input parameter
+ pepper1 and pepper2 when combining two keys using KRB-FX-CF2(). The
+ pepper1 and pepper2 MUST be distinct so that if the two keys being
+ combined are the same, the resulting key is not a trivial key.
+
+
+
+
+
+
+
+Hartman & Zhu Standards Track [Page 18]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+5.2. Managing States for the KDC
+
+ Kerberos KDCs are stateless in that there is no requirement that
+ clients will choose the same KDC for the second request in a
+ conversation. Proxies or other intermediate nodes may also influence
+ KDC selection. So, each request from a client to a KDC must include
+ sufficient information that the KDC can regenerate any needed state.
+ This is accomplished by giving the client a potentially long opaque
+ cookie in responses to include in future requests in the same
+ conversation. The KDC MAY respond that a conversation is too old and
+ needs to restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.
+
+ KDC_ERR_PREAUTH_EXPIRED 90
+
+ When a client receives this error, the client SHOULD abort the
+ existing conversation, and restart a new one.
+
+ An example, where more than one message from the client is needed, is
+ when the client is authenticated based on a challenge/response
+ scheme. In that case, the KDC needs to keep track of the challenge
+ issued for a client authentication request.
+
+ The PA-FX-COOKIE padata type is defined in this section to facilitate
+ state management in the AS exchange. These padata are sent by the
+ KDC when the KDC requires state for a future transaction. The client
+ includes this opaque token in the next message in the conversation.
+ The token may be relatively large; clients MUST be prepared for
+ tokens somewhat larger than the size of all messages in a
+ conversation.
+
+ PA-FX-COOKIE 133
+ -- Stateless cookie that is not tied to a specific KDC.
+
+ The corresponding padata-value field [RFC4120] contains an opaque
+ token that will be echoed by the client in its response to an error
+ from the KDC.
+
+ The cookie token is generated by the KDC and transmitted in a PA-FX-
+ COOKIE pre-authentication data item of a KRB-ERROR message. The
+ client MUST copy the exact cookie encapsulated in a PA-FX-COOKIE data
+ element into the next message of the same conversation. The content
+ of the cookie field is a local matter of the KDC. As a result, it is
+ not generally possible to mix KDC implementations from different
+ vendors in the same realm. However, the KDC MUST construct the
+ cookie token in such a manner that a malicious client cannot subvert
+ the authentication process by manipulating the token. The KDC
+ implementation needs to consider expiration of tokens, key rollover,
+ and other security issues in token design. The content of the cookie
+
+
+
+Hartman & Zhu Standards Track [Page 19]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ field is likely specific to the pre-authentication mechanisms used to
+ authenticate the client. If a client authentication response can be
+ replayed to multiple KDCs via the PA-FX-COOKIE mechanism, an
+ expiration in the cookie is RECOMMENDED to prevent the response being
+ presented indefinitely. Implementations need to consider replay both
+ of an entire conversation and of messages within a conversation when
+ designing what information is stored in a cookie and how pre-
+ authentication mechanisms are implemented.
+
+ If at least one more message for a mechanism or a mechanism set is
+ expected by the KDC, the KDC returns a
+ KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error with a PA-FX-COOKIE to
+ identify the conversation with the client, according to Section 2.2.
+ The cookie is not expected to stay constant for a conversation: the
+ KDC is expected to generate a new cookie for each message.
+
+ KDC_ERR_MORE_PREAUTH_DATA_REQUIRED 91
+
+ A client MAY throw away the state associated with a conversation and
+ begin a new conversation by discarding its state and not including a
+ cookie in the first message of a conversation. KDCs that comply with
+ this specification MUST include a cookie in a response when the
+ client can continue the conversation. In particular, a KDC MUST
+ include a cookie in a KDC_ERR_PREAUTH_REQUIRED or
+ KDC_ERR_MORE_PREAUTH_DATA_REQUIRED. KDCs SHOULD include a cookie in
+ errors containing additional information allowing a client to retry.
+ One reasonable strategy for meeting these requirements is to always
+ include a cookie in KDC errors.
+
+ A KDC MAY indicate that it is terminating a conversation by not
+ including a cookie in a response. When FAST is used, clients can
+ assume that the absence of a cookie means that the KDC is ending the
+ conversation. Similarly, if a cookie is seen at all during a
+ conversation, clients MAY assume that the absence of a cookie in a
+ future message means that the KDC is ending the conversation.
+ Clients also need to deal with KDCs, prior to this specification,
+ that do not include cookies; if neither cookies nor FAST are used in
+ a conversation, the absence of a cookie is not a strong indication
+ that the KDC is terminating the conversation.
+
+5.3. Pre-Authentication Set
+
+ If all mechanisms in a group need to successfully complete in order
+ to authenticate a client, the client and the KDC SHOULD use the PA-
+ AUTHENTICATION-SET padata element.
+
+ PA-AUTHENTICATION-SET 134
+
+
+
+
+Hartman & Zhu Standards Track [Page 20]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ A PA-AUTHENTICATION-SET padata element contains the ASN.1 DER
+ encoding of the PA-AUTHENTICATION-SET structure:
+
+ PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+ PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+ pa-type [0] Int32,
+ -- same as padata-type.
+ pa-hint [1] OCTET STRING OPTIONAL,
+ pa-value [2] OCTET STRING OPTIONAL,
+ ...
+ }
+
+ The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
+ contains the corresponding value of padata-type in PA-DATA [RFC4120].
+ Associated with the pa-type is a pa-hint, which is an octet string
+ specified by the pre-authentication mechanism. This hint may provide
+ information for the client that helps it determine whether the
+ mechanism can be used. For example, a public-key mechanism might
+ include the certificate authorities it trusts in the hint info. Most
+ mechanisms today do not specify hint info; if a mechanism does not
+ specify hint info, the KDC MUST NOT send a hint for that mechanism.
+ To allow future revisions of mechanism specifications to add hint
+ info, clients MUST ignore hint info received for mechanisms that the
+ client believes do not support hint info. The pa-value element of
+ the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the
+ first padata-value from the KDC to the client. If the client chooses
+ this authentication set, then the client MUST process this pa-value.
+ The pa-value element MUST be absent for all but the first entry in
+ the authentication set. Clients MUST ignore the pa-value for the
+ second and following entries in the authentication set.
+
+ If the client chooses an authentication set, then its first AS-REQ
+ message MUST contain a PA-AUTH-SET-SELECTED padata element. This
+ element contains the encoding of the PA-AUTHENTICATION-SET sequence
+ received from the KDC corresponding to the authentication set that is
+ chosen. The client MUST use the same octet values received from the
+ KDC; it cannot re-encode the sequence. This allows KDCs to use bit-
+ wise comparison to identify the selected authentication set.
+ Permitting bit-wise comparison may limit the ability to use certain
+ pre-authentication mechanisms that generate a dynamic challenge in an
+ authentication set with optimistic selection of an authentication
+ set. As with other optimistic pre-authentication failures, the KDC
+ MAY return KDC_ERR_PREAUTH_FAILED with a new list of pre-
+ authentication mechanisms (including authentication sets) if
+ optimistic pre-authentication fails. The PA-AUTH-SET-SELECTED padata
+ element MUST come before any padata elements from the authentication
+ set in the padata sequence in the AS-REQ message. The client MAY
+
+
+
+Hartman & Zhu Standards Track [Page 21]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ cache authentication sets from prior messages and use them to
+ construct an optimistic initial AS-REQ. If the KDC receives a PA-
+ AUTH-SET-SELECTED padata element that does not correspond to an
+ authentication set that it would offer, then the KDC returns the
+ KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error. The e-data in this
+ error contains a sequence of padata just as for the
+ KDC_ERR_PREAUTH_REQUIRED error.
+
+ PA-AUTH-SET-SELECTED 135
+ KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92
+
+ The PA-AUTHENTICATION-SET appears only in the first message from the
+ KDC to the client. In particular, the client MAY fail if the
+ authentication mechanism sets change as the conversation progresses.
+ Clients MAY assume that the hints provided in the authentication set
+ contain enough information that the client knows what user interface
+ elements need to be displayed during the entire authentication
+ conversation. Exceptional circumstances, such as expired passwords
+ or expired accounts, may require that additional user interface be
+ displayed. Mechanism designers need to carefully consider the design
+ of their hints so that the client has this information. This way,
+ clients can construct necessary dialogue boxes or wizards based on
+ the authentication set and can present a coherent user interface.
+ Current standards for user interfaces do not provide an acceptable
+ experience when the client has to ask additional questions later in
+ the conversation.
+
+ When indicating which sets of pre-authentication mechanisms are
+ supported, the KDC includes a PA-AUTHENTICATION-SET padata element
+ for each pre-authentication mechanism set.
+
+ The client sends the padata-value for the first mechanism it picks in
+ the pre-authentication set, when the first mechanism completes, the
+ client and the KDC will proceed with the second mechanism, and so on
+ until all mechanisms complete successfully. The PA-FX-COOKIE, as
+ defined in Section 5.2, MUST be sent by the KDC. One reason for this
+ requirement is so that the conversation can continue if the
+ conversation involves multiple KDCs. KDCs MUST support clients that
+ do not include a cookie because they optimistically choose an
+ authentication set, although they MAY always return a
+ KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET and include a cookie in that
+ message. Clients that support PA-AUTHENTICATION-SET MUST support PA-
+ FX-COOKIE.
+
+ Before the authentication succeeds and a ticket is returned, the
+ message that the client sends is an AS-REQ and the message that the
+ KDC sends is a KRB-ERROR message. The error code in the KRB-ERROR
+ message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_REQUIRED as defined
+
+
+
+Hartman & Zhu Standards Track [Page 22]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ in Section 5.2 and the accompanying e-data contains the DER encoding
+ of ASN.1 type METHOD-DATA. The KDC includes the padata elements in
+ the METHOD-DATA. If there are no padata, the e-data field is absent
+ in the KRB-ERROR message.
+
+ If the client sends the last message for a given mechanism, then the
+ KDC sends the first message for the next mechanism. If the next
+ mechanism does not start with a KDC-side challenge, then the KDC
+ includes a padata item with the appropriate pa-type and an empty pa-
+ data.
+
+ If the KDC sends the last message for a particular mechanism, the KDC
+ also includes the first padata for the next mechanism.
+
+5.4. Definition of Kerberos FAST Padata
+
+ As described in [RFC4120], Kerberos is vulnerable to offline
+ dictionary attacks. An attacker can request an AS-REP and try
+ various passwords to see if they can decrypt the resulting ticket.
+ RFC 4120 provides the encrypted timestamp pre-authentication method
+ that ameliorates the situation somewhat by requiring that an attacker
+ observe a successful authentication. However, stronger security is
+ desired in many environments. The Kerberos FAST pre-authentication
+ padata defined in this section provides a tool to significantly
+ reduce vulnerability to offline dictionary attacks. When combined
+ with encrypted challenge, FAST requires an attacker to mount a
+ successful man-in-the-middle attack to observe ciphertext. When
+ combined with host keys, FAST can even protect against active
+ attacks. FAST also provides solutions to common problems for pre-
+ authentication mechanisms such as binding of the request and the
+ reply and freshness guarantee of the authentication. FAST itself,
+ however, does not authenticate the client or the KDC; instead, it
+ provides a typed hole to allow pre-authentication data be tunneled.
+ A pre-authentication data element used within FAST is called a "FAST
+ factor". A FAST factor captures the minimal work required for
+ extending Kerberos to support a new pre-authentication scheme.
+
+ A FAST factor MUST NOT be used outside of FAST unless its
+ specification explicitly allows so. The typed holes in FAST messages
+ can also be used as generic holes for other padata that are not
+ intended to prove the client's identity, or establish the reply key.
+
+ New pre-authentication mechanisms SHOULD be designed as FAST factors,
+ instead of full-blown pre-authentication mechanisms.
+
+ FAST factors that are pre-authentication mechanisms MUST meet the
+ requirements in Section 4.
+
+
+
+
+Hartman & Zhu Standards Track [Page 23]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ FAST employs an armoring scheme. The armor can be a Ticket Granting
+ Ticket (TGT) obtained by the client's machine using the host keys to
+ pre-authenticate with the KDC, or an anonymous TGT obtained based on
+ anonymous PKINIT [RFC6112] [RFC4556].
+
+ The rest of this section describes the types of armors and the syntax
+ of the messages used by FAST. Conforming implementations MUST
+ support Kerberos FAST padata.
+
+ Any FAST armor scheme MUST provide a fresh armor key for each
+ conversation. Clients and KDCs can assume that if a message is
+ encrypted and integrity protected with a given armor key, then it is
+ part of the conversation using that armor key.
+
+ All KDCs in a realm MUST support FAST if FAST is offered by any KDC
+ as a pre-authentication mechanism.
+
+5.4.1. FAST Armors
+
+ An armor key is used to encrypt pre-authentication data in the FAST
+ request and the response. The KrbFastArmor structure is defined to
+ identify the armor key. This structure contains the following two
+ fields: the armor-type identifies the type of armors and the armor-
+ value is an OCTET STRING that contains the description of the armor
+ scheme and the armor key.
+
+ KrbFastArmor ::= SEQUENCE {
+ armor-type [0] Int32,
+ -- Type of the armor.
+ armor-value [1] OCTET STRING,
+ -- Value of the armor.
+ ...
+ }
+
+ The value of the armor key is a matter of the armor type
+ specification. Only one armor type is defined in this document.
+
+ FX_FAST_ARMOR_AP_REQUEST 1
+
+ The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.
+
+ Conforming implementations MUST implement the
+ FX_FAST_ARMOR_AP_REQUEST armor type. If a FAST KDC receives an
+ unknown armor type it MUST respond with KDC_ERR_PREAUTH_FAILED.
+
+ An armor type may be appropriate for use in armoring AS requests,
+ armoring TGS requests, or both. TGS armor types MUST authenticate
+ the client to the KDC, typically by binding the TGT sub-session key
+
+
+
+Hartman & Zhu Standards Track [Page 24]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ to the armor key. As discussed below, it is desirable for AS armor
+ types to authenticate the KDC to the client, but this is not
+ required.
+
+ FAST implementations MUST maintain state about whether the armor
+ mechanism authenticates the KDC. If it does not, then a FAST factor
+ that authenticates the KDC MUST be used if the reply key is replaced.
+
+5.4.1.1. Ticket-Based Armors
+
+ This is a ticket-based armoring scheme. The armor-type is
+ FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER
+ encoded AP-REQ. The ticket in the AP-REQ is called an armor ticket
+ or an armor TGT. The subkey field in the AP-REQ MUST be present.
+ The armor key is defined by the following function:
+
+ armor_key = KRB-FX-CF2( subkey, ticket_session_key,
+ "subkeyarmor", "ticketarmor" )
+
+ The 'ticket_session_key' is the session key from the ticket in the
+ ap-req. The 'subkey' is the ap-req subkey. This construction
+ guarantees that both the KDC (through the session key) and the client
+ (through the subkey) contribute to the armor key.
+
+ The server name field of the armor ticket MUST identify the TGS of
+ the target realm. Here are three common ways in the decreasing
+ preference order how an armor TGT SHOULD be obtained:
+
+ 1. If the client is authenticating from a host machine whose
+ Kerberos realm has an authentication path to the client's realm,
+ the host machine obtains a TGT by using the host keys. If the
+ client's realm is different than the realm of the local host, the
+ machine then obtains a cross-realm TGT to the client's realm as
+ the armor ticket. Otherwise, the host's primary TGT is the armor
+ ticket.
+
+ 2. If the client's host machine cannot obtain a host ticket strictly
+ based on RFC 4120, but the KDC has an asymmetric signing key
+ whose binding with the expected KDC can be verified by the
+ client, the client can use anonymous PKINIT [RFC6112] [RFC4556]
+ to authenticate the KDC and obtain an anonymous TGT as the armor
+ ticket. The armor ticket can also be a cross-realm TGT obtained
+ based on the initial primary TGT obtained using anonymous PKINIT
+ with KDC authentication.
+
+ 3. Otherwise, the client uses anonymous PKINIT to get an anonymous
+ TGT without KDC authentication and that TGT is the armor ticket.
+ Note that this mode of operation is vulnerable to man-in-the-
+
+
+
+Hartman & Zhu Standards Track [Page 25]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ middle attacks at the time of obtaining the initial anonymous
+ armor TGT.
+
+ If anonymous PKINIT is used to obtain the armor ticket, the KDC
+ cannot know whether its signing key can be verified by the client;
+ hence, the KDC MUST be marked as unverified from the KDC's point of
+ view while the client could be able to authenticate the KDC by
+ verifying the KDC's signing key is bound with the expected KDC. The
+ client needs to carefully consider the risk and benefit tradeoffs
+ associated with active attacks before exposing cipher text encrypted
+ using the user's long-term secrets when the armor does not
+ authenticate the KDC.
+
+ The TGS MUST reject a request if there is an AD-fx-fast-armor (71)
+ element in the authenticator of the pa-tgs-req padata or if the
+ ticket in the authenticator of a pa-tgs-req contains the AD-fx-fast-
+ armor authorization data element. These tickets and authenticators
+ MAY be used as FAST armor tickets but not to obtain a ticket via the
+ TGS. This authorization data is used in a system where the
+ encryption of the user's pre-authentication data is performed in an
+ unprivileged user process. A privileged process can provide to the
+ user process a host ticket, an authenticator for use with that
+ ticket, and the sub-session key contained in the authenticator. In
+ order for the host process to ensure that the host ticket is not
+ accidentally or intentionally misused, (i.e., the user process might
+ use the host ticket to authenticate as the host), it MUST include a
+ critical authorization data element of the type AD-fx-fast-armor when
+ providing the authenticator or in the enc-authorization-data field of
+ the TGS request used to obtain the TGT. The corresponding ad-data
+ field of the AD-fx-fast-armor element is empty.
+
+ This armor type is only valid for AS requests; implicit armor,
+ described below in TGS processing, is the only supported way to
+ establish an armor key for the TGS at this time.
+
+5.4.2. FAST Request
+
+ A padata type PA-FX-FAST is defined for the Kerberos FAST pre-
+ authentication padata. The corresponding padata-value field
+ [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
+ REQUEST. As with all pre-authentication types, the KDC SHOULD
+ advertise PA-FX-FAST in a PREAUTH_REQUIRED error. KDCs MUST send the
+ advertisement of PA-FX-FAST with an empty pa-value. Clients MUST
+ ignore the pa-value of PA-FX-FAST in an initial PREAUTH_REQUIRED
+ error. FAST is not expected to be used in an authentication set:
+ clients will typically use FAST padata if available and this decision
+ should not depend on what other pre-authentication methods are
+ available. As such, no pa-hint is defined for FAST at this time.
+
+
+
+Hartman & Zhu Standards Track [Page 26]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ PA-FX-FAST 136
+ -- Padata type for Kerberos FAST
+
+ PA-FX-FAST-REQUEST ::= CHOICE {
+ armored-data [0] KrbFastArmoredReq,
+ ...
+ }
+
+ KrbFastArmoredReq ::= SEQUENCE {
+ armor [0] KrbFastArmor OPTIONAL,
+ -- Contains the armor that identifies the armor key.
+ -- MUST be present in AS-REQ.
+ req-checksum [1] Checksum,
+ -- For AS, contains the checksum performed over the type
+ -- KDC-REQ-BODY for the req-body field of the KDC-REQ
+ -- structure;
+ -- For TGS, contains the checksum performed over the type
+ -- AP-REQ in the PA-TGS-REQ padata.
+ -- The checksum key is the armor key, the checksum
+ -- type is the required checksum type for the enctype of
+ -- the armor key, and the key usage number is
+ -- KEY_USAGE_FAST_REQ_CHKSUM.
+ enc-fast-req [2] EncryptedData, -- KrbFastReq --
+ -- The encryption key is the armor key, and the key usage
+ -- number is KEY_USAGE_FAST_ENC.
+ ...
+ }
+
+ KEY_USAGE_FAST_REQ_CHKSUM 50
+ KEY_USAGE_FAST_ENC 51
+
+ The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.
+ The KrbFastArmoredReq encapsulates the encrypted padata.
+
+ The enc-fast-req field contains an encrypted KrbFastReq structure.
+ The armor key is used to encrypt the KrbFastReq structure, and the
+ key usage number for that encryption is KEY_USAGE_FAST_ENC.
+
+ The armor key is selected as follows:
+
+ o In an AS request, the armor field in the KrbFastArmoredReq
+ structure MUST be present and the armor key is identified
+ according to the specification of the armor type.
+
+
+
+
+
+
+
+
+Hartman & Zhu Standards Track [Page 27]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ o There are two possibilities for armor for a TGS request. If the
+ ticket presented in the PA-TGS-REQ authenticator is a TGT, then
+ the client SHOULD NOT include the armor field in the Krbfastreq
+ and a subkey MUST be included in the PA-TGS-REQ authenticator. In
+ this case, the armor key is the same armor key that would be
+ computed if the TGS-REQ authenticator was used in an
+ FX_FAST_ARMOR_AP_REQUEST armor. Clients MAY present a non-TGT in
+ the PA-TGS-REQ authenticator and omit the armor field, in which
+ case the armor key is the same that would be computed if the
+ authenticator were used in an FX_FAST_ARMOR_AP_REQUEST armor.
+ This is the only case where a ticket other than a TGT can be used
+ to establish an armor key; even though the armor key is computed
+ the same as an FX_FAST_ARMOR_AP_REQUEST, a non-TGT cannot be used
+ as an armor ticket in FX_FAST_ARMOR_AP_REQUEST. Alternatively, a
+ client MAY use an armor type defined in the future for use with
+ the TGS request.
+
+ The req-checksum field contains a checksum computed differently for
+ AS and TGS. For an AS-REQ, it is performed over the type KDC-REQ-
+ BODY for the req-body field of the KDC-REQ structure of the
+ containing message; for a TGS-REQ, it is performed over the type AP-
+ REQ in the PA-TGS-REQ padata of the TGS request. The checksum key is
+ the armor key, and the checksum type is the required checksum type
+ for the enctype of the armor key per [RFC3961]. This checksum MUST
+ be a keyed checksum and it is included in order to bind the FAST
+ padata to the outer request. A KDC that implements FAST will ignore
+ the outer request, but including a checksum is relatively cheap and
+ may prevent confusing behavior.
+
+ The KrbFastReq structure contains the following information:
+
+ KrbFastReq ::= SEQUENCE {
+ fast-options [0] FastOptions,
+ -- Additional options.
+ padata [1] SEQUENCE OF PA-DATA,
+ -- padata typed holes.
+ req-body [2] KDC-REQ-BODY,
+ -- Contains the KDC request body as defined in Section
+ -- 5.4.1 of [RFC4120].
+ -- This req-body field is preferred over the outer field
+ -- in the KDC request.
+ ...
+ }
+
+
+
+
+
+
+
+
+Hartman & Zhu Standards Track [Page 28]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ The fast-options field indicates various options that are to modify
+ the behavior of the KDC. The following options are defined:
+
+ FastOptions ::= KerberosFlags
+ -- reserved(0),
+ -- hide-client-names(1),
+
+ Bits Name Description
+ -----------------------------------------------------------------
+ 0 RESERVED Reserved for future expansion of this
+ field.
+ 1 hide-client-names Requesting the KDC to hide client
+ names in the KDC response, as
+ described next in this section.
+ 16 kdc-follow-referrals reserved [REFERRALS].
+
+ Bits 1 through 15 inclusive (with bit 1 and bit 15 included) are
+ critical options. If the KDC does not support a critical option, it
+ MUST fail the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS, and
+ there is no accompanying e-data defined in this document for this
+ error code. Bit 16 and onward (with bit 16 included) are non-
+ critical options. KDCs conforming to this specification ignore
+ unknown non-critical options.
+
+ KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS 93
+
+ The hide-client-names Option
+
+ The Kerberos response defined in [RFC4120] contains the client
+ identity in cleartext. This makes traffic analysis
+ straightforward. The hide-client-names option is designed to
+ complicate traffic analysis. If the hide-client-names option is
+ set, the KDC implementing PA-FX-FAST MUST identify the client as
+ the anonymous principal [RFC6112] in the KDC reply and the error
+ response. Hence, this option is set by the client if it wishes to
+ conceal the client identity in the KDC response. A conforming KDC
+ ignores the client principal name in the outer KDC-REQ-BODY field,
+ and identifies the client using the cname and crealm fields in the
+ req-body field of the KrbFastReq structure.
+
+ The kdc-follow-referrals Option
+
+ This option is reserved for [REFERRALS].
+
+
+
+
+
+
+
+
+Hartman & Zhu Standards Track [Page 29]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ The padata field contains a list of PA-DATA structures as described
+ in Section 5.2.7 of [RFC4120]. These PA-DATA structures can contain
+ FAST factors. They can also be used as generic typed-holes to
+ contain data not intended for proving the client's identity or
+ establishing a reply key, but for protocol extensibility. If the KDC
+ supports the PA-FX-FAST-REQUEST padata, unless otherwise specified,
+ the client MUST place any padata that is otherwise in the outer KDC
+ request body into this field. In a TGS request, PA-TGS-REQ padata is
+ not included in this field and it is present in the outer KDC request
+ body.
+
+ The KDC-REQ-BODY in the FAST structure is used in preference to the
+ KDC-REQ-BODY outside of the FAST pre-authentication. The outer KDC-
+ REQ-BODY structure SHOULD be filled in for backwards compatibility
+ with KDCs that do not support FAST. A conforming KDC ignores the
+ outer KDC-REQ-BODY field in the KDC request. Pre-authentication data
+ methods such as [RFC4556] that include a checksum of the KDC-REQ-BODY
+ should checksum the KDC-REQ-BODY in the FAST structure.
+
+ In a TGS request, a client MAY include the AD-fx-fast-used authdata
+ either in the pa-tgs-req authenticator or in the authorization data
+ in the pa-tgs-req ticket. If the KDC receives this authorization
+ data but does not find a FAST padata, then it MUST return
+ KRB_APP_ERR_MODIFIED.
+
+5.4.3. FAST Response
+
+ The KDC that supports the PA-FX-FAST padata MUST include a PA-FX-FAST
+ padata element in the KDC reply. In the case of an error, the PA-FX-
+ FAST padata is included in the KDC responses according to
+ Section 5.4.4.
+
+ The corresponding padata-value field [RFC4120] for the PA-FX-FAST in
+ the KDC response contains the DER encoding of the ASN.1 type PA-FX-
+ FAST-REPLY.
+
+ PA-FX-FAST-REPLY ::= CHOICE {
+ armored-data [0] KrbFastArmoredRep,
+ ...
+ }
+
+ KrbFastArmoredRep ::= SEQUENCE {
+ enc-fast-rep [0] EncryptedData, -- KrbFastResponse --
+ -- The encryption key is the armor key in the request, and
+ -- the key usage number is KEY_USAGE_FAST_REP.
+ ...
+ }
+ KEY_USAGE_FAST_REP 52
+
+
+
+Hartman & Zhu Standards Track [Page 30]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
+ structure. The KrbFastArmoredRep structure encapsulates the padata
+ in the KDC reply in the encrypted form. The KrbFastResponse is
+ encrypted with the armor key used in the corresponding request, and
+ the key usage number is KEY_USAGE_FAST_REP.
+
+ The Kerberos client MUST support a local policy that rejects the
+ response if PA-FX-FAST-REPLY is not included in the response.
+ Clients MAY also support policies that fall back to other mechanisms
+ or that do not use pre-authentication when FAST is unavailable. It
+ is important to consider the potential downgrade attacks when
+ deploying such a policy.
+
+ The KrbFastResponse structure contains the following information:
+
+ KrbFastResponse ::= SEQUENCE {
+ padata [0] SEQUENCE OF PA-DATA,
+ -- padata typed holes.
+ strengthen-key [1] EncryptionKey OPTIONAL,
+ -- This, if present, strengthens the reply key for AS and
+ -- TGS. MUST be present for TGS.
+ -- MUST be absent in KRB-ERROR.
+ finished [2] KrbFastFinished OPTIONAL,
+ -- Present in AS or TGS reply; absent otherwise.
+ nonce [3] UInt32,
+ -- Nonce from the client request.
+ ...
+ }
+
+ The padata field in the KrbFastResponse structure contains a list of
+ PA-DATA structures as described in Section 5.2.7 of [RFC4120]. These
+ PA-DATA structures are used to carry data advancing the exchange
+ specific for the FAST factors. They can also be used as generic
+ typed-holes for protocol extensibility. Unless otherwise specified,
+ the KDC MUST include any padata that are otherwise in the outer KDC-
+ REP or KDC-ERROR structure into this field. The padata field in the
+ KDC reply structure outside of the PA-FX-FAST-REPLY structure
+ typically includes only the PA-FX-FAST-REPLY padata.
+
+ The strengthen-key field provides a mechanism for the KDC to
+ strengthen the reply key. If set, the strengthen-key value MUST be
+ randomly generated to have the same etype as that of the reply key
+ before being strengthened, and then the reply key is strengthened
+ after all padata items are processed. Let padata-reply-key be the
+ reply key after padata processing.
+
+ reply-key = KRB-FX-CF2(strengthen-key, padata-reply-key,
+ "strengthenkey", "replykey")
+
+
+
+Hartman & Zhu Standards Track [Page 31]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ The strengthen-key field MAY be set in an AS reply; it MUST be set in
+ a TGS reply; it must be absent in an error reply. The strengthen key
+ is required in a TGS reply so that an attacker cannot remove the FAST
+ PADATA from a TGS reply, causing the KDC to appear not to support
+ FAST.
+
+ The finished field contains a KrbFastFinished structure. It is
+ filled by the KDC in the final message in the conversation. This
+ field is present in an AS-REP or a TGS-REP when a ticket is returned,
+ and it is not present in an error reply.
+
+ The KrbFastFinished structure contains the following information:
+
+ KrbFastFinished ::= SEQUENCE {
+ timestamp [0] KerberosTime,
+ usec [1] Microseconds,
+ -- timestamp and usec represent the time on the KDC when
+ -- the reply was generated.
+ crealm [2] Realm,
+ cname [3] PrincipalName,
+ -- Contains the client realm and the client name.
+ ticket-checksum [4] Checksum,
+ -- checksum of the ticket in the KDC-REP using the armor
+ -- and the key usage is KEY_USAGE_FAST_FINISH.
+ -- The checksum type is the required checksum type
+ -- of the armor key.
+ ...
+ }
+ KEY_USAGE_FAST_FINISHED 53
+
+ The timestamp and usec fields represent the time on the KDC when the
+ reply ticket was generated, these fields have the same semantics as
+ the corresponding identically named fields in Section 5.6.1 of
+ [RFC4120]. The client MUST use the KDC's time in these fields
+ thereafter when using the returned ticket. The client need not
+ confirm that the timestamp returned is within allowable clock skew:
+ the armor key guarantees that the reply is fresh. The client MAY
+ trust the timestamp returned.
+
+ The cname and crealm fields identify the authenticated client. If
+ facilities described in [REFERRALS] are used, the authenticated
+ client may differ from the client in the FAST request.
+
+ The ticket-checksum is a checksum of the issued ticket. The checksum
+ key is the armor key, and the checksum type is the required checksum
+ type of the enctype of that key, and the key usage number is
+ KEY_USAGE_FAST_FINISHED.
+
+
+
+
+Hartman & Zhu Standards Track [Page 32]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ When FAST padata is included, the PA-FX-COOKIE padata as defined in
+ Section 5.2 MUST be included in the padata sequence in the
+ KrbFastResponse sequence if the KDC expects at least one more message
+ from the client in order to complete the authentication.
+
+ The nonce field in the KrbFastResponse contains the value of the
+ nonce field in the KDC-REQ of the corresponding client request and it
+ binds the KDC response with the client request. The client MUST
+ verify that this nonce value in the reply matches with that of the
+ request and reject the KDC reply otherwise. To prevent the response
+ from one message in a conversation from being replayed to a request
+ in another message, clients SHOULD use a new nonce for each message
+ in a conversation.
+
+5.4.4. Authenticated Kerberos Error Messages Using Kerberos FAST
+
+ If the Kerberos FAST padata was included in the request, unless
+ otherwise specified, the e-data field of the KRB-ERROR message
+ [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
+ [RFC4120] and a PA-FX-FAST is included in the METHOD-DATA. The KDC
+ MUST include all the padata elements such as PA-ETYPE-INFO2 and
+ padata elements that indicate acceptable pre-authentication
+ mechanisms [RFC4120] in the KrbFastResponse structure.
+
+ The KDC MUST also include a PA-FX-ERROR padata item in the
+ KRBFastResponse structure. The padata-value element of this sequence
+ is the ASN.1 DER encoding of the type KRB-ERROR. The e-data field
+ MUST be absent in the PA-FX-ERROR padata. All other fields should be
+ the same as the outer KRB-ERROR. The client ignores the outer error
+ and uses the combination of the padata in the KRBFastResponse and the
+ error information in the PA-FX-ERROR.
+
+ PA-FX-ERROR 137
+
+ If the Kerberos FAST padata is included in the request but not
+ included in the error reply, it is a matter of the local policy on
+ the client to accept the information in the error message without
+ integrity protection. However, the client SHOULD process the KDC
+ errors as the result of the KDC's inability to accept the AP_REQ
+ armor and potentially retry another request with a different armor
+ when applicable. The Kerberos client MAY process an error message
+ without a PA-FX-FAST-REPLY, if that is only intended to return better
+ error information to the application, typically for trouble-shooting
+ purposes.
+
+ In the cases where the e-data field of the KRB-ERROR message is
+ expected to carry a TYPED-DATA [RFC4120] element, that information
+ should be transmitted in a pa-data element within the KRBFastResponse
+
+
+
+Hartman & Zhu Standards Track [Page 33]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ structure. The padata-type is the same as the data-type would be in
+ the typed data element and the padata-value is the same as the data-
+ value. As discussed in Section 7, data-types and padata-types are
+ drawn from the same namespace. For example, the
+ TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR
+ message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE
+ [RFC4556].
+
+5.4.5. Outer and Inner Requests
+
+ Typically, a client will know that FAST is being used before a
+ request containing PA-FX-FAST is sent. So, the outer AS request
+ typically only includes one pa-data item: PA-FX-FAST. The client MAY
+ include additional pa-data, but the KDC MUST ignore the outer request
+ body and any padata besides PA-FX-FAST if and only if PA-FX-FAST is
+ processed. In the case of the TGS request, the outer request should
+ include PA-FX-FAST and PA-TGS-REQ.
+
+ When an AS generates a response, all padata besides PA-FX-FAST should
+ be included in PA-FX-FAST. The client MUST ignore other padata
+ outside of PA-FX-FAST.
+
+5.4.6. The Encrypted Challenge FAST Factor
+
+ The encrypted challenge FAST factor authenticates a client using the
+ client's long-term key. This factor works similarly to the encrypted
+ timestamp pre-authentication option described in [RFC4120]. The word
+ "challenge" is used instead of "timestamp" because while the
+ timestamp is used as an initial challenge, if the KDC and client do
+ not have synchronized time, then the KDC can provide updated time to
+ the client to use as a challenge. The client encrypts a structure
+ containing a timestamp in the challenge key. The challenge key used
+ by the client to send a message to the KDC is KRB-FX-
+ CF2(armor_key,long_term_key, "clientchallengearmor",
+ "challengelongterm"). The challenge key used by the KDC encrypting
+ to the client is KRB-FX-CF2(armor_key, long_term_key,
+ "kdcchallengearmor", "challengelongterm"). Because the armor key is
+ fresh and random, the challenge key is fresh and random. The only
+ purpose of the timestamp is to limit the validity of the
+ authentication so that a request cannot be replayed. A client MAY
+ base the timestamp on the KDC time in a KDC error and need not
+ maintain accurate time synchronization itself. If a client bases its
+ time on an untrusted source, an attacker may trick the client into
+ producing an authentication request that is valid at some future
+ time. The attacker may be able to use this authentication request to
+ make it appear that a client has authenticated at that future time.
+ If ticket-based armor is used, then the lifetime of the ticket will
+ limit the window in which an attacker can make the client appear to
+
+
+
+Hartman & Zhu Standards Track [Page 34]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ have authenticated. For many situations, the ability of an attacker
+ to cause a client to appear to have authenticated is not a
+ significant concern; the ability to avoid requiring time
+ synchronization on clients is more valuable.
+
+ The client sends a padata of type PA-ENCRYPTED-CHALLENGE. The
+ corresponding padata-value contains the DER encoding of ASN.1 type
+ EncryptedChallenge.
+
+ EncryptedChallenge ::= EncryptedData
+ -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
+ -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
+ -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
+
+ PA-ENCRYPTED-CHALLENGE 138
+ KEY_USAGE_ENC_CHALLENGE_CLIENT 54
+ KEY_USAGE_ENC_CHALLENGE_KDC 55
+
+ The client includes some timestamp reasonably close to the KDC's
+ current time and encrypts it in the challenge key in a PA-ENC-TS-ENC
+ structure (see Section 5.2.7.2 in RFC 4120). Clients MAY use the
+ current time; doing so prevents the exposure where an attacker can
+ cause a client to appear to authenticate in the future. The client
+ sends the request including this factor.
+
+ On receiving an AS-REQ containing the PA-ENCRYPTED-CHALLENGE FAST
+ factor, the KDC decrypts the timestamp. If the decryption fails the
+ KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including PA-ETYPE-INFO2 in
+ the KRBFastResponse in the error. The KDC confirms that the
+ timestamp falls within its current clock skew returning
+ KRB_APP_ERR_SKEW if not. The KDC then SHOULD check to see if the
+ encrypted challenge is a replay. The KDC MUST NOT consider two
+ encrypted challenges replays simply because the timestamps are the
+ same; to be a replay, the ciphertext MUST be identical. Allowing
+ clients to reuse timestamps avoids requiring that clients maintain
+ state about which timestamps have been used.
+
+ If the KDC accepts the encrypted challenge, it MUST include a padata
+ element of type PA-ENCRYPTED-CHALLENGE. The KDC encrypts its current
+ time in the challenge key. The KDC MUST strengthen the reply key
+ before issuing a ticket. The client MUST check that the timestamp
+ decrypts properly. The client MAY check that the timestamp is within
+ the window of acceptable clock skew for the client. The client MUST
+ NOT require that the timestamp be identical to the timestamp in the
+ issued credentials or the returned message.
+
+
+
+
+
+
+Hartman & Zhu Standards Track [Page 35]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ The encrypted challenge FAST factor provides the following
+ facilities: Client Authentication and KDC Authentication. This FAST
+ factor also takes advantage of the FAST facility to strengthen the
+ reply key. It does not provide the Replace Reply Key facility. The
+ Security Considerations section of this document provides an
+ explanation why the security requirements are met.
+
+ The encrypted challenge FAST factor can be useful in an
+ authentication set. No pa-hint is defined because the only
+ information needed by this mechanism is information contained in the
+ PA-ETYPE-INFO2 pre-authentication data. KDCs are already required to
+ send PA-ETYPE-INFO2. If KDCs were not required to send PA-ETYPE-
+ INFO2 then that information would need to be part of a hint for
+ encrypted challenge.
+
+ Conforming implementations MUST support the encrypted challenge FAST
+ factor.
+
+5.5. Authentication Strength Indication
+
+ Implementations that have pre-authentication mechanisms offering
+ significantly different strengths of client authentication MAY choose
+ to keep track of the strength of the authentication used as an input
+ into policy decisions. For example, some principals might require
+ strong pre-authentication, while less sensitive principals can use
+ relatively weak forms of pre-authentication like encrypted timestamp.
+
+ An AuthorizationData data type AD-Authentication-Strength is defined
+ for this purpose.
+
+ AD-authentication-strength 70
+
+ The corresponding ad-data field contains the DER encoding of the pre-
+ authentication data set as defined in Section 5.3. This set contains
+ all the pre-authentication mechanisms that were used to authenticate
+ the client. If only one pre-authentication mechanism was used to
+ authenticate the client, the pre-authentication set contains one
+ element. Unless otherwise specified, the hint and value fields of
+ the members of this sequence MUST be empty. In order to permit
+ mechanisms to carry additional information about strength in these
+ fields in the future, clients and application servers MUST ignore
+ non-empty hint and value fields for mechanisms unless the
+ implementation is updated with the interpretation of these fields for
+ a given pre-authentication mechanism in this authorization element.
+
+ The AD-authentication-strength element MUST be included in the AD-
+ KDC-ISSUED container so that the KDC integrity protects its contents.
+ This element can be ignored if it is unknown to the receiver.
+
+
+
+Hartman & Zhu Standards Track [Page 36]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+6. Assigned Constants
+
+ The pre-authentication framework and FAST involve using a number of
+ Kerberos protocol constants. This section lists protocol constants
+ first introduced in this specification drawn from registries not
+ managed by IANA. Many of these registries would best be managed by
+ IANA; that is a known issue that is out of scope for this document.
+ The constants described in this section have been accounted for and
+ will appear in the next revision of the Kerberos core specification
+ or in a document creating IANA registries.
+
+ Section 7 creates IANA registries for a different set of constants
+ used by the extensions described in this document.
+
+6.1. New Errors
+
+ KDC_ERR_PREAUTH_EXPIRED 90
+ KDC_ERR_MORE_PREAUTH_DATA_REQUIRED 91
+ KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92
+ KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS 93
+
+6.2. Key Usage Numbers
+
+ KEY_USAGE_FAST_REQ_CHKSUM 50
+ KEY_USAGE_FAST_ENC 51
+ KEY_USAGE_FAST_REP 52
+ KEY_USAGE_FAST_FINISHED 53
+ KEY_USAGE_ENC_CHALLENGE_CLIENT 54
+ KEY_USAGE_ENC_CHALLENGE_KDC 55
+
+6.3. Authorization Data Elements
+
+ AD-authentication-strength 70
+ AD-fx-fast-armor 71
+ AD-fx-fast-used 72
+
+6.4. New PA-DATA Types
+
+ PA-FX-COOKIE 133
+ PA-AUTHENTICATION-SET 134
+ PA-AUTH-SET-SELECTED 135
+ PA-FX-FAST 136
+ PA-FX-ERROR 137
+ PA-ENCRYPTED-CHALLENGE 138
+
+
+
+
+
+
+
+Hartman & Zhu Standards Track [Page 37]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+7. IANA Considerations
+
+ This document creates a number of IANA registries. These registries
+ are all located under Kerberos Parameters on http://www.iana.org.
+ See [RFC5226] for descriptions of the registration policies used in
+ this section.
+
+7.1. Pre-Authentication and Typed Data
+
+ RFC 4120 defines pre-authentication data, which can be included in a
+ KDC request or response in order to authenticate the client or extend
+ the protocol. In addition, it defines Typed-Data, which is an
+ extension mechanism for errors. Both pre-authentication data and
+ typed data are carried as a 32-bit signed integer along with an octet
+ string. The encoding of typed data and pre-authentication data is
+ slightly different. However, the types for pre-authentication data
+ and typed-data are drawn from the same namespace. By convention,
+ registrations starting with TD- are typed data and registrations
+ starting with PA- are pre-authentication data. It is important that
+ these data types be drawn from the same namespace, because some
+ errors where it would be desirable to include typed data require the
+ e-data field to be formatted as pre-authentication data.
+
+ When Kerberos FAST is used, pre-authentication data encoding is
+ always used.
+
+ There is one apparently conflicting registration between typed data
+ and pre-authentication data. PA-GET-FROM-TYPED-DATA and TD-PADATA
+ are both assigned the value 22. However, this registration is simply
+ a mechanism to include an element of the other encoding. The use of
+ both should be deprecated.
+
+ This document creates a registry for pre-authentication and typed
+ data. The registration procedures are as follows. Expert review for
+ pre-authentication mechanisms designed to authenticate users, KDCs,
+ or establish the reply key. The expert first determines that the
+ purpose of the method is to authenticate clients, KDCs, or to
+ establish the reply key. If so, expert review is appropriate. The
+ expert evaluates the security and interoperability of the
+ specification.
+
+ IETF review is required if the expert believes that the pre-
+ authentication method is broader than these three areas. Pre-
+ authentication methods that change the Kerberos state machine or
+ otherwise make significant changes to the Kerberos protocol should be
+ Standards Track RFCs. A concern that a particular method needs to be
+ a Standards Track RFC may be raised as an objection during IETF
+ review.
+
+
+
+Hartman & Zhu Standards Track [Page 38]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ Several of the registrations indicated below were made at a time when
+ the Kerberos protocol was less mature and do not meet the current
+ requirements for this registry. These registrations are included in
+ order to accurately document what is known about the use of these
+ protocol code points and to avoid conflicts.
+
+ Type Value Reference
+ ----------------------------------------------------------------------
+ PA-TGS-REQ 1 [RFC4120]
+ PA-ENC-TIMESTAMP 2 [RFC4120]
+ PA-PW-SALT 3 [RFC4120]
+ [reserved] 4 [RFC6113]
+ PA-ENC-UNIX-TIME 5 (deprecated) [RFC4120]
+ PA-SANDIA-SECUREID 6 [RFC4120]
+ PA-SESAME 7 [RFC4120]
+ PA-OSF-DCE 8 [RFC4120]
+ PA-CYBERSAFE-SECUREID 9 [RFC4120]
+ PA-AFS3-SALT 10 [RFC4120] [RFC3961]
+ PA-ETYPE-INFO 11 [RFC4120]
+ PA-SAM-CHALLENGE 12 [KRB-WG.SAM]
+ PA-SAM-RESPONSE 13 [KRB-WG.SAM]
+ PA-PK-AS-REQ_OLD 14 [PK-INIT-1999]
+ PA-PK-AS-REP_OLD 15 [PK-INIT-1999]
+ PA-PK-AS-REQ 16 [RFC4556]
+ PA-PK-AS-REP 17 [RFC4556]
+ PA-PK-OCSP-RESPONSE 18 [RFC4557]
+ PA-ETYPE-INFO2 19 [RFC4120]
+ PA-USE-SPECIFIED-KVNO 20 [RFC4120]
+ PA-SVR-REFERRAL-INFO 20 [REFERRALS]
+ PA-SAM-REDIRECT 21 [KRB-WG.SAM]
+ PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) [RFC4120]
+ TD-PADATA 22 (embeds padata) [RFC4120]
+ PA-SAM-ETYPE-INFO 23 (sam/otp) [KRB-WG.SAM]
+ PA-ALT-PRINC 24 (crawdad@fnal.gov) [HW-AUTH]
+ PA-SERVER-REFERRAL 25 [REFERRALS]
+ PA-SAM-CHALLENGE2 30 (kenh@pobox.com) [KRB-WG.SAM]
+ PA-SAM-RESPONSE2 31 (kenh@pobox.com) [KRB-WG.SAM]
+ PA-EXTRA-TGT 41 Reserved extra TGT [RFC6113]
+ TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS
+ TD-KRB-PRINCIPAL 102 PrincipalName
+ TD-KRB-REALM 103 Realm
+ TD-TRUSTED-CERTIFIERS 104 [RFC4556]
+ TD-CERTIFICATE-INDEX 105 [RFC4556]
+ TD-APP-DEFINED-ERROR 106 Application specific [RFC6113]
+ TD-REQ-NONCE 107 INTEGER [RFC6113]
+ TD-REQ-SEQ 108 INTEGER [RFC6113]
+ TD_DH_PARAMETERS 109 [RFC4556]
+ TD-CMS-DIGEST-ALGORITHMS 111 [ALG-AGILITY]
+
+
+
+Hartman & Zhu Standards Track [Page 39]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ TD-CERT-DIGEST-ALGORITHMS 112 [ALG-AGILITY]
+ PA-PAC-REQUEST 128 [MS-KILE]
+ PA-FOR_USER 129 [MS-KILE]
+ PA-FOR-X509-USER 130 [MS-KILE]
+ PA-FOR-CHECK_DUPS 131 [MS-KILE]
+ PA-AS-CHECKSUM 132 [MS-KILE]
+ PA-FX-COOKIE 133 [RFC6113]
+ PA-AUTHENTICATION-SET 134 [RFC6113]
+ PA-AUTH-SET-SELECTED 135 [RFC6113]
+ PA-FX-FAST 136 [RFC6113]
+ PA-FX-ERROR 137 [RFC6113]
+ PA-ENCRYPTED-CHALLENGE 138 [RFC6113]
+ PA-OTP-CHALLENGE 141 (gareth.richards@rsa.com) [OTP-PREAUTH]
+ PA-OTP-REQUEST 142 (gareth.richards@rsa.com) [OTP-PREAUTH]
+ PA-OTP-CONFIRM 143 (gareth.richards@rsa.com) [OTP-PREAUTH]
+ PA-OTP-PIN-CHANGE 144 (gareth.richards@rsa.com) [OTP-PREAUTH]
+ PA-EPAK-AS-REQ 145 (sshock@gmail.com) [RFC6113]
+ PA-EPAK-AS-REP 146 (sshock@gmail.com) [RFC6113]
+ PA_PKINIT_KX 147 [RFC6112]
+ PA_PKU2U_NAME 148 [PKU2U]
+ PA-SUPPORTED-ETYPES 165 [MS-KILE]
+ PA-EXTENDED_ERROR 166 [MS-KILE]
+
+7.2. Fast Armor Types
+
+ FAST armor types are defined in Section 5.4.1. A FAST armor type is
+ a signed 32-bit integer. FAST armor types are assigned by standards
+ action.
+
+ Type Name Description
+ ------------------------------------------------------------
+ 0 Reserved.
+ 1 FX_FAST_ARMOR_AP_REQUEST Ticket armor using an ap-req.
+
+7.3. FAST Options
+
+ A FAST request includes a set of bit flags to indicate additional
+ options. Bits 0-15 are critical; other bits are non-critical.
+ Assigning bits greater than 31 may require special support in
+ implementations. Assignment of FAST options requires standards
+ action.
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu Standards Track [Page 40]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ Type Name Description
+ -------------------------------------------------------------------
+ 0 RESERVED Reserved for future expansion of this
+ field.
+ 1 hide-client-names Requesting the KDC to hide client
+ names in the KDC response
+ 16 kdc-follow-referrals Reserved.
+
+8. Security Considerations
+
+ The kdc-referrals option in the Kerberos FAST padata requests the KDC
+ to act as the client to follow referrals. This can overload the KDC.
+ To limit the damages of denial of service using this option, KDCs MAY
+ restrict the number of simultaneous active requests with this option
+ for any given client principal.
+
+ Regarding the facilities provided by the Encrypted Challenge FAST
+ factor, the challenge key is derived from the client secrets and
+ because the client secrets are known only to the client and the KDC,
+ the verification of the EncryptedChallenge structure proves the
+ client's identity, the verification of the EncryptedChallenge
+ structure in the KDC reply proves that the expected KDC responded.
+ Therefore, the Encrypted Challenge FAST factor as a pre-
+ authentication mechanism offers the following facilities: Client
+ Authentication and KDC Authentication. There is no un-authenticated
+ cleartext introduced by the Encrypted Challenge FAST factor.
+
+ FAST provides an encrypted tunnel over which pre-authentication
+ conversations can take place. In addition, FAST optionally
+ authenticates the KDC to the client. It is the responsibility of
+ FAST factors to authenticate the client to the KDC. Care MUST be
+ taken to design FAST factors such that they are bound to the
+ conversation. If this is not done, a man-in-the-middle may be able
+ to cut&paste a FAST factor from one conversation to another. The
+ easiest way to do this is to bind each FAST factor to the armor key
+ that is guaranteed to be unique for each conversation.
+
+ The anonymous PKINIT mode for obtaining an armor ticket does not
+ always authenticate the KDC to the client before the conversation
+ begins. Tracking the KDC verified state guarantees that by the end
+ of the conversation, the client has authenticated the KDC. However,
+ FAST factor designers need to consider the implications of using
+ their factor when the KDC has not yet been authenticated. If this
+ proves problematic in an environment, then the particular FAST factor
+ should not be used with anonymous PKINIT.
+
+ Existing pre-authentication mechanisms are believed to be at least as
+ secure when used with FAST as they are when used outside of FAST.
+
+
+
+Hartman & Zhu Standards Track [Page 41]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ One part of this security is making sure that when pre-authentication
+ methods checksum the request, they checksum the inner request rather
+ than the outer request. If the mechanism checksummed the outer
+ request, a man-in-the-middle could observe it outside a FAST tunnel
+ and then cut&paste it into a FAST exchange where the inner rather
+ than outer request would be used to select attributes of the issued
+ ticket. Such attacks would typically invalidate auditing information
+ or create a situation where the client and KDC disagree about what
+ ticket is issued. However, such attacks are unlikely to allow an
+ attacker who would not be able to authenticate as a principal to do
+ so. Even so, FAST is believed to defend against these attacks in
+ existing legacy mechanism. However, since there is no standard for
+ how legacy mechanisms bind the request to the pre-authentication or
+ provide integrity protection, security analysis can be difficult. In
+ some cases, FAST may significantly improve the integrity protection
+ of legacy mechanisms.
+
+ The security of the TGS exchange depends on authenticating the client
+ to the KDC. In the AS exchange, this is done using pre-
+ authentication data or FAST factors. In the TGS exchange, this is
+ done by presenting a TGT and by using the session (or sub-session)
+ key in constructing the request. Because FAST uses a request body in
+ the inner request, encrypted in the armor key, rather than the
+ request body in the outer request, it is critical that establishing
+ the armor key be tied to the authentication of the client to the KDC.
+ If this is not done, an attacker could manipulate the options
+ requested in the TGS request, for example, requesting a ticket with
+ different validity or addresses. The easiest way to bind the armor
+ key to the authentication of the client to the KDC is for the armor
+ key to depend on the sub-session key of the TGT. This is done with
+ the implicit TGS armor supported by this specification. Future armor
+ types designed for use with the TGS MUST either bind their armor keys
+ to the TGT or provide another mechanism to authenticate the client to
+ the KDC.
+
+9. Acknowledgements
+
+ Sam Hartman would like to thank the MIT Kerberos Consortium for its
+ funding of his time on this project.
+
+ Several suggestions from Jeffrey Hutzelman based on early revisions
+ of this documents led to significant improvements of this document.
+
+ The proposal to ask one KDC to chase down the referrals and return
+ the final ticket is based on requirements in [CROSS].
+
+ Joel Weber had a proposal for a mechanism similar to FAST that
+ created a protected tunnel for Kerberos pre-authentication.
+
+
+
+Hartman & Zhu Standards Track [Page 42]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ Srinivas Cheruku and Greg Hudson provided valuable review comments.
+
+10. References
+
+10.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3961] Raeburn, K., "Encryption and Checksum Specifications
+ for Kerberos 5", RFC 3961, February 2005.
+
+ [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+ Kerberos Network Authentication Service (V5)",
+ RFC 4120, July 2005.
+
+ [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for
+ Initial Authentication in Kerberos (PKINIT)",
+ RFC 4556, June 2006.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
+ an IANA Considerations Section in RFCs", BCP 26,
+ RFC 5226, May 2008.
+
+ [RFC6112] Zhu, L., Leach, P., and S. Hartman "Anonymity Support
+ for Kerberos", RFC 6112, April 2011.
+
+10.2. Informative References
+
+ [ALG-AGILITY] Astrand, L. and L. Zhu, "PK-INIT algorithm agility",
+ Work in Progress, August 2008.
+
+ [CROSS] Sakane, S., Zrelli, S., and M. Ishiyama , "Problem
+ statement on the cross-realm operation of Kerberos in
+ a specific system", Work in Progress, July 2007.
+
+ [EKE] Bellovin, S. and M. Merritt, "Augmented Encrypted Key
+ Exchange: A Password-Based Protocol Secure Against
+ Dictionary Attacks and Password File Compromise,
+ Proceedings of the 1st ACM Conference on Computer and
+ Communications Security, ACM Press.", November 1993.
+
+ [HW-AUTH] Crawford, M., "Passwordless Initial Authentication to
+ Kerberos by Hardware Preauthentication", Work
+ in Progress, October 2006.
+
+ [IEEE1363.2] IEEE, "IEEE P1363.2: Password-Based Public-Key
+ Cryptography", 2004.
+
+
+
+Hartman & Zhu Standards Track [Page 43]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ [KRB-WG.SAM] Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
+ "Integrating Single-use Authentication Mechanisms
+ with Kerberos", Work in Progress, July 2004.
+
+ [MS-KILE] Microsoft, "Kerberos Protocol Extensions", <http://
+ msdn.microsoft.com/en-us/library/cc206927.aspx>.
+
+ [OTP-PREAUTH] Richards, G., "OTP Pre-authentication", Work
+ in Progress, February 2011.
+
+ [PK-INIT-1999] Tung, B., Neuman, C., Hur, M., Medvinsky, A.,
+ Medvinsky, S., Wray, J., and J. Trostle, "Public Key
+ Cryptography for Initial Authentication in Kerberos",
+ Work in Progress, July 1999.
+
+ [PKU2U] Zhu, L., Altman, J., and N. Williams, "Public Key
+ Cryptography Based User-to-User Authentication -
+ (PKU2U)", Work in Progress, November 2008.
+
+ [REFERRALS] Hartman, S., Ed., Raeburn, K., and L. Zhu, "Kerberos
+ Principal Name Canonicalization and KDC-Generated
+ Cross-Realm Referrals", Work in Progress, March 2011.
+
+ [RFC4557] Zhu, L., Jaganathan, K., and N. Williams, "Online
+ Certificate Status Protocol (OCSP) Support for Public
+ Key Cryptography for Initial Authentication in
+ Kerberos (PKINIT)", RFC 4557, June 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu Standards Track [Page 44]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+Appendix A. Test Vectors for KRB-FX-CF2
+
+ This informative appendix presents test vectors for the KRB-FX-CF2
+ function. Test vectors are presented for several encryption types.
+ In all cases, the first key (k1) is the result of string-to-
+ key("key1", "key1", default_parameters) and the second key (k2) is
+ the result of string-to-key("key2", "key2", default_parameters).
+ Both keys are of the same enctype. The presented test vector is the
+ hexadecimal encoding of the key produced by KRB-FX-CF2(k1, k2, "a",
+ "b"). The peppers are one-octet ASCII strings.
+
+ In performing interoperability testing, there was significant
+ ambiguity surrounding [RFC3961] pseudo-random operations. These test
+ vectors assume that the AES pseudo-random operation is
+ aes-ecb(trunc128(sha-1(input))) where trunc128 truncates its input to
+ 128 bits. The 3DES pseudo-random operation is assumed to be
+ des3-cbc(trunc128(sha-1(input))). The DES pseudo-random operation is
+ assumed to be des-cbc(md5(input)). As specified in RFC 4757, the RC4
+ pseudo-random operation is hmac-sha1(input).
+
+ Interoperability testing also demonstrated ambiguity surrounding the
+ DES random-to-key operation. The random-to-key operation is assumed
+ to be distribute 56 bits into high-7-bits of 8 octets and generate
+ parity.
+
+ These test vectors were produced with revision 22359 of the MIT
+ Kerberos sources. The AES 256 and AES 128 test vectors have been
+ confirmed by multiple other implementors. The RC4 test vectors have
+ been confirmed by one other implementor. The DES and triple DES test
+ vectors have not been confirmed.
+
+ aes 128 (enctype 17): 97df97e4b798b29eb31ed7280287a92a
+ AES256 (enctype 18): 4d6ca4e629785c1f01baf55e2e548566
+ b9617ae3a96868c337cb93b5e72b1c7b
+ DES (enctype 1): 43bae3738c9467e6
+ 3DES (enctype 16): e58f9eb643862c13ad38e529313462a7f73e62834fe54a01
+ RC4 (enctype 23): 24d7f6b6bae4e5c00d2082c5ebab3672
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hartman & Zhu Standards Track [Page 45]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+Appendix B. ASN.1 Module
+
+ KerberosPreauthFramework {
+ iso(1) identified-organization(3) dod(6) internet(1)
+ security(5) kerberosV5(2) modules(4) preauth-framework(3)
+ } DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+ IMPORTS
+ KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
+ Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY,
+ Microseconds, KerberosFlags, UInt32
+ FROM KerberosV5Spec2 { iso(1) identified-organization(3)
+ dod(6) internet(1) security(5) kerberosV5(2)
+ modules(4) krb5spec2(2) };
+ -- as defined in RFC 4120.
+
+ PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
+
+ PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
+ pa-type [0] Int32,
+ -- same as padata-type.
+ pa-hint [1] OCTET STRING OPTIONAL,
+ pa-value [2] OCTET STRING OPTIONAL,
+ ...
+ }
+
+ KrbFastArmor ::= SEQUENCE {
+ armor-type [0] Int32,
+ -- Type of the armor.
+ armor-value [1] OCTET STRING,
+ -- Value of the armor.
+ ...
+ }
+
+ PA-FX-FAST-REQUEST ::= CHOICE {
+ armored-data [0] KrbFastArmoredReq,
+ ...
+ }
+
+ KrbFastArmoredReq ::= SEQUENCE {
+ armor [0] KrbFastArmor OPTIONAL,
+ -- Contains the armor that identifies the armor key.
+ -- MUST be present in AS-REQ.
+ req-checksum [1] Checksum,
+ -- For AS, contains the checksum performed over the type
+ -- KDC-REQ-BODY for the req-body field of the KDC-REQ
+ -- structure;
+ -- For TGS, contains the checksum performed over the type
+
+
+
+Hartman & Zhu Standards Track [Page 46]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ -- AP-REQ in the PA-TGS-REQ padata.
+ -- The checksum key is the armor key, the checksum
+ -- type is the required checksum type for the enctype of
+ -- the armor key, and the key usage number is
+ -- KEY_USAGE_FAST_REQ_CHKSUM.
+ enc-fast-req [2] EncryptedData, -- KrbFastReq --
+ -- The encryption key is the armor key, and the key usage
+ -- number is KEY_USAGE_FAST_ENC.
+ ...
+ }
+
+ KrbFastReq ::= SEQUENCE {
+ fast-options [0] FastOptions,
+ -- Additional options.
+ padata [1] SEQUENCE OF PA-DATA,
+ -- padata typed holes.
+ req-body [2] KDC-REQ-BODY,
+ -- Contains the KDC request body as defined in Section
+ -- 5.4.1 of [RFC4120].
+ -- This req-body field is preferred over the outer field
+ -- in the KDC request.
+ ...
+ }
+
+ FastOptions ::= KerberosFlags
+ -- reserved(0),
+ -- hide-client-names(1),
+ -- kdc-follow-referrals(16)
+
+ PA-FX-FAST-REPLY ::= CHOICE {
+ armored-data [0] KrbFastArmoredRep,
+ ...
+ }
+
+ KrbFastArmoredRep ::= SEQUENCE {
+ enc-fast-rep [0] EncryptedData, -- KrbFastResponse --
+ -- The encryption key is the armor key in the request, and
+ -- the key usage number is KEY_USAGE_FAST_REP.
+ ...
+ }
+
+ KrbFastResponse ::= SEQUENCE {
+ padata [0] SEQUENCE OF PA-DATA,
+ -- padata typed holes.
+ strengthen-key [1] EncryptionKey OPTIONAL,
+ -- This, if present, strengthens the reply key for AS and
+ -- TGS. MUST be present for TGS
+ -- MUST be absent in KRB-ERROR.
+
+
+
+Hartman & Zhu Standards Track [Page 47]
+
+RFC 6113 Kerberos Preauth Framework April 2011
+
+
+ finished [2] KrbFastFinished OPTIONAL,
+ -- Present in AS or TGS reply; absent otherwise.
+ nonce [3] UInt32,
+ -- Nonce from the client request.
+ ...
+ }
+
+ KrbFastFinished ::= SEQUENCE {
+ timestamp [0] KerberosTime,
+ usec [1] Microseconds,
+ -- timestamp and usec represent the time on the KDC when
+ -- the reply was generated.
+ crealm [2] Realm,
+ cname [3] PrincipalName,
+ -- Contains the client realm and the client name.
+ ticket-checksum [4] Checksum,
+ -- checksum of the ticket in the KDC-REP using the armor
+ -- and the key usage is KEY_USAGE_FAST_FINISH.
+ -- The checksum type is the required checksum type
+ -- of the armor key.
+ ...
+ }
+
+ EncryptedChallenge ::= EncryptedData
+ -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
+ -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
+ -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
+ END
+
+Authors' Addresses
+
+ Sam Hartman
+ Painless Security
+
+ EMail: hartmans-ietf@mit.edu
+
+
+ Larry Zhu
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+ US
+
+ EMail: larry.zhu@microsoft.com
+
+
+
+
+
+
+
+Hartman & Zhu Standards Track [Page 48]
+