Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme

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

> -----Original Message-----
> From: Tim [mailto:[e-mail]]
> Sent: Thursday, June 09, 2011 7:42 AM
> To: Robert Sayre
> Cc: Eran Hammer-Lahav; OAuth WG; [e-mail]
> Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC
> Authentication Scheme
> 
> > Digest has a bunch of problems. See this document
> >
> > http://tools.ietf.org/html/draft-ietf-httpbis-security-properties-05#s
> > ection-2.2.2
> >
> > for a short tour of them.
> 
> Thanks for the link.  I totally agree with all of this, and in fact there are more
> MitM attacks possible than are alluded to in that document. This is one of the
> two reasons I brought up Digest initially.  The MAC proposal does not appear
> to provide any additional security over Digest, and yet Digest is still
> susceptible to MitM attacks.
> 
> We can pick and prod at the MAC proposal all we want from a security
> perspective, but we'll probably end up at the same place that Digest is at,
> security-wise.  We'll still have a protocol that can't defend against MitM
> attacks.  So what is the point in providing integrity again?
> 
> We need to use TLS.  Everywhere.

Sure.
 
> The more you look at advanced web attacks (MitM downgrade attacks, DNS
> rebinding attacks, etc), the more you realize that most of these are
> addressed by TLS if only it were used everywhere.
> 
> It's fine to bring out special-purpose authentication protocols.
> Authentication can happen in a variety of ways either within TLS or tunneled
> over it (hopefully with channel binding), but don't pretend you'll be doing
> anyone favors by trying to provide partial integrity protection that is
> ultimately ineffective.  Just focus on better authentication and
> key/certificate management and let TLS do the rest.

Modern web applications require a lot of third-party hosted services: analytics, advertising, plug-ins, etc. Until everyone deploys TLS, including such non-TLS bits in a TLS page cause the browser to show a broken TLS state in the address bar. For most web users, that's more of a red flag (valid TLS but with some resources loaded without TLS) than no TLS at all. The reality is that it is really hard to deploy TLS applications today without having issues with at least one vendor (especially when that vendor is an ad network you rely on for your profits).

So while we wait for the web to catch up and deploy TLS (and this effort does not delay that), we should try and do something about trivial attacks like Firesheep. Yes, adding MAC to cookies without TLS does not provide anywhere near the protection of TLS, but it is better than nothing, when TLS is not available.

Note that the MAC authentication scheme is not exclusively about cookies, and has value beside just making session cookies better.

EHL