- WG-UMA - mailman.kantarainitiative.org

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

Draft minutes of UMA telecon 2017-12-21
by Eve Maler 23 Dec '17

23 Dec '17

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-12-21 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-12-14 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-12-14>: APPROVED by unanimous consent. Meeting schedule - No meetings next week - New GoToMeeting usage in the new year - New calendar entries in the new year – please subscribe to the calendar - Prepare for Roadmap discussions (see blog post here <https://kantarainitiative.org/confluence/display/LC/2017/12/19/UMA+WG+Updat…> ) Eve will specifically invite voting participants to the new calendar entry, and anyone else who asks. The first WG meeting in the new year will be on Jan 4, and the first Legal meeting will be on Jan 5. Andi reminder: The Identiverse CfP <https://www.cvent.com/c/abstracts/48548758-ef7e-4e8c-b1e1-8b970733bc9b> is still open until Jan 15! Don't forget! Discuss security attacks and outcomes The UMA multi-endpoint mix-up attack analysis is here <https://www.websequencediagrams.com/files/render?link=gW2y6DH8IG0-y1Wukq-4>. Nat wrote: *(1) How does the client obtain the issuer string to bootstrap? [attack surface 1] – there are real examples for this kind of attack being successful.* *(2) Has the DNS spoofing against the client for issuer combined with falsely issued certificate been considered? [attack surface 2] – there has been a real attack like this.* *(3) What kind of agent a typical RqP using? If it is a browser, then browser infection to rewrite the request/response is possible. [attack surface 3] – this is a rather common attack.* *It really depends on the answer, but unless there are specific considerations to block the surface, the answers to the questions “Can attacker inject false claims interaction endpoint” and “Does attacker receive claims redirection URI” seem to be both YES to me.* If No. 1 is a point of attack, then the RS is the attacker, and it has much greater/sooner opportunities for attack, as you point out in a way with the as_uri observation. We have analyzed these here <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/XYpGvjLjl…>. Given the potential scope of damage but also the RS's need for a relationship, we've dubbed them "trust attacks", and they don't seem to have practical technical mitigations. Regarding No. 2, UMA already adopts OAuth's security considerations and TLS usage and is simply defined as an OAuth grant (and FedAuthz requires TLS usage). Our thinking is that there's no need for us to add a specific security consideration around this because there's nothing in UMA that's unique relative to OAuth (or even other TLS-using protocols). Regarding No. 3, UMA works with clients of both public and confidential types (Grant Sec 3.3 <https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#seek-…>). Different security levels can thus be achieved in UMA, a bit similarly to choosing different grants in base OAuth. The browser environment obviously raises the possibility of various attacks, which is why there is so much effort in the OAuth security considerations put into that environment. The same security considerations apply. We have consensus on these issues. We will seek a meeting with Nat to try and align on these important topics (as soon as practicable in January) and close the loop firmly. It would be great if Justin could join too. Happy holidays and happy new year to everyone! 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: - George *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 1

Notes from UMA Legal telecon 2017-12-22
by Eve Maler 23 Dec '17

23 Dec '17

https://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+not… 2017-12-22 Attending: Eve, Kathleen, Tim, Bjorn We now have a draft 6 of the paper thanks to Tim's efforts! He considers it nearly complete, which is amazing! He has resolved all the must-do comments. There are other "philosophical discussion" comments that still appear in the draft 5 GDoc, so we haven't lost any of that, but we need not address them them all. *AI:* Eve: Create GitHub issues with the "trust" label (see others here <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…>) for any "real" remaining GDoc comments. Eve talked to Origo and they're interested to check out the UMA Legal work. See their Aggregating and Sharing Pension Information case study video here <https://kantarainitiative.org/confluence/display/uma/Case+Studies>. There's a Kantara-supported International Privacy Summit on Jan 29 in London. Eve is likely traveling to speak there (if not, then presenting by Skype!). Subject: Something like UMA Legal+Consent Receipts. So let's get the model doc ready for its closeup. Kathleen is suggesting not just throwing consent receipts, but also an acknowledgment, or sending the receipt back with an expiration date, so you don't need a new artifact. She and Mohammad are discussing this. She can share a swimlane. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 3

Last Legal call of the year is tomorrow / new calendar entries for 2018
by Eve Maler 21 Dec '17

21 Dec '17

Talk then! (using join.me/findthomas for one last time...) By the way, I have now created 2018 versions of the WG and Legal calendar entries, pointing to the new GoToMeeting link for our calls. I haven't reproduced ALL the invitations as they were before. *If you want to receive an invitation for either or both meeting series, drop me a private note and I will add you.* *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Analysis of the first "opt" box in the figure (was: RE: Trying to analyze "trust attacks")
by n-sakimura 21 Dec '17

21 Dec '17

Hi Eve, Thanks for the drawing. With regard to analysis swimlane<https://www.websequencediagrams.com/files/render?link=gW2y6DH8IG0-y1Wukq-4>, I have a few questions. (1) How does the client obtain the issuer string to bootstrap? [attack surface 1] – there are real examples for this kind of attack being successful. (2) Has the DNS spoofing against the client for issuer combined with falsely issued certificate been considered? [attack surface 2] – there has been a real attack like this. (3) What kind of agent a typical RqP using? If it is a browser, then browser infection to rewrite the request/response is possible. [attack surface 3] – this is a rather common attack. It really depends on the answer, but unless there are specific considerations to block the surface, the answers to the questions “Can attacker inject false claims interaction endpoint” and “Does attacker receive claims redirection URI” seem to be both YES to me. Nat Sakimura PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. From: WG-UMA [mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of Eve Maler Sent: Thursday, December 21, 2017 5:59 AM To: wg-uma(a)kantarainitiative.org WG <wg-uma(a)kantarainitiative.org> Subject: [WG-UMA] Trying to analyze "trust attacks" 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

1 0

Draft minutes of UMA telecon 2017-12-14
by Eve Maler 21 Dec '17

21 Dec '17

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-12-14 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-11-30 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-11-16>: Deferred. Discuss ballot results, comments, and next steps See discussion in the latter part of the thread here <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/jL3puNyiF…> and additional notes Eve sent today with thoughts from Justin and herself here <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/0mRokk5ml…> . George/Eve/(implicit Robert from earlier in the day) discussion: The "UMA version" of a mix-up attack would have to start with the RS sending a wrong or malicious as_loc. Let's say a malicious RS wants to point all clients to a fake AS. The client now has discovered a false token endpoint (let's keep it simple; ignore interactive claims gathering for the moment) and POSTs to it. It comes back with a false RPT that allows the client to do everything. If the RO had already set up the RS with a good AS (authorizing PAT issuance), then the RS could get a permission ticket from *AS*(*good*) and send it and the as_uri for *AS*(*bad*) to the client – and potentially the later two protection API endpoint interactions too. But if there is a claims_redirect_uri-specific attack too, that's separate. Taking the two presumed-separate attacks in turn: In the OAuth security topics draft <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-04#section-4.4>, the mix-up attack (presumed related to claims_redirect_uri) is summarized briefly as: "Mix-up is another kind of attack on more dynamic OAuth scenarios (or at least scenarios where a OAuth client interacts with multiple authorization servers). The goal of the attack is to obtain an authorization code or an access token by tricking the client into sending those credentials to the attacker (which acts as MITM between client and authorization server)". Nat's preferred mitigation, it appears, is the third one: "Clients use AS-specific redirect URIs, for every authorization request store intended AS and compare intention with actual redirect URI where the response was received (no change to OAuth required)". Who is the bad actor? Not the RS; only the AS. Establishing some facts on the ground: In a single UMA authorization process, a client could cycle around approaching the token endpoint on the back channel and redirecting the requesting party to the claims interaction endpoint on the front channel. In order to use the claims interaction endpoint first, the AS has to declare it in the discovery document statically. The AS always has to declare the token endpoint statically. The AS has the option to dynamically provide the claims interaction endpoint as part of the redirect_user hint inside the need_info error after the client's request for a token at the token endpoint fails. The "third mitigation" described in the OAuth security topics draft is for the client to supply a redirection URI that's specific to the AS it came from, so the client can detect proxying/spoofing/tricks. Does this mitigation help from an UMA perspective? The interaction between Bob the requesting party and the AS is sort of "private" for the purpose of collecting claims. However, the AS does send back a rotated permission ticket. Then again, if the client next brings that ticket to the token endpoint to try and get its RPT, which is the only legitimate next step, can we assume it had a good token endpoint, and *AS*(*good*) will reject *AS*(*bad*)'s faux permission ticket? Nope, because there was never *AS*( *good*). But if there was only ever *AS*(*bad*), it could do so much insidious damage everywhere that every communications channel is suspect – with the RS, with the client, with the RO, with the RqP... There are discovery document attacks (all endpoints are funky), RO-trust PAT issuance attacks, policy modification attacks (RO never gets what they want and all protected resources are compromised/stolen), RqP phishing attacks, RO phishing attacks... If there's a malicious AS (without a malicious RS) in the world, we're eventually talking scandals, headlines, etc. Andi notes that such scenarios, similar to contemplating collusion of the major SAML entities, are just disastrous and seem to be beyond reasonable mitigation. We seem to be aligned in thinking that this circumstance is Armageddon, and goes against the entire point of what's discussed in UMA generally (and sections like FedAuthz Sec 1.4 <https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-09.…>specifically), that there's little we could do about it. Now returning to the potentially novel attack where a colluding *RS*(*bad*) and *AS*(*bad*) could pull one over on a naive *AS*(*good*): First, note that even in UMA1 (See UMA1.0.1 Core Sec 1.4 <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#am-endpoints>), we didn't force endpoint declarations to be at the same host as the issuer/config doc, and there are real-life deployments where you might want the various endpoints not to share a host. So there's no point telling the client to check on this. This is about the entire protection API, not just claims interaction. This could hinge on the PAT as a mitigation, potentially. Still thinking about interactive claims gathering, if the client gets confused and sends the permission ticket that it gets to the wrong AS, George is thinking that this should fail. But our conclusion up above was that it wouldn't fail because the permission ticket (endpoint 1) came from the RS-proxied *AS*(*bad*), and the client originally got the as_uri from *RS*(*bad*) and thus the discovery document was tainted and had a token endpoint declaration pointing to *AS*(*bad*) or a MITM to *AS*(*good*). The other two suggested mitigations in the OAuth world are that OAuth and/or OIDC add in an issuer and client ID value dynamically. All the mitigations rely on clients being the "smart one in the room" and paying attention, which is probably not the smartest way to bet! Unfortunate. We intend to continue working towards consensus on this thread. Let's plan to meet on December 21st on this topic. 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 Non-voting participants: - George - Bjorn - Colin *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

3 6