Salted Challenge Response HTTP Authentication Mechanism
draft-ietf-httpauth-scram-auth-15

[Ballot comment]
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?

[Ballot comment]
-- 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/

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-httpauth-scram-auth-13.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry located at:

http://www.iana.org/assignments/http-authschemes/

two new authentication schemes are to be registered as follows:

Authentication Scheme Name: SCRAM-SHA-256
Reference: [ RFC-to-be ]
Notes:

Authentication Scheme Name: SCRAM-SHA-1
Reference: [ RFC-to-be ]
Notes:

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

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

Technical Summary

The authentication mechanism most widely deployed and used by
Internet application protocols is the transmission of clear-text
passwords over a channel protected by Transport Layer Security (TLS).
There are some significant security concerns with that mechanism,
which could be addressed by the use of a challenge response
authentication mechanism protected by TLS.  Unfortunately, the HTTP
Digest challenge response mechanism presently on the standards track
failed widespread deployment, and have had success only in limited
use.

This specification describes a family of HTTP authentication
mechanisms called the Salted Challenge Response Authentication
Mechanism (SCRAM), which addresses security concerns with HTTP Digest
and meets the deployability requirements.  When used in combination
with TLS or an equivalent security layer, a mechanism from this
family could improve the status-quo for HTTP authentication.


Working Group Summary

This document is one of the experimental documents submitted to the
HTTP-Auth working group.

With version -13 it is the consensus of the HTTP-Auth working group
that this document is fit to be published as an experimental RFC.

There are few nits that must be addressed during the IETF LC review.


Document Quality

The proposed authentication method has been reviewed by a fair number of
participants.

There is one known implementation of this protocol.



Personnel

Author: Alexey Melnikov
Shepherd: Rifaat Shekh-Yusef
Area Director: Kathleen Moriarty

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-httpauth-scram-auth@ietf.org, httpauth-chairs@tools.ietf.org, rifaat.ietf@gmail.com, httpauth-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, http-auth@ietf.org, alexey.melnikov@isode.com, draft-ietf-httpauth-scram-auth-all@tools.ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Salted Challenge Response (SCRAM) HTTP Authentication Mechanism) to Experimental RFC


The IESG has received a request from the Hypertext Transfer Protocol
Authentication WG (httpauth) to consider the following document:
- 'Salted Challenge Response (SCRAM) HTTP Authentication Mechanism'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-12-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The authentication mechanism most widely deployed and used by
  Internet application protocols is the transmission of clear-text
  passwords over a channel protected by Transport Layer Security (TLS).
  There are some significant security concerns with that mechanism,
  which could be addressed by the use of a challenge response
  authentication mechanism protected by TLS.  Unfortunately, the HTTP
  Digest challenge response mechanism presently on the standards track
  failed widespread deployment, and have had success only in limited
  use.

  This specification describes a family of HTTP authentication
  mechanisms called the Salted Challenge Response Authentication
  Mechanism (SCRAM), which addresses security concerns with HTTP Digest
  and meets the deployability requirements.  When used in combination
  with TLS or an equivalent security layer, a mechanism from this
  family could improve the status-quo for HTTP authentication.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpauth-scram-auth/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpauth-scram-auth/ballot/


No IPR declarations have been submitted directly on this I-D.