Re: WGLC #348: Realms and scope

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