A Generalized Framework for Kerberos Pre-Authentication
updates
- rfc-4120 — The Kerberos Network Authentication Service (V5)
Extracted elements (31)
FAST is designed as a protected tunnel (typed hole) for FAST factors rather than a direct authentication mechanism because this separation makes individual FAST factors significantly easier to analyze from a security standpoint. A FAST factor captures only the minimal work required to extend Kerberos with a new pre-authentication scheme.
KDCs are stateless by design so that clients may use any KDC for each message in a conversation. The PA-FX-COOKIE mechanism resolves the apparent conflict between stateless KDCs and stateful client conversations by encoding all necessary conversation state in a KDC-generated opaque token that the client echoes back in each subsequent request.
A FAST factor MUST NOT be used outside of FAST unless its specification explicitly allows it. New pre-authentication mechanisms SHOULD be designed as FAST factors rather than as standalone full pre-authentication mechanisms, as FAST factors are significantly easier to analyze from a security standpoint.
Any FAST armor scheme MUST provide a fresh armor key for each conversation. All KDCs in a realm MUST support FAST if FAST is offered by any KDC as a pre-authentication mechanism. If a FAST KDC receives an unknown armor type it MUST respond with KDC_ERR_PREAUTH_FAILED.
Any pre-authentication mechanism that sets a new reply key not based on the principal's long-term secret MUST either verify the KDC reply some other way or indicate the reply is not verified. If a mechanism indicates the reply is not verified, the client MUST return an error unless a subsequent mechanism verifies it.
By the end of a successful authentication exchange, mechanisms MUST guarantee that both client and KDC have verified all plaintext sent by the other party. For multi-round-trip exchanges, mechanisms MUST additionally guarantee no individual messages were reordered or replayed from a previous exchange.
Conforming implementations MUST support Kerberos FAST padata, MUST implement the FX_FAST_ARMOR_AP_REQUEST armor type, and MUST support the encrypted challenge FAST factor. Clients conforming to this specification MUST support the PA-FX-COOKIE padata defined in Section 5.2.
If a client includes padata with wrong mechanisms or keys and the KDC returns KDC_ERR_PREAUTH_FAILED with no indication of correct padata, the client MUST retry with no padata and examine the error data of the KDC_ERR_PREAUTH_REQUIRED error. If the KDC includes pre-authentication information in the error data of KDC_ERR_PREAUTH_FAILED, the client SHOULD process it and retry.
Mechanisms implementing the Replace Reply Key facility MUST mark the reply key as replaced in the pre-authentication state and MUST either provide a mechanism to verify the KDC reply or mark the reply as unverified. They SHOULD NOT be used if a previous mechanism has already used the reply key.
The KDC MUST NOT ignore padata of types used in previous messages in the same conversation; if a KDC issues KDC_ERR_PREAUTH_REQUIRED including padata of type x, it cannot subsequently ignore padata of type x in an AS-REQ. The KDC MUST ignore padata of unknown type.
The KDC SHOULD NOT send data encrypted in the long-term password-based key of the principal before the client has proven knowledge of that key, as this has the same security exposure as Kerberos without pre-authentication.
The Kerberos client MUST support a local policy that rejects the KDC response if PA-FX-FAST-REPLY is not included. The client MUST verify that the nonce value in the KrbFastResponse matches that of the request; clients SHOULD use a new nonce for each message in a conversation to prevent cross-message replay.
When a client selects an authentication set, its first AS-REQ MUST contain a PA-AUTH-SET-SELECTED (padata type 135) element carrying the exact octet encoding of the PA-AUTHENTICATION-SET received from the KDC to allow bitwise comparison. PA-AUTH-SET-SELECTED MUST appear before any padata from the authentication set in the padata sequence.
FastOptions bit flags: bits 1-15 are critical (KDC MUST fail with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS if unsupported); bits 16+ are non-critical (KDC ignores unknown). Defined options: RESERVED (0), hide-client-names (1, critical — KDC identifies the client as anonymous principal in all replies), kdc-follow-referrals (16, non-critical, reserved).
For FX_FAST_ARMOR_AP_REQUEST, the armor key is computed as KRB-FX-CF2(subkey, ticket_session_key, 'subkeyarmor', 'ticketarmor'), ensuring both the KDC (via session key from the ticket) and the client (via the AP-REQ subkey) contribute to the armor key. This armor type is only valid for AS requests; TGS requests use implicit armor derived from the PA-TGS-REQ authenticator.
KRB-FX-CF2 combines two protocol keys of potentially different enctypes using the RFC 3961 pseudo-random function: PRF+(K1, pepper1) XOR PRF+(K2, pepper2) is passed to random-to-key(). Mechanism designers MUST specify distinct pepper1 and pepper2 values so that combining identical keys does not produce a trivial result.
PA-AUTHENTICATION-SET (padata type 134) groups multiple pre-authentication mechanisms that must all complete successfully to authenticate a client. Each PA-AUTHENTICATION-SET-ELEM contains pa-type (Int32), optional pa-hint (OCTET STRING giving mechanism guidance), and optional pa-value (OCTET STRING, present only for the first element, carrying the first KDC-to-client padata-value).
PA-FX-COOKIE (padata type 133) is an opaque stateless token sent by the KDC to capture conversation state across multiple AS-exchange round trips, since KDCs may be stateless and different requests may be handled by different KDCs. The client MUST copy the exact cookie into the next message; the KDC MUST include a cookie in KDC_ERR_PREAUTH_REQUIRED and KDC_ERR_MORE_PREAUTH_DATA_REQUIRED responses.
The encrypted challenge FAST factor (PA-ENCRYPTED-CHALLENGE) authenticates the client using a challenge key derived as KRB-FX-CF2(armor_key, long_term_key, 'clientchallengearmor', 'challengelongterm') for client-to-KDC, and KRB-FX-CF2(armor_key, long_term_key, 'kdcchallengearmor', 'challengelongterm') for KDC-to-client. The fresh armor key ensures the challenge key is fresh and random, protecting against offline dictionary attacks.
When FAST padata was included in the request, authenticated KRB-ERROR messages are delivered via PA-FX-ERROR (padata type 137) inside the KrbFastResponse. The KDC MUST include PA-FX-ERROR carrying the full KRB-ERROR (with e-data absent) so the client ignores the outer unprotected error and uses the integrity-protected inner error.
RFC 6113 creates the FAST Armor Types IANA registry. The only currently defined value is FX_FAST_ARMOR_AP_REQUEST (1), a ticket-based armor scheme. New armor types require IETF Review.
RFC 6113 creates the FAST Options IANA registry for FastOptions bit flags. Bits 1-15 are critical options requiring Standards Action; bits 16 and above are non-critical requiring IETF Review. Currently assigned: RESERVED (0), hide-client-names (1), kdc-follow-referrals (16).
RFC 6113 updates the Pre-Authentication and Typed Data IANA registry adding PA-FX-COOKIE (133), PA-AUTHENTICATION-SET (134), PA-AUTH-SET-SELECTED (135), PA-FX-FAST (136), PA-FX-ERROR (137); and new error codes KDC_ERR_PREAUTH_EXPIRED (90), KDC_ERR_MORE_PREAUTH_DATA_REQUIRED (91), KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET (92), KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS (93); and key usage numbers 50-53.
FAST significantly reduces 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 (ticket-based armor with KDC authentication), FAST can even protect against active attacks.
The TGS MUST reject a request if an AD-fx-fast-armor (71) authorization data element is present in the PA-TGS-REQ authenticator or in the ticket in that authenticator. This prevents a user process from misusing a privileged host ticket to authenticate as the host when the host provided it only for FAST armoring.
The pre-authentication model tracks five state variables per request: the reply key, how strongly the client identity has been authenticated, whether the reply key has been used, whether it has been replaced, and whether the KDC reply can be verified by the client. Each pre-authentication mechanism reads and updates these states before and after processing.
KrbFastArmor is an ASN.1 SEQUENCE with armor-type (Int32) and armor-value (OCTET STRING). The only currently defined armor type is FX_FAST_ARMOR_AP_REQUEST (value 1), which carries an ASN.1 DER-encoded AP-REQ; the AP-REQ subkey field MUST be present.
KrbFastArmoredReq is an ASN.1 SEQUENCE with: armor (KrbFastArmor, OPTIONAL, MUST be present in AS-REQ), req-checksum (Checksum keyed with armor key at KEY_USAGE_FAST_REQ_CHKSUM=50, binding FAST padata to the outer request), and enc-fast-req (EncryptedData containing KrbFastReq, encrypted with armor key at KEY_USAGE_FAST_ENC=51).
KrbFastFinished is an ASN.1 SEQUENCE with timestamp and usec (KDC reply generation time), crealm and cname (authenticated client identity), and ticket-checksum (checksum of the issued ticket using armor key at KEY_USAGE_FAST_FINISHED=53). The client MUST use the KDC's time thereafter when using the returned ticket.
KrbFastReq is an ASN.1 SEQUENCE with fast-options (FastOptions KerberosFlags), padata (SEQUENCE OF PA-DATA for FAST factors and generic extensions), and req-body (KDC-REQ-BODY, preferred over the outer KDC request body which is retained only for backwards compatibility).
KrbFastResponse is an ASN.1 SEQUENCE with padata (SEQUENCE OF PA-DATA), strengthen-key (EncryptionKey, OPTIONAL in AS reply, MUST be present in TGS reply, MUST be absent in error reply), finished (KrbFastFinished, present in AS/TGS reply with returned ticket), and nonce (UInt32 echoing the client request nonce). Encrypted with armor key at KEY_USAGE_FAST_REP (52).