Subject: [http-auth] Review of draft-melnikov-httpbis-scram-auth-00

From: Nico Williams <[email-masked]>
Date: Fri, 3 May 2013 19:34:39 -0500

First, my level-zero comments:

 - As most of you know by now, I think HTTP-layer authentication is a
bit of a dead end.  Consider Mozilla's BrowserID: an application-layer
authentication mechanism (i.e., authentication messages are POSTed).
But there is room for SCRAM here: in -to borrow a term from Kerberos-
pre-authentication of the user to the user's IdP.

   This comment applies to all proposals for authentication mechanisms
that fit into the existing HTTP authentication framework.

Next:

 - This SCRAM is not *the* SCRAM of RFC5802.  Perhaps it should have a
different name to distinguish the two.  In particular this SCRAM a)
adds various attributes such as "realm" and "sid" parameters, and b)
doesn't make use of the "-PLUS" suffix per-RFCs 5801 and 5802.  Nor
does this mechanism add the use of the SASL framework to HTTP -- it's
just an adaptation of RFC5802, not 5801.

   A list of all the differences between this mechanism and RFC5802
would be nice.  Is the authentication database for one usable with the
other?  See comments about the realm attribute below.

 - What's to be done with the "realm" attribute?  Should it be added
to the salt?  Or merely be used to route a SCRAM exchange to an IdP,
or to find the requisite authentication database?

 - What's the purpose of the "sid" attribute?  What can be done with it?

 - Why shouldn't the client name the desired server in its messages?
Then the exchange could be proxied to the named realm which could
authenticate the server doing the proxying.  That'd be nice.  No, I
think it'd have to be *required* if you want to have a realm for
federation purposes.

 - "pre-stored dictionary attack" is not how I'd phrase it.  More like
"pre-computation attack""using "rainbow tables"-- "a dictionary of
pre-computed hash results for a given one-way function and input
passwords".

 - Please remove the reference to "Registration of TLS server
end-point channel bindings"; RFC5929 should suffice.

 - A channel binding type should be required to be supported by
clients and servers, and it should be tls-server-end-point.

 - The security considerations section should mention the lack of
privacy protection for the client ID when not using TLS.

 - Section 7, third paragraph: no, no password-based authentication
mechanism protects against off-line dictionary attacks on stolen
password verifiers, not even ZKPPs.  I recommend striking this
sentence.

 - Section 7, fourth paragraph: how does salting help here?  Oh, by
ensuring that if the user uses the same password on multiple
sites/servers/realms then the verifiers will be different.

 - Section 7, 5th paragraph: how would one negotiate hashes in a
situation in which two SCRAM flavors are available, but both aren't
available for all users (because, e.g., the not all users have
re-enrolled).

 - Section 7, 6th paragraph, can you describe channel binding type
negotiation?  I thought there was none.

I'll save nits for some other time.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 4 May 2013 02:52:36 -0500

Also, as far as proxying authentication, and using the realm parameter for
federation: the proxies get material that they can mount off-line
dictionary attacks on.  This is bad.  When we designed SCRAM Sam opposed
adding a realm parameter and federation, as I recall, because of the
complexity that would have added, as well as this one issue.  My
recommendation is that the realm, if it remains in the protocol, be used
only as a sanity check.  For federation I much prefer BrowserID (full
disclosure: I'm a co-author of Luke Howard's I-D specifying a
BrowserID-based GSS-API mechanism), Keberos, ABFAB, or similar, where the
server doesn't get material suitable for off-line dictionary attacks, nor
does it get to impersonate the user to other services without permission,
and so on.

Nico
--