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

[Eran Hammer-Lahav <[e-mail]>]

Hi Nico,

> -----Original Message-----
> From: [e-mail] [mailto:apps-discuss-
> [e-mail]] On Behalf Of Nico Williams
> Sent: Monday, May 09, 2011 1:03 PM

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

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.

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

We have 3 years of experience asking web developers to perform request normalization and the results are pretty sad. OAuth 1.0 includes a pretty simple normalization of the request URI which ended up being a huge problem for many developers. If someone can come up with a simple way to canonicalize an HTTP request in a way that works with proxies and other intermediaries, and is easy to implement and debug, I'm happy to reconsider.
 
> The response headers also should get a MAC.

We're considering adding response verification, but not sure where to put it.

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

Channel binding is hard to implement the way most web frameworks are used, as well as how browsers manage their stack. Also, lack of TLS is the main driver behind this proposal.

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

Not sure what you mean, but this operates just like HTTP Basic and Digest in terms of its relation to HTTP.

EHL