[WG-UMA] PKCE + Interactive Claims Gathering

[Alec L]

Hi,

We’ve had some requests to add PKCE [1] to the interactive claims gathering flow [2], eg example for public clients. Technically, there is little challenge to directly apply the PKCE code challenge/verifier, with the assumption that the authorization code is equivalent to the uma ticket

Has anyone done this? Any additional considerations?

Thanks,

- Alec

Alec Laws

647 822 1529

al...@identos.ca

[1] PKCE: https://tools.ietf.org/html/rfc7636

[2]  https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#claim-redirect

[Alec L]

Hi all, 

Following the PKCE discussion last week here's some proposed changes to the UMA implementers guide[1]. The guide already has a section addressing "Security Considerations Regarding Interactive Claims Gathering Flows" [2]. The change below changes the focus from only the Mix-Up Attack, and more generally recommends application of any relevant countermeasures from the OAuth BCP document (including use of PKCE)

Cheers,

- Alec

Existing Text:

```

When the requesting party is redirected to the authorization server for interactive claims gathering, a man in the middle/man in the browser can manipulate messages, impacting the claims_redirect_uri parameter (in what is called the Mix-Up attack in the case of a OAuth security analysis) and potentially more elements of the front-channel messages involved. The claims_redirect_uri parameter is similar to the OAuth redirect_uri parameter and some attacks may be able to be mitigated through approaches described in the OAuth Security Topics Internet-Draft (at revision 04 at the time of writing), Section 4.4. If the syntactic mitigation approach described is taken, the authorization server's redirection response back to the client would need to be extended with additional parameters as described in the OAuth 2.0 Mix-Up Mitigation Internet-Draft (at revision 01 at the time of writing). If the client-side mitigation approach described is taken, the client would have to perform a number of coordinating and tracking actions in addition to choosing authorization server-specific URLs. The client could additionally use the state parameter and choose a specific type of value that carries enough application state to enable it to match the value with its callback.

```

Proposed Text:

```

When the requesting party is redirected to the authorization server for interactive claims gathering, there are several possible attacks identified by the [OAuth 2.0 Security Best Current Practice](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14). The OAuth 2.0 authorization code flow is substantially similar to UMA interactive claims gathering: the claims_redirect_uri parameter is similar to the OAuth redirect_uri parameter, the incoming ticket is similar to OAuth scopes, and the returned ticket is similar to the OAuth authorization code; both flows require a client_id and recommend a state parameter. Therefore, these attacks can be mitigated through the countermeasures described in the [OAuth 2.0 Security Best Current Practice](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14). Two such attacks are Cross Site Request Forgery (Section 4.1), recommending application of PKCE, and the Mix-Up attack (Section 4.4), which has several possible mitigations. 

```

[1] https://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Guide

[2] https://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Guide#UMAImplementer'sGuide-front-channel-securitySecurityConsiderationsRegardingInteractiveClaimsGatheringFlows

[Eve Maler]

Thanks, Alec! This looks good. In addition to the callout to OAuth BCP, we also raised this question last week:

"The question might be about if we would want to use it if redirection is used for multiple claims-gathering cycles. Does it actually help in that case?"

Does our callout suffice for this concern?

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

_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
https://kantarainitiative.org/mailman/listinfo/wg-uma

[Alec L]

Ah interesting! I’ll make a statement and then immediately challenge it :)

There are no additional considerations for repeated ICG flows because it will always end with a call to the token endpoint, where the client must send the code verifier to be checked by the AS. If another ICG is required, the client should apply a new code challenge (and state etc) on the next redirect.

However… is that true? Since the client receives a new ticket on its claims_redirect_uri it _could_ immediately send the RqP back for another round of claims gathering before it calls the /token endpoint.

This is the only statement in UMA Grant (that I could find) that addresses _when_ the client will initiate ICG :

"The client might have initiated redirection immediately on receiving an initial permission ticket from the resource server, or, for example, in response to receiving a redirect_user hint in a need_info error (see Section 3.3.6).” [1]

- Alec

Alec Laws

647 822 1529

al...@identos.ca

[1] https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#claim-redirect

[Alec L]

Have made a start to updating the proposed PKCE blurb.. sharing for feedback

```

When the requesting party is redirected to the authorization server for interactive claims gathering, there are several possible attacks identified by the [OAuth 2.0 Security Best Current Practice](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14). The OAuth 2.0 authorization code flow is substantially similar to UMA interactive claims gathering: the claims_redirect_uri parameter is similar to the OAuth redirect_uri parameter, the incoming ticket is similar to OAuth scopes, and the returned ticket is similar to the OAuth authorization code; both flows require a client_id and recommend a state parameter. Therefore, these attacks can be mitigated through the countermeasures described in the [OAuth 2.0 Security Best Current Practice](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14). Two such attacks are Cross Site Request Forgery (Section 4.1), recommending application of PKCE, and the Mix-Up attack (Section 4.4), which has several possible mitigations. 

One UMA specific consideration is the repeated invocation of interactive claims gathering redirection before use of the token endpoint. This is possible since each ICG results in a new uma ticket to be given to the client. This possibility requires UMA analysis and profiling of PKCE to ensure it's still effectively providing the client authentication required. Another potential mechanism to mitigate these attacks on redirection flow is application of client DPOP, where instead of a PKCE code challenge/verifier, the client is registered with a public key, possibly through DCR, and dynamic client authentication is the required at the token endpoint. Another direct mitigation is for the AS profile to explictly require calls to the token endpoint with an uma ticket received through ICG redirection, this ensures that PKCE is applied as designed. 

```

-Alec