UMA telecon 2016-03-17

Owned by Eve Maler
Last updated: Mar 17, 2016
5 min read

UMA telecon 2016-03-17

Date and Time

Agenda

  • Roll call
  • Approve minutes of UMA telecon 2016-03-10
  • Issue 239 materials: report out and final conclusions if all goes well
  • "Why UMA?" AI report and discussion
  • Wide ecosystem: time to push this forward?
  • Charter-bashing (if anyone has done any homework...)
  • AOB

Minutes

(Unofficial ad hoc meeting notes prior to call)

Attending: Eve, Sarah, Justin, Adrian, Maciej, Domenico, Andi, George, Sal

Justin suggests shortening the abstract and introduction by removing the first sentence.

Justin suggests adding 'NOT RECOMMENDED' to the RFC2119 boilerplate that we use. In fact, we should add an editorial issue about this so that we update the other docs eventually, too!

We discussed future-proofing this extension so that it applies, as well, to (e.g.) any UMA V1.0.x or UMA V1.x that might be susceptible to the same attack. We still need normative references to V1.0 and V1.0.1 because of the section references into specific sections of the text, and because the attack is known to appear in those versions, but we want to broaden the normative language in the spec to refer to "...and any other similar versions of the UMA specification to which this attack applies, and in Sec 1.2, say something like "An UMA authorization server that would have implemented a requesting party claims endpoint susceptible to this attack..."

To make the extension spec more helpful, we want to have subsections inside the main Sec 2: Introduction, explaining who should be using this enhancement and why; Attack Sequence, a shortened version of what's in the non-normative doc; and Mitigation, the normative part of the spec.

Maciej noted that "use this endpoint exclusively for interacting with the end-user requesting party to gather claims". Justin thought that breaking out each bullet as a full sentence with a single instruction: "The AS MUST do this..." "The AS MUST do that..." etc. would be good. Specifically, we're thinking that talking about something like "replacing any use of the original claims endpoint with the enhanced claims endpoint would help, vs. "exclusively" language.

Let's also change this: "Effectively, when this extension is in effect, the requirement stated in Section 3.2.2 of UMA1.0.1 as "Permission tickets MUST NOT be single-use" is nullfied" to this: "Effectively, this extension supersedes the requirements stated in Section 3.2.2 of [UMA101] as "Permission tickets MUST NOT be single-use" and Section 3.6.3 as "The same permission ticket value that the client provided in the request.""

Discussion of the new mitigation idea: Eve's idea is that by combining trust elevation mechanisms (through policy conditions that require their combination – recalling that policy is OOB wrt UMA) in significant order, thereby "binding" Bob across those mechanisms/endpoints, trust in the legitimate RqP can be correctly elevated and the attacker can be tossed.

Roll call

Quorum was reached. (Huge showing today!)

Approve minutes

Approve minutes of UMA telecon 2016-03-10: NO OBJECTIONS!!!

Issue 239 materials

Report out and final conclusions if all goes well: We walked through the ad hoc discussion above.

We discussed whether we should name the "parallel endpoint" some sort of "forever and all" name that will last through the next big UMA version overhaul, whenever that might be. Currently we've suggested security_enhanced_claims_endpoint. Let's indeed put this out on the list to think about it, with conclusions by next week. John likes secure_random_value_claims_endpoint. Let's continue discussing.

We forgot to record that we want to delete "This extension does not change any original requirements of UMA if used without these enhancements."

Justin recommends adding "unguessable" to "securely random"; agreed. In that case, we should consider doing this in the original spec too, as an editorial change vs. "The permission ticket is a short-lived correlation handle generated by the authorization server that is intended to be opaque to resource servers and clients. The authorization server therefore MUST ensure that the ticket is securely random, much as it would for authorization codes and access tokens. Within these constraints, however, the authorization server MAY format the ticket however it chooses, for example either as a random string that references data held on the server or by including data within the ticket itself."; let's add this as an issue.

Finally: typo: s/ot permissions/of permissions/

Justin points out that order wouldn't be significant because if Bob is strongly bound initially, then Eve has no chance already. But it's not a particularly interesting mitigation from his perspective unless it's the combination of, say, "I'm 'Bob' to some strength (authentication_context) plus 'I'm a doctor' (specific claim requirements) and 'this client has no knowledge of/ability to/trustworthiness to provide my doctor claim (redirect_user is required)". E.g.: Bob gets his authentication through a hospital, but Alice has a carveout against his access to her information. Her policy is: If is_doctor and is_not 'Bob', then the logic would want to grab the current identity in a convenient way. John notes: "We call Alice’s carveout a “Lockbox” in Ontario. She can lock access to her records to some or all people or groups (barring ‘break the glass’)."

Eve discovered that there are two implementations so far, Gluu and FR, that do use the AAT ("session") for meeting policy conditions, so that's at least a data point for discussing this mitigation. This particular combination hasn't been deployed, however.

So what should be done about this mitigation? It falls into a gray area. It's not something that belongs in a normative spec. It's not for us to "accept" or "reject". We need to qualify who is susceptible to the attack by adding the word "solely", and ensuring that readers of the spec understand that even if they mitigate the attack in any other way, it's "tricksy". We will simply refer them to the background document for "background information on this attack, the provided mitigation, and other discussion.", and then provide discussion of this additional mitigation idea for those who wish to pursue it. We're not going to spend lots of energy writing a full description of the "combined trust elevation mitigation" in that background doc.

We should also add something to the UIG pointing to the new spec and doc, so people won't miss them.

AI: Eve and Maciej: Revise the extension spec for final consideration next week.

AI: Eve: Revise the background doc for next week.

AI: (somebody, can it please not be Eve? (smile) ): Add a mention of the attack and mitigation to the UIG.

"Why UMA?" AI report and discussion

Domenico ran through his analysis of business audiences and ways to make the case. Eve described new discussions in the UMA Dev group around appealing to the developer audience, and invited UMA WGers to contribute. New concrete case studies are extremely welcome, along with statements from individuals and organizations involved in them in their own words; these are the most powerful.

Attendees

As of 18 Feb 2016, quorum is 6 of 11. (François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Mike, Sarah)

  1. Domenico
  2. Kathleen
  3. Sal
  4. Thomas
  5. Andi
  6. Robert
  7. Maciej
  8. Eve
  9. Mike
  10. Sarah

Non-voting participants:

  • Justin
  • Adrian
  • George
  • Ishan
  • Scott
  • John