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

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

> -----Original Message-----
> From: Nico Williams [mailto:[e-mail]]
> Sent: Monday, May 09, 2011 11:46 PM
> To: Eran Hammer-Lahav
> Cc: Apps Discuss; [e-mail]
> Subject: Re: [apps-discuss] [saag] Fwd: HTTP MAC Authentication Scheme
> 
> On Mon, May 9, 2011 at 3:29 PM, Eran Hammer-Lahav
> <[e-mail]> wrote:
> >> 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.
> 
> 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?"

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.

EHL