- From: Alexey Melnikov <alexey.melnikov@isode.com>
- Date: Thu, 31 May 2012 18:50:36 +0100
- 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 UTC