Re: [http-auth] Stephen Farrell's Yes on draft-ietf-httpauth-scram-auth-14: (with COMMENT)

[Alexey Melnikov <[e-mail]>]

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
>