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

Andrei Popov <Andrei.Popov@microsoft.com> Thu, 10 May 2018 22:17 UTC

Return-Path: <Andrei.Popov@microsoft.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 DE565129C56; Thu, 10 May 2018 15:17:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 HtWwlD97B0eB; Thu, 10 May 2018 15:17:21 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0097.outbound.protection.outlook.com [104.47.38.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB92129C51; Thu, 10 May 2018 15:17:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BcnONtEik6ui845zTVJqajzSY7c0u357X33EPzQ9yxs=; b=WbnfjiwbZOSodgr3K6xgWRMwcd3lkq7tOtp0zYkFSjozaeL+eUEAaH0CfcPVgZvhvftYxcRPvcTTOgqrgnmOwEd3GsA35zFxF3O7lTTLKuD3svML+Oc4ykTjH/lmZuWphS93PjyHzGzSprEH6j4x3JXpzfRKzWbhCEmEUMjNN1g=
Received: from DM5PR21MB0507.namprd21.prod.outlook.com (10.172.91.141) by DM5PR21MB0476.namprd21.prod.outlook.com (10.172.92.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.4; Thu, 10 May 2018 22:17:19 +0000
Received: from DM5PR21MB0507.namprd21.prod.outlook.com ([fe80::49e8:420f:baa2:a62f]) by DM5PR21MB0507.namprd21.prod.outlook.com ([fe80::49e8:420f:baa2:a62f%6]) with mapi id 15.20.0776.004; Thu, 10 May 2018 22:17:18 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Nick Harper <nharper@google.com>
CC: John Bradley <ve7jtb@ve7jtb.com>, IETF Tokbind WG <unbearable@ietf.org>, The IESG <iesg@ietf.org>, "tokbind-chairs@ietf.org" <tokbind-chairs@ietf.org>, "draft-ietf-tokbind-https@ietf.org" <draft-ietf-tokbind-https@ietf.org>
Thread-Topic: [Unbearable] Benjamin Kaduk's No Objection on draft-ietf-tokbind-https-15: (with COMMENT)
Thread-Index: AQHT6GYSePFvCAZoUEKFsQYJjMVWRKQpArIAgAB/QoCAAAQ6IA==
Date: Thu, 10 May 2018 22:17:18 +0000
Message-ID: <DM5PR21MB050722993EE0DCA6B0E1F5898C980@DM5PR21MB0507.namprd21.prod.outlook.com>
References: <152596031836.10294.13536754824931837516.idtracker@ietfa.amsl.com> <CACdeXiL0990bMZ02F24nXm_021pZF_FKi9=qRbRkNK-b2GqYmA@mail.gmail.com> <20180510215346.GC84491@kduck.kaduk.org>
In-Reply-To: <20180510215346.GC84491@kduck.kaduk.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:c::4ca]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR21MB0476; 7:BnmG792YYlltTHncS+TJf06dSi5b1pmmYGFC72bZPO4iczA7KU8IA81xbV7ZRmwEeBW/wJE6KU2P7dRYD+KyN4aetMuuHd51d+g5Oyj5wDIFkEyUwKrg1QCEZ8y0rSOkOwZJKKHn5XbixniSQZ/671G8arl/+wyaWj0/G4LSseqIIqyKpSjA/cAn6kn244S0zQCdI1mD8bmg4/BpDVq/0IB8dA2ZBTo/AA7H0CIWK71FUoNPAuuTn+IYQn9Cowpo; 20:ORourdxyaJskeea/e28kW2N1R3QL6i96rgO/Wdijt6v0Hn1UoDibOEItLHbQV0B2E3EDOBAE1VgR04XKNL1hil6KN9IABL29UQAqOzb7ahChvjB1n4gzAR/wUaKlsXgKpOWW+Q+Xr0u4kKZOGJk1+6LD6MkWj5LlPuPW4IlvI7k=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(48565401081)(2017052603328)(7193020); SRVR:DM5PR21MB0476;
x-ms-traffictypediagnostic: DM5PR21MB0476:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com;
x-microsoft-antispam-prvs: <DM5PR21MB047628F6133F0962C5E9DA4C8C980@DM5PR21MB0476.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(189930954265078)(211936372134217)(153496737603132)(219752817060721)(240460790083961);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR21MB0476; BCL:0; PCL:0; RULEID:; SRVR:DM5PR21MB0476;
x-forefront-prvs: 066898046A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(39860400002)(376002)(366004)(346002)(189003)(199004)(13464003)(99286004)(54906003)(46003)(102836004)(6506007)(22452003)(11346002)(6436002)(5660300001)(110136005)(316002)(7696005)(53936002)(3280700002)(106356001)(9686003)(446003)(3660700001)(476003)(33656002)(486006)(55016002)(86362001)(74316002)(6306002)(86612001)(14454004)(2906002)(305945005)(105586002)(68736007)(76176011)(6116002)(2900100001)(97736004)(8990500004)(10090500001)(8936002)(966005)(186003)(10290500003)(6246003)(25786009)(229853002)(81156014)(7736002)(478600001)(53546011)(72206003)(4326008)(5250100002)(2171002)(81166006)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0476; H:DM5PR21MB0507.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: R5kIGUZQvYq8OaXiAjyFZUAICRc0Sjh0YuPsF0SfSodVFjxCmmW3iDIRxKTA/pNCch3wsbB608bvu37tZc7MIoyqr4ORKZ4HAVF3BoqKB792/rcstuhF/LSeEFS6iNV+OPrDXsRIj1zaXmDyPmvJmFjnM9Cti+htuU7Sgg2foe2Ut25aXJArmmF8Gu4ebM/h
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: d70911ab-5743-4858-eee4-08d5b6c3cb4f
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d70911ab-5743-4858-eee4-08d5b6c3cb4f
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2018 22:17:18.7473 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0476
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/W_0MYD_esCc6mfFpCLZemGJZv0U>
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 22:17:24 -0000

> 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.
Correct. In your example, the HTTP GET was encrypted using keys derived from the master secret of the original TLS session. The TB message contained therein signs the EKM derived from the master secret of the original TLS session.

An HTTP GET following the renegotiation will be encrypted using keys derived from the master secret of the renegotiated TLS session. Any TB contained therein will sign the EKM derived from the master secret of the renegotiated TLS session.

Cheers,

Andrei

-----Original Message-----
From: Unbearable <unbearable-bounces@ietf.org> On Behalf Of Benjamin Kaduk
Sent: Thursday, May 10, 2018 2:54 PM
To: Nick Harper <nharper@google.com>
Cc: John Bradley <ve7jtb@ve7jtb.com>om>; IETF Tokbind WG <unbearable@ietf.org>rg>; The IESG <iesg@ietf.org>rg>; tokbind-chairs@ietf.org; draft-ietf-tokbind-https@ietf.org
Subject: Re: [Unbearable] Benjamin Kaduk's No Objection on draft-ietf-tokbind-https-15: (with COMMENT)

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

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Funbearable&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cb764a5ba6a62423a7d1e08d5b6c08bf8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636615860455141303&sdata=767ecoDYOj3vD3xsuqmH1uYh7NKrf5%2BPyC2lqmXLfT8%3D&reserved=0