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

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-httpauth-scram-auth-14: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-scram-auth/



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

- 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

- 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

- 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? (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."

- 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
think you need to explain the former and should explain the latter.

- 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? 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? (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.

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

- 5, is it ok for a client to increment the nonce-count by >1?  (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.

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

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06254.html