RE: [apps-discuss] HTTP MAC Authentication Scheme

From: Eran Hammer-Lahav <eran@hueniverse.com> · Date: Wed, 1 Jun 2011 08:00:12 -0700

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: Tuesday, May 31, 2011 4:57 PM
> To: Eran Hammer-Lahav
> Cc: apps-discuss@ietf.org; Ben Adida; http-state@ietf.org; OAuth WG;
> 'Adam Barth (adam@adambarth.com)'; HTTP Working Group
> Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme
> 
> Hi,
> 
> Reading draft -05.
> 
> The "normalized request string" contains the request-URI and values
> extracted from the Host header. Be aware that intermediaries can and do
> change these; e.g., they may change an absolute URI to a relative URI in the
> request-line, without affecting the semantics of the request. See [1] for
> details (it covers other problematic conditions too).
> 
> It would be more robust to calculate an effective request URI, as in [2].

I'll take a look.

> Also, if you include a hash of the request body, you really need to include a
> hash of the body media type.

This was suggested before, but are there really attack vectors for this?

The problem is that content-type is a pretty flexible header, which means normalization of the header will be required (case, parameter order, white space, etc.).

I would argue that if you are using MAC with body hash and an attacker changing the media type can cause harm, you should use additional methods to secure the content-type (such as making the body self-describing).

> Generally, I think that people can and will want to include other headers; just
> because *some* developers can't get this right doesn't mean we should
> preclude *all* developers from doing it. It'd be really nice to see this either
> leverage DOSETA [3][4], or at least offer a clean transition path to it.

If someone comes up with a practical and secure way to normalize HTTP request headers, they can either define a new authentication scheme or use the 'ext' parameter to pass the additional values. I would vote for a new scheme. MAC is trivial to implement and interoperate. That simplicity comes at a significant lack of features, and limiting extensibility is a design goal.

EHL

> Regards,
> 
> 1. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-
> 4.1.2
> 2. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.3
> 3. http://tools.ietf.org/html/draft-crocker-dkim-doseta-00
> 4. http://tools.ietf.org/html/draft-crocker-doseta-base-02
> 
> 
> On 10/05/2011, at 5:22 AM, Eran Hammer-Lahav wrote:
> 
> > (Please discuss this draft on the Apps-Discuss <apps-discuss@ietf.org>
> mailing list)
> >
> > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token
> >
> > The draft includes:
> >
> > * An HTTP authentication scheme using a MAC algorithm to authenticate
> requests (via a pre-arranged MAC key).
> > * An extension to the Set-Cookie header, providing a method for
> associating a MAC key with a session cookie.
> > * An OAuth 2.0 binding, providing a method of returning MAC credentials
> as an access token.
> >
> > Some background: OAuth 1.0 introduced an HTTP authentication scheme
> using HMAC for authenticating an HTTP request with partial cryptographic
> protection of the HTTP request (namely, the request URI, host, and port).
> The OAuth 1.0 scheme was designed for delegation-based use cases, but is
> widely "abused" for simple client-server authentication (the poorly named
> 'two-legged' use case). This functionality has been separated from OAuth 2.0
> and has been reintroduced as a standalone, generally applicable HTTP
> authentication scheme called MAC.
> >
> > Comments and feedback is greatly appreciated.
> >
> > EHL
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 