Re: More comments on draft-ietf-http-authentication-01.txt

Gisle Aas (gisle@aas.no)
Mon, 6 Apr 1998 11:51:53 +0100 (BST) 

Ronald.Tschalaer@psi.ch (Life is hard... and then you die.) writes:

> > 2) How to interpret the URIs in the 'domain' attribute of the Digest
> > WWW-Authenticate is not clear to me either.  Are the URIs in this
> > list path prefixes that define protection spaces or must there be
> > an exact match.  If it is a prefix, what happens if the URI contains a
> > query part.
> 
> An exact match.

Would not that make this attribute too long to be useful for any real
use?  If you try to protect one specific server script you have to
make a domain attribute that lists all possible parameters (query
part) that this script takes.


> > 3) Section 3.6 does not seem to know about the "407 Proxy
> > Authentication Required" status code.  I though that a
> > "Proxy-Authenticate" header could only be present in a 407 response.
> > That is at least how I read <draft-ietf-http-v11-spec-rev-03>.  I
> > would like this paragraph to go away (it would complicate my
> > implementation if it stays):
> > 
> >   Note that in principle a client could be asked to authenticate
> >   itself to both a proxy and an end-server. It might receive an
> >   "HTTP/1.1 401 Unauthorized" header followed by both a WWW-
> >   Authenticate and a Proxy-Authenticate header. However, it can
> >   never receive more than one Proxy-Authenticate header since such
> >   headers are only for immediate connections and must not be passed
> >   on by proxies. If the client receives both headers, it must
> >   respond with both the Authorization and Proxy-Authorization
> >   headers as described above, which will likely involve different
> >   combinations of username, password, nonce, etc.
> 
> How come this would complicate the implementation? Instead of doing
> 
>   if (status == 401)
>       handle_auth_header
>   if (status == 407)
>       handle_proxy-auth_header
> 
> it becomes
> 
>   if (status == 401)
>       handle_auth_header
>       handle_proxy-auth_header
>   if (status == 407)
>       handle_proxy-auth_header

The problem for me is that handle_auth_header() will actually send a
follow-up request (usually after asking the user for a new
username/password).  I just have to rethink how to deal with this I
guess.


> Actually, now that you mention it, I'm not even really sure why the 407
> is needed at all. The Authorization vs. Proxy-Authorization header gives
> you enough info on where the challenge is coming from. Can anybody shed
> some light on why 407 exists?

Perhaps some old clients that get confused if they get a 401 without
any WWW-Authenticate?


> I think there is a problem with the nonce-count and the MD5-sess
> implementation. Assuming that _set_authorization is only called upon
> receipt of a Authentication or Proxy-Authentication header (i.e. it's
> not used for preemptively sending auth info) you need the following
> changes:

The intent is to use it preemptively (assuming that you by this mean
to send a Authentication to a URL before having seen any
WWW-Authenticate for it).  Is there problem with this?

This also brings up another question on how nonce-count and domain
interact.  If you have a Digest space that spans several servers,
should the nonce-count be incremented seperately for these servers or
should they share it?

Regards,
Gisle