IETF Logo Mail Archive

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

Benjamin Kaduk <kaduk@mit.edu> Thu, 10 May 2018 21:53 UTC

Return-Path: <kaduk@mit.edu>
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 B513512DB70; Thu, 10 May 2018 14:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzCFH0Mnjqsa; Thu, 10 May 2018 14:53:57 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 27DA712D95A; Thu, 10 May 2018 14:53:57 -0700 (PDT)
X-AuditID: 1209190c-087ff7000000786a-6c-5af4bf736652
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 59.46.30826.37FB4FA5; Thu, 10 May 2018 17:53:56 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w4ALrswI008762; Thu, 10 May 2018 17:53:54 -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 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 <kaduk@mit.edu>
To: Nick Harper <nharper@google.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tokbind-https@ietf.org, John Bradley <ve7jtb@ve7jtb.com>, tokbind-chairs@ietf.org, IETF Tokbind WG <unbearable@ietf.org>
Message-ID: <20180510215346.GC84491@kduck.kaduk.org>
References: <152596031836.10294.13536754824931837516.idtracker@ietfa.amsl.com> <CACdeXiL0990bMZ02F24nXm_021pZF_FKi9=qRbRkNK-b2GqYmA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CACdeXiL0990bMZ02F24nXm_021pZF_FKi9=qRbRkNK-b2GqYmA@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/unbearable/3jlFaggb6UfQYWFkFNY9JWGc46U>
Subject: Re: [Unbearable] Benjamin Kaduk's No Objection on draft-ietf-tokbind-https-15: (with COMMENT)
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, 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 <kaduk@mit.edu> 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
[data]


>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.

-Benjamin

v2.23.0 | Report a Bug | By Email