UMA telecon 2016-01-28
...
- Roll call
- Approve minutes of UMA telecon 2016-01-07
- V1.0.1 specs are out: Recommendations and I-Ds (see home page)
- Thanks, Maciej/Thomas/Oliver!
- Other pages are generally updated too
- Review the new UMA Roadmap for 2016 page and prioritize our work
- AOB
Minutes
Roll call
...
Quorum was not reached.
V1.0.1 specs are out
Get the word out! We have a Kantara press release coming, and we think we have a blog post coming too, or maybe they'll be combined.
Thanks, Maciej/Thomas/Oliver! Thanks to Andi too!
Review the new UMA Roadmap for 2016 page and prioritize our work
Let's identity priorities A/B/C for the rows without column checks, and for the column use cases.
Vulnerability to claims-gathering session fixation attack and other security vulnerabilities
This is similar to OAuth 1.0's similar attack (which led to OAuth 1.0a). George notes that UMA is dependent on OAuth dynamic client registration. Eve challenges this assumption, and Justin challenges whether this (presumed) dependency is relevant to this vulnerability. Does the attack affect step-up authentication, or just claims-gathering? Justin confirms that any UMA flow that doesn't use claims-gathering (e.g. step-up authentication, or other non-claims-dependent trust elevation such as time-of-day-dependent access) would not be vulnerable.
There have been three mitigations proposed so far. "Door 1" involves the client getting a bit "smarter" and having to hand back a variable string. "Door 2" involves a backwards-incompatible change to permission tickets. "Door 3" involves more wholesale changes along the lines of other refactoring proposed for UMA V.next. (And maybe there are more "doors" we can think of.)
Today's UMA deployments appear to be safe from this vulnerabilities. There are anticipated deployments in the next couple of quarters that may possibly be vulnerable. Does it make sense to "tell the world to hold off on UMA" till we make wholesale changes? Eve isn't crazy about this because of near-term deployments, and history shows sometimes wholesale V.next efforts take a long time and occasionally forever.
Justin points out that semver means that any backwards-incompatible change would, of course, mean that we'd be upgrading to V2.0. In software, this is no big deal, but in protocols it typically means something different. We'd have to message around this, because the world is used to thinking of a V2.0 protocol as a big deal. While software stacks typically handle multiple versions as a matter of course, presenting sets of endpoints as required in order to handle clients that (say) haven't upgraded yet, protocols progress linearly – and major versions are usually big deals. Eve also notes that the WG itself has little ability to put design work on parallel tracks.
Jin speaks in favor of not delaying UMA till a big wholesale V.next effort, but also working quickly on vulnerability mitigation efforts.
Mike notes that the "extension spec" approach we used for permission registration could work for one of the mitigation approaches. Justin reminds us that we'd have to build in a way for the client to signal that it's a conforming client. Maybe this could be done through a client registration software statement.
AI: All: For next week, weigh in on preferred priorities of the use cases in the matrix.
Logistics for mitigation work
Could we consider extending our meetings to 90 minutes for those who want to dive more deeply into the mitigation work? Traditionally we do this by starting the meetings 30 minutes earlier, but perhaps making them go 30 minutes later suits people better at this point.
AI: Eve: Send a poll of some kind around to the likely principals for these discussions.
Attendees
As of 20 Jan 2016, quorum is 7 of 12. (Evariste, François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Søren, Mike)
- Eve
- Kathleen (new! - sent intro to the list)
- Domenico
- tbsMike
- Maciej
Non-voting participants:
...
- Justin
- Ann
- Jin
- Scott
- George
Regrets:
- Josh
- Sarah
- Sal
- Thomas