Re: [OAUTH-WG] Use Cases for Signed Tokens

[Hannes Tschofenig <[e-mail]>]

Hi Justin,

thanks for the input. 

A few minor remarks inside: 

On Jan 4, 2013, at 12:45 AM, Justin Richer wrote:

> I'd like to present two use cases for signed tokens, for input into the ongoing MAC/HoK/higher-security discussion. Both of these are actual cases that I've done in the past, and we've used either OAuth 1 or JW* to solve them. I think that with the right tooling, a MAC-token-like thing could be used here. I'll note to the crypto nerds in the group (ahem, John) that I'm going to be using terms like "signing" and "MAC" in a somewhat loose sense, so please don't get hung up on that because I think you actually know what I mean.
> 
> So:
> 
> 1) Message-level signing.
> 
> In this, you protect the content of the HTTP message by signing it with the secret part of the token, effectively what was done in OpenID 2, OAuth1, and the MAC draft. You pick some subset of the HTTP components, add them to your signing base in a predictable and repeatable fashion, and sign it with your secret. You then send the signature along with all of the bare HTTP elements across the wire, and the far side does the same signature generation magic and you're good to go.
> 
> The driving use case to this is security in depth. Yes, you probably still do want everything to go over TLS, but that only protects things in transit between endpoints. It won't protect anything as it gets chewed through an application platform or handed around a server farm. It's also considered "best practice" in many cases. In my experience in the health care space, you almost always want to have multiple layers protecting you.
> 
> An alternative approach here is to use a JW* container like a JWS or JWE to hold all of your parameters (as claims) and sign/encrypt over that. But if you do that, you're not really using HTTP anymore, except as a dumb transport. This is the approach of SOAP, and I doubt that many will come to its defense. (At least, those that don't want to sell you something to process SOAP messages.) We've done this ourselves with a prototype, and losing all of the processing capability that comes with HTTP is a huge programmatic hit.

I understand the value of the message level protection vs. the usage of TLS. If you go to the extreme then you could argue that HTTP is terminated in the HTTP stack and not at the application... This line of argumentation wouldn't be too crazy given that some of the HTTP parameters are not accessible through certain application development platforms, for example. 

If you abstract a bit then the two approaches are not so different. Here is the story:

* With an HTTP-based solution you do
   - put additional parameters into the header to convey the algorithm related information, the access token, and the keyed message digest
   - the keyed message digested is computed over some HTTP headers and it would be possible to repeat the value that is used as input to the keyed message digest computation in another parameter.

* With a JSON-based solution you do
   - put the access token and the encoded JSON structure into a header (or alternatively into the body)
   - the signature or keyed message digest is computed over the JSON structure which includes information that relates to the HTTP request. Again, whether you repeat the values in the JSON itself or only a hash of them has not yet been decided. During the OAuth 1.0 days some folks argued that the values should be repeated so that one can easily detect problems. 

Do you see the similarity (expect for the encoding of the parameters)?

> 
> 2) Signed URL as an authorized artifact.
> 
> In this, you have party A generate a URL with parameters in it, protected by a signature. That URL points to party B, who can validate the signature. Party A then hands that fully baked URL to a third party, C, who can't do anything to the parameters in the URL without messing up the signature. From party B's perspective, so long as that signature is valid, all the parameters in the URL can be trusted and the request can proceed. With a timestamp and nonce parameter (built in to OAuth1), you've even got really nice replay and timeout protection. TLS doesn't do you any good here, because there's a party in the middle who has the full right to hold and view the artifact (URL), but does not have the right to modify it. We've solved this in the past using OAuth1's signature mechanism without tokens (aka, 2-legged OAuth1). We can't currently do this with OAuth2. If we had a generalizable HTTP components signing mechanism (which MAC *almost* is, and could become), then we could.
> 
> Again, you could simply cram everything into a JW* container and send *that* as the sole parameter to a URL and get almost the same result. But then you've got to unpack that JW* container to get all of your parameters, and you're back in SOAP land. And again I posit: nerds hate SOAP.

Let me see whether I get that idea right. In this case you put the OAuth related parameter, access token, and keyed message digest into the URL instead of putting it into the HTTP header (as a parameter). Is this the main difference? If so, why do you care whether the values are carried in the header vs. in the URL? 

A slightly separate question: Out of curiosity, what specifically do you dislike about SOAP (even though it has little relationship to what we do here)? Is it the verbose nature due to the usage of XML? Is it the header that contains values that you may not need? Is it WSDL that most people use with SOAP?

> Hopefully both of these will help inform the discussion and shed some light onto why I think that:
> * MAC tokens (or equivalent) are still a good idea for the WG to pursue
> * Channel-binding and TLS don't solve all security problems

TLS and channel bindings can provide additional security features for an application layer solution. 
The channel binding ensures that the TLS exchange is not terminated at an intermediary. 

So, it might be useful to also see them as additional layer of defense rather than as a competitor.  

> * Abusing JOSE leads to breaking good HTTP designs

I understand the philosophical argument but not necessarily the "breaks good HTTP design". You can still use HTTP in the way you want. How are you constrained when you use a JSON encoding as compared to a custom encoding? 

Ciao
Hannes

> 
> -- Justin
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth