DPoP, PAR and Authorization Code binding

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2022-06-24

I have a few questions about DPoP and PAR In FAPI 2

The DPoP spec says this:

Both mechanisms (proof in header or dpop_jkt in body) MUST be supported by an authorization server that supports PAR and DPoP. If both mechanisms are used at the same time, the authorization server MUST reject the request if the JWK Thumbprint in dpop_jkt does not match the public key in the DPoP header.

Do we need to call this out in the FAPI 2.0 spec as I feel it could be missed as we only refer to DPoP as a mechanism for sender-constraining tokens. Whereas it looks like an AS has a requirement to implement DPoP at the PAR endpoint also in order to bind authorization codes.

My reading of the DPoP spec is that this is optional for Clients. Are we happy with this, or should we make it mandatory for Clients?

The DPoP spec says

Use of the dpop_jkt authorization request parameter is OPTIONAL. Note that the dpop_jkt authorization request parameter MAY also be used in combination with PKCE [RFC7636], which is recommended by [I-D.ietf-oauth-security-topics] as a countermeasure to authorization code injection.

‌

‌

---

Bitbucket status: resolved

Bitbucket origin: issue 503

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2022-06-29

Discussed in June 29 call.

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2022-06-29

Discussed a bit on today’s call.

Brian didn’t believe it would add an benefit to require clients to send it (in the FAPI use case of a confidential client with asymmetric authentication).

The conformance tests should try sending valid values (as well as not sending it) as clients may send.

Technically servers are required to support it so we could do negative conformance tests as well; as the most valuable test would consume an authorization code it’s an “expensive” test (when testing banks, the tester generally has to go through MFA authentication for every attempt to obtain an authorization code, and the authorization code may be consumed by a negative test). I wasn’t sure there was enough value to justify that extra hassle for testers.

[bitbucket-import-issues]

Originally submitted by Brian Campbell (Brian Campbell) on 2022-06-29

I’d lean towards not calling it out in FAPI2. It’s subjective but where do you draw the line between repeating or noting specifics of referenced specs and just referencing them?

Also lean towards keeping it optional for Clients. In FAPI2 clients are using asymmetric client auth and PKCE so I don’t think DPoP binding authorization codes adds enough to justify requiring it.

‌

‌

[bitbucket-import-issues]

Originally submitted by Daniel Fett (Daniel Fett) on 2022-06-29

I agree that we should not require it. I would just not mention it in FAPI2.

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2022-06-30

I’m happy to not mention it, but I suppose we will still need AS tests

[bitbucket-import-issues]

Originally submitted by panva (Filip Skokan) on 2022-06-30

FWIW I wrote up a number of testable cases a month ago in the conformance suite tracker https://gitlab.com/openid/conformance-suite/-/issues/1038

[bitbucket-import-issues]

Originally submitted by panva (Filip Skokan) on 2022-06-30

I’d lean towards not calling it out in FAPI2. It’s subjective but where do you draw the line between repeating or noting specifics of referenced specs and just referencing them?

We decided to go the other way for dpop-nonce.

I’m fine either way, but applied to both dpop_jkt and dpop-nonce provisions consistently.

‌

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2022-07-06

For DPoP-nonce we added a requirement for Clients to support this to aid interoperability - it wasn’t a clear requirement in the main DPoP text for Clients to support the nonce, although it is implied.

In this scenario, there is already a clear requirement for the AS to support both approaches, so I’m happy to not call it out.

[bitbucket-import-issues]

Originally submitted by Pieter Kasselman (Pieter Kasselman) on 2022-07-13

Including the DPoP nonce mitigates against proof pre-computation attacks and also removes the need for clock synchronisation (which can be tricky at scale with mobile devices).

The dpop_jkt authorization request parameter is used to prevent an authorization code re-binding attack. The typical vector for this is attackers accessing log files (e.g. the authorization code ends up in a log file and gets exfiltrated/re-used and the attacker binds their own DPoP key to it). There is a couple of variations of this, including cases where the PKCE code verifier gets harvested along with the Authorization Code from a log file.

How is the rebinding attack avoided when using PAR, with asymmetric client authentication (i.e. can the authorization code only be used by the same client to whom the authorization code was issued)?

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2022-07-14

Thanks for the explanation Pieter!

How is the rebinding attack avoided when using PAR, with asymmetric client authentication (i.e. can the authorization code only be used by the same client to whom the authorization code was issued)?

Yes, the authorization code is only usable by the client that it was issued to. (The FAPI conformance tests confirm this mechanism is implemented by attempting to use an authorization code with a different client.)

If I understand that attack vector correctly, this isn’t necessarily sufficient to prevent that attack if using private_key_jwt and the client authentication assertion was put in the log file and accessed by the attacker, though perhaps I’ve not understood which log file is being talked about?

I think our current attacker model assumes the PKCE code verifier can’t be harvested though, is that harvesting method applicable to confidential clients?

I think, with the attacker assumptions you’re making, dpop_jkt may provide extra protection in the FAPI case, at least when considered a per-instance registered confidential client on a mobile device.