Re: [OAUTH-WG] Adding use case to draft-ietf-oauth-pop-architecture-05
Phil Hunt <phil.hunt@oracle.com> Mon, 23 November 2015 20:57 UTC
Return-Path: <phil.hunt@oracle.com>
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 7DCA41B3ABE for <oauth@ietfa.amsl.com>; Mon, 23 Nov 2015 12:57:36 -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 0p2tca5YJrP3 for <oauth@ietfa.amsl.com>; Mon, 23 Nov 2015 12:57:34 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6F1D1B3ABC for <oauth@ietf.org>; Mon, 23 Nov 2015 12:57:34 -0800 (PST)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tANKvWlb008194 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Nov 2015 20:57:32 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tANKvWq2013274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Nov 2015 20:57:32 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tANKvVuY032716; Mon, 23 Nov 2015 20:57:32 GMT
Received: from [192.168.1.200] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Nov 2015 12:57:31 -0800
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <E3E3DB02-F318-4A00-BF9B-3BE0A93749F3@mit.edu>
Date: Mon, 23 Nov 2015 12:57:28 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <ACABA87C-920C-4210-B6D6-55569EAC05DE@oracle.com>
References: <56536DB2.2020609@gmx.net> <BA46B718-85FD-4EB1-8406-95CEFC435569@oracle.com> <E3E3DB02-F318-4A00-BF9B-3BE0A93749F3@mit.edu>
To: Justin Richer <jricher@mit.edu>
X-Mailer: Apple Mail (2.3096.5)
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/bJdJWm6boxDBIzVj18jByex6GTc>
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 20:57:36 -0000
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 >
- [OAUTH-WG] Adding use case to draft-ietf-oauth-po… Hannes Tschofenig
- Re: [OAUTH-WG] Adding use case to draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] Adding use case to draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] Adding use case to draft-ietf-oaut… Phil Hunt
- Re: [OAUTH-WG] Adding use case to draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] Adding use case to draft-ietf-oaut… Hannes Tschofenig