January 2018 - WG-UMA - mailman.kantarainitiative.org

Recommendations published! / New UIG security considerations section
by Eve Maler 09 Jan '18

09 Jan '18

Hey folks-- Please check out the following links -- and thanks for all your hard work!! https://twitter.com/UMAWG/status/950803880727609344 https://kantarainitiative.org/reports-recommendations/ ==== I added a draft section to the UIG to describe the security considerations we've been discussing. This is based on our conclusions of telecon 2018-01-04. Please let me know what you think. We can always revise as needed. https://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Gu…'sGuide-front-channel-securitySecurityConsiderationsRegardingInteractiveClaimsGatheringFlows *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Contributions Program launches annual call for innovative research and knowledge translation proposals - Office of the Privacy Commissioner of Canada
by John Wunderlich 08 Jan '18

08 Jan '18

You’ll know if this applies to you: I think that this has already been circulated, but just in case. There are 10 days left to apply to the contributions program for the privacy commissioner of Canada. Applicants are academics and not-for-profits and trade associations, so if you want funding for research or a translational program and you have a qualifying footprint in Canada, you may want to get busy: https://www.priv.gc.ca/en/opc-news/news-and-announcements/2017/an_171115_cp/ John Wunderlich, BA, MBA @PrivacyCDN <https://twitter.com/PrivacyCDN> Privacy Tools: Kantara Initiative <https://kantarainitiative.org/>: Consent Receipt Specification <https://kantarainitiative.org/confluence/display/infosharing/Consent+Receip…> JLINC Labs <https://www.jlinclabs.com/>: Data Provenance Solutions <https://www.jlinclabs.com/solutions/> PGP Signature: EA86 067A 73F9 ED6D E679 F040 E0BB EB36 A711 D416 -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

1 0

Updated UMA PbD paper
by Eve Maler 07 Jan '18

07 Jan '18

I wanted to brush up the PbD paper in preparation for our publication of the UMA2 Recommendations. It at least enables the updating of the year of publication in the specs. :) It also helps us in our Legal effort... https://kantarainitiative.org/confluence/display/uma/Privacy+by+Design+Impl… (also available at http://tinyurl.com/umapbd ) Please let me know if you have any comments. (Other than adding the last section, I didn't really change it dramatically.) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

First Legal call of the new year - new dial-in - Business Model doc progress!
by Eve Maler 04 Jan '18

04 Jan '18

Hi folks-- We are meeting tomorrow at 8am PT, using the new GoToMeeting line (subscribe to the calendar <https://kantarainitiative.org/confluence/display/uma/Calendar> -- and ask me if you want to receive an invite -- if you want to see things in your native time zone, and see the calendar entry for additional dial-in details): https://global.gotomeeting.com/join/857787301 Agenda: - Get the Business Model paper ready for its closeup (International Privacy Summit <https://privacysummit.kantarainitiative.org/> presentations on Jan 29) - Discuss satellite papers *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Draft minutes of UMA telecon 2018-01-04
by Eve Maler 04 Jan '18

04 Jan '18

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-01-04 MinutesRoll call Quorum was reached. Identiverse - Interest in an UMA2 workshop - The Identiverse CfP <https://www.cvent.com/c/abstracts/48548758-ef7e-4e8c-b1e1-8b970733bc9b> is still open until *Jan 12*! Identiverse is June in Boston. Who's interested in participating in an UMA2 workshop? Justin (discussed how MPD is a small delta off final UMA2), tentatively Eve (showing demos is good), Mike (could show Gluu gateway, to be released). *AI:* Eve: Chat with Thomas about MITREid Connect. Approve minutes Approve minutes of UMA telecon 2017-12-21 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-12-21>: Andi moves to approve: APPROVED. Discuss latest on security attack/trust attack analysis - Possible to confirm and close specs for Recommendations publication? Eve asked Justin in email, and asserted: *"Is the claims_redirect_uri parameter still a vector for the attack in the case where the client sends this value when redirecting the RqP? It's sending the RqP to a known-good AS claims interaction endpoint no matter what (or a known-bad AS entirely, but that's sort of a different "trust attack" that started with the discovery document, as we've been saying -- you can't fix this with OAuth-style mitigations). If I'm stating this accurately, there's simply nothing to fix and no mitigations to mention regarding claims_redirect_uri. The group is of the opinion that we've said enough in the specs about mitigating "trust attack" thingies. (We could say/muse more in a separate doc eventually.)"* "OAuth-style mitigations" means the mix-up attack mitigations <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-04#section-4.4>. The problem with the assertion is that the attacker can sit on the front channel. If we had mandated the state parameter (as Justin had preferred!), then it might have provided a mitigation (or nearly full mitigation?) – George thinks that if the state carried the right content, it might work. A nonce wouldn't be enough. Justin notes that Microsoft's OAuth implementation puts a lot of content into the state value (so that it becomes stateless – rimshot). Carrying a lot of application state enables matching it up with a callback. Justin suggests a non-normative security consideration suggesting that the claims_redirect_uri parameter being susceptible to the same mitigations as the redirect_uri parameter, as in this doc/section <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-04#section-4.4>. Would adding this to the spec require any new review processes? Andrew's take is that it wouldn't have to, as long as it has no impact on conformity assessment and interop testing (in other words, if it's not connected to testable assertions in the specs). If we don't state it as "MUST", then it's not a MUST – tautologically! Nat's comment was based on wanting it to be a MUST. OAuth's security topics draft doesn't have it as a MUST, but that is an add-on document. All three of the OAuth-style mitigations are not great. The first two bullets have syntactic implications (the implication is that they would apply to the AS's response in Grant Sec 3.3.3) and yet any attacker sitting in the middle of the front channel could do worse damage to the information included. The third bullet asks the client to take not only the actions specified but a number of other coordinating and tracking actions. Andi suggests that, since the security topics document is an IETF WG document that is not at last call, it's not a good idea for us to base serious changes on it. Justin likes it. George too. A man in the browser can manipulate and compromise pretty much everything, so AS-specific redirects doesn't sound like it solves much of anything. And UMA is already much less susceptible to discovery attacks because the OAuth situation is based on a user to enter data. In our case, the RS tells the client where to go next. Assume no mal-intent, the next steps are clean. Justin even recommends we could say that *not* putting the claims interaction endpoint in the discovery document is more secure because then the client discovers it directly from the token endpoint. We could put a line in the UIG about all this instead of the spec. Justin notes that 6749 doesn't even mention 6819. We don't have to mention the security topics doc in the spec at this time. Consensus: We all agree that this is simply *best practice* at the current time and thus needs to go in the UIG and not the spec. Updated mix-up attack analysis swimlane (non-normative) <https://www.websequencediagrams.com/files/render?link=gW2y6DH8IG0-y1Wukq-4> based on the group conversation – comments welcome. Schedule Consent Receipt analysis - With Andrew, Andi, Robert, Tim... *AI:* Eve: Do Consent Receipt analysis scheduling offline. 2018 charter and roadmap - Joint consent receipt work? - Working on issues with the "extension" label? - Legal? - What else? Deferred. UMA2 logo Eve briefly showed the current logo options being considered, and also the JSON logo, which Justin had observed looks somewhat similar due to the ring shading. She's working with Colin, will reach out to Maciej, and is gathering opinions and whether they have changed since the first couple of conversations, but is not doing a strict group vote. 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 5. Mike Non-voting participants: - Justin - George - Bjorn *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2018-01-04
by Eve Maler 02 Jan '18

02 Jan '18

Happy new year! Note the GoToMeeting connection info... https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2018-01-04 Date and Time - *Thursdays 9am PT* - Screenshare and dial-in: https://global.gotomeeting.com/join/857787301 - See UMA calendar for additional details: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Identiverse - Interest in an UMA2 workshop - The Identiverse CfP <https://www.cvent.com/c/abstracts/48548758-ef7e-4e8c-b1e1-8b970733bc9b> is still open until *Jan 12*! - Approve minutes of UMA telecon 2017-12-21 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-12-21> - Discuss latest on security attack/trust attack analysis - Possible to confirm and close specs for Recommendations publication? - Schedule Consent Receipt analysis - With Andrew, Andi, Robert, Tim... - 2018 charter and roadmap - Joint consent receipt work? - Working on issues with the "extension" label? - Legal? - What else? - UMA2 logo - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Trying to analyze "trust attacks"
by Eve Maler 02 Jan '18

02 Jan '18

In last week's WG call <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-12-14>, we discussed the potential for a "mix-up attack" on UMA; please check out my new analysis swimlane <https://www.websequencediagrams.com/files/render?link=gW2y6DH8IG0-y1Wukq-4>, where the conclusion so far is that this is not a viable attack. We also started discussing a different sort of attack where a bad RS might be colluding with a bad AS-type service behind the back of the real AS. After doing a bunch of thinking and analysis of this situation and another similar one, I'm starting to think of them -- not so much as security attacks -- but as "trust attacks". Let me describe them in turn, newest one first. *OAuth/UMA short-circuit attack* - What needs protection? RO's AS-protected resources at RS - Entities to protect them from? Colluding RS and client (and possibly RqP using the client), against a naive AS and RO - Likelihood of attack? Higher for bespoke implementations, lower for off-the-rack/third-party - implementations; for OAuth, requires an RS "insider attack" against a naive AS, while for UMA (or other "distributed OAuth") it's potentially likelier in the case of an RS in a distinct domain from an AS (FedAuthz loose coupling) - Worth the effort to mitigate? Technical means through OAuth/UMA don't seem possible, so all methods are relatively "soft" - Seriousness of consequences if you fail? Very high since the RS can give specific recipients access to specific resources Here, the RS has received an access token during a client's resource request that has scopes (or in the case of UMA, permissions) directing it to give access only to extent X, but -- based on its out-of-band recognition of the client (and/or the requesting party in the case of UMA) -- it decides to go ahead and give further access illegitimately to extent Y. Mitigation would be in the realm of access auditing, implementation auditing, deployment auditing, trust establishment with the AS and AS/RO, and RS accreditation. Note that adding an endpoint at the AS to enable the RS to report access given would be a self-reporting function. Most known UMA ecosystem types to date are relatively "classic" on the server side and involve statically established "identity federation" style trust between the AS and RS (if the two aren't already colocated); this means the RS has to get OAuth client credentials from the AS and probably agree to an associated contract. The RS then gets a PAT from the AS by authorization of the RO. (I haven't seen this one discussed before, e.g. in existing threat docs. Has anyone else?) This attack could be really effective, if Armageddon-y, and if the RS applied it in a very selective way, it's likely it could get away with it for a longer time. A perhaps analogous example <https://news.vice.com/en_ca/article/j5vmxp/loblaw-says-sorry-for-fixing-bre…> of what may have been "lower-level employees" (insiders) of multiple related companies getting away with price-fixing on a single product type for 14 years just came to light due to auditing. I don't see anything worth adding to the specs that we haven't already said in our profiling and trust establishment sections. We could add this analysis to a new threat model document if we think it even counts as a true security threat. *Evil federated authorization attack* - What needs protection? RO’s AS-protected resources at RS? RqP's claims containing personal data? - Entities to protect it from? RS(bad) and AS(bad) colluding, against all the other entities, which are uninvolved? - Likelihood of attack? See discussion - Worth the effort to mitigate? See discussion - Seriousness of consequences if you fail? See discussion Here, the evil RS has a properly formed trust relationship with the true AS, but it has a companion server-side attacker with which it colludes to achieve...I'm not sure what ends yet. I can see two mechanisms of attack, as outlined below. I haven't yet made swimlanes for this, but perhaps I can do so before the call tomorrow. *Mechanism 1: Bad actors replace the discovery endpoints wholesale* - The bad actors construct and host a replacement discovery document with false endpoints. - RS(bad) provides a false as_uri value when clients make tokenless resource requests. - Thereafter, RS(bad) and AS(bad) are the only server-side entities interacting with Client(uninvolved) and RqP(uninvolved) throughout every authorization process. - If RqP(uninvolved) Bob is redirected to AS(bad) for interactive claims gathering, can he tell that it's not AS(good)? Generally it’s not considered reliable for humans to detect this, so let's assume not. AS(bad) could steal Bob's personal data. *Discussion:* The uninvolved requesting-side entities will presumably get any access they request, and RO(good) and AS(good) are none the wiser. Also, AS(bad) got RqP(uninvolved)'s claims. But RS(bad) has presumably violated its terms of service, which may eventually be discovered through auditing etc., and this seems like an awful lot of trouble to go to vs. the OAuth/UMA short-circuit attack above, since "random" recipients are being given access to "random" resources rather than in a targeted fashion. In other words, the RS is partnering with another service at great cost and expense to be not just a bad guy but an overall jerk, vs. seeking out specific ways to get the resources out to desired parties on the sly. *Mechanism 2: AS(bad) functions as a MITM proxying requests to AS(good)* *Discussion:* Again, it all starts with the RS's conveyance of the as_uri value. If AS(bad) has to proxy requests to and responses from AS(good), at what point does it actually get to inject something or steal something? If it provides a false rotated permission ticket, that will fail at the client's next request. It could provide a fake RPT, but it wouldn't work. It could provide a need_info error that asks the client to push more claim information than needed. But since this type of information is most likely to be pre-negotiated a la SSO attributes, it may not be understood (and we already have discussions of that and security and privacy considerations around it in the spec). Looking at the AS endpoint responses, I can't think of anything else damaging it could do. Regarding this whole second "trust attack", even though it's not fully analyzed here, I can't help feeling so far that it's not something that warrants editing the specs further. I would very much welcome input from others. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 4