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

Re: WGLC #348: Realms and scope

From: David Morris <dwm@xpasc.com>
Date: Thu, 31 May 2012 07:57:08 -0700 (PDT)
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <alpine.LRH.2.01.1205310752090.15057@egate.xpasc.com>


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).
Received on Thursday, 31 May 2012 14:57:47 GMT

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