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

Hannes Tschofenig <hannes.tschofenig@gmx.net> Tue, 24 November 2015 07:25 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 8BFEA1A01D6 for <oauth@ietfa.amsl.com>; Mon, 23 Nov 2015 23:25:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.185
X-Spam-Level:
X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ii2qDTHWWRKf for <oauth@ietfa.amsl.com>; Mon, 23 Nov 2015 23:25:20 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 358F11A01F2 for <oauth@ietf.org>; Mon, 23 Nov 2015 23:25:20 -0800 (PST)
Received: from [192.168.10.143] ([80.92.121.34]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LnCkb-1aXQyz1Oof-00hJXR; Tue, 24 Nov 2015 08:25:12 +0100
To: Phil Hunt <phil.hunt@oracle.com>, Justin Richer <jricher@mit.edu>
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: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <565410D6.40507@gmx.net>
Date: Tue, 24 Nov 2015 08:25:10 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="T7clmK5vn842GK9a5Vkg6twfB2lKOwX00"
X-Provags-ID: V03:K0:Am1JpxdH2plFor7/fBnnVNDCeu6eYQrfk0kyywghHMODyITuKyo 9s0cEq/OQWYHFgdf+zI+Fb64JnaHJ/31ckA+7tRTFtiooZPkGUnmDCp4fpaYzx5Jyg6hh6s HLUudTFTqvlWqpl81/SlcbewRO4aex0urUiGnQocN/2/uGZcxvKttlZhhWv4kYosjtyWopy ZvRck+uWEZh1DrwGcAvOA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:t0IoOxEC6Mw=:2SkP0UknvpKmJCc4i+FY+8 0McAihwGlDkCO+3/A2L+IrqCAyxqSjZUU26zqrlIELbk9nYkR76uH7I7wnRMimoIqz0kygNWA SX4U8vHWvzzRDKVY0luF6NfAm+LSkHTSrOjwaZ6YAFUS3ATebbyUstDdcEO8sVPyQZkuSuy7o QRtay+aGDDwUjZkPEXYew8peLJP2Y3NqXMBapVmAtPsYAoSfBGje4hFdPxXwel3NkGEZ/vLpG UWGGqYfEv3KC0HQjtzBIB0hgDQqkzTt0J4CVYkAZ2wWmSLscFMjK9I10TFsmPCrzGA5HNsGAY b2Eb53joSNT0TOtFX/Oac/6vgecd9Fs0R3hNM5bELJv0k64lIiSfYZXAMr58WjgSFHNI9CSHv ZAT29QNfjjSRjCvPpbVaEQg4UBJ9a+ICzZm6Xio5JGPVVBlEzZfK0lzx0hgHBBqA43SZhUQCe aAspyJHZScpO1ZHMMEURUF7H1Guzt57iBd6a6+QUWW7r9kXFWBSAO0ZrFRBa/4a8VG2XMS3g/ WOWbppDdm15lfgF4K79N2V+ZyiieDP8p/r9L39AQz7rfhOW7i8ahY5z+nl8o3CLxG9Rdd56R8 Xav7GaC3KG1UykUdl0df86jDdmrlMBMDDG+WDVR5jR5eDiW7M8Lux3AOyS/F9Pb9iGBfNv5b7 dCiYoW3hryLcSeDlK+x5CIPhNVsYo2tVXzo4rqxlfO1Aais+ytleUcuN75IFPMITNEFJmMAsH cBqfFz6ecK2DPcRkm/dRiuCHBVflp6APp4dYpErP9Tsl3We2EfzBoAlsjms=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Rqv13eJtQiqlKhECIiPjdEYUqG0>
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: Tue, 24 Nov 2015 07:25:22 -0000

Hi Phil, Hi Justin,

maybe I need to improve the text here but there are two aspects that I
believe are worth adding, namely

a) the OAuth client may leak access tokens.
This has happened in the past, for example with Buffer:
http://www.programmableweb.com/news/why-attack-buffer-was-serious-wake-call-web/analysis/2013/11/04

This use case motivates the use of PoP tokens. This of course only works
if the attacker is not able to get the token plus the key.

b) the OAuth client may leak other credentials as well, such as refresh
tokens

From an overall solution point of view we tend to talk about access
tokens but, of course, other credentials that may allow the adversary to
get the access token also need to be secured. This includes the refresh
token (if it is more than a one-time key).

I particularly pointed out refresh tokens since we discussed them at the
last IETF meeting. Justin and John mentioned other credentials as well
(such as the client credentials).

I think it is worthwhile to point this out to the reader as well.

Ciao
Hannes


On 11/23/2015 09: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
>>
>