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

Tim,

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

You are referring to draft-salgueiro-secure-state-management-04?

In that document, Section 6 covers responses from the server.  The server
may hash any part of the message it wishes, including the body and selected
header.  It's possible to also have an empty body and including that in the
hash will ensure that no body is inserted where one shouldn't have been.
 
> 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?

We've not looked at HTTP Digest and we were not targeting OAuth with our
document.  Just so that I'm looking at the right "HTTP Digest" text, can you
tell me the document name?  I found several when I did a search.

Paul

Received on Thursday, 9 June 2011 05:13:49 UTC