Kerberos Simple Password-Authenticated Key Exchange (SPAKE) Pre-authentication
Extracted elements (31)
SPAKE pre-authentication was designed as an alternative to FAST for protecting 2FA credentials because FAST requires a secondary trust relationship (often a CA) that is cumbersome to deploy. SPAKE creates a high-entropy encryption channel implicitly from the shared long-term key, enabling 2FA without any third-party trust anchor.
SPAKE was selected over other PAKE algorithms because its encryption method keeps public keys within the underlying group (enabling elliptic curve use at smaller key sizes), it requires only one message from each party (minimizing round trips), and it uses a small number of group operations (simplicity and efficiency).
When SPAKE pre-authentication is used within a FAST channel, the key derivation in Section 7 MUST use the inner KDC-REQ-BODY encoding rather than the outer encoding, ensuring binding to the actual request content inside the FAST tunnel.
A KDC offering SPAKE pre-authentication as a stand-alone mechanism MUST supply a PA-ETYPE-INFO2 value containing a single ETYPE-INFO2-ENTRY, ensuring the initial KDC pre-authentication state contains a singular reply key.
All PA-DATA elements for the SPAKE mechanism MUST use padata-type PA-SPAKE (value 151), and the padata-value MUST be empty or contain a DER encoding of the ASN.1 type PA-SPAKE.
Both KDCs and clients that implement SPAKE pre-authentication MUST support the use of KDC_ERR_MORE_PREAUTH_DATA_REQUIRED, as described in RFC 6113 Section 5.2.
Clients and KDCs MUST implement the edwards25519 group, but they MAY choose not to offer or accept it by default. All implementations MUST support the most verbose version of the protocol.
Clients MUST support the optimistic challenge optimization (KDC sends a challenge in response to the initial AS-REQ). KDCs MUST support the optimization where clients skip the first pass and send a support message directly.
If either the first or second factor fails validation, the KDC MUST respond with a KDC_ERR_PREAUTH_FAILED error. If additional round trips are needed for second-factor validation, the KDC MUST reply with KDC_ERR_MORE_PREAUTH_DATA_REQUIRED containing an encdata PA-SPAKE element.
Implementations MUST NOT use the shared group element K directly for any cryptographic operation. The SPAKE result must be used only via the K'[n] key derivation defined in Section 7.
KDCs that implement SPAKE pre-authentication MUST have a secure mechanism for retaining state between AS-REQs. Clients MUST support PA-FX-COOKIE as described in RFC 6113 Section 5.2.
The KDC and client MUST NOT reuse scalar values x or y for authentications involving different initial reply keys. If reused, an attacker who observes both exchanges and knows one reply key can conduct an offline dictionary attack on the other.
Upon successful validation, the reply key is replaced with K'[0]. The client and KDC MUST use the initial reply key as the base key for all K'[n] derivations; reply key strengthening occurs only once at the end of the exchange.
K'[n] is derived by hashing the concatenation of: the fixed string "SPAKEkey", group number (4 bytes big-endian), reply key encryption type (4 bytes), PRF+ output for w, SPAKE result K, transcript hash, inner KDC-REQ-BODY encoding, n (4 bytes unsigned), and a block counter starting at 0x01. The result is truncated to the key generation seed length and processed through random-to-key, then combined with KRB-FX-CF2.
PA-SPAKE-HINT is an ASN.1 SEQUENCE containing the KDC's supported groups and second factors; it is provided within authentication sets to help clients assess whether SPAKE is likely to succeed before choosing an authentication set. A KDC MUST NOT include PA-SPAKE-HINT directly in a pa-value field.
PA-SPAKE is defined as an ASN.1 CHOICE with four alternatives: support [0] SPAKESupport, challenge [1] SPAKEChallenge, response [2] SPAKEResponse, and encdata [3] EncryptedData. These four message types carry the full SPAKE pre-authentication exchange.
SF-NONE (value 1) is the only second-factor type defined in this document. It indicates no second factor is used; the data field MUST be omitted when SF-NONE is used, and it always validates successfully.
SPAKEChallenge carries the KDC's selected group (Int32), the KDC public key T as an OCTET STRING serialized per Section 5, and an unordered list of supported second-factor types (SPAKESecondFactor). The factors field MUST NOT contain duplicate type values.
SPAKEResponse carries the client's public key S as an OCTET STRING and the client's chosen second-factor data as EncryptedData (key K'[1], key usage KEY_USAGE_SPAKE). The client MUST NOT include a second-factor type not listed in the challenge's factors field.
The SPAKE scalar w is derived from the initial reply key by computing PRF+(K, pepper) where pepper is "SPAKEsecret" concatenated with the group number as a 4-byte big-endian integer, then converting the output to a scalar using the group's multiplier conversion method.
The transcript hash is initialized to all zeros and iteratively updated with the hash of its current value concatenated with each input. In the normal flow it is updated with (SPAKESupport || SPAKEChallenge), then updated again with the client's pubkey value; the final value is used without change for all key derivations.
IANA has established the "Kerberos Second-Factor Types" registry with Specification Required procedure. Initial entries are: 0 (Reserved) and 1 (SF-NONE). Positive values are for public algorithms; negative values for private/experimental use; zero is reserved.
IANA has established the "Kerberos SPAKE Groups" registry with Specification Required procedure. Initial entries are: 1 (edwards25519, SHA-256), 2 (P-256, SHA-256), 3 (P-384, SHA-384), 4 (P-521, SHA-512). Each entry specifies serialization, multiplier length/conversion, and SPAKE M/N constants.
A stateless KDC MUST maintain confidentiality and integrity of its PA-FX-COOKIE (which holds scalar x and transcript hash). The KDC SHOULD limit cookie replay windows with a timestamp and SHOULD bind cookies to specific pre-authentication mechanisms and client principals.
An active attacker posing as the KDC can downgrade a client to encrypted timestamp pre-authentication. Client implementations SHOULD provide a per-realm configuration option to disable encrypted timestamp pre-authentication, and SHOULD assume timestamp/challenge mechanisms are unlikely to succeed after a second-pass SPAKE failure with SF-NONE.
Deserialized public keys S and T MUST be verified to be elements of the group to prevent invalid curve attacks. Cofactor multiplication is ensured by requiring private scalars x and y to be divisible by the cofactor h. The M and N constants MUST NOT have known discrete logarithms.
Implementations MUST avoid side channels, particularly timing channels, in the computation of w and the multiplications wM and wN. Generation of scalar values x and y need not be constant-time, but the time taken MUST NOT reveal information about the resulting value. P-521 requires special care due to its extra high bits in the multiplier input.
Reflection attacks on encdata messages are prevented because client-originated messages use K'[odd n] and KDC-originated messages use K'[even n], so any reflected message would be decrypted with the wrong key and fail.
The support and challenge messages are unauthenticated plaintext; downgrade attacks will result in the client and KDC deriving different keys, detected upon decryption. Second-factor challenge data SHOULD NOT be displayed to users as it could be modified by an attacker to contain misleading content. The KDC-REP message plaintext is not protected by this mechanism.
This mechanism does not directly provide the KDC Authentication facility because no key confirmation is sent from the KDC to the client. When used as a stand-alone mechanism, the existing KDC authentication in the KDC-REP enc-part still applies.
KEY_USAGE_SPAKE is assigned the value 65 and is used as the key usage number for all EncryptedData fields in the SPAKE exchange (both the factor field of SPAKEResponse and subsequent encdata messages).