Re: [OAUTH-WG] OAuth and HTTP caching

From: Peter Saint-Andre <stpeter@stpeter.im> · Date: Tue, 22 Sep 2009 22:16:54 -0600

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<hat type="individual"/>

On 9/22/09 10:03 PM, Mark Nottingham wrote:
> That works -- provided OAuth is completely proof against replay attacks.
> 
> However, are new headers really necessary? 

I think not.

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

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

> 
> Cheers,
> 
> 
> On 23/09/2009, at 1:46 AM, John Panzer wrote:
> 
>> Inline...
>>
>> On Tuesday, September 22, 2009, Mark Nottingham <mnot@mnot.net> wrote:
>>>
>>> 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.
>>>
>>>
>>> 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.
>>
>>>
>>>
>>> -- 
>>> John Panzer / Google
>>> jpanzer@google.com / abstractioneer.org / @jpanzer
>>>
>>>
>>>
>>> On Mon, Sep 21, 2009 at 2:15 PM, Eran Hammer-Lahav
>>> <eran@hueniverse.com> wrote:
>>> 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
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkq5oTYACgkQNL8k5A2w/vzZ4ACgqgKa/CZSYJxQS1BuKf1ZOCDZ
1iUAoIVHMxNppDGq9smMLkFKB67x7I3z
=ztVA
-----END PGP SIGNATURE-----