Subject: WGLC #348: Realms and scope

From: Mark Nottingham <[email-masked]>
Date: Thu, 31 May 2012 22:09:52 +1000

<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 Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 May 2012 15:39:30 +0200

> 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 t…

Works for me.

Best regards, Julian

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 31 May 2012 23:04:30 +0900

+1

If more comments are to be added,
it is important especially when it uses a cleartext credential (e.g. Basic).

-- 
Yutaka OIWA, Ph.D.              Leader, Software Reliability Research Group
                             Research Institute for Secure Systems (RISEC)
   National Institute of Advanced Industrial Science and Technology (AIST)
                     Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 31 May 2012 15:15:17 +0100

> 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 t…
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.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 May 2012 16:36:51 +0200

On 2012-05-31 16:15, Alexey Melnikov wrote:
>> 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.
>> """

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.

Best regards, Julian

---

From: David Morris <[email-masked]>
Date: Thu, 31 May 2012 07:57:08 -0700 (PDT)

On Thu, 31 May 2012, Julian Reschke wrote:

> 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).

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 May 2012 17:06:52 +0200

> of the server operator (HTTP response header filtering).

Yes, but clients *do* send credentials in requests without having 
received a previous challenge. (Otherwise HTTP auth would require one 
additional round trip per request)

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 May 2012 09:11:45 -0700

> 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 t…

Thanks.  That addresses my concern.

Though it would seem that the problem isn't well understood.  Maybe
insert a bit more exposition...

"""[...] 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 all resources on the same
server. This makes it possible for a [...]"""

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 31 May 2012 18:50:36 +0100

On 31/05/2012 15:36, Julian Reschke wrote:
> 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.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 1 Jun 2012 09:48:39 +1000

Would you like to make a proposal?

Regards,

On 01/06/2012, at 3:50 AM, Alexey Melnikov wrote:

>> 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.
>