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

mån 2007-06-11 klockan 14:41 +0000 skrev lists@ingostruck.de:

> >     3. Password transfer for authentication can be done over SSL/TLS,
> >        even if the accessed pages after that are plaintext with the
> >        cookie as authenticator, for performance or caching reasons.
> 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.

> Current UA impls do not send auth across schemes (http/https), which makes 
> perfectly sense for basic, but for digest this could be done without major
> changes to rfc2617, because the scheme is not involved in the hash calculus.

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.


> This one seems to be the crux of the matter, but the 
> Authorization, Authenticate and Proxy-Authenticate headers are available
> to all those server-side-rendering schemes too (at least through CGI,
> via HTTP_AUTHORIZATION etc.).

Some servers filter the Authorization header in CGI for security
reasons, not trusting the CGI with user credentials.

> >     4. Describing hooks whereby the UI elements can appear embedded in
> >        a related HTML page, but aren't required to be.

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.

> >     5. Ensure that it's possible that site authors who write in
> >        e.g. PHP, Perl, CGI etc. can easily make use of the scheme.
> >        Simply because this is an important requirement for practical
> >        deployment.

This falls firmly into the land of server configuration. Auth schemes is
best implemented by the server, not each application running on the
server. 

In short applications (using PHP, Perl, CGI etc) need to be able to
configure the protection realms of the server in a consistent manner.
One example is using Apache .htaccess which works quite well for the
purpose (assuming the server admin allows authentication to be used).

The primary thing missing is some well defined way of establishing the
user password without applications having to dive deep into both server
and scheme details..

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.

Regards
Henrik