Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

Hannes Tschofenig <hannes.tschofenig@gmx.net> Tue, 02 December 2014 12:02 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9245B1A1AE6 for <oauth@ietfa.amsl.com>; Tue, 2 Dec 2014 04:02:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAPU0jjj5ihT for <oauth@ietfa.amsl.com>; Tue, 2 Dec 2014 04:02:54 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED9F1A1ACC for <oauth@ietf.org>; Tue, 2 Dec 2014 04:02:54 -0800 (PST)
Received: from [192.168.131.134] ([80.92.119.109]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LlV4F-1YU0zL0Zrb-00bNcD; Tue, 02 Dec 2014 13:02:52 +0100
Message-ID: <547DAA6B.2020602@gmx.net>
Date: Tue, 02 Dec 2014 13:02:51 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Sergey Beryozkin <sberyozkin@gmail.com>, oauth@ietf.org
References: <547DA128.9090606@gmx.net> <547DA2DE.4050400@gmail.com>
In-Reply-To: <547DA2DE.4050400@gmail.com>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="dhgTmrWuPG1xfiBwi0Aspj4Gc340U3afj"
X-Provags-ID: V03:K0:VDb2iV6qJ6LIpzhVsEc1VlxD7EPxVphHsByg+WSOzis/rvV9Gzu cfZKxbuQTIC8NdqY5I/yG9sTKCtHKHLlsEhK9IRqz2DAnc1pSvKrisGX+/wJGOE7ykIrlZ4 pzzG+z3rvPYvkgWemBPB9EviGWSSP+YvuZZ7xWTRvIFxrdsXy8vzg2/KIXRCGVbi2b2MOZK Pvzt8aHDm1u8r9JL2qPcQ==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wfambEiMdPuw8W4PQQfJ_77PbsI
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 02 Dec 2014 12:02:56 -0000

Hi Sergey,

On 12/02/2014 12:30 PM, Sergey Beryozkin wrote:
>>
>> * Scope
>>
>> I think the document needs to be very clear that is only applicable to
>> bearer tokens (and not to PoP tokens). This issue was raised at the last
>> IETF meeting as well.
>>
> Interesting, I was reading the doc yesterday and thought it was good it
> was not talking about specific access token types :-)
> 
> I wonder why a pop token can not be introspected in the interoperable
> way as per the text for the resource server to tale the authorization
> decision ?
> 

The problem is that the AS needs to have the same context as the RS. In
the bearer token case, the RS really only needs to pass the the access
token along but in the PoP case one could imagine a couple of different
solutions.

A possible solution is that the AS sends the RS the necessary key so
that the RS is able to verify the MAC or digital signature covering the
request.

The story would again be different if the PoP solution involves TLS.

Yet another solution would be to also forward the entire request to the
AS (which I wouldn't do).

This is not specified in the current version of token introspection and,
from the responses Justin gave at the last IETF meeting, he does not
want to wait till the PoP work is finished to actually work out the
details.

Finally, from a security point of view it would be extremely important
that the AS only provides a key to the RS if the RS is (a) authenticated
and (b) the audience field from the token matches the RS since otherwise
the PoP security degrades to a bearer token.

Ciao
Hannes

> Thanks, Sergey