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

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 07 December 2015 11:26 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 006E01A911F; Mon, 7 Dec 2015 03:26:54 -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 SL5Byh0Ykb_T; Mon, 7 Dec 2015 03:26:53 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id DBE341A9053; Mon, 7 Dec 2015 03:26:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1449487612; d=isode.com; s=selector; i=@isode.com; bh=/m90woFbqaSHH4Q3hczl9q7mHjiiHMOK62lteUvrO2I=; 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=Vpr0+uPD3/MEPRqQ+REWQVGwplQOMutokZrKq+ZYKWxnGWStwORRFvkFdneUs4TdT+Naj3 V2MRa28meFg46guEQzv1jBBmmgDYypcXzUXi4v7Jqsdsk+dx3gj7q4QAMpisn2g7b2GrKH jTdnEOvaLXzrqC2klgEquLLpKXcMRW0=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <VmVs-gArT4hL@waldorf.isode.com>; Mon, 7 Dec 2015 11:26:51 +0000
Message-ID: <56656CF9.5030903@isode.com>
Date: Mon, 07 Dec 2015 11:26:49 +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>
References: <B8DA7647-3F10-4D46-B416-2DC905E4807F@vigilsec.com> <565DE69B.6040805@isode.com> <7FDE5317-FB1F-45AE-A4FC-7392823DCC94@vigilsec.com>
In-Reply-To: <7FDE5317-FB1F-45AE-A4FC-7392823DCC94@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/qbk0c6NaxQ6J8XoIh9ZKzVTQetQ>
Cc: IETF SecDir <secdir@ietf.org>, draft-ietf-httpauth-scram-auth.all@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: Mon, 07 Dec 2015 11:26:54 -0000

Hi Russ,

On 01/12/2015 19:13, Russ Housley wrote:
> Alexey:
>
> Continuing the discussion on two of my major concerns.
>
>>> 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.
> I looked before sending this comment, and I did not find anything about freshness.
> Can you point me to the text I missed?
That was always the intent, but I clarified this directly in the draft.
>>> 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.
> I just looked at the text in -12, and I think it needs to be more clear about the
> number of octets that are used to represent nonce-count.
There is ABNF which says it is a number (in decimal) with no leading zeroes.
> Perhaps you can
> use INT().  If you use INT(), please define it as a bullet of its own in Section
> 1.2.
Best Regards,
Alexey