Re: [Unbearable] (belated) WGLC draft-ietf-tokbind-ttrp

Denis <denis.ietf@free.fr> Mon, 17 September 2018 18:23 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 B8744130E80 for <unbearable@ietfa.amsl.com>; Mon, 17 Sep 2018 11:23:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.524
X-Spam-Level:
X-Spam-Status: No, score=0.524 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, URI_HEX=1.122] autolearn=no 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 bv3gCgc-PSg1 for <unbearable@ietfa.amsl.com>; Mon, 17 Sep 2018 11:23:06 -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 EC345130EB8 for <unbearable@ietf.org>; Mon, 17 Sep 2018 11:23:05 -0700 (PDT)
Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 42E22780398 for <unbearable@ietf.org>; Mon, 17 Sep 2018 20:23:04 +0200 (CEST)
To: Tokbind WG <unbearable@ietf.org>
References: <bba419c9-103b-5cb0-4267-c5cec9c7b3dd@sunet.se> <6bea7c7b-80ec-9637-324e-730998c461ad@free.fr> <CA+iA6uh5rjoU-AUdOzt-kJkgo3MshZndu7RL59M-kWjx-ckzbw@mail.gmail.com> <93c77c77-9dfe-fe0b-4b3a-319c9dc7ec8e@free.fr> <CY4PR21MB0774438584D60A8033A94EF18C1E0@CY4PR21MB0774.namprd21.prod.outlook.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <3f7c20ed-26c1-3070-207b-54e97b1dc516@free.fr>
Date: Mon, 17 Sep 2018 20:23:07 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CY4PR21MB0774438584D60A8033A94EF18C1E0@CY4PR21MB0774.namprd21.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------4A881E1BFC15729E3F6F52F7"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/jJFSlB4WmEtutzCUJoLWEjKxT9E>
Subject: Re: [Unbearable] (belated) WGLC draft-ietf-tokbind-ttrp
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.29
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, 17 Sep 2018 18:23:12 -0000

Hi Andrei,

Such a sentence is present in draft-ietf-tokbind-protocol-19 (The Token 
Binding Protocol Version 1.0), but not
in draft-ietf-tokbind-ttrp-06: HTTPS Token Binding with TLS Terminating 
Reverse Proxies.

Denis

> Hi Denis,
>
> IMHO this is already addressed in the security considerations:
>
> “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.”
>
> Cheers,
>
> Andrei
>
> *From:*Unbearable <unbearable-bounces@ietf.org> *On Behalf Of *Denis
> *Sent:* Monday, September 17, 2018 3:43 AM
> *To:* Hans Zandbelt <hans.zandbelt@zmartzone.eu>
> *Cc:* Tokbind WG <unbearable@ietf.org>
> *Subject:* Re: [Unbearable] (belated) WGLC draft-ietf-tokbind-ttrp
>
> Hans,
>
> This has nothing to do with "private key sharing". Private keys are 
> usually protected by some hardware device which does not allow to 
> export these keys.
> However, a legitimate user can *use* his hardware device which means 
> that he can ask to his device to perform some cryptographic 
> computation with the private keys
> that are stored in it.
>
> In the past, when doing a threat analysis, only external attackers 
> were being considered. Collaborative attacks is a different kind of 
> threat that should also be considered.
> However, it only applies to some specific contexts:
>
>     If the security token contains a sufficient number of attributes
>     that allows to fully identify the bearer, the bearer will probably
>     refuse to collaborate with anybody else,
>     because that other body could fully impersonate him.
>
>     If the security token contains one or more attributes that do not
>     allow to fully identify the bearer, the bearer may accept to
>     collaborate with somebody else, because
>     he cannot be identified. Typical examples of such an attribute
>     are: "over 18" or "resident of Florida". Such attributes may allow
>     to access to a service.
>
> Any solution using software only is unable to counter collaborative 
> attacks. Any solution using hardware devices that are only protecting 
> the private keys, /but not their usage/,
> are also unable to counter collaborative attacks. The topic has 
> nothing to do with generic PKI principles and guidelines. However, 
> adding some additional explanations into
> the security considerations section along those provided above could 
> be useful.
>
> Denis
>
>     Can we please stop adding text that says "don't share your private
>     key with others" to IETF drafts? That is an inherent part of PKI
>     and does not need to be repeated everywhere IMO, just like text
>     about how verifying TLS server certificate should work is not
>     repeated in drafts where TLS is a requirement. Perhaps a reference
>     to generic PKI principles and guidelines may be included?
>
>     Hans.
>
>     On Mon, Sep 17, 2018 at 11:32 AM Denis <denis.ietf@free.fr
>     <mailto:denis.ietf@free.fr>> wrote:
>
>         Comments on draft-ietf-tokbind-ttrp-06: HTTPS Token Binding
>         with TLS Terminating Reverse Proxies
>
>         The introduction states:
>
>             An HTTP server issuing cookies or other security tokens
>             can associate them with the Token Binding ID, which
>             ensures those tokens
>             cannot be used successfully over a different TLS
>             connection or by a different client than the one to which
>             they were issued.
>
>         When there are only external attackers, the sentence is
>         correct but is incorrect when there is a collusion between a
>         legitimate client and another client.
>         The sentence should be corrected. Here is a proposal:
>
>             An HTTP server issuing cookies or other security tokens
>             can associate them with the Token Binding ID, which
>             ensures those tokens
>             cannot be used successfully over a different TLS
>             connection or by a different client than the one to which
>             they were issued, as long as
>             there is no collusion between the legitimate client and
>             another client.
>
>         In the "Security Considerations" section (section 4), some
>         explanations should be added. Here is a proposal:
>
>             The token binding mechanism is efficient against external
>             attackers, but, in case a legitimate client collaborates
>             with another client,
>             the mechanism can be defeated since the legitimate client,
>             using the private key which proves possession of the
>             security token, can perform
>             all the cryptographic computations that the other client
>             needs to demonstrate the possession of that security token.
>
>         Denis
>
>             This message marks the start of a 2 week WGLC on
>
>             draft-ietf-tokbind-ttrp-06 as agreed in Montreal but only now effected
>
>             by your chair.
>
>             Please provide your final comments, voices of support or objections
>
>             by COB Fri 28 Sept in any TZ.
>
>               Best R
>
>               Leif
>
>             _______________________________________________
>
>             Unbearable mailing list
>
>             Unbearable@ietf.org <mailto:Unbearable@ietf.org>
>
>             https://www.ietf.org/mailman/listinfo/unbearable
>             <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Funbearable&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C0f190bc7a19c4c92014f08d61c8a6cdd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636727778196060990&sdata=wp0JA58IzQoYFIB0QVMNtyWSjiAhAJr8EHGvXs1fwLc%3D&reserved=0>
>
>         _______________________________________________
>         Unbearable mailing list
>         Unbearable@ietf.org <mailto:Unbearable@ietf.org>
>         https://www.ietf.org/mailman/listinfo/unbearable
>         <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Funbearable&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C0f190bc7a19c4c92014f08d61c8a6cdd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636727778196071002&sdata=CFnNEkHXp9X1RnN9HJij32YLB3IS3NQJ%2FJveXArXOp4%3D&reserved=0>
>
>
>     -- 
>
>     hans.zandbelt@zmartzone.eu <mailto:hans.zandbelt@zmartzone.eu>
>
>     ZmartZone IAM - www.zmartzone.eu
>     <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.zmartzone.eu&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C0f190bc7a19c4c92014f08d61c8a6cdd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636727778196081011&sdata=30pxo8BATC47jY8%2FM6%2FIK4J84FKsoGYGv776w%2FKboJ0%3D&reserved=0>
>