[Unbearable] Comments on draft-ietf-oauth-token-binding-02 (OAuth 2.0 Token Binding)

[Denis <[e-mail]>]

Comments on draft-ietf-oauth-token-binding-02 (OAuth 2.0 Token Binding)

1) The abstract states:

             This use of Token Binding protects these tokens from 
man-in-the-middle and token export and replay attacks.


This is incorrect: the use of Token Binding does not protect these 
tokens from token export since this mechanism
is not resistant to the ABC attack (Alice and Bob collusion attack).

Replace with:

             This use of Token Binding protects these tokens from 
man-in-the-middle attacks.

2) The introduction states:

             This cryptographically binds these tokens to a client's 
Token Binding key pair, possession of which is proven on the TLS 
connections
             over which the tokens are intended to be used. This use of 
Token Binding protects these tokens from man-in-the-middle and token 
export and replay attacks.


The first sentence is correct while the second sentence is incorrect. 
The use of Token Binding does not protect these tokens from token export.
The mechanism is not resistant to the ABC attack (Alice and Bob 
collusion attack).

Replace with:

This cryptographically binds these tokens to a client's Token Binding 
key pair, possession of which is proven on the TLS connections
over which the tokens are intended to be used. This use of Token Binding 
protects these tokens from man-in-the-middle attacks
*but does not protect these tokens in case of collusions between clients*.

3) In section 4.2, the text states:

"This binding ensures that the authorization code cannot successfully be 
played or replayed to the web server client from a different browser
than the one that made the authorization request".

This is incorrect: the use of Token Binding does not protect these 
tokens in case of a collusion between web server clients, e.g. the ABC 
attack (Alice and Bob collusion attack).

Replace with:

"In case of a collusion between web server clients, the authorization 
code *can successfully be played* to the web server client from a 
different browser
than the one that made the authorization request ".

4) The whole content of section 7 (Security Considerations) is currently:

If a refresh request is received by the authorization server containing 
a Referred Token Binding ID and the refresh token in the request
is not itself token bound, then it is not clear that token binding the 
access token adds significant value. This situation should be considered
an open issue for discussion by the working group.

It is important to mention upfront that the mechanism is not resistant 
in case of a collusion between clients.


Add as a first paragraph, i.e.  before//the previous sentences, the two 
following sentences:

This mechanism protects these tokens from man-in-the-middle attacks, 
*but does not protect these bound tokens in case of a deliberate 
collusion between clients*.
A client may intentionally export a bound token with the corresponding 
Token Binding private key, or perform signatures using this key on 
behalf of another client.

Denis