Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 6113

A Generalized Framework for Kerberos Pre-Authentication

Pages: 48
Proposed Standard
Updates:  4120
Part 2 of 3 – Pages 17 to 36
First   Prev   Next

Top   ToC   RFC6113 - Page 17   prevText

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.
Top   ToC   RFC6113 - Page 18
   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

       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

    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.
Top   ToC   RFC6113 - Page 19

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
Top   ToC   RFC6113 - Page 20
   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
   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.


   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
   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
Top   ToC   RFC6113 - Page 21
   A PA-AUTHENTICATION-SET padata element contains the ASN.1 DER
   encoding of the PA-AUTHENTICATION-SET structure:


            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
Top   ToC   RFC6113 - Page 22
   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

         PA-AUTH-SET-SELECTED                   135

   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-

   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
Top   ToC   RFC6113 - Page 23
   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-

   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.
Top   ToC   RFC6113 - Page 24
   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
Top   ToC   RFC6113 - Page 25
   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

   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. 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-
Top   ToC   RFC6113 - Page 26
       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.
Top   ToC   RFC6113 - Page 27
       PA-FX-FAST                         136
           -- Padata type for Kerberos FAST

           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.
Top   ToC   RFC6113 - Page 28
   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.
Top   ToC   RFC6113 - Page 29
   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
       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.


   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].
Top   ToC   RFC6113 - Page 30
   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

   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

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
Top   ToC   RFC6113 - Page 31
   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")
Top   ToC   RFC6113 - Page 32
   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

   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
Top   ToC   RFC6113 - Page 33
   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
Top   ToC   RFC6113 - Page 34
   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

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
Top   ToC   RFC6113 - Page 35
   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 ::= 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

   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 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
   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.
Top   ToC   RFC6113 - Page 36
   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

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.

(next page on part 3)

Next Section