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