Subject: Re: WGLC #348: Realms and scope

From: Julian Reschke <[email-masked]>
Date: Sat, 02 Jun 2012 12:18:09 +0200

On 2012-05-31 18:11, Martin Thomson wrote:
> On 31 May 2012 05:09, Mark Nottingham<[email-masked]>  wrote:
>> 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.
>
> 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 [...]"""

Thanks, Martin.

I slightly tuned all of this to:

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

Feedback appreciated, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 4 Jun 2012 10:48:23 +1000

Looks good to me; anyone have a problem?

--
Mark Nottingham   http://www.mnot.net/

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 4 Jun 2012 15:16:57 +1000

>>>  Possible mitigation strategies include restricting
>>>  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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Jun 2012 11:28:09 -0700

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

That would be great, if one existed.  Can you provide a citation for
an example? ;)

---

From: David Morris <[email-masked]>
Date: Mon, 4 Jun 2012 17:16:25 -0700 (PDT)

On Thu, 31 May 2012, Julian Reschke wrote:

> On 2012-05-31 16:57, David Morris wrote:
> > 
> > 
> > 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).
> 
> 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)

This took a few days to set up a careful test case. I don't have the time
or resources to test every client, so I can't refute the claim that some
clients send the authorization header for a part of the hosts content
which it doesn't apply to, but I've tested:

IE6, IE7, IE8 and Safari (5.1.5 on MacOS 10.7). None of these clients
sent sent the authorization header contrary to my assertion above.

Any wording in the RFC should make it clear that sending the
credentials for the parent of 'a' or for 'b' is incorrect but
may happen with broken clients.

I created the following structure on my test apache server:

a: /authab/index.html
b: /authab/a/index.html ... configured to require credentials
c: /authab/b/index.html

This each was a simple html page with links to the other two pages
and a javascript onClick handler which added a unique query string
to each request to avoid browser caching.

With tcpdump on the server to capture all port 80 traffic.
I entered url a: in each browser's address box. Navigated to c: and
from there to b: and then back to a: and finally back to c:

In each case, the browser requested credentials on the first request
for b:.

I then examined the resulting tcpdump file and confirmed that the
authorization header was not ever included on requests for a: or c:.

I'm willing to share my server with anyone who would like to test
with other clients, but I don't want the name posted on this
mailing list. Send me a private email for the info.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 05 Jun 2012 21:33:14 +0200

On 2012-06-05 02:16, David Morris wrote:
> ...

What's the definition of "doesn't apply to"?

> mailing list. Send me a private email for the info.

Thanks for setting this up. This definitively requires research.

In the meantime: what do we do with the ticket?

Best regards, Julian

---

From: David Morris <[email-masked]>
Date: Wed, 6 Jun 2012 10:37:47 -0700 (PDT)

>From memory ... which has stuck with me because I wasn't real happy
with the definition ...

Thinking of URLs as representing the hierarachical name space
we commonly associate with a file system ...

Realm "RauthA" returned in a 401 response's www-authenticate header
for a request for authab/a/ may be assumed to applu to directory 
authab/a/ and to all directories under authab/a/. So if the client
has credentials for authab/a/ it may return those credentials
in the Authorization header in a request for authab/a/aa/
anticipating that the same credential would apply, but not for
authab/ or any peer of authab/a/ such as authab/b/ in my test.

My current test setup doesn't support the subdirectory case, but
I think I'll expand it when I get a chance.  I also need to go back
and review the RFCs to validate my memory.

Dave Morris

---

From: Martin Thomson <[email-masked]>
Date: Wed, 6 Jun 2012 13:08:48 -0700

> and review the RFCs to validate my memory.

I'd also like to see a test for other resources.  In your test, you
had previously visited the unauthenticated resources.  What about
resource /d?

It all comes down to the criteria used by browser to optimize the
sending of authentication information in requests.  It might use path
hierarchy, or something else.  In the end, it might be easier to ask,
or directly check.

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 7 Jun 2012 14:21:02 +1000

David,

A user browsers to
(1) https://example.com/good/
Gets as 401 response with realm="GoodStuff"; is prompted for credentials; the request is retried successfully with the credentials in the Authorization header.
Now the user browsers to
(2) https://example.com/good/sub/ and
(3) https://example.com/bad/.

The issue isn't whether a browser will automatically send the credentials in request 2, but not in 3.

The issue is whether a browser will automatically send the credentials if request 3 responds with a 401 with realm="GoodStuff". Browsers should do this, and they do (at least Chrome on Windows in a very quick test).

A /bad/ resource can get the /good/ credentials by pretending to be in the same realm.

This is the limitation of realms that the proposed Security Considerations text addresses [http://trac.tools.ietf.org/wg/httpbis/trac/ticket/348].

  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.

A server that enforces different realms values for different parties might theoretically mitigate the risk, without the more destructive blocking of direct access to the Authorization header. However, I wouldn't be surprised if, say, javascript returned from /bad/ could somehow get the credentials the browser is caching for /good/.

--
James Manger

> -----Original Message-----
> From: David Morris [mailto:[email-masked]]
> Sent: Thursday, 7 June 2012 3:38 AM
> To: HTTP Working Group
> Subject: Re: WGLC #348: Realms and scope
> 
> 
>

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 07 Jun 2012 21:17:26 +1200

> A /bad/ resource can get the /good/ credentials by pretending to be in the same realm.

So, we have a server which is authoritatively hosting 2+ parties using 
the same scheme+FQDN+port+realm. Thats a four-factor scoping key; with 
two factors locked to the reading protocol [scheme+port], one factor 
locked to particular ownership/authority [FQDN] and some very weak 
salting [realm text]. The "insecurity" is only created by someone 
administratively undermining two of the four reliability factors 
(FQDN+port) which leaves an attacker with only the weakest factor 
(realm) to undermine for credentials to leak.

The key point [pun intended] being that for any of this to matter in the 
slightest there *first* has to be an administrator willingly removing 
uniqueness from the most critical parts of the algorithm key. So long as 
that continues there is no fixing it *for them*.

IMHO the text says there is a crossover issue and part of how to fix, 
but does not clearly state the problem is not with realm directly but 
from the sharing of authority-URI

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

>   Clients
>    parties.

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.

>   Possible mitigation strategies include restricting direct access

AYJ

---

From: Julian Reschke <[email-masked]>
Date: Thu, 07 Jun 2012 12:17:12 +0200

On 2012-06-07 11:17, Amos Jeffries wrote:
>> establishing a

+1

> 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

    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

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 8 Jun 2012 17:24:47 +1000

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:

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