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

Thomas Broyer <t.broyer@gmail.com> Fri, 25 October 2013 20:01 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 2BD3911E8137 for <oauth@ietfa.amsl.com>; Fri, 25 Oct 2013 13:01:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Level:
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 h8XJRzLryXNt for <oauth@ietfa.amsl.com>; Fri, 25 Oct 2013 13:01:21 -0700 (PDT)
Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id F239811E814F for <oauth@ietf.org>; Fri, 25 Oct 2013 13:01:20 -0700 (PDT)
Received: by mail-vb0-f48.google.com with SMTP id w16so2843214vbf.21 for <oauth@ietf.org>; Fri, 25 Oct 2013 13:01:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iGbnSLZuB2lACjZHKojvPH2PUataQxdlrm8qnMQTZoE=; b=OLNDr9nUHf86XW0s1CPkrhWuNhfRnH6ne9WOOUv5KAqgX+WZ4fPyRre7ziHrEJs79e NkKAv9/ZLWOEfDP6EJUXiWNMfgTModUCGao87jtxEFtZsin05OxJp4pj33wJp7aRZiBd m9bnAZWbc/9OFA8bkRZuZ9ogBwFrIferdD1rFWYZyE3B1R3XDs9AWqUkxparQcHBQGji OM+uFMIiV3l70IytLec8U6biqvYcrDyUnV1ug1c8xi2G7S53Mr6dXkC2oyNnIOsBQdBI +I5jivr7dd1f5wGkNEGov3kj3tpTNsMxia4aOEDnXe5ITkK8b9iZS7cPBKA+DEaIKi5/ EtMg==
MIME-Version: 1.0
X-Received: by 10.58.180.227 with SMTP id dr3mr923635vec.36.1382731280370; Fri, 25 Oct 2013 13:01:20 -0700 (PDT)
Received: by 10.220.219.132 with HTTP; Fri, 25 Oct 2013 13:01:19 -0700 (PDT)
Received: by 10.220.219.132 with HTTP; Fri, 25 Oct 2013 13:01:19 -0700 (PDT)
In-Reply-To: <526AAA2F.5020705@lodderstedt.net>
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> <CAEayHEN5LoX70OObz2jj-7wmH4qqpSQmhiTbe4kwgwpEt4PMkQ@mail.gmail.com> <526AAA2F.5020705@lodderstedt.net>
Date: Fri, 25 Oct 2013 22:01:19 +0200
Message-ID: <CAEayHEPSvpaiAiq-eBQodxvoCRgK7TZ45i1gm=sXKs0HT1qj1g@mail.gmail.com>
From: Thomas Broyer <t.broyer@gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: multipart/alternative; boundary=047d7b66fbcfc9838604e99636a3
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 20:01:22 -0000

Le 25 oct. 2013 19:28, "Torsten Lodderstedt" <torsten@lodderstedt.net> a
écrit :
>
>
> Am 25.10.2013 11:19, schrieb Thomas Broyer:
>>
>>
>>
>>
>> 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
>
>
> I assume you mean signing the request or at least some request data. Just
signing the access token won't help.

I meant signing the access token + PR identifier/URI + some timestamp, at a
minimum.
I explained it better in my answer to Justin; something like jwt-bearer
applied to access tokens.

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