CIBA - Make clear limitation of binding message

[Dave Tonge]

As raised by Pedram and Tim - there are still attacks possible even when a binding message is used (with an attacker controlled client). We should add this to the security considerations.

[Nat Sakimura]

Text needed for security considerations re: binding messages.

[Tim Würtele]

For reference, this is the (simplified) attack flow:

‌

See the Cross-Device Flow BCP for possible mitigations (e.g., establishing physical proximity).

Note: The malicious client never acts as a client towards an AS, RS, or any other client. Hence, even a “closed” ecosystem w.r.t. clients might be susceptible to such an attack. Furthermore, this allows the malicious client to just copy name, branding etc. of an honest client - i.e., in most real-world setups, where the user gets shown an app/client name and logo in Step 7, the user cannot detect the attack.

For the formal security analysis, we excluded this type of attack by assuming that the user can uniquely identify the client they received the binding message from (and can thus compare that to the client identity shown by the AS in Step 7 along with the binding message). I.e., we assumed an authenticated channel for the binding message. This corresponds to what the mitigations in the Cross-Device Flow BCP try to achieve.

‌

[Nat Sakimura]

It is a bit unfortunate that the https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/ is still -04 that I am not sure if it is a good idea to reference it, but perhaps just as FYI?

[Nat Sakimura]

In the call on Nov. 1, we discussed that we should refer to the draft pointing out that we are discussing the concept referred to such and such in -04 and readers should look for the comparable section in the most current document.