Messages - 9.10 Also mention about cut&paste attack

[Nat Sakimura]

cut & paste attack is a kind of token substitution attack. It would be good to mention it here since it is so common in OAuth implementations.

Should it be in Standard by the way? It is mentioning HTTP, which is indicative of that it belongs to HTTP/OAuth binding, which is Standard.

[Michael Jones]

I need you to write the precise text that you want to appear and let me know which sections you want it to appear in. I don't understand this one well enough to be able to guess correctly what to say.

[Nat Sakimura]

Currently, i is:

9.10. Token Substitution

A user may attempt to impersonate a more privileged user by subverting the communication channel between the Token Endpoint and Client, for example by reordering the messages, to convince the Token Endpoint that his or her authorization grant corresponds to the grant sent on behalf of the more privileged user.

Responses to Token Requests are bound to the corresponding requests by message order in HTTP, as both token and requests are protected by TLS that can detect and disallow malicious reordering of packets.

Change to:

9.10. Token Substitution

Token Substitution is a class of attacks that a malicious user swaps various tokens including 'code' of the legitimate user with another token that he has previously obtained or is obtaining.

The implicit flow of OAuth 2.0 [RFC6749] is not designed to mitigate this risk and normatively requires the implementations that any specification that uses the authorization process as a form of delegated end-user authentication to the client MUST NOT use the implicit flow without additional security mechanisms that would enable the client to determine if the access token was issued for its use in Section 10.16 of [RFC6749].

In OpenID Connect, this is mitigated through the mechanisms provided by ID Token. ID Token is a signed token that provides such Claims as 'aud', 'azp', 'at_hash', and 'c_hash'. With this, the client is capable of detect the Token Substitution Attack.

Also, a malicious user may attempt to impersonate a more privileged user by subverting the communication channel between the Authorization Endpoint and Client, or the Token Endpoint and Client, for example by swapping the 'code' or reordering the messages, to convince the Token Endpoint that his or her authorization grant corresponds to the grant sent on behalf of the more privileged user.

For the attack that swaps the 'code', 'c_hash' in ID Token provides a mechanism to mitigate this risk.

For HTTP bindings such as OpenID Connect Standard, the responses to Token Requests are bound to the corresponding requests by message order in HTTP, as both token and requests are protected by TLS that can detect and disallow malicious reordering of packets.

When designing another binding of OpenID Connect Messages to a baseline protocol incapable of strongly binding the request to the token endpoint to the response, additional mechanism to address this issue MUST be defined. One such mechanism could be to include ID Token with c_hash in the token request and response.

[Nat Sakimura]

Propposed text added.

[Michael Jones]

I have update the wording to that proposed. I'll note that the new wording doesn't use the phrase "cut and paste" anywhere, so we might want to say that "The Token Substitution attack is also sometimes known as the "Cut and Paste" attack". Should we do that?

[Michael Jones]

Fixed #840 - Provided a better description of the Token Substitution attack.

→ <<cset e583f8ecf29c>>