PKCE + request object signature as recommeded option

[Giovanni Bartolomeo]

Hi All,

two attacks you may be already aware of.

• If you don't use PKCE you can get a trivial code injection. Nonce does not protect as the attacker can copy it from the Authz request (unless you don't encrypt the Authz request).
• If you don't use request object signature, Authz req can be injected of several parameters, including PKCE (attack described in https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ and referred as "Stronger attacker model").

Therefore, according to our analysis, the only smoothly working pattern is to use PKCE in conjection with request object signature. Can we recommend this solution in the specs?

Note that there is a caveat however, the signature should be computed on the whole set of parameters. Pre-cached signatures (as described in https://openid.net/specs/openid-connect-core-1_0.html#RequestObject)) won't work and exposes to the second attack above.

[Tom Clancy]

Agreed. Specifying PKCE with S256 as the code challenge method appears to address this (since BCP-13). That is the requirement in FAPI 2.0 baseline and MITRE profiles, although MITRE further specifies parameter and value:

FAPI 2.0 [2.2.2] Clients … 5. shall use PKCE [RFC7636] with S256 as the code challenge method

MITRE [2.2.2] Public clients MUST, and confidential clients SHOULD, in compliance with [RFC7636] using the S256 code challenge method, include the code_challenge parameter and code_challenge_method (set to "S256") in the authorization request.

Is there an available mitigation to address the second part of the attack, or should we split this issue pending resolution?

[Tom Clancy]

For discussion:
Add “AS/OP MUST NOT pre-cache signatures” or “MUST use request object signatures”?
Is this a mitigation for the Stonger Attacker attack?
Is such a requirement implementable?

[Tom Clancy]

Changed to BLOCKER to filter for v1.05/Implementer’s draft.

[Tom Clancy]

Partially resolved in PR#25
https://bitbucket.org/openid/igov/pull-requests/25

[Kelley Burgin]

In regards to the need for request object signatures, the “stronger attacker model” assumes the attacker can inject the authorization request and read the authorization response.

[Kelley Burgin]

Consider adding a pushed authz endpoint and requiring PAR as FAPI 2.0 does

[Kelley Burgin]

Concern: PAR implementations may be less common that signed authz requests

[Tom Clancy]

PR#25 adds Stronger Attacker Model to Security Considerations as well as the reference to Daniel's blog post "SAM"\ Mitigation described, but not required due to lack of implementation.
openid / igov / Pull Request #25: issue-#49-make-pkce-mandatory-for-all-clients-and-configure — Bitbucket
Close after merge

[Tom Clancy]

Added Stronger Attacker text to Security Considerations: Ready to merge once approved