[OAUTH-WG] Comments on draft-ietf-oauth-security-topics-13

["Peck, Michael A" <[e-mail]>]

Thank you for writing this BCP. I believe it provides important guidance and support its publication.

I have the following comments on draft -13:

Overall:
The draft uses the term “adversary” (3 times) and the term “attacker” (>100 times). I suggest using one term consistently.

My understanding of the document structure is that Section 3 provides specific implementable recommendations up-front, while Section 4 describes in detail the threats that provide the rationale for those recommendations along with a discussion of various potential countermeasures and their tradeoffs. If that understanding is correct, I believe much of the specific recommendation text in the countermeasures sections (4.1.3, 4.2.4, 4.4.2, 4.5.3) would be a better fit in Section 3.

Section 3.5:
It is not clear to me how MTLS or “private_key_jwt” provide non-repudiation, or what it is that non-repudiation is being provided for. Could you explain or consider removing the non-repudiation discussion?

It is clear to me how MTLS enables use of sender-constrained access tokens. However it’s not clear to me how private_key_jwt does so – at least not without something like DPoP that hasn’t yet been finalized? 

Maybe change the text to something like “Additionally, MTLS enables use of sender-constrained access tokens (without requiring additional keys to be distributed).”?

Section 4.5:
“In such an attack, the adversary attempts to inject a stolen authorization code into a legitimate client on a device under his control.”

This text implies to me that the client is running on a device under the adversary’s control (but that the adversary presumably can’t directly control the client’s behavior)? But I think the intention is that the adversary is using a device/user agent under the adversary’s control to perform the code injection, not that the client is running on the adversary’s device? (e.g. previously discussed cut and paste attacks where the adversary has a session with the client and injects a stolen authorization code into that session)

If I’m understanding correctly how about text like “In such an attack, the adversary attempts to inject a stolen authorization code into the adversary’s own session with the client, in an attempt to associate the adversary’s session with the client to the victim’s resources or identity.”?

Section 4.5.1:
“The attacker obtains an authorization code by performing any of the attacks described above.”
Section 4.5 says “an attacker with advanced capabilities (A3-A5)” are out of scope, but would those advanced capabilities (e.g. A3 – ability to read the authorization response) potentially be useful to steal the authorization code? Should the text about attacker capabilities A3-A5 being out of scope be removed?

Section 4.5.3:
It may be worth noting that PKCE is verified by the authorization server, while the OpenID Connect nonce is verified by the client. There could be an argument to be made that authorization servers are more likely than clients to properly implement checks (e.g. the papers cited in section 4.8.1.1?), and so PKCE should be preferred. There could also be a defense-in-depth argument towards using both PKCE and nonce.

“PKCE is a deployed OAuth feature, even though it is used today to secure native apps only.”
That is not necessarily true anymore (the recommendations in this draft are already being adopted in other work such as FAPI). How about something like:
“PKCE is a deployed OAuth feature, although its original intended use was solely focused on securing native apps, not the broader use recommended by this document.”

Section 4.6:
Similar concerns about the “on a device under his control” text as expressed above for section 4.5.

Thanks,
Mike