From nobody Fri May 5 13:25:41 2017 Return-Path: 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 25AE2128BB6 for ; Fri, 5 May 2017 13:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Z39u8yTeorho for ; Fri, 5 May 2017 13:25:38 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6451F124217 for ; Fri, 5 May 2017 13:25:38 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id j1so9304421lfh.2 for ; Fri, 05 May 2017 13:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jrToIZ7lR3lAdaRoxga1jg4GitgLMEucTolRPu8mVbA=; b=DiL78wIx/PWHHV+AYspE6i5szUy318gk/kkLELzo9o1fADZxfW4H89Q4157int8UcJ dSF0j+62Ja/Y/64BXEWh9BOMd8O96icvk6Vl1szIFkMzDlDNitVgIgeyVu7UZsbUbyKe 69yZZTVnP3UAekvyoJWbXOCKhr6zo0AKTlm/OI7FVQJRKp4GjMxrh56/7IL8krzyBxcm H7mbLhknh34sZPJ5mIeVK3p7S23OGRNAm18Aww8hweGdD4QXOWAScrqc0ApQDxG3us6H EN1ilTCeqVFg5K9LvrbRDsO+N6u7S+YnFneWQM0seXDsXNFfEUUyi+7p4yCwrd0OyZFB nH+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jrToIZ7lR3lAdaRoxga1jg4GitgLMEucTolRPu8mVbA=; b=G6Iw46Mn1cy9gV5SuE+QOL+amJ3s/fBqAQgi9l7pYtOlinGZilykhrYQEJj/Nx75ux e0nbG4MjtDqdWQ8hzFzPOqdhOk3KfBQT+YBrTZgpVqRa+i5jGlPRdnUmVm3B0tnxbDHH gb2oA9up8WHj0XneTZ1ePH3v5FzpZLLAON8GBkkjW+Wl6rQqSLdMDtssGOKT4eVQYTsK lO3vNT1Vw4Qk2yUuCAFbO0DjsWPnASVfBqO09Ov4p5DBhiRZuZrEb1pGyZllNBl/+kvx dep0qFX5nW0NimkJHANq9DQSp5eeTLbYjHp/MJPpL6YDcezPwqeHJFFso1lyCittZdti W7+w== X-Gm-Message-State: AODbwcBqaOyOltrfP9jP5B7jxU+jCOWRUT0Bqt3FNUDbZdw/q6EnX489 O9nu/QBrCQYxfYxQkbo3V0Yyp9spCNeE6B6DQg== X-Received: by 10.25.193.193 with SMTP id r184mr2365565lff.125.1494015936436; Fri, 05 May 2017 13:25:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.150.149 with HTTP; Fri, 5 May 2017 13:25:15 -0700 (PDT) In-Reply-To: <20170428021355.GY30306@kduck.kaduk.org> References: <20170420020846.GY30306@kduck.kaduk.org> <20170428021355.GY30306@kduck.kaduk.org> From: Nick Harper Date: Fri, 5 May 2017 13:25:15 -0700 Message-ID: To: Benjamin Kaduk Cc: Andrei Popov , IETF Tokbind WG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Unbearable] Switching exporters for 0-RTT 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 20:25:40 -0000 It sounds like the consensus on this thread is that 0-RTT TB should use the 0-RTT exporter for the whole connection - switching exporters adds complexity, and no use cases have been identified where it provides extra value. I will update the draft to have it not switch exporters. Once I make the language change around switching exporters and also resolve the 4 issues currently open on https://github.com/nharper/0-rtt-token-binding/issues, I'll upload a new I-D. On Thu, Apr 27, 2017 at 7:13 PM, Benjamin Kaduk wrote: > On Thu, Apr 27, 2017 at 10:46:18PM +0000, Andrei Popov wrote: >> If one is willing to do TB without POP, then one will probably appreciate a simpler way to do this, with fewer moving parts and less room for interop issues. (IMHO, the value of TB without POP approaches zero, but that's a separate discussion.) >> >> The extra complexity of upgrading to secure TB after a bound token and associated application message(s) have been accepted and processed does not increase security in the common use-cases that I can think of. > > One could perhaps concoct a case where the application layer agrees > to only send certain mundane stuff over 0-RTT but for some reason > still wants TB for it. (That is not intended to be a compelling > argument.) > > But in general, I agree with Andrei (especially with the parenthetical). > > In particular, all these discussions of how once you've accepted > 0-RTT TB it doesn't make sense to try to upgrade to 1-RTT are just > serving to cement my feeling that doing 0-RTT TB is a bad idea. So, > to answer Nick's question, I have no interest in implementing 0-RTT > Token Binding, and thus don't have a use case in mind that would > make me only implement (2). :) > > -Ben From nobody Sat May 6 11:04:43 2017 Return-Path: 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 4F0361200F3 for ; Sat, 6 May 2017 11:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 ChTprQII5aof for ; Sat, 6 May 2017 11:04:39 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 B5828124234 for ; Sat, 6 May 2017 11:04:39 -0700 (PDT) X-AuditID: 12074423-bcfff7000000141a-7b-590e10354cd4 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 0A.25.05146.5301E095; Sat, 6 May 2017 14:04:37 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v46I4aiY031269; Sat, 6 May 2017 14:04:36 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v46I4Vcs025743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 6 May 2017 14:04:34 -0400 Date: Sat, 6 May 2017 13:04:32 -0500 From: Benjamin Kaduk To: Nick Harper Cc: Andrei Popov , IETF Tokbind WG Message-ID: <20170506180431.GY30306@kduck.kaduk.org> References: <20170420020846.GY30306@kduck.kaduk.org> <20170428021355.GY30306@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixCmqrGsqwBdpsHmLisWPSTOYLfp37GO0 OPd4IZMDs8eCTaUeS5b8ZPJo3fGXPYA5issmJTUnsyy1SN8ugStj0YSZrAUT2Co+bw9vYPzI 0sXIySEhYCLxftFM1i5GLg4hgcVMElc+HQZLCAlsYJS4cC8PInGFSeLwlAvsIAkWARWJp/87 GEFsNiC7ofsyM4gtAmTPv3qdFcRmFoiVaNnUCFYjLOAq8ejyWTCbF2jbmzVroba1M0ucuXGa CSIhKHFy5hMWiGYtiRv/XgLFOYBsaYnl/zhAwpwCgRJ3tq0Au0FUQFmiYcYD5gmMArOQdM9C 0j0LoXsBI/MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXTO93MwSvdSU0k2MoLBld1Hewfiyz/sQ owAHoxIP7wFWvkgh1sSy4srcQ4ySHExKorxpojyRQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4 n3MDlfOmJFZWpRblw6SkOViUxHnFNRojhATSE0tSs1NTC1KLYLIyHBxKErwS/ECNgkWp6akV aZk5JQhpJg5OkOE8QMP9+ECGFxck5hZnpkPkTzHqcsy59/U9kxBLXn5eqpQ4bwxIkQBIUUZp HtwcULqRyN5f84pRHOgtYd7DIFU8wFQFN+kV0BImoCXRIN/xFpckIqSkGhgDtAsOJv/lvDlV 08lJXPti6DPXk5q5G5nlFqp77Gj4ectOIbJ89b2DoTl1pztqjFjTlb+dCHKZxL3jYdT7Mo3l r+3NP7B3vmB/uzSN4cbJuKVLTx3f8z01WHzFraInvGsm+LB9zu1Xdmhrsnz/g5NtomYI2wQ3 IZul5+0alpbeEzm94t3sbblKLMUZiYZazEXFiQCQjBEMEgMAAA== Archived-At: Subject: Re: [Unbearable] Switching exporters for 0-RTT 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 18:04:41 -0000 On Fri, May 05, 2017 at 01:25:15PM -0700, Nick Harper wrote: > It sounds like the consensus on this thread is that 0-RTT TB should > use the 0-RTT exporter for the whole connection - switching exporters > adds complexity, and no use cases have been identified where it > provides extra value. I will update the draft to have it not switch > exporters. Once I make the language change around switching exporters > and also resolve the 4 issues currently open on > https://github.com/nharper/0-rtt-token-binding/issues, I'll upload a > new I-D. This is not the list for the WG of which I'm chair, so it is not my call to make, but I would worry that there was insufficient input in the thread from which to make a claim of consensus. Chairs, am I in the woods? -Ben From nobody Sat May 6 21:06:45 2017 Return-Path: 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 83D781242EA for ; Sat, 6 May 2017 21:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 PHH4ILiDO-L4 for ; Sat, 6 May 2017 21:06:42 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7D91205F0 for ; Sat, 6 May 2017 21:06:42 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id b68so17495547ywe.3 for ; Sat, 06 May 2017 21:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+0J33aYGxQ5S4G5JnoBaNxkD97H6YvtdxYHsCNS12kU=; b=Tb+OvXqQtcm4v68LKmpbj6mHUinWwB7BLXS2Z4d6ozFWqKqIitHDhztqk5UGIT7c+g oFShactVv0JX/tO6KgsQrZwO0n8MEPsQ6bskq2LFenL6xoGTziJZ7TtBUDif0a5zmlJg GJNmrF5esk/J7PdXXewC0BcHf51BemLZU2OsEUZYjL+ivs2JN9ku+yK6EdE+UdErVW0f BaOeKhdfRRsYM7x3ghaH2JJzgT/3e0HrRfPjXt+rT469Pcz0M+wxbvkyYBVAZlGSBsdO 2/3znoJnM39cG4oP9NXIi6/1+Kc3cJlOabCDG+fI3zT1zfCjqy49u7iQmJuZkYuntTR7 dJtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+0J33aYGxQ5S4G5JnoBaNxkD97H6YvtdxYHsCNS12kU=; b=uflCfKa9bEnoVjK4xeXrBQVaAlseH5A89rf+xER96TvFk742k9t5kH3Pr77D4G7Udm KzD28cxEpbUP/dtbmWiOFzzuXQECJJ+tdbyaOFrHsbVdf3IarqRt826OZMTL2lrCspe8 fnsM/ay4M0RQ3TGrlecPYXseUayrSjVmGYdz/bdrRLCQU8wveAbyHgzgPK+sHaUpBsav DiDKq8Iq11yBnVTjA33wtXDo3VuXZxuRxRU/j1je8x8UQTaiXCJnDYXx1c95iF4OqIeM AzesfOyhhJ23Z2Dpl4KCSbIDXvpS9MktoTBNK94Vmt4WeNZ1HyRJ476oU+Isr0v2EJSE 9yTg== X-Gm-Message-State: AN3rC/52hecydDcVwrHcUN8I58Wvq7vgA/mOKv402aovAcpWWkJEWBhG vb1pHMdFLa8aJUWxMAG5f004myrPWf+t X-Received: by 10.129.93.65 with SMTP id r62mr44815158ywb.95.1494130001492; Sat, 06 May 2017 21:06:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.222.70 with HTTP; Sat, 6 May 2017 21:06:41 -0700 (PDT) In-Reply-To: <20170506180431.GY30306@kduck.kaduk.org> References: <20170420020846.GY30306@kduck.kaduk.org> <20170428021355.GY30306@kduck.kaduk.org> <20170506180431.GY30306@kduck.kaduk.org> From: Bill Cox Date: Sat, 6 May 2017 21:06:41 -0700 Message-ID: To: Benjamin Kaduk Cc: Nick Harper , Andrei Popov , IETF Tokbind WG Content-Type: multipart/alternative; boundary=001a114d9c7afd11f4054ee73f34 Archived-At: Subject: Re: [Unbearable] Switching exporters for 0-RTT 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 04:06:44 -0000 --001a114d9c7afd11f4054ee73f34 Content-Type: text/plain; charset=UTF-8 Sticking with the original EKM makes a lot of sense to me. Is anyone proposing sending 0-RTT data that is poorly protected, and then later sending 1-RTT data that is better protected? Does anyone feel that is a good idea? I hope not, in which case, sticking with the original EMK makes sense. +1 for sticking with the original EKM value. Bill On Sat, May 6, 2017 at 11:04 AM, Benjamin Kaduk wrote: > On Fri, May 05, 2017 at 01:25:15PM -0700, Nick Harper wrote: > > It sounds like the consensus on this thread is that 0-RTT TB should > > use the 0-RTT exporter for the whole connection - switching exporters > > adds complexity, and no use cases have been identified where it > > provides extra value. I will update the draft to have it not switch > > exporters. Once I make the language change around switching exporters > > and also resolve the 4 issues currently open on > > https://github.com/nharper/0-rtt-token-binding/issues, I'll upload a > > new I-D. > > This is not the list for the WG of which I'm chair, so it is not my > call to make, but I would worry that there was insufficient input in > the thread from which to make a claim of consensus. > > Chairs, am I in the woods? > > -Ben > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a114d9c7afd11f4054ee73f34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sticking with the original EKM makes a lot of sense to me.= =C2=A0 Is anyone proposing sending 0-RTT data that is poorly protected, and= then later sending 1-RTT data that is better protected?=C2=A0 Does anyone = feel that is a good idea?=C2=A0 I hope not, in which case, sticking with th= e original EMK makes sense.

+1 for sticking with the ori= ginal EKM value.

Bill

On Sat, May 6, 2017 at 11:04 AM, B= enjamin Kaduk <kaduk@mit.edu> wrote:
On Fri, May 05, 2017 at 01:25:15PM -0700, Nick Harp= er wrote:
> It sounds like the consensus on this thread is that 0-RTT TB should > use the 0-RTT exporter for the whole connection - switching exporters<= br> > adds complexity, and no use cases have been identified where it
> provides extra value. I will update the draft to have it not switch > exporters. Once I make the language change around switching exporters<= br> > and also resolve the 4 issues currently open on
> https://github.com/nharper/0-rtt-tok= en-binding/issues, I'll upload a
> new I-D.

This is not the list for the WG of which I'm chair, so it is not= my
call to make, but I would worry that there was insufficient input in
the thread from which to make a claim of consensus.

Chairs, am I in the woods?

-Ben

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearabl= e

--001a114d9c7afd11f4054ee73f34-- From nobody Wed May 31 10:03:47 2017 Return-Path: X-Original-To: unbearable@ietf.org Delivered-To: unbearable@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7A8126B6D; Wed, 31 May 2017 10:03:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: unbearable@ietf.org, tokbind-chairs@ietf.org, ekr@rtfm.com, leifj@sunet.se X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149625022612.19877.8150266429988551012.idtracker@ietfa.amsl.com> Date: Wed, 31 May 2017 10:03:46 -0700 Archived-At: Subject: [Unbearable] tokbind - New Meeting Session Request for IETF 99 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 17:03:46 -0000 A new meeting session request has just been submitted by Leif Johansson, a Chair of the tokbind working group. --------------------------------------------------------- Working Group Name: Token Binding Area Name: Security Area Session Requester: Leif Johansson Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: ace tls oauth secevent Second Priority: People who must be present: Eric Rescorla Stephen Farrell Leif Johansson Dirk Balfanz John Bradley Andrey Popov Mike Jones Resources Requested: Special Requests: Key contributors are unable to attend on Friday. Please if possible avoid Friday scheduling. --------------------------------------------------------- From nobody Wed May 31 15:53:48 2017 Return-Path: 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 A7B36127333 for ; Wed, 31 May 2017 15:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com 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 Q2a9fQJz8_eN for ; Wed, 31 May 2017 15:53:45 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986E6124D37 for ; Wed, 31 May 2017 15:53:45 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id e193so19887419pfh.0 for ; Wed, 31 May 2017 15:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=wnf1WAnjxZBTICinWEKqX+0caxpOLzNKVC8OFJa3Zss=; b=eI+SsBZvQQ4TnJXJdcb2YYUOzueE/5p+HRRe1NVaYuIaGFI6Dj/KqVZYj7WerW06KY LwxFvgHkcKCafxxa1daOWppO25L9RWIydS2ZAw4lN9NnATNwEP/wxC9XSFZdjfq9XsNi r92XiWDKQSI7rL6wdVqC4ilGqrBUo5S3y/tto= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=wnf1WAnjxZBTICinWEKqX+0caxpOLzNKVC8OFJa3Zss=; b=LaNKz8bOX8Tkseo5YGkDjMCTozIHvh+pTwX8OJ9MIc/8EI+QQGJShBQl2fM/uG4kaR rHr64mfHv1WtcP3ny5X1Uf2YcryN076rObiF2hmvddFYskR0UnCnwRAVsJxcKYUU3FBW xJPmyWYGeInHo9W6wAp1FpkvyHaEeY71IfiAj6H/DEHjyWmstEl2tWabMs3wakCZKZr0 +BmUQuoJZeuFR+xQnLIpuCKIDYSZJES6gC3pwrAtLI9a0Tfapj0NYESQpKW74S8UPKag QGz2FTG8Ii8gMK0xIavr+2acnvu+XJKBbn5PAUdI+2yOcrKUrxEp8O4vHispnctXy28P 4I5A== X-Gm-Message-State: AODbwcCZ1Z5+zm4QnH7rc2YIPSloUgW3HWgj0X+aee0nrBw2EUzbdFN5 grCsb7clroK2q+/n1rGV4aOm7tDRZBee9eE= X-Received: by 10.84.168.67 with SMTP id e61mr73823208plb.124.1496271225036; Wed, 31 May 2017 15:53:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.149.4 with HTTP; Wed, 31 May 2017 15:53:14 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 31 May 2017 16:53:14 -0600 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary="94eb2c11acd6db3dd30550d9ca9f" Archived-At: Subject: Re: [Unbearable] Token Binding Demo Online 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 22:53:48 -0000 --94eb2c11acd6db3dd30550d9ca9f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just wanted to share a quick note that I've updated this demo slightly so that what would typically be the auto-submitting form page that sends the ID Token back to the RP now sends (ugly) HTML with the form and needs a user click to continue. This should make it easier to grab the ID Token and decode it to see if it was token bound with the confirmation "cnf" claim or not. On Fri, Mar 24, 2017 at 3:11 PM, Brian Campbell wrote: > I put up a demonstration of some token binding functionality that I wante= d > to share. There are a few parts to it, which I'll attempt to describe > below. > > At https://unbearable-bc.ping-eng.com:3000/open/ is a token binding > capable reverse proxy (of sorts) that is proxying requests to > http://httpbin.org/ with a little path rewriting. If you go to > https://unbearable-bc.ping-eng.com:3000/open/headers with a token binding > (-10 to -13) capable browser, for example, you should see the a dump of t= he > request headers including "Sec-Token-Binding". > > The reverse proxy is also set up with some access control and will proxy > from https://unbearable-bc.ping-eng.com:3000/ to http://httpbin.org/ but > require an authenticated session to do so. And it's using OpenID Connect > Token Bound Authentication > > with an IDP at https://token-provider-bc.ping-eng.com:9031 to > authenticate users. > > So, for example, if you go to https://unbearable-bc.ping- > eng.com:3000/headers without a session you will be redirected to the > authorization endpoint at that IDP and presented with a login page. Use > USERNAME: brian and PASSWORD: Test5555 on that page. After login, you'll = be > sent back to the relying party via the Form Post Response Mode > > where the ID Token is sent though the browser. If you grab that token and > decode it, there should be a confirmation method claim that has the hash = of > the Token Binding ID used with the relying party (i.e. "cnf": {"tbh": > "...hash..."}). > > The relying party sets up its own session from the OIDC SSO, which is a > cookie named PA.unbearable that is a JWT. The page at > https://unbearable-bc.ping-eng.com:3000/headers will dump the headers > including that cookie. If you decode that JWT, you should also see that t= he > local session is token bound with the confirmation method claim. > > Things will still work when using a non token binding capable browser but > none of the tokens will be token bound. > > As a reminder, you can enable Token Binding in Chrome by putting > chrome://flags/#enable-token-binding into the address bar. Chrome and Chr= ome > Canary=E2=80=8E are what I've been using to play with this. I'm hopping s= omeone > with the TB enabled Edge/IE can poke around on this demo too. > > > > > > > > --94eb2c11acd6db3dd30550d9ca9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just wanted to share a quick note that I've updat= ed this demo slightly so that what would typically be the=20 auto-submitting form page that sends the ID Token back to the RP now=20 sends (ugly) HTML with the form and needs a user click to continue. This should make it easier to grab the ID Token and decode it to see if it was = token bound with the confirmation "cnf" claim or not.

On Fri, Mar 2= 4, 2017 at 3:11 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
I put up a demonstration of some token binding functionality that I wanted= to share. There are a few parts to it, which I'll attempt to describe = below.

At https://unbearable-bc.ping-eng.com:3000/= open/ is a token binding capable reverse proxy (of sorts) that is proxy= ing requests to http://ht= tpbin.org/ with a little path rewriting. If you go to https://u= nbearable-bc.ping-eng.com:3000/open/headers with a token binding (= -10 to -13) capable browser, for example, you should see the a dump of the = request headers including "Sec-Token-Binding".

The reverse proxy is also set up with some access control and will proxy f= rom = https://unbearable-bc.ping-eng.com:3000/ to http://httpbin.org/ but require an authenti= cated session to do so. And it's using Op= enID Connect Token Bound Authentication with an IDP at https://token-pro= vider-bc.ping-eng.com:9031 to authenticate users.

So, for example, if you go to https://unbearable-bc.ping-eng.com= :3000/headers without a session you will be redirected to the authoriza= tion endpoint at that IDP and presented with a login page.=20 Use USERNAME: brian and PASSWORD: Test5555 on that page. After login, you&#= 39;ll be sent back to the relying party via the Form = Post Response Mode where the ID Token is sent though the browser. If yo= u grab that token and decode it, there should be a confirmation method clai= m that has the hash of the Token Binding ID used with the relying party (i.= e. "cnf": {"tbh": "...hash..."}).

The relying party sets up its own session from the OIDC SSO, which i= s a cookie named PA.unbearable that is a JWT. The page at https://unbear= able-bc.ping-eng.com:3000/headers will dump the headers including = that cookie. If you decode that JWT, you should also see that the local ses= sion is token bound with the confirmation method claim.

T= hings will still work when using a non token binding capable browser but no= ne of the tokens will be token bound.

As a re= minder, you can enable Token Binding in Chrome by putting chrome://flags/#enable-token-binding into the address = bar. Chrome and Chrome Canary=E2=80=8E are what I've been using to= play with this. I'm hopping someone with the TB enabled Edge/IE can po= ke around on this demo too.








--94eb2c11acd6db3dd30550d9ca9f--