[Unbearable] Comments on draft-ietf-oauth-token-binding-02 (OAuth 2.0 Token Binding)
Denis <denis.ietf@free.fr> Mon, 20 March 2017 07:49 UTC
Return-Path: <denis.ietf@free.fr>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D453E1296BB for <unbearable@ietfa.amsl.com>; Mon, 20 Mar 2017 00:49:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKUj8te8agnN for <unbearable@ietfa.amsl.com>; Mon, 20 Mar 2017 00:49:40 -0700 (PDT)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 371B61200C1 for <unbearable@ietf.org>; Mon, 20 Mar 2017 00:49:40 -0700 (PDT)
Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 7C5D77803AD for <unbearable@ietf.org>; Mon, 20 Mar 2017 08:49:37 +0100 (CET)
To: IETF Tokbind WG <unbearable@ietf.org>
From: Denis <denis.ietf@free.fr>
Message-ID: <17c7af5f-0f42-1431-8c28-94e8fdc1486e@free.fr>
Date: Mon, 20 Mar 2017 08:49:37 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------D8888E3D02494CE6794C9C67"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/nuhRddd9TdzeSK5akvO331-l-Rs>
Subject: [Unbearable] Comments on draft-ietf-oauth-token-binding-02 (OAuth 2.0 Token Binding)
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Mar 2017 07:49:43 -0000
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