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

[Stephen Farrell <[e-mail]>]

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