Subject: When does scram become prot_ready

From: Sam Hartman <[email-masked]>
Date: Mon, 11 Aug 2008 16:18:22 -0400 (EDT)

I'm assuming that scram does not become prot_ready until the client
final message. Technically the spec could be written so that scram
becomes prot_ready on the server when the server produces its first
message.  I have not thought through the implications of doing
that--in particular whether it opens up any new opportunities for
attacks.

It seems quite clear to me that the scram spec must say when it
becomes prot_ready for there to be a single gs encoding.  If we decide
that it becomes prot_ready earlier than the client final message, then
the ABNF I will be sending later needs to be updated.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Aug 2008 16:04:29 -0500

> the ABNF I will be sending later needs to be updated.

In the ABNF I wrote a while back there were four messages as follows
(ignoring GS2 parts):

1: client->server: username, hash-alg-list, nonce
2: server->client: nonce, hash-alg, salt, iteration-count
3: client->server: client-proof
4: server->client: server-proof

Where the "proofs" are some function of the selected hash function,
nonces, username, salt, shared password, iteration count, direction
flag.

Technically this can become PROT_READY when message #3 is produced
(i.e., on the second call to GSS_Init_sec_context()).

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 11 Aug 2008 17:25:21 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> Technically this can become PROT_READY when message #3 is
    Nicolas> produced (i.e., on the second call to
    Nicolas> GSS_Init_sec_context()).

    Nicolas> Nico --

I actually think it *could* become prot_ready with the second message.
By that point you know all the nonces.
I'm uncomfortable with the security implicatinos of that though.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Aug 2008 16:29:57 -0500

> (i.e., on the second call to GSS_Init_sec_context()).

Duh, it can become PROT_READY when the server produces its first context
token.  But that gives clients material that they can attack off-line,
so let's not do this.

SCRAM should become PROT_READY when the client produces its second
context token.

Nico
--