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

Sergey Beryozkin <sberyozkin@gmail.com> Sun, 20 January 2013 21:28 UTC

Return-Path: <sberyozkin@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB3621F86D4 for <oauth@ietfa.amsl.com>; Sun, 20 Jan 2013 13:28:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Voj+b0JntZf for <oauth@ietfa.amsl.com>; Sun, 20 Jan 2013 13:28:37 -0800 (PST)
Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB8B21F84E6 for <oauth@ietf.org>; Sun, 20 Jan 2013 13:28:37 -0800 (PST)
Received: by mail-ea0-f179.google.com with SMTP id d12so1371483eaa.10 for <oauth@ietf.org>; Sun, 20 Jan 2013 13:28:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sAwMdczy8JUfR2h6Vhwk85+/9t/TIZisdwx+3+ijXfU=; b=MkTA63mkL/kpraSa7xrfChEXICJgg8t8D9hqDtDUwuSQ5WIWZ2cCxy/ceBQjzZH7u7 jv2OxA832aj2UPIe94yYbPJZJayYezuLSVMW2AXexya/3oPk7KS5w4OamtGXfrKxZBub sP4CETFdTWiPps48nmG4FzOaDBHO35c1N4JLxOz5lXawgK1AXJgUHtcBuPuorSBmZJGZ FwqYLfq6ss4VAqLAhy9p3cwjJGFy4jQIx3IIe6ent69KaRa9q2T+SKnhw2sZSXTKQzIG 1+XgKlZhRlLC8UBiLj0Yi/qSu3GB1NprEp2ILLFC6X8qw1J9B8nYciR/4X542k8WPN4I zXzQ==
X-Received: by 10.14.173.69 with SMTP id u45mr52961034eel.21.1358717316391; Sun, 20 Jan 2013 13:28:36 -0800 (PST)
Received: from [192.168.2.5] ([89.100.140.13]) by mx.google.com with ESMTPS id k4sm19319558eep.15.2013.01.20.13.28.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Jan 2013 13:28:35 -0800 (PST)
Message-ID: <50FC6166.8010807@gmail.com>
Date: Sun, 20 Jan 2013 21:28:06 +0000
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References: <50E609F6.3080904@mitre.org>
In-Reply-To: <50E609F6.3080904@mitre.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] Use Cases for Signed Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Jan 2013 21:28:39 -0000

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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth