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

Re: WGLC #348: Realms and scope

From: Alexey Melnikov <alexey.melnikov@isode.com>
Date: Thu, 31 May 2012 18:50:36 +0100
Message-ID: <4FC7AF6C.9030001@isode.com>
To: Julian Reschke <julian.reschke@gmx.de>, Mark Nottingham <mnot@mnot.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>
On 31/05/2012 15:36, Julian Reschke wrote:
> On 2012-05-31 16:15, Alexey Melnikov wrote:
>> On 31/05/2012 13:09, Mark Nottingham wrote:
>>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/348>
>>>
>>> Proposal -
>>>
>>> New section in p7 Security Considerations:
>>>
>>> """
>>> 6.2 Protection Spaces
>>>
>>> Authentication schemes that use the "realm" mechanism for establishing
>>> a protection space will expose credentials to all resources on a
>>> server. This makes it possible for a resource to harvest
>>> authentication credentials for other resources on the same server.
>>>
>>> This is of particular concern when a servers hosts resources for
>>> multiple parties. Possible mitigation strategies include restricting
>>> direct access to authentication credentials (i.e., not making the
>>> content of the Authorization request header available), and separating
>>> protection spaces by using a different hostname for each party.
>>> """
>> Mark, I might be missing something: I thought realm can be used to
>> restrict access to resources within a server (i.e. the same host can
>> serve multiple different realms, each realm can have its own user
>> password database). Your text above contradicts that.
>
> Yes, but the realm value doesn't tell the client what part of the URI 
> space the credentials are for.
>
> So if you basic-authenticate to http://example.com/a successfully, the 
> client may send the same credentials to http:://example.com/b, 
> although it's a separate protection space.

I don't think the suggested text explains this problem at all. Please 
expand the text to explain the issue.
Received on Thursday, 31 May 2012 17:51:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 31 May 2012 17:51:13 GMT