Re: [kitten] SPAKE Preauth

[Greg Hudson <[e-mail]>]

On 04/27/2015 08:45 AM, Nathaniel McCallum wrote:
> I have finally finished the first edition of SPAKE Preauth. You can
> read it at this link:
> http://www.ietf.org/id/draft-mccallum-kitten-krb-spake-preauth-00.txt

I think this mechanism has a lot of potential, and I hope the kitten
working group will adopt this document.  There is a lot of work to be
done at the detail level, but I think the general shape of the mechanism
is about right.

I think this mechanism addresses three under-served scenarios:

1. A realm administrators are concerned (or ought to be concerned) about
the potential for offline dictionary attacks conducted by an adversary
using passive network surveillance.  The realm is using only passwords
for user authentication and does not have the resources to deploy a
second factor.  Encrypted timestamps are in use but do not protect
against a network listener.

There are several other ways to address this use case, including FAST.
But SPAKE preauth can be deployed more easily than FAST--perhaps even
turned on by default--and does not require as many changes to other
layers to make deployment easier.

2. A realm is using passwords for user authentication, and the
administrators want to add a traditional OTP second factor (like Yubikey
or RSA tokens) for some or all principals.  FAST-OTP is designed to
replace, rather than augment, the use of Kerberos long-term keys, and is
therefore not easy to apply to this situation.

In this use case, SPAKE preauth is used with a second-factor challenge
in the second pass, and the token value is transmitted inside the key
confirmation.  The KDC issues a ticket if key agreement succeeded and
the token value is valid, and responds with an error if either is wrong.
 If there are no side channels, an attacker can't tell which factor was
guessed incorrectly.

3. Same as (2), but the realm administrators want to add a Duo-style
second factor.  In this style, the password needs to be validated first,
and then the user is presented with a choice of options for the second
factor.  Depending on the choice, there may or may not be an OTP value
presented to the KDC for validation.

In this use case, SPAKE preauth is used without a second-factor
challenge in the second pass, but additional challenge/responses occur
after key agreement.  An attacker does get to make on-line guesses at
the password separately from the second factor, but is unable to cause
nuisance second-factor challenges (such as pushes to the user's mobile
device) without knowledge of the password.