Subject: OAuth and HTTP caching

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 21 Sep 2009 14:15:04 -0700

As currently written, OAuth use of the HTTP authentication headers is optional at best.

The reason for that was based on concerns that some platforms do not provide access to the HTTP header in either the request or the reply. However, this might have significant ramifications on caching and other parts of HTTP where an indication of an authenticate interaction is needed.

Before the OAuth WG spends any time on discussing the various methods of sending authentication parameters, I would like to find out if using the authentication headers is more of a requirement for such a protocol.

EHL

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Sep 2009 11:48:15 +1000

From a quick look, it looks like you use GET to the user  
authorisation URL, at least, so in this case the response could be  
cached. However, if Cache-Control, Expires and Last-Modified are all  
absent, it will only be stored by a few shared caches (e.g., IIS) and  
only reused in unusual circumstances (e.g., the origin is not  
available any more).

As I have said many times before, I don't buy arguments that we have  
to consider environments where people don't have access to HTTP  
headers; while they exist, the intersection of people who want to use  
OAuth and those who absolutely under any condition cannot find a way  
to influence HTTP headers (including changing hosting environments) is  
vanishingly small. All that accommodating these situations does is  
make the argument that people don't need access to headers stronger,  
thereby weakening the Web overall.

That said, the usual approach here is to use a nonce in the URL.  
Completely disallowing caching of a GET response without any access to  
headers isn't possible.

BTW, how does authentication help? Presumably if you can send  
credentials, you can set other headers as well.

Cheers,

On 22/09/2009, at 7:15 AM, Eran Hammer-Lahav wrote:

> The reason for that was based on concerns that some platforms do not  
> provide access to the HTTP header in either the request or the  
> reply. However, this might have significant ramifications on caching  
> and other parts of HTTP where an indication of an authenticate  
> interaction is needed.
>
> Before the OAuth WG spends any time on discussing the various  
> methods of sending authentication parameters, I would like to find  
> out if using the authentication headers is more of a requirement for  
> such a protocol.
>
> EHL
>

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 21 Sep 2009 20:03:30 -0700

The call can be anything (not just GET), since OAuth is used for accessing resources, not just during the delegation workflow.

EHL

> -----Original Message-----
> From: Mark Nottingham [mailto:[email-masked]]
> Sent: Monday, September 21, 2009 6:48 PM
> To: Eran Hammer-Lahav
> Cc: [email-masked]; [email-masked] Group
> Subject: Re: OAuth and HTTP caching
>

---

From: John Panzer <[email-masked]>
Date: Mon, 21 Sep 2009 21:56:02 +0000

On the server side, one of the concerns in the past has been security in
shared hosting systems where e.g., basic auth data should be handled by a
secure container (Apache) and not passed on in raw form to hosted CGI
scripts.  So some of this comes back to what minimum level of hosting should
be targeted by the specification -- and how much it should bend over
backwards to deal with "challenged" environments.

My $.02 is that we should follow the HTTP spec (Authorization: and
WWW-Authenticate:) and take a minimum distance path to route around limited
environments if necessary (X-Authorization: and X-WWW-Authenticate:, with
exactly the same content, would be my proposal).

--
John Panzer / Google
[email-masked] / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer

On Mon, Sep 21, 2009 at 2:15 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> provide access to the HTTP header in either the request or the reply.
> However, this might have significant ramifications on caching and other
> parts of HTTP where an indication of an authenticate interaction is needed.
>
> Before the OAuth WG spends any time on discussing the various methods of
> sending authentication parameters, I would like to find out if using the
> authentication headers is more of a requirement for such a protocol.
>
> EHL
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Sep 2009 17:56:27 +1000

On 22/09/2009, at 7:56 AM, John Panzer wrote:

> On the server side, one of the concerns in the past has been  
> security in shared hosting systems where e.g., basic auth data  
> should be handled by a secure container (Apache) and not passed on  
> in raw form to hosted CGI scripts.  So some of this comes back to  
> what minimum level of hosting should be targeted by the  
> specification -- and how much it should bend over backwards to deal  
> with "challenged" environments.

That's a good discussion to have.

> WWW-Authenticate:) and take a minimum distance path to route around  
> limited environments if necessary (X-Authorization: and X-WWW- 
> Authenticate:, with exactly the same content, would be my proposal).

Ugh. By allowing other resources on the same server to see  
authentication credentials, wouldn't that just re-open these attacks?

>
> --
> John Panzer / Google
> [email-masked] / abstractioneer.org / @jpanzer
>
>
>
> On Mon, Sep 21, 2009 at 2:15 PM, Eran Hammer-Lahav <[email-masked] 
> > wrote:

---

From: John Panzer <[email-masked]>
Date: Tue, 22 Sep 2009 15:47:32 +0000

Inline...

On Tuesday, September 22, 2009, Mark Nottingham <[email-masked]> wrote:
> On the server side, one of the concerns in the past has been security in shared hosting systems where e.g., basic auth data should be handled by a secure container (Apache) and not passed on in raw form to hosted CGI scripts.  So some of this comes back to what minimum level of hosting should be targeted by the specification -- and how much it should bend over backwards to deal with "challenged" environments.
>
>
> My $.02 is that we should follow the HTTP spec (Authorization: and WWW-Authenticate:) and take a minimum distance path to route around limited environments if necessary (X-Authorization: and X-WWW-Authenticate:, with exactly the same content, would be my proposal).
>
>
> Ugh. By allowing other resources on the same server to see authentication credentials, wouldn't that just re-open these attacks?
>
>

1. Oauth, at least when accessing protected resources, is designed to
be used over insecure connections, so the password sniffing attacks
don't apply.

2. The alternative on the table is to pass these as URL params, which
are more sniffable and also makes the web cry.

> On Mon, Sep 21, 2009 at 2:15 PM, Eran Hammer-Lahav <[email-masked]> wrote:

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 22 Sep 2009 10:09:16 -0700

> with "challenged" environments.

That is only a concern for Basic auth, AFAIK.  Apache could tweak it
to only forward unhandled non-Basic credentials to CGI or just a summary
of what has been validated, though some indication of what needs to be
forwarded would be useful.

> Authenticate:, with exactly the same content, would be my proposal).

Just follow the HTTP spec.  Someone will implement it.  If people try to
bypass HTTP extensibility mechanisms with stupid hacks that get shipped
in production software, Apache will add code to strip their information
from the stream before anyone sees it.

....Roy

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 22 Sep 2009 10:24:30 -0700

> From: Roy T. Fielding [mailto:[email-masked]]
> Sent: Tuesday, September 22, 2009 10:09 AM

> Just follow the HTTP spec.

That what I am trying to figure out...

Does the HTTP spec mandates that new authentication protocols use the WWW-Authenticate and Authorization headers? Are the headers required for existing caches and servers to operate properly? If they are not included in authenticated requests, are there other requirements to make sure it doesn't break existing deployment?

Thanks,

HEL

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 22 Sep 2009 10:47:58 -0700

On Sep 22, 2009, at 10:24 AM, Eran Hammer-Lahav wrote:

> Does the HTTP spec mandates that new authentication protocols use  
> the WWW-Authenticate and Authorization headers?

HTTP is not aware of any other kinds of authentication.  There is no  
reason
to specify anything else.

> Are the headers required for existing caches and servers to operate  
> properly?

Yes (and for user agents as well).  Don't forget about Proxy-Auth*.

> If they are not included in authenticated requests, are there other  
> requirements to make sure it doesn't break existing deployment?

Cache-control: private

is probably needed if the Auth headers are not being used but the
response depends on something like cookies for authentication.

....Roy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Sep 2009 23:15:37 -0400

HTTP is designed the way it is for a reason.

Every single piece of infrastructure that people are using on the Web
today was developed after the authenticate headers were designed. If
people have designed a scripting host in such a fashion that the
information does not make it through, that is clearly either a
deliberate decision on their part or the system is so clueless that
you probably don't want to use it for any security related application
in any case.

If you try to do a work around you may allow maybe a few legacy
applications to work that would otherwise not. But you will do so by
making OATH one of the obstacles that future designers have to work
around.

Part of the whole point of standards organizations is to help people
to know what parts of the specs they can depend on being constant and
which may change. That all changes if people start to make random
choices and second guess.

At the end of the day, this is a security spec. Every step we take
that adds complexity reduces the security we will deliver. Every extra
quotient of complexity is another opportunity for us to screw up or
for implementers.

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 23 Sep 2009 14:03:15 +1000

That works -- provided OAuth is completely proof against replay attacks.

However, are new headers really necessary? Reading in various places  
about this issue, it seems like a common workaround is to use  
mod_rewrite to expose the authorization header in the environment; e.g.,

RewriteEngine on
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]

Isn't that enough to get the 80% case of those who have trouble with  
getting direct access? Specifying two different headers to be used on  
the wire will lead people to always use the more conservative one (X- 
whatever, blech) and thereby lead us directly back into the situation  
Eran's concerned about (intermediaries not realising that this is  
protected content). The workaround for that will be having the header  
duplicated, with both names (double blech).

Cheers,

On 23/09/2009, at 1:46 AM, John Panzer wrote:

>> The reason for that was based on concerns that some platforms do  
>> not provide access to the HTTP header in either the request or the  
>> reply. However, this might have significant ramifications on  
>> caching and other parts of HTTP where an indication of an  
>> authenticate interaction is needed.
>>
>> out if using the authentication headers is more of a requirement  
>> for such a protocol.
>>
>> EHL

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 Sep 2009 22:16:54 -0600

<hat type="individual"/>

On 9/22/09 10:03 PM, Mark Nottingham wrote:
> However, are new headers really necessary? 

I think not.

> Reading in various places
> the wire will lead people to always use the more conservative one
> (X-whatever, blech) and thereby lead us directly back into the situation

Blech blech blech.

Going back to Eran's original message, he said:

   As currently written, OAuth use of the HTTP authentication
   headers is optional at best. The reason for that was based
   on concerns that some platforms do not provide access to
   the HTTP header in either the request or the reply.

Do we have a sense of what those platforms are? Minimal HTTP clients of
some kind? Do we really need to design around those, especially given
that the alternatives seem to be unpalatable?

Peter

>>> On the server side, one of the concerns in the past has been security
>>> in shared hosting systems where e.g., basic auth data should be
>>> handled by a secure container (Apache) and not passed on in raw form
>>> to hosted CGI scripts.  So some of this comes back to what minimum
>>> level of hosting should be targeted by the specification -- and how
>>> much it should bend over backwards to deal with "challenged"
>>> environments.
>>>
>>>
>>> limited environments if necessary (X-Authorization: and
>>> X-WWW-Authenticate:, with exactly the same content, would be my
>>> proposal).
>>>
>>>
>>> However, this might have significant ramifications on caching and
>>> other parts of HTTP where an indication of an authenticate
>>> interaction is needed.
>>>
>>> Before the OAuth WG spends any time on discussing the various methods
>>> of sending authentication parameters, I would like to find out if
>>> using the authentication headers is more of a requirement for such a
>>> protocol.
>>>
>>> EHL

---

From: John Panzer <[email-masked]>
Date: Wed, 23 Sep 2009 04:21:05 +0000

On Tue, Sep 22, 2009 at 9:03 PM, Mark Nottingham <[email-masked]> wrote:

> However, are new headers really necessary? Reading in various places about
> this issue, it seems like a common workaround is to use mod_rewrite to
> expose the authorization header in the environment; e.g.,
>
> RewriteEngine on
> getting direct access? Specifying two different headers to be used on the
> wire will lead people to always use the more conservative one (X-whatever,
> blech) and thereby lead us directly back into the situation Eran's concerned
> about (intermediaries not realising that this is protected content). The
> workaround for that will be having the header duplicated, with both names
> (double blech).
>

Yes, if there is a way to just use the HTTP spec that would be vastly
preferable.  (You could send the X- headers only after an initial 401
failure, but that cure may be worse than the disease.)

 Cheers,
> Ugh. By allowing other resources on the same server to see authentication
> credentials, wouldn't that just re-open these attacks?
>
>
>