UMA telecon 2024-11-21

Date and Time

• Every other Thursday @ 1:00ET/10:00am PT

  • Screenshare and dial-in: https://zoom.us/j/99487814311?pwd=dTAvZi9uN0ZmeXJReWRrc1Zycm5KZz09

  • United States: +1 346 248 7799, Access Code: 994 8781 4311

  • See UMA calendar for additional details: https://kantara.atlassian.net/wiki/spaces/uma/pages/4857518/Calendar

Agenda

• Plan for vulnerability report + publication

•  

•  

Attendees

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

• Voting:

  • Alec

  • Eve

• Non-voting participants:

  • Gabriel

• Regrets:

  •  

Quorum: No

Meeting Minutes

Topics

Scenario 1, health, there is a UMA-based health data-sharing ecosystem

1. A provider(RqP) receives a (malicious/phising) email link to access a patients record (e.g. patient summary resource)

2. The provider opens the link in their EMR client

3. The link points to a malicious RS, which provides a ticket it has from an interaction with the target RS to access all available patients

4. The EMR client follows the WWW-authenticate header to a target AS, it performs dynamic client registration

5. The EMR client follows the WWW-authenticate header to the target AS, the Provider(RqP) is able to authenticate and grant access to the target resource

6. The EMR client negotiates a token and presents it to the malicious RS

7. The malicious RS can access the target RS with the token

Conditions:

• the client trusts ANY RS

• the AS allowed any client to register

• the issued token was a Bearer token →

Scenario 1, health w/ malicious AS, there is a UMA-based health data-sharing ecosystem

1. A provider(RqP) receives a (malicious/phising) email link to access a patients record (e.g. patient summary resource)

2. The provider opens the link in their EMR client

3. The link points to a malicious RS, which provides a ticket it has from an interaction with the target RS to access all available patients

4. The EMR client follows the WWW-authenticate header to a malicious AS, it performs dynamic client registration

5. The EMR client follows the WWW-authenticate header to a malicious AS, which forwards the user to the target AS. The Provider(RqP) is able to authenticate and grant access to the target resource

6. The EMR client negotiates a token and presents it to the malicious RS

7. The malicious RS can access the target RS with the token

Conditions:

• the client trusts ANY RS

• the issued token was a Bearer token →

Scenario 2, financial,

Mitigations:

• informational

  • the client is informed of the RS aud when it receives the token

  • the provider is informed of the scope of access when authenticating (requires claims gathering)

• technical: the client must authenticate to the RS at Resource access time

Plan for vulnerability report + publication

Two reports

1. RS, possible if Client & AS are known and trusted

2. AS, possible only if Client/AS can be unknown to each other

template format

• TLDR: you’re impacted if

• 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?

• Impacts of comprimised but otherwise legitiate actor

•  

AOB