W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

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

From: Tim <tim-projects@sentinelchicken.org>
Date: Tue, 7 Jun 2011 16:41:31 -0700
To: Nico Williams <nico@cryptonector.com>
Cc: "apps-discuss\@ietf\.org" <apps-discuss@ietf.org>, "http-state\@ietf\.org" <http-state@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, OAuth WG <oauth@ietf.org>
Message-ID: <20110607234131.GI1565@sentinelchicken.org>

> > A passive attacker can sniff your cookie and thus hijack your session. All
> > you need to accomplish that attack is connect to any open wifi network and
> > use Firesheep. It's a good bit harder to be an active attacker, even on an
> > open wireless network.
> Yes, but only for resources that you've already stated you don't care about.
> If you cared about those resources you'd protect more of the request
> _and_ response, or you'd use TLS.  But you don't want to protect the
> response and you don't want to use TLS and you don't even want to
> protect the request body.  What you're proposing adds a very marginal
> degree of security that will be trivial to defeat on open wifi
> (particularly once the toolset for doing it gets published).
> Are we serious about security?  Or it this just for show?
> Or am I missing something?

I have to agree with Nico here.  In almost all cases I assert that, on
typical modern networks:

  let P = difficulty of passive attack
  let M = difficulty of active (man-in-the-middle) attack

O(P) = O(M)

This isn't to say the "real world" difficulty of an active attack is
just as easy, but it is within a constant factor.  If someone has
published a tool that conducts MitM attacks for the specific protocol
you're dealing with, the difference in difficulty clearly becomes
marginal.  Consider the complexity of the attacks implemented by
sslstrip and yet the relative ease with which you can use it to MitM
all SSL connections.

I didn't bring this up before because I didn't understand any of the
context behind the MAC proposal, but I will now, at risk of sounding

  What is the MAC Authentication proposal intended to accomplish, in a
security sense, above and beyond HTTP Digest?  

Yes, the HTTP Digest spec is, shall we say, a little rough around the
edges, but would it make more sense to simply *fix* the minor problems
with it and slightly extend it to integrate with OAuth?  Note that it
already does allow for arbitrary encrypted blob values to be attached
to the digest...  Ignoring the integration details for a minute
though, how does MAC improve on Digest from a security persepctive?

Received on Tuesday, 7 June 2011 23:41:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:52 UTC