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

=JeffH <> Thu, 16 November 2017 03:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43C42126CC4 for <>; Wed, 15 Nov 2017 19:01:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s0kVOHcJInTv for <>; Wed, 15 Nov 2017 19:01:45 -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 4CFB2124BE8 for <>; Wed, 15 Nov 2017 19:01:45 -0800 (PST)
Received: from CMOut01 (unknown []) by (Postfix) with ESMTP id 329021201E0 for <>; Wed, 15 Nov 2017 20:01:44 -0700 (MST)
Received: from ([]) by CMOut01 with id aT1h1w0082UhLwi01T1kYU; Wed, 15 Nov 2017 20:01:44 -0700
X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=IkcTkHD0fZMA:10 a=sC3jslCIGhcA:10 a=5IsXbjgYAAAA:8 a=yMhMjlubAAAA:8 a=1XWaLZrsAAAA:8 a=48vgC7mUAAAA:8 a=qI-sqkvjAAAA:8 a=1nf8GrLKyDivVUu9rZgA:9 a=QEXdDO2ut3YA:10 a=RR2nPHISKLg-FD_FhCoU:22 a=w1C3t2QeGrPiZgrLijVG:22
Received: from ([]:57357) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <>) id 1eFAQu-0018Z4-TL for; Wed, 15 Nov 2017 20:01:41 -0700
To: IETF TokBind WG <>
From: =JeffH <>
Message-ID: <>
Date: Thu, 16 Nov 2017 11:01:36 +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: 8bit
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: 1eFAQu-0018Z4-TL
X-Source-Sender: []:57357
X-Email-Count: 1
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 03:01:47 -0000

From: Eric Rescorla <>
Date: Thursday, November 16, 2017 at 8:07 AM
To: Andrei Popov <>
Cc: Leif Johansson <>se>, Vinod Anupam <>om>, 
<>rg>, "" 
<>rg>, Dirk Balfanz <>
Subject: Re: Status of draft-ietf-tokbind-https
Resent-From: <>rg>, Eric Rescorla <>
Resent-To: <>om>, <>om>, Dirk 
Balfanz <>om>, Adam Langley <>om>, 
<>om>, Jeff Hodges <>om>, 
Resent-Date: Thursday, November 16, 2017 at 8:08 AM

Thanks. As you can imagine, this week is terrible, but I should be able 
to finish my read-through next week.


On Thu, Nov 16, 2017 at 7:56 AM, Andrei Popov 
<> wrote:
Hi Eric,

Dirk has uploaded HTTPSTB-11 with additional language at the end of 
section 7.4 “ Securing Federated Sign-On Protocols”:

“Note that the presence of Token Binding does not relieve the Token
    Provider and Token Consumer from performing various checks to ensure
    the security of clients during federated sign-on protocols.  These
    include the following:

    o  The Token Provider should not issue tokens to Token Consumers that
       have been shown to act maliciously.  To aid in this, the
       federation protocol should identify the Token Consumer to the
       Token Provider (e.g., through OAuth client IDs or similar
       mechanisms), and the Token Provider should ensure that tokens are
       indeed issued to the Token Consumer identified in the token
       request (e.g., by verifying that the redirect URI is associated
       with the OAuth client ID.)

    o  The Token Consumer should verify that the tokens were issued for
       it, and not some other token consumer.  To aid in this, the
       federation protocol should include an audience parameter in the
       token response, or apply equivalent mechanisms (the implicit OAuth
       flow requires Token Consumers to identify themselves when they
       exchange OAuth authorization codes for OAuth refresh tokens,
       leaving it up to the Token Provider to verify that the OAuth
       authorization was delivered to the correct Token Consumer).“