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 17:06:52 +0200
Message-ID: <4FC7890C.2000106@gmx.de>
To: HTTP Working Group <ietf-http-wg@w3.org>
CC: David Morris <dwm@xpasc.com>
On 2012-05-31 16:57, David Morris wrote:
> On Thu, 31 May 2012, 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.
> But only if a http://example.com/b resource sends the realm in a
> challenge? If my memory is correct, then this is under the control
> of the server operator (HTTP response header filtering).

Yes, but clients *do* send credentials in requests without having 
received a previous challenge. (Otherwise HTTP auth would require one 
additional round trip per request)

Best regards, Julian
Received on Thursday, 31 May 2012 15:07:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:00 UTC