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

Re: WGLC #348: Realms and scope

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 31 May 2012 16:36:51 +0200
Message-ID: <4FC78203.3070202@gmx.de>
To: Alexey Melnikov <alexey.melnikov@isode.com>
CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
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.

Best regards, Julian
Received on Thursday, 31 May 2012 14:37:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 31 May 2012 14:37:31 GMT