Re: RFC2617, was: Straw-man charter for http-bis

On Monday 11 June 2007 21:04, Henrik Nordstrom wrote:
> > There is no need for that with digest *and* you do not even need
> > SSL/TLS for auth purposes.
>
> And more, with Digest you don't need to worry about session theft when
> not using SSL/TLS. Unlike cookies digest has built-in replay protection.
> Now not every implementation make use of it (partly due to the
> implementation bugs mentioned earlier), but it's there.
It's there and it is known how to work around the known implementation
bugs without violating the spec. :-)

> Digest has the domain response paramater to control this. Have not
> looked into how well supported this is by the current UAs, but it's
> there in the specifications.
I did not try that yet. The spec says
===
 If this directive is omitted or its value is empty, the client should assume
 that the protection space consists of all URIs on the responding server.
====
I would say that this means that for "no value" both
http://foo.com and https://foo.com are the same protection space,
because they inevitably refer to the same server (apart from technical
fancy foods like transparent nat a/o transparent proxying).
However, most UAs consider http://foo.com and https://foo.com to be
different servers.

> Some servers filter the Authorization header in CGI for security
> reasons, not trusting the CGI with user credentials.
Which is basically a good idea, because the situation where the CGI
scripts really know what they do, is rare.

> Yes, and has been on the agenda since at least 1999 as already discussed
> here. And it's not a technically hard thing to do, just someone need to
> do it and get it accepted, and when done it will significantly shift the
> tide in favor for HTTP authentication compared to cookies.
If I had some more spare time, then I would have committed to do
that, but I guess that doing it "formally correct" costs lots of
time. However, I posted a coarse draft of how I would put it down:
 
  http://auth.ingostruck.de/20070611-rfc2617-html-bridge.txt

I guess that a spec that fits into rfc requirements does not need far
more words to explain what is needed.

> This falls firmly into the land of server configuration. Auth schemes is
> best implemented by the server, not each application running on the
> server.
For sure. The applications only need a simple way to trigger UAs
to use the scheme(s) implemented on the server side.

> One example is using Apache .htaccess which works quite well for the
> purpose (assuming the server admin allows authentication to be used).
.htaccess is ok, but far from being optimal, quite like .htpasswd
And I do not think that this is a thing to be put into a spec.
If a server thinks that it is appropriate to store the
user:realm -> H(A1) mapping in a SQL cluster, then it's a (faulty...) decision
up to the server (and up to the application to store new credentials there).
If the server prefers .htacess/.htpasswd files or a tdb then it's ok too.

> Note: I do NOT consider it a reasonable task for a potential WG revising
> RFC2617 to come up with designs allowing applications to use
> authentication on servers where the use of authentication has been
> administratively prohibited. Thats an administrative issue, not a
> technical one.
100% agreed. IMHO a WG revising RFC2617 should:
- remove "opaq" (not needed for obvious reasons)
- remove "auth-param" (will never be needed)
- render all fields that are "optional for compatibility reasons"
  mandatory
- move MD5-sess to a separate rfc or drop it (nobody got it right
  and the same could be achieved with MD5)
- make the scheme of the hash calculus mandatory while allowing
  for different hash algorithms (e.g. SHA1, SHA512, RIPEMD-160)
- address the known editorial problems

Kind regards

Ingo Struck

Received on Monday, 11 June 2007 22:05:11 UTC