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 *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 *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... *2a. Analyze the proposed mitigations* ...tbs... *2b. Identify additional potential mitigations* ...tbs... *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