Subject: HTTP MAC Authentication Scheme

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 9 May 2011 12:22:23 -0700

(Please discuss this draft on the Apps-Discuss <[email-masked]> 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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 20 May 2011 14:18:21 -0700

> -----Original Message-----
> From: Nico Williams [mailto:[email-masked]]
> Sent: Friday, May 20, 2011 1:25 PM
> To: Eran Hammer-Lahav
> Cc: [email-masked]; Ben Adida; [email-masked]; OAuth WG; Adam
> Barth ([email-masked]); HTTP Working Group
> Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme
> 
> Additional comments:
> 
>  - Using nonces for replay protection is heavy-duty.  It is difficult to
> implement a reliable, secure, high-performance replay cache.  (It is easy to
> implement just a high-performance replay cache: use
> memcache.)
> 
>    I recommend an option to use sequence numbers at the server's choice,
> understanding, of course, that requests will not be received in sequence.
> The use of a sliding sequence number window makes it possible to do at
> least as well as when using nonce, and probably faster while still being
> secure.

We switched to use time since credentials were issued. This should be pretty easy to implement if you really need reply protection by using a small window (clock sync is no longer a problem, just the delay in getting the credentials to the client, which should be a small window).

>  - In an open wifi environment active attacks may not be very difficult, thus
> an option to secure more than just a handful of bits from the request, would
> be nice (all of the request and all of the response, say).  The hard part is how
> to decide when to use one or the other.  Ideally browsers can request more
> protection when the network is reconfigured such that there's one or more
> clear wifi interfaces.

There is just no easy way to do that. If you need more, use TLS.

EHL

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 1 Jun 2011 09:57:19 +1000

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

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

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.

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:

> 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.
>  
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

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