[Unbearable] A storm in a cup of tea (related to draft-ietf-tokbind-protocol-13)

Denis <denis.ietf@free.fr> Sun, 19 March 2017 18:42 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 36A47129519 for <unbearable@ietfa.amsl.com>; Sun, 19 Mar 2017 11:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.617
X-Spam-Level:
X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 lXVMMZl3C-3v for <unbearable@ietfa.amsl.com>; Sun, 19 Mar 2017 11:42:52 -0700 (PDT)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (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 36D94129513 for <unbearable@ietf.org>; Sun, 19 Mar 2017 11:42:52 -0700 (PDT)
Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id E1500780373 for <unbearable@ietf.org>; Sun, 19 Mar 2017 19:42:49 +0100 (CET)
From: Denis <denis.ietf@free.fr>
To: IETF Tokbind WG <unbearable@ietf.org>
Message-ID: <468011f3-258a-405e-c883-18739486661f@free.fr>
Date: Sun, 19 Mar 2017 19:42:48 +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="------------8175CABEC421F0178BF97F3C"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/uzIIES84rPtgP_IprEHcaSHWyH8>
Subject: [Unbearable] A storm in a cup of tea (related to draft-ietf-tokbind-protocol-13)
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: Sun, 19 Mar 2017 18:42:54 -0000

On February 27, I sent an email with the following topic: WGLC 3 on core 
documents.

    Comments on draft-ietf-tokbind-protocol-13 (The Token Binding
    Protocol Version 1.0)

    On page 14 within the Security Considerations section, I appreciate
    the fact that the following sentences have been added:

    *The Token Binding protocol does not prevent cooperating clients from*

    *sharing a bound token.A client could intentionally export a bound*

    *token with the corresponding Token Binding private key, or perform*

    *signatures using this key on behalf of another client.*

    However, these sentences have been placed inside section 7.1 which
    is called "Security Token Replay".
    This security consideration has nothing to do with "Security Token
    Replay" but with "Client collusion".

    Therefore, these sentences should be placed under a new section
    called: "7.2. Client collusion".

I was quite surprised to see that Leif Johansson reacted violently. He 
raised *a storm in a cup of tea*.

In any case, this threat does not belong to a subsection called 
"Security Token Replay" since there is no replay of any kind.

A separate section should be used to mention that attack.


*A spade should be called a spade*. Now, if Leif would like to call it 
differently, why not ?

For example, it could also be called "*Security Token Forwarding*"


Hence, up to now, I consider that this comment has not been solved to my 
satisfaction.


Denis