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, 1 Jun 2012 09:48:39 +1000
Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <632A1938-9D59-4E5F-9B2B-7AEC1978F1A8@mnot.net>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Would you like to make a proposal?

Regards,


On 01/06/2012, at 3:50 AM, Alexey Melnikov wrote:

> 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.
> 

--
Mark Nottingham   http://www.mnot.net/
Received on Thursday, 31 May 2012 23:49:08 GMT

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