Re: [OAUTH-WG] Assertions: Client authentication for non-token endpoints?

Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 24 April 2014 09:04 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 39C221A07ED for <oauth@ietfa.amsl.com>; Thu, 24 Apr 2014 02:04:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level:
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] 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 L7t206a63Ght for <oauth@ietfa.amsl.com>; Thu, 24 Apr 2014 02:04:46 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 428F11A07A6 for <oauth@ietf.org>; Thu, 24 Apr 2014 02:04:46 -0700 (PDT)
Received: from [192.168.131.128] ([80.92.122.106]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MLA45-1WdWZ51TVJ-000NFr; Thu, 24 Apr 2014 11:04:38 +0200
Message-ID: <5358D2D8.5080402@gmx.net>
Date: Thu, 24 Apr 2014 11:01:12 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Justin Richer <jricher@mitre.org>, Mike Jones <Michael.Jones@microsoft.com>, "oauth@ietf.org" <oauth@ietf.org>
References: <4E1F6AAD24975D4BA5B16804296739439A191DC0@TK5EX14MBXC288.redmond.corp.microsoft.com> <5357EF2E.1020503@mitre.org>
In-Reply-To: <5357EF2E.1020503@mitre.org>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lt6npRW1UInK355eu5f0SQXkN28IpdX83"
X-Provags-ID: V03:K0:BWEMyGJHuOlI1TN+Tqq3BaOeU6iishYfSkefvJy5Z83V8Ul7egJ 2Gh+LEeLPgE3I36s+mX1Ay9HI4l5MhyG1yH6tCbwUCcrwp9L9swDr8AXVh4Skv6aJ/wWFha nAZq+kBXJcq/WADnRA3bocXZnRdNBVaKvcLUkcpaRusnSQA7xekuyL9XTSjoe30CBQrbTyB vVLl9Qlzd5923h98JKwNQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/p5M66AbaklMwNxfKAZKxoMatS6A
Subject: Re: [OAUTH-WG] Assertions: Client authentication for non-token endpoints?
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: Thu, 24 Apr 2014 09:04:48 -0000

I believe that Mike is right that we might need to describe these
aspects in the token introspection document.

Ensure proper authentication of the resource server to the authorization
server is extremely important for the security (particularly in context
of the PoP work we are doing right now). If everyone is able to retrieve
the session key for the respective PoP-enable access token then the
additional security value goes to null.

Ciao
Hannes


On 04/23/2014 06:49 PM, Justin Richer wrote:
> For introspection, we really just wanted to say "you can authenticate
> the caller (client or RP) just like you would to the token endpoint". So
> if you've got the means to do that with the assertion draft or with
> client secrets or TLS certs or anything else, go for it. I would not
> read the text of the assertions draft as restricting this other use case.
> 
>  -- Justin
> 
> On 04/23/2014 12:42 PM, Mike Jones wrote:
>> The assertions draft is only trying to describe how to perform
>> assertion-based authentication at the Token Endpoint.  Other drafts,
>> such as the introspection draft, could explicitly say that this can
>> also be done in the same manner there, but that's an extension, and
>> should be specified by the extension draft, if appropriate - not in
>> the assertions draft.
>>
>> Justin may have more to say about the applicability or lack of it to
>> the introspection draft, but I'm personally not familiar with it.
>>
>>                 -- Mike
>>
>> -----Original Message-----
>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes
>> Tschofenig
>> Sent: Wednesday, April 23, 2014 5:09 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Assertions: Client authentication for non-token
>> endpoints?
>>
>> Hi all,
>>
>> in a discussion about re-using the client authentication part of the
>> assertion framework for other specifications currently in progress I
>> ran into the following question:
>>
>> Section 6.1 of
>> http://tools.ietf.org/html/draft-ietf-oauth-assertions-15 talks about
>> the client using the assertion with the **token endpoint**.
>>
>> Now, it appears that one cannot use the client authentication with
>> other endpoints, such as the introspection endpoint defined in
>> http://tools.ietf.org/html/draft-richer-oauth-introspection-04#section-2
>>
>> Am I reading too much into Section 6.1 of the assertion draft?
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>