UMA Claims-Gathering Extension for Enhanced Security

The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in [RFC2119].

Unless otherwise noted, all protocol properties and values are case sensitive. JSON [RFC7159] data structures defined by this specification MAY contain extension properties that are not defined in this specification. Any entity receiving or retrieving a JSON data structure SHOULD ignore extension properties it is unable to understand. Names of such extension properties that are unprotected from collisions are outside the scope of this specification.

Following is a summary of this extension and how its identifying URI is used.

• Identifying URI: https://docs.kantarainitiative.org/uma/extensions/claims-sec-1.0
  • An UMA authorization server implementing this specification MUST provide this identifying URI in the uma_profiles_supported property in its configuration data.
• Extension author and contact information: Maciej Machulak (maciej@synergetics.be).
• Updates or obsoletes: None; this extension is new.
• Security considerations: The purpose of the extension is to enhance security.
• Privacy considerations: None additional.
• Error states: None additional.

One of the methods of requesting party trust elevation defined by UMA is redirecting an end-user requesting party to the authorization server for claims-gathering. Since the return URI from this claims gathering process is predictable, this method is susceptible to a session fixation attack. As a consequence, a malicious requesting party may be able to access a protected resource not intended for access by that party by having a legitimate user supply claims and associate them with the attacker's permission ticket.

This extension mitigates the attack by enhancing the security of the claims-gathering mechanism to return an unpredictable URI, thereby making an attacker unable to guess the return state from the victim's claims gathering process and halting the attack. The URI is made unguessable by returning a new permission ticket value, which the client then uses to interact with the authorization server from that point forward, discarding any previous ticket values in the process.

Any authorization server intending to use interactive claims-gathering as the sole means of trust elevation SHOULD implement the extension defined in this specification. Trust elevation through authentication context (requesting party authentication at the authorization endpoint) and pushed claims (claims provided to the RPT endpoint by the client) are not susceptible to this attack.

Preconditions:

• The attacker (a malicious requesting party) and the victim (a legitimate end-user requesting party) both use a client (same instance or different instances) with the same client ID.
• The client(s) are legitimate and uncompromised.
• Both the attacker and the victim already have their respective AATs, which are valid.

Sequence:

1. The attacker attempts access to an UMA protected resource normally available to the victim but not the attacker.
2. The resource server registers a requested permission; the authorization server returns a permission ticket; and the resource server returns a permission ticket (along with other data) to the client.
3. The client asks for authorization data and RPT at the authorization server; the authorization server returns a need_info response with an error_details block containing a redirect_user hint (or the client infers the requirement to redirect the browser to the requesting party claims endpoint).
4. The client attempts to redirect the attacker's browser to the requesting party claims endpoint, but the attacker copies the redirect URL (optionally stripping off the state parameter), including a permission ticket query parameter, and passes it to the victim. The attacker may try to prevent the redirect from their client as well.
5. The victim is tricked to access the URL provided by the attacker (e.g. using a phishing technique). After being phished with the URL, the victim assists the authorization server in completing the claims-gathering process.
6. The authorization server redirects the victim back to the client. No relevant session is found in the client, so the post-redirect request fails. Alternatively, if the attacker controls the victim's network access, they prevent communication between victim and client and stop the redirect.
7. After sufficient time has elapsed, the attacker sends a final request for an RPT using their original ticket value and receives an RPT with sufficient authorization data to access the UMA protected resource.
8. The attacker gains access to the UMA protected resource using the RPT empowered with the victim's claims provided in (5).

To mitigate this attack, an UMA authorization server indicating its conformance to this extension through the identifying URI defined in Section 1.2 MUST do the following.

• The authorization server MUST select a new unguessable value for the permission ticket and invalidate the permission ticket previously received from the client every time it adds a ticket query parameter to the claims_redirect_uri after a claims-gathering flow at this security-enhanced endpoint. This extension supersedes the [UMA101] Section 3.2.2 requirement "Permission tickets MUST NOT be single-use" and the Section 3.6.3 phrase "The same permission ticket value that the client provided in the request...". Consequently, the ticket becomes a single-use nonce in both its front-channel and back-channel correlation roles. This ticket value rotation defeats the attacker's ability to compose a successful RPT request in step 7 of the attack described in Section 2.2.
• The client MUST read the new ticket value from the callback to its claims_redirect_uri and MUST discard the previous ticket value used in the request to the claims gathering endpoint.
• The client MUST use new ticket value for all future interactions with the authorization server, including the RPT endpoint and security enhanced claims gathering endpoint, until such time that its value is replaced again (such as by repeated calls to the security enhanced claims gathering endpoint).
• The client SHOULD use the state parameter to prevent other forms of attacks against its claims_redirect_uri endpoint, but use of the state parameter alone does not prevent the attack described in this specification.
• The authorization server MUST provide a configuration data property for an alternate requesting party claims endpoint in its configuration data called security_enhanced_claims_endpoint, with the URI for the endpoint as its value.
• The authorization server MUST replace any use of the originally specified requesting party claims endpoint with the security-enhanced requesting party claims endpoint for interacting with the end-user requesting party to gather claims. The authorization server MUST NOT provide a configuration data property for the requesting_party_claims_endpoint configuration data. Effectively, this extension supersedes the [UMA10] and [UMA101] Section 1.4 statement "If this property is absent, the authorization server does not interact with the end-user requesting party for claims gathering."