Re: [secdir] SecDir Review of draft-ietf-httpauth-scram-auth-11

[Alexey Melnikov <[e-mail]>]

Hi Russ,
I am quickly replying to your major concerns below.

On 01/12/2015 17:54, Russ Housley wrote:
> I reviewed this document as part of the Security Directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the Security Area
> Directors.  Document authors, document editors, and WG chairs should
> treat these comments just like any other IETF Last Call comments.
>
> Version reviewed: draft-ietf-httpauth-scram-auth-11
>
> Summary: Not Ready
>
>
> Major Concerns:
>
> The document claims that SCRAM is better than authentication a plaintext
> password protected by TLS and that it has better deployment properties
> than earlier TLS-protected challenge response authentication mechanisms.
> Please add a few sentence to the Introduction that justifies these
> claims.
Ok. Some text exists in RFC 5802, but I can copy it here.
> Section 5 says: "The "server-first-message" contains the user's
> iteration count i, the user's salt, and the nonce with a
> concatenation of the client-specified one with a server nonce."
> It needs to be more clear that the nonce is a concatenation of the
> client nonce from the client-first-message and a freshly generated
> nonce by the server.
This is described in RFC 5802, which is a normative reference.
> Section 5 goes on to say: "The latter has the same nonce and a
> ClientProof computed using the selected hash function (e.g.  SHA-256)
> as explained earlier."  Please be clear that this is the nonce from the
> server-first-message (not the one from the client-first-message).
Ok.
> Section 5.1 says: "[[CREF1: Should some counter be added to make
> "sr" unique for each reauth?]]".  This needs to be specified.  In my
> opinion, something needs to be done to make the AuthMessage different
> for each invocation.  One possibility is to include a counter in
> AuthMessage as follows:
>
>        AuthMessage := client-first-message-bare + "," +
>                       server-first-message + "," + counter + "," +
>                       client-final-message-without-proof
This was fixed in -12.
> Section 8 says: "A hostile server can perform a computational
> denial-of-service attack on clients by sending a big iteration count
> value."  The document could suggest that a client implementation pick
> a maximum iteration count that it is will to perform, and that it
> reject any values that exceed that threshold, and of course, failing
> the authentication.
Ok.

Best Regards,
Alexey