Subject: [OAUTH-WG] 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: Justin Richer <[email-masked]>
Date: Mon, 9 May 2011 15:34:47 -0400

I would still like to see a binding of this to use query or form 
parameters. I have a direct use case for handing out signed URLs to the 
client, for which we're using the OAuth 1.0 signing mechanism without 
tokens today. I'd love to switch to something that we could bind to 
OAuth2, but the restriction of using the Auth header puts the MAC token 
out of reach for my immediate usecase.

  -- Justin

On 5/9/2011 3:22 PM, Eran Hammer-Lahav wrote:
> * An extension to the Set-Cookie header, providing a method for 
> associating a MAC key with a session cookie.
>
> 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.
>

---

From: Peter Wolanin <[email-masked]>
Date: Mon, 9 May 2011 22:11:05 -0400

What about using the cookie header?

We have a sha1-HMAC authentication scheme where we are passing the
HMAC, nonce, timestamp as parts of the cookie header since scripting
languages that cannot access arbitrary headers still usually can
access this header.

-Peter

On Mon, May 9, 2011 at 3:34 PM, Justin Richer <[email-masked]> wrote:
> I would still like to see a binding of this to use query or form parameters.
> I have a direct use case for handing out signed URLs to the client, for
> which we're using the OAuth 1.0 signing mechanism without tokens today. I'd
> love to switch to something that we could bind to OAuth2, but the
> restriction of using the Auth header puts the MAC token out of reach for my
> immediate usecase.
>
>  -- Justin
>
> 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.
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Peter M. Wolanin, Ph.D.      : Momentum Specialist,  Acquia. Inc.
[email-masked] : 978-296-5247

"Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"

---

From: Justin Richer <[email-masked]>
Date: Tue, 10 May 2011 10:40:10 -0400

But that's so much work. :-P

The ease of using a throwaway signed URL as a self-contained information
unit shouldn't be ignored. It requires exactly zero client-side code and
can survive all kinds of HTML repackaging and transit easily.

 -- Justin

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 10 May 2011 08:05:16 -0700

It is a compelling use case, but one that I do not intend on solving within the MAC draft for now. Getting MAC cookies adoption is much higher on my list and anything that makes the specification longer and more complex stands in that way.

However, feel free to propose a mechanism and we can discuss that.

EHL

> -----Original Message-----
> From: Justin Richer [mailto:[email-masked]]
> Sent: Tuesday, May 10, 2011 7:40 AM
> To: Peter Wolanin
> Cc: Eran Hammer-Lahav; Ben Adida; OAuth WG; Adam Barth
> ([email-masked])
> Subject: Re: [OAUTH-WG] HTTP MAC Authentication Scheme
> 
> unit shouldn't be ignored. It requires exactly zero client-side code and can
> survive all kinds of HTML repackaging and transit easily.
> 
>  -- Justin
> 
> > > I have a direct use case for handing out signed URLs to the client,
> > > for which we're using the OAuth 1.0 signing mechanism without tokens
> > > today. I'd love to switch to something that we could bind to OAuth2,
> > > but the restriction of using the Auth header puts the MAC token out
> > > of reach for my immediate usecase.
> > >
> > >  -- Justin
> > >
> > > * An HTTP authentication scheme using a MAC algorithm to
> > > authenticate requests (via a pre-arranged MAC key).
> > >
> 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.
> > >
> > >
> > >

---

From: Adam Barth <[email-masked]>
Date: Tue, 10 May 2011 12:17:39 -0700

> languages that cannot access arbitrary headers still usually can

The Cookie header is extreme fragile.  Browser vendors (me included)
are reticent to touch it.  Additionally, using the Authorization
header lets us use the same mechanism for both cookies and OAuth,
which means an easier path to adoption for servers.

Adam

---

From: Nico Williams <[email-masked]>
Date: Fri, 20 May 2011 15:24:42 -0500

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.

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

Nico
--

---

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

> 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: Nico Williams <[email-masked]>
Date: Fri, 20 May 2011 16:31:52 -0500

> 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 t…

Kerberos has had an option to use time or sequence numbers for a long
time.  We've learned a few things from this experience.

For a memcache-type implementation, timestamps are probably best
because maintaining a sequence number window in memcache,
synchronized, would be a pain, if not impossible.

Other replay cache implementations would likely do better using
sequence numbers, especially when they have a small sequence number
window per-session.

And, of course, memcache isn't going to be durable (but probably it
will be good enough in many cases).  If you set a skew window to be
tight on the future side, then you can compensate for this if you can
detect loss of replay data (hmmm, not likely with memcache, eh?).

One big gotcha to be aware of:

 - Some clocks have lousy resolution, leading to easily repeated
values in high-rate environments.  One fix is to add resolution on the
wire and use random numbers for the unused precision bits.  Another
solution is to not use time.

My advice is that you allow the server to select which of timestamps
or sequence numbers to use.

Also, I strongly recommend that you specify replay cache semantics in
some detail.  Think of the Kerberos V5 replay cache semantics.

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

But even then you need to know when to use TLS.  TLS doesn't solve the
problem when you're trying to solve problems without introducing TLS
in the first place.  This is a serious problem.  You think you're
fixing one problem (cookie theft by passive attackers on open
networks) and you're very likely only making things somewhat harder
for the attacker -- we need to be very careful that the attacker can't
just automate active attacks and still win.

Nico
--

---

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/