[kitten] SPAKE preauth behavior on wrong password

[Greg Hudson <[e-mail]>]

In SPAKE preauth, the client sends a key confirmation in the
SPAKEResponse message in the form of an encrypted SPAKESecondFacter
message, using a derived key.  If decryption succeeds, the client used
the correct initial reply key.  If it fails, the client probably used
the wrong initial reply key, which may have resulted from the user
entering the wrong password.  (Less likely possibilities include parts
of the AS exchange being altered in flight, or an interoperability bug.)

The SPAKE draft currently says:

    If decryption is successful, the first factor is successfully
    validated. The KDC then validates the second factor. If either
    factor fails to validate, the KDC SHOULD respond with an appropriate
    KRB-ERROR message.

I think "an appropriate KRB-ERROR message" is probably too vague, and we
should specify what error code to use.  That error code should probably
be KDC_ERR_PREAUTH_FAILED, per RFC 4120 section 3.1.3 and RFC 6113
section 2.  The draft also doesn't say what should be done in the second
pass if the KDC doesn't support any of the client's groups.

RFC 6113 section 2 encourages clients to continue trying to
pre-authenticate after a PREAUTH_FAILED error, either using METHOD-DATA
included in the error or by sending an unauthenticated reques to get
METHOD-DATA.  In context, the motivation for that recommendation may be
optimistic preauth (the client might try to do opstimistic encrypted
timestamp using the wrong salt, for instance), but that recommendation
is also important if a multi-hop mechanism can fail to negotiate
parameters.  For instance, a client might send a SPAKESupport message
and get back a PREAUTH_FAILED error because the KDC doesn't support any
of the groups it offers.

Following this recommendation has an unfortunate result when the wrong
password is entered: the client will self-downgrade to encrypted
timestamp (if the KDC offered it and the client allows it), unless it
has specific logic not to try encrypted timestamp after a PREAUTH_FAILED
reply to a SPAKEResponse message which used SF-NONE.  A passive attacker
could then mount an offline dictionary attack against the wrong
password; from the incorrect password it might only take a few guesses
to find the correct one.  I think we just want to make a note of this in
the security considerations.

I therefore propose the following updates:

* In the "Second Pass" subsection, after "... the KDC MAY select another
  group in hopes that the client might support it", add "Otherwise, the
  KDC MUST respond with a KDC_ERR_PREAUTH_FAILED error."

* Change "SHOULD respond with an appropriate KRB-ERROR message" to
  "SHOULD respond with a KDC_ERR_PREAUTH_FAILED error".

* In security considerations in the "Dictionary Attacks" subsection, add
  a second paragraph (after the one describing an active downgrade
  attack):

    If the user enters the wrong password, the client may fall back to
    encrypted timestamp after receiving a KDC_ERR_PREAUTH_FAILED error
    from the KDC, if encrypted timestamp is offered by the KDC and not
    disabled by client configuration. This fallback will enable a
    passive attacker to mount an offline dictionary attack against the
    incorrect password. Client implementations MAY assume that encrypted
    timestamp is unlikely to succeed if SPAKE pre-authentication fails
    in the second pass and no second factor was used.