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

Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 23 November 2015 19:49 UTC

From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
To: "oauth@ietf.org" <oauth@ietf.org>
Message-ID: <56536DB2.2020609@gmx.net>
Date: Mon, 23 Nov 2015 20:49:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="X7pl2ECBEip2xRbUJh0hgf3uxgL8dCCvW"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/1o8wZTpxwKOztdDMPDQI6Krq1Kk>
Subject: [OAUTH-WG] Adding use case to draft-ietf-oauth-pop-architecture-05
Precedence: list

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

Attachment: signature.asc

[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

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

Attachment: signature.asc