Re: [Unbearable] Benjamin Kaduk's No Objection on draft-ietf-tokbind-https-15: (with COMMENT)

Benjamin Kaduk <> Thu, 10 May 2018 21:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B513512DB70; Thu, 10 May 2018 14:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xzCFH0Mnjqsa; Thu, 10 May 2018 14:53:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 27DA712D95A; Thu, 10 May 2018 14:53:57 -0700 (PDT)
X-AuditID: 1209190c-087ff7000000786a-6c-5af4bf736652
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 59.46.30826.37FB4FA5; Thu, 10 May 2018 17:53:56 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id w4ALrswI008762; Thu, 10 May 2018 17:53:54 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id w4ALrn5c018298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 May 2018 17:53:52 -0400
Date: Thu, 10 May 2018 16:53:49 -0500
From: Benjamin Kaduk <>
To: Nick Harper <>
Cc: The IESG <>,, John Bradley <>,, IETF Tokbind WG <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hTV1i3Z/yXK4NgKdosbDx+wW8z4M5HZ on/HPkaL5fPns1mce7yQyWL13b9sDmweCzaVeixZ8pPJ4/btjSwBzFFcNimpOZllqUX6dglc GUsnNLAU7Oau+L/5HEsD42rOLkZODgkBE4me+VuZQWwhgcVMEksbI7oYuYDsjYwSzXc+MUI4 V5kkrrReYAKpYhFQlfj0q5cdxGYTUJFo6L4M1i0CZM+/ep0VpIFZYDOjxJkl71lAEsIC0RKH 9p1kA7F5gdbtv/eQDWLdVEaJZT1MEHFBiZMzn4DVMwtoSdz49xIozgFkS0ss/8cBEuYUCJR4 c2Yj2F5RAWWJvX2H2CcwCsxC0j0LSfcshO4FjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdA31 cjNL9FJTSjcxgsNakmcH45k3XocYBTgYlXh4C+K+RAmxJpYVV+YeYpTkYFIS5Z155VOUEF9S fkplRmJxRnxRaU5q8SFGCQ5mJRHefSuAynlTEiurUovyYVLSHCxK4rwCmz9ECQmkJ5akZqem FqQWwWRlODiUJHid9gE1ChalpqdWpGXmlCCkmTg4QYbzAA3fClLDW1yQmFucmQ6RP8WoKCXO uwkkIQCSyCjNg+sFpR2J7P01rxjFgV4R5uUGqeIBpiy47ldAg5mABh+8+hlkcEkiQkqqgbHD yewEj89pw+nXdm6xmHgpzH155p2mza+iTp3PvnFxD6fcwmlP5a87TI6Xmx8mG/uQZ2Fk2JaS dZ8MtzVt3PIkXHhlwmWLFdq8DIyp37tmdUSl3zr/371S7LRgbE3fjyKOBdmTp5YoFt6cKWOW HrPIc4X7icmP2AUnfjlSUKdR9c56wrMT9yyVWIozEg21mIuKEwHOXRQ4FgMAAA==
Archived-At: <>
Subject: Re: [Unbearable] Benjamin Kaduk's No Objection on draft-ietf-tokbind-https-15: (with COMMENT)
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, 10 May 2018 21:53:59 -0000

On Thu, May 10, 2018 at 07:18:20AM -0700, Nick Harper wrote:
> On Thu, May 10, 2018 at 6:51 AM, Benjamin Kaduk <> wrote:
> > Section 3
> >
> > To be clear, this means that the EKM used is the one from before
> > the renegotiation, corresponding in the somewhat-common use case of
> > renegotiation for optional client authentication to the
> > unauthenticated-client state, right?
> >
> > For Token Binding messages appearing after renegotiation, the EKM used is
> the one computed after renegotiation (different from the one before
> renegotiation). If we used the same EKM for the whole connection, then
> draft-ietf-tokbind-protocol wouldn't have to require the application
> mapping (in this case, draft-ietf-tokbind-https) to specify the interaction
> with renegotiation, and draft-ietf-tokbind-https wouldn't need to impose
> any restrictions on when renegotiation can occur.

I'm imagining a case like

<TLS handshake with only the server authenticating, token binding negotiated>

GET /some/protected/resource HTTP/1.1
Sec-Token-Binding: <blob>

<Server initiates renegotiation to authenticate client>

HTTP/1.1 200 OK

>From the server's perspective, the token binding was successfully
negotiated and the presented binding validates.  The EKM needed to
do so is from before the renegotiation.

I don't think this is problematic per se; I just want to make sure
we're on the same page.