Re: [WG-UMA] PKCE + Interactive Claims Gathering

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 alec@identos.ca [1] https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#claim... https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#claim...

On Aug 13, 2020, at 12:09 PM, Eve Maler wrote:

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

On Thu, Aug 13, 2020 at 9:44 AM Alec L mailto:alec@identos.ca> wrote:

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 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 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+Gui... https://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Gui... [2] https://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Guide#UMAImplementer'sGuide-front-channel-securitySecurityConsiderationsRegardingInteractiveClaimsGatheringFlows https://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Guide#UMAImplementer'sGuide-front-channel-securitySecurityConsiderationsRegardingInteractiveClaimsGatheringFlows

Alec Laws 647 822 1529 alec@identos.ca mailto:alec@identos.ca

...

On Jul 30, 2020, at 2:42 PM, Alec L mailto:alec@identos.ca> wrote:

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 alec@identos.ca mailto:alec@identos.ca

[1] PKCE: https://tools.ietf.org/html/rfc7636 https://tools.ietf.org/html/rfc7636 [2] https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#claim... https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#claim...

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