W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2007

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

From: <lists@ingostruck.de>
Date: Mon, 11 Jun 2007 23:15:21 +0000
To: Henrik Nordstrom <henrik@henriknordstrom.net>
Cc: Jamie Lokier <jamie@shareable.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-Id: <200706112315.53043.lists@ingostruck.de>

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:

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:42 UTC