- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 8 Jun 2012 17:24:47 +1000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
I think that's good, and I think we're getting to diminishing returns. Unless we hear *strong* objections, we'll close the ticket and incorporate. Regards, On 07/06/2012, at 8:17 PM, Julian Reschke wrote: > On 2012-06-07 11:17, Amos Jeffries wrote: >> ... >>> Authentication schemes that use the "realm" mechanism for >>> establishing a >>> protection space will expose credentials to all resources on a server. >> >> NP: personally I'm not sure we can say it that generically. Some may use >> realm, but also use a target space internally to restrict the scope >> where that realm is relevant/valid. >> >> Perhapse s/use/rely solely on/. Which implies the current Basic and >> Digest without limiting it by naming them. > > +1 > >> ... >> IMHO, this needs to be clearer than "server" since that implies all >> types of virtual hosting as well which are actually not guilty of this >> brokenness. >> Perhapse more words at the end of that sentence to the effect of "under >> the same hostname." or similar. >> ... > > We already have the term "canonical root URI" for that (but maybe we should think about a better term). > > Revised proposal: > > 6.2. Protection Spaces > > Authentication schemes that solely rely on the "realm" mechanism for > establishing a protection space will expose credentials to all > resources on a server. Clients that have successfully made > authenticated requests with a resource can use the same > authentication credentials for other resources on the same server. > This makes it possible for a different resource to harvest > authentication credentials for other resources. > > This is of particular concern when a server hosts resources for > multiple parties under the same canonical root URI (Section 6.2). > Possible mitigation strategies include restricting direct access to > authentication credentials (i.e., not making the content of the > Authorization request header field available), and separating > protection spaces by using a different host name for each party. > > <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/348/348.diff> > > Best regards, Julian > -- Mark Nottingham http://www.mnot.net/
Received on Friday, 8 June 2012 07:25:26 UTC