Kerberos SPAKE with Two-Factor Authentication

Introduction A password-derived long-term key is commonly used in the Kerberos pre-authentication stage to protect messages exchanged between a Kerberos client and a Key Distribution Center (KDC). As noted in , an attacker can mount brute-force password attacks via eavesdropping a legitimate credential returned by the KDC or a legitimate authentication message sent by the client, which are both encrypted by the long-term key. A Kerberos SPAKE pre-authentication mechanism is proposed in , it uses a simple password-authenticated key exchange (SPAKE) to protect against brute-force password attacks, and additionally enables two-factor authentication (2FA). For example, the second-factor (SF) authentication may include one-time passwords, challenge/response signatures, and biometric data. As suggested in , the SF authentication data can be first encrypted using the key established by the PAKE and then securely transferred from the client to the KDC for verification, where the password verification happens implicitly by a successful decryption of the SF authentication data. However, this 2FA methodology does not achieve the security of true two-factor authentication, which requires that the compromise of any factor will not affect the security of whole 2FA protocol. More specifically, in case of password leakage, an attacker can use the leaked password to successfully perform a man-in-the-middle (MITM) attack against the Kerberos SPAKE, i.e., the client establishes a Kerberos SPAKE session A with the attacker and the attacker establishes a Kerberos SPAKE session B with the KDC. In this case, the attacker can obtain the SF authentication data in plaintext from the session A, and can use it as a valid second-factor in session B. Therefore, only the password factor allows the attacker to pass the KDC's two-factor authentication. To remedy the above problem, this document defines a new two-factor authentication mechanism for the Kerberos SPAKE pre-authentication, which uses the widely deployed time-based one-time password (TOTP) as a second factor. The mechanism combines the second factor with the password factor in the following way: the resulting TOTP value is combined with the PAKE's shared key to derive at least two encryption keys at both the client and KDC sides, then the client sends a second-factor challenge encrypted by one key to the KDC for verification and the KDC sends the TGT's session key encrypted by another key to the client for TGT issuance. As a result, if an attacker compromises either of factors, it also needs to obtain another factor's authentication data to derive the final encryption keys, which are necessary to pass the two-factor authentication or obtain the TGT's session key. But this is hard to do if the authentication of another factor is still secure.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The terms "encryption type" and "random-to-key" are defined in .

Kerberos SPAKE Pre-authentication with Second-Factor TOTP

Two-Factor Authentication Overview The SPAKE algorithm combined with the TOTP algorithm can be generally described in the following steps:

Calculation and exchange of the public key.
Calculation of the shared SPAKE result (K1).
Calculation of the shared TOTP result (K2).
Derivation of an encryption key (K') from both the result K1 and K2.
Verification of the derived encryption key (K').

In this mechanism, key verification happens implicitly by a successful decryption of the SF challenge data specific to the second-factor TOTP.

Introduction of the TOTP Algorithm As defined in , the HOTP algorithm is based on the HMAC-SHA-1 algorithm and is computed as follows: where K and C represent the shared secret and counter value, and Truncate represents the function that can convert an HMAC-SHA-1 value into an HOTP value; see for detailed definitions. Recall that in , the TOTP algorithm is defined as TOTP = HOTP(K, T), where T is an integer and represents the number of time steps between the initial counter time T0 (default value is 0, i.e., the Unix epoch) and the current Unix time. Note that TOTP implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 functions, please refer to .

Definition of the Second-Factor TOTP Recall that in , each second factor is represented by a SPAKESecondFactor. The type field is a unique integer that identifies the second-factor type, and the data field contains optional challenge data. This document defines the type as an integer 2 to identify the second-factor TOTP, and defines the data as a random nonce whose length SHOULD match the multiplier length of the negotiated group, where the multiplier length is defined in .

Key Derivation The SPAKE result and the TOTP result are both used to derive keys K'[n] as defined in this section. The intermediate key is produced from the SPAKE result and other relevant values, please refer to . Unlike the computation in , the key K'[n] is computed as follows:

A pepper string is generated by concatenating the string "SF-TOTP" and the TOTP result as an octet string.
An octet string is derived using PRF+(initial-reply-key, pepper), where PRF+ is defined in .
An update reply key is produced from the octet string using the random-to-key function, which has the same encryption type as the initial reply key.
The key K'[n] has the same encryption type as the update reply key, and has the value KRB-FX-CF2(update-reply-key, intermediate-key, "SPAKE", "keyderiv"), where KRB-FX-CF2 is defined in .

Second-Factor Types This document defines one second-factor type: This second-factor type indicates that the TOTP second factor is used.

IANA Considerations This document defines a new second-factor type "SF-TOTP" with the following contents, and requests that IANA add it to the "Kerberos Second-Factor Types" Registry defined in .