Re: [OAUTH-WG] Adding use case to draft-ietf-oauth-pop-architecture-05

Justin Richer <jricher@mit.edu> Mon, 23 November 2015 23:25 UTC

Return-Path: <jricher@mit.edu>
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 8D9271A8864 for <oauth@ietfa.amsl.com>; Mon, 23 Nov 2015 15:25:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.786
X-Spam-Level:
X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 TqRgynYfQhnA for <oauth@ietfa.amsl.com>; Mon, 23 Nov 2015 15:25:09 -0800 (PST)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A62E1A21A3 for <oauth@ietf.org>; Mon, 23 Nov 2015 15:25:08 -0800 (PST)
X-AuditID: 1209190f-f79d06d000004b20-01-5653a0528aa9
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id F9.94.19232.250A3565; Mon, 23 Nov 2015 18:25:06 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id tANNP58J001578; Mon, 23 Nov 2015 18:25:06 -0500
Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tANNP36k022423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Nov 2015 18:25:04 -0500
To: Phil Hunt <phil.hunt@oracle.com>
References: <56536DB2.2020609@gmx.net> <BA46B718-85FD-4EB1-8406-95CEFC435569@oracle.com> <E3E3DB02-F318-4A00-BF9B-3BE0A93749F3@mit.edu> <ACABA87C-920C-4210-B6D6-55569EAC05DE@oracle.com>
From: Justin Richer <jricher@mit.edu>
Message-ID: <5653A04C.5030804@mit.edu>
Date: Mon, 23 Nov 2015 18:25:00 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <ACABA87C-920C-4210-B6D6-55569EAC05DE@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IR4hTV1g1aEBxmcPe2hcXSnfdYLU6+fcVm sWB+I7sDs8fiTfvZPJYs+cnk8fHpLZYA5igum5TUnMyy1CJ9uwSujO2XZzEWNCtWfP3/g6mB cbt0FyMnh4SAicTBhi2sELaYxIV769m6GLk4hAQWM0n8OnifGcLZyCgxaedMNpAqIYHbTBJn vnCD2MICgRKTzswH6xYRUJH4dvU6I0TDfkaJ/vaFQA4HB7NAvMTqjfEgNWwCqhLT17Qwgdi8 AmoSC+dOZQexWYDirfPXgc0XFYiReL9pFSNEjaDEyZlPWEBsTgE7ieWPV4HVMAuYSczb/JAZ wpaXaN46m3kCo+AsJC2zkJTNQlK2gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6JXm5miV5q SukmRnBQS/LvYPx2UOkQowAHoxIP74yi4DAh1sSy4srcQ4ySHExKoryfJgKF+JLyUyozEosz 4otKc1KLDzFKcDArifCumgeU401JrKxKLcqHSUlzsCiJ88794hsmJJCeWJKanZpakFoEk5Xh 4FCS4FWbD9QoWJSanlqRlplTgpBm4uAEGc4DNFwEpIa3uCAxtzgzHSJ/ilGX49CU+2uZhFjy 8vNSpcR59UCKBECKMkrz4OaAklHC28OmrxjFgd4S5nUAqeIBJjK4Sa+AljABLTlSEgiypCQR ISXVwGjGb7aGK88g82b+k5l9dRsW2ugu8JHKvVDtzKFx5/qEd4sZ9Aqf5Irc2rnGoSa9V7n6 Xau4XN+9dkHvO39+TH2+Zc4m7alPVh9MUd5j3J5jdbO5a3n8wew2bRNdV8+1uT+v/3jwvo// 7Xrma0yz1mvOWM4RcUnppF5EhUdg4957jh/db58uWqDEUpyRaKjFXFScCAAU6JR5IQMAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/rS4NgZ5xd7DexF4c5rcky_fh_Qg>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Adding use case to draft-ietf-oauth-pop-architecture-05
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 23 Nov 2015 23:25:11 -0000

I'm agreeing with you that because the confidential client authenticates 
while using the refresh token then the same set of issues addressed by 
PoP don't automatically apply as they do to access tokens.

  -- Justin

On 11/23/2015 3:57 PM, Phil Hunt wrote:
> Huh?
>
> We’re not talking about PoP with the resource server.
>
> This is a new issue regarding refresh tokens that John and Hannes are raising.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>> On Nov 23, 2015, at 12:11 PM, Justin Richer <jricher@mit.edu> wrote:
>>
>> Access tokens and refresh tokens provide different attack surfaces.
>>
>> The refresh token is *potentially* a one-time-use token, but not necessarily so. Confidential clients are still subject to having their credentials stolen across HTTP Basic, but that’s where things like OIDC’s “private_key_jwt” authentication method come into play. Making the refresh token itself PoP doesn’t solve that issue alone.
>>
>> You can’t use things like that at the resource server because the client, by design, doesn’t authenticate there.
>>
>> — Justin
>>
>>> On Nov 23, 2015, at 2:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
>>>
>>> We discussed that confidential clients are not subject to any risks since by definition they already have a unique proof-of-possesion necessary to redeem the refresh token which is already a one-time token.
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>
>>>> On Nov 23, 2015, at 11:49 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> at the Yokohama IETF meeting John gave a presentation about the need to
>>>> also secure access and refresh tokens against unauthorized access and
>>>> loss, see
>>>> https://www.ietf.org/proceedings/94/minutes/minutes-94-oauth
>>>>
>>>> Unfortunately, this threat has not been documented in the current PoP
>>>> architecture draft while other threats have been captured appropriately
>>>> (see Section 3 of
>>>> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-05).
>>>>
>>>> Since we are currently finalizing the work on the PoP architecture
>>>> document I wanted to contribute text about this use case:
>>>>
>>>> ------------------------
>>>>
>>>> 3.5.  Preventing Loss of Access and Refresh Tokens
>>>>
>>>> RFC 6749 distinguished two types of clients, namely public and
>>>> confidential clients, based on their ability to authenticate securely
>>>> with the authorization server. Even with confidential clients there is
>>>> the risk, combined with certain deployment choices, that an attacker
>>>> gains unauthorized access to access and refresh tokens. If those tokens
>>>> are bearer tokens then the adversary can re-use them to gain access to
>>>> the protected resource, for example to post messages to a social
>>>> networking site to distribute spam.
>>>>
>>>> With proof-of-possession tokens an adversary not only needs to gain
>>>> access to a database where those tokens are stored but it also needs to
>>>> retrieve the associated keying material. Assuming that these keys are
>>>> stored more securely, for example, in a hardware security module or
>>>> trusted execution environment this specification offers an additional
>>>> layer of defence.
>>>>
>>>> Since refresh tokens offer a client the ability to request access tokens
>>>> the need arises to also define proof-of-possession functionality for
>>>> refresh tokens (unless keys bound to the access token cannot be changed
>>>> during the lifetime of the refresh token).
>>>>
>>>> ------------------------
>>>>
>>>> Please let us know what you think about including this text into the
>>>> next revision of the PoP architecture document and if you have some
>>>> suggestions for improved wording.
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth