Attending: Eve, Justin, John W, George, Mike, Adrian, Sarah See below. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Tue, Feb 2, 2016 at 10:42 AM, Eve Maler <eve@xmlgrrl.com> wrote:
Attending: Eve, Andi, Sarah, Domenico, Justin, Mike, James, John W, Maciej, George (partial)?
Thanks to the intrepid attendees of this ad hoc meeting series!
*The progressive agenda for this meeting series:*
1. Analyze the nature of the vulnerability and the use cases at risk at the various time horizons (now/near-future/far-future) to be sure we understand its parameters 2. Analyze the proposed mitigations and see if there are any others we have missed 3. Assemble pros and cons for the mitigations and the forms in which they can be "packaged" to bring forward to the whole WG
Adding:
4. How to communicate around this attack?
*NOTE:* We have renamed the issue to call it "Session Fixation Attack on UMA *Claims-Gathering* Protocol (UMA 1.0.1 Section 3.6.3)". This is because in the spec <https://docs.kantarainitiative.org/uma/rec-uma-core.html>, trust elevation encompasses all of the ways to test the RqP (and even the client) for suitability, including any extension mechanisms, not just claims-gathering.
*Logistics:* We will hold a *short ad hoc meeting in the 30 minutes prior to Thursday's WG telecon*. We nearly got through agenda item 1b; the agenda will be to finish 1b, start 2a, and set up next week's ad hoc meeting schedule. We may be able to complete all the agenda items by next week at this pace.
*AI:* Eve: Set up the next ad hoc meeting in the calendar.
*1a. Analyze the nature of the vulnerability*
The preconditions are laid out in the issue <https://github.com/KantaraInitiative/wg-uma/issues/239> in GitHub. Let's see if we can identify other "truths" in the scenario:
- The nature of the grant flow that was used to mint the AAT is irrelevant to this attack. - We're assuming that the attack is possible even if only one of the two RqPs is compromised and nothing else (AS, client, etc.).
This doesn't have to do with step-up authentication; there may be vulnerability dragons there, but they're not the same as this vulnerability. We talked about asking the guys who just formally analyzed OAuth 2.0 to analyze UMA too.
*AI:* Eve: Reach out to the security researchers <http://arxiv.org/pdf/1601.01229v2.pdf> who analyzed OAuth.
Recall that we are showing in our WSD <https://www.websequencediagrams.com/?lz=cGFydGljaXBhbnQgUmVzb3VyY2Ugb3duZXIgYXMgcm8KABMOcXVlc3RpbmcgcGFydHkAHgVxcAAXDWxlZ2l0IGNsaWVudCBhcyBjADUNYXV0aG9yaXphaXRvbiBzZXJ2AGMGYXMAGQ50dGFja2VyAD0LYQA6DwAaCGFzIGEKCgphYy0-YXM6IHIAgR0GIHRva2VuIHdpdGggdGlja2V0CmFzLT5hYzogcmV0dXIAFAduZWVkX2luZm8AOgY6IHJlZGlyZWN0IHRvIEFTIGZvciBjbGFpbXMgZ2F0aGVyaW5nCmEtPnJxcDogc2VuZCBwaGlzaGluZyBsaW5rIChjaGFuZ2Ugc3RhdGUgaWYAXAVlZCkKcnFwAIEaBmxvYWQAQhEgZW5kcG9pbgCBHwYAWAUAfQwAgkYHAIFIBQCBCAZfc3VibWl0dGVkAFQGYwBMDV8AgT0JAB0WYwAsBWZhaWx1cmUgKG1pc21hdGNoAIEwBikKYQCCIgYARQxSADMeAIJMMQCDEwtScVAncwCCXgcKCg&s=napkin> two clients because the attacker uses either the same client or a different client with the same client ID, but with the same session that is able to compromise the existing permission ticket. The (persistent) permission ticket is usable by both pieces of software (or the "same" piece of software used by both victim and attacker).
The attacker is able to phish the true RqP and substitute the true RqP in front of them as soon as interaction with an RqP is needed for any claims-gathering, and then substitute themselves back with the original permission ticket when it's time to "turn in the winning ticket to get the winnings" (get the RPT and then go on to access the resource). You're getting the legitimate winner Bob to present their ID as is proper to get their winnings, but at the last minute, Eve the Eavesdropper <https://en.wikipedia.org/wiki/Alice_and_Bob> swoops in and knocks the winning chit out of his hands and runs up to the counter.
Here is a consolidated web sequence diagram (which will update whenever I make changes to it!) that reflects, I think, a current understanding of the attack. I've added a few comments, and some questions that we can ponder regarding additional potential mitigations. Many thanks to Justin for kicking off this flow.
http://www.websequencediagrams.com/files/render?link=tQ9pVR17H-5H93gM2wzU
We walked through the new swimlane. *AI:* Eve: Change "requesting party (RqP)" in WSD to mention "victim" and edit notes. Is Eve's question above "Load claims gathering endpoint at AS" pertinent? The "pushed claims" scenario, vs. using the claims-gathering endpoint, is what she is seeing around narrow ecosystems. Justin has deployed "tight ecosystems" inside enterprises that do leverage OAuth redirect flows, so he's certain that behavior-signaling is a totally insufficient mitigation because of the high likelihood that the interaction can still be silent (as noted in the writeup of the attack: "the victim’s claims might be passed to the server automatically through SSO"). As long as the phishing email is convincing enough, the victim will go along with it. It's possible that better guidance on this can help at the margin. But by this point in the attack, the AS hasn't even seen the client at all. What about the question about loading claims_redirect? The attacker just polls whenever, and when they achieve success, then they're off to the races. This is the exact same mechanism as in the old OAuth 1.0 session fixation attack. Alice's PAT was used to generate the permission ticket, and until Bob submits his "Bobly claims" (a Justinism :-), we're not sure who is who on the requesting side at all.
*1b. Analyze the use cases at risk at the various time horizons*
Eve's point in suggesting this topic is that it helps us figure out when and how to *potentially* apply tactical (less invasive/disruptive?) and strategic (more invasive/disruptive?) mitigations. One possibility:
NOW........SOON........LATER (tactical?)...........(strategic?)
This is necessarily a more subjective conversation because vulnerability is technical and risk is business-legal.
Mike's deployment doesn't use interactive claims-gathering. It should be noted that he has deployed only #APIsec use cases. Which use cases are likeliest to use interactive claims-gathering? Justin has implemented for it. His use cases are cross-domain (#wideeco) and the human RqP is present and using a client app. He expects interactive claims-gathering. Eve and James are seeing imminent deployments where interactive claims-gathering isn't expected at first; this is because the human RqP experience is expected to be extra-smooth, and the client apps are either published by the operator of the AS or by close partners, and the first deployments are likely to use "hub-and-spoke" identity federations where the AS is also where the RqP's claims from. However, wider -- at least "medium" -- ecosystem deployments will eventually be on the scene.
...tbs: more to come...
To be more precise, the "medium" ecosystems they are seeing arising have Alice's AS as a claims client (at maximum) to Bob's claims providers (typically a single IdP, but it could eventually go beyond just that "identity-centric" role) with a trust relationship pre-established between them. Justin is seeing this "identity-centric" claims-gathering role initially too.
*2a. Analyze the proposed mitigations*
Door #1: Add an unpredictable code parameter to the post-claims-gathering response Door #2: Rotating permission tickets with each call to the Authorization Server Both of these proposed mitigations involve returning some value from the claims-gathering URL to the (attacker's) client that is unpredictable. The permission ticket is currently required to be static across all interactions that seek the same protected resource; Door #1 puts the randomness in a new parameter, and Door #2 puts the randomness in the permission ticket itself. The consequences differ. Door #3: Collapse the claims gathering endpoint and the authorization endpoint into one If we go through all of the work to do this (as Justin has suggested in various other more "wholesale" design-related issues), then the attack goes away. *2b. Identify additional potential mitigations*
Are there other "doors" (approaches), or other ways to apply these same techniques? - It appears that behavioral signaling is a bust. - We had explored various mitigations in our existing Security Considerations for RqP redirection and impersonation threats <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#redirect-threats>, but they don't work in this case because at the last minute, the attacker "steals Bob's candy". The "polling"/session fixation attack works because there's no binding of the authenticated client to the polling attempt, just a client ID. Would it be too complex to require that the client be authenticated at that point? (We switched over to holding the regular WG telecon at this point.)
*3. Assemble pros and cons for the mitigations and their "packages"* ...tbs... *(we should add this one too:)* *4. How to communicate about this attack and related information* ...tbs...
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl