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

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 01 December 2015 18:27 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FFD1B2EBA; Tue, 1 Dec 2015 10:27:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCxi6Y7JQyhY; Tue, 1 Dec 2015 10:27:54 -0800 (PST)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (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; d=isode.com; s=selector; i=@isode.com; 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 [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <Vl3mpgAlTk08@statler.isode.com>; Tue, 1 Dec 2015 18:27:50 +0000
Message-ID: <565DE69B.6040805@isode.com>
Date: Tue, 01 Dec 2015 18:27:39 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
To: Russ Housley <housley@vigilsec.com>, draft-ietf-httpauth-scram-auth.all@ietf.org
References: <B8DA7647-3F10-4D46-B416-2DC905E4807F@vigilsec.com>
In-Reply-To: <B8DA7647-3F10-4D46-B416-2DC905E4807F@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/cgxhP__EorkWPWoI1WnFwKltbnk>
Cc: IETF SecDir <secdir@ietf.org>
Subject: Re: [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 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).
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