Hi Nat-- Below... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, Dec 7, 2017 at 3:30 AM, n-sakimura wrote:

I am finally taking time to read the spec. First, I would commend the UMAtarians for coming out with this new draft, which looks much better than 1.0.

Having said that, there are a few questions that I have and your response will be much appreciated to form my opinion for the voting.

Q.1 `claims_redirect_uri` seems to be optional sometimes, and does not seem to require it to be unique per AS. Client ID by itself is not globally unique and to prevent mix-up attack, the security recommendation is to have something that scopes the Client ID to the AS. In case of the RFC6749, that is `redirect_uri` and it needs to be unique per AS if the client talks to multiple authorization servers. In UMA 2.0, `redirect_uri` is replaced by `claims_redirect_uri` but since it is optional and does not have the uniqueness qualification, it seems to leave an attack surface there. Was there any conscious reason for leaving this attack surface out?

You could say we're "replacing" redirect_uri with claims_redirect_uri; it's more of an "addition" or something because the redirection mechanism applies to a new actor (the requesting party) and is for a new function (claims gathering). It's optional to provide dynamically in exactly one condition, which is when the client has already pre-registered one (Grant Sec 3.3.2 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#claim-...). We specifically based our language here on the 6749 wording in order to capture all the key considerations, and did some careful revisions of this language in latter times. I've just looked through 6749 and also 6819 and see no mention of a uniqueness qualification. What am I missing? I'm assuming, of course, that as we get more deployment experience, we can develop something like an additional threat model document similar to 6819.

Q.2 `state` is recommended in RFC6749, but that has to be taken with a grain of salt. It is only ok to be optional if there is any other provisions that takes care of the CSRF, e.g., `nonce` in OpenID Connect. The `state` parameter was RECOMMENDED in RFC6749 to allow these explicit provisions by the profiles of RFC6749. My question is this: what is the specific anti-CSRF provision in UMA 2.0 so that we can leave the `state` as RECOMMENDED? If there is not, then it is better to make it a MUST. The security considerations talks a bit about it but it is all "SHOULD". I feel that being a bit more prescriptive would be a good idea for the internet hygiene. Let me know what was the reasoning behind.

We discussed making the state parameter required, but ultimately decided to align with OAuth in this regard, as you note (Grant Sec 5.1 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#csrf). UMA is just as broadly applicable to different use cases as its underlying substrate OAuth is. As proof, we're aware of at least two sector-specific efforts that involve creating tighter security profiles: HEART and Pensions Dashboard.

Q.3 It is a version two of the protocol. However, I do not see the version identifier in the messages. I am assuming that the messages are different enough from ver. 1.0 so that there will be no confusion, but want to check if it is so. (In general, I prefer to have an explicit version identifier except for the initial version to avoid the message confusion attack variants.)

For the first time, UMA is formally an OAuth extension grant. Its grant_type has the value urn:ietf:params:oauth:grant-type:uma-ticket (Grant Sec 3.3.1 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#uma-gr...). Also, the discovery document endpoint is /.well-known/uma2-configuration (Grant Sec 2 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#as-con...), so that identifies all the endpoints within it as being of that version. I hope this helps!

Best,

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: Tuesday, November 28, 2017 7:34 AM To: wg-uma@kantarainitiative.org WG Subject: [WG-UMA] URGENT: The UMA 2.0 specifications are now in Kantara All-Member Ballot

I'm pleased to report that the Draft Recommendations, which our WG approved to progress to the LC, and which the LC certified in a very efficient amount of time, have been put into All-Member Ballot by Kantara staff in a likewise extremely efficient manner. Special thanks to Andrew Hughes and Megan Cannon for their assistance!

I have prepared a Get Out The vote (GOTV) Google spreadsheet to help us reach out to Kantara members and member reps individually, to make the best use of this two-week balloting period. It will go by FAST. I invite you all to please help by going into the spreadsheet (I will share with any WG participant who requests access), filling in Kantara member/rep names, and -- especially -- marking yourself down as a "champion" to reach out personally to ask these people ASAP to vote YES on the ballot. There are tabs in the spreadsheet that even suggest email template text to make things extra easy. ;)

By the way, several Kantara individual members are also UMA WG participants, and I will be dropping each of you a note shortly!

Thank you -- please do take action on this as soon as you can, because the ballot runs from today only until DECEMBER 11!

Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

Regarding Q1: RFC 6819 -- a 2013 doc for a 2012 spec -- isn't really outdated (obsoleted), it appears, but rather supplemented by draft-ietf-security-topics (which I recall now, and also the Mix-Up attack). 6819 doesn't include the latter in its references, so people would have to know that it exists through the usual good security practices. And the mitigation for this particular attack didn't get fully described till March 2017 https://tools.ietf.org/html/draft-ietf-oauth-security-topics-02#section-4.4.... from what I can see. (I'd have to go back and see when we stopped editing our analogous text.) If this I-D -- drafted only four months prior https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 -- is ever closed, I wonder if another one would simply have to be started. Obviously security threats have to remain a live topic. We do say the following (Grant Sec 5 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#sec-co...): "This specification relies mainly on OAuth 2.0 security mechanisms as well as transport-level security. Thus, implementers are strongly advised to read [BCP195] and the security considerations in [RFC6749] (Section 10) and [RFC6750] (Section 5) along with the security considerations of any other OAuth token-defining specifications in use, along with the entire [RFC6819] specification, and apply the countermeasures described therein. As well, implementers should take into account the security considerations in all other normatively referenced specifications." This could be taken as applying good practice even if it applies analogously. And I think we should start our own threat model document as well because claims_redirect_uri not-equals redirect_uri. (Note to self: In future, have the foresight to put in spec placeholders for unlimited numbers of self-referential and external threat model docs.) But in practice, since the design is meant to align, having done the right thing in redirect_uri code should transfer readily to claims_redirect_uri code. One of our V2 design principles was OAuth alignment in as many areas as possible, and this is proving to have many benefits. Regarding Q2: This is always true, including for OAuth itself. I note that OAuth doesn't discuss generic profiling specifically for security purposes (e.g., turning various SHOULDs into MUSTs and so on). However, UMA does. For example... - Grant Sec 2 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#as-con...: uma_profiles_supported: OPTIONAL. UMA profiles and extensions supported by this authorization server... As discussed in Section 4, an authorization server supporting a profile or extension related to UMA SHOULD supply the specification's identifying URI (if any) here. - Grant Sec 4 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#profil...: "An UMA profile restricts UMA's available options. An UMA extension defines how to use UMA's extensibility points. The two can be combined. Some reasons for creating profiles and extensions include: ... A profile restricting options in order to tighten security ... The following actions are RECOMMENDED regarding the creation and use of profiles and extensions: ..." - Grant Sec 5.7 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#trust-...: "It is RECOMMENDED to document how the client, authorization server, requesting party, and any additional ecosystem entities and parties will establish a trust relationship and communicate any required keying material in a claim token profile..." - Grant 5.8 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#trust-...: "Parties that are operating and using UMA software entities may need to establish agreements about the parties' rights and responsibilities on a legal or contractual level, along with common interpretations of UMA constructs for consistent and expected software behavior. These agreements can be used to improve the parties' respective security postures..." Regarding Q3: OK. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, Dec 7, 2017 at 8:27 PM, n-sakimura wrote:

Hi Eve,

Re: Q.1

RFC6819 is outdated. You should look at https://tools.ietf.org/html/ draft-ietf-oauth-security-topics-04

Specifically, for this particular topic, you should look at https://tools.ietf.org/html/draft-ietf-oauth-security-topics-04#page-11

You need to put one of the solution or justification not to in place.

Re: Q.2

Got it. Maybe it is a good idea to make the need of profiling it before use.

Re: Q.3

Got it. Thanks.

So, while Q.2 and Q.3 seems to be ok, Q.1 still seems to be a problem to me.

*From:* Eve Maler [mailto:eve@xmlgrrl.com] *Sent:* Friday, December 08, 2017 2:23 AM *To:* n-sakimura *Cc:* wg-uma@kantarainitiative.org WG *Subject:* Re: [WG-UMA] URGENT: The UMA 2.0 specifications are now in Kantara All-Member Ballot

Hi Nat-- Below...

*Eve Maler *Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Thu, Dec 7, 2017 at 3:30 AM, n-sakimura wrote:

I am finally taking time to read the spec. First, I would commend the UMAtarians for coming out with this new draft, which looks much better than 1.0.

Having said that, there are a few questions that I have and your response will be much appreciated to form my opinion for the voting.

Q.1 `claims_redirect_uri` seems to be optional sometimes, and does not seem to require it to be unique per AS. Client ID by itself is not globally unique and to prevent mix-up attack, the security recommendation is to have something that scopes the Client ID to the AS. In case of the RFC6749, that is `redirect_uri` and it needs to be unique per AS if the client talks to multiple authorization servers. In UMA 2.0, `redirect_uri` is replaced by `claims_redirect_uri` but since it is optional and does not have the uniqueness qualification, it seems to leave an attack surface there. Was there any conscious reason for leaving this attack surface out?

You could say we're "replacing" redirect_uri with claims_redirect_uri; it's more of an "addition" or something because the redirection mechanism applies to a new actor (the requesting party) and is for a new function (claims gathering). It's optional to provide dynamically in exactly one condition, which is when the client has already pre-registered one (Grant Sec 3.3.2 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#claim-...). We specifically based our language here on the 6749 wording in order to capture all the key considerations, and did some careful revisions of this language in latter times.

I've just looked through 6749 and also 6819 and see no mention of a uniqueness qualification. What am I missing?

I'm assuming, of course, that as we get more deployment experience, we can develop something like an additional threat model document similar to 6819.

Q.2 `state` is recommended in RFC6749, but that has to be taken with a grain of salt. It is only ok to be optional if there is any other provisions that takes care of the CSRF, e.g., `nonce` in OpenID Connect. The `state` parameter was RECOMMENDED in RFC6749 to allow these explicit provisions by the profiles of RFC6749. My question is this: what is the specific anti-CSRF provision in UMA 2.0 so that we can leave the `state` as RECOMMENDED? If there is not, then it is better to make it a MUST. The security considerations talks a bit about it but it is all "SHOULD". I feel that being a bit more prescriptive would be a good idea for the internet hygiene. Let me know what was the reasoning behind.

We discussed making the state parameter required, but ultimately decided to align with OAuth in this regard, as you note (Grant Sec 5.1 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#csrf). UMA is just as broadly applicable to different use cases as its underlying substrate OAuth is. As proof, we're aware of at least two sector-specific efforts that involve creating tighter security profiles: HEART and Pensions Dashboard.

Q.3 It is a version two of the protocol. However, I do not see the version identifier in the messages. I am assuming that the messages are different enough from ver. 1.0 so that there will be no confusion, but want to check if it is so. (In general, I prefer to have an explicit version identifier except for the initial version to avoid the message confusion attack variants.)

For the first time, UMA is formally an OAuth extension grant. Its grant_type has the value urn:ietf:params:oauth:grant-type:uma-ticket (Grant Sec 3.3.1 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#uma-gr...). Also, the discovery document endpoint is /.well-known/uma2-configuration (Grant Sec 2 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#as-con...), so that identifies all the endpoints within it as being of that version.

I hope this helps!

Best,

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: Tuesday, November 28, 2017 7:34 AM To: wg-uma@kantarainitiative.org WG Subject: [WG-UMA] URGENT: The UMA 2.0 specifications are now in Kantara All-Member Ballot

I'm pleased to report that the Draft Recommendations, which our WG approved to progress to the LC, and which the LC certified in a very efficient amount of time, have been put into All-Member Ballot by Kantara staff in a likewise extremely efficient manner. Special thanks to Andrew Hughes and Megan Cannon for their assistance!

I have prepared a Get Out The vote (GOTV) Google spreadsheet to help us reach out to Kantara members and member reps individually, to make the best use of this two-week balloting period. It will go by FAST. I invite you all to please help by going into the spreadsheet (I will share with any WG participant who requests access), filling in Kantara member/rep names, and -- especially -- marking yourself down as a "champion" to reach out personally to ask these people ASAP to vote YES on the ballot. There are tabs in the spreadsheet that even suggest email template text to make things extra easy. ;)

By the way, several Kantara individual members are also UMA WG participants, and I will be dropping each of you a note shortly!

Thank you -- please do take action on this as soon as you can, because the ballot runs from today only until DECEMBER 11!

Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

Below... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Mon, Dec 11, 2017 at 6:47 AM, n-sakimura wrote:

Thanks Eve,

Re: Q.1

By “outdated”, I did not mean obsoleted, but meant that it needs to be supplemented.

We knew about Mix-up attack since 2015. There has been some mitigation strategies proposed, which OpenID Connect had from the beginning. The mitigation strategy for this attack specifically was documented as a working group draft in draft-ietf-oauth-mix-up-mitigation-01 dated July 6, 2016.

UMA, as an extension spec, could have taken this route as well just like OpenID Connect did (well… we did anticipate something like this so OpenID Connect had a facility without identifying a concrete attack).

The mitigation strategy I mentioned in the previous mail was agreed in July 2016 at the OAuth Security Workshop in Trier and in the subsequent IETF 96 in Berlin. This was documented in the OAuth list by Hannes’s email on July 25, 2016 saying “a combination of exact redirect_URI matching + per-AS redirect_URI +session state checking”. While it did not get into an IETF document till March (you know what is the IETF process is like), it was already codified in FAPI Part 1, which was approved as an implementer’s draft this February.

So, I kind of feel that UMA 2.0 could have at least one of the mitigation strategy in it. (The third one being my preferred one, but I can live with others as well.)

I am really sorry for not catching this earlier – but if it does not make it into 2.0, it should at least get into an immediately following errata.

We did sort of look to Justin (one of the coauthors) to be a liaison for topic such as this, and he was an active part of our editing of this section, but in this case we seemed to have missed the one security topic. (By the way, at this stage and with the current types of UMA ecosystems, I don't know if it's any more than a theoretical risk, though this could change over time.) Nonetheless, we will take appropriate mitigation steps.

For Q.2 and Q.3, I agree with your direction.

Other nits. Some of them are not questions but I am using Q.x numbering scheme just for the sake of consistency. (I should have numbered them like NS01, NS02, etc.)

Understood about the Q*n* structure. :-)

Q.4 Acronyms - The spec needs a section for all the various acronyms. Acronyms are used before they are defined so it makes reading the spec a little difficult. Is it intentional?

We decided to track RFC 6749 closely in having no section called Terminology, just an initial Roles section in Grant with hanging lists. Acronyms are introduced in Grant where they are first used in their full form, except for "RPT" and "PCT" in the diagram just before the relevant definitions. I couldn't find any instance of acronyms used before they are defined except for in the FedAuthz spec, where it says (FedAuthz Sec 1.2 https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-09.h...) "This specification uses all of the terms and concepts in [UMAGrant]." FedAuthz is a "sub-spec" of Grant and we didn't see the point of re-defining all the terms.

Q.5 Some sections need more examples/concrete definitions :

3.3.1 :

claim_token & claim_token_format - ID Token format is mentioned as a possible example in claim_token_format so the ID Token as a claim_token can only be indirectly inferred. Maybe switch the order or mention this in both. Maybe some basic definitions for type/format(e.g. ID Token, SAML Assertion) should be defined.

I'm not sure what you mean, since claim_token_format is defined as "A string specifying the format of the claim token in which the client is directly pushing claims to the authorization server" and the two parameters must appear together. We also give a (code) example just below of an OIDC claim token format. (The parameters are listed in alphabetical order, by the way.) I suppose it would be overtly connected if that sentence said claim_token instead of claim token, but it seems obvious.

Q.6 Parameters - Some request/return parameters have a format/type (e.g. string/boolean) defined whereas some (e.g. PCT) doesn't say what type it is. Is that intentionally left out to be defined elsewhere?

I went through both specs, and at the point of listing/defining parameters, it's pretty much ticket and pct. (The rpt parameter is definitionally about an access token.) The format/type of permission tickets is discussed in Grant Sec 5.5 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#ticket...: "Within the constraints of making permission ticket values unguessable, the authorization server MAY format the permission 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." In Grant Sec 3.3.5 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#give-r..., pct is defined as a "correlation handle" that must be "unguessable" and there is a cross-reference to Grant Sec 5.2 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#sec-co..., which contains the explanation of the requirement for PCT rotation. These both add up to similar, likely string-based, mechanisms. Do you think this is an interop consideration?

Q.7 tickets input parameters : They are defined as "most recent permission ticket". I think it would be helpful to point to the section where the "most recent" one came from. Maybe point out where returned tickets can be used also.

"The most recent permission ticket received by the client as part of this authorization process" appears in both Grant Sec 3.3.1 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#uma-gr... and 3.3.2; complex looping is possible, which we touch on in Grant Sec 1.3.1 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#author... but otherwise leave as an exercise for deployers (or might write some extra guides for, someday). We did used to have a lot more cross-referencing, but it seemed to be getting in the way rhetorically. I'm truly sorry we didn't have your input earlier. We have been cleaning up various nits and editorial items all along (for example, see our Disposition of Comments https://kantarainitiative.org/confluence/display/uma/UMA+V2.0+Disposition+of... document). At this advanced stage it's very important to press ahead with the V2.0 finalization process. I hope we have your vote of support with a plan to start a new doc for Q1.

Best,

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:* Eve Maler [mailto:eve@xmlgrrl.com] *Sent:* Saturday, December 09, 2017 12:16 AM

*To:* n-sakimura *Cc:* wg-uma@kantarainitiative.org WG *Subject:* Re: [WG-UMA] URGENT: The UMA 2.0 specifications are now in Kantara All-Member Ballot

Regarding Q1:

RFC 6819 -- a 2013 doc for a 2012 spec -- isn't really outdated (obsoleted), it appears, but rather supplemented by draft-ietf-security-topics (which I recall now, and also the Mix-Up attack). 6819 doesn't include the latter in its references, so people would have to know that it exists through the usual good security practices. And the mitigation for this particular attack didn't get fully described till March 2017 https://tools.ietf.org/html/draft-ietf-oauth-security-topics-02#section-4.4.... from what I can see. (I'd have to go back and see when we stopped editing our analogous text.) If this I-D -- drafted only four months prior https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 -- is ever closed, I wonder if another one would simply have to be started. Obviously security threats have to remain a live topic.

We do say the following (Grant Sec 5 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#sec-co...): "This specification relies mainly on OAuth 2.0 security mechanisms as well as transport-level security. Thus, implementers are strongly advised to read [BCP195] and the security considerations in [RFC6749] (Section 10) and [RFC6750] (Section 5) along with the security considerations of any other OAuth token-defining specifications in use, along with the entire [RFC6819] specification, and apply the countermeasures described therein. As well, implementers should take into account the security considerations in all other normatively referenced specifications."

This could be taken as applying good practice even if it applies analogously. And I think we should start our own threat model document as well because claims_redirect_uri not-equals redirect_uri. (Note to self: In future, have the foresight to put in spec placeholders for unlimited numbers of self-referential and external threat model docs.) But in practice, since the design is meant to align, having done the right thing in redirect_uri code should transfer readily to claims_redirect_uri code. One of our V2 design principles was OAuth alignment in as many areas as possible, and this is proving to have many benefits.

Regarding Q2:

This is always true, including for OAuth itself. I note that OAuth doesn't discuss generic profiling specifically for security purposes (e.g., turning various SHOULDs into MUSTs and so on). However, UMA does. For example...

- Grant Sec 2 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#as-con...: uma_profiles_supported: OPTIONAL. UMA profiles and extensions supported by this authorization server... As discussed in Section 4, an authorization server supporting a profile or extension related to UMA SHOULD supply the specification's identifying URI (if any) here. - Grant Sec 4 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#profil...: "An UMA profile restricts UMA's available options. An UMA extension defines how to use UMA's extensibility points. The two can be combined. Some reasons for creating profiles and extensions include: ... A profile restricting options in order to tighten security ... The following actions are RECOMMENDED regarding the creation and use of profiles and extensions: ..." - Grant Sec 5.7 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#trust-...: "It is RECOMMENDED to document how the client, authorization server, requesting party, and any additional ecosystem entities and parties will establish a trust relationship and communicate any required keying material in a claim token profile..." - Grant 5.8 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#trust-...: "Parties that are operating and using UMA software entities may need to establish agreements about the parties' rights and responsibilities on a legal or contractual level, along with common interpretations of UMA constructs for consistent and expected software behavior. These agreements can be used to improve the parties' respective security postures..."

Regarding Q3: OK.

*Eve Maler *Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Thu, Dec 7, 2017 at 8:27 PM, n-sakimura wrote:

Hi Eve,

Re: Q.1

RFC6819 is outdated. You should look at https://tools.ietf.org/html/ draft-ietf-oauth-security-topics-04

Specifically, for this particular topic, you should look at https://tools.ietf.org/html/draft-ietf-oauth-security-topics-04#page-11

You need to put one of the solution or justification not to in place.

Re: Q.2

Got it. Maybe it is a good idea to make the need of profiling it before use.

Re: Q.3

Got it. Thanks.

So, while Q.2 and Q.3 seems to be ok, Q.1 still seems to be a problem to me.

*From:* Eve Maler [mailto:eve@xmlgrrl.com] *Sent:* Friday, December 08, 2017 2:23 AM *To:* n-sakimura *Cc:* wg-uma@kantarainitiative.org WG *Subject:* Re: [WG-UMA] URGENT: The UMA 2.0 specifications are now in Kantara All-Member Ballot

Hi Nat-- Below...

*Eve Maler *Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Thu, Dec 7, 2017 at 3:30 AM, n-sakimura wrote:

I am finally taking time to read the spec. First, I would commend the UMAtarians for coming out with this new draft, which looks much better than 1.0.

Having said that, there are a few questions that I have and your response will be much appreciated to form my opinion for the voting.

Q.1 `claims_redirect_uri` seems to be optional sometimes, and does not seem to require it to be unique per AS. Client ID by itself is not globally unique and to prevent mix-up attack, the security recommendation is to have something that scopes the Client ID to the AS. In case of the RFC6749, that is `redirect_uri` and it needs to be unique per AS if the client talks to multiple authorization servers. In UMA 2.0, `redirect_uri` is replaced by `claims_redirect_uri` but since it is optional and does not have the uniqueness qualification, it seems to leave an attack surface there. Was there any conscious reason for leaving this attack surface out?

You could say we're "replacing" redirect_uri with claims_redirect_uri; it's more of an "addition" or something because the redirection mechanism applies to a new actor (the requesting party) and is for a new function (claims gathering). It's optional to provide dynamically in exactly one condition, which is when the client has already pre-registered one (Grant Sec 3.3.2 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#claim-...). We specifically based our language here on the 6749 wording in order to capture all the key considerations, and did some careful revisions of this language in latter times.

I've just looked through 6749 and also 6819 and see no mention of a uniqueness qualification. What am I missing?

I'm assuming, of course, that as we get more deployment experience, we can develop something like an additional threat model document similar to 6819.

Q.2 `state` is recommended in RFC6749, but that has to be taken with a grain of salt. It is only ok to be optional if there is any other provisions that takes care of the CSRF, e.g., `nonce` in OpenID Connect. The `state` parameter was RECOMMENDED in RFC6749 to allow these explicit provisions by the profiles of RFC6749. My question is this: what is the specific anti-CSRF provision in UMA 2.0 so that we can leave the `state` as RECOMMENDED? If there is not, then it is better to make it a MUST. The security considerations talks a bit about it but it is all "SHOULD". I feel that being a bit more prescriptive would be a good idea for the internet hygiene. Let me know what was the reasoning behind.

We discussed making the state parameter required, but ultimately decided to align with OAuth in this regard, as you note (Grant Sec 5.1 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#csrf). UMA is just as broadly applicable to different use cases as its underlying substrate OAuth is. As proof, we're aware of at least two sector-specific efforts that involve creating tighter security profiles: HEART and Pensions Dashboard.

Q.3 It is a version two of the protocol. However, I do not see the version identifier in the messages. I am assuming that the messages are different enough from ver. 1.0 so that there will be no confusion, but want to check if it is so. (In general, I prefer to have an explicit version identifier except for the initial version to avoid the message confusion attack variants.)

For the first time, UMA is formally an OAuth extension grant. Its grant_type has the value urn:ietf:params:oauth:grant-type:uma-ticket (Grant Sec 3.3.1 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#uma-gr...). Also, the discovery document endpoint is /.well-known/uma2-configuration (Grant Sec 2 https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html#as-con...), so that identifies all the endpoints within it as being of that version.

I hope this helps!

Best,

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: Tuesday, November 28, 2017 7:34 AM To: wg-uma@kantarainitiative.org WG Subject: [WG-UMA] URGENT: The UMA 2.0 specifications are now in Kantara All-Member Ballot

I'm pleased to report that the Draft Recommendations, which our WG approved to progress to the LC, and which the LC certified in a very efficient amount of time, have been put into All-Member Ballot by Kantara staff in a likewise extremely efficient manner. Special thanks to Andrew Hughes and Megan Cannon for their assistance!

I have prepared a Get Out The vote (GOTV) Google spreadsheet to help us reach out to Kantara members and member reps individually, to make the best use of this two-week balloting period. It will go by FAST. I invite you all to please help by going into the spreadsheet (I will share with any WG participant who requests access), filling in Kantara member/rep names, and -- especially -- marking yourself down as a "champion" to reach out personally to ask these people ASAP to vote YES on the ballot. There are tabs in the spreadsheet that even suggest email template text to make things extra easy. ;)

By the way, several Kantara individual members are also UMA WG participants, and I will be dropping each of you a note shortly!

Thank you -- please do take action on this as soon as you can, because the ballot runs from today only until DECEMBER 11!

Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl