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

Russ Housley <housley@vigilsec.com> Tue, 01 December 2015 17:55 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C11D21B2DF4; Tue, 1 Dec 2015 09:55:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id MULhjPgxBAlj; Tue, 1 Dec 2015 09:55:33 -0800 (PST)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net []) by ietfa.amsl.com (Postfix) with ESMTP id ADD561B2D4D; Tue, 1 Dec 2015 09:55:33 -0800 (PST)
Received: from localhost (unknown []) by odin.smetech.net (Postfix) with ESMTP id 4CEE1F2406E; Tue, 1 Dec 2015 12:55:23 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([]) by localhost (ronin.smeinc.net []) (amavisd-new, port 10024) with ESMTP id CV3PuNAFsCGw; Tue, 1 Dec 2015 12:54:13 -0500 (EST)
Received: from [] (pool-108-51-128-219.washdc.fios.verizon.net []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 36F75F24041; Tue, 1 Dec 2015 12:55:09 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue, 1 Dec 2015 12:54:58 -0500
Message-Id: <B8DA7647-3F10-4D46-B416-2DC905E4807F@vigilsec.com>
To: draft-ietf-httpauth-scram-auth.all@ietf.org
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/m74Y-wMeAFbY8tDhhRh3fNIaeSw>
Cc: IETF SecDir <secdir@ietf.org>
Subject: [secdir] SecDir Review of draft-ietf-httpauth-scram-auth-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2015 17:55:35 -0000

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

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 + "," +

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.


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

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/