Subject: [kitten] SPAKE and not replying to requests

From: Greg Hudson <[email-masked]>
Date: Tue, 22 Aug 2017 12:45:50 -0400

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 responds with an appropriate
    KRB-ERROR message.

Nathaniel and I recently discussed some scenarios where the KDC might
want to drop the request without replying:

1. The second-factor implementation is stateful, and the KDC which
received the request doesn't have the requisite state.

2. The second-factor type isn't recognized by the KDC, but another KDC
in the realm running a more recent version of the KDC code might be able
to handle it.

3. A KDC might not want to reveal timing information to an attacker, for
the purposes of indistinguishability (making it difficult to tell
whether the first factor validated).

On further consideration, (3) is a bit unlikely--it would yield a bad
user experience whenever a user mistypes their password.  Doing (1) or
(2) without (3) also breaks indistinguishability, but KDCs aren't
required to implement indistinguishability.

I propose to change this text to:

    [...] If either factor fails to validate, the KDC SHOULD respond
    with an appropriate KRB-ERROR message.  The KDC MAY choose not to
    respond to the request, with the expectation that the client will
    retry against other KDC servers within the realm.

---

From: Robbie Harwood <[email-masked]>
Date: Tue, 22 Aug 2017 14:16:57 -0400

Greg Hudson <[email-masked]> writes:

> in the realm running a more recent version of the KDC code might be
> able to handle it.
>
> 3. A KDC might not want to reveal timing information to an attacker,
> for the purposes of indistinguishability (making it difficult to tell

I wonder if we should be more explicit about what the client should do
if it doesn't get a reply from the server here.  Maybe something like,
e.g., "The KDC MAY choose not to respond to the request, at which point
the client SHOULD retry against other KDC servers within the realm." or
so?

Thanks,
--Robbie

---

From: Greg Hudson <[email-masked]>
Date: Wed, 23 Aug 2017 11:58:46 -0400

> the client SHOULD retry against other KDC servers within the realm." or

I would prefer that this document not get into the weeds of client-KDC
network communication, but looking at RFC 4120, I think you are right
that nothing really says what the client should do in the face of a
timeout.  There are also cases where a client might not be able to reach
all KDC processes for a realm (network load balancers, MIT krb5 KDC
worker processes, etc.), so perhaps black-holing requests is a hack we
shouldn't encourage in the standard.

With that in mind, I guess I just want the text to say:

    If either factor fails to validate, the KDC SHOULD respond with an
    appropriate KRB-ERROR message.

with no further discussion of what a KDC might choose to do instead.

---

From: Robbie Harwood <[email-masked]>
Date: Wed, 23 Aug 2017 16:33:44 -0400

> with no further discussion of what a KDC might choose to do instead.

Agreed, that makes sense to me.

Thanks,
--Robbie

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 28 Aug 2017 20:07:40 -0500

> Agreed, that makes sense to me.

It makes sense to me as well.

-Ben

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Tue, 29 Aug 2017 16:51:33 -0700

‘sarright. ;-)

> On Aug 28, 2017, at 6:07 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

Personal email.  [email-masked]