UMA telecon 2017-12-14

Owned by Eve Maler
Last updated: Dec 14, 2017
4 min read


UMA telecon 2017-12-14

Date and Time

Agenda

  • Roll call
  • Approve minutes of UMA telecon 2017-11-30 
  • Discuss ballot results, comments, and next steps
    • See discussion in the latter part of the thread here
  • AOB

Minutes

Roll call

Quorum was reached.

Approve minutes

Approve minutes of UMA telecon 2017-11-30: Deferred.

Discuss ballot results, comments, and next steps

See discussion in the latter part of the thread here and additional notes Eve sent today with thoughts from Justin and herself here.

George/Eve/(implicit Robert from earlier in the day) discussion: The "UMA version" of a mix-up attack would have to start with the RS sending a wrong or malicious as_loc. Let's say a malicious RS wants to point all clients to a fake AS. The client now has discovered a false token endpoint (let's keep it simple; ignore interactive claims gathering for the moment) and POSTs to it. It comes back with a false RPT that allows the client to do everything. If the RO had already set up the RS with a good AS (authorizing PAT issuance), then the RS could get a permission ticket from AS(good) and send it and the as_uri for AS(bad) to the client – and potentially the later two protection API endpoint interactions too. But if there is a claims_redirect_uri-specific attack too, that's separate.

Taking the two presumed-separate attacks in turn:

In the OAuth security topics draft, the mix-up attack (presumed related to claims_redirect_uri) is summarized briefly as: "Mix-up is another kind of attack on more dynamic OAuth scenarios (or at least scenarios where a OAuth client interacts with multiple authorization servers). The goal of the attack is to obtain an authorization code or an access token by tricking the client into sending those credentials to the attacker (which acts as MITM between client and authorization server)". Nat's preferred mitigation, it appears, is the third one: "Clients use AS-specific redirect URIs, for every authorization request store intended AS and compare intention with actual redirect URI where the response was received (no change to OAuth required)". Who is the bad actor? Not the RS; only the AS.

Establishing some facts on the ground: In a single UMA authorization process, a client could cycle around approaching the token endpoint on the back channel and redirecting the requesting party to the claims interaction endpoint on the front channel. In order to use the claims interaction endpoint first, the AS has to declare it in the discovery document statically. The AS always has to declare the token endpoint statically. The AS has the option to dynamically provide the claims interaction endpoint as part of the redirect_user hint inside the need_info error after the client's request for a token at the token endpoint fails. The "third mitigation" described in the OAuth security topics draft is for the client to supply a redirection URI that's specific to the AS it came from, so the client can detect proxying/spoofing/tricks.

Does this mitigation help from an UMA perspective? The interaction between Bob the requesting party and the AS is sort of "private" for the purpose of collecting claims. However, the AS does send back a rotated permission ticket. Then again, if the client next brings that ticket to the token endpoint to try and get its RPT, which is the only legitimate next step, can we assume it had a good token endpoint, and AS(good) will reject AS(bad)'s faux permission ticket? Nope, because there was never AS(good). But if there was only ever AS(bad), it could do so much insidious damage everywhere that every communications channel is suspect – with the RS, with the client, with the RO, with the RqP... There are discovery document attacks (all endpoints are funky), RO-trust PAT issuance attacks, policy modification attacks (RO never gets what they want and all protected resources are compromised/stolen), RqP phishing attacks, RO phishing attacks... If there's a malicious AS (without a malicious RS) in the world, we're eventually talking scandals, headlines, etc. Andi notes that such scenarios, similar to contemplating collusion of the major SAML entities, are just disastrous and seem to be beyond reasonable mitigation. We seem to be aligned in thinking that this circumstance is Armageddon, and goes against the entire point of what's discussed in UMA generally (and sections like FedAuthz Sec 1.4 specifically), that there's little we could do about it.

Now returning to the potentially novel attack where a colluding RS(bad) and AS(bad) could pull one over on a naive AS(good): First, note that even in UMA1 (See UMA1.0.1 Core Sec 1.4), we didn't force endpoint declarations to be at the same host as the issuer/config doc, and there are real-life deployments where you might want the various endpoints not to share a host. So there's no point telling the client to check on this. This is about the entire protection API, not just claims interaction. This could hinge on the PAT as a mitigation, potentially.

Still thinking about interactive claims gathering, if the client gets confused and sends the permission ticket that it gets to the wrong AS, George is thinking that this should fail. But our conclusion up above was that it wouldn't fail because the permission ticket (endpoint 1) came from the RS-proxied AS(bad), and the client originally got the as_uri from RS(bad) and thus the discovery document was tainted and had a token endpoint declaration pointing to AS(bad) or a MITM to AS(good).

The other two suggested mitigations in the OAuth world are that OAuth and/or OIDC add in an issuer and client ID value dynamically. All the mitigations rely on clients being the "smart one in the room" and paying attention, which is probably not the smartest way to bet! Unfortunate.

We intend to continue working towards consensus on this thread. Let's plan to meet on December 21st on this topic.

Attendees

As of 7 Mar 2017, quorum is 4 of 7. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem)

  1. Domenico
  2. Sal
  3. Andi
  4. Eve

Non-voting participants:

  • George
  • Bjorn
  • Colin