Page Comparison

...

• NOTE: As of Sept 15, 2022, quorum is 3 of 5. (Peter, Sal, Alec, Eve, Steve)

• Voting:

  • Alec

• Non-voting participants:

• Regrets:

  • Eve

Quorum: No

Meeting Minutes

...

Drafting vulnerability report + publication

template format

Protecting Wide-UMA Ecosystems

Introduction

Creating loosely coupled ecosystems presents some direct challenges in establishing and maintaining trust between dynamic connected, and often previously unknown systems.

OAuth and UMA both allow dynamic client interactions and registration, especially when the network is large. In fact, this is one of the main goals of UMA, to allow a user managed ecosystem of Resource Servers and client applications, where the relationships and authorization for a client to access a resource is established by the user at run time. UMA starts from the perspective that the client, resource server and authorization server may not have any existing or established relationship, and that a authorization and access of an API is facilitated by a human (Resource owner) to human (requesting party) interaction, out of band from the technical interactions.

Although UMA is open for completely unknown parties to interact,a authorization and exchange data, it does not preclude a safe system from having controls and a trust model to ensure that network participants are trusted - willing and able to follow the norms and rules of the ecosystem.

A possible network vulnerability does occur when there is little to no trust process or requirements for dynamically connected participants. Having no requirements for unknown systems opens an ecosystem to malicious actors and unintended disclosure of information. These ‘system in the middle’ attacks can be mitigated both with technical controls and by raising appropriate information to the end-users of trusted systems.

Criteria for affected wide-ecosystems

• Authorization Servers will interact with any client application. They allow dynamic client registration with little to no client attestation required

• Clients will interact with any resource server or authorization service.

• Access tokens are full bearer tokens – anyone with the token can can access the resource

Scenarios (make this concrete, eg access to financial information)

A malicious actor, Evan, has a target resource and a target resource server they want access to. They know that a user, Alice, may have access to this resource.

Scenario: Fishing with a malicious resource location

1. Evan sets up a malicious resource server, and create a fake resource.

2. Evan, crafts a fishing message to Alice, which includes the fake resource uri

3. Alice uses her trusted client to access the fake resource uri

4. On that request, Evan’s malicious resource server makes a request to the target resource and receives a permission ticket and trusted authorization server uri

5. Evan’s malicious resource server returns the permission ticket to Alice’s client

6. Alice’s client uses the ticket to follow the UMA Grant flow with the trusted AS.

7. Alice completes authentication and claims gathering at the trusted AS

8. The AS provides Alice’s client with a access token for the targetted resource

9. Alice’s client attempts to use the access token at the malicious resource server

END: the malicious resource server uses the access token to retrieve the target resource

Mitigations

There are several places that controls can be added to the above scenario to prevent the inappropriate access.

In step 3, Alice’s client may consult a list of known and trusted resource servers before making the request

In step 7, the Authorization service could present Alice with information about the requested resource, in order for her to determine that the resource she is granting access to is a different location than the malicious resource

In step 6, the authorization server may require the client to register a public key that can be used for dynamic proof of possession by the RS at access time

In step 8, the AS may provide the client with information about the audience of the token, the URL of the trusted resource server where the token should be presented. the Client may then determine that the granted token is not valid or intended for the malicious resource server

In step 9, the client may provide a signed and dynamic proof of possession over the access token. This prevent the malicious RS from replaying the request to the target resource

Scenario: Fishing with a malicious authorization service

• description of the vulnerability (general)

...

• frame up “real” scenarios to show motivation → help us test mitigations

• how do implementors know if they’re impacted?

• what are their mitigation option?

Vulnerability Description

AOB

...