W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: WGLC #348: Realms and scope

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 8 Jun 2012 17:24:47 +1000
Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Message-Id: <E85744D3-4EB5-4B7A-AD00-EEEF6E84F338@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>
I think that's good, and I think we're getting to diminishing returns.

Unless we hear *strong* objections, we'll close the ticket and incorporate.


On 07/06/2012, at 8:17 PM, Julian Reschke wrote:

> On 2012-06-07 11:17, Amos Jeffries wrote:
>> ...
>>>   Authentication schemes that use the "realm" mechanism for
>>> establishing a
>>>   protection space will expose credentials to all resources on a server.
>> NP: personally I'm not sure we can say it that generically. Some may use
>> realm, but also use a target space internally to restrict the scope
>> where that realm is relevant/valid.
>> Perhapse s/use/rely solely on/. Which implies the current Basic and
>> Digest without limiting it by naming them.
> +1
>> ...
>> IMHO, this needs to be clearer than "server" since that implies all
>> types of virtual hosting as well which are actually not guilty of this
>> brokenness.
>> Perhapse more words at the end of that sentence to the effect of "under
>> the same hostname." or similar.
>> ...
> We already have the term "canonical root URI" for that (but maybe we should think about a better term).
> Revised proposal:
> 6.2.  Protection Spaces
>   Authentication schemes that solely rely on the "realm" mechanism for
>   establishing a protection space will expose credentials to all
>   resources on a server.  Clients that have successfully made
>   authenticated requests with a resource can use the same
>   authentication credentials for other resources on the same server.
>   This makes it possible for a different resource to harvest
>   authentication credentials for other resources.
>   This is of particular concern when a server hosts resources for
>   multiple parties under the same canonical root URI (Section 6.2).
>   Possible mitigation strategies include restricting direct access to
>   authentication credentials (i.e., not making the content of the
>   Authorization request header field available), and separating
>   protection spaces by using a different host name for each party.
> <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/348/348.diff>
> Best regards, Julian

Mark Nottingham   http://www.mnot.net/
Received on Friday, 8 June 2012 07:25:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:02 UTC