Telechat Review of draft-ietf-httpauth-scram-auth-11
review-ietf-httpauth-scram-auth-11-secdir-telechat-housley-2015-12-03-00

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.

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.

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).

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

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.


Minor Concerns:

I think the Abstract covers some material that belongs in the
Introduction.  For example, the fact that HTTP Digest did not get
wide deployment does not help the reader decide if they want to
read this document.  I suggest:

   This specification describes a family of HTTP authentication
   mechanisms called the Salted Challenge Response Authentication
   Mechanism (SCRAM), which provides a more robust authentication
   mechanism than a plaintext password protected by Transport Layer
   Security (TLS) and avoids the deployment obstacles presented by
   earlier TLS-protected challenge response authentication mechanisms.
   
Then, please add the information that was removed from the Abstract
to a new paragraph in the Introduction.

I think the document would be easier to digest if the Introduction
came before the current Section 1, "Conventions Used in This Document".

Section 7 says: "The "UTF8-2", "UTF8-3" and "UTF8-4" non-terminals are
defined in [RFC3629]."  These non-terminals are not used in Section 7.
   

Nits:

Section 1.1 says: "For network-level protocols such as PPP or 802.11x,
the use of RADIUS [RFC2865] is more common."  PPP and 802.11 are not
network-level protocols.  To avoid getting too picky, it might be best
to say, "For lower-layer protocols such as ..."

I think it would be more readable if the Hi function were described in
its own section.  Also, since the INT function is only used in this one
place to handle a constant, I wonder if 0x00000001 would be easier to
understand.

The paragraph beginning with "Formally" in Section 5.1 does not need an
extra level of indentation.

In Section 3: s/it's useful/it is useful/