tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6113

 
 
 

A Generalized Framework for Kerberos Pre-Authentication

Part 2 of 3, p. 17 to 36
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 17 
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      Up      ToC       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
   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.

Top      Up      ToC       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      Up      ToC       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
   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

Top      Up      ToC       Page 21 
   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

Top      Up      ToC       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
   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

Top      Up      ToC       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-
   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.

Top      Up      ToC       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      Up      ToC       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
   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-

Top      Up      ToC       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      Up      ToC       Page 27 
       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.

Top      Up      ToC       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      Up      ToC       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
                                   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].

Top      Up      ToC       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
   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

Top      Up      ToC       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      Up      ToC       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
   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.

Top      Up      ToC       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      Up      ToC       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
   [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

Top      Up      ToC       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.

      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.

Top      Up      ToC       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
   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.


Next RFC Part