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> >
- [Unbearable] (belated) WGLC draft-ietf-tokbind-tt… Leif Johansson
- Re: [Unbearable] (belated) WGLC draft-ietf-tokbin… Denis
- Re: [Unbearable] (belated) WGLC draft-ietf-tokbin… Hans Zandbelt
- Re: [Unbearable] (belated) WGLC draft-ietf-tokbin… Denis
- Re: [Unbearable] (belated) WGLC draft-ietf-tokbin… Andrei Popov
- Re: [Unbearable] (belated) WGLC draft-ietf-tokbin… Denis
- Re: [Unbearable] (belated) WGLC draft-ietf-tokbin… Andrei Popov
- Re: [Unbearable] (belated) WGLC draft-ietf-tokbin… Hans Zandbelt
- Re: [Unbearable] (belated) WGLC draft-ietf-tokbin… Brian Campbell