Proxy authentication

Proxy authentication, if I read it right, does not work for architectures 
with more than one proxy between the browser and server, each with their
own security needs. 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. "

This needs to be fixed. We are working with proxies as stream transducers,
that can be piped to one-another or to (or from) firewall/caching proxies.
(See "Application-Specific Proxy Servers as HTTP Stream Transducers" in
WWW4, and our paper on using these for group annotation services in WWW5
for more information.) I believe that Digest Authentication should be passed
asap, but the Proxy Authentication looks seperable from DAA, and I don't
recall seeing this issue discussed in the working group.

The problem arises in setups such as a group of browsers using a single
group annotation proxy, which in turn proxies through a firewall to
organizationally external servers. Under the current proposal, the clients
can authenticate to the group annotation proxy, which can then impose its
security policy on its data and services. However, only the group annotation
proxy can authenticate to the firewall proxy. The firewall proxy would have 
to trust the group annotation proxy to never pass on requests from users
not authorized to use the firewall proxy, which is an unreasonable and
easily breakable reliance. A scheme that allowed each browser to authenticate
to each proxy would allow each proxy to maintain its own security policy
and make its own checks. 

Also, from a security architecture point of view, you definately want to
be able to authenticate the end user (browser) at any intervening proxy.
Was there some reason to draft the proxy authentication with this 
restriction?
	Mez

Received on Friday, 19 April 1996 10:06:34 UTC