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

Tim <> Tue, 07 June 2011 23:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A024721F8465 for <>; Tue, 7 Jun 2011 16:41:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BcHuyeFTFRQl for <>; Tue, 7 Jun 2011 16:41:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C9FFD21F8463 for <>; Tue, 7 Jun 2011 16:41:33 -0700 (PDT)
Received: (qmail 14024 invoked from network); 7 Jun 2011 23:41:31 -0000
Received: from unknown (HELO ( by with ESMTPS (DHE-RSA-AES256-SHA encrypted); 7 Jun 2011 23:41:31 -0000
Received: (qmail 26041 invoked from network); 7 Jun 2011 23:42:48 -0000
Received: from ( by with SMTP; 7 Jun 2011 23:42:48 -0000
Received: (nullmailer pid 17134 invoked by uid 1000); Tue, 07 Jun 2011 23:41:31 -0000
Date: Tue, 7 Jun 2011 16:41:31 -0700
From: Tim <>
To: Nico Williams <>
Message-ID: <>
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <09c801cc24c2$a05bae00$e1130a00$> <> <00f101cc255e$2d426020$87c72060$> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Wed, 08 Jun 2011 08:39:52 -0700
Cc: OAuth WG <>, HTTP Working Group <>, "" <>, "" <>
Subject: Re: [apps-discuss] [OAUTH-WG] [http-state] HTTP MAC Authentication Scheme
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Jun 2011 23:41:34 -0000

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