Re: [http-auth] Stephen Farrell's Yes on draft-ietf-httpauth-scram-auth-14: (with COMMENT)
Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 15 December 2015 13:47 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0013E1A896A; Tue, 15 Dec 2015 05:47:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 9IkVcMVckXqt; Tue, 15 Dec 2015 05:47:50 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF851A8966; Tue, 15 Dec 2015 05:47:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8DEA1BE51; Tue, 15 Dec 2015 13:47:48 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZblrnrHv_wFo; Tue, 15 Dec 2015 13:47:47 +0000 (GMT)
Received: from [172.28.172.2] (unknown [95.83.253.109]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1125CBE50; Tue, 15 Dec 2015 13:47:45 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450187266; bh=YpVnbbu2ATTjJr0vbaV1K1ajFn8LJL54cnB3T+euiLY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Yio+k38rJFXE39gLOE2c6mMy0mLZUW87xfLpLkovV0t9adljhGTBwyGrzVT63y39H eYXoymKrprtZiTOR5r8HoLlfGummHdQ3uWQsLC+ELXw5DPAylwVFG/rsBvseF9dO9G mpefbzD3M5xKCEkmlnF9F70TFuoCC6AoQ1/yoeZI=
To: Alexey Melnikov <alexey.melnikov@isode.com>, The IESG <iesg@ietf.org>
References: <20151214111921.18176.92140.idtracker@ietfa.amsl.com> <56701963.6080400@isode.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <567019FE.70205@cs.tcd.ie>
Date: Tue, 15 Dec 2015 13:47:42 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <56701963.6080400@isode.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/http-auth/KLZ6eehQbRanQtTHpeia-hEzm_s>
Cc: draft-ietf-httpauth-scram-auth@ietf.org, httpauth-chairs@tools.ietf.org, httpauth-chairs@ietf.org, http-auth@ietf.org, draft-ietf-httpauth-scram-auth-all@tools.ietf.org
Subject: Re: [http-auth] Stephen Farrell's Yes on draft-ietf-httpauth-scram-auth-14: (with COMMENT)
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/http-auth/>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Dec 2015 13:47:52 -0000
Fair enough - those all look like good enough responses, Thanks, S. On 15/12/15 13:45, Alexey Melnikov wrote: > > Hi Stephen, > Thank you for your comments. > > On 14/12/2015 11:19, Stephen Farrell wrote: >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> Some of the issues below would be discuss points for a standards >> track draft but I think clarifying these kinds of corner-case issues >> during an experimental deployment should be fine. I think it'd be >> really good if you noted some of these issues and that they were >> things to clarify as part of the experiment. The interleaving issue >> being perhaps the most worthy of noting. >> >> - abstract: the claims seem somewhat overbroad, I hoped those would >> be justified in the text, but I didn't see that tbh. I'd recommend >> toning that down some. > I will check. >> - intro, 1st para, typo: s/have had/has had/ >> >> - intro, 3rd para: s/adoptation/an adaptation/ and s/SCRAM data/ The >> SCRAM data/ in the same para, and s/adds/adds a/ similarly > Fixed. >> - intro, bullet1: where you say "is not sufficient" that can be true >> of cleartext password schemes too, the difference here is that the >> protocol data units must require a dictionary attack, which is good >> but mostly neutral if good back-end practices are in place, but bad >> back-end practices can be in place with SCRAM just as much as with >> cleartext pwds, so I think the claim is not justified in the end >> unless you add "depending on sound implemenation practices" or some >> such. >> >> - intro, bullets 2&3: these should really have a caveat that a >> dictionary attack works and would invalidate the claims made > Ok. >> - 2.1: it is not clear to me how LDAP or RADIUS could be used as an >> authentication DB for SCRAM, unless the cleartext pwd is stored >> there, which would invalidate the claims made in the intro, or are >> there standard ways in both protocols to store SCRAM verifiers that >> are not cleartext passwords? > The latter. See <http://datatracker.ietf.org/doc/rfc5803/> >> (That might be the case, I just don't >> know.) >> >> - 2.2: "may not be included" would be better as "is optional" as the >> former can be read ambiguously to mean "must not be included." > Ok. >> - 2.2: Definition of "Hi" - it is odd to have the "i" twice in the >> formula. >> - 2.2: definition of "Hi" - what is INT(1) and why is it there? > I believe this is from PBKDF2 definition, >> I think you need to explain the former and should explain the latter. > It is defined below Hi(). >> - section 5: Hmm - I didn't realise that HTTP really allows for two >> 401 messages within the same authentication. It isn't clear to me >> that a browser and server can always correctly maintain state for >> that. Are you sure that they can? > I've asked Julian Reschke and he didn't think it was a problem. After > the first exchange a session is established (with session id), it then > can be used to correlate. >> Can't two requests for protected >> resources cross over in HTTP causing server confusion (if the realms >> differ and passwords differ) or maybe even a condition that might >> not represent the client's actual wishes? > The server is supposed to respond to requests in the same order as > received. > Also, HTTP/2.0 makes this problem go away ;-). >> (That said, I've not gone >> and looked if this kind of interleaving is a real problem or not.) >> >> - 5, initial client msg: "a random, unique nonce attributes" is >> ambiguous - is it one ("a random") or many ("attributes"). I think >> you need to be precise. > Should be "attribute". >> - 5, just before 5.1: "might have to drop" is very vague, why? If >> the server auth is broken I think a "MUST drop" has to be correct. > It doesn't have to drop the connection and might do other things. So it > is more like MAY. >> - 5, is it ok for a client to increment the nonce-count by >1? > I assume you are talking about reauthentication case: I don't think so. > But reauthentication can be done multiple times, so the value can be > incremented by more than 1 from the original value. I should make this > clearer, if it isn't already. >> (I assume it is as a request could get lost, albeit that'd be rare and >> mostly down to proxy bugs I suspect.) > >> - section 8: "a successor to SHA-1" is a bit coy and now that Tony >> has defined one I think you can mention the sha256 based scheme. > Changed. >> - Thanks for handling the secdir review [1] and I appreciate that >> the author has pinged the reviewer on that. It'd maybe be no harm to >> re-ping if the reviewer still hasn't had a chance to respond. > Will do. >> [1]https://www.ietf.org/mail-archive/web/secdir/current/msg06254.html >> >
- [http-auth] Stephen Farrell's Yes on draft-ietf-h… Stephen Farrell
- Re: [http-auth] Stephen Farrell's Yes on draft-ie… Alexey Melnikov
- Re: [http-auth] Stephen Farrell's Yes on draft-ie… Stephen Farrell