Comments on draft-ietf-oauth-token-binding-05

Comments have been posted on draft-ietf-oauth-token-binding-02 (OAuth 2.0 Token Binding)
and as far as I know have not received any feedback.
See: https://www.ietf.org/mail-archive/web/unbearable/current/msg01316.html

Hereafter is an update of the same comments applied to draft-ietf-oauth-token-binding-05.

1) The abstract states:

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

The use of Token Binding does not protect these tokens from token export in case of collusion between clients 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 and token export and replay attacks but does not protect against token export in case of collusion performed by clients.

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 mechanism is not resistant to the ABC attack (Alice and Bob collusion attack).See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html

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, token export and replay attacks but does not protect these tokens in case of collusion
performed by 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).

Add afterwards:

"However, in case of 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) Section 7 (Security Considerations) includes the following two subsections:

7.1.Phasing in Token Binding

7.2.Binding of Refresh Tokens


It is important to mention that the mechanism is not resistant in case of a collusion between clients.
Add a subsection with the following text:

7.3.Collusion attacks performed by clients

This mechanism 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 and then transmit both the bound token and the results to the other client.

Denis


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

         Title           : OAuth 2.0 Token Binding
         Authors         : Michael B. Jones
                           Brian Campbell
                           John Bradley
                           William Denniss
        Filename        : draft-ietf-oauth-token-binding-05.txt
        Pages           : 30
        Date            : 2017-10-26

Abstract:
    This specification enables OAuth 2.0 implementations to apply Token
    Binding to Access Tokens, Authorization Codes, Refresh Tokens, JWT
    Authorization Grants, and JWT Client Authentication.  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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-token-binding-05
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-binding-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-binding-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to