Subject: [saag] Fwd: [apps-discuss] HTTP MAC Authentication Scheme

From: Paul Hoffman <[email-masked]>
Date: Mon, 9 May 2011 12:39:36 -0700

Of interest to some here.

> From: Eran Hammer-Lahav <[email-masked]>
> Date: May 9, 2011 12:22:23 PM PDT
> To: "[email-masked]" <[email-masked]>
> Cc: Ben Adida <[email-masked]>, "[email-masked]" <[email-masked]>, OAuth WG <[email-masked]>, "'Adam Barth \([email-masked]\)'" <[email-masked]>, HTTP Working Group <[email-masked]>
> Subject: [apps-discuss] HTTP MAC Authentication Scheme
> 
> (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: Nico Williams <[email-masked]>
Date: Mon, 9 May 2011 15:03:11 -0500

> Of interest to some here.

Indeed.  My GSS-REST proposal uses something like this too.

Regarding the question of when to include a hash of the body in the
normalized request string that gets MACed... If one is using TLS, then
I suggest adding the TLS channel binding into the MAC input string and
drop the body hash.  This will speed up operation, since there's no
need to hash the body (think of the performance impact of hashing the
request body in an implementation that uses sendfile()!).

I don't see the point of attempting to provide only partial integrity
protection (e.g., the draft doesn't say to include ever request header
into the MAC input) if there's no TLS.  In fact, I don't see the point
of not using TLS, but if TLS avoidance is desired then all of the
request (minus the MAC) and response should be covered by the MAC.

The response headers also should get a MAC.

Using channel binding means that the MAC input string can be much
smaller -- it need only be fresh if the TLS CB type is
tls-server-end-point.  If the CB type is tls-unique then no nonce nor
credential age elements are needed to establish freshness.  And back
to the tls-server-end-point case, if the freshness element is a
sequence number then the MACs can be pre-computed, with a small
sliding window (implemented as a small bitmap and highest number seen
state elements).

Finally, presumably it's the application that generates and validates
the MACs, not HTTP itself.  Correct?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 10 May 2011 01:45:30 -0500

On Mon, May 9, 2011 at 3:29 PM, Eran Hammer-Lahav <[email-masked]> wrote:
>> normalized request string that gets MACed... If one is using TLS, then I
>> suggest adding the TLS channel binding into the MAC input string and drop
>> the body hash.  This will speed up operation, since there's no need to hash
>> the body (think of the performance impact of hashing the request body in an
>> implementation that uses sendfile()!).
>
> It is still not clear when hashing the body is really important, and if this should be just an optional feature or something that is required. If it is optional, it is not clear how the server should indicate to the client that it is required for any particular protected resource. We're still debating that and waiting for some deployment experience to guide us.

See below.

>> I don't see the point of attempting to provide only partial integrity protection
>> (e.g., the draft doesn't say to include ever request header into the MAC
>> input) if there's no TLS.  In fact, I don't see the point of not using TLS, but if
>> TLS avoidance is desired then all of the request (minus the MAC) and
>> response should be covered by the MAC.
>
> The point is to be practical given the target audience and use cases we have for this: web developers.

Surely not.  Surely the point is to make some attack more difficult.
Yes, surely it's nice to make it easy for developers to use it, but
that's a secondary issue.  The primary issue, what I'm not getting
from the I-D, is what you're trying to protect against.

"What is your threat model?"

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 10 May 2011 02:28:28 -0500

On Tue, May 10, 2011 at 2:06 AM, Eran Hammer-Lahav <[email-masked]> wrote:
> An eavesdropper grabbing plaintext credentials and using them to gain access to protected resources. That's 99% of it, with the other 1% being that sending plaintext credentials over TLS can still leak due to incorrect implementation, or attacks on dynamic configuration, leading the client to send its plaintext credentials over TLS to the wrong server.

That's what I thought.  If you add channel binding (meaning, to make
it real simple: add the server's certificate, or hash thereof, to the
MAC inputs -- the server cert is available in at least some JavaScript
implementations, like Firefox's) then you'll avoid those attacks that
you mention when using TLS.

It's not clear to me if you want to allow use of this MAC without
using TLS.  From the above I guess so, since the MAC alone will take
care of the eavesdroppers.

Nico
--

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 10 May 2011 00:06:22 -0700

> -----Original Message-----
> From: Nico Williams [mailto:[email-masked]]
> Sent: Monday, May 09, 2011 11:46 PM
> To: Eran Hammer-Lahav
> Cc: Apps Discuss; [email-masked]
> Subject: Re: [apps-discuss] [saag] Fwd: HTTP MAC Authentication Scheme
> 
> >> normalized request string that gets MACed... If one is using TLS,
> >> then I suggest adding the TLS channel binding into the MAC input
> >> string and drop the body hash.  This will speed up operation, since
> >> there's no need to hash the body (think of the performance impact of
> >> hashing the request body in an implementation that uses sendfile()!).
> >
> > It is still not clear when hashing the body is really important, and if this
> should be just an optional feature or something that is required. If it is
> optional, it is not clear how the server should indicate to the client that it is
> required for any particular protected resource. We're still debating that and
> waiting for some deployment experience to guide us.
> 
> See below.
> 
> >> protection (e.g., the draft doesn't say to include ever request
> >> header into the MAC
> >> input) if there's no TLS.  In fact, I don't see the point of not
> >> using TLS, but if TLS avoidance is desired then all of the request
> >> (minus the MAC) and response should be covered by the MAC.
> >
> Yes, surely it's nice to make it easy for developers to use it, but that's a
> secondary issue.  The primary issue, what I'm not getting from the I-D, is
> what you're trying to protect against.
> 

EHL