W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: #177: Realm required on challenges

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Mon, 25 Jul 2011 15:00:53 +1200
Message-ID: <4E2CDC65.602@treenet.co.nz>
To: ietf-http-wg@w3.org
On 25/07/11 13:39, Adrien de Croy wrote:
>
> Hi
>
> firstly, thanks for the expanded text around realm, it makes it a lot
> clearer what it is for.
>
> It does raise an immediate issue for proxy auth though. Realm in the
> context of the authority + Scheme doesn't make sense for proxy auth.
>
> If a proxy must provide a realm with any challenge, (BTW NTLM ignores
> this), then what is the base effective URI? How can a proxy indicate
> that proxy creds can be re-used for access to the entire internet?
>
> We may need to propose different restrictions. For instance on the net
> it would be very dangerous to be able to specify a wild-card or
> universal realm (e.g which encompasses more than one site) due to
> credential leakage issues, but for a proxy that's exactly what you want.

AIUI, WWW-Auth and Proxy-Auth are defined explicitly with distinct 
end-to-end and hop-by-hop requirements to prevent exactly that leakage. 
There is no leak problem unless the implementation is non-compliant or 
misconfigured.

There is the edge case we hit occasionally. Where two chained proxies 
require unique Proxy-Auth credentials from the client. Admin obsession 
with end-to-end single-signon appears to be avoiding this problem for 
now on most networks. But these per-user chaining configurations are 
still being asked about in our user base occasionally. It is reasonable 
to assume they are being implemented ... somehow.

>
> Or, the realm for proxy auth must only apply to the proxy itself (which
> isn't stated anywhere).

Section 4 paragraph 2, sentence 1 seems to be that.

"
    Unlike Authorization, the Proxy-Authorization header field applies
    only to the next outbound proxy that demanded authentication using
    the Proxy-Authenticate field.
"

That and the wording about consuming the header. Implies any realm 
stated on it is proxy/hop specific. No leaks.

>
> In any case, the client will need to treat the realm differently for
> proxy auth vs auth to an O-S.
>
> Yet another reason why intercepting connections is a bad idea.
>

What has that got to do with this topic? any halfway sane interceptor 
won't touch auth at all. The insane ones break things regardless of what 
gets specified.

AYJ
Received on Monday, 25 July 2011 03:01:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:45 GMT