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

[Sergey Beryozkin <[e-mail]>]

Hi,
On 03/01/13 22:45, 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.
>
> 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.
>
>
>
> 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
> * Abusing JOSE leads to breaking good HTTP designs

IMHO it's a very good summary - and a good read.
While this is off-topic, it might also make sense to consider MAC as a 
light weight alternative to JW*, with both token styles nicely 
complementing each other and covering the signed tokens space 
completely, as opposed to prioritizing on a single token only which IMHO 
may not be ideal, which is also highlighted above by Justin

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