Projects/Improve OTP deployability - Revision history

Ghudson: /* Unverified anonymous PKINIT FAST armor with PAKE FAST factor and OTP (in sequence) */

2014-09-05T16:22:52Z

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

Ghudson at 16:22, 5 September 2014

2014-09-05T16:22:34Z

Ghudson at 00:21, 27 August 2014

2014-08-27T00:21:00Z

TomYu: New page: {{project-early}} The existing FAST-based OTP currently requires a KDC-authenticated FAST armor in order to use safely for a common OTP back end deployment scenario. (The OTP back end re...

2013-12-13T21:40:54Z

New page: {{project-early}} The existing FAST-based OTP currently requires a KDC-authenticated FAST armor in order to use safely for a common OTP back end deployment scenario. (The OTP back end re...

New page

{{project-early}}

The existing FAST-based OTP currently requires a KDC-authenticated FAST armor in order to use safely for a common OTP back end deployment scenario. (The OTP back end receives the cleartext OTP value from the KDC and verifies it.)

==Use cases==

Some sites (including Stanford and MIT) have a need to transition users from normal a long-term password to an OTP two-factor authentication, while retaining the user's existing long-term password as one of the factors. Additionally, it is useful to transition a user from such an OTP two-factor status to remove the OTP requirement while retaining the same long-term password. (e.g., hardware OTP token is lost and user needs to get work done anyway).

Additionally, existing FAST armors suitable for use with FAST-OTP require deploying either a keytab or a KDC public key certificate (or trust anchor) on the client host. It would make OTP easier to deploy if some FAST armor suitable for FAST-OTP could be deployed with minimal configuration on the client. This probably means developing some kind of PAKE-based FAST armor.

==Challenges==

PAKE armor means that an online attack could potentially discover the user's long-term password without also knowing the OTP values.

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

@@ Line 78: / Line 78: @@
 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 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 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 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.

@@ Line 24: / Line 24: @@
 * 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==
@@ Line 54: / Line 58: @@
 * 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).
+* 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.
@@ Line 65: / Line 69: @@
 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.
@@ Line 71: / Line 76: @@
 ===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.
+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:
 PAKE algorithms might have patent issues, particularly if elliptic curve crypto (useful for size and performance) is involved.

@@ Line 1: / Line 1: @@
 {{project-early}}
-==Use cases==
+==Background==
 PAKE algorithms might have patent issues, particularly if elliptic curve crypto (useful for size and performance) is involved.