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 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 -- 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): "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: 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: "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: "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: "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 <n-sakimura@nri.co.jp> 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 <n-sakimura@nri.co.jp>
Cc: wg-uma@kantarainitiative.org WG <wg-uma@kantarainitiative.org>
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 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Thu, Dec 7, 2017 at 3:30 AM, n-sakimura <n-sakimura@nri.co.jp> 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). 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). 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). Also, the discovery document endpoint is /.well-known/uma2-configuration (Grant Sec 2), 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 <wg-uma@kantarainitiative.org>
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