UMA telecon 2024-11-07
- Alec Laws
UMA telecon 2024-11-07
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
Review AS vulnerability
Plan for vulnerability report + publication
Attendees
NOTE: As of Sept 15, 2022, quorum is 3 of 5. (Peter, Sal, Alec, Eve, Steve)
Voting:
Alec
Non-voting participants:
Mark Wholey
Gabrial Corona
Hanfei
Regrets:
Quorum: No
Meeting Minutes
Topics
Review AS vulnerability
Is this available in OAuth also? Yes, if there is DCR from client → AS.
Condition:
DCR aka client doen’t have static/ahead-of-time knowledge of the AS
phishing, client talks to malicious RS
client has to accept arbitrary URIs
RS has to accept arbitrary AS URIs during RO AS selection
does client have to be malicious? No, client only has to accept arbitrary RS URI
doe the RS have to be malicious? it has to have been told to use malicious AS during resource registration
RqP only has knowledge/trust of Client & RS URI, not of the AS
Mitigations:
static registration at the client of RS & AS
showing user appropriate and complete information when granting consent, only applies to interactive claims
for pushed claims
can we separate protocol issues from operational security issues?
yes & no
user thinks authorizing Legit Client to access to RS 1 but is actually authorizing Malicious AS to access to RS2
What is driving this attack, what is an example scenario?
- e.g. what is the malicious client trying to access?
Action item, frame up an example use-case
access sensitive health info, taking Medicaid payment, claim and payment steal. get and display legitimate test
financial use, open banking. access info vs authorize payment
Plan for vulnerability report + publication
TODO:
look at similar attack patterns in OAuth2? malicious/phising client
scope of publication?
idea: full BCP. no it’s too broad and would take a long time
let’s focus on these specific vulnerabilities
two or one? they are very different, esp the mitigations
separate but follow similar template/format
template format
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?
Next call, confirm template for reports and start outlining section
AOB