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

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