Subject: [OAUTH-WG] WGLC review of draft-ietf-oauth-security-topics-13

From: Pedram Hosseyni <[email-masked]>
Date: Thu, 21 Nov 2019 14:50:52 +0100

Dear all,

I have a few comments about the leakage of access tokens and the 
underlying assumptions:

Section 2, A5 should be clarified:

"a resource server can be compromised by an attacker": Is the assumption 
that the attacker cannot get access to the resources stored at the 
compromised RS (or only parts of it)? Otherwise, the attacker does not 
need to get an AT anymore. A more differentiated view on RS 
compromisation is already given in Section 4.8.2, but this is not 
reflected in A5.

Also, A5 states that "an access token may be sent to an 
attacker-controlled resource server due to a misconfiguration," which 
does not require the compromisation of an honest RS.

Perhaps one could be more generic here and just say that the AT leaks to 
the attacker. However, a misconfigured RS endpoint not only gets the 
request to this endpoint (containing an AT) but can also respond and 
provide the RO with wrong resources. At the same time, if, say, the RO 
thinks that she is connected to her cloud storage, the attacker would 
get access to all uploaded data.

Is this really what A5 should express, or is the primary focus on the 
leakage of the AT?

Also, for this or the next version of this document, the Cuckoo's Token 
attack (see Section IV-A of http://arxiv.org/abs/1901.11520/ ), should 
be addressed. We also discussed this issue extensively at the last OSW 
in Stuttgart.

Typo: Section 3.5: MTLS -> mTLS

Best regards
Pedram Hosseyni

-- 
Pedram Hosseyni, M.Sc.
Room V38 2.438
Institute of Information Security - SEC
Universität Stuttgart
Universitätsstraße 38
D-70569 Stuttgart
Germany
Phone: +49 711 685 88454
https://sec.uni-stuttgart.de

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 26 Nov 2019 07:51:16 -0800

Hi Pedram,

> be addressed. We also discussed this issue extensively at the last OSW 

I took a look at the paper, and I'm not sure I'm properly understanding the
"Cuckoo's Token" attack.  Looking at Figure 4 of the paper to have
something concrete to refer to, I assume that the client, as a white box,
is presumed to be honest.  Since the access token is bound to the client, I
assume that the attacker has to return the phished access token to the same
client that originally (honestly) got it, as otherwise the token will not
be usable at the RS.  The paper concludes that in step 6, the client gets
access to the honest resource owner's resources, and furthermore that the
attacker has access to those resources through the client.  It's that last
part that I'm not sure I understand -- if the client is honest, why would
it return resource information to the attacker?  The best I can come up
with is that there's some sense of a "session" between the user and client,
such that the client links its resource accesses with the "session" on
behalf of which the access occurs, and is willing to return such
information back to the user only on the "linked session".  (The
countermeasure makes sense and is a good practice, of course.)

Thanks,

Ben

---

From: Pedram Hosseyni <[email-masked]>
Date: Tue, 26 Nov 2019 18:33:04 +0100

Hi Ben,

The attacker uses the (honest) client shown in Figure 4 as a regular 
user. For example, the client might provide access to a cloud storage 
via its website, i.e., by using the clients' website, a user can access 
her files stored at the resource server.

I'll try to clarify the attack with a simplified example.

Let's assume that the client supports two authorization servers 
AS_honest and AS_attacker. Intuitively, if the attacker phishes an 
access token created by AS_honest for an honest user (Alice), one would 
expect that sender-constraining the access token (e.g., via mTLS) 
prevents the attacker from using this access token.

The overall goal of the attacker is to use the sender-constrained access 
token (which he cannot use directly at the resource server) to access 
Alices cloud storage.

The attack works as follows:

First, the attacker visits the website of the client. Usually, the 
attacker would now choose an AS, and after successful authentication, 
access his files stored in the cloud. When selecting the AS, the 
attacker chooses AS_attacker. In Step 5 of Figure 4, AS_attacker now 
provides the phished access token. As this token is bound to this 
client, the client can use it at the resource server for getting access 
to the cloud storage of Alice. As the attacker is using the client 
(through the clients' website), he now gets access to these files 
(stored at the RS).

Please let me know if you have any other questions.

Best regards,
Pedram

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 26 Nov 2019 10:31:09 -0800

Hi Pedram,

Thanks for confirming that the scenario is as I was trying to understand
it.  I don't think it's universal that all clients will give transitive
access from the user to the accessed resource, though it's certainly
common; the lack of exposition on that point is what I had been stumbling
on.

-Ben

---

From: "Peck, Michael A" <[email-masked]>
Date: Tue, 26 Nov 2019 20:08:07 +0000

Hi Pedram,

I understand why a client would need to allow use of multiple authorization servers if the client needs to access various resource servers each of which may trust different ASs (e.g. the client supports accessing resources at multiple cloud storage services).

However, how common is the case that a client would need to allow selecting from multiple authorization servers for accessing a particular resource server?

Would it be reasonable for the document to recommend that clients designate a specific AS for each RS that the client accesses (and not allow the user to select a different AS)? Would that help prevent the attack? Wouldn't most RSs only trust access tokens from a single AS anyways?

Thanks,
Mike

On 11/26/19, 1:32 PM, "OAuth on behalf of Benjamin Kaduk" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Pedram,

    -Ben
    
    > > countermeasure makes sense and is a good practice, of course.)
    
    _______________________________________________
    OAuth mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/oauth

---

From: Pedram Hosseyni <[email-masked]>
Date: Wed, 27 Nov 2019 15:04:58 +0100

Hi Mike,

 > Wouldn't most RSs only trust access tokens from a single AS anyways?

At the last OSW, there was broad agreement that this is typically the 
case. Otherwise, the mitigation that we suggested in the paper would not 
prevent the attack.

 > Would it be reasonable for the document to recommend that clients 
designate a specific AS for each RS that the client accesses (and not 
allow the user to select a different AS)? Would that help prevent the 
attack?

In principle, this should prevent the attack. However, this would 
require the client to identify the correct AS for each RS, which might 
not always be possible (e.g., in more dynamic settings) and more 
complicated than just delegating this decision to the RS.

Any opinions (also from other OAuth WG members) on this?

Best regards,
Pedram

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 28 Nov 2019 11:40:27 +0100

Hi,

> On 27. Nov 2019, at 15:04, Pedram Hosseyni <[email-masked]> wrote:
> 
> Hi Mike,
> 
> At the last OSW, there was broad agreement that this is typically the case. Otherwise, the mitigation that we suggested in the paper would not prevent the attack.
> 
> > Would it be reasonable for the document to recommend that clients designate a specific AS for each RS that the client accesses (and not allow the user to select a different AS)? Would that help prevent the attack?
> 
> In principle, this should prevent the attack. However, this would require the client to identify the correct AS for each RS, which might not always be possible (e.g., in more dynamic settings) and more complicated than just delegating this decision to the RS.
> 

I think one can observe all possible combinations of AS and RS in the wild. 

In the traditional OAuth setup, there is a 1:1 relationship between RS and AS. 

There are also deployments where a single RS works with multiple ASs, e.g. because those ASs represent different portions of the overall user base. In this case, the RS determines the base set of ASs and the user selects the AS to be used from that base set. 

As far as I understand, in UMA any AS can provide access tokens to any RS as long as the relationship had been set up by the user beforehand.   

best,
Torsten.