Re: [OAUTH-WG] OAuth and HTTP caching

On Tue, Sep 22, 2009 at 9:03 PM, Mark Nottingham <mnot@mnot.net> wrote:

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

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,
>
>
>
> 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
>
>
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>
>
> --
> --
> John Panzer / Google
> jpanzer@google.com / abstractioneer.org / @jpanzer
>
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>