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

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 23 Nov 2015 20:49:06 +0100

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

---

From: Phil Hunt <[email-masked]>
Date: Mon, 23 Nov 2015 11:59:09 -0800

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
[email-masked]

> On Nov 23, 2015, at 11:49 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Mon, 23 Nov 2015 15:11:43 -0500

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 <[email-masked]> wrote:
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 23 Nov 2015 12:57:28 -0800

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
[email-masked]

> On Nov 23, 2015, at 12:11 PM, Justin Richer <[email-masked]> wrote:
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 23 Nov 2015 18:25:00 -0500

I'm agreeing with you that because the confidential client authenticates 
while using the refresh token then the same set of issues addressed by 
PoP don't automatically apply as they do to access tokens.

  -- Justin

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Nov 2015 08:25:10 +0100

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