[kitten] SPAKE preauth behavior on wrong password

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[kitten] SPAKE preauth behavior on wrong password

Greg Hudson
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.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE preauth behavior on wrong password

Robbie Harwood
Greg Hudson <[hidden email]> writes:

> 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.
>
> * 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.
I would be tempted to use "SHOULD" here rather than "MAY", but otherwise
I think this is good.

(The rest is fine by me as well.)

Thanks,
--Robbie

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE preauth behavior on wrong password

Henry B (Hank) Hotz, CISSP-2
In reply to this post by Greg Hudson

> On Oct 3, 2017, at 8:10 AM, Greg Hudson <[hidden email]> wrote:
>
> 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

To be more explicit about the actual security implication, insert: "which is likely close to the correct password."

> . Client implementations MAY

Agree with SHOULD instead of MAY.

> assume that encrypted
>    timestamp is unlikely to succeed if SPAKE pre-authentication fails
>    in the second pass and no second factor was used.

Should we say anything about other, e.g. FAST-based alternatives?

Personal email.  [hidden email]



_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE preauth behavior on wrong password

Greg Hudson
On 10/03/2017 02:02 PM, Henry B (Hank) Hotz, CISSP wrote:
> To be more explicit about the actual security implication, insert: "which is likely close to the correct password."
[...]
> Agree with SHOULD instead of MAY.
[...]
> Should we say anything about other, e.g. FAST-based alternatives?

Revised proposed security considerations text:

    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, which may be similar to the correct password.
    Client implementations SHOULD assume that encrypted timestamp and
    encrypted challenge are unlikely to succeed if SPAKE
    pre-authentication fails in the second pass and no second factor
    was used.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE preauth behavior on wrong password

Robbie Harwood
Greg Hudson <[hidden email]> writes:

> On 10/03/2017 02:02 PM, Henry B (Hank) Hotz, CISSP wrote:
>> To be more explicit about the actual security implication, insert: "which is likely close to the correct password."
> [...]
>> Agree with SHOULD instead of MAY.
> [...]
>> Should we say anything about other, e.g. FAST-based alternatives?
>
> Revised proposed security considerations text:
>
>     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, which may be similar to the correct password.
>     Client implementations SHOULD assume that encrypted timestamp and
>     encrypted challenge are unlikely to succeed if SPAKE
>     pre-authentication fails in the second pass and no second factor
>     was used.
Happy with this, thanks!

--Robbie

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE preauth behavior on wrong password

Benjamin Kaduk-2
On Tue, Oct 03, 2017 at 03:56:04PM -0400, Robbie Harwood wrote:

> Greg Hudson <[hidden email]> writes:
>
> > On 10/03/2017 02:02 PM, Henry B (Hank) Hotz, CISSP wrote:
> >> To be more explicit about the actual security implication, insert: "which is likely close to the correct password."
> > [...]
> >> Agree with SHOULD instead of MAY.
> > [...]
> >> Should we say anything about other, e.g. FAST-based alternatives?
> >
> > Revised proposed security considerations text:
> >
> >     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, which may be similar to the correct password.
> >     Client implementations SHOULD assume that encrypted timestamp and
> >     encrypted challenge are unlikely to succeed if SPAKE
> >     pre-authentication fails in the second pass and no second factor
> >     was used.
>
> Happy with this, thanks!
Me, too.

Though I would consider s/may/might/ in the first line, to appease people
who dislike non-capitalized RFC 2119 terms.

-Ben

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

signature.asc (681 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] SPAKE preauth behavior on wrong password

Henry B (Hank) Hotz, CISSP-2
Also happy. Abstain on the /may/might/ issue.

> On Oct 3, 2017, at 6:17 PM, Benjamin Kaduk <[hidden email]> wrote:
>
> On Tue, Oct 03, 2017 at 03:56:04PM -0400, Robbie Harwood wrote:
>> Greg Hudson <[hidden email]> writes:
>>
>>> On 10/03/2017 02:02 PM, Henry B (Hank) Hotz, CISSP wrote:
>>>> To be more explicit about the actual security implication, insert: "which is likely close to the correct password."
>>> [...]
>>>> Agree with SHOULD instead of MAY.
>>> [...]
>>>> Should we say anything about other, e.g. FAST-based alternatives?
>>>
>>> Revised proposed security considerations text:
>>>
>>>    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, which may be similar to the correct password.
>>>    Client implementations SHOULD assume that encrypted timestamp and
>>>    encrypted challenge are unlikely to succeed if SPAKE
>>>    pre-authentication fails in the second pass and no second factor
>>>    was used.
>>
>> Happy with this, thanks!
>
> Me, too.
>
> Though I would consider s/may/might/ in the first line, to appease people
> who dislike non-capitalized RFC 2119 terms.
>
> -Ben

Personal email.  [hidden email]



_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten