- From: Manger, James H <James.H.Manger@team.telstra.com>
- Date: Mon, 4 Jun 2012 15:16:57 +1000
- To: Mark Nottingham <mnot@mnot.net>, Julian Reschke <julian.reschke@gmx.de>
- CC: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
>>> 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. Could we mention the best mitigation strategy (using a phishing-resistant authentication scheme that does not expose the client credentials in the protocol), instead of the strategy of restricting access to the "Authorization" value (which makes it hard to deploy better authentication schemes that need access to this header). -- James Manger > Looks good to me; anyone have a problem? > > > > > > > 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. 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. 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>) > >
Received on Monday, 4 June 2012 05:17:33 UTC