Re: [Unbearable] FWD: Status of draft-ietf-tokbind-https

=JeffH <> Thu, 16 November 2017 02:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2830E126DFB for <>; Wed, 15 Nov 2017 18:42:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NNkzs33KDXuH for <>; Wed, 15 Nov 2017 18:42:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A88F3126CC4 for <>; Wed, 15 Nov 2017 18:42:18 -0800 (PST)
Received: from cmgw4 (unknown []) by (Postfix) with ESMTP id 5F7FE6AD66 for <>; Wed, 15 Nov 2017 19:42:18 -0700 (MST)
Received: from ([]) by cmgw4 with id aSiE1w00A2UhLwi01SiHg7; Wed, 15 Nov 2017 19:42:18 -0700
X-Authority-Analysis: v=2.2 cv=JNNLi4Cb c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=IkcTkHD0fZMA:10 a=sC3jslCIGhcA:10 a=5IsXbjgYAAAA:8 a=48vgC7mUAAAA:8 a=yMhMjlubAAAA:8 a=1XWaLZrsAAAA:8 a=qI-sqkvjAAAA:8 a=jHZcg3eliQUGabWl4-EA:9 a=u5y99PvpAtivChGq:21 a=bfOvsgzaF8XuCIBY:21 a=QEXdDO2ut3YA:10 a=RR2nPHISKLg-FD_FhCoU:22 a=w1C3t2QeGrPiZgrLijVG:22
Received: from ([]:56992) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <>) id 1eFA85-000zlw-Ue for; Wed, 15 Nov 2017 19:42:14 -0700
From: =JeffH <>
To: IETF TokBind WG <>
Message-ID: <>
Date: Thu, 16 Nov 2017 10:42:10 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Exim-ID: 1eFA85-000zlw-Ue
X-Source-Sender: []:56992
X-Email-Count: 2
X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ==
X-Local-Domain: no
Archived-At: <>
Subject: Re: [Unbearable] FWD: Status of draft-ietf-tokbind-https
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: Thu, 16 Nov 2017 02:42:20 -0000

From: Leif Johansson <>
Date: Monday, November 13, 2017 at 9:10 PM
To: Eric Rescorla <>, 
<>, "" 
Subject: Re: Status of draft-ietf-tokbind-https
Resent-From: <>, Leif Johansson <>
Resent-To: <>, <>, Dirk 
Balfanz <>, Adam Langley <>, 
<>, Jeff Hodges <>, 
Resent-Date: Monday, November 13, 2017 at 9:10 PM

 > On 2017-11-13 14:00, Eric Rescorla wrote:
 > Hi folks,
 > I have made a first pass through this document and while I have some
 > comments it appears generally sound. My one concern is the complexity
 > of the federated version. It's complicated enough that it's not obviously
 > secure and I don't know how much analysis there has been of it.

Have we gotten a secdir review yet? I confess I haven't seen one yet but
I may have missed something...

 > One thing I noticed that is a bit concerning is a potential way for an
 > attacker to get a confused token. As I understand it, the objective of
 > the flow is for the client to get a token which he can provide to the
 > Token Consumer that has in it the TBID for the key which he will use
 > to do a provided token binding to the Token Consumer. However, the
 > Token Provider's notion of who the TC is (the audience) usually comes
 > from some kind of redirect argument.
 > Specifically, consider the case where Alice is for some reason trying
 > to authenticate to the attacker, you can then get the following flow:
 > Alice                        Attacker                  Token Provider
 > Request ------------------------>
 > <-------------  Redirect to TP w/
 > Include-Referred-Token-Binding-ID:true
 > Audience identity = Victim
 > GET ---------------------------------------------------------->
 > EBTMS([K_tp, provided_binding],
 >       [K_attacker, referred_binding])
 > Audience identity = Victim
 > <-------------------------------------------------------- Token
 > So at this point, the Provider issues a token he thinks is for
 > the Victim but actually has the TBID for the attacker. I don't
 > see how to make this an attack, but it seems like it has the TP
 > being confused and (if the token has an audience value in it)
 > a token which is confused too, which doesn't seem ideal. Am I
 > wrong about this?
 > Anyway, my question really is: how can we make sure we have reasonable
 > confidence that this piece of token binding is secure? How much
 > analysis has there been? is there anything I can read? Or do we
 > just have whatever is in the draft?
 > Happy to sync up before the session tomorrow if that's useful
 > Thanks,
 > -Ekr

I don't have anything pressing in the morning. Happy to meet up
to talk about this. JB, Nick and Brian is here but I haven't
seen any of the key folks behind the core protocol yet.

	Cheers Leif