Re: WGLC #348: Realms and scope

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 UTC