Variety of issues on revs 05

[xmlgrrl]

These were submitted on the WG list [UPDATE: Edited to add letters to distinguish individual comments for reference in Disposition of Comments document]:

https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.html:

• a: 5.1.1: For exp, the behavior for absent value is defined. iat and nbf are missing definition for this state. Although it is quite intuitive (“if absent, the token-level value takes precedence”), might be worth include it to prevent possible misunderstandings.

https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html:

• b: 3.3: “The client has obtained OAuth client credentials from the authorization server, …, and is prepared to authenticate itself to the token endpoint if appropriate.” RFC6749 – 3.2.1: “Confidential clients or other clients issued client credentials MUST authenticate with the authorization server as described in Section 2.3 when making requests to the token endpoint.” Doesn’t this mean, that in UMA, the client requesting at the token EP MUST always authenticate? The formulation from uma_grant 3.3 may lead to a conclusion there exists a situation in which it is not necessary to authenticate.
• c: 3.3.2: If AS supports RFC7591, it MUST allow clients to register claims_redirect_uri (as mentioned in 2.), but it is not defined, how this parameter looks like (array?, space separated?) Shouldn’t it be better to have “claims_redirect_uris”? (RFC7591 defines redirect_uris also in plural). In RFC6749, redirection URI (which is similar from the security point of view to the claims redir URI) SHOULD require the use of TLS and MUST be registered for public clients. In addition, an incomplete redirection URI is enabled, and some other features. Wouldn’t it be beneficial to define claims redirection URI with reference to the definition of redirection URI?
• d: 3.3.3: I personally would extend the first sentence to “ … of the claims redirection URI resolved according to the algorithm described in previous section using the …”. Otherwise, any preregistered claims redirection URI might be used (I know you would need to be an evil implementer to do this, but hey, who isn’t a bit?).
• e: 3.3.3: The example response from AS is actually a request.
• f: 3.3.4: This whole section makes the permission concept unclear to me. I suppose, that a request for RPT can contain multiple tuples (resource, scopes), where the scopes for each resource may be different. Section 3.3.4 puts an impression on me, that all these scopes sets are actually identical. Namely: “Let a set called PermissionTicket stand for the scopes associated with the permission ticket” does not distinguish between all the permissions that can be bound to the permission ticket. The example does not help in this either, as it concerns only a single resource. I’d suggest to add something like: “This authorization assessment holds for any permission bound to the permission ticket received by the AS.” Subsequently, it needs to be made clear, what happens if CandidateGrantedScopes < RequestedScopes for not all of the requested permissions.
• (no letter; see #332) 3.3.5: Described in https://github.com/KantaraInitiative/wg-uma/issues/332
• g: 5.6: Permission ticket is similar in use to authorization code in OAuth (both are single use, may be transferred over plain HTTP), but the latter is influenced by additional security measure – if the same code is observed twice by AS, it should attempt to revoke all access tokens issued based on that code. Shouldn’t this be considered also for the permission ticket and relevant RPTs?

[xmlgrrl]

Editor response to sub-issue (b): The UMA grant is actually agnostic as to whether the client is confidential, so mentioning "client credentials" (vs, say, having obtained at least a client identifier) is essentially an overstatement in the case of public clients. This is why the text subsequently says "...and is prepared to authenticate itself to the token endpoint if appropriate".

The editor recommends clarifying that the client MAY be public or confidential, with the attendant implications for its authentication credentials.

[xmlgrrl]

Editor response to sub-issues (c) and (d): A requirement for the authorization server to allow dynamic registration of these URIs as part of ([RFC7591] or [OIDCDynClientReg]) dynamic client registration is mentioned in Grant Sec 2. (UMA cannot itself provide a way to do this.) Static client registration is an out-of-band mechanism so there is no way to specify the precise mechanism here either.

The group chose to design the claims redirection URI as a close cousin of the redirection URI mechanism, eschewing the incomplete URI idea for simplicity. We decided to make pre-registration a SHOULD because OAuth does so, having discussed it several times. (Can't locate the 6749 reference saying public clients MUST register a redirection URI.)

The definition of the claims redirection URI (where it is supplied by a client in an actual redirect) in Grant Sec 3.3.2 does refer to the definition of the OAuth redirection URI, pointing out similarities and differences.

The editor therefore recommends no change.

[xmlgrrl]

Editor response to sub-issue (e): Yes, we will fix this.

[xmlgrrl]

Editor response to sub-issue (f): In UMA, scopes can differ per resource, though they need not; the example illustrates this with photo1 and photo2, in that the second resource has a scope, link, available to it that the first resource does not. Let's say a third resource called album existed too, with its own unique scopes, say, layout and buy. The resource server could have requested this at the same time as photo1 because the photo appears in this album.

The group previously received a comment that caused us to clarify some related text in this section (issue #328) (see here). It appears further clarification could be warranted. In short, clients are unaware of the resource-boundedness of scopes, and as a result, the authorization server takes an expansive approach in matching each scope the client has pre-registered and is requesting to all of the scopes anywhere (associated with any resource) in a permission ticket.

The editor recommends expanding on the text slightly to achieve this, possibly including enhancing the example.

[xguttner]

(c),(d): The MUST for redirection endpoint to be registered for public clients is in RFC6749 sec. 3.1.2.2. and again in the last paragraph of 10.6. The definition of claims redirection endpoint in Grant Sec 3.3.2 is clear and understandable. I just wanted to point out for consideration the two issues that are not addressed (SHOULD for TLS and MUST for public clients). As of the definition of the format of claims_redirect_uri when using RFC7591, I still think this should be defined (somewhere). Let's have two different approaches - RFC6749 (to my knowledge) does not refer explicitly to any defined way of client registration. On the contrary, OpenID refers to the OpenID Connect Dynamic Client Registration when speaking about registered parameters, while the use of the DCR is not required. It seems to me that UMA specification follows the same approach as OpenID, while not defining the actual structure of the parameter... Maybe just a registration of the client metadata element into the "OAuth Dynamic Client Registration Metadata Registry" could be enough?

(f): Issue #328 is about something different than I had on mind. Issue (f) comes really from the fact the permission ticket is bound to multiple requested permissions and sec 3.3.4 deals with it more in an 1:1 manner. Namely, what does: "Let a set called PermissionTicket stand for the scopes associated with the permission ticket ..." mean? If "A permission ticket represents some number of requested permissions ...", then is PermissionTicket a set of scopes from a single permission and the whole section 3.3.4 depicts the processing for each of the requested permissions represented by the permission ticket (which is how I understand it, but it's really not mentioned). Or is PermissionTicket a union of scopes from all the permissions represented by the permission ticket (which I doubt, but I haven't found a sentence that would prevent this).

[xmlgrrl]

(Closing this issue was a mistake -- meant to close a different one!)

[xmlgrrl]

Editor response to sub-issue (g): Regarding permission tickets: We do say in Grant Sec 5.6 that "The authorization server MUST invalidate a permission ticket when the client presents the permission ticket to either the token endpoint or the claims interaction endpoint, or when the permission ticket expires, whichever occurs first." I think this requirement may have even a stronger effect to the one you mention (if the AS sees a duplicate it kills any access tokens based on that duplicate). Combined with the rule about their being single-use, seeing a duplicate just means it would get rejected by the AS with an invalid_grant error as described in Grant Sec 3.3.6. Is this missing a security scenario?

Regarding RPTs, they are access tokens and aren't single-use, so this doesn't seem to apply, unless I'm missing something else about your comment.

[xguttner]

First, sorry for giving you a hard time :)

Second, (g). I finally see where we don't understand each other. You've written the requirement I've mentioned is: "if the AS sees a duplicate it kills any access tokens based on that duplicate". In this case, yes, you're right and what's already in Grant Sec 5.6 is maybe more strict. However, this is not what I meant.

The whole sentence in RFC6749 Sec 10.5. is: "If the AS observes multiple attempts to exchange an authorization code for an access token, the AS SHOULD attempt to revoke all access tokens already granted based on the compromised authorization code." And the key is in how you perceive the term "compromised". You've written "to kill any AT based on that duplicate", which I think means the ATs issued by the first use of authorization code/permission ticket will be still valid. Contrary, I perceive it as deleting also the ATs based on the first (legitimate) use of authorization code. This has a stronger effect to what is in Grant Sec 5.6 as there the permission ticket is invalidated only and no other actions needed. For authorization code, subsequent actions SHOULD be taken, i.e., observing the duplication and ...

More insight into this gives RFC6749 Sec 10.4. that, 'though it deals with refresh tokens, describes similar approach: "For example, the AS could employ refresh token rotation in which a new refresh token is issued with every access token refresh response. The previous refresh token is invalidated but retained by the AS. If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach." And exactly this is what IMHO happens with authz code and might by applied also to permission ticket. You can't be sure which use is the valid one, hence you need to invalidate everything.

Maybe I'm utterly wrong somewhere, but I at least hope this was explanatory enough.

[xmlgrrl]

No worries! And I understand now. We should be reaching a conclusion on this and the other outstanding issues in today's call, assuming we have the time to discuss all of them. By the way, as a (non-voting) WG participant you're welcome to join the call anytime.

[xguttner]

One more thing regarding (g) - if you agree the security risk is high enough to include this in the standard, then similar issue applies on PCT as it is sent in the same response as RPT. If the attacker somehow gets the permission ticket and is quick enough to use it first to get the response, then it will get RPT and optionally PCT. Subsequent use of the same permission ticket (by the valid user) could lead to invalidation of the RPT (according to suggestion (g)), but this is not enough, as the attacker might use the issued PCT. The threat here is somehow limited by the bound of PCT-client that is maintained by AS (I assume this also means that there MUST be a validation that requesting client has to be bound to the used PCT). However, as mentioned earlier, UMA does not restrict the use of confidential clients, so this threat is still valid for public clients.

(Maybe there is something that actually prevents this, but it is a bit overcomplicated to me now... would need to think about it a bit longer.)

P.S.: Did I mention that it probably also applies on a new permission ticket based on compromised old permission ticket?

[xmlgrrl]

Edited the issue title so as not to prejudice the nature of the issues before they're all fully decided. Also removed the "editorial" label.

[xmlgrrl]

Per UMA telecon 2017-07-27:

On sub-issue c/d: The suggestion is to 1) make it a MUST for the AS to require public clients to register claims redirection URIs (Grant Sec something), with the rationales that it matches 6749 Sec 3.1.2.2 and it's more secure (we have consensus on this), and 2) to request registration of a metadata field to the OAuth dynamic client registration metadata registry (Grant Sec 2). Would we also want to request registration of a metadaata field to the OIDC dynamic client registration metadata registry, or is it all the same? It appears to be the former. We have consensus that adding the metadata field is sensible too, with the rationale that it gives a concrete way to register the URI and removes friction from interoperable dynamic registration. But we do want to check with Justin (who is the designated expert for this metadata registry). This would require a new section or subsection in Grant akin to the AS metadata section. AI: Eve: Ping Justin re claims_redirect_uri metadata field.

Re sub-issue f: We discussed Cigdem's proposed example, which starts with a resource request of album and a permission ticket containing photo1 and photo2, which adds a level of trickiness that may be distracting for the point at hand. We think the calculation seems pretty simple regardless; the AS is "dumb" with respect to resources, even though scopes are resource-bound, so it does the calculatiion the same way regardless. Only the RS knows resource relationships. The AS does an expansive scope match on the client's behalf because the client is "dumb" with respect to resources. AI: Eve (hopefully with Cigdem's input): Come up with a hybrid example that has two resources in the permission ticket.

[xmlgrrl]

Per UMA telecon 2017-08-03: On sub-issue (b): We reached consensus to replace the current assumption wording in Grant Sec 3.3: "The client has obtained OAuth client credentials from the authorization server, either dynamically through [RFC7591] or [OIDCDynClientReg], or alternatively through a static process, and is prepared to authenticate itself to the token endpoint if appropriate." with: "The client has obtained a client ID or a full set of client credentials as appropriate, either statically or dynamically (for example, through [RFC7591] or [OIDCDynClientReg]). This grant works with clients of both confidential and public types."

[xmlgrrl]

Per UMA telecon 2017-07-27:

Re sub-issue a: RFC 7519 just says these three claims are optional. (Right now we are being inspired by the claims and not registering for JWT claims specifically.) Cigdem, along with Justin, argued for removal of an explicit statement (as we still do for exp) saying exactly what it means when the permission-level parameter is absent. If we don't say, then Eve's interpretation is that "the AS isn't claiming anything" about that semantic. It's up to the AS, presumably, what it means, but that's part of its prerogative. Mike wonders what AS wouldn't include a value. We already say what happens if it has a value at variance with the permission-level value. If we take away the exp "no-value" statement of "never", then the AS has the incentive to do the right thing in any case (vs, say, deciding on a super-secret nbf value of Jan 5, 2020 at 03:59:53). That doesn't help anyone! Consensus to remove the exp statement.

[xmlgrrl]

For completeness's sake, noting that UMA telecon 2017-08-07, decided sub-issue g.