Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04

Thomas Broyer <t.broyer@gmail.com> Fri, 25 October 2013 09:20 UTC

Return-Path: <t.broyer@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 C696A11E8392 for <oauth@ietfa.amsl.com>; Fri, 25 Oct 2013 02:20:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Level:
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD+TwpM1ifFb for <oauth@ietfa.amsl.com>; Fri, 25 Oct 2013 02:20:23 -0700 (PDT)
Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD8D11E839E for <oauth@ietf.org>; Fri, 25 Oct 2013 02:20:17 -0700 (PDT)
Received: by mail-vb0-f51.google.com with SMTP id x16so2512442vbf.38 for <oauth@ietf.org>; Fri, 25 Oct 2013 02:20:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YFePt1PMDh56pY/8WHEdC4ICbNaua3qaduG7FOZSO8U=; b=DUTYR6Lir6F1qRSn39oHUBVXZ0WfWxPmMKgd3yodXU1GAY2O/+15SRQwfbAFN9HjjQ mC4AXWJqWA0KV5jBsltl+rRD7khjSUqQ78wC7R01QvYUD+TleM/+zWpAWScOANrDJID4 EYAzuazVS2AOSOBtJeC18CBczd78fCJJxfmLVd/He8+FoA+FjsqYAdzTYX4jlDMMDHNo Z4H6JhvfL7l62m68RKvEuzycZyTJ5bxV1sD2ESlppxVEySsROnSKxpgchSxm9q45ZObP lRisivy+PeK+hjdhDwfVSm8tlse9Rq+Yh6zyHHSSHDBpVfeNuieAk4BGsI+Z4kTkANym M6Bg==
X-Received: by 10.58.233.98 with SMTP id tv2mr3922893vec.11.1382692810507; Fri, 25 Oct 2013 02:20:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.219.132 with HTTP; Fri, 25 Oct 2013 02:19:50 -0700 (PDT)
In-Reply-To: <9adcccce-7c48-47b8-b9b8-77a4ce439254@email.android.com>
References: <CAEayHENijdeTVu9-OxsnrJEh0JQBrvQo0eKWSjFvXSLqwzVRWg@mail.gmail.com> <63692DF5-4616-4F53-B12E-518397CFEFB3@mitre.org> <CAEayHEMZdOY5G=A5nc_pA14gUcyNpbbeb-pVpo7Cf_yB70Mjjw@mail.gmail.com> <9adcccce-7c48-47b8-b9b8-77a4ce439254@email.android.com>
From: Thomas Broyer <t.broyer@gmail.com>
Date: Fri, 25 Oct 2013 11:19:50 +0200
Message-ID: <CAEayHEN5LoX70OObz2jj-7wmH4qqpSQmhiTbe4kwgwpEt4PMkQ@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: multipart/alternative; boundary=089e0115ef9ccdd0e704e98d411f
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04
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: Fri, 25 Oct 2013 09:20:25 -0000

On Thu, Oct 24, 2013 at 7:50 AM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> Hi Thomas,
>
> we generate access tokens per resource server in order to mitigate this
> and other risks. You must issue those tokens to different audiences
> (resource server id) and the resource servers must validate if the token is
> issued for its particular audience. Otherwise a compromised resource server
> can still abuse the tokens.
>
> Talking about burden: You need to compare the effort needed to obtain
> different access tokens to the effort needed to implement proof of
> possession.
>

On our backlog is also support for "service accounts" (to use Google's
terminology), so clients will likely need to do some crypto-related work.
Asking them to do it for each and every request to sign the access token
might not be that much of a problem (if they have the right tools;
google-oauth-java-client for instance does a great job making all of this
easier, and google-api-java-client adds service accounts support with a
just-as-easy-to-use API:
https://code.google.com/p/google-api-java-client/wiki/OAuth2#Service_Accounts;
same for PHP, Python, etc.)
That said, I'm rather new to crypto too, so I might be oversimplifying
things…
I'll check with the project manager and project owner which approach we'd
use (we could also support both…)

I recommend you to take a look into the OAuth threat model for a discussion
> of this threat ( http://tools.ietf.org/html/rfc6819#section-4.6.4).
>

Thanks for the pointer. I had already read that RFC but somehow forgot
about some details, and failed to check it back for that particular problem.


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>