Re: Proxy authentication

Thanks John,

> > > Section 2.5 of the DAA spec says:
> > > 
> > > " the proxy versions, Proxy-
> > >   Authenticate and Proxy-Authorization, apply only to the current
> > >   connection and must not be passed upstream or downstream. "
> > 
> > That part of the Digest spec is wrong.  The decision of whether or not
> > that information is passed along is made by the Proxy.  Each proxy
> > along the line may forward or interpret or rewrite the proxy-AA header fields.
> 
[...]

> The current working version of <draft-ietf-http-v11-spec-02.html> says
> in section 10.30
> 
>    "Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
>    only to the current connection and must not be passed on to downstream
>    clients."
> 
> and in section 10.31
> 
>    "Unlike Authorization, the Proxy-Authorization applies only to the
>    current connection and must not be passed on to upstream servers."
>
> The Digest Authentication specification is merely reflecting these
> sections.
> If changes are made to these sections then, of course, the Digest
> Authentication specification will be changed to be compatible.
> Until that time, I suggest that Roy's assertion that the digest
> specification is "wrong" should be interpreted to mean that he
> would favor a change in the HTTP/1.1 draft specification sections
> quoted above.

I favor that too. I've outlined our actual need for that change. And I know
that our need is not particularly aberrant, since many distributed security
systems have this support in it (see "Cascaded Authentication" by Sollins,
the paper on DSSA delegation by Gasser and McDermott, and DCE delegatin 
support, which I know customers requested specficially).

> 
> On this subject, if a scheme like that described in 
> 
>   <http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q1/0365.html>
> 
> is to be adopted, it needs to be thought out carefully.  For example,
> consider a chain of agents like
> 
>          A --> B --> C --> D
> 
> where C requires authentication from A, and D requires authentication
> from B.  I believe that under the current specification for Basic
> Authentication, when B receives a Proxy-Authenticate header from C it
> would have no way to know if this originated from C and is intended to
> be passed on to A or originated from D and is intended for B.

This is a good point. I don't know of any need for a fully general solution
(although a fully general solution will satisfy more unseen future needs).
In the short term, the only need we have is the ability of A to authenticate
to B, C, and D. 

One possibility for a fully general solution would be to allow authentication/
authorization failures to propogate back through the chain. So, if C issues
a proxy-authenticate, B would consider whether it was equipped to handle an
authentication request from that realm. If it could, it would attempt. If not,
or if it's attempt failed, it could pass it back to A. Alternatively,
B could send the request back the chain, and send on authentication information
from both A and itself (if they both had it), and let C implement it's
desired policy.

I can't say I'm fully comfortable with either of these, but I don't know what
other concrete security policies people have out there, other than ours. 
The best solution would provide authentication information from the whole
chain, in a manner that preserved the order information (most particularly,
differentiated A from the rest). Rohit, can this be done with PEP?
	Mez

Received on Monday, 22 April 1996 08:24:45 UTC