Salted Challenge Response HTTP Authentication Mechanism
draft-ietf-httpauth-scram-auth-15
Yes
(Kathleen Moriarty)
No Objection
(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)
Note: This ballot was opened for revision 14 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(2015-12-15 for -14)
Unknown
-- Section 3 -- It sends the username to the server, which retrieves the corresponding authentication information, i.e. a salt, StoredKey, ServerKey and the iteration count i. As this is written, it's not clear whether the "corresponding authentication information" is "a salt" alone, or the whole list of things after. I suggest this: NEW It sends the username to the server, which retrieves the corresponding authentication information: a salt, a StoredKey, a ServerKey, and an iteration count (i). END Why does the paragraph end in a colon ("and sends a ClientProof to the server:")? To begin with, the SCRAM client is in possession of a username and password (*) (or a ClientKey/ServerKey, or SaltedPassword). ...and... (*) - Note that both the username and the password MUST be encoded in UTF-8 [RFC3629]. I suggest that splitting these up with a bunch of text in between isn't a good way to do it. I think this would be better: NEW To begin with, the SCRAM client is in possession of a username and password, both encoded in UTF-8 [RFC3629] (or a ClientKey/ServerKey, or SaltedPassword). END There's no pressing need to use the word "MUST" there. Informative Note: Implementors are encouraged to create test cases that use both username passwords with non-ASCII codepoints. In particular, it is useful to test codepoints whose "Unicode Normalization Form C" and "Unicode Normalization Form KC" are different. It would be good to include an informative reference to the Unicode Normalization Forms document here, so people can easily look up what NFC and NFKC are. It might also be good to say "Normalization Form Canonical Composition (NFC)" and "Normalization Form Compatibility Composition (NFKC)", rather than to use the mixed versions that you have here. -- Section 4 -- from the IANA "Hash Function Textual Names" registry (see http://www.iana.org) . Better, I think, to use the direct URL for the registry (which is fine with IANA): http://www.iana.org/assignments/hash-function-text-names/
Kathleen Moriarty Former IESG member
Yes
Yes
(for -14)
Unknown
Stephen Farrell Former IESG member
Yes
Yes
(2015-12-14 for -14)
Unknown
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
Alia Atlas Former IESG member
No Objection
No Objection
()
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
()
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
()
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2015-12-16)
Unknown
Can you say something about why this is experimental? That is, what is the nature of the experiment? Will results be reported? Is there a need for deployment experience? Do you expect this to progress to standards track at some point in the future?
Benoît Claise Former IESG member
No Objection
No Objection
()
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2015-12-16)
Unknown
Tim Chown performed the opsdir review
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -14)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
()
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -14)
Unknown