December 2017 - WG-UMA - mailman.kantarainitiative.org

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

Article: Why the PAT?
by Eve Maler 20 Dec '17

20 Dec '17

I've written an article called "UMA: Why the PAT? <https://docs.google.com/a/forgerock.com/document/d/1UFFc3MJg5fPHfT5_oruAqxa…>" and I would be grateful for any review comments -- and ideas for publication options -- people have. This question comes up a lot, and the writeup has already been helpful. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-12-21
by Eve Maler 19 Dec '17

19 Dec '17

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-12-21 Date and Time - *Thursdays 9am PT* - Screenshare and dial-in: http://join.me/findthomas (WILL CHANGE IN 2018) - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2017-12-14 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-12-14> - 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…> ) - Discuss security attacks and outcomes - 2017-12-14 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-12-14> - AOB - *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Preparing for our call today - hope you can make it
by Eve Maler 14 Dec '17

14 Dec '17

If you haven't yet read the latter half of the "URGENT: The UMA 2.0 specifications are now in Kantara All-Member Ballot" thread <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/jL3puNyiF…> where Nat raised an issue to do with the OAuth Mix-Up attack, please take a moment to do so before the call shortly. He has already attached similar feedback to his vote (a No vote) on the ballot, and made some specific recommendations for next actions). I'm very grateful to Nat for his comments! His application of time and expertise are always welcome. Although Kantara process does not require us to provide a disposition of comments at this stage of the proceedings, the nature of Nat's first comment particularly seems to warrant such. I've discussed the issue a bit with Justin, and right now, it's our current mutual understanding that the OAuth Mix-Up attack does *not* apply to UMA. I'll try to explain the logic briefly here, and plan to explore this in the call (and, as warranted, in continuing fashion with the WG) to ensure we get a proper understanding and consensus around this issue. Helpful resources: - https://tools.ietf.org/html/draft-ietf-oauth-security-topics-04#section-4.4 - https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-01 The theory of why the attack (a client-AS MITM attack that exploits an endpoint discovery problem) applies is that the OAuth redirect_uri parameter, which the client gives to the AS to enable the AS to send the user (resource owner) back to the client after the process at the authorization endpoint is done, is directly analogous to UMA's claims_redirect_uri. However, UMA already has built-in ways to provision the client with the targeted AS and endpoint information it needs to make good endpoint-routing decisions, before the client gets to the stage of having to give the AS a claims_redirect_uri value. The first step is that the RS knows which AS is protecting whichever resource the client is trying to request, and it provides an as_loc value ("AS location"). This gets the client to the AS discovery document, where the client finds at least the token endpoint URI. (UMA doesn't have an authorization endpoint.) If the client gets an error from this endpoint that leads it to do interactive claims gathering, and it didn't yet know the claims interaction endpoint from the discovery document, it would get it from the need_info error response (the redirect_user hint) from that token endpoint. If, by chance, the client is supposed to send the requesting party to do interactive claims gathering first before approaching the token endpoint, this relies on the claims interaction endpoint also having been declared statically in the discovery document. I hope this helps us sort through the issue. Hope you can join the call. Thanks. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2017-12-14
by Eve Maler 12 Dec '17

12 Dec '17

https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-12-14 Date and Time - *Thursdays 9am PT* - Screenshare and dial-in: http://join.me/findthomas - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2017-11-30 <https://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-11-16> - 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…> - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0