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

Alexey Melnikov <> Tue, 01 December 2015 18:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C5FFD1B2EBA; Tue, 1 Dec 2015 10:27:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GCxi6Y7JQyhY; Tue, 1 Dec 2015 10:27:54 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 71FC61B2EB5; Tue, 1 Dec 2015 10:27:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1448994470;; s=selector;; bh=ZEOzocmdMe72CK2NiC5otiDmlgghFC2CpYY1LQstMBc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=uthv4Z+e7qvA0JR0fue4nKjWE5XcuIgm+ZvX04UjG3XLh8FSsvP4Xy7RhOfx4VzcUPgYo4 t9vtW440RYC0AFvVYlB7XLiDpjXg+u1VGCQkpQcXBDWwS4L7os9M1CwZzBvUuB/AA2Yw0T kW5iU+D3nMwCqvBqsIpWPQNfsgU+9qQ=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Tue, 1 Dec 2015 18:27:50 +0000
Message-ID: <>
Date: Tue, 01 Dec 2015 18:27:39 +0000
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
To: Russ Housley <>,
References: <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: IETF SecDir <>
Subject: Re: [secdir] SecDir Review of draft-ietf-httpauth-scram-auth-11
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Dec 2015 18:27:55 -0000

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

Best Regards,