- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 1 Jun 2012 09:48:39 +1000
- To: Alexey Melnikov <alexey.melnikov@isode.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
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 UTC