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

[Phil Hunt <[e-mail]>]

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
[e-mail]

> On Nov 23, 2015, at 12:11 PM, Justin Richer <[e-mail]> 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 <[e-mail]> 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
>> [e-mail]
>> 
>>> On Nov 23, 2015, at 11:49 AM, Hannes Tschofenig <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>