Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input

[Benjamin Kaduk <[e-mail]>]

On Thu, 14 May 2015, Benjamin Kaduk wrote:

> On Thu, 14 May 2015, Watson Ladd wrote:
>
> > On May 13, 2015 9:05 AM, "Nico Williams" <[e-mail]> wrote:
> > >
> > >
> > > That depends on how its salted.  For our purposes, in practice it's not.
> >
> > Not true: w comes from a much smaller list of values. If it was
> > uniformly distributed over a wide range, we could use it as a key
> > directly.
>
> In the scheme kitten is considering, w is an existing kerberos long-term
> (password-derived) key, so at least 128 bits and with no clear structure.

Now that I am awake (i.e., not falling asleep), I should clarify that w is
planned to be the output of a KDF or PRF construction keyed on the
kerberos long-term key I mentioned, not the key itself.  (I don't think
this was very clear in the -00, though, and we discussed it on the list a
fair amount.)

To give something of a summary of the propsal with background from
kerberos:

In kerberos, we have password-derived keys that are used for initial user
authentication; the KDC ends up sending a response with session key,
encrypted in the long-term password-derived key.  (Sometimes the user
sends a timestamp encrypted in that key as "pre-authentication".)
Regardless, an attacker can easily get a ciphertext in this
password-derived key, and since some users will always pick weak
passwords, some of this traffic will succumb to a brute-force guessing
attack.

The proposal in draft-mccallum-kitten-krb-spake-preauth is to use SPAKE(2)
as a zero-knowledge proof, not of the password itself, but rather of the
password-derived kerberos key, so that existing kerberos deployments can
seamlessly be upgraded to use this new preauthentication scheme which does
not expose ciphertexts in the password-derived key to an attacker.  As an
additional feature, it allows for a second factor to be included in the
key exchange in a fashion such that an attacker trying online guessing
cannot tell which of the password or second factor was incorrect.  So, the
"password" input to spake is not the user's actual password, but rather
this kerberos long-term password-derived key, which has already been
through a salted PBKDF2 (or similar, for older enctypes).  As is normal
for use of long-term kerberos keys, it will go through a key-derivation
step before being used.

Hopefully that gives some background to the questions we were asking for
input on.

-Ben