View source for Projects/Improve OTP deployability

{{project-early}}

This project page describes several options for improving the deployability and security of OTP within MIT krb5.

==Background==

MIT krb5 implements an OTP preauth mechanism specified in {{rfcref|6560}}.  The KDC uses a RADIUS server to verify OTP values submitted by the client.  The specification and its implementation in MIT krb5 have several deployability limitations:

* The FAST channel must authenticate the KDC (or an active attacker could steal the OTP value from the client).  This requires either that the client have access to a ticket derived from the host key, or that the client can verify the KDC's PKINIT certificate.
* In the current implementation, OTP cannot be combined with the Kerberos long-term key.  Instead, the user's password must be treated as an OTP PIN, transmitted to the KDC, and verified by the RADIUS server, so the RADIUS server must have access to passwords or verification hashes for the principal.
* It is not currently possible to make kinit use FAST transparently; it has to be explicitly specified by the user.

==Requirements==

The following deployment properties are desirable for some sites, including Stanford and MIT:

* It should be possible to transition a user from a normal long-term password to OTP two-factor authentication, retaining the user's existing password as one of the factors.
* It should be possible to administratively remove OTP as a factor while retaining the same long-term password, in cases where the hardware OTP token is lost.
* It should be possible to deploy OTP without requiring either keytab access or KDC public key certificate verification on the client.  This implies that the password must be leveraged to authenticate the KDC, without transmitting the password to the KDC.

The following security properties are desirable, but may not all be practical:

* An attacker who tries to guess the password and OTP value cannot find out which factor is wrong, only that both are correct or both are incorrect.
* An attacker who knows the password cannot obtain an OTP value through passive monitoring of a legitimate exchange.
* An attacker who knows the password cannot obtain an OTP value through an active attack against a legitimate exchange.

The client implementation should be able to prompt for the password and OTP value at the same time, rather than prompting for the password and then prompting again for the OTP value.

The underlying OTP mechanism is assumed not to be key-generating; that is, the KDC can verify an OTP value through some back-end mechanism but cannot determine what it should be.  This means the client must transmit the OTP value to the KDC, but must be careful not to transmit the OTP value to an attacker impersonating the KDC.

==Protocol design possibilities and challenges==

This section describes some possible preauth extensions which address some of the deployability concerns, and their associated challenges.

===PAKE FAST armor with OTP preauth===

In this design, a new FAST armor type (an alternative to ticket armor) is specified and implemented.  The new armor type uses a PAKE exchange with the principal's long-term key.  Within the resulting FAST channel, the client performs OTP preauthentication using the OTP value.

Weaknesses of this design include:

* We don't really have a negotiation mechanism for FAST armor types, other than "try one, then try another" which is slow and subject to downgrade attacks.
* FAST armor requests can only be one round trip with the client speaking first [XXX confirm? {{rfcref|6113}} isn't explicit about this].  With such a restriction, any PAKE protocol will allow the client to find out whether it used the correct password before the KDC does, allowing it to conduct an online attack without being restricted by account lockout.
* The password factor can be attacked independently of the OTP factor.
* The client implementation must prompt for a password (for the FAST armor) before it knows that an OTP token is required, so it cannot prompt for both pieces of information at the same time.

===Unverified anonymous PKINIT FAST armor with encrypted challenge and OTP (in serial)===

In this design:

* Our FAST and preauth framework code is extended to track whether the KDC is verified.
* Our anonymous PKINIT client module is extended to allow the KDC to remain unverified.
* Our OTP client module is extended so that it refuses to send values to an unverified KDC.
* Our encrypted challenge module is extended to note that the KDC is verified.
* We implement multi-round-trip preauth and {{rfcref|6113}} preauth sets, on the client and the KDC.
* Within a FAST channel, the KDC offers a preauth set beginning with encrypted challenge and continuing with OTP.

Weaknesses of this design include:

* An active attacker can split the anonymous PKINIT channel into two, one between the client and attacker and a second between the attacker and KDC.  These channels will necessarily have different armor keys.  Because encrypted challenge binds to the armor key, the attacker cannot successfully perform encrypted challenge to the KDC, but the attacker does receive a ciphertext from the client with which it can perform an offline attack against the client password.  (There are usually easier ways to get the client to produce such a ciphertext, such as offering the client encrypted timestamp without FAST, but in a locked-down client configuration this might not be possible.)
* Even without an active attack, the password factor can be attacked independently of the OTP factor (but this attack is at least subject to the password lockout policy).
* An attacker who knows the password can capture an OTP value using an active attack.
* Performing encrypted challenge and OTP in sequence requires an extra round trip.
* Arranging to prompt for the password and OTP value at the same time might be problematic.  {{rfcref|6560}} does not define a pa-hint for use in preauth sets, and the initial preauth set offer cannot include a pa-value for the second mechanism.  The client could prompt for an OTP value with the password based on the knowledge that OTP is part of the preauth set, but the challenge at the point where it needs the password to continue.
* The OTP mechanism resets the reply key to the armor key, which unnecessarily weakens the exchange because the long-term key does not contribute to protecting the ticket.  No obvious additional attacks result from this.

===Verified anonymous PKINIT FAST armor with encrypted challenge and OTP (in parallel)===

This design is similar to the above, but instead of implementing {{rfcref|6113}} preauth sets, we specify and implement an alternative to preauth sets which operates in parallel.  The client receives a parallel-preauth set for encrypted challenge and OTP, with an OTP challenge.  Because this design sends the OTP value before the KDC is verified, it can only be used with verified anonymous PKINIT.  Because the anonymous PKINIT exchange verifies the KDC, an attacker cannot split the PKINIT channel and therefore cannot capture an encrypted challenge plaintext.  The password and OTP factors cannot be attacked independently.  No extra round trip is required.

Weaknesses of this design include:

* Because it relies on verified anonymous PKINIT, it sacrifices one of the deployability desirables.
* Specifying parallel preauth sets may be complicated when taking into account all possible interactions between preauth mechanisms.  The interactions between encrypted challenge and OTP are not problematic, though.
* The OTP mechanism still resets the reply key to the armor key, unnecessarily weakening the exchange (but no obvious attacks result).

===Unverified anonymous PKINIT FAST armor with PAKE FAST factor and OTP (in sequence)===

This design is similar to the second design, but instead of encrypted challenge, we specify and implement a PAKE FAST factor, with the following basic design:

# The KDC includes a public value in the preauth hint.
# The client submits a public value and a verifier proving possession of the negotiated key.
# The KDC responds with a verifier proving its possession of the negotiated key.

The KDC must remember its public value, probably using the FAST cookie.  FAST cookies are subject to replays, so this part of the design requires additional analysis.

Once the KDC response has been verified, the FAST channel authenticates the KDC to the client, and the client can safely submit the OTP value.  The PAKE mechanism must bind the negotiated key to the armor key as well as the client long-term key.

Weaknesses of this design are similar to those of the second design.  An active attacker who splits the FAST channel cannot perform an offline attack on the password, but an attacker can conduct an online attack the password separately from the OTP value, subject to the password lockout policy.

===Unverified anonymous PKINIT FAST armor with combo mechanism===

In this design, instead of a preauth set containing two factors, we design a new factor which combines the client long-term key with an OTP value, much like the old SAM-2 mechanism does.  By tightly binding the two factors together, we might reduce the number of round trips or prevent the factors from being attacked separately.

One possible design for the new FAST factor is to simply send the OTP value encrypted in the client key.  This creates an opportunity for an offline attack against the client password unless we (1) do not use {{rfcref|3961}} authenticated encryption, and (2) ensure that the encryption plaintexts are uniformly distributed.  The second property may be difficult since the decryptor must still be able to recover the OTP value.

Another design is a PAKE exchange where the client verifier includes the OTP value.

==General challenges==

PAKE algorithms might have patent issues, particularly if elliptic curve crypto (useful for size and performance) is involved.

If the client is unconfigured as posited in the requirements, an active attacker can bypass most of the security properties of any new mechanism by pretending that the KDC only supports encrypted timestamp.  The prompt might look different in this case (because it won't prompt for an OTP value), but users would typically type their password, generating a ciphertext which is subject to an offline attack.

If the password and OTP value are prompted for at the same time, and the password is leveraged to authenticate the KDC to the client, it follows that any information provided by the KDC which might influence the OTP prompt is unauthenticated.