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

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Nov 2012 20:53:57 -0500

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/

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Nov 2012 09:05:29 +0000

Just on one point...

> even the proposed Web Authentication WG.

The proposal is for an HTTP authentication WG and not for
a broader web authentication WG. Only worth pointing out
since that caused some confusion at the BoF.

Ta,
S.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 16 Nov 2012 09:41:20 -0500

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:

> 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).
> 
> 
> -- 
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 22 Nov 2012 11:58:55 -0500

No, I am not re-inventing OAuth any more than they are re-inventing Digest.

OAuth like all the rest of the Web Authentication schemes (yeah I know they
claim to only do AuthZ but that was a necessary fiction) has to fight with
the fact that HTTP infrastructure is not adapted well. So the scheme is
split over three layers.

On Fri, Nov 16, 2012 at 9:41 AM, Hannes Tschofenig <
[email-masked]> wrote:

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

SCREW INTERMEDIARIES

This is designed for authentication binding in Web Services. Those almost
never go through an intermediary except for purposes of bypassing firewalls.

In this case the desired behavior is to BREAK if the contents are tampered
with. The whole point is to detect modification by a MITM. If a proxy
changes a linebreak then the desired behavior is BREAK the protocol.

Yes, people who put up broken intermediaries are going to break protocols.
But that does not mean that we should drop requirements that are essential
in some environments.

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

Agreed, but there are cases where content is carried in headers in Web
Services.

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

I don't think 'Google' is proposing anything, its individual participation,
remember. What they were proposing in HTTP-Bis was to use TLS all the time
so that they could avoid the need to think about intermediaries polluting
the channel. I think that is a perfectly sensible solution to the
intermediary problem but still does not address the problem of dealing with
Authorization at the transport layer.

TLS is useful but it hasn't got a viable client auth story and the binding
of TLS auth to the HTTP layer is really problematic.

Channel binding helps to an extent, but it still leaves the client auth
mechanism flapping in the breeze. What applications like Web Services would
have to do to use TLS is to bury their client credentials into the TLS
layer through APIs that mostly don't exist and then the servers would have
to fish them out - fighting the fact that in many cases the server end of
the TLS session terminates before the Web Service server (inescapable in
two and three tier server architectures).

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 22 Nov 2012 12:21:08 -0500

I can implement all the features describes in the OAUTH-MAC draft in my
scheme but I don't think the reverse is true.

The idea here is that we take out the session continuation component and
make it a single common feature that OAUTH, OpenID, SAML and Web Services
authentication schemes can all share so that we have one way to do it for
all HTTP schemes.

Designing in the context of OAUTH only leads to a scheme that is difficult
to then apply as a generic. There are two problems to be addressed in a
session continuation mechanism, one is which parts of the message (if any)
should be covered by the authentication mechanism and second how to prevent
replay attacks. Which choices you take are going to depend on which
particular authentication problem to solve.

If what we are trying to do here is to simply replace bearer token cookies
with something less disastrous then we are not going to want to have any
authentication binding to the content at all so that we avoid the problem
of intermediaries raised by Hannes etc. We are going to be concerned about
replay attacks though and probably want to ensure that the solution is
stateless at the server.

If what we are doing is looking to replace the SOAP/WS-Security stack then
we are going to want a MAC over the message contents and probably the
request URI as well. Replay attack might not be a concern then because we
might prefer to do that in the application layer or if we do it in the HTTP
layer we probably don't care much about the overhead of per connection
state.