Projects/Improve OTP deployability

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.

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 RFC 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.

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? RFC 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 RFC 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.)
• 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. RFC 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 RFC 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 also similar to the second design, but instead of encrypted challenge, we specify and implement a PAKE FAST factor.

[TBD: more analysis of this option]

Other challenges

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