W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1999

Re: Proxy auth

From: David W. Morris <dwm@xpasc.com>
Date: Thu, 18 Nov 1999 11:04:58 -0800 (PST)
To: Dave Kristol <dmk@research.bell-labs.com>
Cc: http-wg@hplb.hpl.hp.com, joshco@exchange.microsoft.com, fielding@kiwi.ICS.UCI.EDU, lawrence@agranat.com, http-wg@cuckoo.hpl.hp.com
Message-ID: <Pine.GSO.4.05.9911181100110.6197-100000@shell1>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/632

On Thu, 18 Nov 1999, Dave Kristol wrote:

> "Josh Cohen (Exchange)" <joshco@Exchange.Microsoft.com> wrote:
>   >  Since we're talking about proxies....
>   > Im curious to know what others think the right thing
>   > according to the intent of the 1.1 spec to do is
>   > in this situation:
>   > 
>   > If you have two chained proxy servers:
>   > 
>   > client -> proxy1 -> proxy2 -> origin server
>   > 
>   > If proxy 2 challenges for proxy-authentication (in its realm),
>   > should the challenge go back to the client if proxy1 doesnt intend
>   > to satisfy the challenge ?
>   > 
>   > My understanding was that the intent was that this situation was
>   > to be covered.  By this I mean a client can auth to a proxy up the chain.
>   > The spec is somewhat ambiguous, it says the proxy-auth headers are 
>   > hop-by-hop, but then mentions that chained proxy-auth can work.
> My understanding has always been that proxy authentication is strictly
> hop-by-hop.  So proxy1 should not bump the authentication request up to
> the client.  After all, it's proxy1 that has a trust relationship with
> proxy2, whereas the client may have no such relationship.

My recollection matchs DaveK's ... it was acknowledged at the time that
the proxy auth was hop-hop only and as I recall the WG rejected an attempt
to extend the protocol to accurately allow for proxy authentication thru
another proxy. 

I believe there are cases where Josh's scenario would be valuable but it
isn't what was defined.

Dave Morris
Received on Thursday, 18 November 1999 11:11:07 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:06 UTC