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

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

From: Tim <tim-projects@sentinelchicken.org>
Date: Wed, 8 Jun 2011 08:32:25 -0700
To: "Paul E\. Jones" <paulej@packetizer.com>
Cc: 'Nico Williams' <nico@cryptonector.com>, 'Eran Hammer-Lahav' <eran@hueniverse.com>, apps-discuss@ietf.org, http-state@ietf.org, 'HTTP Working Group' <ietf-http-wg@w3.org>, 'OAuth WG' <oauth@ietf.org>
Message-ID: <20110608153225.GL1565@sentinelchicken.org>

Hi Paul,

> That's the reason for the MAC.  Once we can ensure the integrity of
> the message exchange, then the existing cookie mechanism can provide
> us with the secure state management capability we need.

Maybe I'm missing something in the MAC authentication draft, but I
don't see how it provides integrity for the "exchange".  In
particular, the body of request messages may be optionally hashed to
protect their integrity, but no such facility seems to be provided for
responses from the server.  In many modern web applications, this
could be trivially exploited by an attacker to inject malicious script
into a server response. 

HTTP Digest authentication provides an option (auth-int) for integrity
protection of both requests and responses and for every
request/response after the initial authentication.  In fact if servers
change nonces each time, reuse of hashes becomes difficult.  Some
level of mutual authentication is also provided and the opaque string
can be used to pass arbitrary extra data between clients and servers.
IIRC, this value can be passed *cross domain* based on a defined white
list.

At risk of repeating myself: Why not just adapt HTTP Digest for OAuth?
That is not just rhetorical, it is a genuine question.  What is HTTP
Digest missing that you need?  

tim
Received on Wednesday, 8 June 2011 15:32:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:41 GMT