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

=JeffH <Jeff.Hodges@KingsMountain.com> Thu, 16 November 2017 02:42 UTC

Return-Path: <Jeff.Hodges@kingsmountain.com>
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 2830E126DFB for <unbearable@ietfa.amsl.com>; Wed, 15 Nov 2017 18:42:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNkzs33KDXuH for <unbearable@ietfa.amsl.com>; Wed, 15 Nov 2017 18:42:18 -0800 (PST)
Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) (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 A88F3126CC4 for <unbearable@ietf.org>; Wed, 15 Nov 2017 18:42:18 -0800 (PST)
Received: from cmgw4 (unknown [10.0.90.85]) by qproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 5F7FE6AD66 for <unbearable@ietf.org>; Wed, 15 Nov 2017 19:42:18 -0700 (MST)
Received: from box514.bluehost.com ([74.220.219.114]) 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 dhcp-8b7b.meeting.ietf.org ([31.133.139.123]:56992) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1eFA85-000zlw-Ue for unbearable@ietf.org; Wed, 15 Nov 2017 19:42:14 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
To: IETF TokBind WG <unbearable@ietf.org>
Message-ID: <36e949a4-b4cf-2848-0474-f163e8d7b861@KingsMountain.com>
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 - box514.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - KingsMountain.com
X-BWhitelist: no
X-Source-IP: 31.133.139.123
X-Exim-ID: 1eFA85-000zlw-Ue
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: dhcp-8b7b.meeting.ietf.org [31.133.139.123]:56992
X-Source-Auth: jeff.hodges+kingsmountain.com
X-Email-Count: 2
X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ==
X-Local-Domain: no
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/SuymQ0UekxcrA1FpGMiFEn-ndCU>
Subject: Re: [Unbearable] FWD: Status of draft-ietf-tokbind-https
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: Thu, 16 Nov 2017 02:42:20 -0000


From: Leif Johansson <leifj@sunet.se>
Date: Monday, November 13, 2017 at 9:10 PM
To: Eric Rescorla <ekr@rtfm.com>, 
"draft-ietf-tokbind-https@tools.ietf.org" 
<draft-ietf-tokbind-https@tools.ietf.org>, "tokbind-chairs@ietf.org" 
<tokbind-chairs@ietf.org>
Subject: Re: Status of draft-ietf-tokbind-https
Resent-From: <alias-bounces@ietf.org>, Leif Johansson <leifj@sunet.se>
Resent-To: <andreipo@microsoft.com>, <mnystrom@microsoft.com>, Dirk 
Balfanz <balfanz@google.com>, Adam Langley <agl@google.com>, 
<nharper@google.com>, Jeff Hodges <Jeff.Hodges@PayPal.com>, 
<draft-ietf-tokbind-https@ietf.org>
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