Re: [websec] HTTP Integrity header / Session Continuation scheme

[Hannes Tschofenig <[e-mail]>]

Phillip, 

you are re-inventing OAuth. In your draft you have pretty much written a copy of http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00

You also include a MAC over the HTTP body. Folks in the OAuth community tried that as well and it did not work out too well since intermediaries mess around with the body. 
You also have to selectively cover the header field and the canonicalization has caused problems for developers.

The MAC of only the headers unfortunately does not provide a lot of great properties for the security of the overall application solution since the valuable stuff is in the body. 

I believe that a solution that uses TLS is better, as Google is proposing, since it covers the entire communication (including confidentiality protection) and the TLS Record Layer itself does not lead to a huge computational overhead. The heavy part is the authentication and key exchange. 

Ciao
Hannes

On Nov 14, 2012, at 8:53 PM, Phillip Hallam-Baker wrote:

> There is a new draft at:
> http://tools.ietf.org/html/draft-hallambaker-httpintegrity-02
> 
> One of the biggest holes in the Web Security scheme is the fact that cookies end up being used as bearer tokens and this is a very, very bad idea. It leads to all sorts of cookie stealing schemes which are very hard to deal with because while the HTTP stack is simple, the Web stack of HTTP + HTML + JavaScript + Random plugins is very complicated and many parts were originally designed by people who didn't know what the rest did.
> 
> While we cannot move to eliminate cookies overnight, there are some companies with affiliate schemes that are loosing seven or eight figure sums each year in affiliate fraud. If even one of the major browsers supported a mechanism that prevented cookie stealing, they would see an instant return. 
> 
> 
> The scheme described in the draft is NOT an authentication scheme, rather it describes one small part of the authentication scheme, the part that allows an authentication/authorization context established in one protocol exchange to be continued into further transactions. 
> 
> The mechanism by which the authentication context is established is outside the scope of the draft because that is an area where there can be a lot of useful variation. If an organization has a Kerberos server or SAML infrastructure already then it makes sense to use those. There is never going to be a single canonical means of managing user credentials or presenting/validating them.
> 
> But when you look at how a good authentication mechanism continues on from the point the session has been established it pretty much boils down to some form of identifier to specify the session and some sort of shared secret used to create a result that authenticates the session. We can add in additional information such as nonces and time values and counters and the like to prevent replay attacks but these are generic mechanisms that can be used to the same effect whether we used Kerberos, OpenID, SAML or some newfangled scheme to set up the context.
> 
> 
> I am not quite sure where this would be best progressed. In the short term I was thinking of applying for a provisional HTTP header assignment so that I can start using it in the Web Service protocol I am writing (omnibroker). But right now the scheme could fit in WebSec or could fit in HTTPbis or even the proposed Web Authentication WG.
> 
> Regardless of where the work ends up, I think it is clear that if we are going to specify any new HTTP authentication schemes we are going to end up addressing the issue of session continuation somewhere and that the eventual solution needs to be reviewed by the people in all three places (if they are distinct persons).
> 
> 
> -- 
> Website: http://hallambaker.com/
> 
> _______________________________________________
> websec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/websec