From nobody Tue Mar 1 11:04:07 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD631B3FE5 for ; Tue, 1 Mar 2016 11:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 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, USER_IN_WHITELIST=-100] autolearn=ham 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 MJrena_VYyOQ for ; Tue, 1 Mar 2016 11:04:01 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id CA90F1B3FCC for ; Tue, 1 Mar 2016 11:04:00 -0800 (PST) Received: (qmail 26536 invoked by uid 0); 1 Mar 2016 19:04:00 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy7.mail.unifiedlayer.com with SMTP; 1 Mar 2016 19:04:00 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id Qj3u1s0152UhLwi01j3x7l; Tue, 01 Mar 2016 12:03:58 -0700 X-Authority-Analysis: v=2.1 cv=PPOcp5aC c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=2nZJt5_SITsA:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=9hlyuBdhgS79cxEtfAUA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=Xc3F2uor4kyvkVhRblIFrs1GS1knS78+vAqR6FHMgEQ=; b=XdfQLDG2FYzH38kEnv+KHEpTuVAskCkAv9F+o4+PGO1ZKAqFEIp88gsowq5wU1EDSrYzrxaDPaqawAHpHdefLyXQDNHpNRNMEY6TdqbhghrCt0Ja6El/2zShJ5z14XrH; Received: from [70.213.8.227] (port=11366 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aapaO-0007QS-9H for unbearable@ietf.org; Tue, 01 Mar 2016 12:03:56 -0700 To: IETF Tokbind WG From: =JeffH Message-ID: <56D5E798.9030702@KingsMountain.com> Date: Tue, 1 Mar 2016 11:03:52 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.213.8.227 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: Re: [Unbearable] -tokbind-https-02: "Federated token bindings" figures X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Mar 2016 19:04:06 -0000 I've updated the "Token Binding over HTTP: Federation Use Cases" figure adding EKMs & keys and denoting who-signs-what-when, per discussion in the "-tokbind-protocol-04: verifying signature(s) in TokenBindingMessage.TokenBinding?" thread. HTH, =JeffH Token Binding over HTTP https://tools.ietf.org/html/draft-ietf-tokbind-https Diagram of section 3. Federation Use Cases https://tools.ietf.org/html/draft-ietf-tokbind-https-02#section-3 What: Typical HTTP Redirect-based Web Broswer SSO Profile (no artifact, no callbacks), featuring binding of a TLS Token Binding ID into an OpenID Connect "ID Token". Legend: EKM: TLS Exported Keying Material [RFC5705] {EKMn}Ksm: EKM for server "n", signed by private key of TBID "m", where "n" must represent server receiving the ETBMSG. if a conveyed TB's type is provided_token_binding, then m = n, else if TB's type is referred_token_binding, then m != n. E.g., see step 1b in diagram below. ETBMSG: "Token-Binding" HTTP header field conveying an EncodedTokenBindingMessage, in turn conveying TokenBinding (TB)struct(s), e.g.: ETBMSG[[TB]] or ETBMSG[[TB1],[TB2]] ID Token: the "ID Token" in OIDC, it is the semantic equivalent of a SAML "authentication assertion". "ID Token w/TBIDn" denotes a "token bound" ID Token containing TBIDn. Ks & Kp: private (aka secret) key, and public key, respectively, of client-side Token Binding key pair OIDC: Open ID Connect TB: TokenBinding struct containing signed EKM, TBID, and TB type, e.g.: [{EKM1}Ks1,TBID1,provided_token_binding] TBIDn: Token Binding ID for client and server n's token-bound TLS association Client, Token Consumer, Token Provider, aka: aka: aka: User Agent OpenID Client, OpenID Provider, OIDC Relying Party, OIDC Provider, SAML Relying Party SAML Identity Provider [ server "1" ] [ server "2" ] +--------+ +----+ +-----+ | Client | | TC | | TP | +--------+ +----+ +-----+ | | | | | | | | | | 0. Client interacts w/TC | | | over HTTPS, establishes Ks1 & Kp1, TBID1 | | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | |------------------------------>| | | | | | | | | | | | 1a. OIDC ID Token request, aka| | | "Authentication Request", conveyed with | | HTTP response header field of: | | Include-Referer-Token-Binding-ID:true | | any security-relevant cookies | | | should contain TBID1 | | +<- - - - - - - - - - - - - - - - | | . | (redirect to TP via 301, 302, | | . | 303, 307, or 308) | | . | | | +------------------------------------------------------->| | 1b. opens HTTPS & establishes Ks2, Kp2, TBID2; | | sends GET or POST with | | ETBMSG[[{EKM2}Ks2,TBID2,provided_token_binding], | | [{EKM2}Ks1,TBID1,referred_token_binding]] | | as well as the ID Token request | | | | | | | | | | | 2. user authentication (if applicable, | | methods vary, particulars are out of scope) | |<====================================================>| | (TP generates ID Token for TC containing TBID1, may | | also set cookie(s) containing TBID2 and/or TBID1, | | details vary, particulars are out of scope) | | | | | | | | | | | 3a. ID Token containing TBID1, issued for TC, | | conveyed via OIDC "Authentication Response" | +<- - - - - - - - - - - - - - - - - - - - - - - - - - - -| . | (redirect to TC) | | . | | | . | | | +-------------------------------->| | | 3b. HTTPS GET or POST with | | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | | conveying Authn Reponse containing | | ID Token w/TBID1, issued for TC | | | | | | | | | | | 4. user is signed-on, any security-relevant cookie(s)| | that are set SHOULD contain TBID1 | |<------------------------------| | | | | | | | From nobody Tue Mar 1 19:26:50 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723FE1B4661 for ; Tue, 1 Mar 2016 19:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 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, USER_IN_WHITELIST=-100] autolearn=ham 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 zFDPf0Mj4Os2 for ; Tue, 1 Mar 2016 19:26:47 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id A94C71A90A3 for ; Tue, 1 Mar 2016 19:26:47 -0800 (PST) Received: (qmail 12850 invoked by uid 0); 2 Mar 2016 03:26:43 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy7.mail.unifiedlayer.com with SMTP; 2 Mar 2016 03:26:43 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id QrSc1s00e2UhLwi01rSfii; Tue, 01 Mar 2016 20:26:42 -0700 X-Authority-Analysis: v=2.1 cv=O8aq4nNW c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=2nZJt5_SITsA:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=ieNpE_y6AAAA:8 a=6VZg79Lre34grV8_bugA:9 a=QEXdDO2ut3YA:10 a=mkMbj8FlDA4A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:Cc:To; bh=mdOJS5ixIXqT6E6ZhO3rFIBNWmN/i7hrKcaw26Cs9c8=; b=cLaVGB0vYCSKmP/gCxSJj2GhGU9as36tAKf44wE/6INjw/z4dfzKT1vZ2yi1Kkm/OZ1eOUOg/QY1mizs/4ZMW9n+Sg7rsmbEJ/W2k/qMBzGNjzRDNkfnRcG+RlEUpPzd; Received: from [70.213.8.227] (port=11386 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aaxQr-0001pc-R6; Tue, 01 Mar 2016 20:26:37 -0700 To: Nick Harper , Andrei Popov From: =JeffH Message-ID: <56D65D67.80004@KingsMountain.com> Date: Tue, 1 Mar 2016 19:26:31 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.213.8.227 authed with jeff.hodges+kingsmountain.com} Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] -tokbind-protocol-04: verifying signature(s) in, TokenBindingMessage.TokenBinding? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 02 Mar 2016 03:26:49 -0000 Nick wrote: > My understanding of referred token bindings is that the signature in the > TokenBinding struct is over the same EKM value for all TokenBinding > structs in the TokenBindingMessage. That is, when server A sends the > Include-Referer-Token-Binding-ID and redirects to server B, the > TokenBindingMessage sent to server B has a provided TokenBinding with > the client's TokenBindingID for server B and a signature of the EKM for > the connection to server B, and a referred TokenBinding with the > client's TokenBindingID for server A and a signature of the EKM for the > connection to server B. This way, server B can verify the signature for > both keys (assuming server B supports the key parameter used for the > referred TokenBinding). Thanks for the detailed explanation, that makes sense. Andrei added: > Correct, in order for a server to verify the binding, the signature has > to be over the EKM of the TLS connection with this server. Such > federation scenarios are described in detail in section 3.2 of HTTPSTB: > https://tools.ietf.org/html/draft-ietf-tokbind-https-02#section-3.2 However, it seems the details wrt which EKM is signed for referred_token_bindings is not explicitly stated AFAICT in either -tokbind-https-02 or in -tokbind-protocol-04. Although some folks have obviously figured it out, it may be difficult for others (I spose I'm one of 'em). So, I"ve crafted up some modest mods to -tokbind-protocol-04 that make this stuff explicit. The source can be perused here.. https://github.com/TokenBinding/Internet-Drafts/pull/16 ..and a formatted diff is here.. HTH, =JeffH From nobody Wed Mar 2 11:55:09 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363C51B2E58 for ; Wed, 2 Mar 2016 11:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 YuK_J9ZRezgg for ; Wed, 2 Mar 2016 11:55:04 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2F4A1B2E56 for ; Wed, 2 Mar 2016 11:55:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/IK7a3+7rDcpKTboLqIE4GpuuDMBr7t8f5ggj7snpwE=; b=bXkPsSUgKRRIZL44/mtFopXjnunZlt4zjjCRRlbn82Kt1CS9k9Y8Nom4i3qkqKEG3GbqG1SRsm1wNrhKg/ROk1rDvxM8xrICnLQGj+DhcBzDqPZ3AOao/qkOv5FyIpd/SeP7MDVlOYtLLfCoAAzPbFprtmPfDMblO3XPJ+wMSbk= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.415.20; Wed, 2 Mar 2016 19:54:43 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0415.024; Wed, 2 Mar 2016 19:54:43 +0000 From: Andrei Popov To: =JeffH , Nick Harper Thread-Topic: [Unbearable] -tokbind-protocol-04: verifying signature(s) in, TokenBindingMessage.TokenBinding? Thread-Index: AQHRdDNZ6YpFSIOsmUGGK+E735xSTp9GkP7g Date: Wed, 2 Mar 2016 19:54:43 +0000 Message-ID: References: <56D65D67.80004@KingsMountain.com> In-Reply-To: <56D65D67.80004@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: KingsMountain.com; dkim=none (message not signed) header.d=none;KingsMountain.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:5::1d2] x-ms-office365-filtering-correlation-id: caee99b6-d444-4eb8-570a-08d342d47feb x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:qQNFrSIA1rPOoVVDr0ULuZHj5gQ9ojuDgDgBsr1xW2/x2cGhlXfExuidw7oEAehIRdeCPiQaqmcUTIYScEPel6/vVqa10l3h3RiVLfcKj6nabWpjwlwnQ06pY50aQlF7Sb9e3FsiHC7diWd9ry/xDw==; 24:8x2MW4FNHXQozEofuIm2Y4XP8DVgE3W8EuolmvO1GLQbCyDk84P1P6Y6PQwk74NDgvrb8WggEhnRtTmjqcP8tfxao8MLfJNlWPZh7Bsrozc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 086943A159 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(164054003)(51914003)(13464003)(230783001)(575784001)(5001770100001)(122556002)(5003600100002)(86362001)(86612001)(15650500001)(40100003)(189998001)(5002640100001)(33656002)(15975445007)(99286002)(77096005)(5004730100002)(76576001)(106116001)(76176999)(87936001)(74316001)(54356999)(50986999)(2900100001)(6116002)(10290500002)(10400500002)(1220700001)(5005710100001)(92566002)(2950100001)(3660700001)(3280700002)(19580405001)(19580395003)(4326007)(5001960100004)(2906002)(1096002)(11100500001)(10090500001)(586003)(102836003)(5008740100001)(81156011)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2016 19:54:43.3501 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] -tokbind-protocol-04: verifying signature(s) in, TokenBindingMessage.TokenBinding? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 02 Mar 2016 19:55:07 -0000 SGkgSmVmZiwNCg0KSXQgaXMgYSBnb29kIGlkZWEgdG8gY2xhcmlmeSB3aGljaCBFS00gaXMgc2ln bmVkIGluIGVhY2ggbGVnIG9mIHRoZSBmZWRlcmF0aW9uIHNjZW5hcmlvLiBJIGJlbGlldmUgdGhp cyB3aWxsIGJlIGEgYmV0dGVyIGZpdCBpbiB0aGUgSFRUUFNUQiBkcmFmdCwgd2hpY2ggdGFsa3Mg YWJvdXQgYWxsIHRoaW5ncyBmZWRlcmF0aW9uLg0KDQpUaGFua3MsDQoNCkFuZHJlaQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogPUplZmZIIFttYWlsdG86SmVmZi5Ib2RnZXNA S2luZ3NNb3VudGFpbi5jb21dIA0KU2VudDogVHVlc2RheSwgTWFyY2ggMSwgMjAxNiA3OjI3IFBN DQpUbzogTmljayBIYXJwZXIgPG5oYXJwZXJAZ29vZ2xlLmNvbT47IEFuZHJlaSBQb3BvdiA8QW5k cmVpLlBvcG92QG1pY3Jvc29mdC5jb20+DQpDYzogSUVURiBUb2tiaW5kIFdHIDx1bmJlYXJhYmxl QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSAtdG9rYmluZC1wcm90b2NvbC0w NDogdmVyaWZ5aW5nIHNpZ25hdHVyZShzKSBpbiwgVG9rZW5CaW5kaW5nTWVzc2FnZS5Ub2tlbkJp bmRpbmc/DQoNCg0KTmljayB3cm90ZToNCiA+IE15IHVuZGVyc3RhbmRpbmcgb2YgcmVmZXJyZWQg dG9rZW4gYmluZGluZ3MgaXMgdGhhdCB0aGUgc2lnbmF0dXJlIGluIHRoZSAgPiBUb2tlbkJpbmRp bmcgc3RydWN0IGlzIG92ZXIgdGhlIHNhbWUgRUtNIHZhbHVlIGZvciBhbGwgVG9rZW5CaW5kaW5n ICA+IHN0cnVjdHMgaW4gdGhlIFRva2VuQmluZGluZ01lc3NhZ2UuIFRoYXQgaXMsIHdoZW4gc2Vy dmVyIEEgc2VuZHMgdGhlICA+IEluY2x1ZGUtUmVmZXJlci1Ub2tlbi1CaW5kaW5nLUlEIGFuZCBy ZWRpcmVjdHMgdG8gc2VydmVyIEIsIHRoZSAgPiBUb2tlbkJpbmRpbmdNZXNzYWdlIHNlbnQgdG8g c2VydmVyIEIgaGFzIGEgcHJvdmlkZWQgVG9rZW5CaW5kaW5nIHdpdGggID4gdGhlIGNsaWVudCdz IFRva2VuQmluZGluZ0lEIGZvciBzZXJ2ZXIgQiBhbmQgYSBzaWduYXR1cmUgb2YgdGhlIEVLTSBm b3IgID4gdGhlIGNvbm5lY3Rpb24gdG8gc2VydmVyIEIsIGFuZCBhIHJlZmVycmVkIFRva2VuQmlu ZGluZyB3aXRoIHRoZSAgPiBjbGllbnQncyBUb2tlbkJpbmRpbmdJRCBmb3Igc2VydmVyIEEgYW5k IGEgc2lnbmF0dXJlIG9mIHRoZSBFS00gZm9yIHRoZSAgPiBjb25uZWN0aW9uIHRvIHNlcnZlciBC LiBUaGlzIHdheSwgc2VydmVyIEIgY2FuIHZlcmlmeSB0aGUgc2lnbmF0dXJlIGZvciAgPiBib3Ro IGtleXMgKGFzc3VtaW5nIHNlcnZlciBCIHN1cHBvcnRzIHRoZSBrZXkgcGFyYW1ldGVyIHVzZWQg Zm9yIHRoZSAgPiByZWZlcnJlZCBUb2tlbkJpbmRpbmcpLg0KDQpUaGFua3MgZm9yIHRoZSBkZXRh aWxlZCBleHBsYW5hdGlvbiwgdGhhdCBtYWtlcyBzZW5zZS4NCg0KDQpBbmRyZWkgYWRkZWQ6DQog PiBDb3JyZWN0LCBpbiBvcmRlciBmb3IgYSBzZXJ2ZXIgdG8gdmVyaWZ5IHRoZSBiaW5kaW5nLCB0 aGUgc2lnbmF0dXJlIGhhcyAgPiB0byBiZSBvdmVyIHRoZSBFS00gb2YgdGhlIFRMUyBjb25uZWN0 aW9uIHdpdGggdGhpcyBzZXJ2ZXIuIFN1Y2ggID4gZmVkZXJhdGlvbiBzY2VuYXJpb3MgYXJlIGRl c2NyaWJlZCBpbiBkZXRhaWwgaW4gc2VjdGlvbiAzLjIgb2YgSFRUUFNUQjoNCiA+IGh0dHBzOi8v bmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJm dG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzLTAyJTIzc2Vj dGlvbi0zLjImZGF0YT0wMSU3YzAxJTdjQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3Y2Q5 NDcwYjMzYjc2MTQzN2IxOTc4MDhkMzQyNGE3YWQ0JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj ZDAxMWRiNDclN2MxJnNkYXRhPU85VUJ6Z291N0NuV0pQdGN5VUNFZHZDbnE5VjBZVk1PMklJY3dV Y1JiTmMlM2QNCg0KSG93ZXZlciwgaXQgc2VlbXMgdGhlIGRldGFpbHMgd3J0IHdoaWNoIEVLTSBp cyBzaWduZWQgZm9yIHJlZmVycmVkX3Rva2VuX2JpbmRpbmdzIGlzIG5vdCBleHBsaWNpdGx5IHN0 YXRlZCBBRkFJQ1QgaW4gZWl0aGVyDQotdG9rYmluZC1odHRwcy0wMiBvciBpbiAtdG9rYmluZC1w cm90b2NvbC0wNC4gQWx0aG91Z2ggc29tZSBmb2xrcyBoYXZlIG9idmlvdXNseSBmaWd1cmVkIGl0 IG91dCwgaXQgbWF5IGJlIGRpZmZpY3VsdCBmb3Igb3RoZXJzIChJIHNwb3NlIEknbSBvbmUgb2Yg J2VtKS4NCg0KU28sIEkidmUgY3JhZnRlZCB1cCBzb21lIG1vZGVzdCBtb2RzIHRvIC10b2tiaW5k LXByb3RvY29sLTA0IHRoYXQgbWFrZSB0aGlzIHN0dWZmIGV4cGxpY2l0LiBUaGUgc291cmNlIGNh biBiZSBwZXJ1c2VkIGhlcmUuLg0KDQpodHRwczovL2dpdGh1Yi5jb20vVG9rZW5CaW5kaW5nL0lu dGVybmV0LURyYWZ0cy9wdWxsLzE2DQoNCi4uYW5kIGEgZm9ybWF0dGVkIGRpZmYgaXMgaGVyZS4u DQoNCjxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwJTNhJTJmJTJma2luZ3Ntb3VudGFpbi5jb20lMmZkb2MlMmZkaWZmJTJmRGlmZi0tZHJhZnQt aWV0Zi10b2tiaW5kLXByb3RvY29sLTA0LnR4dC0tdG8tLWRyYWZ0LWlldGYtdG9rYmluZC1wcm90 b2NvbC0wNGMudHh0Lmh0bWwmZGF0YT0wMSU3YzAxJTdjQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0 LmNvbSU3Y2Q5NDcwYjMzYjc2MTQzN2IxOTc4MDhkMzQyNGE3YWQ0JTdjNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPVRjNjRkM2ZJbk5rVkt4UVJuR2lBcmxuWEFvRDl4 dGE1Ym50akhWTEdrOVUlM2Q+DQoNCkhUSCwNCg0KPUplZmZIDQoNCg== From nobody Wed Mar 2 14:09:58 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773AE1B32AC for ; Wed, 2 Mar 2016 14:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 UkFUh-h5GPla for ; Wed, 2 Mar 2016 14:09:55 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id C13541B32A9 for ; Wed, 2 Mar 2016 14:09:52 -0800 (PST) Received: (qmail 9405 invoked by uid 0); 2 Mar 2016 22:09:52 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy6.mail.unifiedlayer.com with SMTP; 2 Mar 2016 22:09:52 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id RA9n1s00S2UhLwi01A9qbx; Wed, 02 Mar 2016 15:09:51 -0700 X-Authority-Analysis: v=2.1 cv=O8aq4nNW c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-JcCEVYgZOcA:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=ieNpE_y6AAAA:8 a=rwB2mwCRvWTc0mjXtx8A:9 a=QEXdDO2ut3YA:10 a=mkMbj8FlDA4A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:To:References:Subject; bh=s39+Lth8jVlAioc/5QP/Mze4q2v+aSCjEpdrRRPmjWE=; b=KbMGShftL6chusXOKNvUOEZ3fbUTIYuw9ihf8eRTylNpJ4+2yWCkm0iQs1+B8gBXWsK+/QZsD0NWvZt9+xnlmqjWo37C9uw91jJyC72aQCO01vXalKB0pMd+VI0Afr1d; Received: from [70.213.6.69] (port=4653 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1abExk-00025y-2B; Wed, 02 Mar 2016 15:09:44 -0700 References: <56D65D67.80004@KingsMountain.com> To: Andrei Popov From: =JeffH Message-ID: <56D764A3.3040802@KingsMountain.com> Date: Wed, 2 Mar 2016 14:09:39 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56D65D67.80004@KingsMountain.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.213.6.69 authed with jeff.hodges+kingsmountain.com} Archived-At: Cc: IETF Tokbind WG , =JeffH Subject: Re: [Unbearable] -tokbind-protocol-04: verifying signature(s) in, TokenBindingMessage.TokenBinding? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 02 Mar 2016 22:09:56 -0000 bottom-posted.. On 03/01/2016 07:26 PM, =JeffH wrote: > > Nick wrote: > > My understanding of referred token bindings is that the signature in the > > TokenBinding struct is over the same EKM value for all TokenBinding > > structs in the TokenBindingMessage. That is, when server A sends the > > Include-Referer-Token-Binding-ID and redirects to server B, the > > TokenBindingMessage sent to server B has a provided TokenBinding with > > the client's TokenBindingID for server B and a signature of the EKM for > > the connection to server B, and a referred TokenBinding with the > > client's TokenBindingID for server A and a signature of the EKM for the > > connection to server B. This way, server B can verify the signature for > > both keys (assuming server B supports the key parameter used for the > > referred TokenBinding). > > Thanks for the detailed explanation, that makes sense. > > > Andrei added: > > Correct, in order for a server to verify the binding, the signature has > > to be over the EKM of the TLS connection with this server. Such > > federation scenarios are described in detail in section 3.2 of HTTPSTB: > > https://tools.ietf.org/html/draft-ietf-tokbind-https-02#section-3.2 > > However, it seems the details wrt which EKM is signed for > referred_token_bindings is not explicitly stated AFAICT in either > -tokbind-https-02 or in -tokbind-protocol-04. Although some folks have > obviously figured it out, it may be difficult for others (I spose I'm one of > 'em). > > So, I"ve crafted up some modest mods to -tokbind-protocol-04 that make this > stuff explicit. The source can be perused here.. > > https://github.com/TokenBinding/Internet-Drafts/pull/16 > > ..and a formatted diff is here.. > > Andrei replied: > It is a good idea to clarify which EKM is signed agreed, thx. > in each leg of the > federation scenario. I believe this will be a better fit in the HTTPSTB > draft, which talks about all things federation. hm, I don't think that's the way to go for various reasons, e.g., -tokbind-protocol (aka TBPROTO).. 1. defines TokenBindingType (provided and referred), 2. specifies the signature-over-EKM(s) mechanism. Plus, HTTPSTB (aka -tokbind-https) is HTTP-specific. If some other app protocol (eg SIP?) that layers over TLS leverages TokBind and has need for using referred_token_binding, then everything they need to know ought to be contained in TBPROTO and TBNEGO -- they aren't necessarily going to pay attention to -tokbind-https. addtionally, -tokbind-https does not specifically mention the signature mechanism used in the TokenBindingMessage, i.e., it doesn't mention EKMs (other than in the Security Cons). plus, in the -tokbind-protocol context specifically, all "referred" seems to mean is that "this other 3d-party server said it is ok to reveal to you (the 1st party server) my TBID for that other server and to prove to you my possession of the private key associated with said TBID" -- i.e. the fact that -tokbind-https uses this "referred" building block to accommodate issuance and consumption of bound "federated" security tokens at the HTTP layer does not mean that it, -tokbind-https, needs to get into the business of specifying which EKM is signed by whom per token binding type. finally, if I'm understanding the security model correctly, one always needs to use and sign the present-server-EKM when sending the TokenBindingMessage to the preset server, regardless of the type of contained TokenBindings (provided or referred), because otherwise the server won't have cryptographic proof-of-possession of the private keys. Thus this might as well be specified in one central place -- i.e., -tokbind-protocol. HTH, =JeffH From nobody Wed Mar 2 15:09:54 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA9D1B340D for ; Wed, 2 Mar 2016 15:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 qr1wLmEeDcCa for ; Wed, 2 Mar 2016 15:09:47 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:713]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 892601B340C for ; Wed, 2 Mar 2016 15:09:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=831pAJANIK1C2Jivv38TtEuLhnXpHUcotKafn8mMXU0=; b=WEg6GbFuSzPQpj1Z6a7bEMzzrvUh6ieAk5Szx1QE3Z73ijoJ7Y2+IbrqnhvBaAGsEF8bJCJ8M6Gy1F5efwjnO/9k/MuSy9/hhI/KV6IIBE7KHIGjRDPSrIpS4KdSED5mhJjJ/kqoGsdYwfwa3m/Tw4MQ7CURbOX9x2m7C2bb75Q= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1394.namprd03.prod.outlook.com (10.163.81.140) with Microsoft SMTP Server (TLS) id 15.1.415.20; Wed, 2 Mar 2016 23:09:29 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0415.024; Wed, 2 Mar 2016 23:09:29 +0000 From: Andrei Popov To: =JeffH Thread-Topic: [Unbearable] -tokbind-protocol-04: verifying signature(s) in, TokenBindingMessage.TokenBinding? Thread-Index: AQHRdDNZ6YpFSIOsmUGGK+E735xSTp9GuAaAgAAMR8A= Date: Wed, 2 Mar 2016 23:09:29 +0000 Message-ID: References: <56D65D67.80004@KingsMountain.com> <56D764A3.3040802@KingsMountain.com> In-Reply-To: <56D764A3.3040802@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: KingsMountain.com; dkim=none (message not signed) header.d=none;KingsMountain.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:5::1d2] x-ms-office365-filtering-correlation-id: f1d759ae-83f3-42b6-b6c2-08d342efb571 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1394; 5:rfSHTFVif6OowKK5lNG0tkQgSUQ7XUbEKlpUzVYKDX7mwr3qUVcYUNG8M9ihYmw9Ppvkqe9EMK3znpYi92jzNuvLsxCxspo0NtZ/DMSjcj6cK34CjUZFNgMPOYlKGchFvU1ZZasbD3tVhvxymIWRGg==; 24:bndB7B9KJtoWCHltByz34koPKBwUnEppFbGsi2hC+NW02yaAuXX46HLqVjJly23tYRoHB/hpwUW+Mc3qJLZPDGBER7K1AryUBaDxpgPiutE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1394; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1394; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1394; x-forefront-prvs: 086943A159 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(479174004)(377454003)(51914003)(2950100001)(5005710100001)(2900100001)(92566002)(10290500002)(10400500002)(99286002)(4326007)(10090500001)(2906002)(40100003)(11100500001)(74316001)(15975445007)(5001960100004)(122556002)(6116002)(110136002)(189998001)(76176999)(50986999)(15650500001)(102836003)(586003)(5003600100002)(230783001)(19580395003)(3660700001)(3280700002)(87936001)(76576001)(5008740100001)(33656002)(1096002)(54356999)(86612001)(19580405001)(5002640100001)(86362001)(1220700001)(77096005)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1394; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2016 23:09:29.6086 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1394 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] -tokbind-protocol-04: verifying signature(s) in, TokenBindingMessage.TokenBinding? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 02 Mar 2016 23:09:53 -0000 PiBmaW5hbGx5LCBpZiBJJ20gdW5kZXJzdGFuZGluZyB0aGUgc2VjdXJpdHkgbW9kZWwgY29ycmVj dGx5LCBvbmUgYWx3YXlzIG5lZWRzIA0KPiB0byB1c2UgYW5kIHNpZ24gdGhlIHByZXNlbnQtc2Vy dmVyLUVLTSB3aGVuIHNlbmRpbmcgdGhlIFRva2VuQmluZGluZ01lc3NhZ2UgDQo+IHRvIHRoZSBw cmVzZXQgc2VydmVyLCByZWdhcmRsZXNzIG9mIHRoZSB0eXBlIG9mIGNvbnRhaW5lZCBUb2tlbkJp bmRpbmdzIA0KPiAocHJvdmlkZWQgb3IgcmVmZXJyZWQpLCBiZWNhdXNlIG90aGVyd2lzZSB0aGUg c2VydmVyIHdvbid0IGhhdmUgDQo+IGNyeXB0b2dyYXBoaWMgcHJvb2Ytb2YtcG9zc2Vzc2lvbiBv ZiB0aGUgcHJpdmF0ZSBrZXlzLiBUaHVzIHRoaXMgbWlnaHQgYXMgDQo+IHdlbGwgYmUgc3BlY2lm aWVkIGluIG9uZSBjZW50cmFsIHBsYWNlIC0tIGkuZS4sIC10b2tiaW5kLXByb3RvY29sLg0KDQpZ ZXMsIGFuZCBJIHRoaW5rIHdlIGNhbiBtYWtlIGEgc2ltcGxlIGNsYXJpZmljYXRpb24gaW4gVEJQ Uk9UTywgd2l0aG91dCBhZGRpbmcgZmVkZXJhdGlvbiBjb250ZW50IHRvIGl0LiBUaGUgSS1EIGN1 cnJlbnRseSBzYXlzOg0KIiBUaGUgVG9rZW4gQmluZGluZyBtZXNzYWdlIGNvbnNpc3RzIG9mIGEg c2VyaWVzIG9mIFRva2VuQmluZGluZw0KICAgc3RydWN0dXJlcyBjb250YWluaW5nIHRoZSB0eXBl IG9mIHRoZSB0b2tlbiBiaW5kaW5nLCB0aGUNCiAgIFRva2VuQmluZGluZ0lELCBhIHNpZ25hdHVy ZSBvdmVyIHRoZSBleHBvcnRlZCBrZXlpbmcgbWF0ZXJpYWwgKEVLTSkNCiAgIHZhbHVlLCBvcHRp b25hbGx5IGZvbGxvd2VkIGJ5IEV4dGVuc2lvbiBzdHJ1Y3R1cmVzLiINCg0KV2UgY291bGQgYWRk Og0KIiBUaGUgRUtNIE1VU1QgYmUgb2J0YWluZWQgZnJvbSB0aGUgVExTIGNvbm5lY3Rpb24gdGhh dCBpcyB1c2VkIHRvIHNlbmQgdGhlIFRva2VuIEJpbmRpbmcgbWVzc2FnZS4iDQoNCkFkZGluZyBm ZWRlcmF0aW9uLXJlbGF0ZWQgY29udGVudCB0byBUQlBST1RPIHNlZW1zIHVuZGVzaXJhYmxlLCBi ZWNhdXNlIGZlZGVyYXRpb24gbWVjaGFuaXNtcyBhcmUgaGlnaGx5IGFwcGxpY2F0aW9uIHByb3Rv Y29sLXNwZWNpZmljLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogPUplZmZIIFttYWlsdG86SmVmZi5Ib2RnZXNAS2luZ3NNb3VudGFpbi5j b21dIA0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyLCAyMDE2IDI6MTAgUE0NClRvOiBBbmRyZWkg UG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPg0KQ2M6ID1KZWZmSCA8SmVmZi5Ib2Rn ZXNAS2luZ3NNb3VudGFpbi5jb20+OyBJRVRGIFRva2JpbmQgV0cgPHVuYmVhcmFibGVAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIC10b2tiaW5kLXByb3RvY29sLTA0OiB2ZXJp Znlpbmcgc2lnbmF0dXJlKHMpIGluLCBUb2tlbkJpbmRpbmdNZXNzYWdlLlRva2VuQmluZGluZz8N Cg0KYm90dG9tLXBvc3RlZC4uDQoNCk9uIDAzLzAxLzIwMTYgMDc6MjYgUE0sID1KZWZmSCB3cm90 ZToNCiA+DQogPiBOaWNrIHdyb3RlOg0KID4gID4gTXkgdW5kZXJzdGFuZGluZyBvZiByZWZlcnJl ZCB0b2tlbiBiaW5kaW5ncyBpcyB0aGF0IHRoZSBzaWduYXR1cmUgaW4gdGhlICA+ICA+IFRva2Vu QmluZGluZyBzdHJ1Y3QgaXMgb3ZlciB0aGUgc2FtZSBFS00gdmFsdWUgZm9yIGFsbCBUb2tlbkJp bmRpbmcgID4gID4gc3RydWN0cyBpbiB0aGUgVG9rZW5CaW5kaW5nTWVzc2FnZS4gVGhhdCBpcywg d2hlbiBzZXJ2ZXIgQSBzZW5kcyB0aGUgID4gID4gSW5jbHVkZS1SZWZlcmVyLVRva2VuLUJpbmRp bmctSUQgYW5kIHJlZGlyZWN0cyB0byBzZXJ2ZXIgQiwgdGhlICA+ICA+IFRva2VuQmluZGluZ01l c3NhZ2Ugc2VudCB0byBzZXJ2ZXIgQiBoYXMgYSBwcm92aWRlZCBUb2tlbkJpbmRpbmcgd2l0aCAg PiAgPiB0aGUgY2xpZW50J3MgVG9rZW5CaW5kaW5nSUQgZm9yIHNlcnZlciBCIGFuZCBhIHNpZ25h dHVyZSBvZiB0aGUgRUtNIGZvciAgPiAgPiB0aGUgY29ubmVjdGlvbiB0byBzZXJ2ZXIgQiwgYW5k IGEgcmVmZXJyZWQgVG9rZW5CaW5kaW5nIHdpdGggdGhlICA+ICA+IGNsaWVudCdzIFRva2VuQmlu ZGluZ0lEIGZvciBzZXJ2ZXIgQSBhbmQgYSBzaWduYXR1cmUgb2YgdGhlIEVLTSBmb3IgdGhlICA+ ICA+IGNvbm5lY3Rpb24gdG8gc2VydmVyIEIuIFRoaXMgd2F5LCBzZXJ2ZXIgQiBjYW4gdmVyaWZ5 IHRoZSBzaWduYXR1cmUgZm9yICA+ICA+IGJvdGgga2V5cyAoYXNzdW1pbmcgc2VydmVyIEIgc3Vw cG9ydHMgdGhlIGtleSBwYXJhbWV0ZXIgdXNlZCBmb3IgdGhlICA+ICA+IHJlZmVycmVkIFRva2Vu QmluZGluZykuDQogPg0KID4gVGhhbmtzIGZvciB0aGUgZGV0YWlsZWQgZXhwbGFuYXRpb24sIHRo YXQgbWFrZXMgc2Vuc2UuDQogPg0KID4NCiA+IEFuZHJlaSBhZGRlZDoNCiA+ICA+IENvcnJlY3Qs IGluIG9yZGVyIGZvciBhIHNlcnZlciB0byB2ZXJpZnkgdGhlIGJpbmRpbmcsIHRoZSBzaWduYXR1 cmUgaGFzICA+ICA+IHRvIGJlIG92ZXIgdGhlIEVLTSBvZiB0aGUgVExTIGNvbm5lY3Rpb24gd2l0 aCB0aGlzIHNlcnZlci4gU3VjaCAgPiAgPiBmZWRlcmF0aW9uIHNjZW5hcmlvcyBhcmUgZGVzY3Jp YmVkIGluIGRldGFpbCBpbiBzZWN0aW9uIDMuMiBvZiBIVFRQU1RCOg0KID4gID4gaHR0cHM6Ly9u YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0 b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1pZXRmLXRva2JpbmQtaHR0cHMtMDIlMjNzZWN0 aW9uLTMuMiZkYXRhPTAxJTdjMDElN2NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdjZmI0 NDQ3MDYzYTg4NDAyMGY2N2UwOGQzNDJlNzYxOGUlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk MDExZGI0NyU3YzEmc2RhdGE9Z2lWZWRiUDhKU3hWNlk4bnFKRGR6dkpBTDlTV1pXWHdpeDVoTktK Y2JCdyUzZA0KID4NCiA+IEhvd2V2ZXIsIGl0IHNlZW1zIHRoZSBkZXRhaWxzIHdydCB3aGljaCBF S00gaXMgc2lnbmVkIGZvciAgPiByZWZlcnJlZF90b2tlbl9iaW5kaW5ncyBpcyBub3QgZXhwbGlj aXRseSBzdGF0ZWQgQUZBSUNUIGluIGVpdGhlciAgPiAtdG9rYmluZC1odHRwcy0wMiBvciBpbiAt dG9rYmluZC1wcm90b2NvbC0wNC4gQWx0aG91Z2ggc29tZSBmb2xrcyBoYXZlICA+IG9idmlvdXNs eSBmaWd1cmVkIGl0IG91dCwgaXQgbWF5IGJlIGRpZmZpY3VsdCBmb3Igb3RoZXJzIChJIHNwb3Nl IEknbSBvbmUgb2YgID4gJ2VtKS4NCiA+DQogPiBTbywgSSJ2ZSBjcmFmdGVkIHVwIHNvbWUgbW9k ZXN0IG1vZHMgdG8gLXRva2JpbmQtcHJvdG9jb2wtMDQgdGhhdCBtYWtlIHRoaXMgID4gc3R1ZmYg ZXhwbGljaXQuIFRoZSBzb3VyY2UgY2FuIGJlIHBlcnVzZWQgaGVyZS4uDQogPg0KID4gaHR0cHM6 Ly9naXRodWIuY29tL1Rva2VuQmluZGluZy9JbnRlcm5ldC1EcmFmdHMvcHVsbC8xNg0KID4NCiA+ IC4uYW5kIGEgZm9ybWF0dGVkIGRpZmYgaXMgaGVyZS4uDQogPg0KID4NCjxodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJma2luZ3Nt b3VudGFpbi5jb20lMmZkb2MlMmZkaWZmJTJmRGlmZi0tZHJhZnQtaWV0Zi10b2tiaW5kLXByb3Rv Y29sLTA0LnR4dC0tdG8tLWRyYWZ0LWlldGYtdG9rYmluZC1wcm90b2NvbC0wNGMudHh0Lmh0bWwm ZGF0YT0wMSU3YzAxJTdjQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3Y2ZiNDQ0NzA2M2E4 ODQwMjBmNjdlMDhkMzQyZTc2MThlJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N2MxJnNkYXRhPWolMmJQWW10N0FzMzl0QTY0Q2tYSjNobkxWWXBpMGg4cnVmSnJOY1hqRjB2YyUz ZD4gDQoNCg0KDQpBbmRyZWkgcmVwbGllZDoNCiA+IEl0IGlzIGEgZ29vZCBpZGVhIHRvIGNsYXJp Znkgd2hpY2ggRUtNIGlzIHNpZ25lZA0KDQphZ3JlZWQsIHRoeC4NCg0KID4gaW4gZWFjaCBsZWcg b2YgdGhlDQogPiBmZWRlcmF0aW9uIHNjZW5hcmlvLiBJIGJlbGlldmUgdGhpcyB3aWxsIGJlIGEg YmV0dGVyIGZpdCBpbiB0aGUgSFRUUFNUQg0KID4gZHJhZnQsIHdoaWNoIHRhbGtzIGFib3V0IGFs bCB0aGluZ3MgZmVkZXJhdGlvbi4NCg0KaG0sIEkgZG9uJ3QgdGhpbmsgdGhhdCdzIHRoZSB3YXkg dG8gZ28gZm9yIHZhcmlvdXMgcmVhc29ucywgZS5nLiwgDQotdG9rYmluZC1wcm90b2NvbCAoYWth IFRCUFJPVE8pLi4NCg0KMS4gZGVmaW5lcyBUb2tlbkJpbmRpbmdUeXBlIChwcm92aWRlZCBhbmQg cmVmZXJyZWQpLA0KDQoyLiBzcGVjaWZpZXMgdGhlIHNpZ25hdHVyZS1vdmVyLUVLTShzKSBtZWNo YW5pc20uDQoNClBsdXMsIEhUVFBTVEIgKGFrYSAtdG9rYmluZC1odHRwcykgaXMgSFRUUC1zcGVj aWZpYy4gSWYgc29tZSBvdGhlciBhcHAgDQpwcm90b2NvbCAoZWcgU0lQPykgdGhhdCBsYXllcnMg b3ZlciBUTFMgbGV2ZXJhZ2VzIFRva0JpbmQgYW5kIGhhcyBuZWVkIGZvciANCnVzaW5nIHJlZmVy cmVkX3Rva2VuX2JpbmRpbmcsIHRoZW4gZXZlcnl0aGluZyB0aGV5IG5lZWQgdG8ga25vdyBvdWdo dCB0byBiZSANCmNvbnRhaW5lZCBpbiBUQlBST1RPIGFuZCBUQk5FR08gLS0gdGhleSBhcmVuJ3Qg bmVjZXNzYXJpbHkgZ29pbmcgdG8gcGF5IA0KYXR0ZW50aW9uIHRvIC10b2tiaW5kLWh0dHBzLg0K DQphZGR0aW9uYWxseSwgLXRva2JpbmQtaHR0cHMgZG9lcyBub3Qgc3BlY2lmaWNhbGx5IG1lbnRp b24gdGhlIHNpZ25hdHVyZSANCm1lY2hhbmlzbSB1c2VkIGluIHRoZSBUb2tlbkJpbmRpbmdNZXNz YWdlLCBpLmUuLCBpdCBkb2Vzbid0IG1lbnRpb24gRUtNcyANCihvdGhlciB0aGFuIGluIHRoZSBT ZWN1cml0eSBDb25zKS4NCg0KcGx1cywgaW4gdGhlIC10b2tiaW5kLXByb3RvY29sIGNvbnRleHQg c3BlY2lmaWNhbGx5LCBhbGwgInJlZmVycmVkIiBzZWVtcyB0byANCm1lYW4gaXMgdGhhdCAidGhp cyBvdGhlciAzZC1wYXJ0eSBzZXJ2ZXIgc2FpZCBpdCBpcyBvayB0byByZXZlYWwgdG8geW91ICh0 aGUgDQoxc3QgcGFydHkgc2VydmVyKSBteSBUQklEIGZvciB0aGF0IG90aGVyIHNlcnZlciBhbmQg dG8gcHJvdmUgdG8geW91IG15IA0KcG9zc2Vzc2lvbiBvZiB0aGUgcHJpdmF0ZSBrZXkgYXNzb2Np YXRlZCB3aXRoIHNhaWQgVEJJRCIgLS0gaS5lLiB0aGUgZmFjdCANCnRoYXQgLXRva2JpbmQtaHR0 cHMgdXNlcyB0aGlzICJyZWZlcnJlZCIgYnVpbGRpbmcgYmxvY2sgdG8gYWNjb21tb2RhdGUgDQpp c3N1YW5jZSBhbmQgY29uc3VtcHRpb24gb2YgYm91bmQgImZlZGVyYXRlZCIgc2VjdXJpdHkgdG9r ZW5zIGF0IHRoZSBIVFRQIA0KbGF5ZXIgZG9lcyBub3QgbWVhbiB0aGF0IGl0LCAtdG9rYmluZC1o dHRwcywgbmVlZHMgdG8gZ2V0IGludG8gdGhlIGJ1c2luZXNzIA0Kb2Ygc3BlY2lmeWluZyB3aGlj aCBFS00gaXMgc2lnbmVkIGJ5IHdob20gcGVyIHRva2VuIGJpbmRpbmcgdHlwZS4NCg0KZmluYWxs eSwgaWYgSSdtIHVuZGVyc3RhbmRpbmcgdGhlIHNlY3VyaXR5IG1vZGVsIGNvcnJlY3RseSwgb25l IGFsd2F5cyBuZWVkcyANCnRvIHVzZSBhbmQgc2lnbiB0aGUgcHJlc2VudC1zZXJ2ZXItRUtNIHdo ZW4gc2VuZGluZyB0aGUgVG9rZW5CaW5kaW5nTWVzc2FnZSANCnRvIHRoZSBwcmVzZXQgc2VydmVy LCByZWdhcmRsZXNzIG9mIHRoZSB0eXBlIG9mIGNvbnRhaW5lZCBUb2tlbkJpbmRpbmdzIA0KKHBy b3ZpZGVkIG9yIHJlZmVycmVkKSwgYmVjYXVzZSBvdGhlcndpc2UgdGhlIHNlcnZlciB3b24ndCBo YXZlIA0KY3J5cHRvZ3JhcGhpYyBwcm9vZi1vZi1wb3NzZXNzaW9uIG9mIHRoZSBwcml2YXRlIGtl eXMuIFRodXMgdGhpcyBtaWdodCBhcyANCndlbGwgYmUgc3BlY2lmaWVkIGluIG9uZSBjZW50cmFs IHBsYWNlIC0tIGkuZS4sIC10b2tiaW5kLXByb3RvY29sLg0KDQpIVEgsDQoNCj1KZWZmSA0KDQoN Cg0KDQoNCg0KDQo= From nobody Thu Mar 3 13:53:45 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14DE1B2C95 for ; Thu, 3 Mar 2016 13:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 TLHechy0DTEY for ; Thu, 3 Mar 2016 13:53:42 -0800 (PST) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 019FD1B2C91 for ; Thu, 3 Mar 2016 13:53:39 -0800 (PST) Received: (qmail 27774 invoked by uid 0); 3 Mar 2016 21:53:37 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 3 Mar 2016 21:53:37 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id RZtU1s01A2UhLwi01ZtXx5; Thu, 03 Mar 2016 14:53:37 -0700 X-Authority-Analysis: v=2.1 cv=FouWoQbq c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=BbB3o22BIMkA:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=MSyYmFcRy0azI9MP_ywA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=s1KGsHcuvX4NlCzu68aXDUEHPgNI4suc0fi/16M82A0=; b=7WlLtySc32NV5VdeElIEvJlk7v uK9b6YOWRZsBi0kKCIG+xMBwxwudCAO6egg1EtgJjUEH2Da35YOS3DBVhq4ZNq2RkGx3PNmyrogS9 4RZQx7Th+Olsvk93fsTMETU2v; Received: from [173.224.162.79] (port=3580 helo=[192.168.86.135]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from ) id 1abbBY-0007p1-S2 for unbearable@ietf.org; Thu, 03 Mar 2016 14:53:28 -0700 To: IETF Tokbind WG From: =JeffH Message-ID: <56D8B256.60702@KingsMountain.com> Date: Thu, 3 Mar 2016 13:53:26 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 173.224.162.79 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: [Unbearable] -protocol-04 & -https-02: MITM TBID substitution in bound security tokens? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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, 03 Mar 2016 21:53:43 -0000 summary: if TokenBindingIDs (TBIDs) are contained within application security tokens (e.g., authn cookies, OIDC ID Tokens, SAML authn assertions, etc), or by reference, without the binding to said security tokens being integrity-protected in some fashion, then what prevents a man-in-the-middle (MITM) entity, as contextually defined in S 4.5 of -tokbind-https-02, from (in the simplest case) performing a cut-and-paste substitution of their TBID with the server, into said security token before conveying it to the server? This sec cons wrinkle doesn't seem to be addressed in either spec -- a security considerations suggestion is at the end below. HTH, =JeffH details: From HTTPSTB https://tools.ietf.org/html/draft-ietf-tokbind-https-02#section-4.5: > 4.5. Securing Federated Sign-On Protocols > > [...] > > o A man-in-the-middle is allowed to intercept the connection between > client and Token Consumer or between Client and Token Provider (or > both). > > The goal is to detect the presence of the man-in-the-middle in these > scenarios. > > First, consider a man-in-the-middle between the client and the Token > Provider. Recall that we assume that the client possesses a bound > authentication token (e.g., cookie) for the Token Provider. The man- > in-the-middle can intercept and modify any message sent by the client > to the Token Provider, and any message sent by the Token Provider to > the client. (This means, among other things, that the man-in-the- > middle controls the Javascript running at the client in the origin of > the Token Provider.) It is not, however, in possession of the > client's Token Binding key. Therefore, it can either choose to > replace the Token Binding key in requests from the client to the > Token Provider, and create a Token-Binding header that matches the > TLS connection between the man-in-the-middle and the Token Provider; > or it can choose to leave the Token-Binding header unchanged. > > If it chooses the latter, the signature in the Token Binding message > (created by the original client on the exported keying material (EKM) > for the connection between client and man-in-the-middle) will not > match the EKM between man-in-the-middle and the Token Provider. > > If it chooses the former (and creates its own signature, with its own > Token Binding key, over the EKM for the connection between man-in- > the-middle and Token Provider), then the Token Binding message will > match the connection between man-in-the-middle and Token Provider, > but the Token Binding key in the message will not match the Token > Binding key that the client's authentication token is bound to. In the case where the TBID is contained directly within the authn token, what is preventing the MITM from substituting its own TBID, for the MITM's token-bound TLS session with the Token Provider, within the client's authn token? See also S 6 (below) from TBPROTO -- >From TBPROTO https://tools.ietf.org/html/draft-ietf-tokbind-protocol-04#section-6 : > 6. Security Token Validation > > Security tokens can be bound to the TLS layer either by embedding the > Token Binding ID in the token, or by maintaining a database mapping > tokens to Token Binding IDs. The specific method of generating bound > security tokens is application-defined and beyond the scope of this > document. > > [...] Although I agree with the latter statement above wrt details of generating bound security tokens, are there not some overall security considerations that TBPROTO could/should mention? E.g.. The manner in which a Token Binding ID is bound to an application security token is application-defined, however, there are overall security considerations which the application developers and deployers should be aware of: it should not be possible for a MITM to substitute another TBID for the one bound to an app security token without detection. This can be accomplished in various ways, e.g., a directly-bound security token can be cryptographically integrity- protected, or, the TBID may be bound to the security token by reference in a fashion that is not susceptible to direct substitution. end From nobody Thu Mar 3 16:09:50 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5411B305A for ; Thu, 3 Mar 2016 16:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 dYWcjmdKLahE for ; Thu, 3 Mar 2016 16:09:46 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:720]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2CC1B3052 for ; Thu, 3 Mar 2016 16:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WNl0cN0MjQe3uj7oY8w3sajSeFsnHC0Q77QVzDcA45U=; b=iVYlRPpXuSCw8Vz8I+4RZRPZSvo3tPnYyoQ3cDOxiW7g367LyHxXJUM29QslRXLqvzLHZgP9HAAcyq/VShlYce3tA6Obb2iNewwO29I7pjzvR3pX6w6MH3y1IbdM0kLQ6LgUC12xTotgqrRJshxbfHBUc4R0LSXk452tlae5d2g= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.415.20; Fri, 4 Mar 2016 00:09:27 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0415.024; Fri, 4 Mar 2016 00:09:27 +0000 From: Andrei Popov To: =JeffH , IETF Tokbind WG Thread-Topic: [Unbearable] -protocol-04 & -https-02: MITM TBID substitution in bound security tokens? Thread-Index: AQHRdZctvc3dlqoZJEC3hnQkeEhsN59IaHsQ Date: Fri, 4 Mar 2016 00:09:26 +0000 Message-ID: References: <56D8B256.60702@KingsMountain.com> In-Reply-To: <56D8B256.60702@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: KingsMountain.com; dkim=none (message not signed) header.d=none;KingsMountain.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:c::1d2] x-ms-office365-filtering-correlation-id: 5a54ad22-cbcd-43fc-e2c2-08d343c14014 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:7u+ZI+UHi58tMH0E9UCgAqN4pXq0thL3DdEdJycCLCIhGZtQ3RKzzBQAnRXHJinsPd5pkD3VAO0M0yKH1+EMIbZZ/3OztoPgFMzMX/KOalIbS8Z8C+XJxc6+VahNPiVL+oBg35GJdarZMCAmACcqFw==; 24:qnzjMSc2jYNXBOfVucavCU8FBxX7isGoyDnuZ/aC7Eku/CwIj7kIoec4dQP1ROd4gS821dqqq3zozBMsJ5mpW8GobHObKZk/ORWzf0MCOQs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 0871917CDA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(13464003)(11100500001)(5002640100001)(5008740100001)(74316001)(3660700001)(5003600100002)(77096005)(15975445007)(1096002)(2950100001)(87936001)(1220700001)(102836003)(6116002)(76576001)(2906002)(3280700002)(2900100001)(50986999)(586003)(76176999)(54356999)(10090500001)(92566002)(5004730100002)(10400500002)(5005710100001)(10290500002)(33656002)(8990500004)(99286002)(40100003)(106116001)(122556002)(189998001)(107886002)(575784001)(5001770100001)(86362001)(86612001)(19580405001)(15650500001)(19580395003)(81166005)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2016 00:09:26.9575 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: Subject: Re: [Unbearable] -protocol-04 & -https-02: MITM TBID substitution in bound security tokens? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 04 Mar 2016 00:09:50 -0000 Yes, this looks like a useful security consideration. Unless folks object, = I will add this in the next revision. Thanks, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of =3DJeffH Sent: Thursday, March 3, 2016 1:53 PM To: IETF Tokbind WG Subject: [Unbearable] -protocol-04 & -https-02: MITM TBID substitution in b= ound security tokens? summary: if TokenBindingIDs (TBIDs) are contained within application secur= ity tokens (e.g., authn cookies, OIDC ID Tokens, SAML authn assertions, etc= ), or by reference, without the binding to said security tokens being integ= rity-protected in some fashion, then what prevents a man-in-the-middle (MITM) entity, as contextually defined in S 4.5 of -tokbind-https-02, from = (in the simplest case) performing a cut-and-paste substitution of their TBI= D with the server, into said security token before conveying it to the serv= er? This sec cons wrinkle doesn't seem to be addressed in either spec -- a secu= rity considerations suggestion is at the end below. HTH, =3DJeffH details: From HTTPSTB https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2ftools.ie= tf.org%2fhtml%2fdraft-ietf-tokbind-https-02%23section-4.5%3a&data=3D01%7c01= %7cAndrei.Popov%40microsoft.com%7c0994d7e8f3ac46a1cdaa08d343ae4e0c%7c72f988= bf86f141af91ab2d7cd011db47%7c1&sdata=3DOrOoi9teVWJ6htB086I6nCu7i7jleChQrV1p= o7ZMoDE%3d > 4.5. Securing Federated Sign-On Protocols > > [...] > > o A man-in-the-middle is allowed to intercept the connection between > client and Token Consumer or between Client and Token Provider (or > both). > > The goal is to detect the presence of the man-in-the-middle in these > scenarios. > > First, consider a man-in-the-middle between the client and the Token > Provider. Recall that we assume that the client possesses a bound > authentication token (e.g., cookie) for the Token Provider. The man- > in-the-middle can intercept and modify any message sent by the client > to the Token Provider, and any message sent by the Token Provider to > the client. (This means, among other things, that the man-in-the- > middle controls the Javascript running at the client in the origin of > the Token Provider.) It is not, however, in possession of the > client's Token Binding key. Therefore, it can either choose to > replace the Token Binding key in requests from the client to the > Token Provider, and create a Token-Binding header that matches the > TLS connection between the man-in-the-middle and the Token Provider; > or it can choose to leave the Token-Binding header unchanged. > > If it chooses the latter, the signature in the Token Binding message > (created by the original client on the exported keying material (EKM) > for the connection between client and man-in-the-middle) will not > match the EKM between man-in-the-middle and the Token Provider. > > If it chooses the former (and creates its own signature, with its own > Token Binding key, over the EKM for the connection between man-in- > the-middle and Token Provider), then the Token Binding message will > match the connection between man-in-the-middle and Token Provider, > but the Token Binding key in the message will not match the Token > Binding key that the client's authentication token is bound to. In the case where the TBID is contained directly within the authn token, wh= at is preventing the MITM from substituting its own TBID, for the MITM's to= ken-bound TLS session with the Token Provider, within the client's authn to= ken? See also S 6 (below) from TBPROTO -- >From TBPROTO https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2ftools.ie= tf.org%2fhtml%2fdraft-ietf-tokbind-protocol-04%23section-6&data=3D01%7c01%7= cAndrei.Popov%40microsoft.com%7c0994d7e8f3ac46a1cdaa08d343ae4e0c%7c72f988bf= 86f141af91ab2d7cd011db47%7c1&sdata=3DKAsvD1MIU18OHAsT7asxtIT6FkJQ%2bdUz5yCV= esw3PKU%3d : > 6. Security Token Validation > > Security tokens can be bound to the TLS layer either by embedding the > Token Binding ID in the token, or by maintaining a database mapping > tokens to Token Binding IDs. The specific method of generating bound > security tokens is application-defined and beyond the scope of this > document. > > [...] Although I agree with the latter statement above wrt details of generating = bound security tokens, are there not some overall security considerations t= hat TBPROTO could/should mention? E.g.. The manner in which a Token Binding ID is bound to an application security token is application-defined, however, there are overall security considerations which the application developers and deployers should be aware of: it should not be possible for a MITM to substitute another TBID for the one bound to an app security token without detection. This can be accomplished in various ways, e.g., a directly-bound security token can be cryptographically integrity- protected, or, the TBID may be bound to the security token by reference in a fashion that is not susceptible to direct substitution. end _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7cAndrei.Popov%40micr= osoft.com%7c0994d7e8f3ac46a1cdaa08d343ae4e0c%7c72f988bf86f141af91ab2d7cd011= db47%7c1&sdata=3DiYoMPO22FAoGFtrAaczPCvW7q8qoP5A6%2beI52XCZ%2bfA%3d From nobody Thu Mar 3 19:00:53 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11561B2F7E for ; Thu, 3 Mar 2016 19:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 YHe1pc1gjR7j for ; Thu, 3 Mar 2016 19:00:50 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id B06881B2F7A for ; Thu, 3 Mar 2016 19:00:50 -0800 (PST) Received: (qmail 24454 invoked by uid 0); 4 Mar 2016 03:00:47 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy9.mail.unifiedlayer.com with SMTP; 4 Mar 2016 03:00:47 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id Rf0f1s0062UhLwi01f0ieP; Thu, 03 Mar 2016 20:00:45 -0700 X-Authority-Analysis: v=2.1 cv=O8aq4nNW c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=O4JpR-GPhiwse4O4zcoA:9 a=bSHkwNbTnbNke_BH:21 a=paIoyLUaj7C9-mpy:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=HyXHBZ53sh9YoOEZxW8/yXbcLqWNn91iWxj+quFGgjc=; b=KqmoDVo7vubZg8G6XBN+jOTJ/V fvIQnr/RWKF9I75Z21MYBapI4f5UI6vGNBFapEz/pggH4BNYmOw2Z4zw90IATFHzhpwPVzepMVDPK 9jGj7RLPuKlSKXe678kHh6urh; Received: from [73.202.80.238] (port=41762 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from ) id 1abfyq-0001gF-8A for unbearable@ietf.org; Thu, 03 Mar 2016 20:00:40 -0700 To: IETF Tokbind WG From: =JeffH Message-ID: <56D8FA54.3050508@KingsMountain.com> Date: Thu, 3 Mar 2016 19:00:36 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: [Unbearable] -tokbind-protocol-04: Security considerations incomplete? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 04 Mar 2016 03:00:52 -0000 Hi, Wrt ... > 8. Security Considerations > > 8.1. Security Token Replay > > The goal of the Token Binding protocol is to prevent attackers from > exporting and replaying security tokens, thereby impersonating > legitimate users and gaining access to protected resources. Bound > tokens can still be replayed by the malware present in the User > Agent. In order to export the token to another machine and > successfully replay it, the attacker also needs to export the > corresponding private key. Token Binding private keys are therefore > high-value assets and SHOULD be strongly protected, ideally by > generating them in a hardware security module that prevents key > export. The above, wrt an active & external attacker needing to also wield the client's TB private key, is succinct but may not be intuitively obvious to the reader, plus it does not describe possible consequences/exploit scenarios. Also, there are not (in TBPROTO) security considerations discussing impersonation and MITM scenarios, and thus its sec cons are arguably incomplete. C.f. https://tools.ietf.org/html/rfc3552 Overviews of such scenarios could be provided, e.g., by leveraging and generalizing the HTTP-specific analysis in -tokbind-https-02 sections 4.4 & 4.5 which appear to address these issues, and also fill-in some of the background for S 8.1 above. Having complete sec cons in TBPROTO will arguably be helpful to non-HTTP protocols/apps employing TLS that may wish to leverage TLS Token Binding, and may not review -tokbind-https. HTH, =JeffH From nobody Thu Mar 3 19:01:50 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07561B2FE6 for ; Thu, 3 Mar 2016 19:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 JwRf4_Su2vUV for ; Thu, 3 Mar 2016 19:01:48 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 230931B2FB5 for ; Thu, 3 Mar 2016 19:01:48 -0800 (PST) Received: (qmail 16650 invoked by uid 0); 4 Mar 2016 03:01:47 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy6.mail.unifiedlayer.com with SMTP; 4 Mar 2016 03:01:47 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id Rm1f1s00H2UhLwi01m1iC0; Fri, 04 Mar 2016 03:01:44 -0700 X-Authority-Analysis: v=2.1 cv=GOWbTI9K c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7OsogOcEt9IA:10 a=g7-_gZEWvWoGEcy8hRgA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=ISOp4YqcA/4MBk2Xx9775PuDdypFWZqhKurJzCG8ylU=; b=e522Sr2Ix2TvfTHuwVQwv7MiPq FLVl6hqZaNhk1QAWK13lJ+RnL5G9FB48i8k44jYGGK5eNrMWL+N9a8KnL1fdfyS+BL6NLnIk7xnOK NsTmlzn6RKhxotN6x496AEIyf; Received: from [73.202.80.238] (port=41766 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from ) id 1abfzq-0002U6-1h for unbearable@ietf.org; Thu, 03 Mar 2016 20:01:42 -0700 To: IETF Tokbind WG From: =JeffH Message-ID: <56D8FA93.6000900@KingsMountain.com> Date: Thu, 3 Mar 2016 19:01:39 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: [Unbearable] -tokbind-protocol-04: version mismatch between negotiation and TB msg? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 04 Mar 2016 03:01:49 -0000 Hi, The TB ProtocolVersion and TokenBindingKeyParameters are negotiated in the TLS handshake as specified in -tokbind-negotiation-02, but there is no version indication in TokenBindingMessage (defined in tokbind-protocol-04 aka TBPROTO). Also, the criteria for incrementing the TB protocol version is not stipulated in either spec. Would the TB protocol version be incremented only due to changes to any of the structs defined in TBPROTO? It seems that defining a TB extension would not necessitate a TB protocol version increment because TBPROTO says that impls must ignore extensions they do not understand. However, what about if a new TokenBindingType is defined? I suppose that it could be side-stepped by stipulating that servers must ignore any TokenBindingMessage. TokenBinding.tokenbinding_type they do not understand. This is not presently stated AFAICT. Also there are no stipulations in TBPROTO that the TokenBindingMessage MUST be of the same version negotiated at the TLS layer -- however, there are such stipulations wrt key parameters. HTH, =JeffH From nobody Thu Mar 3 19:29:52 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7591B3240 for ; Thu, 3 Mar 2016 19:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.067 X-Spam-Level: X-Spam-Status: No, score=-101.067 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 91KpDQCc1AJj for ; Thu, 3 Mar 2016 19:29:48 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 53AD01B323F for ; Thu, 3 Mar 2016 19:29:48 -0800 (PST) Received: (qmail 5597 invoked by uid 0); 4 Mar 2016 03:29:44 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 4 Mar 2016 03:29:44 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id RfVb1s00E2UhLwi01fVepT; Thu, 03 Mar 2016 20:29:42 -0700 X-Authority-Analysis: v=2.1 cv=PPOcp5aC c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7OsogOcEt9IA:10 a=NEAV23lmAAAA:8 a=F0BeyRXEmr0XoGDuREsA:9 a=YjenX7mqlNH03EAb:21 a=WHAOSTQwXfnDhtRj:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:Cc:To; bh=1E1I69C1M4vrPOku3RUgNnTweY0Y3aCzOWM48n6/zIU=; b=O/ZtCy0LgbA4yL8A2fa8SkRTeQ ez+suFkr8A3/N+D4gNNacq9roeFbBEFU7qAtdntn+/bZ/r8xaxDG69UKZRapdBNYjEldOavGNwqaW oOG0HXAzzzt4YNlxhR+NGlxSB; Received: from [73.202.80.238] (port=41882 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from ) id 1abgQq-0006gU-VD; Thu, 03 Mar 2016 20:29:37 -0700 To: Andrei Popov From: =JeffH Message-ID: <56D9011E.1050701@KingsMountain.com> Date: Thu, 3 Mar 2016 19:29:34 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] -tokbind-protocol-04: verifying signature(s) in TokenBindingMessage.TokenBinding? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 04 Mar 2016 03:29:49 -0000 Andrei wrote: >> finally, if I'm understanding the security model correctly, one always needs >> to use and sign the present-server-EKM when sending the TokenBindingMessage >> to the preset server, regardless of the type of contained TokenBindings >> (provided or referred), because otherwise the server won't have >> cryptographic proof-of-possession of the private keys. Thus this might as >> well be specified in one central place -- i.e., -tokbind-protocol. > > Yes, and I think we can make a simple clarification in TBPROTO, without > adding federation content to it. The I-D currently says: > " The Token Binding message consists of a series of TokenBinding > structures containing the type of the token binding, the > TokenBindingID, a signature over the exported keying material (EKM) > value, optionally followed by Extension structures." > > We could add: > " The EKM MUST be obtained from the TLS connection that is used to send > the Token Binding message." > > Adding federation-related content to TBPROTO seems undesirable, because > federation mechanisms are highly application protocol-specific. hm, a couple thoughts.. * -tokbind-protocol-04 already contains this language.. [I-D.ietf-tokbind-https] also describes Token Binding between multiple communicating parties: User Agent, Identity Provider and Relying Party. ..which is pretty clearly describing federation. * more importantly, by virtue of defining the TokenBindingType of "referred_token_binding", TBPROTO is already tiptoe'g into the "multiple communicating parties" morass (aka "federation"). Perhaps if we think that pretty much only HTTP will make use of the TokenBindingType of "referred_token_binding", then maybe that TB type ought to be defined and IANA-regisgtered in -tokbind-https -- in that way it seems all mention of the "referred" TB concept can be excised from TBPROTO. The latter spec would still establish the TB type registry. Otherwise, I tend to think that embodies what needs to be done in TBPROTO to have proper processing rules for referred Token Bindings. In any case, in my view, the processing rules language in TBPROTO could be usefully stated more clearly and my overall suggestions regarding that are embodied in the above-linked PR #16. HTH, =JeffH From nobody Fri Mar 4 08:49:41 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5B61A1A5D for ; Fri, 4 Mar 2016 08:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_61=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 auWD6zfwxcaL for ; Fri, 4 Mar 2016 08:49:37 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 527951A1A1D for ; Fri, 4 Mar 2016 08:49:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SwDiHRW1G4XAsBD+iocZTbgeObz21kC3kAaMOcis/UI=; b=NP10Rg4le1Hd738KyQpeX63SBarHANQn+ZT1dLjYCVnc/UqbG/CsmKul2HsuSVzyJ6qfLNJpbwom2yRKbrqiSjhWmGOq9dqGDtlUAK6jCMCHcd4bilGN8eugZPS73L8nNyWgwBUQnt1a1ykbdU+comNlGlbr6KCtO45kSCh1JFM= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.415.20; Fri, 4 Mar 2016 16:49:15 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0415.024; Fri, 4 Mar 2016 16:49:15 +0000 From: Andrei Popov To: =JeffH Thread-Topic: [Unbearable] -tokbind-protocol-04: verifying signature(s) in TokenBindingMessage.TokenBinding? Thread-Index: AQHRdcYZ50G3yg8Wh0CzgHElTck4WZ9JflhA Date: Fri, 4 Mar 2016 16:49:14 +0000 Message-ID: References: <56D9011E.1050701@KingsMountain.com> In-Reply-To: <56D9011E.1050701@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: KingsMountain.com; dkim=none (message not signed) header.d=none;KingsMountain.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:c::1d2] x-ms-office365-filtering-correlation-id: 67b89b00-4e34-4186-f7ba-08d3444ceb9e x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:mAnarFKWOnafrOHDxSwNzjCecvVQ0s8F7CGC2+waw19PuFr0400j8+TAd/DYs8AgpfDTHU6VyE63KEZ3ZUCedpyAWTkyVhcmisQxypFVhyiBVL+MDABlMUvuKywMfrftRLUcv6mCg5ozQG6tBgrsNg==; 24:422cE078Cn2nnmIrjrGu3Sx694yCd+koB0ZMZD1qdmc+72WX4q/IfHZiP9SDxCb8YPdqL40WOozt+Y488rRXmtKjXwE2EVZU8KUmGG3z6bA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 0871917CDA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(24454002)(5005710100001)(10400500002)(10290500002)(11100500001)(5003600100002)(5002640100001)(92566002)(10090500001)(81166005)(86362001)(6116002)(102836003)(586003)(86612001)(1096002)(3280700002)(1220700001)(87936001)(3660700001)(2906002)(5008740100001)(4326007)(50986999)(76176999)(15975445007)(230783001)(2950100001)(76576001)(2900100001)(106116001)(15650500001)(54356999)(74316001)(40100003)(122556002)(99286002)(110136002)(189998001)(33656002)(19580395003)(19580405001)(77096005)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2016 16:49:14.7201 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] -tokbind-protocol-04: verifying signature(s) in TokenBindingMessage.TokenBinding? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 04 Mar 2016 16:49:40 -0000 Pi4uLiBUQlBST1RPIGlzIGFscmVhZHkgdGlwdG9lJ2cgaW50byB0aGUgIm11bHRpcGxlIGNvbW11 bmljYXRpbmcgcGFydGllcyIgbW9yYXNzIChha2EgImZlZGVyYXRpb24iKS4NCkl0IGRpZCwgd2l0 aCB0aGUgZ29hbCBvZiBkZWZpbmluZyBhbGwgdGhlIFRva2VuIEJpbmRpbmcgdHlwZXMgd2UgY3Vy cmVudGx5IGtub3cgb2YgaW4gb25lIGRvY3VtZW50Lg0KDQo+IC4uLiB0aGVuIG1heWJlIHRoYXQg VEIgdHlwZSBvdWdodCB0byBiZSBkZWZpbmVkIGFuZCBJQU5BLXJlZ2lzZ3RlcmVkIGluIC10b2ti aW5kLWh0dHBzIC0tIGluIHRoYXQgd2F5IGl0IHNlZW1zIGFsbCBtZW50aW9uIG9mIHRoZSAicmVm ZXJyZWQiIFRCIGNvbmNlcHQgY2FuIGJlIGV4Y2lzZWQgZnJvbSBUQlBST1RPLiAgDQpNeSBwcmVm ZXJlbmNlIGlzIHRvIGRvIHRoaXMsIGlmIEkgaGF2ZSB0bywgcmF0aGVyIHRoYW4gYnJpbmdpbmcg bW9yZSBmZWRlcmF0aW9uIGxhbmd1YWdlIGludG8gVEJST1RPLiBFdmVuIGJldHRlciwgd2UgY2Fu IGp1c3QgYWRkIG9uZSBzZW50ZW5jZSBleHBsaWNpdGx5IHNheWluZyB0aGF0IEVLTSBjb21lcyBm cm9tIHRoZSBzYW1lIFRMUyBjb25uZWN0aW9uIHRoYXQgY2FycmllcyB0aGUgc2lnbmF0dXJlIG92 ZXIgdGhpcyBFS00sIGFuZCBhdm9pZCBhbnkgYW1iaWd1aXR5Lg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogPUplZmZIIFttYWlsdG86SmVmZi5Ib2RnZXNAS2luZ3NNb3VudGFp bi5jb21dIA0KU2VudDogVGh1cnNkYXksIE1hcmNoIDMsIDIwMTYgNzozMCBQTQ0KVG86IEFuZHJl aSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+DQpDYzogSUVURiBUb2tiaW5kIFdH IDx1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtVbmJlYXJhYmxlXSAtdG9rYmlu ZC1wcm90b2NvbC0wNDogdmVyaWZ5aW5nIHNpZ25hdHVyZShzKSBpbiBUb2tlbkJpbmRpbmdNZXNz YWdlLlRva2VuQmluZGluZz8NCg0KQW5kcmVpIHdyb3RlOg0KID4+IGZpbmFsbHksIGlmIEknbSB1 bmRlcnN0YW5kaW5nIHRoZSBzZWN1cml0eSBtb2RlbCBjb3JyZWN0bHksIG9uZSBhbHdheXMgbmVl ZHMgID4+IHRvIHVzZSBhbmQgc2lnbiB0aGUgcHJlc2VudC1zZXJ2ZXItRUtNIHdoZW4gc2VuZGlu ZyB0aGUgVG9rZW5CaW5kaW5nTWVzc2FnZSAgPj4gdG8gdGhlIHByZXNldCBzZXJ2ZXIsIHJlZ2Fy ZGxlc3Mgb2YgdGhlIHR5cGUgb2YgY29udGFpbmVkIFRva2VuQmluZGluZ3MgID4+IChwcm92aWRl ZCBvciByZWZlcnJlZCksIGJlY2F1c2Ugb3RoZXJ3aXNlIHRoZSBzZXJ2ZXIgd29uJ3QgaGF2ZSAg Pj4gY3J5cHRvZ3JhcGhpYyBwcm9vZi1vZi1wb3NzZXNzaW9uIG9mIHRoZSBwcml2YXRlIGtleXMu IFRodXMgdGhpcyBtaWdodCBhcyAgPj4gd2VsbCBiZSBzcGVjaWZpZWQgaW4gb25lIGNlbnRyYWwg cGxhY2UgLS0gaS5lLiwgLXRva2JpbmQtcHJvdG9jb2wuDQogPg0KID4gWWVzLCBhbmQgSSB0aGlu ayB3ZSBjYW4gbWFrZSBhIHNpbXBsZSBjbGFyaWZpY2F0aW9uIGluIFRCUFJPVE8sIHdpdGhvdXQg ID4gYWRkaW5nIGZlZGVyYXRpb24gY29udGVudCB0byBpdC4gVGhlIEktRCBjdXJyZW50bHkgc2F5 czoNCiA+ICIgVGhlIFRva2VuIEJpbmRpbmcgbWVzc2FnZSBjb25zaXN0cyBvZiBhIHNlcmllcyBv ZiBUb2tlbkJpbmRpbmcNCiA+ICAgIHN0cnVjdHVyZXMgY29udGFpbmluZyB0aGUgdHlwZSBvZiB0 aGUgdG9rZW4gYmluZGluZywgdGhlDQogPiAgICBUb2tlbkJpbmRpbmdJRCwgYSBzaWduYXR1cmUg b3ZlciB0aGUgZXhwb3J0ZWQga2V5aW5nIG1hdGVyaWFsIChFS00pDQogPiAgICB2YWx1ZSwgb3B0 aW9uYWxseSBmb2xsb3dlZCBieSBFeHRlbnNpb24gc3RydWN0dXJlcy4iDQogPg0KID4gV2UgY291 bGQgYWRkOg0KID4gIiBUaGUgRUtNIE1VU1QgYmUgb2J0YWluZWQgZnJvbSB0aGUgVExTIGNvbm5l Y3Rpb24gdGhhdCBpcyB1c2VkIHRvIHNlbmQgID4gIHRoZSBUb2tlbiBCaW5kaW5nIG1lc3NhZ2Uu Ig0KID4NCiA+IEFkZGluZyBmZWRlcmF0aW9uLXJlbGF0ZWQgY29udGVudCB0byBUQlBST1RPIHNl ZW1zIHVuZGVzaXJhYmxlLCBiZWNhdXNlICA+IGZlZGVyYXRpb24gbWVjaGFuaXNtcyBhcmUgaGln aGx5IGFwcGxpY2F0aW9uIHByb3RvY29sLXNwZWNpZmljLg0KDQpobSwgYSBjb3VwbGUgdGhvdWdo dHMuLg0KDQoqIC10b2tiaW5kLXByb3RvY29sLTA0IGFscmVhZHkgY29udGFpbnMgdGhpcyBsYW5n dWFnZS4uDQoNCiAgICBbSS1ELmlldGYtdG9rYmluZC1odHRwc10gYWxzbyBkZXNjcmliZXMgVG9r ZW4gQmluZGluZyBiZXR3ZWVuDQogICAgbXVsdGlwbGUgY29tbXVuaWNhdGluZyBwYXJ0aWVzOiBV c2VyIEFnZW50LCBJZGVudGl0eSBQcm92aWRlciBhbmQNCiAgICBSZWx5aW5nIFBhcnR5Lg0KDQou LndoaWNoIGlzIHByZXR0eSBjbGVhcmx5IGRlc2NyaWJpbmcgZmVkZXJhdGlvbi4NCg0KKiBtb3Jl IGltcG9ydGFudGx5LCBieSB2aXJ0dWUgb2YgZGVmaW5pbmcgdGhlIFRva2VuQmluZGluZ1R5cGUg b2YgInJlZmVycmVkX3Rva2VuX2JpbmRpbmciLCBUQlBST1RPIGlzIGFscmVhZHkgdGlwdG9lJ2cg aW50byB0aGUgIm11bHRpcGxlIGNvbW11bmljYXRpbmcgcGFydGllcyIgbW9yYXNzIChha2EgImZl ZGVyYXRpb24iKS4NCg0KDQpQZXJoYXBzIGlmIHdlIHRoaW5rIHRoYXQgcHJldHR5IG11Y2ggb25s eSBIVFRQIHdpbGwgbWFrZSB1c2Ugb2YgdGhlIFRva2VuQmluZGluZ1R5cGUgb2YgInJlZmVycmVk X3Rva2VuX2JpbmRpbmciLCB0aGVuIG1heWJlIHRoYXQgVEIgdHlwZSBvdWdodCB0byBiZSBkZWZp bmVkIGFuZCBJQU5BLXJlZ2lzZ3RlcmVkIGluIC10b2tiaW5kLWh0dHBzIC0tIGluIHRoYXQgd2F5 IGl0IHNlZW1zIGFsbCBtZW50aW9uIG9mIHRoZSAicmVmZXJyZWQiIFRCIGNvbmNlcHQgY2FuIGJl IGV4Y2lzZWQgZnJvbSBUQlBST1RPLiAgVGhlIGxhdHRlciBzcGVjIHdvdWxkIHN0aWxsIGVzdGFi bGlzaCB0aGUgVEIgdHlwZSByZWdpc3RyeS4NCg0KT3RoZXJ3aXNlLCBJIHRlbmQgdG8gdGhpbmsg dGhhdA0KPGh0dHBzOi8vZ2l0aHViLmNvbS9Ub2tlbkJpbmRpbmcvSW50ZXJuZXQtRHJhZnRzL3B1 bGwvMTY+IGVtYm9kaWVzIHdoYXQgbmVlZHMgdG8gYmUgZG9uZSBpbiBUQlBST1RPIHRvIGhhdmUg cHJvcGVyIHByb2Nlc3NpbmcgcnVsZXMgZm9yIHJlZmVycmVkIFRva2VuIEJpbmRpbmdzLg0KDQpJ biBhbnkgY2FzZSwgaW4gbXkgdmlldywgdGhlIHByb2Nlc3NpbmcgcnVsZXMgbGFuZ3VhZ2UgaW4g VEJQUk9UTyBjb3VsZCBiZSB1c2VmdWxseSBzdGF0ZWQgbW9yZSBjbGVhcmx5IGFuZCBteSBvdmVy YWxsIHN1Z2dlc3Rpb25zIHJlZ2FyZGluZyB0aGF0IGFyZSBlbWJvZGllZCBpbiB0aGUgYWJvdmUt bGlua2VkIFBSICMxNi4NCg0KSFRILA0KDQo9SmVmZkgNCg0KDQoNCg== From nobody Fri Mar 4 10:38:40 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B151F1A873C for ; Fri, 4 Mar 2016 10:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.768 X-Spam-Level: X-Spam-Status: No, score=-99.768 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 YWPCiUqg8Vx4 for ; Fri, 4 Mar 2016 10:38:36 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 92B901A873A for ; Fri, 4 Mar 2016 10:38:36 -0800 (PST) Received: (qmail 22508 invoked by uid 0); 4 Mar 2016 18:38:35 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 4 Mar 2016 18:38:35 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id RueW1s00F2UhLwi01ueZFw; Fri, 04 Mar 2016 11:38:35 -0700 X-Authority-Analysis: v=2.1 cv=FouWoQbq c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=SklZikNDuKEqgTFYHHkA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:To:From:Subject:Date:Message-ID; bh=BjJlgzJhX98QFQNHROzcTFu3b3Ugbrr2BWuptq+idDE=; b=uN4tAoops3w2buyRvnNyGMdlLA P/SFOguFhSv6DTYcY/GMMEXRsvIG0321GeUWQgxr9FzvWjYwQXxucijiRTthwpGUQOZxsc+37AUy0 qmCwylV02w6HB4wwGfaegoyID; Received: from [127.0.0.1] (port=57117 helo=box514.bluehost.com) by box514.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1abucQ-0004qa-0Y for unbearable@ietf.org; Fri, 04 Mar 2016 11:38:30 -0700 Received: from 167.220.25.49 ([167.220.25.49]) (SquirrelMail authenticated user jeff.hodges@kingsmountain.com) by box514.bluehost.com with HTTP; Fri, 4 Mar 2016 11:38:30 -0700 Message-ID: <0e48e588076c41f791a2143eeb2cf3ea.squirrel@box514.bluehost.com> Date: Fri, 4 Mar 2016 11:38:30 -0700 From: jeff.hodges@kingsmountain.com To: "IETF Tokbind WG" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Identified-User: {:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:program running on server} Archived-At: Subject: Re: [Unbearable] -tokbind-https-02: "Federated token bindings" figures X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 04 Mar 2016 18:38:38 -0000 I've made some very minor editorial changes to the "Token Binding over HTTP: Federation Use Cases" figure... Token Binding over HTTP https://tools.ietf.org/html/draft-ietf-tokbind-https Diagram of section 3. Federation Use Cases https://tools.ietf.org/html/draft-ietf-tokbind-https-02#section-3 What: Typical HTTP Redirect-based Web Broswer SSO Profile (no artifact, no callbacks), featuring binding of, e.g., a TLS Token Binding ID into an OpenID Connect "ID Token". Legend: EKM: TLS Exported Keying Material [RFC5705] {EKMn}Ksm: EKM for server "n", signed by private key of TBID "m", where "n" must represent server receiving the ETBMSG, if a conveyed TB's type is provided_token_binding, then m = n, else if TB's type is referred_token_binding, then m != n. E.g., see step 1b in diagram below. ETBMSG: "Token-Binding" HTTP header field conveying an EncodedTokenBindingMessage, in turn conveying TokenBinding (TB)struct(s), e.g.: ETBMSG[[TB]] or ETBMSG[[TB1],[TB2]] ID Token: the "ID Token" in OIDC, it is the semantic equivalent of a SAML "authentication assertion". "ID Token w/TBIDn" denotes a "token bound" ID Token containing TBIDn. Ks & Kp: private (aka secret) key, and public key, respectively, of client-side Token Binding key pair OIDC: Open ID Connect TB: TokenBinding struct containing signed EKM, TBID, and TB type, e.g.: [{EKM1}Ks1,TBID1,provided_token_binding] TBIDn: Token Binding ID for client and server n's token-bound TLS association. TBIDn contains Kpn. Client, Token Consumer, Token Provider, aka: aka: aka: User Agent OpenID Client, OpenID Provider, OIDC Relying Party, OIDC Provider, SAML Relying Party SAML Identity Provider [ server "1" ] [ server "2" ] +--------+ +----+ +-----+ | Client | | TC | | TP | +--------+ +----+ +-----+ | | | | | | | | | | 0. Client interacts w/TC | | | over HTTPS, establishes Ks1 & Kp1, TBID1 | | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | |------------------------------>| | | | | | | | | | | | 1a. OIDC ID Token request, aka| | | "Authentication Request", conveyed with | | HTTP response header field of: | | Include-Referer-Token-Binding-ID:true | | any security-relevant cookies | | | should contain TBID1 | | +<- - - - - - - - - - - - - - - - | | . | (redirect to TP via 301, 302, | | . | 303, 307, or 308) | | . | | | +------------------------------------------------------->| | 1b. opens HTTPS w/ TP, | | establishes Ks2, Kp2, TBID2; | | sends GET or POST with | | ETBMSG[[{EKM2}Ks2,TBID2,provided_token_binding], | | [{EKM2}Ks1,TBID1,referred_token_binding]] | | as well as the ID Token request | | | | | | | | | | | 2. user authentication (if applicable, | | methods vary, particulars are out of scope) | |<====================================================>| | (TP generates ID Token for TC containing TBID1, may | | also set cookie(s) containing TBID2 and/or TBID1, | | details vary, particulars are out of scope) | | | | | | | | | | | 3a. ID Token containing TBID1, issued for TC, | | conveyed via OIDC "Authentication Response" | +<- - - - - - - - - - - - - - - - - - - - - - - - - - - -| . | (redirect to TC) | | . | | | . | | | +-------------------------------->| | | 3b. HTTPS GET or POST with | | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | | conveying Authn Reponse containing | | ID Token w/TBID1, issued for TC | | | | | | | | | | | 4. user is signed-on, any security-relevant cookie(s)| | that are set SHOULD contain TBID1 | |<------------------------------| | | | | | | | From nobody Fri Mar 4 10:56:39 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218BF1A87A1 for ; Fri, 4 Mar 2016 10:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.967 X-Spam-Level: X-Spam-Status: No, score=-98.967 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 NRCgpcdQrQ44 for ; Fri, 4 Mar 2016 10:56:37 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 585C21A87A0 for ; Fri, 4 Mar 2016 10:56:37 -0800 (PST) Received: (qmail 19490 invoked by uid 0); 4 Mar 2016 18:56:36 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy6.mail.unifiedlayer.com with SMTP; 4 Mar 2016 18:56:36 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id RuwW1s00P2UhLwi01uwZJc; Fri, 04 Mar 2016 11:56:34 -0700 X-Authority-Analysis: v=2.1 cv=O8aq4nNW c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=7OsogOcEt9IA:10 a=HOlrMCsI8_rnUXj6DrwA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=s/le1dTzy1a2+p6FnXcz04mghVWmE3ihfXZX4vdn0J4=; b=gjYKUxbToyAb3AhNCShzsEU2/s 4NluZ8y5xZJrxJtslraBZZ71tRT76JAuN6vL6BijS3b+O2nIRoeWHgcoxIGl1n38BHvsE1pRRurdO tc1dW9jclQW2iPBAa1FWGaQ7I; Received: from [127.0.0.1] (port=33616 helo=box514.bluehost.com) by box514.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1abutp-0004Gb-2b; Fri, 04 Mar 2016 11:56:29 -0700 Received: from 167.220.25.49 ([167.220.25.49]) (SquirrelMail authenticated user jeff.hodges@kingsmountain.com) by box514.bluehost.com with HTTP; Fri, 4 Mar 2016 11:56:29 -0700 Message-ID: <19706e82cca45bbe54e20e4ae6929c14.squirrel@box514.bluehost.com> In-Reply-To: <0e48e588076c41f791a2143eeb2cf3ea.squirrel@box514.bluehost.com> References: <0e48e588076c41f791a2143eeb2cf3ea.squirrel@box514.bluehost.com> Date: Fri, 4 Mar 2016 11:56:29 -0700 From: jeff.hodges@kingsmountain.com To: jeff.hodges@kingsmountain.com User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Identified-User: {:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:program running on server} Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] -tokbind-https-02: "Federated token bindings" figures X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 04 Mar 2016 18:56:38 -0000 > I've made some very minor editorial changes to the "Token Binding over HTTP: > Federation Use Cases" figure... apologies, prior msg had some of them sneaky tab chars in there causing misalignment, I'll have to resend using a different MUA later on... From nobody Sun Mar 6 08:50:53 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1375C1B2F18 for ; Sun, 6 Mar 2016 08:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.967 X-Spam-Level: X-Spam-Status: No, score=-98.967 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 Hzllgz_CEX9Z for ; Sun, 6 Mar 2016 08:50:50 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id B24B91B2F17 for ; Sun, 6 Mar 2016 08:50:50 -0800 (PST) Received: (qmail 24490 invoked by uid 0); 6 Mar 2016 16:50:48 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 6 Mar 2016 16:50:48 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id Snqg1s00A2UhLwi01nqjpK; Sun, 06 Mar 2016 16:50:45 -0700 X-Authority-Analysis: v=2.1 cv=GOWbTI9K c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=9hlyuBdhgS79cxEtfAUA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:To:Subject:From; bh=kDDOBdLlGVpEoQSdvWj2QNlKMfnePDn1g0TOob7MrpE=; b=lt4UnMaNJkcnEEpwOh2O2jXD7Y Mp8bEAsWM/fRSs7syGLMwpKIU89+QfGmQmC+VrGdux0UGI2+AmhF5ZvG3lPkpDUZcQFoYftOVFsC5 nvY/ikdfPMpd61ZFjmKSbwa7F; Received: from [73.202.80.238] (port=45385 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from ) id 1acbtC-0003u9-S1 for unbearable@ietf.org; Sun, 06 Mar 2016 09:50:42 -0700 From: =JeffH To: IETF Tokbind WG Message-ID: <56DC5FDF.9070805@KingsMountain.com> Date: Sun, 6 Mar 2016 08:50:39 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: Re: [Unbearable] -tokbind-https-02: "Federated token bindings" figures X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 06 Mar 2016 16:50:52 -0000 minor updates to the "Token Binding over HTTP: Federation Use Cases" figure. HTH, =JeffH Token Binding over HTTP https://tools.ietf.org/html/draft-ietf-tokbind-https Diagram of section 3. Federation Use Cases https://tools.ietf.org/html/draft-ietf-tokbind-https-02#section-3 What: Typical HTTP Redirect-based Web Broswer SSO Profile (no artifact, no callbacks), featuring binding of, e.g., a TLS Token Binding ID into an OpenID Connect "ID Token". Legend: EKM: TLS Exported Keying Material [RFC5705] {EKMn}Ksm: EKM for server "n", signed by private key of TBID "m", where "n" must represent server receiving the ETBMSG, if a conveyed TB's type is provided_token_binding, then m = n, else if TB's type is referred_token_binding, then m != n. E.g., see step 1b in diagram below. ETBMSG: "Token-Binding" HTTP header field conveying an EncodedTokenBindingMessage, in turn conveying TokenBinding (TB)struct(s), e.g.: ETBMSG[[TB]] or ETBMSG[[TB1],[TB2]] ID Token: the "ID Token" in OIDC, it is the semantic equivalent of a SAML "authentication assertion". "ID Token w/TBIDn" denotes a "token bound" ID Token containing TBIDn. Ks & Kp: private (aka secret) key, and public key, respectively, of client-side Token Binding key pair OIDC: Open ID Connect TB: TokenBinding struct containing signed EKM, TBID, and TB type, e.g.: [{EKM1}Ks1,TBID1,provided_token_binding] TBIDn: Token Binding ID for client and server n's token-bound TLS association. TBIDn contains Kpn. Client, Token Consumer, Token Provider, aka: aka: aka: User Agent OpenID Client, OpenID Provider, OIDC Relying Party, OIDC Provider, SAML Relying Party SAML Identity Provider [ server "1" ] [ server "2" ] +--------+ +----+ +-----+ | Client | | TC | | TP | +--------+ +----+ +-----+ | | | | | | | | | | 0. Client interacts w/TC | | | over HTTPS, establishes Ks1 & Kp1, TBID1 | | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | |------------------------------>| | | | | | | | | | | | 1a. OIDC ID Token request, aka| | | "Authentication Request", conveyed with | | HTTP response header field of: | | Include-Referer-Token-Binding-ID:true | | any security-relevant cookies | | | should contain TBID1 | | +<- - - - - - - - - - - - - - - - | | . | (redirect to TP via 301, 302, | | . | 303, 307, or 308) | | . | | | +------------------------------------------------------->| | 1b. opens HTTPS w/ TP, | | establishes Ks2, Kp2, TBID2; | | sends GET or POST with | | ETBMSG[[{EKM2}Ks2,TBID2,provided_token_binding], | | [{EKM2}Ks1,TBID1,referred_token_binding]] | | as well as the ID Token request | | | | | | | | | | | 2. user authentication (if applicable, | | methods vary, particulars are out of scope) | |<====================================================>| | (TP generates ID Token for TC containing TBID1, may | | also set cookie(s) containing TBID2 and/or TBID1, | | details vary, particulars are out of scope) | | | | | | | | | | | 3a. ID Token containing TBID1, issued for TC, | | conveyed via OIDC "Authentication Response" | +<- - - - - - - - - - - - - - - - - - - - - - - - - - - -| . | (redirect to TC) | | . | | | . | | | +-------------------------------->| | | 3b. HTTPS GET or POST with | | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | | conveying Authn Reponse containing | | ID Token w/TBID1, issued for TC | | | | | | | | | | | 4. user is signed-on, any security-relevant cookie(s)| | that are set SHOULD contain TBID1 | |<------------------------------| | | | | | | | From nobody Mon Mar 7 16:25:22 2016 Return-Path: X-Original-To: unbearable@ietfc.amsl.com Delivered-To: unbearable@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ED5F81CDF11 for ; Mon, 7 Mar 2016 16:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKKX4W9ORUlP for ; Mon, 7 Mar 2016 16:25:20 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id DD5951CDF10 for ; Mon, 7 Mar 2016 16:25:19 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id e6so136957633vkh.2 for ; Mon, 07 Mar 2016 16:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=SZCWaBihMlpQ7vpdkQmY6GVjrRy50cohCpx/Pwio7JM=; b=C7NtEoUi2a/ePcJiJKD+dXBwnVBzGXViUOyGrAez41/gJZNgU8aN5fozUmQ2jySRaf MaUXeEnDOKuOJBsiD5nsv3HWk8Y3L2MEqNl62XwA9OVsFyGL62GX+clDYj5XK4QOzSOG B9rVDMFzG4WbtNK0STHYPuMUmYb5aXDH2GiMFveC25TLCUL/IN8hoPdBn6vXu3nVAjBz VLFYqXYLdrSod0TnXrvFzAJTwDaFTX16THHb4QvqNwGemeJKgtPvzEaSSJ/KBAbfZjM4 C6qq/bwbUUgKZo2PN1g0Xpd5xxqFl6syriCXDunXuZYA6Q5Rkj0u+plQ/Uu1iaGSKvJB RaqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SZCWaBihMlpQ7vpdkQmY6GVjrRy50cohCpx/Pwio7JM=; b=DK7kOecDH5MEOEoW9NawAWmYVO4Y76rQaQiN0nYbADYLoud36PMGc8bmt8oYsYLeGD R52WQ1mBgmlcCAWARcoZP8YvQ+xjjooV7OYeJe0Rso4qGUTxbiEhGpqjSbJBv5DgM/TW AAbH1g0TINkoDR4kV6jx+64f6vZ5OxoIThQpi3+VT+pyynqU/mrVrvF0wVwqQnD/T9QM BlnPFGAmGxNayUBaqUZTtJdXEpDKOD94kOWzoM5L4JmI63CCL47MsxWxIzWe8pWcvJWC OqbIKAPiUnvFN5iPdFN2dSqftvO/JGDxXrJA2VwhHXnES93Ju4thvPw1CBfE8brOYGHV PxgA== X-Gm-Message-State: AD7BkJIuZEP2tcfVW16c9DB8dCnNsl35+Zfvwe6sZISKACkWtVzxu0qI9WLqXyfla9VJ71zVPOaq/vURkSp0ktBY X-Received: by 10.31.171.143 with SMTP id u137mr24145815vke.88.1457396718888; Mon, 07 Mar 2016 16:25:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.76.198 with HTTP; Mon, 7 Mar 2016 16:24:59 -0800 (PST) From: Nick Harper Date: Mon, 7 Mar 2016 16:24:59 -0800 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary=001a1143e99cba2ea2052d7e9dc8 Archived-At: Subject: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Mar 2016 00:25:21 -0000 --001a1143e99cba2ea2052d7e9dc8 Content-Type: text/plain; charset=UTF-8 If a client receives an "Include-Referer-Token-Binding-ID" header in response to a request that already had a referred TBID in the TokenBindingMessage, should it include both of those TBIDs as referred TBIDs in the next request? I.e. - client sends request to server A w/ provided TBID A - gets back Include-Referer-Token-Binding-ID header on a redirect to B - client sends request to B w/ provided TBID B, referred TBID A - gets back Include-Referer-Token-Binding-ID header on a redirect to C Possible behaviors: i) client sends request to C w/ provided TBID C, referred TBID B, referred TBID A ii) client sends request to C w/ provided TBID C, referred TBID B iii) client sends request to C w/ provided TBID C, referred TBID A, referred TBID B I don't know what a use case for this situation might be, but the spec seems unclear to me on what to do. Option (i) seems most likely, followed by option (ii). One potential way this might happen is if an identity provider changes the URL for their endpoint that generates tokens and sets up a redirect from the old URL to the new URL. In that case, option (ii) wouldn't work because both B and C are the IdP. --001a1143e99cba2ea2052d7e9dc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If a client receives an "Include-Referer-Token-Bindin= g-ID" header in response to a request that already had a referred TBID= in the TokenBindingMessage, should it include both of those TBIDs as refer= red TBIDs in the next request?

I.e.
- client s= ends request to server A w/ provided TBID A
- gets back Include-R= eferer-Token-Binding-ID header on a redirect to B
- client sends = request to B w/ provided TBID B, referred TBID A
- gets back Incl= ude-Referer-Token-Binding-ID header on a redirect to C
Possible b= ehaviors:
i) client sends request to C w/ provided TBID C, referr= ed TBID B, referred TBID A
ii) client sends request to C w/ provi= ded TBID C, referred TBID B
iii) client sends request to C w/= provided TBID C, referred TBID A, referred TBID B

=
I don't know what a use case for this situation might be, but the = spec seems unclear to me on what to do. Option (i) seems most likely, follo= wed by option (ii). One potential way this might happen is if an identity p= rovider changes the URL for their endpoint that generates tokens and sets u= p a redirect from the old URL to the new URL. In that case, option (ii) wou= ldn't work because both B and C are the IdP.
--001a1143e99cba2ea2052d7e9dc8-- From nobody Tue Mar 8 14:43:33 2016 Return-Path: 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 F2EFF12DBC3 for ; Tue, 8 Mar 2016 14:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.521 X-Spam-Level: X-Spam-Status: No, score=-22.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=paypal.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA_pZArGTPYd for ; Tue, 8 Mar 2016 14:43:30 -0800 (PST) Received: from den-ipout-01-data1.paypalcorp.com (den-ipout-01-data1.paypalcorp.com [173.224.160.153]) (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 9629612DBC2 for ; Tue, 8 Mar 2016 14:43:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal.com; i=@paypal.com; q=dns/txt; s=pp-dkim1; t=1457477011; x=1489013011; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gQNrWGo1MIvB5MIBqSv5DRB7y7WAcuVqBCpRBogCld8=; b=s6Jn5IddSDSZHWL5glcmh6tta7chB9ERuJ7KZ5oaWW4z+7FOy451QbFg e/HgfzNRdCaCj1F1+YRYUewXCpYRXqa9DZuKhGqqXPrpGKD55G3TY+8hD UAC9dWjAhksKXHp3Sm4faeY024BSYqtA63oxlsH1DVdOw1CJBdanOZEgg v4J1IL0l71O6xbAKZGlJouIcBKtpsdrGLsKJu3X3GBgJHJIMPHJJegg36 +/5YxcdX7M8/gtl76fmGBghzyfiW9scT8RHiSPP0uvtKoGjIeVj37QszS wJgpzvQpmelfXM/GlLJgYdZxqjkqY0NpCPiUvxubYVShRC1e+WS5tIgFM Q==; X-IronPort-AV: E=Sophos;i="5.22,558,1449558000"; d="scan'208";a="11460436" Received: from unknown (HELO lvs-ipcld-01-data1.paypalcorp.com) ([10.184.246.164]) by den-ipout-01-data1.paypalcorp.com with ESMTP; 08 Mar 2016 15:43:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,558,1449561600"; d="scan'208";a="4152671" X-CloudService: Office365 Received: from mail-by2lp0241.outbound.protection.outlook.com (HELO na01-by2-obe.outbound.protection.outlook.com) ([207.46.163.241]) by lvs-ipcld-01-data1.paypalcorp.com with ESMTP/TLS/AES256-SHA256; 08 Mar 2016 14:43:29 -0800 Received: from BL2PR06MB2083.namprd06.prod.outlook.com (10.167.99.143) by BL2PR06MB2081.namprd06.prod.outlook.com (10.167.99.141) with Microsoft SMTP Server (TLS) id 15.1.427.16; Tue, 8 Mar 2016 22:43:27 +0000 Received: from BL2PR06MB2083.namprd06.prod.outlook.com ([10.167.99.143]) by BL2PR06MB2083.namprd06.prod.outlook.com ([10.167.99.143]) with mapi id 15.01.0427.019; Tue, 8 Mar 2016 22:43:27 +0000 From: "Hodges, Jeff" To: Nick Harper Thread-Topic: [Unbearable] Referred token binding IDs Thread-Index: AQHReNEDYw8BpTDZrk+xA8bz5ugEpJ9PoB4A Date: Tue, 8 Mar 2016 22:43:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=paypal.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [173.224.162.69] x-ms-office365-filtering-correlation-id: f72b55a2-f8c4-420a-2902-08d347a310dc x-microsoft-exchange-diagnostics: 1; BL2PR06MB2081; 5:PTNvSMefLD00oTp9Yz9JNyU77I7a845v8Miv7Bu4UspOm7Q68q4cxnzBActUZlEnbqRlP8nMNydDS1ujDRTGN7wstOzobbC/DkTpKTu6PTJSw111x+0N8XLmfHgymd2GMq93B9trR9qkTKAI+Du7Dw==; 24:hNeZDgHNLttPyqXI0m37Ez9BtaO3arFOKATq2OxRt5IybHGAz6JzbrxaSmNRvcw4R2i2nNmIv2Xq/Nyu8mqKrE/dO3yYQsUyOPYNZdLxTN0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR06MB2081; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BL2PR06MB2081; BCL:0; PCL:0; RULEID:; SRVR:BL2PR06MB2081; x-forefront-prvs: 08756AC3C8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(479174004)(2900100001)(2950100001)(77096005)(10130500003)(50986999)(19580395003)(19580405001)(54356999)(76176999)(189998001)(66066001)(10290500002)(10400500002)(86362001)(10300500001)(99286002)(3280700002)(122556002)(106116001)(2906002)(87936001)(81166005)(4326007)(5004730100002)(1220700001)(1096002)(3846002)(36756003)(6116002)(5002640100001)(102836003)(92566002)(4500500003)(73692002)(10770500004)(3660700001)(5008740100001)(586003)(11100500001)(110136002)(10630500005)(56826009); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR06MB2081; H:BL2PR06MB2083.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <85FE1BDDEED06945817E8985A34E5D37@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: paypal.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2016 22:43:27.3102 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fb007914-6020-4374-977e-21bac5f3f4c8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR06MB2081 X-CFilter: Scanned den1 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Mar 2016 22:43:32 -0000 On 3/7/16, 4:24 PM nharper@google.com> wrote: >If a client receives an "Include-Referer-Token-Binding-ID" header in >response to a request that already had a referred TBID in the >TokenBindingMessage, should it include both of those TBIDs as referred >TBIDs in the next request? > >I.e. >- client sends request to server A w/ provided TBID A >- gets back Include-Referer-Token-Binding-ID header on a redirect to B >- client sends request to B w/ provided TBID B, referred TBID A >- gets back Include-Referer-Token-Binding-ID header on a redirect to C >Possible behaviors: >i) client sends request to C w/ provided TBID C, referred TBID B, >referred TBID A >ii) client sends request to C w/ provided TBID C, referred TBID B > >iii) client sends request to C w/ provided TBID C, referred TBID A, >referred TBID B > > >I don't know what a use case for this situation might be, but the spec >seems unclear to me on what to do. Option (i) seems most likely, followed >by option (ii).=20 >One potential way this might happen is if an identity provider changes >the URL for their endpoint that generates tokens and sets up a redirect >from the old URL to the new URL. In that case, option (ii) wouldn't work >because both B and C are the IdP. In this latter case it seems all C needs in the TBMsg, if it is just going to redirect back to A with an "id token w/TBID A", is {provided TBID C, referred TBID A}, yes? though, as presently specified in -tokbind-https, there's no way for B to signal to the client that the client needs to present TBID A to C as 'referred' rather than presenting TBID B as referred. Also, presently, -tokbind-protocol-04 does not indicate there's any particular ordering of TokenBinding structs within TBMsg. It's offhand plausible for the client to just keep appending referred TBIDs to the TBMsg, and whichever entity is the ultimate "token provider" to incorporate the correct (i.e., "first") referred TBID in whatever federation token it is issuing, but then there'd be the chance for some sort of "redirect loop" (either accidentally or maliciously) and having a size-unbounded TBMsg. perhaps a way to create the necessary signaling is: instead of just a boolean, the Include-Referer-Token-Binding-ID header field could convey the TBID to be referred? i.e., in the above use case, B knows that it isn't the present Token Provider, and can be configured to indicate to the client which TBID to include in the TBMsg to C as "referred" (which in this case is TBID A)...? perhaps we need to have folks familiar with actual federated ID deployments (such as the tokbind wg chairs :) hold forth on the sorts of use cases they are aware of that -tokbind-https doesn't (yet) address, but perhaps should at least mention and maybe at least provide some guidance about? =20 HTH,=20 =3DJeffH From nobody Tue Mar 8 15:03:07 2016 Return-Path: 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 5E26C12DBDF for ; Tue, 8 Mar 2016 15:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_HELO_PASS=-0.001, SPF_PASS=-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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IScf5LcDsQn for ; Tue, 8 Mar 2016 15:03:04 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0790.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:790]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D810C12DBE9 for ; Tue, 8 Mar 2016 15:03:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0kVxlN8Nernmp8R2fNZkDDb7ixNH1V5qOdPsLhIhYkM=; b=eHjvLJajP4JrwxnUJ/saL1cnupFCyeO2RDHov2EpZNXgc+qHwq0418IiefEebO96wmAlvc3ekVbYxABThPItAOmrohn1ZagN884c7G9m2/yGQvXfvpgII7qhzJM5r6nDNt1coexnoE3sbwqetlW43ZIGGrfqsL+X9hisY4ZNm0E= Received: from BN3PR03MB1398.namprd03.prod.outlook.com (10.163.34.17) by BN3PR03MB1397.namprd03.prod.outlook.com (10.163.34.16) with Microsoft SMTP Server (TLS) id 15.1.427.16; Tue, 8 Mar 2016 23:02:43 +0000 Received: from BN3PR03MB1398.namprd03.prod.outlook.com ([10.163.34.17]) by BN3PR03MB1398.namprd03.prod.outlook.com ([10.163.34.17]) with mapi id 15.01.0427.019; Tue, 8 Mar 2016 23:02:43 +0000 From: Andrei Popov To: "Hodges, Jeff" , Nick Harper , "Dirk Balfanz (balfanz@google.com)" Thread-Topic: [Unbearable] Referred token binding IDs Thread-Index: AQHReNEDwXywEPRvE0GPN9JtJMKEHp9QJjmAgAAAn9A= Date: Tue, 8 Mar 2016 23:02:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: paypal.com; dkim=none (message not signed) header.d=none;paypal.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:5::1d2] x-ms-office365-filtering-correlation-id: 0843f22c-e36a-4e58-ad0a-08d347a5c1d7 x-microsoft-exchange-diagnostics: 1; BN3PR03MB1397; 5:onnKNadujAFfc/i1VtTkDhkIACQB5EJzh0SEwd5FGZQAX0XtnWhjep/tABnNgHbuhCX6Ya3pU4O4RfIM7LWffTYESSzCrmx/OQ0zWfVyErv/qILLsf0QlUjySBEXv/tJngHlPmNeqn6W38NXEkfMYA==; 24:BNoeE6Rbj17LvCU1TYhnXYZYvq8NeUqyr5fh4FsxCsDjZuHi70Ia6Tda65UGV1UDQSxZXqu3P5fwm10d8A6OuzS/+YL+UYxdescJygwET/8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1397; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BN3PR03MB1397; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1397; x-forefront-prvs: 08756AC3C8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(479174004)(24454002)(99286002)(87936001)(81166005)(106116001)(11100500001)(92566002)(189998001)(3280700002)(1220700001)(122556002)(77096005)(19580395003)(5003600100002)(86362001)(33656002)(76576001)(575784001)(74316001)(54356999)(76176999)(86612001)(50986999)(19580405001)(5008740100001)(5004730100002)(6116002)(4326007)(15975445007)(102836003)(10290500002)(586003)(8990500004)(5002640100001)(1096002)(2900100001)(2950100001)(5005710100001)(5001770100001)(3660700001)(10090500001)(10400500002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1397; H:BN3PR03MB1398.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2016 23:02:43.4966 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1397 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Mar 2016 23:03:06 -0000 The current HTTPSTB says:=20 " The TokenBindingMessage SHOULD contain a TokenBinding with TokenBindingType referred_token_binding. If included, this TokenBinding MUST be signed with the Token Binding key used by the client for connections between itself and the Token Consumer... As described above, the TokenBindingMessage MUST additionally contain a Provided Token Binding ID..." Based on the above, currently only option ii) exists. Dirk, please correct = me if I'm wrong, but I believe this means that IDP C would generate a token= for IDP B, which would then generate a token for RP A. HTTPSTB does not ex= plicitly discuss multiple-redirect scenarios (perhaps we should add some la= nguage). > Also, presently, > -tokbind-protocol-04 does not indicate there's any particular ordering of= TokenBinding structs within TBMsg. >From the TBPROTO perspective, there should be at least one binding in the T= B message, no other constraints on TB type or ordering. The idea is for the= basic protocol to accommodate cases other than HTTPS-style federation. Cheers, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Hodges, = Jeff Sent: Tuesday, March 8, 2016 2:43 PM To: Nick Harper Cc: IETF Tokbind WG Subject: Re: [Unbearable] Referred token binding IDs On 3/7/16, 4:24 PM nharper@google.com> wrote: >If a client receives an "Include-Referer-Token-Binding-ID" header in=20 >response to a request that already had a referred TBID in the=20 >TokenBindingMessage, should it include both of those TBIDs as referred=20 >TBIDs in the next request? > >I.e. >- client sends request to server A w/ provided TBID A >- gets back Include-Referer-Token-Binding-ID header on a redirect to B >- client sends request to B w/ provided TBID B, referred TBID A >- gets back Include-Referer-Token-Binding-ID header on a redirect to C=20 >Possible behaviors: >i) client sends request to C w/ provided TBID C, referred TBID B,=20 >referred TBID A >ii) client sends request to C w/ provided TBID C, referred TBID B > >iii) client sends request to C w/ provided TBID C, referred TBID A,=20 >referred TBID B > > >I don't know what a use case for this situation might be, but the spec=20 >seems unclear to me on what to do. Option (i) seems most likely,=20 >followed by option (ii). >One potential way this might happen is if an identity provider changes=20 >the URL for their endpoint that generates tokens and sets up a redirect=20 >from the old URL to the new URL. In that case, option (ii) wouldn't=20 >work because both B and C are the IdP. In this latter case it seems all C needs in the TBMsg, if it is just going = to redirect back to A with an "id token w/TBID A", is {provided TBID C, ref= erred TBID A}, yes? though, as presently specified in -tokbind-https, there's no way for B to s= ignal to the client that the client needs to present TBID A to C as 'referr= ed' rather than presenting TBID B as referred. Also, presently, -tokbind-protocol-04 does not indicate there's any particular ordering of T= okenBinding structs within TBMsg. It's offhand plausible for the client to = just keep appending referred TBIDs to the TBMsg, and whichever entity is th= e ultimate "token provider" to incorporate the correct (i.e., "first") referred TBID in whatever federation token it is issuing, but then= there'd be the chance for some sort of "redirect loop" (either accidentall= y or maliciously) and having a size-unbounded TBMsg. perhaps a way to create the necessary signaling is: instead of just a boole= an, the Include-Referer-Token-Binding-ID header field could convey the TBID= to be referred? i.e., in the above use case, B knows that it isn't the pre= sent Token Provider, and can be configured to indicate to the client which = TBID to include in the TBMsg to C as "referred" (which in this case is TBID= A)...? perhaps we need to have folks familiar with actual federated ID deployments= (such as the tokbind wg chairs :) hold forth on the sorts of use cases th= ey are aware of that -tokbind-https doesn't (yet) address, but perhaps shou= ld at least mention and maybe at least provide some guidance about? =20 HTH,=20 =3DJeffH _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7cAndrei.Popov%40micr= osoft.com%7c29ccc4b816964749c50708d347a3156f%7c72f988bf86f141af91ab2d7cd011= db47%7c1&sdata=3DUfJy3GD5cEOSaRSMQzxoHYzR2JPv0RHmtHam4ijqqE4%3d From nobody Tue Mar 8 16:22:16 2016 Return-Path: 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 ABD2712DCB0 for ; Tue, 8 Mar 2016 16:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.52 X-Spam-Level: X-Spam-Status: No, score=-22.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=paypal.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H69hflV-HMgb for ; Tue, 8 Mar 2016 16:22:13 -0800 (PST) Received: from den-ipout-03-data1.paypalcorp.com (den-ipout-03-data1.paypalcorp.com [173.224.160.157]) (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 6F4E612DC98 for ; Tue, 8 Mar 2016 16:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal.com; i=@paypal.com; q=dns/txt; s=pp-dkim1; t=1457482933; x=1489018933; h=from:to:subject:date:message-id:mime-version; bh=1dXPubivI29C/Dg79xnJUsNFyqH5eKgpeVBRx+qZ2ZM=; b=buLyUpQe5kQyjXJ2g5W5B5ct9qxsloGTZc2DIdNt+lZWv+ZONPmawzuP g5NzlSeV0EYdd6lCYm8B1eWuzte2pjoQpxQuEqCEDn65JdR/wYGwxHr8k 8wUGuSjfn9BO0lcrkJMuxdTcYRI4OU0SdP8ECncFgVLcCZUUJDz7nJg5G zh3MZ474fpD7L5UXBzhbw4OPVCMCGgqUg6Ut6Gh4cK39pkJ15x8/DY+b+ K/6BRruLYhr1GGUhSL8zWZ0CqxldgHQwZi7GBdWUSOmj98c7FKjNRsqL4 VWgaJkQxrxOgIYIjFpsrzLIvrq+CNGWiOQku9HIQQniSnAugyaNrdosGI w==; X-IronPort-AV: E=Sophos; i="5.22,558,1449558000"; d="scan'208,217"; a="11468318" Received: from unknown (HELO lvs-ipcld-01-data1.paypalcorp.com) ([10.184.246.164]) by den-ipout-03-data1.paypalcorp.com with ESMTP; 08 Mar 2016 17:22:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,558,1449561600"; d="scan'208,217";a="4154842" X-CloudService: Office365 Received: from mail-by2lp0242.outbound.protection.outlook.com (HELO na01-by2-obe.outbound.protection.outlook.com) ([207.46.163.242]) by lvs-ipcld-01-data1.paypalcorp.com with ESMTP/TLS/AES256-SHA256; 08 Mar 2016 16:22:11 -0800 Received: from BL2PR06MB2083.namprd06.prod.outlook.com (10.167.99.143) by BL2PR06MB2083.namprd06.prod.outlook.com (10.167.99.143) with Microsoft SMTP Server (TLS) id 15.1.427.16; Wed, 9 Mar 2016 00:22:10 +0000 Received: from BL2PR06MB2083.namprd06.prod.outlook.com ([10.167.99.143]) by BL2PR06MB2083.namprd06.prod.outlook.com ([10.167.99.143]) with mapi id 15.01.0427.019; Wed, 9 Mar 2016 00:22:10 +0000 From: "Hodges, Jeff" To: Tokbind WG Thread-Topic: triple handshake admonitions -- pare 'em down to one ? Thread-Index: AQHReZm4xsDOY3MKnE6xWMJZ/2S/IQ== Date: Wed, 9 Mar 2016 00:22:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=paypal.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [173.224.162.69] x-ms-office365-filtering-correlation-id: c639e502-96cb-4c04-d014-08d347b0db57 x-microsoft-exchange-diagnostics: 1; BL2PR06MB2083; 5:7gFpn6gLA7rmndB0PkZU7lKWFwspHRxVRXtBI3/Ekjik5XwgdSLeBUdLlBMFqX1I8sO2IWnvrkuLs4NGzJe3xbENJl4iDHDK4I31Wu4VjTAm0UWkNp8NH+lPXLQFEN3jQHVBai+dPaLc/T3bhoZIWw==; 24:npeqO2oxCkIqH5upMmALxzwR9ySif8j7G6K7zT1GWQslXS3+Yhb6tv1AYR28ha8Acfk2BW1xUmTGwomKrDp0E7J+i9EYhnz3Zx2VpWrRi/I= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR06MB2083; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BL2PR06MB2083; BCL:0; PCL:0; RULEID:; SRVR:BL2PR06MB2083; x-forefront-prvs: 0876988AF0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(4500500003)(189998001)(81166005)(110136002)(5002640100001)(107886002)(122556002)(16236675004)(10290500002)(450100001)(229853001)(77072002)(66066001)(586003)(73692002)(82432001)(50986999)(3846002)(99286002)(106116001)(10770500004)(10130500003)(92566002)(3280700002)(3660700001)(36756003)(1220700001)(1096002)(87936001)(102836003)(6116002)(86362001)(5004730100002)(2906002)(19580395003)(54356999)(11100500001)(10400500002)(77096005)(5008740100001)(10630500005); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR06MB2083; H:BL2PR06MB2083.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D304ACB391D00jehodgespaypalcorpcom_" MIME-Version: 1.0 X-OriginatorOrg: paypal.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2016 00:22:10.6340 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fb007914-6020-4374-977e-21bac5f3f4c8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR06MB2083 X-CFilter: Scanned den1 Archived-At: Subject: [Unbearable] triple handshake admonitions -- pare 'em down to one ? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 09 Mar 2016 00:22:15 -0000 --_000_D304ACB391D00jehodgespaypalcorpcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The admonition wrt "triple handshake vuln" appears four times in the three = specs -- twice in TBPROTO, once each in TBNEGO and HTTPSTB. Yes, it is important, but arguably, it only needs to appear in TBNEGO becau= se it is TBNEGO that defines the TLS session establishment. The other spec= s are at the next layer up and refer to TBNEGO wrt TLS establishment. If y'all really want to keep the admonition in all three specs, then I'd pa= re TBPROTO down to one occurance, in security considerations. HTH, =3DJeffH > grep -Hi "triple handshake" *xml draft-ietf-tokbind-https-02.xml:
draft-ietf-tokbind-https-02.xml: TLS Token Binding. The triple han= dshake attack Triple Handshakes and Cook= ie Cutters: Breaking and Fixing Authentication over draft-ietf-tokbind-negotiation-02.xml:
draft-ietf-tokbind-negotiation-02.xml: associate a TLS connection wi= th a Token Binding. The triple handshake attack draft-ietf-tokbind-negotiation-02.xml: Triple Handshakes an= d Cookie Cutters: Breaking and Fixing Authentication over draft-ietf-tokbind-protocol-04.xml: <t>The triple handshake vulnerab= ility in TLS 1.2 and older TLS versions affects the security draft-ietf-tokbind-protocol-04.xml: <section title=3D"Triple Handshake= Vulnerability in TLS 1.2 and Older TLS Versions"> draft-ietf-tokbind-protocol-04.xml: TLS connection with a Token Bind= ing. The triple handshake attack draft-ietf-tokbind-protocol-04.xml: <title>Triple Handshakes and C= ookie Cutters: Breaking and Fixing Authentication over --_000_D304ACB391D00jehodgespaypalcorpcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5ACA71562B769B45A330BB08106C75BC@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif;"> <div>The admonition wrt "triple handshake vuln" appears four time= s in the three specs -- twice in TBPROTO, once each in TBNEGO and HTTPSTB.<= /div> <div><br> </div> <div>Yes, it is important, but arguably, it only needs to appear in TBNEGO = because it is TBNEGO that defines the TLS session establishment. =  The other specs are at the next layer up and refer to TBNEGO wrt TLS = establishment. </div> <div><br> </div> <div>If y'all really want to keep the admonition in all three specs, then I= 'd pare TBPROTO down to one occurance, in security considerations. </d= iv> <div><br> </div> <div>HTH,</div> <div><br> </div> <div>=3DJeffH</div> <div><br> </div> <div> <p style=3D"margin: 0px; font-size: 10px; font-family: Menlo;">> grep -H= i "triple handshake" *xml</p> <p style=3D"margin: 0px; font-size: 10px; font-family: Menlo;">draft-ietf-t= okbind-https-02.xml:      <section title=3D"Triple H= andshake Vulnerability in TLS"></p> <p style=3D"margin: 0px; font-size: 10px; font-family: Menlo;">draft-ietf-t= okbind-https-02.xml:          TLS Token Binding. T= he triple handshake attack <xref</p> <p style=3D"margin: 0px; font-size: 10px; font-family: Menlo;">draft-ietf-t= okbind-https-02.xml:          <title>Triple = Handshakes and Cookie Cutters: Breaking and Fixing Authentication over = ;</p> <p style=3D"margin: 0px; font-size: 10px; font-family: Menlo;"><br> </p> <p style=3D"margin: 0px; font-size: 10px; font-family: Menlo;"><br> </p> <p style=3D"margin: 0px; font-size: 10px; font-family: Menlo;">draft-ietf-t= okbind-negotiation-02.xml:      <section title=3D"Tr= iple Handshake Vulnerability in TLS 1.2 and Older TLS Versions"></p= > <p style=3D"margin: 0px; font-size: 10px; font-family: Menlo;">draft-ietf-t= okbind-negotiation-02.xml:        associate a TLS conne= ction with a Token Binding. The triple handshake attack </p> <p style=3D"margin: 0px; font-size: 10px; font-family: Menlo;">draft-ietf-t= okbind-negotiation-02.xml:          <title>T= riple Handshakes and Cookie Cutters: Breaking and Fixing Authentication ove= r </p> <p style=3D"margin: 0px; font-size: 10px; font-family: Menlo;"><br> </p> <p style=3D"margin: 0px; font-size: 10px; font-family: Menlo;"><br> </p> <p style=3D"margin: 0px; font-size: 10px; font-family: Menlo;"><br> </p> <p style=3D"margin: 0px; font-size: 10px; font-family: Menlo;">draft-ietf-t= okbind-protocol-04.xml:        <t>The triple hand= shake vulnerability in TLS 1.2 and older TLS versions affects the security<= /p> <p style=3D"margin: 0px; font-size: 10px; font-family: Menlo;">draft-ietf-t= okbind-protocol-04.xml:      <section title=3D"Tripl= e Handshake Vulnerability in TLS 1.2 and Older TLS Versions"></p> <p style=3D"margin: 0px; font-size: 10px; font-family: Menlo;">draft-ietf-t= okbind-protocol-04.xml:        TLS connection with a To= ken Binding. The triple handshake attack </p> <p style=3D"margin: 0px; font-size: 10px; font-family: Menlo;">draft-ietf-t= okbind-protocol-04.xml:          <title>Trip= le Handshakes and Cookie Cutters: Breaking and Fixing Authentication over&n= bsp;</p> </div> <div><br> </div> <div><br> </div> <div><br> </div> <div><br> </div> <div><br> </div> <div><br> </div> <div><br> </div> </body> </html> --_000_D304ACB391D00jehodgespaypalcorpcom_-- From nobody Fri Mar 11 13:57:46 2016 Return-Path: <jeff.hodges@paypal.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 1A9C112DCC7 for <unbearable@ietfa.amsl.com>; Fri, 11 Mar 2016 13:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.52 X-Spam-Level: X-Spam-Status: No, score=-22.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=paypal.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 LhgBoQkCS3vP for <unbearable@ietfa.amsl.com>; Fri, 11 Mar 2016 13:57:41 -0800 (PST) Received: from den-ipout-03-data1.paypalcorp.com (den-ipout-03-data1.paypalcorp.com [173.224.160.157]) (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 EDA2412DA63 for <unbearable@ietf.org>; Fri, 11 Mar 2016 13:57:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal.com; i=@paypal.com; q=dns/txt; s=pp-dkim1; t=1457733460; x=1489269460; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4cZ0TQIlxdlhK/dnEFyj9iYA1ICTZKmiDIllQgCiSL8=; b=PTxNcSA1EQVti3zFn8wzAXwXsGEab7lC6RkcDMSu3Dezpsv42jrT4fzx Iiz/MCPnrmnr8dnhDQQi2NK/oAvziA6ornP8t1F/Sf9pVymRboBAJmU0j XBjjBeTGbYdc5U2WhneQcHMQvVI7pH6m0HoX5z9Z3aYyj2Vu38Hc6YA81 5xnvh+1GP8xD6b1WYxa8RzYCUDMiVyWxA3Y03IvdIRfofOgB2Jqo8zstA MBkP2rD7NeRMjmMTGNEg1W9gg5Der2lP9gH/JUvIc+Ap3FfGTLU88bQQq YZRMbh4yYNfV3hy6m9sNbArNMrlPVpspDj/Nm4pkF+r2LjaF1Rr2J78fL A==; X-IronPort-AV: E=Sophos; i="5.24,321,1455001200"; d="scan'208,217"; a="11682796" Received: from unknown (HELO den-ipcld-02-data1.paypalcorp.com) ([10.184.246.164]) by den-ipout-03-data1.paypalcorp.com with ESMTP; 11 Mar 2016 14:57:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,321,1455001200"; d="scan'208,217";a="5618236" X-CloudService: Office365 Received: from mail-bn1lp0142.outbound.protection.outlook.com (HELO na01-bn1-obe.outbound.protection.outlook.com) ([207.46.163.142]) by den-ipcld-02-data1.paypalcorp.com with ESMTP/TLS/AES256-SHA256; 11 Mar 2016 14:57:39 -0700 Received: from SN1PR06MB2094.namprd06.prod.outlook.com (10.169.125.142) by SN1PR06MB2096.namprd06.prod.outlook.com (10.169.125.144) with Microsoft SMTP Server (TLS) id 15.1.434.16; Fri, 11 Mar 2016 21:57:37 +0000 Received: from SN1PR06MB2094.namprd06.prod.outlook.com ([10.169.125.142]) by SN1PR06MB2094.namprd06.prod.outlook.com ([10.169.125.142]) with mapi id 15.01.0434.016; Fri, 11 Mar 2016 21:57:38 +0000 From: "Hodges, Jeff" <jeff.hodges@paypal.com> To: Andrei Popov <Andrei.Popov@microsoft.com>, "Dirk Balfanz (balfanz@google.com)" <balfanz@google.com> Thread-Topic: [Unbearable] Referred token binding IDs Thread-Index: AQHReNEDYw8BpTDZrk+xA8bz5ugEpJ9PoB4AgACLfYCABB6ygA== Date: Fri, 11 Mar 2016 21:57:37 +0000 Message-ID: <D3087418.94239%jehodges@paypalcorp.com> References: <CACdeXi+seOpR8q5e8bdvO0eHwxaEDuE0UBsaSfYRKqR-+at-7w@mail.gmail.com> <D3047F47.90E4A%jehodges@paypalcorp.com> <BN3PR03MB13989D5440652D5D664682BA8CB20@BN3PR03MB1398.namprd03.prod.outlook.com> In-Reply-To: <BN3PR03MB13989D5440652D5D664682BA8CB20@BN3PR03MB1398.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=paypal.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [173.224.162.69] x-ms-office365-filtering-correlation-id: a67707aa-abde-4e39-1116-08d349f8292c x-microsoft-exchange-diagnostics: 1; SN1PR06MB2096; 5:STGbvb/barGffDyWG1EHkXR6hri7nq6dwyucbkgosqiQJ0pTmgeU5OxbTHyC8nFZaeg2DgbgyQPdRQq7uF2j3ig4bUycJIrxQqxPWmLCSteYpeXET/Ngi6RgwLqaLgsdBDpdQFIWwrcQWXiFO53cJA==; 24:Y8nd12x9tTUQzBGgM6I4AJezhARn6M3g2CdNs061Qrkyhyp8U0dLWUsGTz8/CMuHyqw378RYNFOh8crn8G7T6AVe2rkR44FW4Flp1qYw2ac= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR06MB2096; x-microsoft-antispam-prvs: <SN1PR06MB20968A57E9DF3744E69614F593B50@SN1PR06MB2096.namprd06.prod.outlook.com> x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR06MB2096; BCL:0; PCL:0; RULEID:; SRVR:SN1PR06MB2096; x-forefront-prvs: 087894CD3C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(13464003)(479174004)(377454003)(189002)(24454002)(2950100001)(2421001)(1096002)(2906002)(19617315012)(106116001)(50986999)(5008740100001)(102836003)(10300500001)(1220700001)(76176999)(82432001)(6116002)(10400500002)(3280700002)(10770500004)(2900100001)(87936001)(86362001)(77096005)(36756003)(99286002)(92566002)(54356999)(575784001)(3660700001)(2561002)(4326007)(5001770100001)(81166005)(189998001)(66066001)(5004730100002)(122556002)(10290500002)(19580405001)(5002640100001)(19580395003)(97736004)(4500500003)(77072002)(16236675004)(1511001)(10130500003)(3846002)(15395725005)(586003)(73692002)(15975445007)(10010500004)(56826009); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR06MB2096; H:SN1PR06MB2094.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D308741894239jehodgespaypalcorpcom_" MIME-Version: 1.0 X-OriginatorOrg: paypal.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2016 21:57:37.7405 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fb007914-6020-4374-977e-21bac5f3f4c8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR06MB2096 X-CFilter: Scanned den1 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/xow4E8qg9jdQ2uhA5iFZ_nw95a0> Cc: IETF Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 11 Mar 2016 21:57:44 -0000 --_000_D308741894239jehodgespaypalcorpcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 3/8/16, 3:02 PM, "Andrei Popov" <Andrei.Popov@microsoft.com<mailto:Andre= i.Popov@microsoft.com>> wrote: The current HTTPSTB says: " The TokenBindingMessage SHOULD contain a TokenBinding with TokenBindingType referred_token_binding. If included, this TokenBinding MUST be signed with the Token Binding key used by the client for connections between itself and the Token Consumer... As described above, the TokenBindingMessage MUST additionally contain a Provided Token Binding ID..." Based on the above, currently only option ii) exists. Well, what you are asserting above is only implied by the text and the redi= rect pattern: the text does not say anything explicit about how many TokenB= indingMessage.TokenBinding's of which type may be present in a given TokenB= indingMessage. I.e. it does not explicitly say to create a new TokenBindin= gMessage containing only two TokenBindings when the client follows a redire= ct response containing the Include-Referer-Token-Binding-ID response header= field (as opposed to adding a TokenBinding to the TokenBindingMessage its = been using). Dirk, please correct me if I'm wrong, but I believe this means that IDP C w= ould generate a token for IDP B, which would then generate a token for RP A= . Not necessarily -- the message exchange pattern is overall governed by the = federation protocol profile in use, as are the roles of the sending/receivi= ng entities, and it's all subject to how a deployment is configured in actu= ality: i.e., Nick's scenario of an IDP changing the URL for their security= token generation endpoint is plausible. Plus, the "return address" for the= IDP to redirect to, in order to deliver the generated security token, is t= ypcially specified in the fed protocol's authn request message (which is ge= nerated by A) and typically will point back to A (ie not B). [ saml: Asser= tionConsumerServiceURL, see S 3.4.1 in [1]; OIDC: redirect_uri, see S 3.1.2= .1 in [2] ] thus I continue to think that the flexibility in fed protocols (and their d= eployments) requires a bit more flexibility in -tokbind-https's mechanism, = we should think about adding an explicit signal from server to client wrt w= hich TBID is to be referred. [1] https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf [2] http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest HTTPSTB does not explicitly discuss multiple-redirect scenarios (perhaps we= should add some language). Also, presently, -tokbind-protocol-04 does not indicate there's any particular ordering of T= okenBinding structs within TBMsg. >From the TBPROTO perspective, there should be at least one binding in the T= B message, no other constraints on TB type or ordering. The idea is for the= basic protocol to accommodate cases other than HTTPS-style federation. agreed wrt TBPROTO. -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Hodges, = Jeff Sent: Tuesday, March 8, 2016 2:43 PM To: Nick Harper <nharper@google.com<mailto:nharper@google.com>> Cc: IETF Tokbind WG <unbearable@ietf.org<mailto:unbearable@ietf.org>> Subject: Re: [Unbearable] Referred token binding IDs On 3/7/16, 4:24 PM nharper@google.com<mailto:nharper@google.com>> wrote: If a client receives an "Include-Referer-Token-Binding-ID" header in response to a request that already had a referred TBID in the TokenBindingMessage, should it include both of those TBIDs as referred TBIDs in the next request? I.e. - client sends request to server A w/ provided TBID A - gets back Include-Referer-Token-Binding-ID header on a redirect to B - client sends request to B w/ provided TBID B, referred TBID A - gets back Include-Referer-Token-Binding-ID header on a redirect to C Possible behaviors: i) client sends request to C w/ provided TBID C, referred TBID B, referred TBID A ii) client sends request to C w/ provided TBID C, referred TBID B iii) client sends request to C w/ provided TBID C, referred TBID A, referred TBID B I don't know what a use case for this situation might be, but the spec seems unclear to me on what to do. Option (i) seems most likely, followed by option (ii). One potential way this might happen is if an identity provider changes the URL for their endpoint that generates tokens and sets up a redirect from the old URL to the new URL. In that case, option (ii) wouldn't work because both B and C are the IdP. In this latter case it seems all C needs in the TBMsg, if it is just going = to redirect back to A with an "id token w/TBID A", is {provided TBID C, ref= erred TBID A}, yes? though, as presently specified in -tokbind-https, there's no way for B to s= ignal to the client that the client needs to present TBID A to C as 'referr= ed' rather than presenting TBID B as referred. Also, presently, -tokbind-protocol-04 does not indicate there's any particular ordering of T= okenBinding structs within TBMsg. It's offhand plausible for the client to = just keep appending referred TBIDs to the TBMsg, and whichever entity is th= e ultimate "token provider" to incorporate the correct (i.e., "first") referred TBID in whatever federation token it is issuing, but then= there'd be the chance for some sort of "redirect loop" (either accidentall= y or maliciously) and having a size-unbounded TBMsg. perhaps a way to create the necessary signaling is: instead of just a boole= an, the Include-Referer-Token-Binding-ID header field could convey the TBID= to be referred? i.e., in the above use case, B knows that it isn't the pre= sent Token Provider, and can be configured to indicate to the client which = TBID to include in the TBMsg to C as "referred" (which in this case is TBID= A)...? perhaps we need to have folks familiar with actual federated ID deployments= (such as the tokbind wg chairs :) hold forth on the sorts of use cases th= ey are aware of that -tokbind-https doesn't (yet) address, but perhaps shou= ld at least mention and maybe at least provide some guidance about? HTH, =3DJeffH _______________________________________________ Unbearable mailing list Unbearable@ietf.org<mailto:Unbearable@ietf.org> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7cAndrei.Popov%40micr= osoft.com%7c29ccc4b816964749c50708d347a3156f%7c72f988bf86f141af91ab2d7cd011= db47%7c1&sdata=3DUfJy3GD5cEOSaRSMQzxoHYzR2JPv0RHmtHam4ijqqE4%3d --_000_D308741894239jehodgespaypalcorpcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <F5603A4C393DDA4F9EFFA4F4FC0CF213@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif;"> <span id=3D"OLK_SRC_BODY_SECTION"> <div> <div>On 3/8/16, 3:02 PM, "Andrei Popov" <<a href=3D"mailto:And= rei.Popov@microsoft.com">Andrei.Popov@microsoft.com</a>> wrote:</div> </div> <blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT:= #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"> <div> <div> <div>The current HTTPSTB says: </div> <div>" The TokenBindingMessage SHOULD contain a TokenBinding with</div= > <div>   TokenBindingType referred_token_binding.  If in= cluded, this</div> <div>   TokenBinding MUST be signed with the Token Binding key us= ed by the</div> <div>   client for connections between itself and the Token Consu= mer...</div> <div><br> </div> <div>   As described above, the TokenBindingMessage MUST addition= ally contain</div> <div>   a Provided Token Binding ID..."</div> <div><br> </div> <div>Based on the above, currently only option ii) exists. </div> </div> </div> </blockquote> </span> <div><br> </div> <div>Well, what you are asserting above is only implied by the text and the= redirect pattern: the text does not say anything explicit about how many T= okenBindingMessage.TokenBinding's of which type may be present in a given T= okenBindingMessage. I.e. it does not explicitly say to create a new  TokenBindingMessage containing on= ly two TokenBindings when the client follows a redirect response containing= the Include-Referer-Token-Binding-ID response header field (as opposed to = adding a TokenBinding to the TokenBindingMessage its been using). </div> <div><br> </div> <div><br> </div> <span id=3D"OLK_SRC_BODY_SECTION"> <blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT:= #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"> <div> <div> <div>Dirk, please correct me if I'm wrong, but I believe this means that ID= P C would generate a token for IDP B, which would then generate a token for= RP A. </div> </div> </div> </blockquote> </span> <div><br> </div> <div>Not necessarily -- the message exchange pattern is overall governed by= the federation protocol profile in use, as are the roles of the sending/re= ceiving entities, and it's all subject to how a deployment is configured in= actuality:  i.e., Nick's scenario of an <span style=3D"font-family: Calibri; font-size: medium;">IDP ch= anging the URL for their security token generation endpoint is plausible. P= lus, the "return address" for the IDP to redirect to, in order to= deliver the generated security token, is typcially specified in the fed protocol's authn request message (which is generated = by A) and typically will point back to A (ie not B).  [ </span>sa= ml: AssertionConsumerServiceURL, see S 3.4.1 in [1]; OIDC: redirect_uri, se= e S 3.1.2.1 in [2] ]</div> <div><br> </div> <div>thus I continue to think that the flexibility in fed protocols (and th= eir deployments) requires a bit more flexibility in -tokbind-https's mechan= ism, we should think about adding an explicit signal from server to client = wrt which TBID is to be referred. </div> <div><br> </div> <div><br> </div> <div>[1] <a href=3D"https://docs.oasis-open.org/security/saml/v2.0/sam= l-core-2.0-os.pdf">https://docs.oasis-open.org/security/saml/v2.0/saml-core= -2.0-os.pdf</a></div> <div>[2] <a href=3D"http://openid.net/specs/openid-connect-core-1_0.ht= ml#AuthRequest">http://openid.net/specs/openid-connect-core-1_0.html#AuthRe= quest</a> </div> <div><br> </div> <div><br> </div> <span id=3D"OLK_SRC_BODY_SECTION"> <blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT:= #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"> <div> <div> <div>HTTPSTB does not explicitly discuss multiple-redirect scenarios (perha= ps we should add some language).</div> <div><br> </div> <blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT:= #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"> <div>Also, presently,</div> <div>-tokbind-protocol-04 does not indicate there's any particular ordering= of TokenBinding structs within TBMsg.</div> </blockquote> <div><br> </div> <div>From the TBPROTO perspective, there should be at least one binding in = the TB message, no other constraints on TB type or ordering. The idea is fo= r the basic protocol to accommodate cases other than HTTPS-style federation= .</div> </div> </div> </blockquote> </span> <div><br> </div> <div>agreed wrt TBPROTO. </div> <div><br> </div> <div><br> </div> <span id=3D"OLK_SRC_BODY_SECTION"> <blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT:= #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"> <div> <div> <div><br> </div> <div>-----Original Message-----</div> <div>From: Unbearable [<a href=3D"mailto:unbearable-bounces@ietf.org">mailt= o:unbearable-bounces@ietf.org</a>] On Behalf Of Hodges, Jeff</div> <div>Sent: Tuesday, March 8, 2016 2:43 PM</div> <div>To: Nick Harper <<a href=3D"mailto:nharper@google.com">nharper@goog= le.com</a>></div> <div>Cc: IETF Tokbind WG <<a href=3D"mailto:unbearable@ietf.org">unbeara= ble@ietf.org</a>></div> <div>Subject: Re: [Unbearable] Referred token binding IDs</div> <div><br> </div> <div>On 3/7/16, 4:24 PM <a href=3D"mailto:nharper@google.com">nharper@googl= e.com</a>> wrote:</div> <blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT:= #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"> <div>If a client receives an "Include-Referer-Token-Binding-ID" h= eader in </div> <div>response to a request that already had a referred TBID in the </div> <div>TokenBindingMessage, should it include both of those TBIDs as referred= </div> <div>TBIDs in the next request?</div> <div><br> </div> <div>I.e.</div> <div>- client sends request to server A w/ provided TBID A</div> <div>- gets back Include-Referer-Token-Binding-ID header on a redirect to B= </div> <div>- client sends request to B w/ provided TBID B, referred TBID A</div> <div>- gets back Include-Referer-Token-Binding-ID header on a redirect to C= </div> <div>Possible behaviors:</div> <div>i) client sends request to C w/ provided TBID C, referred TBID B, </di= v> <div>referred TBID A</div> <div>ii) client sends request to C w/ provided TBID C, referred TBID B</div= > <div><br> </div> <div>iii) client sends request to C w/ provided TBID C, referred TBID A, </= div> <div>referred TBID B</div> <div><br> </div> <div><br> </div> <div>I don't know what a use case for this situation might be, but the spec= </div> <div>seems unclear to me on what to do. Option (i) seems most likely, </div= > <div>followed by option (ii).</div> </blockquote> <div><br> </div> <blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT:= #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"> <div>One potential way this might happen is if an identity provider changes= </div> <div>the URL for their endpoint that generates tokens and sets up a redirec= t </div> <div>from the old URL to the new URL. In that case, option (ii) wouldn't </= div> <div>work because both B and C are the IdP.</div> </blockquote> <div><br> </div> <div>In this latter case it seems all C needs in the TBMsg, if it is just g= oing to redirect back to A with an "id token w/TBID A", is {provi= ded TBID C, referred TBID A}, yes?</div> <div><br> </div> <div>though, as presently specified in -tokbind-https, there's no way for B= to signal to the client that the client needs to present TBID A to C as 'r= eferred' rather than presenting TBID B as referred. Also, presently,</div> <div>-tokbind-protocol-04 does not indicate there's any particular ordering= of TokenBinding structs within TBMsg. It's offhand plausible for the clien= t to just keep appending referred TBIDs to the TBMsg, and whichever entity = is the ultimate "token provider" to incorporate the correct (i.e.,</div> <div>"first") referred TBID in whatever federation token it is is= suing, but then there'd be the chance for some sort of "redirect loop&= quot; (either accidentally or maliciously) and having a size-unbounded TBMs= g.</div> <div><br> </div> <div>perhaps a way to create the necessary signaling is: instead of just a = boolean, the Include-Referer-Token-Binding-ID header field could convey the= TBID to be referred? i.e., in the above use case, B knows that it isn't th= e present Token Provider, and can be configured to indicate to the client which TBID to include in the TBMsg= to C as "referred" (which in this case is TBID A)...?</div> <div><br> </div> <div>perhaps we need to have folks familiar with actual federated ID deploy= ments (such as the tokbind wg chairs :)  hold forth on the sorts = of use cases they are aware of that -tokbind-https doesn't (yet) address, b= ut perhaps should at least mention and maybe at least provide some guidance about?  </div> <div><br> </div> <div>HTH, </div> <div><br> </div> <div>=3DJeffH</div> <div><br> </div> <div><br> </div> <div>_______________________________________________</div> <div>Unbearable mailing list</div> <div><a href=3D"mailto:Unbearable@ietf.org">Unbearable@ietf.org</a></div> <div><a href=3D"https://na01.safelinks.protection.outlook.com/?url=3Dhttps%= 3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7= cAndrei.Popov%40microsoft.com%7c29ccc4b816964749c50708d347a3156f%7c72f988bf= 86f141af91ab2d7cd011db47%7c1&sdata=3DUfJy3GD5cEOSaRSMQzxoHYzR2JPv0RHmtH= am4ijqqE4%3d">https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a= %2f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7cA= ndrei.Popov%40microsoft.com%7c29ccc4b816964749c50708d347a3156f%7c72f988bf86= f141af91ab2d7cd011db47%7c1&sdata=3DUfJy3GD5cEOSaRSMQzxoHYzR2JPv0RHmtHam= 4ijqqE4%3d</a></div> <div><br> </div> </div> </div> </blockquote> </span> <div><br> </div> <div><br> </div> </body> </html> --_000_D308741894239jehodgespaypalcorpcom_-- From nobody Fri Mar 11 14:42:33 2016 Return-Path: <balfanz@google.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 E65A112DD3D for <unbearable@ietfa.amsl.com>; Fri, 11 Mar 2016 14:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 H76ShdOp2uCY for <unbearable@ietfa.amsl.com>; Fri, 11 Mar 2016 14:42:27 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0032A12DD2C for <unbearable@ietf.org>; Fri, 11 Mar 2016 14:42:26 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id p65so34895219wmp.0 for <unbearable@ietf.org>; Fri, 11 Mar 2016 14:42:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LIl2HpI0BJ37GUHZ717SGoFSVqGmgX6spQHyPShLkYU=; b=Io9DTd2Ib67Nplf0G5WAg7rmKzvWUL8BbkktkHkzGriKBQ1r3kP4M6kwUX4okEBsn9 2VvrdsI3QTcyOgk9N27QB1ZApO/f6rZhYsNfNqOsNqshcUuea0/0n6rZoDd7T6AV+JT+ tyOao3FDs5ZcNvTz8qsmCKRqOeHbQZuLOc2BteQb1evSw+XAiqRjRUNC/srx+SHMAKUz 10CdsuOSbq1zqg8kaJPLAVVjplJOBEPY7exb2PyYzpnWXFx9cQwR7V2tb+r9yk98CHlq BABHbNgYaBFjQwtDmYAbt63Ur72mgcVq+u/lQ86RAvFZpmH2XdRPGO4DbYiovMah402K fFzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LIl2HpI0BJ37GUHZ717SGoFSVqGmgX6spQHyPShLkYU=; b=KRD2EeZLU8tDl1qIdgj5mFf61uYC1hcvQHk6Wlr7h9S0IDdwnHiRnIm+3TpCRSSgn6 +fplFO+yn0IE7R7v70bo0waX7MQ8aJWOu86rB2k1q2GZHD/BqmsITJsgPJfrNj4hYeZ0 O9ya2ABXiXhPtSO1EmF48Z96WVkMfN9so3GAAHDsyxRWxPilQHAyYAGdPYLVKKjn7VKi +2dht3pcT5CTohsv6bzYWShlNPIypchBUUXNJkuyuwhUwyn1pYALltrA3I5rc2YY98sS VGqYyUpTrkvF+jOMc8snZrpYrboAhlr7pPVizQ2yanQZTH8gYeNHA4VlXNjAxR2zmlcx xvmw== X-Gm-Message-State: AD7BkJJAgrDcZTpYp9OrMShzVgAtFRGiaEmYBVj4YOtCdrP+vuqkw886nAT6CrrTIdc6PuSFeuSMgXAkLEY3JfW5 X-Received: by 10.28.50.133 with SMTP id y127mr5153007wmy.4.1457736145143; Fri, 11 Mar 2016 14:42:25 -0800 (PST) MIME-Version: 1.0 References: <CACdeXi+seOpR8q5e8bdvO0eHwxaEDuE0UBsaSfYRKqR-+at-7w@mail.gmail.com> <D3047F47.90E4A%jehodges@paypalcorp.com> <BN3PR03MB13989D5440652D5D664682BA8CB20@BN3PR03MB1398.namprd03.prod.outlook.com> <D3087418.94239%jehodges@paypalcorp.com> In-Reply-To: <D3087418.94239%jehodges@paypalcorp.com> From: Dirk Balfanz <balfanz@google.com> Date: Fri, 11 Mar 2016 22:42:15 +0000 Message-ID: <CADHfa2Cf=hMrxbHR9d41svy8C9zM3FC4MmMxP=G9E0Kt2st_Sg@mail.gmail.com> To: "Hodges, Jeff" <jeff.hodges@paypal.com>, Andrei Popov <Andrei.Popov@microsoft.com> Content-Type: multipart/alternative; boundary=001a114293b41be009052dcda54f Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/YVbEJZa5aexsfXzy1NMnowOyto8> Cc: IETF Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 11 Mar 2016 22:42:32 -0000 --001a114293b41be009052dcda54f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry for chiming in late. The intended semantics in the current spec is ii). I believe that covers all the use cases that you're describing: Let's first consider the case where there is one Relying Party, and one Identity Provider. The RP might go through a bunch of redirects before ultimately handing things off to the IdP, and the IdP might go through a bunch of redirects before ultimately handling the RP request. Same on the way back from the IdP to the RP. The one redirect where the referred token binding is necessary is the redirect that crosses functional boundaries: from the RP to the IdP. If the first endpoint at the IdP isn't the one that is processing the RP request (because, say, it's the old one and it's now redirecting to the new one), that endpoint needs to encode the information it learns (i.e., what is the public key that the client is using with the RP) in some way (which can be proprietary to the IdP) and pass that along as the request is handed off. On the way back, after the IdP redirects back to the RP, the RP just needs to make sure that one of the endpoints in the redirect chain is on the same eTLD+1 as the endpoint that did the hand-off to the IdP, so it can process the IdP response there. Next, let's consider what happens if there are multiple IdP's involved, say something like rp.com -> identity-as-a-service.com -> idp.com. In that case, identity-as-a-service.com acts like an IdP to rp.com, and as an RP to idp.com, so we play the game described above twice. It wouldn't make sense here if idp.com somehow knew what public key the client is using with rp.co= m - it's useless information. In a scenario like this, idp.com needs to strongly authenticate the client to identity-as-a-service.com, not to rp.co= m . Does this make sense? Dirk. On Fri, Mar 11, 2016 at 1:57 PM Hodges, Jeff <jeff.hodges@paypal.com> wrote= : > On 3/8/16, 3:02 PM, "Andrei Popov" <Andrei.Popov@microsoft.com> wrote: > > The current HTTPSTB says: > " The TokenBindingMessage SHOULD contain a TokenBinding with > TokenBindingType referred_token_binding. If included, this > TokenBinding MUST be signed with the Token Binding key used by the > client for connections between itself and the Token Consumer... > > As described above, the TokenBindingMessage MUST additionally contain > a Provided Token Binding ID..." > > Based on the above, currently only option ii) exists. > > > Well, what you are asserting above is only implied by the text and the > redirect pattern: the text does not say anything explicit about how many > TokenBindingMessage.TokenBinding's of which type may be present in a give= n > TokenBindingMessage. I.e. it does not explicitly say to create a new > TokenBindingMessage containing only two TokenBindings when the client > follows a redirect response containing the Include-Referer-Token-Binding-= ID > response header field (as opposed to adding a TokenBinding to the > TokenBindingMessage its been using). > > > Dirk, please correct me if I'm wrong, but I believe this means that IDP C > would generate a token for IDP B, which would then generate a token for R= P > A. > > > Not necessarily -- the message exchange pattern is overall governed by th= e > federation protocol profile in use, as are the roles of the > sending/receiving entities, and it's all subject to how a deployment is > configured in actuality: i.e., Nick's scenario of an IDP changing the > URL for their security token generation endpoint is plausible. Plus, the > "return address" for the IDP to redirect to, in order to deliver the > generated security token, is typcially specified in the fed protocol's > authn request message (which is generated by A) and typically will point > back to A (ie not B). [ saml: AssertionConsumerServiceURL, see S 3.4.1 > in [1]; OIDC: redirect_uri, see S 3.1.2.1 in [2] ] > > thus I continue to think that the flexibility in fed protocols (and their > deployments) requires a bit more flexibility in -tokbind-https's mechanis= m, > we should think about adding an explicit signal from server to client wrt > which TBID is to be referred. > > > [1] https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf > [2] http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest > > > HTTPSTB does not explicitly discuss multiple-redirect scenarios (perhaps > we should add some language). > > Also, presently, > -tokbind-protocol-04 does not indicate there's any particular ordering of > TokenBinding structs within TBMsg. > > > From the TBPROTO perspective, there should be at least one binding in the > TB message, no other constraints on TB type or ordering. The idea is for > the basic protocol to accommodate cases other than HTTPS-style federation= . > > > agreed wrt TBPROTO. > > > > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org > <unbearable-bounces@ietf.org>] On Behalf Of Hodges, Jeff > Sent: Tuesday, March 8, 2016 2:43 PM > To: Nick Harper <nharper@google.com> > Cc: IETF Tokbind WG <unbearable@ietf.org> > Subject: Re: [Unbearable] Referred token binding IDs > > On 3/7/16, 4:24 PM nharper@google.com> wrote: > > If a client receives an "Include-Referer-Token-Binding-ID" header in > response to a request that already had a referred TBID in the > TokenBindingMessage, should it include both of those TBIDs as referred > TBIDs in the next request? > > I.e. > - client sends request to server A w/ provided TBID A > - gets back Include-Referer-Token-Binding-ID header on a redirect to B > - client sends request to B w/ provided TBID B, referred TBID A > - gets back Include-Referer-Token-Binding-ID header on a redirect to C > Possible behaviors: > i) client sends request to C w/ provided TBID C, referred TBID B, > referred TBID A > ii) client sends request to C w/ provided TBID C, referred TBID B > > iii) client sends request to C w/ provided TBID C, referred TBID A, > referred TBID B > > > I don't know what a use case for this situation might be, but the spec > seems unclear to me on what to do. Option (i) seems most likely, > followed by option (ii). > > > One potential way this might happen is if an identity provider changes > the URL for their endpoint that generates tokens and sets up a redirect > from the old URL to the new URL. In that case, option (ii) wouldn't > work because both B and C are the IdP. > > > In this latter case it seems all C needs in the TBMsg, if it is just goin= g > to redirect back to A with an "id token w/TBID A", is {provided TBID C, > referred TBID A}, yes? > > though, as presently specified in -tokbind-https, there's no way for B to > signal to the client that the client needs to present TBID A to C as > 'referred' rather than presenting TBID B as referred. Also, presently, > -tokbind-protocol-04 does not indicate there's any particular ordering of > TokenBinding structs within TBMsg. It's offhand plausible for the client = to > just keep appending referred TBIDs to the TBMsg, and whichever entity is > the ultimate "token provider" to incorporate the correct (i.e., > "first") referred TBID in whatever federation token it is issuing, but > then there'd be the chance for some sort of "redirect loop" (either > accidentally or maliciously) and having a size-unbounded TBMsg. > > perhaps a way to create the necessary signaling is: instead of just a > boolean, the Include-Referer-Token-Binding-ID header field could convey t= he > TBID to be referred? i.e., in the above use case, B knows that it isn't t= he > present Token Provider, and can be configured to indicate to the client > which TBID to include in the TBMsg to C as "referred" (which in this case > is TBID A)...? > > perhaps we need to have folks familiar with actual federated ID > deployments (such as the tokbind wg chairs :) hold forth on the sorts of > use cases they are aware of that -tokbind-https doesn't (yet) address, bu= t > perhaps should at least mention and maybe at least provide some guidance > about? > > HTH, > > =3DJeffH > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7cAndrei.Popov%40mi= crosoft.com%7c29ccc4b816964749c50708d347a3156f%7c72f988bf86f141af91ab2d7cd0= 11db47%7c1&sdata=3DUfJy3GD5cEOSaRSMQzxoHYzR2JPv0RHmtHam4ijqqE4%3d > > > > --001a114293b41be009052dcda54f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Sorry for chiming in late. The intended semantics in the c= urrent spec is ii).<div><br></div><div>I believe that covers all the use ca= ses that you're describing: Let's first consider the case where the= re is one Relying Party, and one Identity Provider. The RP might go through= a bunch of redirects before ultimately handing things off to the IdP, and = the IdP might go through a bunch of redirects before ultimately handling th= e RP request. Same on the way back from the IdP to the RP.</div><div><br></= div><div>The one redirect where the referred token binding is necessary is = the redirect that crosses functional boundaries: from the RP to the IdP. If= the first endpoint at the IdP isn't the one that is processing the RP = request (because, say, it's the old one and it's now redirecting to= the new one), that endpoint needs to encode the information it learns (i.e= ., what is the public key that the client is using with the RP) in some way= (which can be proprietary to the IdP) and pass that along as the request i= s handed off.</div><div><br></div><div>On the way back, after the IdP redir= ects back to the RP, the RP just needs to make sure that one of the endpoin= ts in the redirect chain is on the same eTLD+1 as the endpoint that did the= hand-off to the IdP, so it can process the IdP response there.</div><div><= br></div><div>Next, let's consider what happens if there are multiple I= dP's involved, say something like <a href=3D"http://rp.com">rp.com</a> = -> <a href=3D"http://identity-as-a-service.com">identity-as-a-service.co= m</a> -> <a href=3D"http://idp.com">idp.com</a>. In that case, <a href= =3D"http://identity-as-a-service.com">identity-as-a-service.com</a> acts li= ke an IdP to <a href=3D"http://rp.com">rp.com</a>, and as an RP to <a href= =3D"http://idp.com">idp.com</a>, so we play the game described above twice.= It wouldn't make sense here if <a href=3D"http://idp.com">idp.com</a> = somehow knew what public key the client is using with <a href=3D"http://rp.= com">rp.com</a> - it's useless information. In a scenario like this, <a= href=3D"http://idp.com">idp.com</a> needs to strongly authenticate the cli= ent to <a href=3D"http://identity-as-a-service.com">identity-as-a-service.c= om</a>, not to <a href=3D"http://rp.com">rp.com</a>.</div><div><br></div><d= iv>Does this make sense?</div><div><br></div><div>Dirk.</div><div><br></div= ><div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Mar 11, 2016 = at 1:57 PM Hodges, Jeff <<a href=3D"mailto:jeff.hodges@paypal.com">jeff.= hodges@paypal.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote"= style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d= iv style=3D"word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-famil= y:Calibri,sans-serif"> <span> <div> <div>On 3/8/16, 3:02 PM, "Andrei Popov" <<a href=3D"mailto:And= rei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov@microsoft.com</a>&g= t; wrote:</div> </div> <blockquote style=3D"BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0= 0 5"> <div> <div> <div>The current HTTPSTB says: </div> <div>" The TokenBindingMessage SHOULD contain a TokenBinding with</div= > <div>=C2=A0=C2=A0 TokenBindingType referred_token_binding.=C2=A0=C2=A0If in= cluded, this</div> <div>=C2=A0=C2=A0 TokenBinding MUST be signed with the Token Binding key us= ed by the</div> <div>=C2=A0=C2=A0 client for connections between itself and the Token Consu= mer...</div> <div><br> </div> <div>=C2=A0=C2=A0 As described above, the TokenBindingMessage MUST addition= ally contain</div> <div>=C2=A0=C2=A0 a Provided Token Binding ID..."</div> <div><br> </div> <div>Based on the above, currently only option ii) exists. </div> </div> </div> </blockquote> </span> <div><br> </div> </div><div style=3D"word-wrap:break-word;color:rgb(0,0,0);font-size:14px;fo= nt-family:Calibri,sans-serif"><div>Well, what you are asserting above is on= ly implied by the text and the redirect pattern: the text does not say anyt= hing explicit about how many TokenBindingMessage.TokenBinding's of whic= h type may be present in a given TokenBindingMessage. I.e. it does not explicitly say to create a new =C2=A0TokenBindingMessage containing on= ly two TokenBindings when the client follows a redirect response containing= the Include-Referer-Token-Binding-ID response header field (as opposed to = adding a TokenBinding to the TokenBindingMessage its been using).=C2=A0</div></div><div style=3D"word-wrap:break-word;color= :rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"> <div><br> </div> <div><br> </div> <span> <blockquote style=3D"BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0= 0 5"> <div> <div> <div>Dirk, please correct me if I'm wrong, but I believe this means tha= t IDP C would generate a token for IDP B, which would then generate a token= for RP A. </div> </div> </div> </blockquote> </span> <div><br> </div> </div><div style=3D"word-wrap:break-word;color:rgb(0,0,0);font-size:14px;fo= nt-family:Calibri,sans-serif"><div>Not necessarily -- the message exchange = pattern is overall governed by the federation protocol profile in use, as a= re the roles of the sending/receiving entities, and it's all subject to= how a deployment is configured in actuality: =C2=A0i.e., Nick's scenar= io of an=C2=A0<span style=3D"font-family:Calibri;font-size:medium">IDP changi= ng the URL for their security token generation endpoint is plausible. Plus,= the "return address" for the IDP to redirect to, in order to del= iver the generated security token, is typcially specified in the fed protocol's authn request message (which is genera= ted by A) and typically will point back to A (ie not B). =C2=A0[=C2=A0</spa= n>saml: AssertionConsumerServiceURL, see S 3.4.1 in [1]; OIDC: redirect_uri= , see S 3.1.2.1 in [2] ]</div> <div><br> </div> <div>thus I continue to think that the flexibility in fed protocols (and th= eir deployments) requires a bit more flexibility in -tokbind-https's me= chanism, we should think about adding an explicit signal from server to cli= ent wrt which TBID is to be referred.=C2=A0</div> <div><br> </div> <div><br> </div> <div>[1]=C2=A0<a href=3D"https://docs.oasis-open.org/security/saml/v2.0/sam= l-core-2.0-os.pdf" target=3D"_blank">https://docs.oasis-open.org/security/s= aml/v2.0/saml-core-2.0-os.pdf</a></div> <div>[2]=C2=A0<a href=3D"http://openid.net/specs/openid-connect-core-1_0.ht= ml#AuthRequest" target=3D"_blank">http://openid.net/specs/openid-connect-co= re-1_0.html#AuthRequest</a>=C2=A0</div></div><div style=3D"word-wrap:break-= word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"> <div><br> </div> <div><br> </div> <span> <blockquote style=3D"BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0= 0 5"> <div> <div> <div>HTTPSTB does not explicitly discuss multiple-redirect scenarios (perha= ps we should add some language).</div> <div><br> </div> <blockquote style=3D"BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0= 0 5"> <div>Also, presently,</div> <div>-tokbind-protocol-04 does not indicate there's any particular orde= ring of TokenBinding structs within TBMsg.</div> </blockquote> <div><br> </div> <div>From the TBPROTO perspective, there should be at least one binding in = the TB message, no other constraints on TB type or ordering. The idea is fo= r the basic protocol to accommodate cases other than HTTPS-style federation= .</div> </div> </div> </blockquote> </span> <div><br> </div> </div><div style=3D"word-wrap:break-word;color:rgb(0,0,0);font-size:14px;fo= nt-family:Calibri,sans-serif"><div>agreed wrt TBPROTO.=C2=A0</div></div><di= v style=3D"word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family= :Calibri,sans-serif"> <div><br> </div> <div><br> </div> <span> <blockquote style=3D"BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0= 0 5"> <div> <div> <div><br> </div> <div>-----Original Message-----</div> <div>From: Unbearable [<a href=3D"mailto:unbearable-bounces@ietf.org" targe= t=3D"_blank">mailto:unbearable-bounces@ietf.org</a>] On Behalf Of Hodges, J= eff</div> <div>Sent: Tuesday, March 8, 2016 2:43 PM</div> <div>To: Nick Harper <<a href=3D"mailto:nharper@google.com" target=3D"_b= lank">nharper@google.com</a>></div> <div>Cc: IETF Tokbind WG <<a href=3D"mailto:unbearable@ietf.org" target= =3D"_blank">unbearable@ietf.org</a>></div> <div>Subject: Re: [Unbearable] Referred token binding IDs</div> <div><br> </div> <div>On 3/7/16, 4:24 PM <a href=3D"mailto:nharper@google.com" target=3D"_bl= ank">nharper@google.com</a>> wrote:</div> <blockquote style=3D"BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0= 0 5"> <div>If a client receives an "Include-Referer-Token-Binding-ID" h= eader in </div> <div>response to a request that already had a referred TBID in the </div> <div>TokenBindingMessage, should it include both of those TBIDs as referred= </div> <div>TBIDs in the next request?</div> <div><br> </div> <div>I.e.</div> <div>- client sends request to server A w/ provided TBID A</div> <div>- gets back Include-Referer-Token-Binding-ID header on a redirect to B= </div> <div>- client sends request to B w/ provided TBID B, referred TBID A</div> <div>- gets back Include-Referer-Token-Binding-ID header on a redirect to C= </div> <div>Possible behaviors:</div> <div>i) client sends request to C w/ provided TBID C, referred TBID B, </di= v> <div>referred TBID A</div> <div>ii) client sends request to C w/ provided TBID C, referred TBID B</div= > <div><br> </div> <div>iii) client sends request to C w/ provided TBID C, referred TBID A, </= div> <div>referred TBID B</div> <div><br> </div> <div><br> </div> <div>I don't know what a use case for this situation might be, but the = spec </div> <div>seems unclear to me on what to do. Option (i) seems most likely, </div= > <div>followed by option (ii).</div> </blockquote> <div><br> </div> <blockquote style=3D"BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0= 0 5"> <div>One potential way this might happen is if an identity provider changes= </div> <div>the URL for their endpoint that generates tokens and sets up a redirec= t </div> <div>from the old URL to the new URL. In that case, option (ii) wouldn'= t </div> <div>work because both B and C are the IdP.</div> </blockquote> <div><br> </div> <div>In this latter case it seems all C needs in the TBMsg, if it is just g= oing to redirect back to A with an "id token w/TBID A", is {provi= ded TBID C, referred TBID A}, yes?</div> <div><br> </div> <div>though, as presently specified in -tokbind-https, there's no way f= or B to signal to the client that the client needs to present TBID A to C a= s 'referred' rather than presenting TBID B as referred. Also, prese= ntly,</div> <div>-tokbind-protocol-04 does not indicate there's any particular orde= ring of TokenBinding structs within TBMsg. It's offhand plausible for t= he client to just keep appending referred TBIDs to the TBMsg, and whichever= entity is the ultimate "token provider" to incorporate the correct (i.e.,</div> <div>"first") referred TBID in whatever federation token it is is= suing, but then there'd be the chance for some sort of "redirect l= oop" (either accidentally or maliciously) and having a size-unbounded = TBMsg.</div> <div><br> </div> <div>perhaps a way to create the necessary signaling is: instead of just a = boolean, the Include-Referer-Token-Binding-ID header field could convey the= TBID to be referred? i.e., in the above use case, B knows that it isn'= t the present Token Provider, and can be configured to indicate to the client which TBID to include in the TBMsg= to C as "referred" (which in this case is TBID A)...?</div> <div><br> </div> <div>perhaps we need to have folks familiar with actual federated ID deploy= ments (such as the tokbind wg chairs :)=C2=A0=C2=A0hold forth on the sorts = of use cases they are aware of that -tokbind-https doesn't (yet) addres= s, but perhaps should at least mention and maybe at least provide some guidance about?=C2=A0=C2=A0</div> <div><br> </div> <div>HTH, </div> <div><br> </div> <div>=3DJeffH</div> <div><br> </div> <div><br> </div> <div>_______________________________________________</div> <div>Unbearable mailing list</div> <div><a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ie= tf.org</a></div> <div><a href=3D"https://na01.safelinks.protection.outlook.com/?url=3Dhttps%= 3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7= cAndrei.Popov%40microsoft.com%7c29ccc4b816964749c50708d347a3156f%7c72f988bf= 86f141af91ab2d7cd011db47%7c1&sdata=3DUfJy3GD5cEOSaRSMQzxoHYzR2JPv0RHmtH= am4ijqqE4%3d" target=3D"_blank">https://na01.safelinks.protection.outlook.c= om/?url=3Dhttps%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable&= data=3D01%7c01%7cAndrei.Popov%40microsoft.com%7c29ccc4b816964749c50708d347a= 3156f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DUfJy3GD5cEOSaRSMQz= xoHYzR2JPv0RHmtHam4ijqqE4%3d</a></div> <div><br> </div> </div> </div> </blockquote> </span> <div><br> </div> <div><br> </div> </div></blockquote></div></div></div> --001a114293b41be009052dcda54f-- From nobody Fri Mar 11 14:45:27 2016 Return-Path: <nharper@google.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 0436812DD4A for <unbearable@ietfa.amsl.com>; Fri, 11 Mar 2016 14:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 wiBSH4R1SgL7 for <unbearable@ietfa.amsl.com>; Fri, 11 Mar 2016 14:45:22 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 309BA12DD1B for <unbearable@ietf.org>; Fri, 11 Mar 2016 14:45:22 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id e6so151492413vkh.2 for <unbearable@ietf.org>; Fri, 11 Mar 2016 14:45:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g7omomz5KyfWWSfs8Ba/+cJHj5XotTQAmy9brClq7+U=; b=AU5HQigT2UmeFpFMqBJRo7LapVchofpMd3l3xwgImPpkIFzi0w6RyqIZ16XCog9drB GtPUR0RfI0e39Rh6CjHs7RGD4W3bI6ETwNyEb+MfpYEVdSHX7PUU7Ez7nM+dJhcAVZfF YhuFyvHisBjcwSB+gkNzq5Tky9k7BogOl4Opb2VXddtVFeoDYXQan1CQUkBuKuJzPd8W m+de7rbKgXq5i3qSChUreBQLXAN/PdSOLfosTPoqmgbDCH0BQkREmRLfR8OK7R5x/Xcr 7mM7aAPMFdw11+G7CC52aNDLFUwWWsRNdF9XoEuKIVi+P6KaYAJzSeAoNP+z9MvTLjxz +Ujw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g7omomz5KyfWWSfs8Ba/+cJHj5XotTQAmy9brClq7+U=; b=Ank+clADD8wv7zrEEXL2oOzKd7LNumeUBzqSYXqgKgnqWbjDjxvH/O5TjfUk4ra+mS sWdpClKAuA3vxR+RP45vxkuR6tHU7ceo0avs3jIXz3vI3BGTotc5XvBNgsGLgIfHOWnc TEl3PhIfI1H1OHHPb2qNLsaVyT6WY+eZE7pG7MuCD25iRHVc+KdCP1nXv4/GBHzaijrQ G2SzFAGSd1ujaJEB6mI6ktzc2CkK3D0gwNwRqQmECo2j3dnHkLyDMUmemuz/C6VUaF1d b3KlknLJod3dBdsOQRyQ9S/DKevA2M2ZHUr+4Fd91kK33KU2TIPQB0FsshLh1I1OLi2/ W9PA== X-Gm-Message-State: AD7BkJJ56Jeozlsk1pB/o6YQM6ckHF2YPVwELGyGkicom+852FFvmRPpU4VszRJiZ4Xb0PrZZPo5f7tYkUtWvkYM X-Received: by 10.31.171.143 with SMTP id u137mr12852598vke.88.1457736320794; Fri, 11 Mar 2016 14:45:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.76.198 with HTTP; Fri, 11 Mar 2016 14:45:01 -0800 (PST) In-Reply-To: <CADHfa2Cf=hMrxbHR9d41svy8C9zM3FC4MmMxP=G9E0Kt2st_Sg@mail.gmail.com> References: <CACdeXi+seOpR8q5e8bdvO0eHwxaEDuE0UBsaSfYRKqR-+at-7w@mail.gmail.com> <D3047F47.90E4A%jehodges@paypalcorp.com> <BN3PR03MB13989D5440652D5D664682BA8CB20@BN3PR03MB1398.namprd03.prod.outlook.com> <D3087418.94239%jehodges@paypalcorp.com> <CADHfa2Cf=hMrxbHR9d41svy8C9zM3FC4MmMxP=G9E0Kt2st_Sg@mail.gmail.com> From: Nick Harper <nharper@google.com> Date: Fri, 11 Mar 2016 14:45:01 -0800 Message-ID: <CACdeXi+q4bv5q9oPBJB4=T+Q9kytQMjM2gujriMGL732wQyKyA@mail.gmail.com> To: Dirk Balfanz <balfanz@google.com> Content-Type: multipart/alternative; boundary=001a1143e99c943142052dcdaf77 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/1g-emHZMVzFfrHSE0oGsXKtxudo> Cc: Andrei Popov <Andrei.Popov@microsoft.com>, IETF Tokbind WG <unbearable@ietf.org>, "Hodges, Jeff" <jeff.hodges@paypal.com> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 11 Mar 2016 22:45:26 -0000 --001a1143e99c943142052dcdaf77 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, that all makes sense. On Fri, Mar 11, 2016 at 2:42 PM, Dirk Balfanz <balfanz@google.com> wrote: > Sorry for chiming in late. The intended semantics in the current spec is > ii). > > I believe that covers all the use cases that you're describing: Let's > first consider the case where there is one Relying Party, and one Identit= y > Provider. The RP might go through a bunch of redirects before ultimately > handing things off to the IdP, and the IdP might go through a bunch of > redirects before ultimately handling the RP request. Same on the way back > from the IdP to the RP. > > The one redirect where the referred token binding is necessary is the > redirect that crosses functional boundaries: from the RP to the IdP. If t= he > first endpoint at the IdP isn't the one that is processing the RP request > (because, say, it's the old one and it's now redirecting to the new one), > that endpoint needs to encode the information it learns (i.e., what is th= e > public key that the client is using with the RP) in some way (which can b= e > proprietary to the IdP) and pass that along as the request is handed off. > > On the way back, after the IdP redirects back to the RP, the RP just need= s > to make sure that one of the endpoints in the redirect chain is on the sa= me > eTLD+1 as the endpoint that did the hand-off to the IdP, so it can proces= s > the IdP response there. > > Next, let's consider what happens if there are multiple IdP's involved, > say something like rp.com -> identity-as-a-service.com -> idp.com. In > that case, identity-as-a-service.com acts like an IdP to rp.com, and as > an RP to idp.com, so we play the game described above twice. It wouldn't > make sense here if idp.com somehow knew what public key the client is > using with rp.com - it's useless information. In a scenario like this, > idp.com needs to strongly authenticate the client to > identity-as-a-service.com, not to rp.com. > > Does this make sense? > > Dirk. > > > On Fri, Mar 11, 2016 at 1:57 PM Hodges, Jeff <jeff.hodges@paypal.com> > wrote: > >> On 3/8/16, 3:02 PM, "Andrei Popov" <Andrei.Popov@microsoft.com> wrote: >> >> The current HTTPSTB says: >> " The TokenBindingMessage SHOULD contain a TokenBinding with >> TokenBindingType referred_token_binding. If included, this >> TokenBinding MUST be signed with the Token Binding key used by the >> client for connections between itself and the Token Consumer... >> >> As described above, the TokenBindingMessage MUST additionally contain >> a Provided Token Binding ID..." >> >> Based on the above, currently only option ii) exists. >> >> >> Well, what you are asserting above is only implied by the text and the >> redirect pattern: the text does not say anything explicit about how many >> TokenBindingMessage.TokenBinding's of which type may be present in a giv= en >> TokenBindingMessage. I.e. it does not explicitly say to create a new >> TokenBindingMessage containing only two TokenBindings when the client >> follows a redirect response containing the Include-Referer-Token-Binding= -ID >> response header field (as opposed to adding a TokenBinding to the >> TokenBindingMessage its been using). >> >> >> Dirk, please correct me if I'm wrong, but I believe this means that IDP = C >> would generate a token for IDP B, which would then generate a token for = RP >> A. >> >> >> Not necessarily -- the message exchange pattern is overall governed by >> the federation protocol profile in use, as are the roles of the >> sending/receiving entities, and it's all subject to how a deployment is >> configured in actuality: i.e., Nick's scenario of an IDP changing the >> URL for their security token generation endpoint is plausible. Plus, the >> "return address" for the IDP to redirect to, in order to deliver the >> generated security token, is typcially specified in the fed protocol's >> authn request message (which is generated by A) and typically will point >> back to A (ie not B). [ saml: AssertionConsumerServiceURL, see S 3.4.1 >> in [1]; OIDC: redirect_uri, see S 3.1.2.1 in [2] ] >> >> thus I continue to think that the flexibility in fed protocols (and thei= r >> deployments) requires a bit more flexibility in -tokbind-https's mechani= sm, >> we should think about adding an explicit signal from server to client wr= t >> which TBID is to be referred. >> >> >> [1] https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf >> [2] http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest >> >> >> HTTPSTB does not explicitly discuss multiple-redirect scenarios (perhaps >> we should add some language). >> >> Also, presently, >> -tokbind-protocol-04 does not indicate there's any particular ordering o= f >> TokenBinding structs within TBMsg. >> >> >> From the TBPROTO perspective, there should be at least one binding in th= e >> TB message, no other constraints on TB type or ordering. The idea is for >> the basic protocol to accommodate cases other than HTTPS-style federatio= n. >> >> >> agreed wrt TBPROTO. >> >> >> >> -----Original Message----- >> From: Unbearable [mailto:unbearable-bounces@ietf.org >> <unbearable-bounces@ietf.org>] On Behalf Of Hodges, Jeff >> Sent: Tuesday, March 8, 2016 2:43 PM >> To: Nick Harper <nharper@google.com> >> Cc: IETF Tokbind WG <unbearable@ietf.org> >> Subject: Re: [Unbearable] Referred token binding IDs >> >> On 3/7/16, 4:24 PM nharper@google.com> wrote: >> >> If a client receives an "Include-Referer-Token-Binding-ID" header in >> response to a request that already had a referred TBID in the >> TokenBindingMessage, should it include both of those TBIDs as referred >> TBIDs in the next request? >> >> I.e. >> - client sends request to server A w/ provided TBID A >> - gets back Include-Referer-Token-Binding-ID header on a redirect to B >> - client sends request to B w/ provided TBID B, referred TBID A >> - gets back Include-Referer-Token-Binding-ID header on a redirect to C >> Possible behaviors: >> i) client sends request to C w/ provided TBID C, referred TBID B, >> referred TBID A >> ii) client sends request to C w/ provided TBID C, referred TBID B >> >> iii) client sends request to C w/ provided TBID C, referred TBID A, >> referred TBID B >> >> >> I don't know what a use case for this situation might be, but the spec >> seems unclear to me on what to do. Option (i) seems most likely, >> followed by option (ii). >> >> >> One potential way this might happen is if an identity provider changes >> the URL for their endpoint that generates tokens and sets up a redirect >> from the old URL to the new URL. In that case, option (ii) wouldn't >> work because both B and C are the IdP. >> >> >> In this latter case it seems all C needs in the TBMsg, if it is just >> going to redirect back to A with an "id token w/TBID A", is {provided TB= ID >> C, referred TBID A}, yes? >> >> though, as presently specified in -tokbind-https, there's no way for B t= o >> signal to the client that the client needs to present TBID A to C as >> 'referred' rather than presenting TBID B as referred. Also, presently, >> -tokbind-protocol-04 does not indicate there's any particular ordering o= f >> TokenBinding structs within TBMsg. It's offhand plausible for the client= to >> just keep appending referred TBIDs to the TBMsg, and whichever entity is >> the ultimate "token provider" to incorporate the correct (i.e., >> "first") referred TBID in whatever federation token it is issuing, but >> then there'd be the chance for some sort of "redirect loop" (either >> accidentally or maliciously) and having a size-unbounded TBMsg. >> >> perhaps a way to create the necessary signaling is: instead of just a >> boolean, the Include-Referer-Token-Binding-ID header field could convey = the >> TBID to be referred? i.e., in the above use case, B knows that it isn't = the >> present Token Provider, and can be configured to indicate to the client >> which TBID to include in the TBMsg to C as "referred" (which in this cas= e >> is TBID A)...? >> >> perhaps we need to have folks familiar with actual federated ID >> deployments (such as the tokbind wg chairs :) hold forth on the sorts o= f >> use cases they are aware of that -tokbind-https doesn't (yet) address, b= ut >> perhaps should at least mention and maybe at least provide some guidance >> about? >> >> HTH, >> >> =3DJeffH >> >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i= etf.org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7cAndrei.Popov%40m= icrosoft.com%7c29ccc4b816964749c50708d347a3156f%7c72f988bf86f141af91ab2d7cd= 011db47%7c1&sdata=3DUfJy3GD5cEOSaRSMQzxoHYzR2JPv0RHmtHam4ijqqE4%3d >> >> >> >> > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --001a1143e99c943142052dcdaf77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Yes, that all makes sense.</div><div class=3D"gmail_extra"= ><br><div class=3D"gmail_quote">On Fri, Mar 11, 2016 at 2:42 PM, Dirk Balfa= nz <span dir=3D"ltr"><<a href=3D"mailto:balfanz@google.com" target=3D"_b= lank">balfanz@google.com</a>></span> wrote:<br><blockquote class=3D"gmai= l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= :1ex"><div dir=3D"ltr">Sorry for chiming in late. The intended semantics in= the current spec is ii).<div><br></div><div>I believe that covers all the = use cases that you're describing: Let's first consider the case whe= re there is one Relying Party, and one Identity Provider. The RP might go t= hrough a bunch of redirects before ultimately handing things off to the IdP= , and the IdP might go through a bunch of redirects before ultimately handl= ing the RP request. Same on the way back from the IdP to the RP.</div><div>= <br></div><div>The one redirect where the referred token binding is necessa= ry is the redirect that crosses functional boundaries: from the RP to the I= dP. If the first endpoint at the IdP isn't the one that is processing t= he RP request (because, say, it's the old one and it's now redirect= ing to the new one), that endpoint needs to encode the information it learn= s (i.e., what is the public key that the client is using with the RP) in so= me way (which can be proprietary to the IdP) and pass that along as the req= uest is handed off.</div><div><br></div><div>On the way back, after the IdP= redirects back to the RP, the RP just needs to make sure that one of the e= ndpoints in the redirect chain is on the same eTLD+1 as the endpoint that d= id the hand-off to the IdP, so it can process the IdP response there.</div>= <div><br></div><div>Next, let's consider what happens if there are mult= iple IdP's involved, say something like <a href=3D"http://rp.com" targe= t=3D"_blank">rp.com</a> -> <a href=3D"http://identity-as-a-service.com" = target=3D"_blank">identity-as-a-service.com</a> -> <a href=3D"http://idp= .com" target=3D"_blank">idp.com</a>. In that case, <a href=3D"http://identi= ty-as-a-service.com" target=3D"_blank">identity-as-a-service.com</a> acts l= ike an IdP to <a href=3D"http://rp.com" target=3D"_blank">rp.com</a>, and a= s an RP to <a href=3D"http://idp.com" target=3D"_blank">idp.com</a>, so we = play the game described above twice. It wouldn't make sense here if <a = href=3D"http://idp.com" target=3D"_blank">idp.com</a> somehow knew what pub= lic key the client is using with <a href=3D"http://rp.com" target=3D"_blank= ">rp.com</a> - it's useless information. In a scenario like this, <a hr= ef=3D"http://idp.com" target=3D"_blank">idp.com</a> needs to strongly authe= nticate the client to <a href=3D"http://identity-as-a-service.com" target= =3D"_blank">identity-as-a-service.com</a>, not to <a href=3D"http://rp.com"= target=3D"_blank">rp.com</a>.</div><div><br></div><div>Does this make sens= e?</div><div><br></div><div>Dirk.</div><div><br></div><div><br><div class= =3D"gmail_quote"><div dir=3D"ltr">On Fri, Mar 11, 2016 at 1:57 PM Hodges, J= eff <<a href=3D"mailto:jeff.hodges@paypal.com" target=3D"_blank">jeff.ho= dges@paypal.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><spa= n class=3D""><div style=3D"word-wrap:break-word;color:rgb(0,0,0);font-size:= 14px;font-family:Calibri,sans-serif"> <span> <div> <div>On 3/8/16, 3:02 PM, "Andrei Popov" <<a href=3D"mailto:And= rei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov@microsoft.com</a>&g= t; wrote:</div> </div> <blockquote style=3D"BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0= 0 5"> <div> <div> <div>The current HTTPSTB says: </div> <div>" The TokenBindingMessage SHOULD contain a TokenBinding with</div= > <div>=C2=A0=C2=A0 TokenBindingType referred_token_binding.=C2=A0=C2=A0If in= cluded, this</div> <div>=C2=A0=C2=A0 TokenBinding MUST be signed with the Token Binding key us= ed by the</div> <div>=C2=A0=C2=A0 client for connections between itself and the Token Consu= mer...</div> <div><br> </div> <div>=C2=A0=C2=A0 As described above, the TokenBindingMessage MUST addition= ally contain</div> <div>=C2=A0=C2=A0 a Provided Token Binding ID..."</div> <div><br> </div> <div>Based on the above, currently only option ii) exists. </div> </div> </div> </blockquote> </span> <div><br> </div> </div></span><div style=3D"word-wrap:break-word;color:rgb(0,0,0);font-size:= 14px;font-family:Calibri,sans-serif"><div>Well, what you are asserting abov= e is only implied by the text and the redirect pattern: the text does not s= ay anything explicit about how many TokenBindingMessage.TokenBinding's = of which type may be present in a given TokenBindingMessage. I.e. it does not explicitly say to create a new =C2=A0TokenBindingMessage containing on= ly two TokenBindings when the client follows a redirect response containing= the Include-Referer-Token-Binding-ID response header field (as opposed to = adding a TokenBinding to the TokenBindingMessage its been using).=C2=A0</div></div><span class=3D""><div style=3D"word-wrap= :break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"= > <div><br> </div> <div><br> </div> <span> <blockquote style=3D"BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0= 0 5"> <div> <div> <div>Dirk, please correct me if I'm wrong, but I believe this means tha= t IDP C would generate a token for IDP B, which would then generate a token= for RP A. </div> </div> </div> </blockquote> </span> <div><br> </div> </div></span><div style=3D"word-wrap:break-word;color:rgb(0,0,0);font-size:= 14px;font-family:Calibri,sans-serif"><div>Not necessarily -- the message ex= change pattern is overall governed by the federation protocol profile in us= e, as are the roles of the sending/receiving entities, and it's all sub= ject to how a deployment is configured in actuality: =C2=A0i.e., Nick's= scenario of an=C2=A0<span style=3D"font-family:Calibri;font-size:medium">IDP changi= ng the URL for their security token generation endpoint is plausible. Plus,= the "return address" for the IDP to redirect to, in order to del= iver the generated security token, is typcially specified in the fed protocol's authn request message (which is genera= ted by A) and typically will point back to A (ie not B). =C2=A0[=C2=A0</spa= n>saml: AssertionConsumerServiceURL, see S 3.4.1 in [1]; OIDC: redirect_uri= , see S 3.1.2.1 in [2] ]</div> <div><br> </div> <div>thus I continue to think that the flexibility in fed protocols (and th= eir deployments) requires a bit more flexibility in -tokbind-https's me= chanism, we should think about adding an explicit signal from server to cli= ent wrt which TBID is to be referred.=C2=A0</div> <div><br> </div> <div><br> </div> <div>[1]=C2=A0<a href=3D"https://docs.oasis-open.org/security/saml/v2.0/sam= l-core-2.0-os.pdf" target=3D"_blank">https://docs.oasis-open.org/security/s= aml/v2.0/saml-core-2.0-os.pdf</a></div> <div>[2]=C2=A0<a href=3D"http://openid.net/specs/openid-connect-core-1_0.ht= ml#AuthRequest" target=3D"_blank">http://openid.net/specs/openid-connect-co= re-1_0.html#AuthRequest</a>=C2=A0</div></div><span class=3D""><div style=3D= "word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,s= ans-serif"> <div><br> </div> <div><br> </div> <span> <blockquote style=3D"BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0= 0 5"> <div> <div> <div>HTTPSTB does not explicitly discuss multiple-redirect scenarios (perha= ps we should add some language).</div> <div><br> </div> <blockquote style=3D"BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0= 0 5"> <div>Also, presently,</div> <div>-tokbind-protocol-04 does not indicate there's any particular orde= ring of TokenBinding structs within TBMsg.</div> </blockquote> <div><br> </div> <div>From the TBPROTO perspective, there should be at least one binding in = the TB message, no other constraints on TB type or ordering. The idea is fo= r the basic protocol to accommodate cases other than HTTPS-style federation= .</div> </div> </div> </blockquote> </span> <div><br> </div> </div></span><div style=3D"word-wrap:break-word;color:rgb(0,0,0);font-size:= 14px;font-family:Calibri,sans-serif"><div>agreed wrt TBPROTO.=C2=A0</div></= div><div><div class=3D"h5"><div style=3D"word-wrap:break-word;color:rgb(0,0= ,0);font-size:14px;font-family:Calibri,sans-serif"> <div><br> </div> <div><br> </div> <span> <blockquote style=3D"BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0= 0 5"> <div> <div> <div><br> </div> <div>-----Original Message-----</div> <div>From: Unbearable [<a href=3D"mailto:unbearable-bounces@ietf.org" targe= t=3D"_blank">mailto:unbearable-bounces@ietf.org</a>] On Behalf Of Hodges, J= eff</div> <div>Sent: Tuesday, March 8, 2016 2:43 PM</div> <div>To: Nick Harper <<a href=3D"mailto:nharper@google.com" target=3D"_b= lank">nharper@google.com</a>></div> <div>Cc: IETF Tokbind WG <<a href=3D"mailto:unbearable@ietf.org" target= =3D"_blank">unbearable@ietf.org</a>></div> <div>Subject: Re: [Unbearable] Referred token binding IDs</div> <div><br> </div> <div>On 3/7/16, 4:24 PM <a href=3D"mailto:nharper@google.com" target=3D"_bl= ank">nharper@google.com</a>> wrote:</div> <blockquote style=3D"BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0= 0 5"> <div>If a client receives an "Include-Referer-Token-Binding-ID" h= eader in </div> <div>response to a request that already had a referred TBID in the </div> <div>TokenBindingMessage, should it include both of those TBIDs as referred= </div> <div>TBIDs in the next request?</div> <div><br> </div> <div>I.e.</div> <div>- client sends request to server A w/ provided TBID A</div> <div>- gets back Include-Referer-Token-Binding-ID header on a redirect to B= </div> <div>- client sends request to B w/ provided TBID B, referred TBID A</div> <div>- gets back Include-Referer-Token-Binding-ID header on a redirect to C= </div> <div>Possible behaviors:</div> <div>i) client sends request to C w/ provided TBID C, referred TBID B, </di= v> <div>referred TBID A</div> <div>ii) client sends request to C w/ provided TBID C, referred TBID B</div= > <div><br> </div> <div>iii) client sends request to C w/ provided TBID C, referred TBID A, </= div> <div>referred TBID B</div> <div><br> </div> <div><br> </div> <div>I don't know what a use case for this situation might be, but the = spec </div> <div>seems unclear to me on what to do. Option (i) seems most likely, </div= > <div>followed by option (ii).</div> </blockquote> <div><br> </div> <blockquote style=3D"BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0= 0 5"> <div>One potential way this might happen is if an identity provider changes= </div> <div>the URL for their endpoint that generates tokens and sets up a redirec= t </div> <div>from the old URL to the new URL. In that case, option (ii) wouldn'= t </div> <div>work because both B and C are the IdP.</div> </blockquote> <div><br> </div> <div>In this latter case it seems all C needs in the TBMsg, if it is just g= oing to redirect back to A with an "id token w/TBID A", is {provi= ded TBID C, referred TBID A}, yes?</div> <div><br> </div> <div>though, as presently specified in -tokbind-https, there's no way f= or B to signal to the client that the client needs to present TBID A to C a= s 'referred' rather than presenting TBID B as referred. Also, prese= ntly,</div> <div>-tokbind-protocol-04 does not indicate there's any particular orde= ring of TokenBinding structs within TBMsg. It's offhand plausible for t= he client to just keep appending referred TBIDs to the TBMsg, and whichever= entity is the ultimate "token provider" to incorporate the correct (i.e.,</div> <div>"first") referred TBID in whatever federation token it is is= suing, but then there'd be the chance for some sort of "redirect l= oop" (either accidentally or maliciously) and having a size-unbounded = TBMsg.</div> <div><br> </div> <div>perhaps a way to create the necessary signaling is: instead of just a = boolean, the Include-Referer-Token-Binding-ID header field could convey the= TBID to be referred? i.e., in the above use case, B knows that it isn'= t the present Token Provider, and can be configured to indicate to the client which TBID to include in the TBMsg= to C as "referred" (which in this case is TBID A)...?</div> <div><br> </div> <div>perhaps we need to have folks familiar with actual federated ID deploy= ments (such as the tokbind wg chairs :)=C2=A0=C2=A0hold forth on the sorts = of use cases they are aware of that -tokbind-https doesn't (yet) addres= s, but perhaps should at least mention and maybe at least provide some guidance about?=C2=A0=C2=A0</div> <div><br> </div> <div>HTH, </div> <div><br> </div> <div>=3DJeffH</div> <div><br> </div> <div><br> </div> <div>_______________________________________________</div> <div>Unbearable mailing list</div> <div><a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ie= tf.org</a></div> <div><a href=3D"https://na01.safelinks.protection.outlook.com/?url=3Dhttps%= 3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7= cAndrei.Popov%40microsoft.com%7c29ccc4b816964749c50708d347a3156f%7c72f988bf= 86f141af91ab2d7cd011db47%7c1&sdata=3DUfJy3GD5cEOSaRSMQzxoHYzR2JPv0RHmtH= am4ijqqE4%3d" target=3D"_blank">https://na01.safelinks.protection.outlook.c= om/?url=3Dhttps%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable&= data=3D01%7c01%7cAndrei.Popov%40microsoft.com%7c29ccc4b816964749c50708d347a= 3156f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DUfJy3GD5cEOSaRSMQz= xoHYzR2JPv0RHmtHam4ijqqE4%3d</a></div> <div><br> </div> </div> </div> </blockquote> </span> <div><br> </div> <div><br> </div> </div></div></div></blockquote></div></div></div> <br>_______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org">Unbearable@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> <br></blockquote></div><br></div> --001a1143e99c943142052dcdaf77-- From nobody Fri Mar 11 15:40:35 2016 Return-Path: <jeff.hodges@paypal.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 666A012DDA5 for <unbearable@ietfa.amsl.com>; Fri, 11 Mar 2016 15:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.521 X-Spam-Level: X-Spam-Status: No, score=-22.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=paypal.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 HXhc02_ibxqO for <unbearable@ietfa.amsl.com>; Fri, 11 Mar 2016 15:40:30 -0800 (PST) Received: from den-ipout-03-data1.paypalcorp.com (den-ipout-03-data1.paypalcorp.com [173.224.160.157]) (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 CCB5A12DD9C for <unbearable@ietf.org>; Fri, 11 Mar 2016 15:40:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal.com; i=@paypal.com; q=dns/txt; s=pp-dkim1; t=1457739630; x=1489275630; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=p0l0n0q8NSZ9Nc4kcFcX4v//Im7TnOWHga5AgTNiMNM=; b=v60qThjEOxh13ZOd75wlZqnUeKW6h83f8ycbAKWzKXUbszK8CooN30ER 447QUMop+ckij/+LuEcJAvxD7Uowr69D+7s6KNCj4bDV/WzBabZSPPlVJ BZWb4t7no5N0INUY6bmHvPb5wppH7wAeMb3YNPzMyd6AJ1tqs+4nBSAFj qm8bs0z8e0QdY7dyjBOIgt4KMEhBZtpDQ8fcURUE04Kuydw+jCd+hcFmT x4qJwlK6c2fbC1FLH5ipQ8GO5gaxc5SN4BlkAjXRwVlEJDS5Z/q8RuCYZ M65zotsAMU7Xxa87A2AL/Z256aAFArjEquSM5rCZGaD2/4ywMx4CKzu0H w==; X-IronPort-AV: E=Sophos;i="5.24,321,1455001200"; d="scan'208";a="11686835" Received: from unknown (HELO den-ipcld-02-data1.paypalcorp.com) ([10.184.246.165]) by den-ipout-03-data1.paypalcorp.com with ESMTP; 11 Mar 2016 16:40:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,321,1455001200"; d="scan'208";a="5619633" X-CloudService: Office365 Received: from mail-by2lp0237.outbound.protection.outlook.com (HELO na01-by2-obe.outbound.protection.outlook.com) ([207.46.163.237]) by den-ipcld-02-data1.paypalcorp.com with ESMTP/TLS/AES256-SHA256; 11 Mar 2016 16:40:29 -0700 Received: from SN1PR06MB2094.namprd06.prod.outlook.com (10.169.125.142) by SN1PR06MB2095.namprd06.prod.outlook.com (10.169.125.143) with Microsoft SMTP Server (TLS) id 15.1.434.16; Fri, 11 Mar 2016 23:40:28 +0000 Received: from SN1PR06MB2094.namprd06.prod.outlook.com ([10.169.125.142]) by SN1PR06MB2094.namprd06.prod.outlook.com ([10.169.125.142]) with mapi id 15.01.0434.016; Fri, 11 Mar 2016 23:40:28 +0000 From: "Hodges, Jeff" <jeff.hodges@paypal.com> To: Tokbind WG <unbearable@ietf.org> Thread-Topic: IANA Considerations exporter label reg & sectionalize Thread-Index: AQHRe+9kLrmmCrukc0eU4GgWm8YfRw== Date: Fri, 11 Mar 2016 23:40:28 +0000 Message-ID: <D308976D.94532%jehodges@paypalcorp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=paypal.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [173.224.162.69] x-ms-office365-filtering-correlation-id: 5b1fbf68-cb18-4f54-8407-08d34a068715 x-microsoft-exchange-diagnostics: 1; SN1PR06MB2095; 5:Ltn7pGCznPF7bKInpLjPkxCSv6wz/C4xeH0WYKLjTQAwrZUiJeIoIMZc+oCoZ7OWyT9WE6+P9IAEqDFWzoB2Q6WQ1lky3sIV3DBeHqca0FXFc8oruHNZojxZ8moaDIplm503k9HunFn5jK1KFhe3uw==; 24:LMh2Z2B/Mt6L4XdjHPFCRwU1GHhR7VGSSbJBDRNi/rbujO1bCd6MSVaTn1ZsQOdf7kEPJue8MRpbtd3J3Ta9HDEJDuAY1MMQC/frmVMluOE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR06MB2095; x-microsoft-antispam-prvs: <SN1PR06MB20956AFEBA51E976508302B993B50@SN1PR06MB2095.namprd06.prod.outlook.com> x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR06MB2095; BCL:0; PCL:0; RULEID:; SRVR:SN1PR06MB2095; x-forefront-prvs: 087894CD3C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(50986999)(1220700001)(6116002)(5008740100001)(86362001)(3846002)(586003)(5002640100001)(1096002)(107886002)(82432001)(102836003)(4500500003)(73692002)(110136002)(54356999)(5004730100002)(106116001)(2900100001)(19580395003)(99286002)(36756003)(189998001)(2906002)(97736004)(3280700002)(15975445007)(11100500001)(10770500004)(3660700001)(122556002)(87936001)(10300500001)(229853001)(77072002)(77096005)(81166005)(66066001)(92566002)(10290500002)(450100001)(10130500003)(10400500002)(10630500005)(56826009); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR06MB2095; H:SN1PR06MB2094.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <7CF1EB2EEA9B134CBC800D95ADFC8467@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: paypal.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2016 23:40:28.4090 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fb007914-6020-4374-977e-21bac5f3f4c8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR06MB2095 X-CFilter: Scanned den1 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/ZyEnCd4hoLsR_jRwb0qX_pAdSSo> Subject: [Unbearable] IANA Considerations exporter label reg & sectionalize X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 11 Mar 2016 23:40:32 -0000 IANA Cons exporter label reg & sectionalize https://github.com/TokenBinding/Internet-Drafts/pull/18 =20 =20 TBPROTO does not register its TLS Exporter Label with IANA (req'd per https://tools.ietf.org/html/rfc5705#section-6), this adds that, plus establishes IANA Considerations subsections and references them as appropriate from the TokenBindingMessage section. HTH, =3DJeffH =20 =20 From nobody Fri Mar 11 16:02:48 2016 Return-Path: <agenda@ietf.org> X-Original-To: unbearable@ietf.org Delivered-To: unbearable@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B56B412DD82; Fri, 11 Mar 2016 15:05:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" <agenda@ietf.org> To: <tokbind-chairs@ietf.org>, <leifj@sunet.se> X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230543.15028.74496.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:43 -0800 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/EQp_luiNLGPmuLAO9jUw1jNh3So> X-Mailman-Approved-At: Fri, 11 Mar 2016 16:02:46 -0800 Cc: unbearable@ietf.org, stephen.farrell@cs.tcd.ie Subject: [Unbearable] tokbind - Requested session has been scheduled for IETF 95 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 11 Mar 2016 23:05:44 -0000 Dear Leif Johansson, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tokbind Session 1 (2:00:00) Monday, Morning Session I 1000-1230 Room Name: Buen Ayre B size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Token Binding Area Name: Security Area Session Requester: Leif Johansson Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: httpbis oauth Second Priority: jose Special Requests: Avoid entire SEC area --------------------------------------------------------- From nobody Fri Mar 11 16:12:17 2016 Return-Path: <nharper@google.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 16E1512DDBD for <unbearable@ietfa.amsl.com>; Fri, 11 Mar 2016 16:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 59cRm_BP7d3N for <unbearable@ietfa.amsl.com>; Fri, 11 Mar 2016 16:12:14 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7DAE12D916 for <unbearable@ietf.org>; Fri, 11 Mar 2016 16:12:06 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id c3so153080071vkb.3 for <unbearable@ietf.org>; Fri, 11 Mar 2016 16:12:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=Jkb4E5zXXExLtfMPMJOjkNW1+Dt3CpAAU2Ivjc6D/hY=; b=BD/D7xj8Yd/n/TpkTyVPrQbFFUJqLWUg74ETWXPN2/10NF6PbdP6SnsJIuSkmwe2mj R8XlGMpUe7AxJEtpKbTIL7o15EslW0iUiS/fX6pd3wbJwLeSbJSk7KZX7KSh7lBgbvw6 aKRaqDyaQ+aMQ/9Ju2vi2BfHuZh4OzcVSg7dOW2I6zTjQBe120n2OSuN0NXIKblLsYk6 wGJaGT8KBlb2THXGaholEK2R3b42mQD/yXtgWsbxP164aqa3CTOWxc9cfdL4rgay1w54 4Ei+phCWWLAzDfr0pT3T7JKmdeorRNWmMh0MPvecUoK2RlHd92nK1LJ7/4GkWF35owLw GyDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Jkb4E5zXXExLtfMPMJOjkNW1+Dt3CpAAU2Ivjc6D/hY=; b=PS9j54HSsxh5LdgQakl9XuPUC1/X2RWWu4j07jZ7+Huc9cQme20dyyg/q38Fyl2vH4 81GySU7LurTN34jaJbXXaO0AIUVO6ljbBJIBecOxcf3xl5tJdqeGWmQ7U4WQBb8D5sYY xnGXzgtqrhTn5VVITM69sSTw4b5urADjajYclgKFa+ZovYO9l3thG7ZtrMe0amn4VDSF uzvpyEyGCkXu4o0DfomKzLN0e9hZyLfAKKdg4nPbccRYgzttmHeWj6aCIkiQltJkWjfX F4CX/zdE/nlHYCIy8urapNC9amhbWkn1wn1mgisCn5IW132Rs+qT0Ry4WWqkwNDvB9wm Ducw== X-Gm-Message-State: AD7BkJKIm6+se/3rJGoyq7WdQlaPzHhWze6RVvL2wPJkByHQrSLUWXZs4hr1OZ4Ctc5ttggXpya6IJIRFZs9BRo+ X-Received: by 10.31.162.3 with SMTP id l3mr12825022vke.68.1457741525650; Fri, 11 Mar 2016 16:12:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.76.198 with HTTP; Fri, 11 Mar 2016 16:11:46 -0800 (PST) From: Nick Harper <nharper@google.com> Date: Fri, 11 Mar 2016 16:11:46 -0800 Message-ID: <CACdeXiJWXiJYH2mjHV7hSNXhBxdK4zcMB2eY3uqfjhgqxMYWng@mail.gmail.com> To: IETF Tokbind WG <unbearable@ietf.org> Content-Type: multipart/alternative; boundary=001a114406eacfe7fc052dcee554 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/_z8HW-teAuoR6SeEX65fIUM5mWI> Subject: [Unbearable] Potential privacy bug if Include-Referer-Token-Binding-ID is improperly implemented client-side X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 12 Mar 2016 00:12:16 -0000 --001a114406eacfe7fc052dcee554 Content-Type: text/plain; charset=UTF-8 While implementing referred token bindings, I realized that if the client doesn't handle the "Include-Referer-Token-Binding-ID" header correctly, it could introduce a privacy bug that could result in an attacker MitMing plaintext HTTP to trick the client into revealing to the attacker the TokenBinding IDs for any site that does not use HSTS. This would happen if the client doesn't check that the Include-Referer-Token-Binding-ID header was sent in response to a request that had the Token-Binding header. I don't know how likely others might run into this in implementation. If it's a concern, the following wording could be added to the tbhttps spec: "If the Include-Referer-Token-Binding-ID header is received in response to a request that did not include the Token-Binding header, the client MUST ignore the Include-Referer-Token-Binding-ID header." --001a114406eacfe7fc052dcee554 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">While implementing referred token bindings, I realized tha= t if the client doesn't handle the "Include-Referer-Token-Binding-= ID" header correctly, it could introduce a privacy bug that could resu= lt in an attacker MitMing plaintext HTTP to trick the client into revealing= to the attacker the TokenBinding IDs for any site that does not use HSTS. = This would happen if the client doesn't check that the Include-Referer-= Token-Binding-ID header was sent in response to a request that had the Toke= n-Binding header. I don't know how likely others might run into this in= implementation. If it's a concern, the following wording could be adde= d to the tbhttps spec:<div><br></div><div>"If the Include-Referer-Toke= n-Binding-ID header is received in response to a request that did not inclu= de the Token-Binding header, the client MUST ignore the Include-Referer-Tok= en-Binding-ID header."</div></div> --001a114406eacfe7fc052dcee554-- From nobody Mon Mar 14 16:55:30 2016 Return-Path: <waywardgeek@google.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 5DCAC12D6CA for <unbearable@ietfa.amsl.com>; Mon, 14 Mar 2016 16:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 cjBbuJ7ugYHL for <unbearable@ietfa.amsl.com>; Mon, 14 Mar 2016 16:55:26 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2347512D742 for <unbearable@ietf.org>; Mon, 14 Mar 2016 16:55:26 -0700 (PDT) Received: by mail-ig0-x234.google.com with SMTP id ig19so75196514igb.0 for <unbearable@ietf.org>; Mon, 14 Mar 2016 16:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=7gZ0oIqoY10go90fovxU6rBmmlpJGnDimXRUea4O7AM=; b=Zyeuz69VlmTInoocGOz5BfnrzS0jvu0Z4HfRJoU/dtllW5LYUM64294Q8SsF00WG18 /Ob71ZPrlbF3+zQGliSJy9/5eOYjIHPbdRkeyQmSADogfREWVwdujmROyB6oCvNNvkAZ S3WisY0tpGvVn8wIi3hLmN969mGEBWtaZJf0YJ0DHQ4NKhUV384MhHnDk9yefQbb+KVT KsJz7MtVOQ6cOaDRUWdV8HCQ9D79YosLaJoK1FaXeaUnzPattRPqGpuqwRIz8WuiIBY7 IntjZXtMCRw9MIQGdkyw+EPcds0XfKygAAPTzgh89XmWCUuTbOhXex0TaH6s/qQos9cM Mnfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=7gZ0oIqoY10go90fovxU6rBmmlpJGnDimXRUea4O7AM=; b=HafSuZzJZU4YLY8+o2U7z/8Qzvg7PJyK3l4N8BaItv2AkT6WvOaAgQvMrbFps0bLVm iedaJUbLUlqEQT3yyXoQNQ1C5v296eY1z7B26m+CQwueMgAm6foPmdwRQGAeEKHrF1kY b3vCukwPfz/yTN5DoYp16fGFL8ItihFelwnF+UQAUp6vIIKmJMyGfnFH/vRQ0UZS4Hcw YbX6RDimL/IYWipHGSkHGPlMcvfjOTCmnBVp2xPJGhCUKC+UT/bEnSC5FyLBdHAYaqrT mHOAB5jstqGwmH9ILEtzHuP1FuT5bTCWAdkddaBa0rNve9oVcnKsiYUJ37GtMgFWkAFs InAA== X-Gm-Message-State: AD7BkJIDufakLDhBDt6FmMCKyLpFeprQiewZbup8yI6KASQLaws6eabKBVZ0Eh/FUtRN48WjoJcLVbTXWhqnl2lY MIME-Version: 1.0 X-Received: by 10.50.59.242 with SMTP id c18mr20866230igr.4.1457999725449; Mon, 14 Mar 2016 16:55:25 -0700 (PDT) Received: by 10.107.183.141 with HTTP; Mon, 14 Mar 2016 16:55:25 -0700 (PDT) Date: Mon, 14 Mar 2016 16:55:25 -0700 Message-ID: <CAH9QtQFKGDaLftvBwps_zvDKt0XBjpvKJQbMejbGVQbRYUJ05g@mail.gmail.com> From: Bill Cox <waywardgeek@google.com> To: Tokbind WG <unbearable@ietf.org> Content-Type: multipart/alternative; boundary=047d7bea423eb824ba052e0b0316 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/KohIWeAnQqcHl-ejbQF8wFvqEGQ> Subject: [Unbearable] Exporter label for token bindnig? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 14 Mar 2016 23:55:28 -0000 --047d7bea423eb824ba052e0b0316 Content-Type: text/plain; charset=UTF-8 I see it is EXPORTER-Token-Binding. Did we register that like we are supposed to? All I know is that I didn't :p A colleague would like to use the same label, since the result is a TLS-unique value, which has various applications. Did we register the label? Currently, it is EXPORTER-Token-Binding. If that's a done-deal, I'll just ask him to use it. Thanks, Bill --047d7bea423eb824ba052e0b0316 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I see it is=C2=A0EXPORTER-Token-Binding.=C2=A0 Did we regi= ster that like we are supposed to?=C2=A0 All I know is that I didn't :p= <div><br></div><div>A colleague would like to use the same label, since the= result is a TLS-unique value, which has various applications.=C2=A0 Did we= register the label?=C2=A0 Currently, it is=C2=A0EXPORTER-Token-Binding.=C2= =A0 If that's a done-deal, I'll just ask him to use it.</div><div><= br></div><div>Thanks,</div><div>Bill</div></div> --047d7bea423eb824ba052e0b0316-- From nobody Mon Mar 14 18:28:13 2016 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 4F3D812D84A for <unbearable@ietfa.amsl.com>; Mon, 14 Mar 2016 18:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 DoWOO_JHJcRn for <unbearable@ietfa.amsl.com>; Mon, 14 Mar 2016 18:28:10 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id E24D512D84B for <unbearable@ietf.org>; Mon, 14 Mar 2016 18:28:06 -0700 (PDT) Received: (qmail 32119 invoked by uid 0); 15 Mar 2016 01:28:05 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 15 Mar 2016 01:28:05 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id W1Tz1s0032UhLwi011U2GN; Mon, 14 Mar 2016 19:28:03 -0600 X-Authority-Analysis: v=2.1 cv=Nal1iQz4 c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7OsogOcEt9IA:10 a=NEAV23lmAAAA:8 a=48vgC7mUAAAA:8 a=Lxf8hR8mDUUBIu2daxMA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:Cc:To; bh=zgSG7eH+F3qMp2xWo+2Cuq/X0v6xsN9seYjVFx5PvcY=; b=nZP8GInuR05xpc7gWKavxFxbRZ Qxet6XqDBoIeWXlJhBZwnFkWUPn4EPoE8xQctfyiYuUfPnTlDA/rRcJ8GuMsYAQPVSGRh2KRiZjV2 CLG4caYSH7XcFP6XqVltxlViq; Received: from [73.202.80.238] (port=35572 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1afdmC-0004Ab-S6; Mon, 14 Mar 2016 19:28:00 -0600 To: Bill Cox <waywardgeek@google.com> From: =JeffH <Jeff.Hodges@KingsMountain.com> Message-ID: <56E7651B.4060506@KingsMountain.com> Date: Mon, 14 Mar 2016 18:27:55 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/5E74K8q15-J8Zle6H0lKp1SVac4> Cc: IETF Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Exporter label for token bindnig? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Mar 2016 01:28:12 -0000 > I see it is EXPORTER-Token-Binding. Did we register that like we are > supposed to? All I know is that I didn't :p I noticed a registration hadn't yet been included in -tokbind-protocol aka TBPROTO and so it's in this PR.. https://github.com/TokenBinding/Internet-Drafts/pull/18 > A colleague would like to use the same label, since the result is a > TLS-unique value, which has various applications. Did we register the > label? Currently, it is EXPORTER-Token-Binding. If that's a done-deal, > I'll just ask him to use it. shouldn't an exporter label be used only for the purpose it's allocated for? is that not the admonition in the 2nd para of rfc5705 sec cons (below)? or if it is a tokenbinding rfelated usage, perhaps using the label but being sure to supply a context value (TBPROTO uses a null context value) would be ok? =JefffH https://tools.ietf.org/html/rfc5705#section-5 5. Security Considerations The prime security requirement for exporter outputs is that they be independent. More formally, after a particular TLS session, if an adversary is allowed to choose multiple (label, context value) pairs and is given the output of the PRF for those values, the attacker is still unable to distinguish between the output of the PRF for a (label, context value) pair (different from the ones that it submitted) and a random value of the same length. In particular, there may be settings, such as the one described in Section 4, where the attacker can control the context value; such an attacker MUST NOT be able to predict the output of the exporter. Similarly, an attacker who does not know the master secret should not be able to distinguish valid exporter outputs from random values. The current set of TLS PRFs is believed to meet this objective, provided the master secret is randomly generated. Because an exporter produces the same value if applied twice with the same label to the same master_secret, it is critical that two EKM values generated with the same label not be used for two different purposes -- hence, the requirement for IANA registration. However, because exporters depend on the TLS PRF, it is not a threat to the use of an EKM value generated from one label to reveal an EKM value generated from another label. With certain TLS cipher suites, the TLS master secret is not necessarily unique to a single TLS session. In particular, with RSA key exchange, a malicious party acting as TLS server in one session and as TLS client in another session can cause those two sessions to have the same TLS master secret (though the sessions must be established simultaneously to get adequate control of the Random values). Applications using the EKM need to consider this in how they use the EKM; in some cases, requiring the use of other cipher suites (such as those using a Diffie-Hellman key exchange) may be advisable. Designing a secure mechanism that uses exporters is not necessarily straightforward. This document only provides the exporter mechanism, but the problem of agreeing on the surrounding context and the meaning of the information passed to and from the exporter remains. Any new uses of the exporter mechanism should be subject to careful review. From nobody Sun Mar 20 05:44:25 2016 Return-Path: <leifj@sunet.se> 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 DDCA812D74E for <unbearable@ietfa.amsl.com>; Sun, 20 Mar 2016 05:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sunet.se 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 CrBPmAF6_GjW for <unbearable@ietfa.amsl.com>; Sun, 20 Mar 2016 05:44:20 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 D39DA12D725 for <unbearable@ietf.org>; Sun, 20 Mar 2016 05:44:19 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id u2KCiGeB018998 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <unbearable@ietf.org>; Sun, 20 Mar 2016 13:44:16 +0100 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id u2KCiDfd005523 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for <unbearable@ietf.org>; Sun, 20 Mar 2016 13:44:16 +0100 (CET) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1458477856; bh=jH1CSjvB9r2THqEg/YsXi5pZjpGRdJ/pnbs8sabdsaQ=; h=Subject:To:References:From:Date:In-Reply-To; b=gNmfdqOBu1fwPAh75hXAJIUqirmeXsh8bIEaV59aLYMYfdqfbKu/QNlor9a+0LlTm y3/cQq1DqTUuc3jM4FUfxGJiyU9van/YEOiYaOfaX3j4GM8sBBFvSLhA1Vq8BSAyiG SdtBrWPnfvQMB3Z8Cf0RA50NzTqieX/cr+FiiAxk= X-Footer: c3VuZXQuc2U= Received: from [10.0.0.109] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 9.0.1) with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)) for unbearable@ietf.org; Sun, 20 Mar 2016 13:44:10 +0100 To: unbearable@ietf.org References: <20160219201541.23231.63310.idtracker@ietfa.amsl.com> <56C77DD0.8020303@sunet.se> <BLUPR03MB13962F80468B8643F3E3D2048CA00@BLUPR03MB1396.namprd03.prod.outlook.com> <3134C6C7-8A8F-47A9-B281-9338251ADC33@ve7jtb.com> From: Leif Johansson <leifj@sunet.se> Message-ID: <56EE9B1A.1090703@sunet.se> Date: Sun, 20 Mar 2016 13:44:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <3134C6C7-8A8F-47A9-B281-9338251ADC33@ve7jtb.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09QwcIgRE - 4efcb843a148 - 20160320 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=<leifj@sunet.se>; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/wc_QYLJQhxII1LVDLsR0QGwIKYQ> Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 95 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 20 Mar 2016 12:44:25 -0000 On 2016-02-24 20:11, John Bradley wrote: > I am going. as am I >> On Feb 19, 2016, at 9:58 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote: >> >> So far I'm planning on attending, esp. if TB will be discussed. >> >> -----Original Message----- >> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Leif Johansson >> Sent: Friday, February 19, 2016 12:41 PM >> To: unbearable@ietf.org >> Subject: [Unbearable] Fwd: tokbind - New Meeting Session Request for IETF 95 >> >> >> I'm not 100% we decided if we needed a session in BA but I have put in a slot request just the same. >> >> Am I right in thinking that at least some of the key contributors will be in BA? >> >> Cheers Leif >> >> >> -------- Forwarded Message -------- >> Subject: tokbind - New Meeting Session Request for IETF 95 >> Date: Fri, 19 Feb 2016 12:15:41 -0800 >> From: "IETF Meeting Session Request Tool" >> <session_request_developers@ietf.org> >> To: session-request@ietf.org >> CC: leifj@matematik.su.se, unbearable@ietf.org, tokbind-chairs@ietf.org, stephen.farrell@cs.tcd.ie >> >> >> >> A new meeting session request has just been submitted by Leif Johansson, a Chair of the tokbind working group. >> >> >> --------------------------------------------------------- >> Working Group Name: Token Binding >> Area Name: Security Area >> Session Requester: Leif Johansson >> >> Number of Sessions: 1 >> Length of Session(s): 2 Hours >> Number of Attendees: 75 >> Conflicts to Avoid: >> First Priority: httpbis oauth >> Second Priority: jose >> >> >> >> Special Requests: >> Avoid entire SEC area >> --------------------------------------------------------- >> >> >> >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c15e0609d1978420fc9e108d3396cfb8f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=TvsG9yxXkn%2f%2bTZYXoHl3X%2fFXZmSZ6tk3faBviBnSB%2f8%3d >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > From nobody Sun Mar 20 18:17:34 2016 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 4455712D6F8 for <unbearable@ietfa.amsl.com>; Sun, 20 Mar 2016 18:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 vZseJ57euwkB for <unbearable@ietfa.amsl.com>; Sun, 20 Mar 2016 18:17:29 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id D703312D63E for <unbearable@ietf.org>; Sun, 20 Mar 2016 18:17:28 -0700 (PDT) Received: (qmail 7904 invoked by uid 0); 21 Mar 2016 01:17:27 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 21 Mar 2016 01:17:27 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id YRHM1s00i2UhLwi01RHQo7; Sun, 20 Mar 2016 19:17:25 -0600 X-Authority-Analysis: v=2.1 cv=Nal1iQz4 c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7OsogOcEt9IA:10 a=1XWaLZrsAAAA:8 a=W0ucIhDPAAAA:8 a=8Bq9hsb5AAAA:8 a=C_Wl2PXKAAAA:8 a=gbc7qRT5AAAA:8 a=is3RsFX7AAAA:8 a=mkMtH7XpAAAA:8 a=48vgC7mUAAAA:8 a=m6fL0YDwAAAA:8 a=vsl7EGGSGcCSMFN_k24A:9 a=KLnvdErGYsOnqr6M:21 a=WwQBjGCpUa0OsIrf:21 a=QEXdDO2ut3YA:10 a=wAaNCLKu2AUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:Cc:To; bh=3f8gut8PZgEsx3g1j97arqHR4miJiJ/Ay2CyQuJIUjU=; b=5KEKsvC4ZTdOV5zu27ySyEIcJr 1AUOKuT/6HTnhNGm7CSNPz1GfQo79a/Mrni4cNb6vpclaYV8QfMlThnBr/Z7R/QFPmwZCj8wFN0et Wrb6jdV/AZr2OIr+Q2H8FYSdg; Received: from [73.202.80.238] (port=54308 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1ahoTD-0000rr-Fr; Sun, 20 Mar 2016 19:17:23 -0600 To: Dirk Balfanz <balfanz@google.com> From: =JeffH <Jeff.Hodges@KingsMountain.com> Message-ID: <56EF4B9B.7000609@KingsMountain.com> Date: Sun, 20 Mar 2016 18:17:15 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/Bay_-JiDeAZhCpfvc3zyldiDFYw> Cc: IETF Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Mar 2016 01:17:32 -0000 >> On 3/7/16, 4:24 PM nharper@google.com> wrote: >>> >>> If a client receives an "Include-Referer-Token-Binding-ID" header in >>> response to a request that already had a referred TBID in the >>> TokenBindingMessage, should it include both of those TBIDs as referred >>> TBIDs in the next request? >>> >>> I.e. >>> - client sends request to server A w/ provided TBID A >>> - gets back Include-Referer-Token-Binding-ID header on a redirect to B >>> - client sends request to B w/ provided TBID B, referred TBID A >>> - gets back Include-Referer-Token-Binding-ID header on a redirect to C >>> Possible behaviors: >>> i) client sends request to C w/ provided TBID C, referred TBID B, >>> referred TBID A >>> ii) client sends request to C w/ provided TBID C, referred TBID B >>> >>> iii) client sends request to C w/ provided TBID C, referred TBID A, >>> referred TBID B On Fri, 11 Mar 2016 Dirk replied: > The intended semantics in the current spec is ii). what you mean that is that the TokenBindingMessage (TBMSG) contains only two TokenBindings in this case, and the TBMSG is included in an HTTP request from the client to server only when satisfying a redirect that is crossing "functional boundaries" as noted below, yes? [ "current spec" discussed herein = -tokbind-https-02 aka HTTPSTB, other specs.. -tokbind-negotiation-02 aka TBNEGO -tokbind-protocol-04 aka TBPROTO ] On Fri, 11 Mar 2016 Dirk further replied: > I believe that covers all the use cases that you're describing: Let's first > consider the case where there is one Relying Party, and one Identity > Provider. The RP might go through a bunch of redirects before ultimately > handing things off to the IdP, and the IdP might go through a bunch of > redirects before ultimately handling the RP request. Same on the way back > from the IdP to the RP. understood. > The one redirect where the referred token binding is necessary is the > redirect that crosses functional boundaries: from the RP to the IdP. agreed. > If the > first endpoint at the IdP isn't the one that is processing the RP request > (because, say, it's the old one and it's now redirecting to the new one), > that endpoint needs to encode the information it learns (i.e., what is the > public key that the client is using with the RP) in some way (which can be > proprietary to the IdP) and pass that along as the request is handed off. agreed that the above works in the case where the Token Consumer (RP) that redirects to IdP1 is the intended recipient of the eventual token-bound ID token. However, federation protocols have a notion of a 'return address' that's typically included in the RP's 'authn request'. E.g., in OIDC it is the "redirect_uri" [1], and in SAML the equivalent is the "AssertionConsumerServiceURL" [2]. Upon issuance of the security token, the IDP redirects the UA to the specified 'return address', which does not necessarily point to the RP entity that redirected the UA to the IDP, nor even any of the entities in the RP's "redirect chain". So there needs to be some means for the IDP to receive the _correct_ referred TBID to include in the security token it generates and then returns -- this is not necessarily the RP entity that redirected to the IDP. A few ways to address this in HTTPSTB perhaps are.. We could mandate in HTTPSTB that the receiving RP entity (aka Token Consumer) MUST have the same eTLD+1 as the RP entity that redirected (aka "handed off") to the IDP. (see below for discussion of TB scoping rules) Or, we could attempt to devise a means for the RP entities to signal the correct referred TBID to the IDP via HTTPSTB/TBPROTO. Or, we could punt the problem to deployers and say something like "the referred TBID in the TBMSG MUST map to the entity specified in the authn request's return address -- i.e., the TBID included in the issued security token by the IDP needs to match the client's TLS connection with the entity who will _receive_ the security token, even if the latter entity is not the one to redirect to the IDP" -- it is implementers' and deployers' responsibility to get this right. See [figure 1] at end below. > On the way back, after the IdP redirects back to the RP, the RP just needs > to make sure that one of the endpoints in the redirect chain is on the same > eTLD+1 as the endpoint that did the hand-off to the IdP, so it can process > the IdP response there. hm, perhaps there are some issues here.. * with regards to processing the IDP response ... is the above-stated eTLD+1 requirement because the client aka user agent (UA) will use the same provided TBID with servers whose hostnames map to the same eTLD+1 ? -tokbind-protocol aka TBPROTO says.. ... In order to prevent cooperating servers from linking user identities, different keys SHOULD be used by the client for connections to different servers, according to the token scoping rules of the application protocol. ..so it seems we are assuming (in HTTPSTB) that HTTPS clients map the servers to eTLD+1 when generating their TB key pairs, and afix Token-Binding header fields to their HTTP msgs per said mapping, yes? some thoughts/issues.. - eTLD and eTLD+1 are not mentioned in HTTPSTB - HTTPSTB does not explicitly define which particular "token scoping rules" impls must adhere to. Is the client-side TBID storage-and-mapping model intended to map only to domain names, and in this case be "domain lowered" to eTLD+1 (modulo publicsuffix.org) similarly to how cookies' domain-matching works? [3][4] - what about servers that are identified by IP address? Note that in HSTS we punted on supporting servers identified by IP addresses [5]. Tho, in RFC6265 a server addressed by IP address can set cookies, but only for itself (i.e., the host-only flag is set to true [6]; i.e., cookie "domain lowering" is undefined for IP addresses). Is allowing/disallowing a host-only IP address-based TBID mapping something we should consider generally for TBPROTO, or just specifically consider for HTTSTB? > Next, let's consider what happens if there are multiple IdP's involved, say > something like rp.com -> identity-as-a-service.com -> idp.com. In that > case, identity-as-a-service.com acts like an IdP to rp.com, and as an RP to > idp.com, so we play the game described above twice. It wouldn't make sense > here if idp.com somehow knew what public key the client is using with rp.com > - it's useless information. In a scenario like this, idp.com needs to > strongly authenticate the client to identity-as-a-service.com, not to rp.com Agreed, in this particular, tightly-constrained scenario. HTH, =JeffH [1] https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest [2] https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf [3] https://tools.ietf.org/html/rfc6265#section-5.1.3 [4] http://identitymeme.org/http-cookie-processing-algorithm-etlds/ [5] https://tools.ietf.org/html/rfc6797#appendix-A [6] https://tools.ietf.org/html/rfc6265#section-5.3 - step 6. [figure 1] What: Analysis of redirect hops at RP aka TC and at IDP aka TP Legend: EKM: TLS Exported Keying Material [RFC5705] {EKMn}Ksm: EKM for server "n", signed by private key of TBID "m", where "n" must represent server receiving the ETBMSG, if a conveyed TB's type is provided_token_binding, then m = n, else if TB's type is referred_token_binding, then m != n. E.g., see step 1b in diagram below. ETBMSG: "Token-Binding" HTTP header field conveying an EncodedTokenBindingMessage, in turn conveying TokenBinding (TB)struct(s), e.g.: ETBMSG[[TB]] or ETBMSG[[TB1],[TB2]] ID Token: the "ID Token" in OIDC, it is the semantic equivalent of a SAML "authentication assertion". "ID Token w/TBIDn" denotes a "token bound" ID Token containing TBIDn. Ks & Kp: private (aka secret) key, and public key, respectively, of client-side Token Binding key pair OIDC: Open ID Connect TB: TokenBinding struct containing signed EKM, TBID, and TB type, e.g.: [{EKM1}Ks1,TBID1,provided_token_binding] TBIDn: Token Binding ID for client and server n's token-bound TLS association. TBIDn contains Kpn. Token Consumer, Token Provider, aka: aka: OpenID Client, OpenID Provider, Client, OIDC Relying Party, OIDC Provider, aka: SAML Relying Party SAML Identity Provider User Agent [ servers "1", "2" ] [ servers "3", "4" ] +--------+ +-----+ +-----+ +-----+ +-----+ | Client | | TC1 | | TC2 | | TP3 | | TP4 | +--------+ +-----+ +-----+ +-----+ +-----+ | | | | | | | | | | | 0. Client interacts w/TC1 | | | over HTTPS, establishes Ks1 & Kp1, TBID1 | | | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | | |------------------------------>| | | | | | | | | | | | | | | 1a. redirect to TC2 for TC-specific reasons | | | any security-relevant cookies should contain TBID1 | | +<- - - - - - - - - - - - - - - - | | | | . | | | | | +----------------------------------------->| | | | 1b. establishes Ks2 & Kp2, TBID2 | | | | ETBMSG[[{EKM2}Ks2,TBID2,provided_token_binding]] | | | | | | | | | | | | | | | | | | 2a. OIDC ID Token request, | | | | | aka "Authentication Request" w/ redirect_uri=TC1; <-- note well | conveyed w/ HTTP response header field of: | Include-Referer-Token-Binding-ID:true | | | any security-relevant cookies should contain TBID2 | | +<- - - - - - - - - - - - - - - - - - - - -| | | . | (redirect to TP via 301, 302, | | | | . | 303, 307, or 308) | | | | . | | | | | +----------------------------------------------------->| | | 2b. client opens HTTPS w/ TP3, | | | | establishes Ks3, Kp3, TBID3; | | | | sends GET or POST with | | | | ID Token request w/ redirect_uri=TC1, | | | | ETBMSG[[{EKM3}Ks3,TBID3,provided_token_binding], | | [{EKM3}Ks2,TBID2,referred_token_binding]] <-- but ID Tok request | | | <-- is for TC1 | | | | | | | | | | | | | | 3a. redirect to TP4 for TP-specific reasons | | | any security-relevant cookies should contain TBID3 | | +<- - - - - - - - - - - - - - - - - - - - - - - - - - -| | . | | | | | +--------------------------------------------------------------->| | 3b. client opens HTTPS w/ TP4, | | | | establishes Ks4 & Kp4, TBID4 | | | | ETBMSG[[{EKM4}Ks4,TBID4,provided_token_binding]] | | | *** as well as the ID Token request w/ redirect_uri=TC1; | *** also, somehow conveys TBID2 to TP4 ? | | | | | | | | | | | | | | | | 4. user authentication (if applicable, | | | methods vary, particulars are out of scope) | | |<============================================================>| | (TP generates ID Token for TC1 containing TBID1 - TP4 has only TBID2 | also set cookie(s) containing TBID4 and/or TBID3 | details vary) | | | | | | | | | | | | | | | | | | | | 5a. ID Token issued for TC1, containing TBID1, <-- how do this if | conveyed via OIDC "Authentication Response" <-- don't have TBID1? +<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| . | (redirect to TC1) | | | | . | | | | | +-------------------------------->| | | | | 5b. HTTPS GET or POST with | | | | | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | | | conveying Authn Reponse containing ID Token w/TBID1, | | issued for TC1 | | | | | | | | | | | | | | | | | | | | | | 6. user is signed-on, any security-relevant cookie(s) | | that are set SHOULD contain TBID1 | | | |<------------------------------| | | | | | | | | | | | | | end From nobody Sun Mar 20 21:33:04 2016 Return-Path: <balfanz@google.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 9E11B12D580 for <unbearable@ietfa.amsl.com>; Sun, 20 Mar 2016 21:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 xktICAuvYLBA for <unbearable@ietfa.amsl.com>; Sun, 20 Mar 2016 21:33:01 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B563E12D553 for <unbearable@ietf.org>; Sun, 20 Mar 2016 21:33:00 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id l68so107062074wml.1 for <unbearable@ietf.org>; Sun, 20 Mar 2016 21:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=GeDYMXvuCon+pqMmc11IyNFHO0J50GCVUX1YhoLqItM=; b=XPbiuRkTUsn3mcHk1bJVK+AgV3BMQbxZFkxEwHrVGA+O4dGey1/tTsR0W81XYhA3Kb cbx/nGaNkvlNq6K493rLClI4Oq+rzQTXRAvY2G9JmgSLybTvTZsqLAmHXjgNxvi249FU DVNupAm7lqBQJnL0OqtmxBxIIeEfWY1ZdOgD2Z5hT3lDfzJLfukeSQox2kst96iM52Il V6Xm1RdkDou+1+F8daYwFVb3cMQQtxr87aAFDZEswn+8oniY+1CmyLctay3xiREtUfdB GSciVj8XO/DoyMZoSMo6o//1XSmN+bXj9CsFmAZmJVag+uVp4kQ/E33vszKK9bBrOOO7 Xajw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=GeDYMXvuCon+pqMmc11IyNFHO0J50GCVUX1YhoLqItM=; b=Gu2Dp4MOvwb78Gk+oZFOPG5LXXP9bNWv5PcAHu1+TaQDWeQqUJvI5ZZEIe+I11mGd+ C2h4qtJYzps8OSIjGCBTEgf7ml4/0i/aS6ZPVpUCpyaJh30PQKpnjfSzkGFZaY7JBkn2 Qdl7DaJJPJFx+Pac54X96NeAuDmR0TT+L+HLwbpCDc1EhINJ8xNMiw49q8fAIy/IX0YE eZHjnXxT9rwaP8zeTYrZQTp1LkJpgw4fWM+YIXT4MCVaBpmeINxQF2nHzC5DuA1f3s1m y2GXjqTXWR6cuLFLX3mZ0ol9fKeVq84rmwAImp0rFf2F80w7x/6R9BD2yg0a/VlxWysN Tf0A== X-Gm-Message-State: AD7BkJLka8q8LXqEhtYolH7MNFOewTzytoUTaRNmnCBRpltJA3voVzTGTpJ2yWyiR3RUjrLuv/GrW3jYDVH4sQQn X-Received: by 10.28.22.213 with SMTP id 204mr12054384wmw.12.1458534779055; Sun, 20 Mar 2016 21:32:59 -0700 (PDT) MIME-Version: 1.0 References: <56DC5FDF.9070805@KingsMountain.com> In-Reply-To: <56DC5FDF.9070805@KingsMountain.com> From: Dirk Balfanz <balfanz@google.com> Date: Mon, 21 Mar 2016 04:32:48 +0000 Message-ID: <CADHfa2A97Q+FAJF4d=Vig9E5C0vQ2rn8LVLCT3zqDUjUD_gVcw@mail.gmail.com> To: "=JeffH" <Jeff.Hodges@kingsmountain.com>, IETF Tokbind WG <unbearable@ietf.org> Content-Type: multipart/alternative; boundary=001a114712fc663973052e879747 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/ab6neUKLKSZaKP2ak-XdXINKhTE> Subject: Re: [Unbearable] -tokbind-https-02: "Federated token bindings" figures X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Mar 2016 04:33:03 -0000 --001a114712fc663973052e879747 Content-Type: text/plain; charset=UTF-8 Thanks Jeff! I will incorporate this in the new draft. Dirk. On Sun, Mar 6, 2016 at 8:50 AM =JeffH <Jeff.Hodges@kingsmountain.com> wrote: > minor updates to the "Token Binding over HTTP: Federation Use Cases" > figure. > > HTH, > > =JeffH > > Token Binding over HTTP > https://tools.ietf.org/html/draft-ietf-tokbind-https > > Diagram of section 3. Federation Use Cases > https://tools.ietf.org/html/draft-ietf-tokbind-https-02#section-3 > > What: > Typical HTTP Redirect-based Web Broswer SSO Profile > (no artifact, no callbacks), featuring binding of, > e.g., a TLS Token Binding ID into an OpenID Connect "ID Token". > > Legend: > > EKM: TLS Exported Keying Material [RFC5705] > > {EKMn}Ksm: EKM for server "n", signed by private key of TBID "m", > where "n" must represent server receiving the ETBMSG, > if a conveyed TB's type is provided_token_binding, then > m = n, else if TB's type is referred_token_binding, then > m != n. E.g., see step 1b in diagram below. > > ETBMSG: "Token-Binding" HTTP header field conveying an > EncodedTokenBindingMessage, in turn conveying > TokenBinding (TB)struct(s), e.g.: > ETBMSG[[TB]] or ETBMSG[[TB1],[TB2]] > > ID Token: the "ID Token" in OIDC, it is the semantic equivalent > of a SAML "authentication assertion". "ID Token w/TBIDn" > denotes a "token bound" ID Token containing TBIDn. > > Ks & Kp: private (aka secret) key, and public key, respectively, > of client-side Token Binding key pair > > OIDC: Open ID Connect > > TB: TokenBinding struct containing signed EKM, TBID, and > TB type, e.g.: [{EKM1}Ks1,TBID1,provided_token_binding] > > TBIDn: Token Binding ID for client and server n's token-bound > TLS association. TBIDn contains Kpn. > > > > Client, Token Consumer, Token Provider, > aka: aka: aka: > User Agent OpenID Client, OpenID Provider, > OIDC Relying Party, OIDC Provider, > SAML Relying Party SAML Identity > Provider > [ server "1" ] [ server "2" ] > +--------+ +----+ +-----+ > | Client | | TC | | TP | > +--------+ +----+ +-----+ > | | | > | | | > | | | > | 0. Client interacts w/TC | | > | over HTTPS, establishes Ks1 & Kp1, TBID1 | > | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | > |------------------------------>| | > | | | > | | | > | | | > | 1a. OIDC ID Token request, aka| | > | "Authentication Request", conveyed with | > | HTTP response header field of: | > | Include-Referer-Token-Binding-ID:true | > | any security-relevant cookies | | > | should contain TBID1 | | > +<- - - - - - - - - - - - - - - - | | > . | (redirect to TP via 301, 302, | | > . | 303, 307, or 308) | | > . | | | > +------------------------------------------------------->| > | 1b. opens HTTPS w/ TP, | > | establishes Ks2, Kp2, TBID2; | > | sends GET or POST with | > | ETBMSG[[{EKM2}Ks2,TBID2,provided_token_binding], | > | [{EKM2}Ks1,TBID1,referred_token_binding]] | > | as well as the ID Token request | > | | | > | | | > | | | > | 2. user authentication (if applicable, | > | methods vary, particulars are out of scope) | > |<====================================================>| > | (TP generates ID Token for TC containing TBID1, may | > | also set cookie(s) containing TBID2 and/or TBID1, | > | details vary, particulars are out of scope) | > | | | > | | | > | | | > | 3a. ID Token containing TBID1, issued for TC, | > | conveyed via OIDC "Authentication Response" | > +<- - - - - - - - - - - - - - - - - - - - - - - - - - - -| > . | (redirect to TC) | | > . | | | > . | | | > +-------------------------------->| | > | 3b. HTTPS GET or POST with | > | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | > | conveying Authn Reponse containing | > | ID Token w/TBID1, issued for TC | > | | | > | | | > | | | > | 4. user is signed-on, any security-relevant cookie(s)| > | that are set SHOULD contain TBID1 | > |<------------------------------| | > | | | > | | | > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a114712fc663973052e879747 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+VGhhbmtzIEplZmYhIEkgd2lsbCBpbmNvcnBvcmF0ZSB0aGlzIGluIHRo ZSBuZXcgZHJhZnQuPGRpdj48YnI+PC9kaXY+PGRpdj5EaXJrLjxicj48YnI+PGRpdiBjbGFzcz0i Z21haWxfcXVvdGUiPjxkaXYgZGlyPSJsdHIiPk9uIFN1biwgTWFyIDYsIDIwMTYgYXQgODo1MCBB TSA9SmVmZkggJmx0OzxhIGhyZWY9Im1haWx0bzpKZWZmLkhvZGdlc0BraW5nc21vdW50YWluLmNv bSI+SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb208L2E+Jmd0OyB3cm90ZTo8YnI+PC9kaXY+ PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7 Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+bWlub3IgdXBkYXRl cyB0byB0aGUgJnF1b3Q7VG9rZW4gQmluZGluZyBvdmVyIEhUVFA6IEZlZGVyYXRpb24gVXNlIENh c2VzJnF1b3Q7IGZpZ3VyZS48YnI+DQo8YnI+DQpIVEgsPGJyPg0KPGJyPg0KPUplZmZIPGJyPg0K PGJyPg0KVG9rZW4gQmluZGluZyBvdmVyIEhUVFA8YnI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzIiByZWw9Im5vcmVmZXJyZXIi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10 b2tiaW5kLWh0dHBzPC9hPjxicj4NCjxicj4NCkRpYWdyYW0gb2Ygc2VjdGlvbiAzLiBGZWRlcmF0 aW9uIFVzZSBDYXNlczxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXRva2JpbmQtaHR0cHMtMDIjc2VjdGlvbi0zIiByZWw9Im5vcmVmZXJyZXIiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10b2ti aW5kLWh0dHBzLTAyI3NlY3Rpb24tMzwvYT48YnI+DQo8YnI+DQpXaGF0Ojxicj4NCsKgIMKgVHlw aWNhbCBIVFRQIFJlZGlyZWN0LWJhc2VkIFdlYiBCcm9zd2VyIFNTTyBQcm9maWxlPGJyPg0KwqAg wqAobm8gYXJ0aWZhY3QsIG5vIGNhbGxiYWNrcyksIGZlYXR1cmluZyBiaW5kaW5nIG9mLDxicj4N CsKgIMKgZS5nLiwgYSBUTFMgVG9rZW4gQmluZGluZyBJRCBpbnRvIGFuIE9wZW5JRCBDb25uZWN0 ICZxdW90O0lEIFRva2VuJnF1b3Q7Ljxicj4NCjxicj4NCkxlZ2VuZDo8YnI+DQo8YnI+DQrCoCDC oEVLTTrCoCDCoCDCoCDCoFRMUyBFeHBvcnRlZCBLZXlpbmcgTWF0ZXJpYWwgW1JGQzU3MDVdPGJy Pg0KPGJyPg0KwqAgwqB7RUtNbn1Lc206IEVLTSBmb3Igc2VydmVyICZxdW90O24mcXVvdDssIHNp Z25lZCBieSBwcml2YXRlIGtleSBvZiBUQklEICZxdW90O20mcXVvdDssPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgd2hlcmUgJnF1b3Q7biZxdW90OyBtdXN0IHJlcHJlc2VudCBzZXJ2ZXIgcmVj ZWl2aW5nIHRoZSBFVEJNU0csPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgaWYgYSBjb252ZXll ZCBUQiYjMzk7cyB0eXBlIGlzIHByb3ZpZGVkX3Rva2VuX2JpbmRpbmcsIHRoZW48YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCBtID0gbiwgZWxzZSBpZiBUQiYjMzk7cyB0eXBlIGlzIHJlZmVycmVk X3Rva2VuX2JpbmRpbmcsIHRoZW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCBtICE9IG4uIEUu Zy4sIHNlZSBzdGVwIDFiIGluIGRpYWdyYW0gYmVsb3cuPGJyPg0KPGJyPg0KwqAgwqBFVEJNU0c6 wqAgwqAgJnF1b3Q7VG9rZW4tQmluZGluZyZxdW90OyBIVFRQIGhlYWRlciBmaWVsZCBjb252ZXlp bmcgYW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCBFbmNvZGVkVG9rZW5CaW5kaW5nTWVzc2Fn ZSwgaW4gdHVybiBjb252ZXlpbmc8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCBUb2tlbkJpbmRp bmcgKFRCKXN0cnVjdChzKSwgZS5nLjo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCBFVEJNU0db W1RCXV0gb3IgRVRCTVNHW1tUQjFdLFtUQjJdXTxicj4NCjxicj4NCsKgIMKgSUQgVG9rZW46wqAg dGhlICZxdW90O0lEIFRva2VuJnF1b3Q7IGluIE9JREMsIGl0IGlzIHRoZSBzZW1hbnRpYyBlcXVp dmFsZW50PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgb2YgYSBTQU1MICZxdW90O2F1dGhlbnRp Y2F0aW9uIGFzc2VydGlvbiZxdW90Oy4gJnF1b3Q7SUQgVG9rZW4gdy9UQklEbiZxdW90Ozxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIGRlbm90ZXMgYSAmcXVvdDt0b2tlbiBib3VuZCZxdW90OyBJ RCBUb2tlbiBjb250YWluaW5nIFRCSURuLjxicj4NCjxicj4NCsKgIMKgS3MgJmFtcDsgS3A6wqAg wqBwcml2YXRlIChha2Egc2VjcmV0KSBrZXksIGFuZCBwdWJsaWMga2V5LCByZXNwZWN0aXZlbHks PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgb2YgY2xpZW50LXNpZGUgVG9rZW4gQmluZGluZyBr ZXkgcGFpcjxicj4NCjxicj4NCsKgIMKgT0lEQzrCoCDCoCDCoCBPcGVuIElEIENvbm5lY3Q8YnI+ DQo8YnI+DQrCoCDCoFRCOsKgIMKgIMKgIMKgIFRva2VuQmluZGluZyBzdHJ1Y3QgY29udGFpbmlu ZyBzaWduZWQgRUtNLCBUQklELCBhbmQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCBUQiB0eXBl LCBlLmcuOiBbe0VLTTF9S3MxLFRCSUQxLHByb3ZpZGVkX3Rva2VuX2JpbmRpbmddPGJyPg0KPGJy Pg0KwqAgwqBUQklEbjrCoCDCoCDCoFRva2VuIEJpbmRpbmcgSUQgZm9yIGNsaWVudCBhbmQgc2Vy dmVyIG4mIzM5O3MgdG9rZW4tYm91bmQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCBUTFMgYXNz b2NpYXRpb24uIFRCSURuIGNvbnRhaW5zIEtwbi48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQrCoCDC oENsaWVudCzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUb2tlbiBDb25zdW1lcizC oCDCoCDCoCDCoFRva2VuIFByb3ZpZGVyLDxicj4NCsKgIMKgYWthOsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgYWthOsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFrYTo8 YnI+DQrCoCDCoFVzZXIgQWdlbnTCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoE9wZW5JRCBD bGllbnQswqAgwqAgwqAgwqAgT3BlbklEIFByb3ZpZGVyLDxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE9JREMgUmVseWluZyBQYXJ0eSzCoCDCoE9J REMgUHJvdmlkZXIsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgU0FNTCBSZWx5aW5nIFBhcnR5wqAgwqAgU0FNTCBJZGVudGl0eSBQcm92aWRlcjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFsgc2Vy dmVyICZxdW90OzEmcXVvdDsgXcKgIMKgIMKgIMKgIFsgc2VydmVyICZxdW90OzImcXVvdDsgXTxi cj4NCsKgIMKgKy0tLS0tLS0tK8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICst LS0tK8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICstLS0tLSs8YnI+DQrCoCDCoHwgQ2xpZW50IHzC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IFRDIHzCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCB8IFRQwqAgfDxicj4NCsKgIMKgKy0tLS0tLS0tK8KgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgICstLS0tK8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICstLS0tLSs8YnI+ DQrCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgwqB8 wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCDCoHwgMC4gQ2xpZW50IGludGVyYWN0cyB3L1RDwqAg wqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCDC oHwgb3ZlciBIVFRQUywgZXN0YWJsaXNoZXMgS3MxICZhbXA7IEtwMSwgVEJJRDHCoCDCoCDCoCDC oCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoCDCoHwgRVRCTVNHW1t7RUtNMX1LczEsVEJJRDEscHJv dmlkZWRfdG9rZW5fYmluZGluZ11dwqAgwqAgwqB8PGJyPg0KwqAgwqAgwqAgwqB8LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3zCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB8PGJyPg0KwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIMKg IMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCDCoHzCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgwqB8IDFhLiBPSURDIElEIFRva2VuIHJl cXVlc3QsIGFrYXzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAg wqAgwqB8ICZxdW90O0F1dGhlbnRpY2F0aW9uIFJlcXVlc3QmcXVvdDssIGNvbnZleWVkIHdpdGjC oCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgwqB8IEhUVFAgcmVzcG9uc2UgaGVh ZGVyIGZpZWxkIG9mOsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4NCsKg IMKgIMKgIMKgfCBJbmNsdWRlLVJlZmVyZXItVG9rZW4tQmluZGluZy1JRDp0cnVlwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIMKgIMKgIMKgfCBhbnkgc2VjdXJpdHktcmVsZXZhbnQg Y29va2llcyB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIMKgIMKg IMKgfCBzaG91bGQgY29udGFpbiBUQklEMcKgIMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqArJmx0Oy0gLSAtIC0gLSAtIC0gLSAtIC0g LSAtIC0gLSAtIC0gfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDC oCDCoC4gfCAocmVkaXJlY3QgdG8gVFAgdmlhIDMwMSwgMzAyLCB8wqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIMKgIMKgLiB8wqAgMzAzLCAzMDcsIG9yIDMwOCnCoCDC oCDCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCsKg IMKgIMKgLiB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8 wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIMKgIMKgKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fDxicj4N CsKgIMKgIMKgIMKgfCAxYi4gb3BlbnMgSFRUUFMgdy8gVFAswqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgwqAgwqB8IGVzdGFibGlzaGVz IEtzMiwgS3AyLCBUQklEMjvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8 YnI+DQrCoCDCoCDCoCDCoHwgc2VuZHMgR0VUIG9yIFBPU1Qgd2l0aMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIMKgIMKgfCBFVEJNU0db W3tFS00yfUtzMixUQklEMixwcm92aWRlZF90b2tlbl9iaW5kaW5nXSzCoCDCoCDCoHw8YnI+DQrC oCDCoCDCoCDCoHzCoCDCoCDCoCDCoFt7RUtNMn1LczEsVEJJRDEscmVmZXJyZWRfdG9rZW5fYmlu ZGluZ11dwqAgwqAgwqAgfDxicj4NCsKgIMKgIMKgIMKgfCBhcyB3ZWxsIGFzIHRoZSBJRCBUb2tl biByZXF1ZXN0wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIMKgIMKg IMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCDCoHzCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fDxicj4NCsKgIMKgIMKgIMKgfCAyLiB1c2VyIGF1dGhlbnRpY2F0aW9uIChpZiBhcHBsaWNhYmxl LMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIMKgIMKgfMKgIMKgIG1ldGhvZHMg dmFyeSwgcGFydGljdWxhcnMgYXJlIG91dCBvZiBzY29wZSnCoCDCoCDCoCDCoHw8YnI+DQrCoCDC oCDCoCDCoHwmbHQ7PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PSZndDt8PGJyPg0KwqAgwqAgwqAgwqB8IChUUCBnZW5lcmF0ZXMgSUQgVG9rZW4gZm9y IFRDIGNvbnRhaW5pbmcgVEJJRDEsIG1hecKgIHw8YnI+DQrCoCDCoCDCoCDCoHzCoCBhbHNvIHNl dCBjb29raWUocykgY29udGFpbmluZyBUQklEMiBhbmQvb3IgVEJJRDEswqAgwqB8PGJyPg0KwqAg wqAgwqAgwqB8wqAgZGV0YWlscyB2YXJ5LCBwYXJ0aWN1bGFycyBhcmUgb3V0IG9mIHNjb3BlKcKg IMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8 YnI+DQrCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAg wqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIMKgIMKgIMKgfCAzYS4gSUQgVG9r ZW4gY29udGFpbmluZyBUQklEMSwgaXNzdWVkIGZvciBUQyzCoCDCoCDCoCDCoCB8PGJyPg0KwqAg wqAgwqAgwqB8wqAgwqAgY29udmV5ZWQgdmlhIE9JREMgJnF1b3Q7QXV0aGVudGljYXRpb24gUmVz cG9uc2UmcXVvdDvCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoCsmbHQ7LSAtIC0gLSAtIC0gLSAt IC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLXw8YnI+DQrCoCDCoCDCoC4g fMKgIMKgKHJlZGlyZWN0IHRvIFRDKcKgIMKgIMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAuIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB8PGJyPg0KwqAgwqAgwqAuIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAg wqArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCDCoHwgM2IuIEhUVFBTIEdFVCBvciBQT1NU IHdpdGjCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDC oCDCoCDCoHwgRVRCTVNHW1t7RUtNMX1LczEsVEJJRDEscHJvdmlkZWRfdG9rZW5fYmluZGluZ11d wqAgwqAgwqB8PGJyPg0KwqAgwqAgwqAgwqB8IGNvbnZleWluZyBBdXRobiBSZXBvbnNlIGNvbnRh aW5pbmfCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoCDCoHwgSUQg VG9rZW4gdy9UQklEMSwgaXNzdWVkIGZvciBUQ8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHw8YnI+DQrCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAg wqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8 wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIMKgIMKgIMKgfMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCDCoHwgNC4gdXNlciBpcyBzaWduZWQt b24sIGFueSBzZWN1cml0eS1yZWxldmFudCBjb29raWUocyl8PGJyPg0KwqAgwqAgwqAgwqB8IHRo YXQgYXJlIHNldCBTSE9VTEQgY29udGFpbiBUQklEMcKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHw8YnI+DQrCoCDCoCDCoCDCoHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t fMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCDCoHzCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfDxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlVuYmVhcmFibGVA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby91bmJlYXJhYmxlIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGU8L2E+PGJyPg0KPC9i bG9ja3F1b3RlPjwvZGl2PjwvZGl2PjwvZGl2Pg0K --001a114712fc663973052e879747-- From nobody Sun Mar 20 21:58:57 2016 Return-Path: <balfanz@google.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 EED8612D545 for <unbearable@ietfa.amsl.com>; Sun, 20 Mar 2016 21:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 wWr5LXYdn5du for <unbearable@ietfa.amsl.com>; Sun, 20 Mar 2016 21:58:54 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C510312D50F for <unbearable@ietf.org>; Sun, 20 Mar 2016 21:58:53 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id l68so107440322wml.1 for <unbearable@ietf.org>; Sun, 20 Mar 2016 21:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=hkKkCDR58pTd+4qtUCuG++tyWw49pFZOe5x1PEldUr0=; b=m5QKa5UgWBzxf8n9+1bulJyx4XuDaRX1SdSJHRL7DTxLSUng849BNMLVirfQd60iFy BgoK1BlHTKqyRrqZw9vYiVqFGx046bWeXnI3PI8gZwYMzB3lLDIrJbiUYK5lTSsnlNCC m8NVY3R78Vkp9eDoANhR/P3q5A40vjQ2vaW/kqWeSpwYO/pS8aJQMO2syeGI6a980WoO SH11L9328aCeeljogdtPjgT3dGCwak2cXnTncdVkjWxMdzUBkPXSvIzZrXfpTgbv9d9R /fRAycb6T9FfheVn0rRlUa80OWA9UW64UB6YKumihytNX8e/N+fYD5mf1PrXDnl6CwO5 1AUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=hkKkCDR58pTd+4qtUCuG++tyWw49pFZOe5x1PEldUr0=; b=MCkonsP8f/2YQBPJvH8EfTGeqOke8cH1RFmhRbIDwbPbN2fVG9MGJRKvdYK0lDOA13 4i36UvUlcCDZ4Udjg7IKhF7/hEO84pibwq2KqqTMnjU5az65vIhI7199TnoaIAx4AXW3 u08LcIQoitC9ySrJ6dx+9PAcEl9QFVPtyGu8R35IPem9gyta7uCYpTdRxSCfyGGMf855 G0kOlg3OtvecaZe/964Ih0B1McFhUdehjSG5vxOwQfh0pLUahDCcGATu1MYIrRo5DlK6 LPYI7o1jYbncnR74u5UEa4YeQvvH7H4TfTnKC0groxJAMIG1rEFE3UTzadidJQ9qSUsI xQ2w== X-Gm-Message-State: AD7BkJImw65eFAHX1hIVZZZOlNWAQye9oXzf/8VRCAO1CRE2XGg5MQxYZ8ELVZ0kNORxmVStSyCw/GpIpgFPucXT X-Received: by 10.28.22.213 with SMTP id 204mr12141466wmw.12.1458536332296; Sun, 20 Mar 2016 21:58:52 -0700 (PDT) MIME-Version: 1.0 References: <CACdeXiJWXiJYH2mjHV7hSNXhBxdK4zcMB2eY3uqfjhgqxMYWng@mail.gmail.com> In-Reply-To: <CACdeXiJWXiJYH2mjHV7hSNXhBxdK4zcMB2eY3uqfjhgqxMYWng@mail.gmail.com> From: Dirk Balfanz <balfanz@google.com> Date: Mon, 21 Mar 2016 04:58:42 +0000 Message-ID: <CADHfa2AHhxoosobOThDj+KOwuZgrh_CcQsKN6BxA7TRJeipAoQ@mail.gmail.com> To: Nick Harper <nharper@google.com>, IETF Tokbind WG <unbearable@ietf.org> Content-Type: multipart/alternative; boundary=001a114712fcfac3b5052e87f30f Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/6X0UmixPvOKp9kApWcQtTL3gSFI> Subject: Re: [Unbearable] Potential privacy bug if Include-Referer-Token-Binding-ID is improperly implemented client-side X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Mar 2016 04:58:56 -0000 --001a114712fcfac3b5052e87f30f Content-Type: text/plain; charset=UTF-8 Hi Nick, can you explain a little more? Let's say a client has a policy to not use Token Binding with server A, but no such restrictions for server B. Let's also say that A redirects to B with the Include-Referer-Token-Binding-ID header. Now, the client would reveal to B, as a referred token binding, the TokenBindingID it would normally use with A, even though there was no Token-Binding header in the initial request to A (and it is not, in fact, using any such TokenBindingID with A because of its policy). Is there something wrong with that? Dirk. On Fri, Mar 11, 2016 at 4:12 PM Nick Harper <nharper@google.com> wrote: > While implementing referred token bindings, I realized that if the client > doesn't handle the "Include-Referer-Token-Binding-ID" header correctly, it > could introduce a privacy bug that could result in an attacker MitMing > plaintext HTTP to trick the client into revealing to the attacker the > TokenBinding IDs for any site that does not use HSTS. This would happen if > the client doesn't check that the Include-Referer-Token-Binding-ID header > was sent in response to a request that had the Token-Binding header. I > don't know how likely others might run into this in implementation. If it's > a concern, the following wording could be added to the tbhttps spec: > > "If the Include-Referer-Token-Binding-ID header is received in response to > a request that did not include the Token-Binding header, the client MUST > ignore the Include-Referer-Token-Binding-ID header." > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a114712fcfac3b5052e87f30f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi Nick,=C2=A0<div><br></div><div>can you explain a little= more? Let's say a client has a policy to not use Token Binding with se= rver A, but no such restrictions for server B. Let's also say that A re= directs to B with the=C2=A0<span style=3D"line-height:1.5">Include-Referer-= Token-</span><span style=3D"line-height:1.5">Binding-ID header. Now, the cl= ient would reveal to B, as a referred token binding, the TokenBindingID it = would normally use with A, even though there was no Token-Binding header in= the initial request to A (and it is not, in fact, using any such TokenBind= ingID with A because of its policy).</span></div><div><span style=3D"line-h= eight:1.5"><br></span></div><div><span style=3D"line-height:1.5">Is there s= omething wrong with that?</span></div><div><span style=3D"line-height:1.5">= <br></span></div><div><span style=3D"line-height:1.5">Dirk.</span></div><di= v><span style=3D"line-height:1.5"><br></span></div></div><br><div class=3D"= gmail_quote"><div dir=3D"ltr">On Fri, Mar 11, 2016 at 4:12 PM Nick Harper &= lt;<a href=3D"mailto:nharper@google.com">nharper@google.com</a>> wrote:<= br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde= r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">While implementing= referred token bindings, I realized that if the client doesn't handle = the "Include-Referer-Token-Binding-ID" header correctly, it could= introduce a privacy bug that could result in an attacker MitMing plaintext= HTTP to trick the client into revealing to the attacker the TokenBinding I= Ds for any site that does not use HSTS. This would happen if the client doe= sn't check that the Include-Referer-Token-Binding-ID header was sent in= response to a request that had the Token-Binding header. I don't know = how likely others might run into this in implementation. If it's a conc= ern, the following wording could be added to the tbhttps spec:<div><br></di= v><div>"If the Include-Referer-Token-Binding-ID header is received in = response to a request that did not include the Token-Binding header, the cl= ient MUST ignore the Include-Referer-Token-Binding-ID header."</div></= div> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> </blockquote></div> --001a114712fcfac3b5052e87f30f-- From nobody Sun Mar 20 22:27:27 2016 Return-Path: <nharper@google.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 BDB9512D5DF for <unbearable@ietfa.amsl.com>; Sun, 20 Mar 2016 22:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 tuuf7P-x_OVN for <unbearable@ietfa.amsl.com>; Sun, 20 Mar 2016 22:27:23 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7868A12D545 for <unbearable@ietf.org>; Sun, 20 Mar 2016 22:27:23 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id q138so111147810vkb.3 for <unbearable@ietf.org>; Sun, 20 Mar 2016 22:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9qQJGWvRtSKti8xoyBOSrJPn/BYtWrTK6nkgGwL3ADE=; b=YVYZsHqP2PkQ+0RwDExzm33avar6uBarq1sRCB0oIXBbud7+qdcikrN0mYLM5Bxt14 XvvH7GxGfQrhAwuijrWnm5u4JPY8zKMuNBtAqzJrHHWf8nDX5dFUGnYvhJ1W5McGfReM H5QlmNmO/wSIyQbMWBSJ5jt+XGUrher9tgP0Uk8ifrOr0CfTM5XqdvcVHDAISIq346nQ 0S+ZazWot962mKCdriSEUOO1EW4hRezZxBmSwNbSb7+DTsN27JiC8mG237KQeKBKWxoY n6yx7KbMA0G+Wv41/TsHBScQpeWAMCd0WmjYiMIDzs00xXWCcikXtewtxXpojUJ63Uwq Vu4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9qQJGWvRtSKti8xoyBOSrJPn/BYtWrTK6nkgGwL3ADE=; b=RlpseKnPU51tXT64JkoYYf1RRfAWGREl+2o/2YxVcdY278jD/kFH1vcwd+VhY+/dU+ bcxYL8Y580kSWVRFrm6uNT4LB6v3eSPXUOToF6f1004meU2KrYsOKMu5yGEdPZ56G1ur HbZN/a5g3NH6egiEigWiQivWUTBKBUCz0ILJXEs8Eq8Ja7wvIOIMrHWanIjW4Zo9tZgP cS/TI62MGD9HLoWv7kMTzfNbRYOhjQ/lhA/mSh6MKO24ONMgLCi+fxBx5GJTlt5W+RlF 3B2G0b08ektOVFxGcbE4gXos4W6IAf9/Zqy9p8d7VumC3FqJJF0W+L8TZs1YvTeB1VEb qf9A== X-Gm-Message-State: AD7BkJIVZLq4F1hvEYln7ES8xuT0cbEAHAqiNhLRJcC0XZGfD+dMIWJ6264gNmfqDbK7/LV3g5Oc/ixR7La6M+M/ X-Received: by 10.31.48.132 with SMTP id w126mr31892776vkw.5.1458538042110; Sun, 20 Mar 2016 22:27:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.76.198 with HTTP; Sun, 20 Mar 2016 22:27:02 -0700 (PDT) In-Reply-To: <CADHfa2AHhxoosobOThDj+KOwuZgrh_CcQsKN6BxA7TRJeipAoQ@mail.gmail.com> References: <CACdeXiJWXiJYH2mjHV7hSNXhBxdK4zcMB2eY3uqfjhgqxMYWng@mail.gmail.com> <CADHfa2AHhxoosobOThDj+KOwuZgrh_CcQsKN6BxA7TRJeipAoQ@mail.gmail.com> From: Nick Harper <nharper@google.com> Date: Sun, 20 Mar 2016 22:27:02 -0700 Message-ID: <CACdeXiL0erBXGK_q+ucgfkqCGCTDBVeaqe6pw7WEQskLJG15+Q@mail.gmail.com> To: Dirk Balfanz <balfanz@google.com> Content-Type: multipart/alternative; boundary=001a11430e0ee47963052e885953 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/ZzQ65VM2hYIKmetCBoonhvpvafU> Cc: IETF Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Potential privacy bug if Include-Referer-Token-Binding-ID is improperly implemented client-side X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Mar 2016 05:27:26 -0000 --001a11430e0ee47963052e885953 Content-Type: text/plain; charset=UTF-8 Here's the problem: Suppose the connection to server A is over http. Now a network attacker B injects into some http page (from server C) code that will cause the client to make an http request to server A. The attacker B intercepts the request and responds with a redirect to server B (with the Include-Referer-Token-Binding-ID header). The client dutifully follows that request and forwards the TokenBindingID it has for A to the attacker-controlled B. This is a problem, because A never intended to have the client forward its TokenBindingID from A to B. On Sun, Mar 20, 2016 at 9:58 PM, Dirk Balfanz <balfanz@google.com> wrote: > Hi Nick, > > can you explain a little more? Let's say a client has a policy to not use > Token Binding with server A, but no such restrictions for server B. Let's > also say that A redirects to B with the Include-Referer-Token-Binding-ID > header. Now, the client would reveal to B, as a referred token binding, the > TokenBindingID it would normally use with A, even though there was no > Token-Binding header in the initial request to A (and it is not, in fact, > using any such TokenBindingID with A because of its policy). > > Is there something wrong with that? > > Dirk. > > > On Fri, Mar 11, 2016 at 4:12 PM Nick Harper <nharper@google.com> wrote: > >> While implementing referred token bindings, I realized that if the client >> doesn't handle the "Include-Referer-Token-Binding-ID" header correctly, it >> could introduce a privacy bug that could result in an attacker MitMing >> plaintext HTTP to trick the client into revealing to the attacker the >> TokenBinding IDs for any site that does not use HSTS. This would happen if >> the client doesn't check that the Include-Referer-Token-Binding-ID header >> was sent in response to a request that had the Token-Binding header. I >> don't know how likely others might run into this in implementation. If it's >> a concern, the following wording could be added to the tbhttps spec: >> >> "If the Include-Referer-Token-Binding-ID header is received in response >> to a request that did not include the Token-Binding header, the client MUST >> ignore the Include-Referer-Token-Binding-ID header." >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >> > --001a11430e0ee47963052e885953 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Here's the problem: Suppose the connection to server A= is over http. Now a network attacker B injects into some http page (from s= erver C) code that will cause the client to make an http request to server = A. The attacker B intercepts the request and responds with a redirect to se= rver B (with the Include-Referer-Token-Binding-ID header). The client dutif= ully follows that request and forwards the TokenBindingID it has for A to t= he attacker-controlled B. This is a problem, because A never intended to ha= ve the client forward its TokenBindingID from A to B.</div><div class=3D"gm= ail_extra"><br><div class=3D"gmail_quote">On Sun, Mar 20, 2016 at 9:58 PM, = Dirk Balfanz <span dir=3D"ltr"><<a href=3D"mailto:balfanz@google.com" ta= rget=3D"_blank">balfanz@google.com</a>></span> wrote:<br><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa= dding-left:1ex"><div dir=3D"ltr">Hi Nick,=C2=A0<div><br></div><div>can you = explain a little more? Let's say a client has a policy to not use Token= Binding with server A, but no such restrictions for server B. Let's al= so say that A redirects to B with the=C2=A0<span style=3D"line-height:1.5">= Include-Referer-Token-</span><span style=3D"line-height:1.5">Binding-ID hea= der. Now, the client would reveal to B, as a referred token binding, the To= kenBindingID it would normally use with A, even though there was no Token-B= inding header in the initial request to A (and it is not, in fact, using an= y such TokenBindingID with A because of its policy).</span></div><div><span= style=3D"line-height:1.5"><br></span></div><div><span style=3D"line-height= :1.5">Is there something wrong with that?</span></div><div><span style=3D"l= ine-height:1.5"><br></span></div><div><span style=3D"line-height:1.5">Dirk.= </span></div><div><span style=3D"line-height:1.5"><br></span></div></div><b= r><div class=3D"gmail_quote"><span class=3D""><div dir=3D"ltr">On Fri, Mar = 11, 2016 at 4:12 PM Nick Harper <<a href=3D"mailto:nharper@google.com" t= arget=3D"_blank">nharper@google.com</a>> wrote:<br></div></span><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex"><span class=3D""><div dir=3D"ltr">While implementing= referred token bindings, I realized that if the client doesn't handle = the "Include-Referer-Token-Binding-ID" header correctly, it could= introduce a privacy bug that could result in an attacker MitMing plaintext= HTTP to trick the client into revealing to the attacker the TokenBinding I= Ds for any site that does not use HSTS. This would happen if the client doe= sn't check that the Include-Referer-Token-Binding-ID header was sent in= response to a request that had the Token-Binding header. I don't know = how likely others might run into this in implementation. If it's a conc= ern, the following wording could be added to the tbhttps spec:<div><br></di= v><div>"If the Include-Referer-Token-Binding-ID header is received in = response to a request that did not include the Token-Binding header, the cl= ient MUST ignore the Include-Referer-Token-Binding-ID header."</div></= div></span> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> </blockquote></div> </blockquote></div><br></div> --001a11430e0ee47963052e885953-- From nobody Sun Mar 20 22:34:04 2016 Return-Path: <balfanz@google.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 C157612D67A for <unbearable@ietfa.amsl.com>; Sun, 20 Mar 2016 22:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 1e0Msv0LsVJo for <unbearable@ietfa.amsl.com>; Sun, 20 Mar 2016 22:34:00 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CA112D5DF for <unbearable@ietf.org>; Sun, 20 Mar 2016 22:34:00 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id r129so36095513wmr.1 for <unbearable@ietf.org>; Sun, 20 Mar 2016 22:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=reqcAd0s+3qUfS4BBIDBCg9luKFDPfHJTDBWL8vVQ0o=; b=pD60WrMDbgyioVS/4NA1NZ+LAJxBz8eFJ0D0AVMvwGTRAJM6iyBKXlGTn8fM/3yWiK U66IDmhBrhkg8gi07m7wwmplxU6RdYWBWIuHVGOk19HPHWYJDYPSToHEKw4dWr/3r5H5 4dF2gBxf1sbIGPj2doCbTjNHeNK4P0ji9zGTnvPbsGSPRHirLrptEnRaUOOohqpQyABA 8LeMkN+se+NnbeJL8HR/kx1wy4Yn6Zf/kAlyv8k4CWsxve9AlbBlI5z5ayMZh8GPYO8B 6bA+ksogiGNfgHW4G8eOGbuhdchrm7aThwFTNgYgws31Clbf3AQ39hkKuMm5M712qU2I HfaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=reqcAd0s+3qUfS4BBIDBCg9luKFDPfHJTDBWL8vVQ0o=; b=iETyoEkRtyBr3xzbgqX3+EG1b3EgBmOu7wgS5QlTRa+YHnCYyZDnjQt+El6g7d2R7D nd61vKmtDEkvvpSOQcHQg45xJm6qCmjzOGxSasXwzS8uMzEwrnFufTkNRn4vokSsvjox ezSJiTg2L3ZesT/GmLK5u6gESlH32ASl96+MGmqirl7QxDIfvUsjLFcw5geFcOkSLmQk OLeU4STnyTuWHTc/M+27xQlDoG8ocRmSq1utieA3E5JkkkEKVGgWGrnOqz75bt+WFkKM FQG49yizrW8yDP4npi/Tkx/NGldU5rj6g64IPL3RXPvDh1yW5hCxsR3rDgQ/Ad/ZZIHT dMyQ== X-Gm-Message-State: AD7BkJL9Pi6BtgXtRUC+9+HDjsY9eAe7vQyPK6odEbcSNtCaGF/5Rg7O/+zGt0OidpySH0gGt/odzLWSbA9QLNyI X-Received: by 10.194.203.5 with SMTP id km5mr31293304wjc.172.1458538438512; Sun, 20 Mar 2016 22:33:58 -0700 (PDT) MIME-Version: 1.0 References: <CACdeXiJWXiJYH2mjHV7hSNXhBxdK4zcMB2eY3uqfjhgqxMYWng@mail.gmail.com> <CADHfa2AHhxoosobOThDj+KOwuZgrh_CcQsKN6BxA7TRJeipAoQ@mail.gmail.com> <CACdeXiL0erBXGK_q+ucgfkqCGCTDBVeaqe6pw7WEQskLJG15+Q@mail.gmail.com> In-Reply-To: <CACdeXiL0erBXGK_q+ucgfkqCGCTDBVeaqe6pw7WEQskLJG15+Q@mail.gmail.com> From: Dirk Balfanz <balfanz@google.com> Date: Mon, 21 Mar 2016 05:33:49 +0000 Message-ID: <CADHfa2AToC=Jfmqrpe6JFdMPfDDF3h-hWQVTUTJ1EFKkKWS3Ug@mail.gmail.com> To: Nick Harper <nharper@google.com> Content-Type: multipart/alternative; boundary=047d7bae4532852578052e887178 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/hUtDkCUCPSS1-3g-rDdMgFImQEk> Cc: IETF Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Potential privacy bug if Include-Referer-Token-Binding-ID is improperly implemented client-side X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Mar 2016 05:34:02 -0000 --047d7bae4532852578052e887178 Content-Type: text/plain; charset=UTF-8 I see. The problem is that the *server* may not see its preferences honored if there is a MITM. Let me add this sentence to the spec. Dirk. On Sun, Mar 20, 2016 at 10:27 PM Nick Harper <nharper@google.com> wrote: > Here's the problem: Suppose the connection to server A is over http. Now a > network attacker B injects into some http page (from server C) code that > will cause the client to make an http request to server A. The attacker B > intercepts the request and responds with a redirect to server B (with the > Include-Referer-Token-Binding-ID header). The client dutifully follows that > request and forwards the TokenBindingID it has for A to the > attacker-controlled B. This is a problem, because A never intended to have > the client forward its TokenBindingID from A to B. > > On Sun, Mar 20, 2016 at 9:58 PM, Dirk Balfanz <balfanz@google.com> wrote: > >> Hi Nick, >> >> can you explain a little more? Let's say a client has a policy to not use >> Token Binding with server A, but no such restrictions for server B. Let's >> also say that A redirects to B with the Include-Referer-Token-Binding-ID >> header. Now, the client would reveal to B, as a referred token binding, the >> TokenBindingID it would normally use with A, even though there was no >> Token-Binding header in the initial request to A (and it is not, in fact, >> using any such TokenBindingID with A because of its policy). >> >> Is there something wrong with that? >> >> Dirk. >> >> >> On Fri, Mar 11, 2016 at 4:12 PM Nick Harper <nharper@google.com> wrote: >> >>> While implementing referred token bindings, I realized that if the >>> client doesn't handle the "Include-Referer-Token-Binding-ID" header >>> correctly, it could introduce a privacy bug that could result in an >>> attacker MitMing plaintext HTTP to trick the client into revealing to the >>> attacker the TokenBinding IDs for any site that does not use HSTS. This >>> would happen if the client doesn't check that the >>> Include-Referer-Token-Binding-ID header was sent in response to a request >>> that had the Token-Binding header. I don't know how likely others might run >>> into this in implementation. If it's a concern, the following wording could >>> be added to the tbhttps spec: >>> >>> "If the Include-Referer-Token-Binding-ID header is received in response >>> to a request that did not include the Token-Binding header, the client MUST >>> ignore the Include-Referer-Token-Binding-ID header." >>> _______________________________________________ >>> Unbearable mailing list >>> Unbearable@ietf.org >>> https://www.ietf.org/mailman/listinfo/unbearable >>> >> > --047d7bae4532852578052e887178 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I see. The problem is that the *server* may not see its pr= eferences honored if there is a MITM.<div><br></div><div>Let me add this se= ntence to the spec.</div><div><br></div><div>Dirk.</div><div><br></div></di= v><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sun, Mar 20, 2016 at 1= 0:27 PM Nick Harper <<a href=3D"mailto:nharper@google.com">nharper@googl= e.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt= r">Here's the problem: Suppose the connection to server A is over http.= Now a network attacker B injects into some http page (from server C) code = that will cause the client to make an http request to server A. The attacke= r B intercepts the request and responds with a redirect to server B (with t= he Include-Referer-Token-Binding-ID header). The client dutifully follows t= hat request and forwards the TokenBindingID it has for A to the attacker-co= ntrolled B. This is a problem, because A never intended to have the client = forward its TokenBindingID from A to B.</div><div class=3D"gmail_extra"><br= ><div class=3D"gmail_quote">On Sun, Mar 20, 2016 at 9:58 PM, Dirk Balfanz <= span dir=3D"ltr"><<a href=3D"mailto:balfanz@google.com" target=3D"_blank= ">balfanz@google.com</a>></span> wrote:<br><blockquote class=3D"gmail_qu= ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex= "><div dir=3D"ltr">Hi Nick,=C2=A0<div><br></div><div>can you explain a litt= le more? Let's say a client has a policy to not use Token Binding with = server A, but no such restrictions for server B. Let's also say that A = redirects to B with the=C2=A0<span style=3D"line-height:1.5">Include-Refere= r-Token-</span><span style=3D"line-height:1.5">Binding-ID header. Now, the = client would reveal to B, as a referred token binding, the TokenBindingID i= t would normally use with A, even though there was no Token-Binding header = in the initial request to A (and it is not, in fact, using any such TokenBi= ndingID with A because of its policy).</span></div><div><span style=3D"line= -height:1.5"><br></span></div><div><span style=3D"line-height:1.5">Is there= something wrong with that?</span></div><div><span style=3D"line-height:1.5= "><br></span></div><div><span style=3D"line-height:1.5">Dirk.</span></div><= div><span style=3D"line-height:1.5"><br></span></div></div><br><div class= =3D"gmail_quote"><span><div dir=3D"ltr">On Fri, Mar 11, 2016 at 4:12 PM Nic= k Harper <<a href=3D"mailto:nharper@google.com" target=3D"_blank">nharpe= r@google.com</a>> wrote:<br></div></span><blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">= <span><div dir=3D"ltr">While implementing referred token bindings, I realiz= ed that if the client doesn't handle the "Include-Referer-Token-Bi= nding-ID" header correctly, it could introduce a privacy bug that coul= d result in an attacker MitMing plaintext HTTP to trick the client into rev= ealing to the attacker the TokenBinding IDs for any site that does not use = HSTS. This would happen if the client doesn't check that the Include-Re= ferer-Token-Binding-ID header was sent in response to a request that had th= e Token-Binding header. I don't know how likely others might run into t= his in implementation. If it's a concern, the following wording could b= e added to the tbhttps spec:<div><br></div><div>"If the Include-Refere= r-Token-Binding-ID header is received in response to a request that did not= include the Token-Binding header, the client MUST ignore the Include-Refer= er-Token-Binding-ID header."</div></div></span> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> </blockquote></div> </blockquote></div><br></div> </blockquote></div> --047d7bae4532852578052e887178-- From nobody Sun Mar 20 22:52:37 2016 Return-Path: <balfanz@google.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 3A18712D660 for <unbearable@ietfa.amsl.com>; Sun, 20 Mar 2016 22:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 MZgjeSu90nNb for <unbearable@ietfa.amsl.com>; Sun, 20 Mar 2016 22:52:35 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8368412D603 for <unbearable@ietf.org>; Sun, 20 Mar 2016 22:52:35 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id l68so108319371wml.1 for <unbearable@ietf.org>; Sun, 20 Mar 2016 22:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=kPC3s4kd6vqsHc0DD+eBlh8qjOeviLYfKtZpSsjtgN0=; b=ioJYGFoTSEC8YsqtgJVbRjpqSqMkspYzKFBeNDRGEh4sOV4D848kHo79Cm/fH6/ctM n8iYn9d/8cRo1q9k0wpcWUM2zYtpyiCjygMgOo3cM0RFfjEz+iAyz7WvasC6HRKMGj8I cHzDcmEhRtXiaYrL3/D7R+g6xaU6l5zF17Y0MGaBtVfyEcG5CVU+rpteTI+fd9yZwXXU GipQWeg0xCVwewUyIU3lRIrjm39d/cNpGZcwndVOrJ8P1aLNTOpxdH4sEEGxPNGoAdIx LSFYa5QSC4pMbli0gfLIE2q2HfNpislT9M5ID9SQOhcFssFUCUt8E1iT8Jz3XARuVwyV WUPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kPC3s4kd6vqsHc0DD+eBlh8qjOeviLYfKtZpSsjtgN0=; b=dtyjWGQjIHY6yg0jxjNdG6YvwUXWjH2omTvok6IHyniOXD5w+0ajuO5kNQKEhYeeKz TGinrbZ28J8gYP5KxB2OY+GlPtbDwIRpKW/y0y2O4O8wXrliHZTBSUXjWsEic0J7n+84 45bvKfYjn8XFy3/T9SQLOXi/ZsYEr0ou1fIhsttm3SI8RTGO9VytAVPioaOXKQj6qKKt cCfkhhPrzyZ+QjVenwwLPni2eoO7auun9a1SEYB6HhOBjLwsDhc8qYTi9qqrjSuGbHKn wDQhl3G6OktsjQvEv4x/KZXLHr3VN8AyAHnPcWUgfhpfstYoysr4SIZ+ayv2zLWO8kqa E4Hg== X-Gm-Message-State: AD7BkJLuZsaCJSwu1RFqiOgmkiRB8ihgSb3hgHc6xCXXyYXy5FbI4tLh5/PgNdR2IpADeFKn23VwSi2pyKUftTYc X-Received: by 10.28.22.213 with SMTP id 204mr12351575wmw.12.1458539554020; Sun, 20 Mar 2016 22:52:34 -0700 (PDT) MIME-Version: 1.0 From: Dirk Balfanz <balfanz@google.com> Date: Mon, 21 Mar 2016 05:52:24 +0000 Message-ID: <CADHfa2CVYz40CzWhhproL6p-+Ki1FVAdLaSpfTw5zmFUcz8wug@mail.gmail.com> To: Tokbind WG <unbearable@ietf.org> Content-Type: multipart/alternative; boundary=001a114712fc02669a052e88b431 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/exAc-wQYKCR9qrp_0vaDZJ2QMUI> Subject: [Unbearable] new draft-ietf-tokbind-https draft X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Mar 2016 05:52:37 -0000 --001a114712fc02669a052e88b431 Content-Type: text/plain; charset=UTF-8 Hi there, draft -03 of draft-ietf-tokbind-https is available at https://github.com/TokenBinding/Internet-Drafts. https://datatracker.ietf.org seems to be down right now and I have about 19 more hours before the IETF 95 deadline. I hope that I will be able to upload the draft to the IETF tracking site by then. Changes since the last version: - The header has a Sec- prefix again. - There is a cool diagram showing the redirect flow for the federation case (thanks Jeff!) - There is a new expanded privacy considerations section. - Some language tweaks to make it clearer how/when to use referred token bindings. Dirk. --001a114712fc02669a052e88b431 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi there,=C2=A0</div><div><br></div><div>draft -03 of= =C2=A0draft-ietf-tokbind-https is available at <a href=3D"https://github.co= m/TokenBinding/Internet-Drafts">https://github.com/TokenBinding/Internet-Dr= afts</a>.=C2=A0</div><div><br></div><div><a href=3D"https://datatracker.iet= f.org">https://datatracker.ietf.org</a>=C2=A0seems to be down right now and= I have about 19 more hours before the IETF 95 deadline. I hope that I will= be able to upload the draft to the IETF tracking site by then.</div><div><= br></div><div>Changes since the last version:</div><div><br></div><div>- Th= e header has a Sec- prefix again.</div><div><br></div><div>- There is a coo= l diagram showing the redirect flow for the federation case (thanks Jeff!)<= /div><div><br></div><div>- There is a new expanded privacy considerations s= ection.</div><div><br></div><div>- Some language tweaks to make it clearer = how/when to use referred token bindings.</div><div><br></div><div>Dirk.</di= v><div><br></div></div> --001a114712fc02669a052e88b431-- From nobody Sun Mar 20 23:04:14 2016 Return-Path: <balfanz@google.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 B1A8312D623 for <unbearable@ietfa.amsl.com>; Sun, 20 Mar 2016 23:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 8KeHxK279OHG for <unbearable@ietfa.amsl.com>; Sun, 20 Mar 2016 23:04:10 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2682512D55D for <unbearable@ietf.org>; Sun, 20 Mar 2016 23:04:10 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id r129so36608312wmr.1 for <unbearable@ietf.org>; Sun, 20 Mar 2016 23:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qqBagWx0MnA+Sqe9z2X8jysl54EUx18T1UVMBHwObsY=; b=mjiV4oPSHgaHQVIjs1+Wv+vh+39s1Wg76PS9SyDLF85bpz5T0NIkgs9nQgA1niFgtZ DMSSj80hucJ3ztz+sBrpb6mtdctYQNdWrgX6hyKyVtVwHm+M2r6EhzmD3Wsqij8LMyDy ZCoOP/XslfgO2yAutQevJ52rypnHuu2dQcV7UcBDowZFZocJSsH4ip3L+WZWU7XXrkvO gBYmm73KdkwYmbHqEZDlSlDeK2OeSC92FqF9HcKnYvOFedyUotpmg7oyJ1eL4cmzBJ3j lcXWCNJYnYXFXdUMliq9fBKu6nvc1actMmMdY+K/K/kxclfwgB5Hf7IMloO1HdAeBWuR FJug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qqBagWx0MnA+Sqe9z2X8jysl54EUx18T1UVMBHwObsY=; b=SayWDWyZALVNYFWwKI0xxMVlufqZzbPnLOz5YrBq2SenwYEx5kFsBVRrZ3mOGDL7Fx /4TN8qFZZaT2me7cYw4HcjZJ0c0+h+u1rONpNmN8E+Rs75k46V3f16jsIHVb0iz1K7bX NRvev899YHgUov2Cig8VhOFRJaAyg+LvdELOg/z77nzW/A6TJsR3+oDYSLYhcVBQJi4D LVy7IXAjZRn2ehq//Zd9K5DdmxWV09otDFBEdiTXv+xk3hg9/h2qBaBv7acGHnR/Jkqe TnWaP6PJyxwY3w1gB/GD53t/1DFUQIICW0yZUxBJR0jB1w5Gf3CNP9Is139SCftwOKXL bMNQ== X-Gm-Message-State: AD7BkJK8CpNf7OfHJ7xuhyXLeuhi5on2hSbaFRoIjBAjtIJpwScDLyCrMnSQ+ayBPySxRJ7blbUZv/PmAy4PgYAZ X-Received: by 10.28.7.196 with SMTP id 187mr12397176wmh.12.1458540248518; Sun, 20 Mar 2016 23:04:08 -0700 (PDT) MIME-Version: 1.0 References: <56EF4B9B.7000609@KingsMountain.com> In-Reply-To: <56EF4B9B.7000609@KingsMountain.com> From: Dirk Balfanz <balfanz@google.com> Date: Mon, 21 Mar 2016 06:03:59 +0000 Message-ID: <CADHfa2ACdV_mdm-R-23PajYUzHJ8nG2QN680aXxN2zqKLtB0Vw@mail.gmail.com> To: "=JeffH" <Jeff.Hodges@kingsmountain.com> Content-Type: multipart/alternative; boundary=001a1144213067975a052e88ddd4 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/Ej0QwBvg2vTbFNqA0eadU2lHGJ4> Cc: IETF Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Mar 2016 06:04:13 -0000 --001a1144213067975a052e88ddd4 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 20, 2016 at 6:17 PM =JeffH <Jeff.Hodges@kingsmountain.com> wrote: > >> On 3/7/16, 4:24 PM nharper@google.com> wrote: > >>> > >>> If a client receives an "Include-Referer-Token-Binding-ID" header in > >>> response to a request that already had a referred TBID in the > >>> TokenBindingMessage, should it include both of those TBIDs as referred > >>> TBIDs in the next request? > >>> > >>> I.e. > >>> - client sends request to server A w/ provided TBID A > >>> - gets back Include-Referer-Token-Binding-ID header on a redirect to B > >>> - client sends request to B w/ provided TBID B, referred TBID A > >>> - gets back Include-Referer-Token-Binding-ID header on a redirect to C > >>> Possible behaviors: > >>> i) client sends request to C w/ provided TBID C, referred TBID B, > >>> referred TBID A > >>> ii) client sends request to C w/ provided TBID C, referred TBID B > >>> > >>> iii) client sends request to C w/ provided TBID C, referred TBID A, > >>> referred TBID B > > > On Fri, 11 Mar 2016 Dirk replied: > > The intended semantics in the current spec is ii). > > what you mean that is that the TokenBindingMessage (TBMSG) contains only > two > TokenBindings in this case, and the TBMSG is included in an HTTP request > from the client to server only when satisfying a redirect that is crossing > "functional boundaries" as noted below, yes? > > [ "current spec" discussed herein = -tokbind-https-02 aka HTTPSTB, > other specs.. > -tokbind-negotiation-02 aka TBNEGO > -tokbind-protocol-04 aka TBPROTO ] > > On Fri, 11 Mar 2016 Dirk further replied: > > I believe that covers all the use cases that you're describing: Let's > first > > consider the case where there is one Relying Party, and one Identity > > Provider. The RP might go through a bunch of redirects before ultimately > > handing things off to the IdP, and the IdP might go through a bunch of > > redirects before ultimately handling the RP request. Same on the way back > > from the IdP to the RP. > > understood. > > > The one redirect where the referred token binding is necessary is the > > redirect that crosses functional boundaries: from the RP to the IdP. > > agreed. > > > If the > > first endpoint at the IdP isn't the one that is processing the RP request > > (because, say, it's the old one and it's now redirecting to the new one), > > that endpoint needs to encode the information it learns (i.e., what is > the > > public key that the client is using with the RP) in some way (which can > be > > proprietary to the IdP) and pass that along as the request is handed off. > > agreed that the above works in the case where the Token Consumer (RP) that > redirects to IdP1 is the intended recipient of the eventual token-bound ID > token. > > However, federation protocols have a notion of a 'return address' that's > typically included in the RP's 'authn request'. E.g., in OIDC it is the > "redirect_uri" [1], and in SAML the equivalent is the > "AssertionConsumerServiceURL" [2]. > > Upon issuance of the security token, the IDP redirects the UA to the > specified 'return address', which does not necessarily point to the RP > entity that redirected the UA to the IDP, nor even any of the entities in > the RP's "redirect chain". > > So there needs to be some means for the IDP to receive the _correct_ > referred TBID to include in the security token it generates and then > returns > -- this is not necessarily the RP entity that redirected to the IDP. A few > ways to address this in HTTPSTB perhaps are.. > > We could mandate in HTTPSTB that the receiving RP entity (aka Token > Consumer) MUST have the same eTLD+1 as the RP entity that redirected (aka > "handed off") to the IDP. (see below for discussion of TB scoping rules) > > Or, we could attempt to devise a means for the RP entities to signal the > correct referred TBID to the IDP via HTTPSTB/TBPROTO. > > Or, we could punt the problem to deployers and say something like "the > referred TBID in the TBMSG MUST map to the entity specified in the authn > request's return address -- i.e., the TBID included in the issued security > token by the IDP needs to match the client's TLS connection with the entity > who will _receive_ the security token, even if the latter entity is not the > one to redirect to the IDP" -- it is implementers' and deployers' > responsibility to get this right. > > See [figure 1] at end below. > > > > On the way back, after the IdP redirects back to the RP, the RP just > needs > > to make sure that one of the endpoints in the redirect chain is on the > same > > eTLD+1 as the endpoint that did the hand-off to the IdP, so it can > process > > the IdP response there. > > hm, perhaps there are some issues here.. > > * with regards to processing the IDP response ... is the above-stated > eTLD+1 > requirement because the client aka user agent (UA) will use the same > provided TBID with servers whose hostnames map to the same eTLD+1 ? > -tokbind-protocol aka TBPROTO says.. > > ... In order to prevent cooperating servers from linking user > identities, different keys SHOULD be used by the client for > connections to different servers, according to the token scoping > rules of the application protocol. > > ..so it seems we are assuming (in HTTPSTB) that HTTPS clients map the > servers to eTLD+1 when generating their TB key pairs, and afix > Token-Binding > header fields to their HTTP msgs per said mapping, yes? > > some thoughts/issues.. > > - eTLD and eTLD+1 are not mentioned in HTTPSTB > > - HTTPSTB does not explicitly define which particular "token scoping > rules" impls must adhere to. Is the client-side TBID > storage-and-mapping > model intended to map only to domain names, and in this case be "domain > lowered" to eTLD+1 (modulo publicsuffix.org) similarly to how cookies' > domain-matching works? [3][4] > Just added language to that effect in a new "Privacy Considerations" section in -03. Take a look and see whether you like it / have some ideas to improve on it. > > - what about servers that are identified by IP address? Note that in HSTS > we punted on supporting servers identified by IP addresses [5]. Tho, in > RFC6265 a server addressed by IP address can set cookies, but only for > itself (i.e., the host-only flag is set to true [6]; i.e., cookie > "domain lowering" is undefined for IP addresses). Is > allowing/disallowing a host-only IP address-based TBID mapping > something we should consider generally for TBPROTO, or > just specifically consider for HTTSTB? > I'd say that servers identified by IP addresses will get keys scoped to that exact IP address - just like cookies. I think it belongs in HTTPSTB as a SHOULD for web browsers. Dirk. > > > > Next, let's consider what happens if there are multiple IdP's involved, > say > > something like rp.com -> identity-as-a-service.com -> idp.com. In that > > case, identity-as-a-service.com acts like an IdP to rp.com, and as an > RP to > > idp.com, so we play the game described above twice. It wouldn't make > sense > > here if idp.com somehow knew what public key the client is using with > rp.com > > - it's useless information. In a scenario like this, idp.com needs to > > strongly authenticate the client to identity-as-a-service.com, not to > rp.com > > Agreed, in this particular, tightly-constrained scenario. > > HTH, > > =JeffH > > > [1] https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest > > [2] https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf > > [3] https://tools.ietf.org/html/rfc6265#section-5.1.3 > > [4] http://identitymeme.org/http-cookie-processing-algorithm-etlds/ > > [5] https://tools.ietf.org/html/rfc6797#appendix-A > > [6] https://tools.ietf.org/html/rfc6265#section-5.3 - step 6. > > > > [figure 1] > > What: Analysis of redirect hops at RP aka TC and at IDP aka TP > > Legend: > > EKM: TLS Exported Keying Material [RFC5705] > > {EKMn}Ksm: EKM for server "n", signed by private key of TBID "m", > where "n" must represent server receiving the ETBMSG, > if a conveyed TB's type is provided_token_binding, then > m = n, else if TB's type is referred_token_binding, then > m != n. E.g., see step 1b in diagram below. > > ETBMSG: "Token-Binding" HTTP header field conveying an > EncodedTokenBindingMessage, in turn conveying > TokenBinding (TB)struct(s), e.g.: > ETBMSG[[TB]] or ETBMSG[[TB1],[TB2]] > > ID Token: the "ID Token" in OIDC, it is the semantic equivalent > of a SAML "authentication assertion". "ID Token w/TBIDn" > denotes a "token bound" ID Token containing TBIDn. > > Ks & Kp: private (aka secret) key, and public key, respectively, > of client-side Token Binding key pair > > OIDC: Open ID Connect > > TB: TokenBinding struct containing signed EKM, TBID, and > TB type, e.g.: [{EKM1}Ks1,TBID1,provided_token_binding] > > TBIDn: Token Binding ID for client and server n's token-bound > TLS association. TBIDn contains Kpn. > > > > Token Consumer, Token Provider, > aka: aka: > OpenID Client, OpenID Provider, > Client, OIDC Relying Party, OIDC Provider, > aka: SAML Relying Party SAML Identity > Provider > User Agent [ servers "1", "2" ] [ servers "3", "4" ] > +--------+ +-----+ +-----+ +-----+ +-----+ > | Client | | TC1 | | TC2 | | TP3 | | TP4 | > +--------+ +-----+ +-----+ +-----+ +-----+ > | | | | | > | | | | | > | 0. Client interacts w/TC1 | | > | over HTTPS, establishes Ks1 & Kp1, TBID1 | | > | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | | > |------------------------------>| | | | > | | | | | > | | | | | > | 1a. redirect to TC2 for TC-specific reasons | | > | any security-relevant cookies should contain TBID1 | | > +<- - - - - - - - - - - - - - - - | | | | > . | | | | | > +----------------------------------------->| | | > | 1b. establishes Ks2 & Kp2, TBID2 | | | > | ETBMSG[[{EKM2}Ks2,TBID2,provided_token_binding]] | | > | | | | | > | | | | | > | | | | | > | 2a. OIDC ID Token request, | | | | > | aka "Authentication Request" w/ redirect_uri=TC1; <-- note well > | conveyed w/ HTTP response header field of: > | Include-Referer-Token-Binding-ID:true | | > | any security-relevant cookies should contain TBID2 | | > +<- - - - - - - - - - - - - - - - - - - - -| | | > . | (redirect to TP via 301, 302, | | | | > . | 303, 307, or 308) | | | | > . | | | | | > +----------------------------------------------------->| | > | 2b. client opens HTTPS w/ TP3, | | | > | establishes Ks3, Kp3, TBID3; | | | > | sends GET or POST with | | | > | ID Token request w/ redirect_uri=TC1, | | | > | ETBMSG[[{EKM3}Ks3,TBID3,provided_token_binding], | > | [{EKM3}Ks2,TBID2,referred_token_binding]] <-- but ID Tok > request > | | | <-- is for TC1 > | | | > | | | | | > | | | | | > | 3a. redirect to TP4 for TP-specific reasons | | > | any security-relevant cookies should contain TBID3 | | > +<- - - - - - - - - - - - - - - - - - - - - - - - - - -| | > . | | | | | > +--------------------------------------------------------------->| > | 3b. client opens HTTPS w/ TP4, | | | > | establishes Ks4 & Kp4, TBID4 | | | > | ETBMSG[[{EKM4}Ks4,TBID4,provided_token_binding]] | | > | *** as well as the ID Token request w/ redirect_uri=TC1; > | *** also, somehow conveys TBID2 to TP4 ? > | | | | | > | | | | | > | | | | | > | 4. user authentication (if applicable, | | > | methods vary, particulars are out of scope) | | > |<============================================================>| > | (TP generates ID Token for TC1 containing TBID1 - TP4 has only TBID2 > | also set cookie(s) containing TBID4 and/or TBID3 > | details vary) | | | | > | | | | | > | | | | | > | | | | | > | 5a. ID Token issued for TC1, containing TBID1, <-- how do this if > | conveyed via OIDC "Authentication Response" <-- don't have TBID1? > +<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| > . | (redirect to TC1) | | | | > . | | | | | > +-------------------------------->| | | | > | 5b. HTTPS GET or POST with | | | | > | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | | > | conveying Authn Reponse containing ID Token w/TBID1, | > | issued for TC1 | > | | | | | > | | | | | > | | | | | > | | | | | > | 6. user is signed-on, any security-relevant cookie(s) | > | that are set SHOULD contain TBID1 | | | > |<------------------------------| | | | > | | | | | > | | | | | > > > end > > > --001a1144213067975a052e88ddd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+PGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdiBkaXI9 Imx0ciI+T24gU3VuLCBNYXIgMjAsIDIwMTYgYXQgNjoxNyBQTSA9SmVmZkggJmx0OzxhIGhyZWY9 Im1haWx0bzpKZWZmLkhvZGdlc0BraW5nc21vdW50YWluLmNvbSI+SmVmZi5Ib2RnZXNAa2luZ3Nt b3VudGFpbi5jb208L2E+Jmd0OyB3cm90ZTo8YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mg c29saWQ7cGFkZGluZy1sZWZ0OjFleCI+Jmd0OyZndDsgT24gMy83LzE2LCA0OjI0IFBNIDxhIGhy ZWY9Im1haWx0bzpuaGFycGVyQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5uaGFycGVyQGdv b2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsgSWYgYSBjbGllbnQgcmVjZWl2ZXMgYW4gJnF1b3Q7SW5jbHVkZS1SZWZlcmVyLVRva2VuLUJp bmRpbmctSUQmcXVvdDsgaGVhZGVyIGluPGJyPg0KJmd0OyZndDsmZ3Q7IHJlc3BvbnNlIHRvIGEg cmVxdWVzdCB0aGF0IGFscmVhZHkgaGFkIGEgcmVmZXJyZWQgVEJJRCBpbiB0aGU8YnI+DQomZ3Q7 Jmd0OyZndDsgVG9rZW5CaW5kaW5nTWVzc2FnZSwgc2hvdWxkIGl0IGluY2x1ZGUgYm90aCBvZiB0 aG9zZSBUQklEcyBhcyByZWZlcnJlZDxicj4NCiZndDsmZ3Q7Jmd0OyBUQklEcyBpbiB0aGUgbmV4 dCByZXF1ZXN0Pzxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJLmUuPGJyPg0K Jmd0OyZndDsmZ3Q7IC0gY2xpZW50IHNlbmRzIHJlcXVlc3QgdG8gc2VydmVyIEEgdy8gcHJvdmlk ZWQgVEJJRCBBPGJyPg0KJmd0OyZndDsmZ3Q7IC0gZ2V0cyBiYWNrIEluY2x1ZGUtUmVmZXJlci1U b2tlbi1CaW5kaW5nLUlEIGhlYWRlciBvbiBhIHJlZGlyZWN0IHRvIEI8YnI+DQomZ3Q7Jmd0OyZn dDsgLSBjbGllbnQgc2VuZHMgcmVxdWVzdCB0byBCIHcvIHByb3ZpZGVkIFRCSUQgQiwgcmVmZXJy ZWQgVEJJRCBBPGJyPg0KJmd0OyZndDsmZ3Q7IC0gZ2V0cyBiYWNrIEluY2x1ZGUtUmVmZXJlci1U b2tlbi1CaW5kaW5nLUlEIGhlYWRlciBvbiBhIHJlZGlyZWN0IHRvIEM8YnI+DQomZ3Q7Jmd0OyZn dDsgUG9zc2libGUgYmVoYXZpb3JzOjxicj4NCiZndDsmZ3Q7Jmd0OyBpKSBjbGllbnQgc2VuZHMg cmVxdWVzdCB0byBDIHcvIHByb3ZpZGVkIFRCSUQgQywgcmVmZXJyZWQgVEJJRCBCLDxicj4NCiZn dDsmZ3Q7Jmd0OyByZWZlcnJlZCBUQklEIEE8YnI+DQomZ3Q7Jmd0OyZndDsgaWkpIGNsaWVudCBz ZW5kcyByZXF1ZXN0IHRvIEMgdy8gcHJvdmlkZWQgVEJJRCBDLCByZWZlcnJlZCBUQklEIEI8YnI+ DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgaWlpKSBjbGllbnQgc2VuZHMgcmVxdWVz dCB0byBDIHcvIHByb3ZpZGVkIFRCSUQgQywgcmVmZXJyZWQgVEJJRCBBLDxicj4NCiZndDsmZ3Q7 Jmd0OyByZWZlcnJlZCBUQklEIEI8YnI+DQo8YnI+DQo8YnI+DQpPbiBGcmksIDExIE1hciAyMDE2 IERpcmsgcmVwbGllZDo8YnI+DQomZ3Q7IFRoZSBpbnRlbmRlZCBzZW1hbnRpY3MgaW4gdGhlIGN1 cnJlbnQgc3BlYyBpc8KgIGlpKS48YnI+DQo8YnI+DQp3aGF0IHlvdSBtZWFuIHRoYXQgaXMgdGhh dCB0aGUgVG9rZW5CaW5kaW5nTWVzc2FnZSAoVEJNU0cpIGNvbnRhaW5zIG9ubHkgdHdvPGJyPg0K VG9rZW5CaW5kaW5ncyBpbiB0aGlzIGNhc2UsIGFuZCB0aGUgVEJNU0cgaXMgaW5jbHVkZWQgaW4g YW4gSFRUUCByZXF1ZXN0PGJyPg0KZnJvbSB0aGUgY2xpZW50IHRvIHNlcnZlciBvbmx5IHdoZW4g c2F0aXNmeWluZyBhIHJlZGlyZWN0IHRoYXQgaXMgY3Jvc3Npbmc8YnI+DQomcXVvdDtmdW5jdGlv bmFsIGJvdW5kYXJpZXMmcXVvdDsgYXMgbm90ZWQgYmVsb3csIHllcz88YnI+DQo8YnI+DQpbICZx dW90O2N1cnJlbnQgc3BlYyZxdW90OyBkaXNjdXNzZWQgaGVyZWluID0gLXRva2JpbmQtaHR0cHMt MDIgYWthIEhUVFBTVEIsPGJyPg0KwqAgwqBvdGhlciBzcGVjcy4uPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgLXRva2JpbmQtbmVnb3RpYXRpb24tMDIgYWthIFRCTkVHTzxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIC10b2tiaW5kLXByb3RvY29sLTA0IGFrYSBUQlBST1RP IF08YnI+DQo8YnI+DQpPbiBGcmksIDExIE1hciAyMDE2IERpcmsgZnVydGhlciByZXBsaWVkOjxi cj4NCiZndDsgSSBiZWxpZXZlIHRoYXQgY292ZXJzIGFsbCB0aGUgdXNlIGNhc2VzIHRoYXQgeW91 JiMzOTtyZSBkZXNjcmliaW5nOiBMZXQmIzM5O3MgZmlyc3Q8YnI+DQomZ3Q7IGNvbnNpZGVyIHRo ZSBjYXNlIHdoZXJlIHRoZXJlIGlzIG9uZSBSZWx5aW5nIFBhcnR5LCBhbmQgb25lIElkZW50aXR5 PGJyPg0KJmd0OyBQcm92aWRlci4gVGhlIFJQIG1pZ2h0IGdvIHRocm91Z2ggYSBidW5jaCBvZiBy ZWRpcmVjdHMgYmVmb3JlIHVsdGltYXRlbHk8YnI+DQomZ3Q7IGhhbmRpbmcgdGhpbmdzIG9mZiB0 byB0aGUgSWRQLCBhbmQgdGhlIElkUCBtaWdodCBnbyB0aHJvdWdoIGEgYnVuY2ggb2Y8YnI+DQom Z3Q7IHJlZGlyZWN0cyBiZWZvcmUgdWx0aW1hdGVseSBoYW5kbGluZyB0aGUgUlAgcmVxdWVzdC4g U2FtZSBvbiB0aGUgd2F5IGJhY2s8YnI+DQomZ3Q7IGZyb20gdGhlIElkUCB0byB0aGUgUlAuPGJy Pg0KPGJyPg0KdW5kZXJzdG9vZC48YnI+DQo8YnI+DQomZ3Q7IFRoZSBvbmUgcmVkaXJlY3Qgd2hl cmUgdGhlIHJlZmVycmVkIHRva2VuIGJpbmRpbmcgaXMgbmVjZXNzYXJ5IGlzIHRoZTxicj4NCiZn dDsgcmVkaXJlY3QgdGhhdCBjcm9zc2VzIGZ1bmN0aW9uYWwgYm91bmRhcmllczogZnJvbSB0aGUg UlAgdG8gdGhlIElkUC48YnI+DQo8YnI+DQphZ3JlZWQuPGJyPg0KPGJyPg0KJmd0OyBJZiB0aGU8 YnI+DQomZ3Q7IGZpcnN0IGVuZHBvaW50IGF0IHRoZSBJZFAgaXNuJiMzOTt0IHRoZSBvbmUgdGhh dCBpcyBwcm9jZXNzaW5nIHRoZSBSUCByZXF1ZXN0PGJyPg0KJmd0OyAoYmVjYXVzZSwgc2F5LCBp dCYjMzk7cyB0aGUgb2xkIG9uZSBhbmQgaXQmIzM5O3Mgbm93IHJlZGlyZWN0aW5nIHRvIHRoZSBu ZXcgb25lKSw8YnI+DQomZ3Q7IHRoYXQgZW5kcG9pbnQgbmVlZHMgdG8gZW5jb2RlIHRoZSBpbmZv cm1hdGlvbiBpdCBsZWFybnMgKGkuZS4sIHdoYXQgaXMgdGhlPGJyPg0KJmd0OyBwdWJsaWMga2V5 IHRoYXQgdGhlIGNsaWVudCBpcyB1c2luZyB3aXRoIHRoZSBSUCkgaW4gc29tZSB3YXkgKHdoaWNo IGNhbiBiZTxicj4NCiZndDsgcHJvcHJpZXRhcnkgdG8gdGhlIElkUCkgYW5kIHBhc3MgdGhhdCBh bG9uZyBhcyB0aGUgcmVxdWVzdCBpcyBoYW5kZWQgb2ZmLjxicj4NCjxicj4NCmFncmVlZCB0aGF0 IHRoZSBhYm92ZSB3b3JrcyBpbiB0aGUgY2FzZSB3aGVyZSB0aGUgVG9rZW4gQ29uc3VtZXIgKFJQ KSB0aGF0PGJyPg0KcmVkaXJlY3RzIHRvIElkUDEgaXMgdGhlIGludGVuZGVkIHJlY2lwaWVudCBv ZiB0aGUgZXZlbnR1YWwgdG9rZW4tYm91bmQgSUQ8YnI+DQp0b2tlbi48YnI+DQo8YnI+DQpIb3dl dmVyLCBmZWRlcmF0aW9uIHByb3RvY29scyBoYXZlIGEgbm90aW9uIG9mIGEgJiMzOTtyZXR1cm4g YWRkcmVzcyYjMzk7IHRoYXQmIzM5O3M8YnI+DQp0eXBpY2FsbHkgaW5jbHVkZWQgaW4gdGhlIFJQ JiMzOTtzICYjMzk7YXV0aG4gcmVxdWVzdCYjMzk7LiBFLmcuLCBpbiBPSURDIGl0IGlzIHRoZTxi cj4NCiZxdW90O3JlZGlyZWN0X3VyaSZxdW90OyBbMV0sIGFuZCBpbiBTQU1MIHRoZSBlcXVpdmFs ZW50IGlzIHRoZTxicj4NCiZxdW90O0Fzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTCZxdW90OyBb Ml0uPGJyPg0KPGJyPg0KVXBvbiBpc3N1YW5jZSBvZiB0aGUgc2VjdXJpdHkgdG9rZW4sIHRoZSBJ RFAgcmVkaXJlY3RzIHRoZSBVQSB0byB0aGU8YnI+DQpzcGVjaWZpZWQgJiMzOTtyZXR1cm4gYWRk cmVzcyYjMzk7LCB3aGljaCBkb2VzIG5vdCBuZWNlc3NhcmlseSBwb2ludCB0byB0aGUgUlA8YnI+ DQplbnRpdHkgdGhhdCByZWRpcmVjdGVkIHRoZSBVQSB0byB0aGUgSURQLCBub3IgZXZlbiBhbnkg b2YgdGhlIGVudGl0aWVzIGluPGJyPg0KdGhlIFJQJiMzOTtzICZxdW90O3JlZGlyZWN0IGNoYWlu JnF1b3Q7Ljxicj4NCjxicj4NClNvIHRoZXJlIG5lZWRzIHRvIGJlIHNvbWUgbWVhbnMgZm9yIHRo ZSBJRFAgdG8gcmVjZWl2ZSB0aGUgX2NvcnJlY3RfPGJyPg0KcmVmZXJyZWQgVEJJRCB0byBpbmNs dWRlIGluIHRoZSBzZWN1cml0eSB0b2tlbiBpdCBnZW5lcmF0ZXMgYW5kIHRoZW4gcmV0dXJuczxi cj4NCi0tIHRoaXMgaXMgbm90IG5lY2Vzc2FyaWx5IHRoZSBSUCBlbnRpdHkgdGhhdCByZWRpcmVj dGVkIHRvIHRoZSBJRFAuIEEgZmV3PGJyPg0Kd2F5cyB0byBhZGRyZXNzIHRoaXMgaW4gSFRUUFNU QiBwZXJoYXBzIGFyZS4uPGJyPg0KPGJyPg0KV2UgY291bGQgbWFuZGF0ZSBpbiBIVFRQU1RCIHRo YXQgdGhlIHJlY2VpdmluZyBSUCBlbnRpdHkgKGFrYSBUb2tlbjxicj4NCkNvbnN1bWVyKSBNVVNU IGhhdmUgdGhlIHNhbWUgZVRMRCsxIGFzIHRoZSBSUCBlbnRpdHkgdGhhdCByZWRpcmVjdGVkIChh a2E8YnI+DQomcXVvdDtoYW5kZWQgb2ZmJnF1b3Q7KSB0byB0aGUgSURQLiAoc2VlIGJlbG93IGZv ciBkaXNjdXNzaW9uIG9mIFRCIHNjb3BpbmcgcnVsZXMpPGJyPg0KPGJyPg0KT3IsIHdlIGNvdWxk IGF0dGVtcHQgdG8gZGV2aXNlIGEgbWVhbnMgZm9yIHRoZSBSUCBlbnRpdGllcyB0byBzaWduYWwg dGhlPGJyPg0KY29ycmVjdCByZWZlcnJlZCBUQklEIHRvIHRoZSBJRFAgdmlhIEhUVFBTVEIvVEJQ Uk9UTy48YnI+DQo8YnI+DQpPciwgd2UgY291bGQgcHVudCB0aGUgcHJvYmxlbSB0byBkZXBsb3ll cnMgYW5kIHNheSBzb21ldGhpbmcgbGlrZSAmcXVvdDt0aGU8YnI+DQpyZWZlcnJlZCBUQklEIGlu IHRoZSBUQk1TRyBNVVNUIG1hcCB0byB0aGUgZW50aXR5IHNwZWNpZmllZCBpbiB0aGUgYXV0aG48 YnI+DQpyZXF1ZXN0JiMzOTtzIHJldHVybiBhZGRyZXNzIC0tIGkuZS4sIHRoZSBUQklEIGluY2x1 ZGVkIGluIHRoZSBpc3N1ZWQgc2VjdXJpdHk8YnI+DQp0b2tlbiBieSB0aGUgSURQIG5lZWRzIHRv IG1hdGNoIHRoZSBjbGllbnQmIzM5O3MgVExTIGNvbm5lY3Rpb24gd2l0aCB0aGUgZW50aXR5PGJy Pg0Kd2hvIHdpbGwgX3JlY2VpdmVfIHRoZSBzZWN1cml0eSB0b2tlbiwgZXZlbiBpZiB0aGUgbGF0 dGVyIGVudGl0eSBpcyBub3QgdGhlPGJyPg0Kb25lIHRvIHJlZGlyZWN0IHRvIHRoZSBJRFAmcXVv dDsgLS0gaXQgaXMgaW1wbGVtZW50ZXJzJiMzOTsgYW5kIGRlcGxveWVycyYjMzk7PGJyPg0KcmVz cG9uc2liaWxpdHkgdG8gZ2V0IHRoaXMgcmlnaHQuPGJyPg0KPGJyPg0KU2VlIFtmaWd1cmUgMV0g YXQgZW5kIGJlbG93Ljxicj4NCjxicj4NCjxicj4NCiZndDsgT24gdGhlIHdheSBiYWNrLCBhZnRl ciB0aGUgSWRQIHJlZGlyZWN0cyBiYWNrIHRvIHRoZSBSUCwgdGhlIFJQIGp1c3QgbmVlZHM8YnI+ DQomZ3Q7IHRvIG1ha2Ugc3VyZSB0aGF0IG9uZSBvZiB0aGUgZW5kcG9pbnRzIGluIHRoZSByZWRp cmVjdCBjaGFpbiBpcyBvbiB0aGUgc2FtZTxicj4NCiZndDsgZVRMRCsxIGFzIHRoZSBlbmRwb2lu dCB0aGF0IGRpZCB0aGUgaGFuZC1vZmYgdG8gdGhlIElkUCwgc28gaXQgY2FuIHByb2Nlc3M8YnI+ DQomZ3Q7IHRoZSBJZFAgcmVzcG9uc2UgdGhlcmUuPGJyPg0KPGJyPg0KaG0sIHBlcmhhcHMgdGhl cmUgYXJlIHNvbWUgaXNzdWVzIGhlcmUuLjxicj4NCjxicj4NCiogd2l0aCByZWdhcmRzIHRvIHBy b2Nlc3NpbmcgdGhlIElEUCByZXNwb25zZSAuLi4gaXMgdGhlIGFib3ZlLXN0YXRlZCBlVExEKzE8 YnI+DQpyZXF1aXJlbWVudCBiZWNhdXNlIHRoZSBjbGllbnQgYWthIHVzZXIgYWdlbnQgKFVBKSB3 aWxsIHVzZSB0aGUgc2FtZTxicj4NCnByb3ZpZGVkIFRCSUQgd2l0aCBzZXJ2ZXJzIHdob3NlIGhv c3RuYW1lcyBtYXAgdG8gdGhlIHNhbWUgZVRMRCsxID88YnI+DQotdG9rYmluZC1wcm90b2NvbCBh a2EgVEJQUk9UTyBzYXlzLi48YnI+DQo8YnI+DQrCoCDCoCAuLi4gSW4gb3JkZXIgdG8gcHJldmVu dCBjb29wZXJhdGluZyBzZXJ2ZXJzIGZyb20gbGlua2luZyB1c2VyPGJyPg0KwqAgwqAgaWRlbnRp dGllcywgZGlmZmVyZW50IGtleXMgU0hPVUxEIGJlIHVzZWQgYnkgdGhlIGNsaWVudCBmb3I8YnI+ DQrCoCDCoCBjb25uZWN0aW9ucyB0byBkaWZmZXJlbnQgc2VydmVycywgYWNjb3JkaW5nIHRvIHRo ZSB0b2tlbiBzY29waW5nPGJyPg0KwqAgwqAgcnVsZXMgb2YgdGhlIGFwcGxpY2F0aW9uIHByb3Rv Y29sLjxicj4NCjxicj4NCi4uc28gaXQgc2VlbXMgd2UgYXJlIGFzc3VtaW5nIChpbiBIVFRQU1RC KSB0aGF0IEhUVFBTIGNsaWVudHMgbWFwIHRoZTxicj4NCnNlcnZlcnMgdG8gZVRMRCsxIHdoZW4g Z2VuZXJhdGluZyB0aGVpciBUQiBrZXkgcGFpcnMsIGFuZCBhZml4IFRva2VuLUJpbmRpbmc8YnI+ DQpoZWFkZXIgZmllbGRzIHRvIHRoZWlyIEhUVFAgbXNncyBwZXIgc2FpZCBtYXBwaW5nLCB5ZXM/ PGJyPg0KPGJyPg0Kc29tZSB0aG91Z2h0cy9pc3N1ZXMuLjxicj4NCjxicj4NCsKgIC0gZVRMRCBh bmQgZVRMRCsxIGFyZSBub3QgbWVudGlvbmVkIGluIEhUVFBTVEI8YnI+DQo8YnI+DQrCoCAtIEhU VFBTVEIgZG9lcyBub3QgZXhwbGljaXRseSBkZWZpbmUgd2hpY2ggcGFydGljdWxhciAmcXVvdDt0 b2tlbiBzY29waW5nPGJyPg0KwqAgwqAgcnVsZXMmcXVvdDsgaW1wbHMgbXVzdCBhZGhlcmUgdG8u IElzIHRoZSBjbGllbnQtc2lkZSBUQklEIHN0b3JhZ2UtYW5kLW1hcHBpbmc8YnI+DQrCoCDCoCBt b2RlbCBpbnRlbmRlZCB0byBtYXAgb25seSB0byBkb21haW4gbmFtZXMsIGFuZCBpbiB0aGlzIGNh c2UgYmUgJnF1b3Q7ZG9tYWluPGJyPg0KwqAgwqAgbG93ZXJlZCZxdW90OyB0byBlVExEKzEgKG1v ZHVsbyA8YSBocmVmPSJodHRwOi8vcHVibGljc3VmZml4Lm9yZyIgcmVsPSJub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayI+cHVibGljc3VmZml4Lm9yZzwvYT4pIHNpbWlsYXJseSB0byBob3cgY29v a2llcyYjMzk7PGJyPg0KwqAgwqAgZG9tYWluLW1hdGNoaW5nIHdvcmtzPyBbM11bNF08YnI+PC9i bG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+SnVzdCBhZGRlZCBsYW5ndWFnZSB0byB0aGF0 IGVmZmVjdCBpbiBhIG5ldyAmcXVvdDtQcml2YWN5IENvbnNpZGVyYXRpb25zJnF1b3Q7IHNlY3Rp b24gaW4gLTAzLiBUYWtlIGEgbG9vayBhbmQgc2VlIHdoZXRoZXIgeW91IGxpa2UgaXQgLyBoYXZl IHNvbWUgaWRlYXMgdG8gaW1wcm92ZSBvbiBpdC48L2Rpdj48ZGl2PsKgPC9kaXY+PGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxl ZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8YnI+DQrCoCAtIHdoYXQgYWJv dXQgc2VydmVycyB0aGF0IGFyZSBpZGVudGlmaWVkIGJ5IElQIGFkZHJlc3M/IE5vdGUgdGhhdCBp biBIU1RTPGJyPg0KwqAgwqAgd2UgcHVudGVkIG9uIHN1cHBvcnRpbmcgc2VydmVycyBpZGVudGlm aWVkIGJ5IElQIGFkZHJlc3NlcyBbNV0uIFRobywgaW48YnI+DQrCoCDCoCBSRkM2MjY1IGEgc2Vy dmVyIGFkZHJlc3NlZCBieSBJUCBhZGRyZXNzIGNhbiBzZXQgY29va2llcywgYnV0IG9ubHkgZm9y PGJyPg0KwqAgwqAgaXRzZWxmIChpLmUuLCB0aGUgaG9zdC1vbmx5IGZsYWcgaXMgc2V0IHRvIHRy dWUgWzZdOyBpLmUuLCBjb29raWU8YnI+DQrCoCDCoCAmcXVvdDtkb21haW4gbG93ZXJpbmcmcXVv dDsgaXMgdW5kZWZpbmVkIGZvciBJUCBhZGRyZXNzZXMpLiBJczxicj4NCsKgIMKgIGFsbG93aW5n L2Rpc2FsbG93aW5nIGEgaG9zdC1vbmx5IElQIGFkZHJlc3MtYmFzZWQgVEJJRCBtYXBwaW5nPGJy Pg0KwqAgwqAgc29tZXRoaW5nwqAgd2Ugc2hvdWxkIGNvbnNpZGVyIGdlbmVyYWxseSBmb3IgVEJQ Uk9UTywgb3I8YnI+DQrCoCDCoCBqdXN0IHNwZWNpZmljYWxseSBjb25zaWRlciBmb3IgSFRUU1RC Pzxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5JJiMzOTtkIHNheSB0aGF0IHNl cnZlcnMgaWRlbnRpZmllZCBieSBJUCBhZGRyZXNzZXMgd2lsbCBnZXQga2V5cyBzY29wZWQgdG8g dGhhdCBleGFjdCBJUCBhZGRyZXNzIC0ganVzdCBsaWtlIGNvb2tpZXMuIEkgdGhpbmsgaXQgYmVs b25ncyBpbiBIVFRQU1RCIGFzIGEgU0hPVUxEIGZvciB3ZWIgYnJvd3NlcnMuwqA8L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PkRpcmsuPC9kaXY+PGRpdj7CoDwvZGl2PjxibG9ja3F1b3RlIGNsYXNz PSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAj Y2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJyPg0KPGJyPg0KJmd0OyBOZXh0LCBsZXQm IzM5O3MgY29uc2lkZXIgd2hhdCBoYXBwZW5zIGlmIHRoZXJlIGFyZSBtdWx0aXBsZSBJZFAmIzM5 O3MgaW52b2x2ZWQsIHNheTxicj4NCiZndDsgc29tZXRoaW5nIGxpa2UgPGEgaHJlZj0iaHR0cDov L3JwLmNvbSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+cnAuY29tPC9hPiAtJmd0 OyA8YSBocmVmPSJodHRwOi8vaWRlbnRpdHktYXMtYS1zZXJ2aWNlLmNvbSIgcmVsPSJub3JlZmVy cmVyIiB0YXJnZXQ9Il9ibGFuayI+aWRlbnRpdHktYXMtYS1zZXJ2aWNlLmNvbTwvYT4gLSZndDsg PGEgaHJlZj0iaHR0cDovL2lkcC5jb20iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsi PmlkcC5jb208L2E+LiBJbiB0aGF0PGJyPg0KJmd0OyBjYXNlLCA8YSBocmVmPSJodHRwOi8vaWRl bnRpdHktYXMtYS1zZXJ2aWNlLmNvbSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+ aWRlbnRpdHktYXMtYS1zZXJ2aWNlLmNvbTwvYT4gYWN0cyBsaWtlIGFuIElkUCB0byA8YSBocmVm PSJodHRwOi8vcnAuY29tIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5ycC5jb208 L2E+LCBhbmQgYXMgYW4gUlAgdG88YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9pZHAuY29tIiBy ZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5pZHAuY29tPC9hPiwgc28gd2UgcGxheSB0 aGUgZ2FtZSBkZXNjcmliZWQgYWJvdmUgdHdpY2UuIEl0IHdvdWxkbiYjMzk7dCBtYWtlIHNlbnNl PGJyPg0KJmd0OyBoZXJlIGlmIDxhIGhyZWY9Imh0dHA6Ly9pZHAuY29tIiByZWw9Im5vcmVmZXJy ZXIiIHRhcmdldD0iX2JsYW5rIj5pZHAuY29tPC9hPiBzb21laG93IGtuZXcgd2hhdCBwdWJsaWMg a2V5IHRoZSBjbGllbnQgaXMgdXNpbmcgd2l0aCA8YSBocmVmPSJodHRwOi8vcnAuY29tIiByZWw9 Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5ycC5jb208L2E+PGJyPg0KJmd0OyAtIGl0JiMz OTtzIHVzZWxlc3MgaW5mb3JtYXRpb24uIEluIGEgc2NlbmFyaW8gbGlrZSB0aGlzLCA8YSBocmVm PSJodHRwOi8vaWRwLmNvbSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aWRwLmNv bTwvYT4gbmVlZHMgdG88YnI+DQomZ3Q7IHN0cm9uZ2x5IGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50 IHRvIDxhIGhyZWY9Imh0dHA6Ly9pZGVudGl0eS1hcy1hLXNlcnZpY2UuY29tIiByZWw9Im5vcmVm ZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5pZGVudGl0eS1hcy1hLXNlcnZpY2UuY29tPC9hPiwgbm90 IHRvIDxhIGhyZWY9Imh0dHA6Ly9ycC5jb20iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxh bmsiPnJwLmNvbTwvYT48YnI+DQo8YnI+DQpBZ3JlZWQsIGluIHRoaXMgcGFydGljdWxhciwgdGln aHRseS1jb25zdHJhaW5lZCBzY2VuYXJpby48YnI+DQo8YnI+DQpIVEgsPGJyPg0KPGJyPg0KPUpl ZmZIPGJyPg0KPGJyPg0KPGJyPg0KWzFdIDxhIGhyZWY9Imh0dHBzOi8vb3BlbmlkLm5ldC9zcGVj cy9vcGVuaWQtY29ubmVjdC1jb3JlLTFfMC5odG1sI0F1dGhSZXF1ZXN0IiByZWw9Im5vcmVmZXJy ZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5l Y3QtY29yZS0xXzAuaHRtbCNBdXRoUmVxdWVzdDwvYT48YnI+DQo8YnI+DQpbMl0gPGEgaHJlZj0i aHR0cHM6Ly9kb2NzLm9hc2lzLW9wZW4ub3JnL3NlY3VyaXR5L3NhbWwvdjIuMC9zYW1sLWNvcmUt Mi4wLW9zLnBkZiIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kb2Nz Lm9hc2lzLW9wZW4ub3JnL3NlY3VyaXR5L3NhbWwvdjIuMC9zYW1sLWNvcmUtMi4wLW9zLnBkZjwv YT48YnI+DQo8YnI+DQpbM10gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzYyNjUjc2VjdGlvbi01LjEuMyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYyNjUjc2VjdGlvbi01LjEuMzwvYT48YnI+DQo8 YnI+DQpbNF0gPGEgaHJlZj0iaHR0cDovL2lkZW50aXR5bWVtZS5vcmcvaHR0cC1jb29raWUtcHJv Y2Vzc2luZy1hbGdvcml0aG0tZXRsZHMvIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vaWRlbnRpdHltZW1lLm9yZy9odHRwLWNvb2tpZS1wcm9jZXNzaW5nLWFsZ29yaXRo bS1ldGxkcy88L2E+PGJyPg0KPGJyPg0KWzVdIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2Nzk3I2FwcGVuZGl4LUEiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2Nzk3I2FwcGVuZGl4LUE8L2E+PGJy Pg0KPGJyPg0KWzZdIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MjY1 I3NlY3Rpb24tNS4zIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNjI2NSNzZWN0aW9uLTUuMzwvYT4gLSBzdGVwIDYuPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KW2ZpZ3VyZSAxXTxicj4NCjxicj4NCldoYXQ6IEFuYWx5c2lzIG9m IHJlZGlyZWN0IGhvcHMgYXQgUlAgYWthIFRDIGFuZCBhdCBJRFAgYWthIFRQPGJyPg0KPGJyPg0K TGVnZW5kOjxicj4NCjxicj4NCsKgIMKgRUtNOsKgIMKgIMKgIMKgVExTIEV4cG9ydGVkIEtleWlu ZyBNYXRlcmlhbCBbUkZDNTcwNV08YnI+DQo8YnI+DQrCoCDCoHtFS01ufUtzbTogRUtNIGZvciBz ZXJ2ZXIgJnF1b3Q7biZxdW90Oywgc2lnbmVkIGJ5IHByaXZhdGUga2V5IG9mIFRCSUQgJnF1b3Q7 bSZxdW90Oyw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCB3aGVyZSAmcXVvdDtuJnF1b3Q7IG11 c3QgcmVwcmVzZW50IHNlcnZlciByZWNlaXZpbmcgdGhlIEVUQk1TRyw8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCBpZiBhIGNvbnZleWVkIFRCJiMzOTtzIHR5cGUgaXMgcHJvdmlkZWRfdG9rZW5f YmluZGluZywgdGhlbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIG0gPSBuLCBlbHNlIGlmIFRC JiMzOTtzIHR5cGUgaXMgcmVmZXJyZWRfdG9rZW5fYmluZGluZywgdGhlbjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIG0gIT0gbi4gRS5nLiwgc2VlIHN0ZXAgMWIgaW4gZGlhZ3JhbSBiZWxvdy48 YnI+DQo8YnI+DQrCoCDCoEVUQk1TRzrCoCDCoCAmcXVvdDtUb2tlbi1CaW5kaW5nJnF1b3Q7IEhU VFAgaGVhZGVyIGZpZWxkIGNvbnZleWluZyBhbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIEVu Y29kZWRUb2tlbkJpbmRpbmdNZXNzYWdlLCBpbiB0dXJuIGNvbnZleWluZzxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIFRva2VuQmluZGluZyAoVEIpc3RydWN0KHMpLCBlLmcuOjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIEVUQk1TR1tbVEJdXSBvciBFVEJNU0dbW1RCMV0sW1RCMl1dPGJyPg0K PGJyPg0KwqAgwqBJRCBUb2tlbjrCoCB0aGUgJnF1b3Q7SUQgVG9rZW4mcXVvdDsgaW4gT0lEQywg aXQgaXMgdGhlIHNlbWFudGljIGVxdWl2YWxlbnQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCBv ZiBhIFNBTUwgJnF1b3Q7YXV0aGVudGljYXRpb24gYXNzZXJ0aW9uJnF1b3Q7LiAmcXVvdDtJRCBU b2tlbiB3L1RCSURuJnF1b3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGVub3RlcyBhICZx dW90O3Rva2VuIGJvdW5kJnF1b3Q7IElEIFRva2VuIGNvbnRhaW5pbmcgVEJJRG4uPGJyPg0KPGJy Pg0KwqAgwqBLcyAmYW1wOyBLcDrCoCDCoHByaXZhdGUgKGFrYSBzZWNyZXQpIGtleSwgYW5kIHB1 YmxpYyBrZXksIHJlc3BlY3RpdmVseSw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCBvZiBjbGll bnQtc2lkZSBUb2tlbiBCaW5kaW5nIGtleSBwYWlyPGJyPg0KPGJyPg0KwqAgwqBPSURDOsKgIMKg IMKgIE9wZW4gSUQgQ29ubmVjdDxicj4NCjxicj4NCsKgIMKgVEI6wqAgwqAgwqAgwqAgVG9rZW5C aW5kaW5nIHN0cnVjdCBjb250YWluaW5nIHNpZ25lZCBFS00sIFRCSUQsIGFuZDxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIFRCIHR5cGUsIGUuZy46IFt7RUtNMX1LczEsVEJJRDEscHJvdmlkZWRf dG9rZW5fYmluZGluZ108YnI+DQo8YnI+DQrCoCDCoFRCSURuOsKgIMKgIMKgVG9rZW4gQmluZGlu ZyBJRCBmb3IgY2xpZW50IGFuZCBzZXJ2ZXIgbiYjMzk7cyB0b2tlbi1ib3VuZDxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIFRMUyBhc3NvY2lhdGlvbi4gVEJJRG4gY29udGFpbnMgS3BuLjxicj4N Cjxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIFRva2VuIENvbnN1bWVyLMKgIMKgIMKgIMKgIFRva2VuIFByb3ZpZGVyLDxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFrYTrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGFrYTo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPcGVuSUQgQ2xpZW50LMKgIMKgIMKgIMKgIMKgT3Bl bklEIFByb3ZpZGVyLDxicj4NCkNsaWVudCzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBPSURDIFJlbHlpbmcgUGFydHkswqAgwqAgT0lEQyBQcm92aWRlciw8YnI+DQpha2E6wqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBTQU1MIFJlbHlpbmcgUGFydHnC oCDCoCDCoFNBTUwgSWRlbnRpdHkgUHJvdmlkZXI8YnI+DQpVc2VyIEFnZW50wqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBbIHNlcnZlcnMgJnF1b3Q7MSZxdW90OywgJnF1b3Q7MiZxdW90 OyBdwqAgwqBbIHNlcnZlcnMgJnF1b3Q7MyZxdW90OywgJnF1b3Q7NCZxdW90OyBdPGJyPg0KKy0t LS0tLS0tK8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKy0tLS0tK8KgICstLS0t LSvCoCDCoCDCoCstLS0tLSvCoCDCoCstLS0tLSs8YnI+DQp8IENsaWVudCB8wqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IFRDMSB8wqAgfCBUQzIgfMKgIMKgIMKgfCBUUDMgfMKg IMKgfCBUUDQgfDxicj4NCistLS0tLS0tLSvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCstLS0tLSvCoCArLS0tLS0rwqAgwqAgwqArLS0tLS0rwqAgwqArLS0tLS0rPGJyPg0KwqAg wqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAg wqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIMKg fMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKg IMKgIHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoHwgMC4g Q2xpZW50IGludGVyYWN0cyB3L1RDMcKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoHwgb3ZlciBIVFRQUywgZXN0YWJsaXNo ZXMgS3MxICZhbXA7IEtwMSwgVEJJRDHCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8 YnI+DQrCoCDCoCDCoHwgRVRCTVNHW1t7RUtNMX1LczEsVEJJRDEscHJvdmlkZWRfdG9rZW5fYmlu ZGluZ11dwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgwqB8LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tJmd0O3zCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAg wqAgwqAgwqB8PGJyPg0KwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKg IMKgfDxicj4NCsKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgfMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8 YnI+DQrCoCDCoCDCoHwgMWEuIHJlZGlyZWN0IHRvIFRDMiBmb3IgVEMtc3BlY2lmaWMgcmVhc29u c8KgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoHwgYW55IHNlY3VyaXR5 LXJlbGV2YW50IGNvb2tpZXMgc2hvdWxkIGNvbnRhaW4gVEJJRDEgfMKgIMKgIMKgIMKgIMKgfDxi cj4NCsKgIMKgKyZsdDstIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIHzCoCDCoCDCoCDC oCB8wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAuIHzCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8wqAg wqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKg IMKgIMKgfDxicj4NCsKgIMKgIMKgfCAxYi4gZXN0YWJsaXNoZXMgS3MyICZhbXA7IEtwMiwgVEJJ RDLCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDC oCDCoHwgRVRCTVNHW1t7RUtNMn1LczIsVEJJRDIscHJvdmlkZWRfdG9rZW5fYmluZGluZ11dwqAg wqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgfMKg IMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDC oCDCoCDCoHw8YnI+DQrCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAg wqB8PGJyPg0KwqAgwqAgwqB8IDJhLiBPSURDIElEIFRva2VuIHJlcXVlc3QswqAgwqAgfMKgIMKg IMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoHwg YWthICZxdW90O0F1dGhlbnRpY2F0aW9uIFJlcXVlc3QmcXVvdDsgdy8gcmVkaXJlY3RfdXJpPVRD MTvCoCAmbHQ7LS0gbm90ZSB3ZWxsPGJyPg0KwqAgwqAgwqB8IGNvbnZleWVkIHcvIEhUVFAgcmVz cG9uc2UgaGVhZGVyIGZpZWxkIG9mOjxicj4NCsKgIMKgIMKgfMKgIMKgSW5jbHVkZS1SZWZlcmVy LVRva2VuLUJpbmRpbmctSUQ6dHJ1ZcKgIMKgIMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoHw8 YnI+DQrCoCDCoCDCoHwgYW55IHNlY3VyaXR5LXJlbGV2YW50IGNvb2tpZXMgc2hvdWxkIGNvbnRh aW4gVEJJRDIgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgKyZsdDstIC0gLSAtIC0gLSAtIC0g LSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLXzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDC oHw8YnI+DQrCoCDCoC4gfCAocmVkaXJlY3QgdG8gVFAgdmlhIDMwMSwgMzAyLCB8wqAgwqAgwqAg wqAgfMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgLiB8wqAgMzAz LCAzMDcsIG9yIDMwOCnCoCDCoCDCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKg IMKgIMKgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgLiB8wqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKg fMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3zCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDC oHwgMmIuIGNsaWVudCBvcGVucyBIVFRQUyB3LyBUUDMswqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAg wqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgwqB8IGVzdGFibGlzaGVzIEtzMywg S3AzLCBUQklEMzvCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDC oCDCoHw8YnI+DQrCoCDCoCDCoHwgc2VuZHMgR0VUIG9yIFBPU1Qgd2l0aMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKg IMKgfCBJRCBUb2tlbiByZXF1ZXN0IHcvIHJlZGlyZWN0X3VyaT1UQzEswqAgfMKgIMKgIMKgIMKg IMKgIMKgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIMKgfCBFVEJNU0dbW3tFS00zfUtzMyxU QklEMyxwcm92aWRlZF90b2tlbl9iaW5kaW5nXSzCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+DQrC oCDCoCDCoHzCoCDCoCDCoCDCoFt7RUtNM31LczIsVEJJRDIscmVmZXJyZWRfdG9rZW5fYmluZGlu Z11dICZsdDstLSBidXQgSUQgVG9rIHJlcXVlc3Q8YnI+DQrCoCDCoCDCoHzCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8wqAgwqAgwqAg wqAgJmx0Oy0tIGlzIGZvciBUQzE8YnI+DQrCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqB8wqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAg fMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIMKgfMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIHzCoCDC oCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoHwgM2EuIHJlZGlyZWN0 IHRvIFRQNCBmb3IgVFAtc3BlY2lmaWMgcmVhc29uc8KgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDC oHw8YnI+DQrCoCDCoCDCoHwgYW55IHNlY3VyaXR5LXJlbGV2YW50IGNvb2tpZXMgc2hvdWxkIGNv bnRhaW4gVEJJRDMgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgKyZsdDstIC0gLSAtIC0gLSAt IC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLXzCoCDCoCDCoCDCoCDCoHw8 YnI+DQrCoCDCoC4gfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgfMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrC oCDCoCstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0mZ3Q7fDxicj4NCsKgIMKgIMKgfCAzYi4gY2xpZW50IG9wZW5zIEhUVFBTIHcv IFRQNCzCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+ DQrCoCDCoCDCoHwgZXN0YWJsaXNoZXMgS3M0ICZhbXA7IEtwNCwgVEJJRDTCoCDCoCDCoCDCoCDC oCDCoHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoHwgRVRC TVNHW1t7RUtNNH1LczQsVEJJRDQscHJvdmlkZWRfdG9rZW5fYmluZGluZ11dwqAgwqB8wqAgwqAg wqAgwqAgwqB8PGJyPg0KwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAqKiogYXMgd2VsbCBhcyB0aGUg SUQgVG9rZW4gcmVxdWVzdCB3LyByZWRpcmVjdF91cmk9VEMxOzxicj4NCsKgIMKgIMKgfMKgIMKg IMKgIMKgIMKgKioqIGFsc28sIHNvbWVob3cgY29udmV5cyBUQklEMiB0byBUUDQgPzxicj4NCsKg IMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKg IMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDC oHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDC oCDCoCB8wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgwqB8wqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAg fMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIMKgfCA0LiB1c2Vy IGF1dGhlbnRpY2F0aW9uIChpZiBhcHBsaWNhYmxlLMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKg IMKgIMKgIMKgfDxicj4NCsKgIMKgIMKgfMKgIMKgIG1ldGhvZHMgdmFyeSwgcGFydGljdWxhcnMg YXJlIG91dCBvZiBzY29wZSnCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoHwm bHQ7PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Jmd0O3w8YnI+DQrCoCDCoCDCoHwgKFRQIGdlbmVyYXRlcyBJRCBUb2tlbiBmb3IgVEMx IGNvbnRhaW5pbmcgVEJJRDEgLSBUUDQgaGFzIG9ubHkgVEJJRDI8YnI+DQrCoCDCoCDCoHzCoCBh bHNvIHNldCBjb29raWUocykgY29udGFpbmluZyBUQklENCBhbmQvb3IgVEJJRDM8YnI+DQrCoCDC oCDCoHzCoCBkZXRhaWxzIHZhcnkpwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKg IHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoHzCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8wqAg wqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgwqB8wqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgfMKgIMKgIMKg IMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDC oCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoHwgNWEuIElEIFRva2VuIGlzc3VlZCBm b3IgVEMxLCBjb250YWluaW5nIFRCSUQxLCAmbHQ7LS0gaG93IGRvIHRoaXMgaWY8YnI+DQrCoCDC oCDCoHzCoCDCoCBjb252ZXllZCB2aWEgT0lEQyAmcXVvdDtBdXRoZW50aWNhdGlvbiBSZXNwb25z ZSZxdW90OyAmbHQ7LS0gZG9uJiMzOTt0IGhhdmUgVEJJRDE/PGJyPg0KwqAgwqArJmx0Oy0gLSAt IC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0g LXw8YnI+DQrCoCDCoC4gfMKgIMKgKHJlZGlyZWN0IHRvIFRDMSnCoCDCoCDCoCDCoCDCoCDCoHzC oCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAu IHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDC oCDCoCB8wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqArLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDC oCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoHwgNWIuIEhUVFBTIEdFVCBvciBQT1NU IHdpdGjCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKg fDxicj4NCsKgIMKgIMKgfCBFVEJNU0dbW3tFS00xfUtzMSxUQklEMSxwcm92aWRlZF90b2tlbl9i aW5kaW5nXV3CoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoHwgY29udmV5aW5nIEF1 dGhuIFJlcG9uc2UgY29udGFpbmluZyBJRCBUb2tlbiB3L1RCSUQxLMKgIMKgIMKgIMKgIMKgfDxi cj4NCsKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGlzc3VlZCBmb3IgVEMxwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIMKgIMKg fMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKg IMKgIHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoHzCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8 wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgwqB8wqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgfMKgIMKg IMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIMKgfMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDC oCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoHwgNi4gdXNlciBpcyBzaWduZWQt b24sIGFueSBzZWN1cml0eS1yZWxldmFudCBjb29raWUocynCoCDCoCDCoCDCoCB8PGJyPg0KwqAg wqAgwqB8IHRoYXQgYXJlIHNldCBTSE9VTEQgY29udGFpbiBUQklEMcKgIMKgIMKgIHzCoCDCoCDC oCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoHwmbHQ7LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tfMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDC oCDCoCDCoHw8YnI+DQrCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAg wqB8PGJyPg0KwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqB8wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgfDxi cj4NCjxicj4NCjxicj4NCmVuZDxicj4NCjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT48L2Rpdj48 L2Rpdj4NCg== --001a1144213067975a052e88ddd4-- From nobody Mon Mar 21 09:23:00 2016 Return-Path: <internet-drafts@ietf.org> X-Original-To: unbearable@ietf.org Delivered-To: unbearable@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE0B12D7BF; Mon, 21 Mar 2016 09:22:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: <i-d-announce@ietf.org> X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321162256.31928.37054.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 09:22:56 -0700 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/VUPMTKp22D-3Yv6vJMZhSafEAho> Cc: unbearable@ietf.org Subject: [Unbearable] I-D Action: draft-ietf-tokbind-https-03.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Mar 2016 16:22:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding of the IETF. Title : Token Binding over HTTP Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Jeff Hodges Filename : draft-ietf-tokbind-https-03.txt Pages : 16 Date : 2016-03-21 Abstract: This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind authentication tokens (such as cookies and OAuth tokens) to a TLS [RFC5246] connection. We describe both _first-party_ as well as _federated_ scenarios. In a first-party scenario, an HTTP server issues a security token (such as a cookie) to a client, and expects the client to send the security token back to the server at a later time in order to authenticate. Binding the token to the TLS connection between client and server protects the security token from theft, and ensures that the security token can only be used by the client that it was issued to. Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS [RFC5246] connection that the client has with a _different_ server than the one issuing the token. This Internet-Draft is a companion document to The Token Binding Protocol [TBPROTO] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tokbind-https-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-https-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 21 09:28:01 2016 Return-Path: <balfanz@google.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 1BC5712D81F for <unbearable@ietfa.amsl.com>; Mon, 21 Mar 2016 09:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 90zKm9p48yel for <unbearable@ietfa.amsl.com>; Mon, 21 Mar 2016 09:27:57 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0ACF12D8E5 for <unbearable@ietf.org>; Mon, 21 Mar 2016 09:27:55 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id l68so128840630wml.1 for <unbearable@ietf.org>; Mon, 21 Mar 2016 09:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=bTfgj1TbJRtD6ZTm69uXDYJuviX+eWX8ADwbl5nBD30=; b=LCbElsZmERSjlj+rtu51JBVzf3y37msklKlt4Wi4sM4zUl72Qc9GU+llb0ZxWk62k0 nYBELdGo8hvYmK3YIlsBGT+YyoSkC1016iNbnKdR0IKHUp9LLBwLSW6z6svxCpqSQ3B3 MH0aqH5SIsI/N7Y84jwIviaFjg8wxGELToks8NQdoWjZwlK638+bCM3v4JFHfeUvaGdK erJlgCUh/J0KXQvKhHsy63RC3W9FYuEt1tZU1lCUQHqrSnSUbGBIwmpdiPe5ofV7JGqJ wtDCQVRO9r2OLvyXZ4b0h/PLt5rPFnQSqx9NEaU2q+Z/w5yWNuQCAyQisvM8zNWg+TCu zaZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=bTfgj1TbJRtD6ZTm69uXDYJuviX+eWX8ADwbl5nBD30=; b=WXebo1rKY8dy4IaU25VDgNpHM8GSbRGOfq1BtPlyF2LUs7pVTyvS/WADR+EamHXfpW l4YD1Lw2u34ZHWyt1FA7QO3HxKZzRgvAvc8QIqacyNoCu7y+lxIKdq/7SOJ8+ruZmVyr 1aer5AF5gwyJzt3fEW/OZ+BNF2jwVazzx1oVFAObBwSMVmwAXR59juTKOGM+1uNeYqlS 9j+sFz4hnxivt0akXh0/FYH1b3plMhYYilC4V9eQxVsY3r8LdQ2Se4AhdGnQuqc90MHR 2aIxIQih4vPvjN9JTQMedp2am1twHht/lAXo7uY/w296ANvx3txO2mcpb3RoFQIql+1g rUhA== X-Gm-Message-State: AD7BkJJ/+RZfCZIZBMgluwZm60X3z5U26og8JHK+IXznF7TQicSp9hfrh2moHOpCqv+J1i5D4J/3guocigWlrEU6 X-Received: by 10.28.22.213 with SMTP id 204mr15573104wmw.12.1458577674274; Mon, 21 Mar 2016 09:27:54 -0700 (PDT) MIME-Version: 1.0 References: <CADHfa2CVYz40CzWhhproL6p-+Ki1FVAdLaSpfTw5zmFUcz8wug@mail.gmail.com> In-Reply-To: <CADHfa2CVYz40CzWhhproL6p-+Ki1FVAdLaSpfTw5zmFUcz8wug@mail.gmail.com> From: Dirk Balfanz <balfanz@google.com> Date: Mon, 21 Mar 2016 16:27:44 +0000 Message-ID: <CADHfa2APY0E5qk-PJgGpTAQfvUCvDyB_9TQ12CoCNcw2q8AwRw@mail.gmail.com> To: Tokbind WG <unbearable@ietf.org> Content-Type: multipart/alternative; boundary=001a114712fc275705052e9194d1 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/7WBva610kJ-lh9KjYO3EnpFcN1I> Subject: Re: [Unbearable] new draft-ietf-tokbind-https draft X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Mar 2016 16:27:59 -0000 --001a114712fc275705052e9194d1 Content-Type: text/plain; charset=UTF-8 This has now been uploaded to the IETF tracker and is available at https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ Dirk. On Sun, Mar 20, 2016 at 10:52 PM Dirk Balfanz <balfanz@google.com> wrote: > Hi there, > > draft -03 of draft-ietf-tokbind-https is available at > https://github.com/TokenBinding/Internet-Drafts. > > https://datatracker.ietf.org seems to be down right now and I have about > 19 more hours before the IETF 95 deadline. I hope that I will be able to > upload the draft to the IETF tracking site by then. > > Changes since the last version: > > - The header has a Sec- prefix again. > > - There is a cool diagram showing the redirect flow for the federation > case (thanks Jeff!) > > - There is a new expanded privacy considerations section. > > - Some language tweaks to make it clearer how/when to use referred token > bindings. > > Dirk. > > --001a114712fc275705052e9194d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">This has now been uploaded to the IETF tracker and is avai= lable at=C2=A0<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-tokbin= d-https/">https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/</a><di= v><br></div><div>Dirk.</div><div><br></div></div><br><div class=3D"gmail_qu= ote"><div dir=3D"ltr">On Sun, Mar 20, 2016 at 10:52 PM Dirk Balfanz <<a = href=3D"mailto:balfanz@google.com">balfanz@google.com</a>> wrote:<br></d= iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left= :1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Hi there,=C2=A0</di= v><div><br></div><div>draft -03 of=C2=A0draft-ietf-tokbind-https is availab= le at <a href=3D"https://github.com/TokenBinding/Internet-Drafts" target=3D= "_blank">https://github.com/TokenBinding/Internet-Drafts</a>.=C2=A0</div><d= iv><br></div><div><a href=3D"https://datatracker.ietf.org" target=3D"_blank= ">https://datatracker.ietf.org</a>=C2=A0seems to be down right now and I ha= ve about 19 more hours before the IETF 95 deadline. I hope that I will be a= ble to upload the draft to the IETF tracking site by then.</div><div><br></= div><div>Changes since the last version:</div><div><br></div><div>- The hea= der has a Sec- prefix again.</div><div><br></div><div>- There is a cool dia= gram showing the redirect flow for the federation case (thanks Jeff!)</div>= <div><br></div><div>- There is a new expanded privacy considerations sectio= n.</div><div><br></div><div>- Some language tweaks to make it clearer how/w= hen to use referred token bindings.</div></div><div dir=3D"ltr"><div><br></= div><div>Dirk.</div><div><br></div></div></blockquote></div> --001a114712fc275705052e9194d1-- From nobody Mon Mar 21 13:41:24 2016 Return-Path: <nharper@google.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 DD48712D611 for <unbearable@ietfa.amsl.com>; Mon, 21 Mar 2016 13:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 EmsKYobzP9F9 for <unbearable@ietfa.amsl.com>; Mon, 21 Mar 2016 13:41:18 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E347F12DB59 for <unbearable@ietf.org>; Mon, 21 Mar 2016 13:41:17 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id e185so229213469vkb.1 for <unbearable@ietf.org>; Mon, 21 Mar 2016 13:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CdFQGiyd+wnH7MU1Giet4FYeiJwA4of4sZkXMEqPDsU=; b=hJ19pELSx+Xhb04cTpdn2jLAGfOb4ms+DT8GXKFolYyKqAgbW/rF/1WXxJBAsFtDUZ EO3UuIU75s4/O5njOJRnFSncV0VQFub9Ky+9/mIvaPnBKdCVgimLruyxLOtk2PjoRK4K ynuvqFbjL1lWPhKKuzy2YyENpCCmN2XgQCGiokN11Cvvh3U8oltMxM0o4WZ8UDzsTmxp Ypnxt8qid02GX+PAXDx08RvuKTBl110SCy1R+6TryNQCk2OExAN/qUwDNzFZHS/CJaZc bsRvRV+/YkI+fubn8rx8lJpRtfkv4Y6jDtGtKXSiqjaOM9NltyHEnHK5RxCuXjS72Svy 7Dhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CdFQGiyd+wnH7MU1Giet4FYeiJwA4of4sZkXMEqPDsU=; b=kN4wNdl2XAAnCvFh0Wvooc4zA8hSC+kVH20n5mL/KKfAFQ4lQ7eFJ9rKUU2TPDJ/SE kaXm0z3qiVcL7YDwdDSFWz8zJmY0HHdvfTBTYLgGtsxoiKBXnF7oJGCO4iW0TnNbqDX5 jrdy0s0U2sfLfKIalZZhvLzo2726zPRz8kvcjrKLCnJELu5P38Jt8vYL/vR/Cx+5AN3R OYayTTk7nAtuKaXYbKm3DuWvh6i0n224/TlForUC4MpKamMBKqzkBSDzVmLwd3xnBNG7 fyCxA2sb1dzd68IP+9BPGoV8IZ1bLZvD/Ar24bXmeAYyDLnD4tC4tUNxhrAG2Bc4BjRv qLaQ== X-Gm-Message-State: AD7BkJLFnMfbr89tpXHalj1ohSOqc0EuCGVrujpchdrCuKB5TaGvBdqeZ+/AAMkN6DwtBobydw3PpdBfG6CGgk7R X-Received: by 10.31.182.143 with SMTP id g137mr32790831vkf.45.1458592876653; Mon, 21 Mar 2016 13:41:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.76.198 with HTTP; Mon, 21 Mar 2016 13:40:57 -0700 (PDT) In-Reply-To: <CADHfa2ACdV_mdm-R-23PajYUzHJ8nG2QN680aXxN2zqKLtB0Vw@mail.gmail.com> References: <56EF4B9B.7000609@KingsMountain.com> <CADHfa2ACdV_mdm-R-23PajYUzHJ8nG2QN680aXxN2zqKLtB0Vw@mail.gmail.com> From: Nick Harper <nharper@google.com> Date: Mon, 21 Mar 2016 13:40:57 -0700 Message-ID: <CACdeXiLKjN3-ePh=PCX_sh8+cDAyEhJxa=mxM543OL6KQFUGvg@mail.gmail.com> To: Dirk Balfanz <balfanz@google.com> Content-Type: multipart/alternative; boundary=001a114386ac498cc4052e951ee7 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/p1gjmGFZFgUiDcNlT0md5qMw-fU> Cc: IETF Tokbind WG <unbearable@ietf.org>, David Benjamin <davidben@google.com>, =JeffH <Jeff.Hodges@kingsmountain.com> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Mar 2016 20:41:23 -0000 --001a114386ac498cc4052e951ee7 Content-Type: text/plain; charset=UTF-8 My understanding of the problem in figure 1 is that 1) in the redirect from TC2 to TP3, the referred TBID is is TBID2, while the redirect uri is to TC1, and 2) when TP3 redirects to TP4, somehow TBID2 needs to be relayed. Please correct me if that is wrong or incomplete. One way to solve problem 2 is to treat the TP3->TP4 redirect like the "identity-as-a-service" scenario that Dirk mentioned. Instead of TP4 redirecting to TC1, it can create a token to be consumed by TP3, and redirect to TP3, which will then create a token to send back to TC1. For problem 1, I am going to assume that TC1 and TC2 are cooperating. The easiest way to fix this is to have TC2 transmit to TC1 out-of-band what TBID2 is so that TC1 can verify it. Here's another solution (for both problems) that I think could work (credit to David Benjamin for initially proposing it). I'm going to use OpenID Connect terminology here, but I imagine this could be adapted for other federated protocols. When the clients makes the OIDC authentication request, it includes the TBID in the nonce query param. Regardless of what happens in terms of redirects from TP3->TP4 (or anything else), the token that the client sends back to the token consumer will have the TBID in the nonce claim. For the case of TC1 redirects to TC2 which then does the redirect for the authentication request, TC1 can pass the TBID to TC2 in a query param. By moving the referred Token Binding ID from the tbproto (and tbhttps) to the federation protocol, it simplifies the setup and implementation of both. User-agents no longer have to handle the Include-Referer-Token-Binding-ID header; identity providers don't have to do anything additional with creating a new claim and plumbing the TBID from the Sec-Token-Binding header into the new claim; the token consumer doesn't have to worry about whether the token provider supports token binding (or the same key params), as it will always get back a bound token. The only downside I see (so far) to this approach is that the token provider has no way to verify that the client has possession of the private key for the referred Token Binding ID. What security benefits are provided by the token provider verifying proof of possession? As far as I could tell, it could open up a token injection attack, but that would be thwarted by the federation protocol's CSRF protection. On Sun, Mar 20, 2016 at 11:03 PM, Dirk Balfanz <balfanz@google.com> wrote: > > > On Sun, Mar 20, 2016 at 6:17 PM =JeffH <Jeff.Hodges@kingsmountain.com> > wrote: > >> >> On 3/7/16, 4:24 PM nharper@google.com> wrote: >> >>> >> >>> If a client receives an "Include-Referer-Token-Binding-ID" header in >> >>> response to a request that already had a referred TBID in the >> >>> TokenBindingMessage, should it include both of those TBIDs as referred >> >>> TBIDs in the next request? >> >>> >> >>> I.e. >> >>> - client sends request to server A w/ provided TBID A >> >>> - gets back Include-Referer-Token-Binding-ID header on a redirect to B >> >>> - client sends request to B w/ provided TBID B, referred TBID A >> >>> - gets back Include-Referer-Token-Binding-ID header on a redirect to C >> >>> Possible behaviors: >> >>> i) client sends request to C w/ provided TBID C, referred TBID B, >> >>> referred TBID A >> >>> ii) client sends request to C w/ provided TBID C, referred TBID B >> >>> >> >>> iii) client sends request to C w/ provided TBID C, referred TBID A, >> >>> referred TBID B >> >> >> On Fri, 11 Mar 2016 Dirk replied: >> > The intended semantics in the current spec is ii). >> >> what you mean that is that the TokenBindingMessage (TBMSG) contains only >> two >> TokenBindings in this case, and the TBMSG is included in an HTTP request >> from the client to server only when satisfying a redirect that is crossing >> "functional boundaries" as noted below, yes? >> >> [ "current spec" discussed herein = -tokbind-https-02 aka HTTPSTB, >> other specs.. >> -tokbind-negotiation-02 aka TBNEGO >> -tokbind-protocol-04 aka TBPROTO ] >> >> On Fri, 11 Mar 2016 Dirk further replied: >> > I believe that covers all the use cases that you're describing: Let's >> first >> > consider the case where there is one Relying Party, and one Identity >> > Provider. The RP might go through a bunch of redirects before ultimately >> > handing things off to the IdP, and the IdP might go through a bunch of >> > redirects before ultimately handling the RP request. Same on the way >> back >> > from the IdP to the RP. >> >> understood. >> >> > The one redirect where the referred token binding is necessary is the >> > redirect that crosses functional boundaries: from the RP to the IdP. >> >> agreed. >> >> > If the >> > first endpoint at the IdP isn't the one that is processing the RP >> request >> > (because, say, it's the old one and it's now redirecting to the new >> one), >> > that endpoint needs to encode the information it learns (i.e., what is >> the >> > public key that the client is using with the RP) in some way (which can >> be >> > proprietary to the IdP) and pass that along as the request is handed >> off. >> >> agreed that the above works in the case where the Token Consumer (RP) that >> redirects to IdP1 is the intended recipient of the eventual token-bound ID >> token. >> >> However, federation protocols have a notion of a 'return address' that's >> typically included in the RP's 'authn request'. E.g., in OIDC it is the >> "redirect_uri" [1], and in SAML the equivalent is the >> "AssertionConsumerServiceURL" [2]. >> >> Upon issuance of the security token, the IDP redirects the UA to the >> specified 'return address', which does not necessarily point to the RP >> entity that redirected the UA to the IDP, nor even any of the entities in >> the RP's "redirect chain". >> >> So there needs to be some means for the IDP to receive the _correct_ >> referred TBID to include in the security token it generates and then >> returns >> -- this is not necessarily the RP entity that redirected to the IDP. A few >> ways to address this in HTTPSTB perhaps are.. >> >> We could mandate in HTTPSTB that the receiving RP entity (aka Token >> Consumer) MUST have the same eTLD+1 as the RP entity that redirected (aka >> "handed off") to the IDP. (see below for discussion of TB scoping rules) >> >> Or, we could attempt to devise a means for the RP entities to signal the >> correct referred TBID to the IDP via HTTPSTB/TBPROTO. >> >> Or, we could punt the problem to deployers and say something like "the >> referred TBID in the TBMSG MUST map to the entity specified in the authn >> request's return address -- i.e., the TBID included in the issued security >> token by the IDP needs to match the client's TLS connection with the >> entity >> who will _receive_ the security token, even if the latter entity is not >> the >> one to redirect to the IDP" -- it is implementers' and deployers' >> responsibility to get this right. >> >> See [figure 1] at end below. >> >> >> > On the way back, after the IdP redirects back to the RP, the RP just >> needs >> > to make sure that one of the endpoints in the redirect chain is on the >> same >> > eTLD+1 as the endpoint that did the hand-off to the IdP, so it can >> process >> > the IdP response there. >> >> hm, perhaps there are some issues here.. >> >> * with regards to processing the IDP response ... is the above-stated >> eTLD+1 >> requirement because the client aka user agent (UA) will use the same >> provided TBID with servers whose hostnames map to the same eTLD+1 ? >> -tokbind-protocol aka TBPROTO says.. >> >> ... In order to prevent cooperating servers from linking user >> identities, different keys SHOULD be used by the client for >> connections to different servers, according to the token scoping >> rules of the application protocol. >> >> ..so it seems we are assuming (in HTTPSTB) that HTTPS clients map the >> servers to eTLD+1 when generating their TB key pairs, and afix >> Token-Binding >> header fields to their HTTP msgs per said mapping, yes? >> >> some thoughts/issues.. >> >> - eTLD and eTLD+1 are not mentioned in HTTPSTB >> >> - HTTPSTB does not explicitly define which particular "token scoping >> rules" impls must adhere to. Is the client-side TBID >> storage-and-mapping >> model intended to map only to domain names, and in this case be >> "domain >> lowered" to eTLD+1 (modulo publicsuffix.org) similarly to how >> cookies' >> domain-matching works? [3][4] >> > > Just added language to that effect in a new "Privacy Considerations" > section in -03. Take a look and see whether you like it / have some ideas > to improve on it. > > >> >> - what about servers that are identified by IP address? Note that in >> HSTS >> we punted on supporting servers identified by IP addresses [5]. Tho, >> in >> RFC6265 a server addressed by IP address can set cookies, but only for >> itself (i.e., the host-only flag is set to true [6]; i.e., cookie >> "domain lowering" is undefined for IP addresses). Is >> allowing/disallowing a host-only IP address-based TBID mapping >> something we should consider generally for TBPROTO, or >> just specifically consider for HTTSTB? >> > > I'd say that servers identified by IP addresses will get keys scoped to > that exact IP address - just like cookies. I think it belongs in HTTPSTB as > a SHOULD for web browsers. > > Dirk. > > >> >> >> > Next, let's consider what happens if there are multiple IdP's involved, >> say >> > something like rp.com -> identity-as-a-service.com -> idp.com. In that >> > case, identity-as-a-service.com acts like an IdP to rp.com, and as an >> RP to >> > idp.com, so we play the game described above twice. It wouldn't make >> sense >> > here if idp.com somehow knew what public key the client is using with >> rp.com >> > - it's useless information. In a scenario like this, idp.com needs to >> > strongly authenticate the client to identity-as-a-service.com, not to >> rp.com >> >> Agreed, in this particular, tightly-constrained scenario. >> >> HTH, >> >> =JeffH >> >> >> [1] https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest >> >> [2] https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf >> >> [3] https://tools.ietf.org/html/rfc6265#section-5.1.3 >> >> [4] http://identitymeme.org/http-cookie-processing-algorithm-etlds/ >> >> [5] https://tools.ietf.org/html/rfc6797#appendix-A >> >> [6] https://tools.ietf.org/html/rfc6265#section-5.3 - step 6. >> >> >> >> [figure 1] >> >> What: Analysis of redirect hops at RP aka TC and at IDP aka TP >> >> Legend: >> >> EKM: TLS Exported Keying Material [RFC5705] >> >> {EKMn}Ksm: EKM for server "n", signed by private key of TBID "m", >> where "n" must represent server receiving the ETBMSG, >> if a conveyed TB's type is provided_token_binding, then >> m = n, else if TB's type is referred_token_binding, then >> m != n. E.g., see step 1b in diagram below. >> >> ETBMSG: "Token-Binding" HTTP header field conveying an >> EncodedTokenBindingMessage, in turn conveying >> TokenBinding (TB)struct(s), e.g.: >> ETBMSG[[TB]] or ETBMSG[[TB1],[TB2]] >> >> ID Token: the "ID Token" in OIDC, it is the semantic equivalent >> of a SAML "authentication assertion". "ID Token w/TBIDn" >> denotes a "token bound" ID Token containing TBIDn. >> >> Ks & Kp: private (aka secret) key, and public key, respectively, >> of client-side Token Binding key pair >> >> OIDC: Open ID Connect >> >> TB: TokenBinding struct containing signed EKM, TBID, and >> TB type, e.g.: [{EKM1}Ks1,TBID1,provided_token_binding] >> >> TBIDn: Token Binding ID for client and server n's token-bound >> TLS association. TBIDn contains Kpn. >> >> >> >> Token Consumer, Token Provider, >> aka: aka: >> OpenID Client, OpenID Provider, >> Client, OIDC Relying Party, OIDC Provider, >> aka: SAML Relying Party SAML Identity >> Provider >> User Agent [ servers "1", "2" ] [ servers "3", "4" ] >> +--------+ +-----+ +-----+ +-----+ +-----+ >> | Client | | TC1 | | TC2 | | TP3 | | TP4 | >> +--------+ +-----+ +-----+ +-----+ +-----+ >> | | | | | >> | | | | | >> | 0. Client interacts w/TC1 | | >> | over HTTPS, establishes Ks1 & Kp1, TBID1 | | >> | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | | >> |------------------------------>| | | | >> | | | | | >> | | | | | >> | 1a. redirect to TC2 for TC-specific reasons | | >> | any security-relevant cookies should contain TBID1 | | >> +<- - - - - - - - - - - - - - - - | | | | >> . | | | | | >> +----------------------------------------->| | | >> | 1b. establishes Ks2 & Kp2, TBID2 | | | >> | ETBMSG[[{EKM2}Ks2,TBID2,provided_token_binding]] | | >> | | | | | >> | | | | | >> | | | | | >> | 2a. OIDC ID Token request, | | | | >> | aka "Authentication Request" w/ redirect_uri=TC1; <-- note well >> | conveyed w/ HTTP response header field of: >> | Include-Referer-Token-Binding-ID:true | | >> | any security-relevant cookies should contain TBID2 | | >> +<- - - - - - - - - - - - - - - - - - - - -| | | >> . | (redirect to TP via 301, 302, | | | | >> . | 303, 307, or 308) | | | | >> . | | | | | >> +----------------------------------------------------->| | >> | 2b. client opens HTTPS w/ TP3, | | | >> | establishes Ks3, Kp3, TBID3; | | | >> | sends GET or POST with | | | >> | ID Token request w/ redirect_uri=TC1, | | | >> | ETBMSG[[{EKM3}Ks3,TBID3,provided_token_binding], | >> | [{EKM3}Ks2,TBID2,referred_token_binding]] <-- but ID Tok >> request >> | | | <-- is for TC1 >> | | | >> | | | | | >> | | | | | >> | 3a. redirect to TP4 for TP-specific reasons | | >> | any security-relevant cookies should contain TBID3 | | >> +<- - - - - - - - - - - - - - - - - - - - - - - - - - -| | >> . | | | | | >> +--------------------------------------------------------------->| >> | 3b. client opens HTTPS w/ TP4, | | | >> | establishes Ks4 & Kp4, TBID4 | | | >> | ETBMSG[[{EKM4}Ks4,TBID4,provided_token_binding]] | | >> | *** as well as the ID Token request w/ redirect_uri=TC1; >> | *** also, somehow conveys TBID2 to TP4 ? >> | | | | | >> | | | | | >> | | | | | >> | 4. user authentication (if applicable, | | >> | methods vary, particulars are out of scope) | | >> |<============================================================>| >> | (TP generates ID Token for TC1 containing TBID1 - TP4 has only >> TBID2 >> | also set cookie(s) containing TBID4 and/or TBID3 >> | details vary) | | | | >> | | | | | >> | | | | | >> | | | | | >> | 5a. ID Token issued for TC1, containing TBID1, <-- how do this if >> | conveyed via OIDC "Authentication Response" <-- don't have >> TBID1? >> +<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| >> . | (redirect to TC1) | | | | >> . | | | | | >> +-------------------------------->| | | | >> | 5b. HTTPS GET or POST with | | | | >> | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | | >> | conveying Authn Reponse containing ID Token w/TBID1, | >> | issued for TC1 | >> | | | | | >> | | | | | >> | | | | | >> | | | | | >> | 6. user is signed-on, any security-relevant cookie(s) | >> | that are set SHOULD contain TBID1 | | | >> |<------------------------------| | | | >> | | | | | >> | | | | | >> >> >> end >> >> >> > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --001a114386ac498cc4052e951ee7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">My understanding of the problem in figure 1 is that 1) in = the redirect from TC2 to TP3, the referred TBID is is TBID2, while the redi= rect uri is to TC1, and 2) when TP3 redirects to TP4, somehow TBID2 needs t= o be relayed. Please correct me if that is wrong or incomplete.<div><br></d= iv><div>One way to solve problem 2 is to treat the TP3->TP4 redirect lik= e the "identity-as-a-service" scenario that Dirk mentioned. Inste= ad of TP4 redirecting to TC1, it can create a token to be consumed by TP3, = and redirect to TP3, which will then create a token to send back to TC1.</d= iv><div><br></div><div>For problem 1, I am going to assume that TC1 and TC2= are cooperating. The easiest way to fix this is to have TC2 transmit to TC= 1 out-of-band what TBID2 is so that TC1 can verify it.</div><div><br></div>= <div>Here's another solution (for both problems) that I think could wor= k (credit to David Benjamin for initially proposing it). I'm going to u= se OpenID Connect terminology here, but I imagine this could be adapted for= other federated protocols. When the clients makes the OIDC authentication = request, it includes the TBID in the nonce query param. Regardless of what = happens in terms of redirects from TP3->TP4 (or anything else), the toke= n that the client sends back to the token consumer will have the TBID in th= e nonce claim. For the case of TC1 redirects to TC2 which then does the red= irect for the authentication request, TC1 can pass the TBID to TC2 in a que= ry param.</div><div><br></div><div>By moving the referred Token Binding ID = from the tbproto (and tbhttps) to the federation protocol, it simplifies th= e setup and implementation of both. User-agents no longer have to handle th= e Include-Referer-Token-Binding-ID header; identity providers don't hav= e to do anything additional with creating a new claim and plumbing the TBID= from the Sec-Token-Binding header into the new claim; the token consumer d= oesn't have to worry about whether the token provider supports token bi= nding (or the same key params), as it will always get back a bound token.</= div><div><br></div><div>The only downside I see (so far) to this approach i= s that the token provider has no way to verify that the client has possessi= on of the private key for the referred Token Binding ID. What security bene= fits are provided by the token provider verifying proof of possession? As f= ar as I could tell, it could open up a token injection attack, but that wou= ld be thwarted by the federation protocol's CSRF protection.</div></div= ><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Mar 20, = 2016 at 11:03 PM, Dirk Balfanz <span dir=3D"ltr"><<a href=3D"mailto:balf= anz@google.com" target=3D"_blank">balfanz@google.com</a>></span> wrote:<= br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left= :1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br><div class=3D"gm= ail_quote"><div><div class=3D"h5"><div dir=3D"ltr">On Sun, Mar 20, 2016 at = 6:17 PM =3DJeffH <<a href=3D"mailto:Jeff.Hodges@kingsmountain.com" targe= t=3D"_blank">Jeff.Hodges@kingsmountain.com</a>> wrote:<br></div><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex">>> On 3/7/16, 4:24 PM <a href=3D"mailto:nharpe= r@google.com" target=3D"_blank">nharper@google.com</a>> wrote:<br> >>><br> >>> If a client receives an "Include-Referer-Token-Binding-ID= " header in<br> >>> response to a request that already had a referred TBID in the<= br> >>> TokenBindingMessage, should it include both of those TBIDs as = referred<br> >>> TBIDs in the next request?<br> >>><br> >>> I.e.<br> >>> - client sends request to server A w/ provided TBID A<br> >>> - gets back Include-Referer-Token-Binding-ID header on a redir= ect to B<br> >>> - client sends request to B w/ provided TBID B, referred TBID = A<br> >>> - gets back Include-Referer-Token-Binding-ID header on a redir= ect to C<br> >>> Possible behaviors:<br> >>> i) client sends request to C w/ provided TBID C, referred TBID= B,<br> >>> referred TBID A<br> >>> ii) client sends request to C w/ provided TBID C, referred TBI= D B<br> >>><br> >>> iii) client sends request to C w/ provided TBID C, referred TB= ID A,<br> >>> referred TBID B<br> <br> <br> On Fri, 11 Mar 2016 Dirk replied:<br> > The intended semantics in the current spec is=C2=A0 ii).<br> <br> what you mean that is that the TokenBindingMessage (TBMSG) contains only tw= o<br> TokenBindings in this case, and the TBMSG is included in an HTTP request<br= > from the client to server only when satisfying a redirect that is crossing<= br> "functional boundaries" as noted below, yes?<br> <br> [ "current spec" discussed herein =3D -tokbind-https-02 aka HTTPS= TB,<br> =C2=A0 =C2=A0other specs..<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -tokbind-neg= otiation-02 aka TBNEGO<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -tokbind-pro= tocol-04 aka TBPROTO ]<br> <br> On Fri, 11 Mar 2016 Dirk further replied:<br> > I believe that covers all the use cases that you're describing: Le= t's first<br> > consider the case where there is one Relying Party, and one Identity<b= r> > Provider. The RP might go through a bunch of redirects before ultimate= ly<br> > handing things off to the IdP, and the IdP might go through a bunch of= <br> > redirects before ultimately handling the RP request. Same on the way b= ack<br> > from the IdP to the RP.<br> <br> understood.<br> <br> > The one redirect where the referred token binding is necessary is the<= br> > redirect that crosses functional boundaries: from the RP to the IdP.<b= r> <br> agreed.<br> <br> > If the<br> > first endpoint at the IdP isn't the one that is processing the RP = request<br> > (because, say, it's the old one and it's now redirecting to th= e new one),<br> > that endpoint needs to encode the information it learns (i.e., what is= the<br> > public key that the client is using with the RP) in some way (which ca= n be<br> > proprietary to the IdP) and pass that along as the request is handed o= ff.<br> <br> agreed that the above works in the case where the Token Consumer (RP) that<= br> redirects to IdP1 is the intended recipient of the eventual token-bound ID<= br> token.<br> <br> However, federation protocols have a notion of a 'return address' t= hat's<br> typically included in the RP's 'authn request'. E.g., in OIDC i= t is the<br> "redirect_uri" [1], and in SAML the equivalent is the<br> "AssertionConsumerServiceURL" [2].<br> <br> Upon issuance of the security token, the IDP redirects the UA to the<br> specified 'return address', which does not necessarily point to the= RP<br> entity that redirected the UA to the IDP, nor even any of the entities in<b= r> the RP's "redirect chain".<br> <br> So there needs to be some means for the IDP to receive the _correct_<br> referred TBID to include in the security token it generates and then return= s<br> -- this is not necessarily the RP entity that redirected to the IDP. A few<= br> ways to address this in HTTPSTB perhaps are..<br> <br> We could mandate in HTTPSTB that the receiving RP entity (aka Token<br> Consumer) MUST have the same eTLD+1 as the RP entity that redirected (aka<b= r> "handed off") to the IDP. (see below for discussion of TB scoping= rules)<br> <br> Or, we could attempt to devise a means for the RP entities to signal the<br= > correct referred TBID to the IDP via HTTPSTB/TBPROTO.<br> <br> Or, we could punt the problem to deployers and say something like "the= <br> referred TBID in the TBMSG MUST map to the entity specified in the authn<br= > request's return address -- i.e., the TBID included in the issued secur= ity<br> token by the IDP needs to match the client's TLS connection with the en= tity<br> who will _receive_ the security token, even if the latter entity is not the= <br> one to redirect to the IDP" -- it is implementers' and deployers&#= 39;<br> responsibility to get this right.<br> <br> See [figure 1] at end below.<br> <br> <br> > On the way back, after the IdP redirects back to the RP, the RP just n= eeds<br> > to make sure that one of the endpoints in the redirect chain is on the= same<br> > eTLD+1 as the endpoint that did the hand-off to the IdP, so it can pro= cess<br> > the IdP response there.<br> <br> hm, perhaps there are some issues here..<br> <br> * with regards to processing the IDP response ... is the above-stated eTLD+= 1<br> requirement because the client aka user agent (UA) will use the same<br> provided TBID with servers whose hostnames map to the same eTLD+1 ?<br> -tokbind-protocol aka TBPROTO says..<br> <br> =C2=A0 =C2=A0 ... In order to prevent cooperating servers from linking user= <br> =C2=A0 =C2=A0 identities, different keys SHOULD be used by the client for<b= r> =C2=A0 =C2=A0 connections to different servers, according to the token scop= ing<br> =C2=A0 =C2=A0 rules of the application protocol.<br> <br> ..so it seems we are assuming (in HTTPSTB) that HTTPS clients map the<br> servers to eTLD+1 when generating their TB key pairs, and afix Token-Bindin= g<br> header fields to their HTTP msgs per said mapping, yes?<br> <br> some thoughts/issues..<br> <br> =C2=A0 - eTLD and eTLD+1 are not mentioned in HTTPSTB<br> <br> =C2=A0 - HTTPSTB does not explicitly define which particular "token sc= oping<br> =C2=A0 =C2=A0 rules" impls must adhere to. Is the client-side TBID sto= rage-and-mapping<br> =C2=A0 =C2=A0 model intended to map only to domain names, and in this case = be "domain<br> =C2=A0 =C2=A0 lowered" to eTLD+1 (modulo <a href=3D"http://publicsuffi= x.org" rel=3D"noreferrer" target=3D"_blank">publicsuffix.org</a>) similarly= to how cookies'<br> =C2=A0 =C2=A0 domain-matching works? [3][4]<br></blockquote><div><br></div>= </div></div><div>Just added language to that effect in a new "Privacy = Considerations" section in -03. Take a look and see whether you like i= t / have some ideas to improve on it.</div><span class=3D""><div>=C2=A0</di= v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 1px #ccc solid;padding-left:1ex"> <br> =C2=A0 - what about servers that are identified by IP address? Note that in= HSTS<br> =C2=A0 =C2=A0 we punted on supporting servers identified by IP addresses [5= ]. Tho, in<br> =C2=A0 =C2=A0 RFC6265 a server addressed by IP address can set cookies, but= only for<br> =C2=A0 =C2=A0 itself (i.e., the host-only flag is set to true [6]; i.e., co= okie<br> =C2=A0 =C2=A0 "domain lowering" is undefined for IP addresses). I= s<br> =C2=A0 =C2=A0 allowing/disallowing a host-only IP address-based TBID mappin= g<br> =C2=A0 =C2=A0 something=C2=A0 we should consider generally for TBPROTO, or<= br> =C2=A0 =C2=A0 just specifically consider for HTTSTB?<br></blockquote><div><= br></div></span><div>I'd say that servers identified by IP addresses wi= ll get keys scoped to that exact IP address - just like cookies. I think it= belongs in HTTPSTB as a SHOULD for web browsers.=C2=A0</div><span class=3D= "HOEnZb"><font color=3D"#888888"><div><br></div><div>Dirk.</div></font></sp= an><div><div class=3D"h5"><div>=C2=A0</div><blockquote class=3D"gmail_quote= " style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> <br> > Next, let's consider what happens if there are multiple IdP's = involved, say<br> > something like <a href=3D"http://rp.com" rel=3D"noreferrer" target=3D"= _blank">rp.com</a> -> <a href=3D"http://identity-as-a-service.com" rel= =3D"noreferrer" target=3D"_blank">identity-as-a-service.com</a> -> <a hr= ef=3D"http://idp.com" rel=3D"noreferrer" target=3D"_blank">idp.com</a>. In = that<br> > case, <a href=3D"http://identity-as-a-service.com" rel=3D"noreferrer" = target=3D"_blank">identity-as-a-service.com</a> acts like an IdP to <a href= =3D"http://rp.com" rel=3D"noreferrer" target=3D"_blank">rp.com</a>, and as = an RP to<br> > <a href=3D"http://idp.com" rel=3D"noreferrer" target=3D"_blank">idp.co= m</a>, so we play the game described above twice. It wouldn't make sens= e<br> > here if <a href=3D"http://idp.com" rel=3D"noreferrer" target=3D"_blank= ">idp.com</a> somehow knew what public key the client is using with <a href= =3D"http://rp.com" rel=3D"noreferrer" target=3D"_blank">rp.com</a><br> > - it's useless information. In a scenario like this, <a href=3D"ht= tp://idp.com" rel=3D"noreferrer" target=3D"_blank">idp.com</a> needs to<br> > strongly authenticate the client to <a href=3D"http://identity-as-a-se= rvice.com" rel=3D"noreferrer" target=3D"_blank">identity-as-a-service.com</= a>, not to <a href=3D"http://rp.com" rel=3D"noreferrer" target=3D"_blank">r= p.com</a><br> <br> Agreed, in this particular, tightly-constrained scenario.<br> <br> HTH,<br> <br> =3DJeffH<br> <br> <br> [1] <a href=3D"https://openid.net/specs/openid-connect-core-1_0.html#AuthRe= quest" rel=3D"noreferrer" target=3D"_blank">https://openid.net/specs/openid= -connect-core-1_0.html#AuthRequest</a><br> <br> [2] <a href=3D"https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0= -os.pdf" rel=3D"noreferrer" target=3D"_blank">https://docs.oasis-open.org/s= ecurity/saml/v2.0/saml-core-2.0-os.pdf</a><br> <br> [3] <a href=3D"https://tools.ietf.org/html/rfc6265#section-5.1.3" rel=3D"no= referrer" target=3D"_blank">https://tools.ietf.org/html/rfc6265#section-5.1= .3</a><br> <br> [4] <a href=3D"http://identitymeme.org/http-cookie-processing-algorithm-etl= ds/" rel=3D"noreferrer" target=3D"_blank">http://identitymeme.org/http-cook= ie-processing-algorithm-etlds/</a><br> <br> [5] <a href=3D"https://tools.ietf.org/html/rfc6797#appendix-A" rel=3D"noref= errer" target=3D"_blank">https://tools.ietf.org/html/rfc6797#appendix-A</a>= <br> <br> [6] <a href=3D"https://tools.ietf.org/html/rfc6265#section-5.3" rel=3D"nore= ferrer" target=3D"_blank">https://tools.ietf.org/html/rfc6265#section-5.3</= a> - step 6.<br> <br> <br> <br> [figure 1]<br> <br> What: Analysis of redirect hops at RP aka TC and at IDP aka TP<br> <br> Legend:<br> <br> =C2=A0 =C2=A0EKM:=C2=A0 =C2=A0 =C2=A0 =C2=A0TLS Exported Keying Material [R= FC5705]<br> <br> =C2=A0 =C2=A0{EKMn}Ksm: EKM for server "n", signed by private key= of TBID "m",<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 where "n" must r= epresent server receiving the ETBMSG,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if a conveyed TB's typ= e is provided_token_binding, then<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m =3D n, else if TB's = type is referred_token_binding, then<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m !=3D n. E.g., see step 1= b in diagram below.<br> <br> =C2=A0 =C2=A0ETBMSG:=C2=A0 =C2=A0 "Token-Binding" HTTP header fie= ld conveying an<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 EncodedTokenBindingMessage= , in turn conveying<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TokenBinding (TB)struct(s)= , e.g.:<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ETBMSG[[TB]] or ETBMSG[[TB= 1],[TB2]]<br> <br> =C2=A0 =C2=A0ID Token:=C2=A0 the "ID Token" in OIDC, it is the se= mantic equivalent<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of a SAML "authentica= tion assertion". "ID Token w/TBIDn"<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 denotes a "token boun= d" ID Token containing TBIDn.<br> <br> =C2=A0 =C2=A0Ks & Kp:=C2=A0 =C2=A0private (aka secret) key, and public = key, respectively,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of client-side Token Bindi= ng key pair<br> <br> =C2=A0 =C2=A0OIDC:=C2=A0 =C2=A0 =C2=A0 Open ID Connect<br> <br> =C2=A0 =C2=A0TB:=C2=A0 =C2=A0 =C2=A0 =C2=A0 TokenBinding struct containing = signed EKM, TBID, and<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TB type, e.g.: [{EKM1}Ks1,= TBID1,provided_token_binding]<br> <br> =C2=A0 =C2=A0TBIDn:=C2=A0 =C2=A0 =C2=A0Token Binding ID for client and serv= er n's token-bound<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TLS association. TBIDn con= tains Kpn.<br> <br> <br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Token Consumer,=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Token Provider,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 aka:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0aka:<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OpenID Client,=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0OpenID Provider,<br> Client,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 OIDC Relying Party,=C2=A0 =C2=A0 OIDC Provider,<br> aka:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0SAML Relying Party=C2=A0 =C2=A0 =C2=A0SAML Ident= ity Provider<br> User Agent=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0[ servers "1", "2" ]=C2=A0 =C2=A0[ servers= "3", "4" ]<br> +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+-----+=C2=A0 +-----+=C2=A0 =C2=A0 =C2=A0+-----+=C2=A0 = =C2=A0+-----+<br> | Client |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| TC1 |=C2=A0 | TC2 |=C2=A0 =C2=A0 =C2=A0| TP3 |=C2=A0 = =C2=A0| TP4 |<br> +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+-----+=C2=A0 +-----+=C2=A0 =C2=A0 =C2=A0+-----+=C2=A0 = =C2=A0+-----+<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 0. Client interacts w/TC1=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| over HTTPS, establishes Ks1 & Kp1, TBID1=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]]=C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|------------------------------>|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 1a. redirect to TC2 for TC-specific reasons=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| any security-relevant cookies should contain TBID1 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0+<- - - - - - - - - - - - - - - - |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|<br> =C2=A0 =C2=A0. |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|<br> =C2=A0 =C2=A0+----------------------------------------->|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 1b. establishes Ks2 & Kp2, TBID2=C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| ETBMSG[[{EKM2}Ks2,TBID2,provided_token_binding]]=C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 2a. OIDC ID Token request,=C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| aka "Authentication Request" w/ redirect_ur= i=3DTC1;=C2=A0 <-- note well<br> =C2=A0 =C2=A0 =C2=A0| conveyed w/ HTTP response header field of:<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0Include-Referer-Token-Binding-ID:true=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= <br> =C2=A0 =C2=A0 =C2=A0| any security-relevant cookies should contain TBID2 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0+<- - - - - - - - - - - - - - - - - - - - -|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0. | (redirect to TP via 301, 302, |=C2=A0 =C2=A0 =C2=A0 =C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|<br> =C2=A0 =C2=A0. |=C2=A0 303, 307, or 308)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0. |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|<br> =C2=A0 =C2=A0+----------------------------------------------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 2b. client opens HTTPS w/ TP3,=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| establishes Ks3, Kp3, TBID3;=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| sends GET or POST with=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| ID Token request w/ redirect_uri=3DTC1,=C2=A0 |=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| ETBMSG[[{EKM3}Ks3,TBID3,provided_token_binding],=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0[{EKM3}Ks2,TBID2,referred_t= oken_binding]] <-- but ID Tok request<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 <-- is for TC1<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 3a. redirect to TP4 for TP-specific reasons=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| any security-relevant cookies should contain TBID3 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0+<- - - - - - - - - - - - - - - - - - - - - - - - - - -|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0. |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|<br> =C2=A0 =C2=A0+-------------------------------------------------------------= -->|<br> =C2=A0 =C2=A0 =C2=A0| 3b. client opens HTTPS w/ TP4,=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| establishes Ks4 & Kp4, TBID4=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| ETBMSG[[{EKM4}Ks4,TBID4,provided_token_binding]]=C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*** as well as the I= D Token request w/ redirect_uri=3DTC1;<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*** also, somehow co= nveys TBID2 to TP4 ?<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 4. user authentication (if applicable,=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 methods vary, particulars are out of sco= pe)=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|<br> =C2=A0 =C2=A0 =C2=A0| (TP generates ID Token for TC1 containing TBID1 - TP4= has only TBID2<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 also set cookie(s) containing TBID4 and/or TBID= 3<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 details vary)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 5a. ID Token issued for TC1, containing TBID1, <--= how do this if<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 conveyed via OIDC "Authentication R= esponse" <-- don't have TBID1?<br> =C2=A0 =C2=A0+<- - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - - -|<br> =C2=A0 =C2=A0. |=C2=A0 =C2=A0(redirect to TC1)=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0. |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|<br> =C2=A0 =C2=A0+-------------------------------->|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 5b. HTTPS GET or POST with=C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]]=C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| conveying Authn Reponse containing ID Token w/TBID1,= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i= ssued for TC1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 6. user is signed-on, any security-relevant cookie(s)= =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br> =C2=A0 =C2=A0 =C2=A0| that are set SHOULD contain TBID1=C2=A0 =C2=A0 =C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|<br> =C2=A0 =C2=A0 =C2=A0|<------------------------------|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> <br> <br> end<br> <br> <br> </blockquote></div></div></div></div> <br>_______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org">Unbearable@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> <br></blockquote></div><br></div> --001a114386ac498cc4052e951ee7-- From nobody Mon Mar 21 15:50:16 2016 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 76C1912D0E0 for <unbearable@ietfa.amsl.com>; Mon, 21 Mar 2016 15:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 GKY7tqtS-u3V for <unbearable@ietfa.amsl.com>; Mon, 21 Mar 2016 15:50:13 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id E5E1D12D0C5 for <unbearable@ietf.org>; Mon, 21 Mar 2016 15:50:12 -0700 (PDT) Received: (qmail 27235 invoked by uid 0); 21 Mar 2016 22:50:11 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 21 Mar 2016 22:50:11 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id Ytq41s00W2UhLwi01tq7KP; Mon, 21 Mar 2016 23:50:08 -0600 X-Authority-Analysis: v=2.1 cv=Maz/5fPf c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7OsogOcEt9IA:10 a=NEAV23lmAAAA:8 a=1XWaLZrsAAAA:8 a=48vgC7mUAAAA:8 a=ekYV4lpRAAAA:8 a=xUqauMeT5wHXlCOISGQA:9 a=UAGp5bKhPdJ_4wBH:21 a=2jqBnX0JOnDT4zoS:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=40YLfsrxlkReA+redgBu/xZbJEq/GRqsd/iiWLZhEPI=; b=H1JP2qiD5BaDO6mO4nU002bZnw XSS6Jg0eyXjDVZLP7+qVgPp5qP4sjANDfMd+Lklzwbvh4Oa9jpHsBvlU8XdsHlo9IgBsuvwEBfJOh uzrfiIuw5AOYg2YtAapaCQo8p; Received: from [73.202.80.238] (port=52931 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1ai8eF-0005AT-An for unbearable@ietf.org; Mon, 21 Mar 2016 16:50:07 -0600 To: IETF Tokbind WG <unbearable@ietf.org> From: =JeffH <Jeff.Hodges@KingsMountain.com> Message-ID: <56F07A95.4050904@KingsMountain.com> Date: Mon, 21 Mar 2016 15:49:57 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/T11KdQ1UA9jSzkbyQanuvaXYuhs> Subject: Re: [Unbearable] Sec- prefix for Token-Binding headers (was: new draft-ietf-tokbind-https-03 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Mar 2016 22:50:14 -0000 original issue: Give the header a Sec-* prefix https://github.com/TokenBinding/Internet-Drafts/issues/1 > On 30 June 2015 at 03:09, Dirk Balfanz <balfanz@google.com> wrote: >> Hi guys, >> >> following Leif's request to mirror discussions here, I wanted to point out >> one discussion we're having over there regarding the Sec- prefix for the >> Token-Binding header: >> https://github.com/TokenBinding/Internet-Drafts/issues/1 >> >> Anne favors a Sec- prefix (meaning it can't be set directly from >> Javascript), whereas Martin doesn't. >> >> I find Anne's arguments persuasive. On 30 Jun 2015 09:41:09 Martin Thomson said: > This is wholly confused, as I explained in the issue. The security of > token binding is based on the private key. If it is not, then I think > we need to discuss how that is not sufficient. On Mon, 21 Mar 2016 Dirk said: > > https://tools.ietf.org/html/draft-ietf-tokbind-https-03 > > Changes since the last version: > > - The header has a Sec- prefix again. > ... Hm. I don't see discussion of adding the "Sec-" header field prefix back to the token-binding header field. What's the motivation for doing so? issue #1 was closed 30-Jun-2015. in any case, here are relevant references into the fetch() spec.. https://fetch.spec.whatwg.org/#forbidden-header-name https://fetch.spec.whatwg.org/#http-header-layer-division So, from the above references, it seems that if we have the "Sec-" prefix to the token-binding header field, we are essentially saying that the user agent will automagically handle TB negotiation at the TLS layer, and also automagically include the token-binding header in any and all HTTP request messages sent to a server with which TG was successfully negotiated, and this is /not/ under the control of any web application that may be being served by said server, yes? Are folks imagining giving a client-side web app the ability to control whether TB is negotiated when HTTPS connections are established? Or is it intended to be automatic? Having it be automatic sounds nominally ok to me in the case of only one server, but I'm wondering whether it would be an issue in the federation use case(s) where the client-side web application may need to craft a TBMSG (and thus token-binding header conveying that TBMSG) containing the correct referred TBID, and thus may need an API to facilitate doing so. [see the "Referred token binding IDs" thread] Hm, I'm curious, to what extent are federated Web SSO protocols being baked directly into the browsers? The answer was "none" a while back, but is that changing? In terms of the actual -tokbind-https-03 spec, if the Sec- header prefix is kept, the implications ought to be described and security considerations added. One consideration I can think of if there is no "Sec-" header prefix is whether we recommend that the TBMSG creation and sending of the TBMSG be done in by the user agent or the web app, and if it ends up being embedded in browsers, then the web app code could still craft TBMSGs and add them to requests. in any case we need to stipulate whether or not the server honors any, only one, or all received token-binding headers in a received HTTP msg. In HSTS and HPKP we explictly state the server honors on the first header field in a received HTTP msg. HTH, =JeffH From nobody Mon Mar 21 16:02:56 2016 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 2EE7E12D165 for <unbearable@ietfa.amsl.com>; Mon, 21 Mar 2016 16:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 iRuFOebOAU97 for <unbearable@ietfa.amsl.com>; Mon, 21 Mar 2016 16:02:52 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id B1E4A12D0AD for <unbearable@ietf.org>; Mon, 21 Mar 2016 16:02:46 -0700 (PDT) Received: (qmail 32326 invoked by uid 0); 21 Mar 2016 23:02:45 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy8.mail.unifiedlayer.com with SMTP; 21 Mar 2016 23:02:45 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id Yn2g1s0012UhLwi01n2jtV; Mon, 21 Mar 2016 17:02:44 -0600 X-Authority-Analysis: v=2.1 cv=G/WPTbU5 c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7OsogOcEt9IA:10 a=lGWU0-vQhkO3HhAlc2YA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=uQL0lSjh23u1wu2k5Hfsf1J5lAHaCJ96znnsRtSUrQg=; b=gOAgQM2YjNT0Jmj0xVNeImGj6h sIRmxr1e6DZZnI3aQorNtMdT+wqYwMYSB0G7uCg2GGpFcxWrVPhvTltC/FgBO1fRz6xTBu0tmgari +rmcTnu9IMMh4FvQSY6pTvjd/; Received: from [73.202.80.238] (port=52948 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1ai8qP-0007ge-5i for unbearable@ietf.org; Mon, 21 Mar 2016 17:02:41 -0600 To: IETF Tokbind WG <unbearable@ietf.org> From: =JeffH <Jeff.Hodges@KingsMountain.com> Message-ID: <56F07D87.6040606@KingsMountain.com> Date: Mon, 21 Mar 2016 16:02:31 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/bmqrhNegtxafrasPkRJ4NqLgii8> Subject: Re: [Unbearable] Potential privacy bug if Include-Referer-Token-Binding-ID is improperly implemented client-side X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Mar 2016 23:02:54 -0000 > Here's the problem: Suppose the connection to server A is over http. did you mean 'http' or 'https' in the above? > Now a > network attacker B injects into some http page (from server C) code that > will cause the client to make an http request to server A. 'http' or 'https' ? > The attacker B > intercepts the request and responds with a redirect to server B (with the > Include-Referer-Token-Binding-ID header). The client dutifully follows that > request and forwards the TokenBindingID it has for A to the > attacker-controlled B. This is a problem, because A never intended to have > the client forward its TokenBindingID from A to B. In any case, part of the way to deal with this sort of issue is to normatively stipulate that the client MUST not honor Include-Referer-Token-Binding-ID headers that are not received over (established error free) secure transport, a la HSTS & HPKP. similarly, the server should not honor any (sec-)token-binding header received over insecure transport. -tokbind-https-03 does say in the Intro.. ...Note that TokenBindingMessages are only defined if the underlying transport uses TLS. This means that Token Binding over HTTP is only defined when the HTTP protocol is layered on top of TLS (commonly referred to as HTTPS). ..but it doesn't appear to normatively back this up. HTH, =JeffH From nobody Mon Mar 21 16:25:40 2016 Return-Path: <nharper@google.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 1829C12D175 for <unbearable@ietfa.amsl.com>; Mon, 21 Mar 2016 16:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 I8pfaXxUB90h for <unbearable@ietfa.amsl.com>; Mon, 21 Mar 2016 16:25:36 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3011312D170 for <unbearable@ietf.org>; Mon, 21 Mar 2016 16:25:36 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id k1so233792193vkb.0 for <unbearable@ietf.org>; Mon, 21 Mar 2016 16:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mgvhlfmqfKg3Cax8GWIdtVU7r8w8rxBA76YxcC3k8VM=; b=lihKs+RmUGMzV1Otr8udRf7ZNPOE0425tQYnZ/w97x6Kp7Zx+PIEUDnZn2uhVJWJod 4TwA8w/VS9meilgeqOD930B/Vwj4S78OOQDeRZkExJ+JR+Z5GEYc0AMHC5bbg6gqTLSa 6rfqOJK4aQjLvYoeKJ6/B5k43oVeUlkx39XpW+snqiDkKcbTqSnlAkeIr8uTZS6lF8Bm LRIcZ2Y/39YNgiu2fbNup+5sPxaBKdI5ymQ3b+XL/fpmh1lmlYd0rVKOdrLnieC/2Y8U +4NGZ2ZcibRjC7VoWySNT4JWWOyUZ02Al6WGLXg/5cOPfZETwU1dqlJb8HAwvIUPsRpW 2RWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mgvhlfmqfKg3Cax8GWIdtVU7r8w8rxBA76YxcC3k8VM=; b=cuo4fZceFwVPIeVewH3b0nTCp48NNZZ8+KZgINkcU9pl8wMkSrZ9ZAU6y20vvf7SCd zpXMjQsQjxqW51OvsOQyi/Zol42uniYgrxubiJOdaTfX1tZpgzvTlhCQtfZuqqCY6t33 SQ1qlk6dc3uMtHLXc5fBLKcbdlKpm9+YhLEpciN8fQoBD3t59SnJpJhlcJLx6mk4UGGE QoTKIx3Hvz9svUsiTUzdUM0PfbNargogKcLo5VowAgxEsGBSoTV/Y5SpsZORqkmaJUSu gSaBWnXp4B6NcPmzfMBP3mI3Jnvxn5QQCieXiQvnHW1w/UD7lCpuAF8pYWFATS10tQwq A5dA== X-Gm-Message-State: AD7BkJJpi+DZi/Vygm4Q+2ght7WrSLZK4RywKsPeh8biGjnzGncOY19M6gBvKyWfTG9oeP9zkq4TIKOa278KXdCg X-Received: by 10.159.38.120 with SMTP id 111mr2885319uag.104.1458602735033; Mon, 21 Mar 2016 16:25:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.76.198 with HTTP; Mon, 21 Mar 2016 16:25:15 -0700 (PDT) In-Reply-To: <56F07D87.6040606@KingsMountain.com> References: <56F07D87.6040606@KingsMountain.com> From: Nick Harper <nharper@google.com> Date: Mon, 21 Mar 2016 16:25:15 -0700 Message-ID: <CACdeXi+V350A1CvMnJ_RKYsBLspPQ5EP5dv1Eq2Yj8Wy_c2egg@mail.gmail.com> To: "=JeffH" <Jeff.Hodges@kingsmountain.com> Content-Type: multipart/alternative; boundary=001a113ad1fee440e8052e976934 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/EROVml4Eu7etJlltvk966J_Lb4s> Cc: IETF Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Potential privacy bug if Include-Referer-Token-Binding-ID is improperly implemented client-side X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Mar 2016 23:25:38 -0000 --001a113ad1fee440e8052e976934 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 21, 2016 at 4:02 PM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote: > > Here's the problem: Suppose the connection to server A is over http. > > did you mean 'http' or 'https' in the above? http > > > > Now a > > network attacker B injects into some http page (from server C) code that > > will cause the client to make an http request to server A. > > 'http' or 'https' ? http > > > > The attacker B > > intercepts the request and responds with a redirect to server B (with the > > Include-Referer-Token-Binding-ID header). The client dutifully follows > that > > request and forwards the TokenBindingID it has for A to the > > attacker-controlled B. This is a problem, because A never intended to > have > > the client forward its TokenBindingID from A to B. > > In any case, part of the way to deal with this sort of issue is to > normatively stipulate that the client MUST not honor > Include-Referer-Token-Binding-ID headers that are not received over > (established error free) secure transport, a la HSTS & HPKP. similarly, the > server should not honor any (sec-)token-binding header received over > insecure transport. > The conditions for when a user-agent can honor an Include-Referer-Token-Binding-ID should be the same conditions for when it sends a Sec-Token-Binding header. It by necessity must be only for https connections (because there is no EKM to sign for http connections). It would certainly be nice for the transport to be established error free, and to use HSTS and HPKP, but I don't think those need to be made as requirements for using Token Binding. > > -tokbind-https-03 does say in the Intro.. > > ...Note that TokenBindingMessages are only defined if the underlying > transport uses TLS. This means that Token Binding over HTTP is only > defined when the HTTP protocol is layered on top of TLS (commonly > referred to as HTTPS). > > ..but it doesn't appear to normatively back this up. > > HTH, > > =JeffH > > > > > > > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a113ad1fee440e8052e976934 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On Mon, Mar 21, 2016 at 4:02 PM, =3DJeffH <span dir=3D"ltr"><<a href= =3D"mailto:Jeff.Hodges@kingsmountain.com" target=3D"_blank">Jeff.Hodges@kin= gsmountain.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><spa= n>> Here's the problem: Suppose the connection to server A is over h= ttp.<br> <br></span> did you mean 'http' or 'https' in the above?</blockquote><d= iv>http=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br> <br> > Now a<br> > network attacker B injects into some http page (from server C) code th= at<br> > will cause the client to make an http request to server A.<br> <br></span> 'http' or 'https' ?</blockquote><div>http=C2=A0</div><block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex"><span><br> <br> > The attacker B<br> > intercepts the request and responds with a redirect to server B (with = the<br> > Include-Referer-Token-Binding-ID header). The client dutifully follows= that<br> > request and forwards the TokenBindingID it has for A to the<br> > attacker-controlled B. This is a problem, because A never intended to = have<br> > the client forward its TokenBindingID from A to B.<br> <br></span> In any case, part of the way to deal with this sort of issue is to normativ= ely stipulate that the client MUST not honor Include-Referer-Token-Binding-= ID headers that are not received over (established error free) secure trans= port, a la HSTS & HPKP. similarly, the server should not honor any (sec= -)token-binding header received over insecure transport.<br></blockquote><d= iv><br></div><div>The conditions for when a user-agent can honor an Include= -Referer-Token-Binding-ID should be the same conditions for when it sends a= Sec-Token-Binding header. It by necessity must be only for https connectio= ns (because there is no EKM to sign for http connections). It would certain= ly be nice for the transport to be established error free, and to use HSTS = and HPKP, but I don't think those need to be made as requirements for u= sing Token Binding.</div><blockquote class=3D"gmail_quote" style=3D"margin:= 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> -tokbind-https-03 does say in the Intro..<br> <br> =C2=A0 =C2=A0...Note that TokenBindingMessages are only defined if the unde= rlying<br> =C2=A0 =C2=A0transport uses TLS.=C2=A0 This means that Token Binding over H= TTP is only<br> =C2=A0 =C2=A0defined when the HTTP protocol is layered on top of TLS (commo= nly<br> =C2=A0 =C2=A0referred to as HTTPS).<br> <br> ..but it doesn't appear to normatively back this up.<br> <br> HTH,<br> <br> =3DJeffH<div><div><br> <br> <br> <br> <br> <br> <br> <br> <br> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> </div></div></blockquote></div><br></div></div> --001a113ad1fee440e8052e976934-- From nobody Mon Mar 21 20:43:22 2016 Return-Path: <balfanz@google.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 180AB12D5C1 for <unbearable@ietfa.amsl.com>; Mon, 21 Mar 2016 20:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 1hTVCL412Yug for <unbearable@ietfa.amsl.com>; Mon, 21 Mar 2016 20:43:18 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC64112D5B3 for <unbearable@ietf.org>; Mon, 21 Mar 2016 20:43:17 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id l68so145695583wml.1 for <unbearable@ietf.org>; Mon, 21 Mar 2016 20:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wFgnUjxffgPrJFKWo3XYefyhfLYoxDS7TmyAwKKsk/Q=; b=fwynKmDfjsyldC9ctttwDOuxzHpGCE0umBanGP9e2vcNoSoLNoKGymhAX1TfitHCIE dqCP+NhWmrnOcuDD7Mc0Y7Rs72LYDtrg2TG4pnKl6Psbd4aMRBtB1mkKvQuyaU4hvzIf g04kRfWOX7NHWDQfQkrC0TX4pEJsTKcfvk40inaWVN/hnekdQM24gaiTP9Qrm0wmawi1 e6T3cvuhQFKMVXqHGVF4WvGRMUz4ALwtx05qkWMhciHf7XkA+Y1U4xvhriOXc+BNL7+G lzCFb0c6J5fnlk31TTC+FTU7bYRbSRoZeAzpLQrELvYUeuzA7dZmDg6XzfMsLGtTCTRV jWGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=wFgnUjxffgPrJFKWo3XYefyhfLYoxDS7TmyAwKKsk/Q=; b=CoZ4bL6dpMiRz0Fz2u09s7B+t51GzHr4vk4icoCnmSw08asoO/rtI7Zw0WQFBBlfGj wPGg6Kh+VsmNCGikvUucDoW9O3KZmerJ8lCv+rEdKT0SZW7QtUbg1MrjcQw+iJbxGZaq MBqACXErmVtraash4ouJ0N0bGzHqehmHh0gkVkqi9FpEXp+YIan93wPFkR2uKp1VimE+ LWIk92QYu3vZtAvlCYExT2yRddGNBjeunQAjB5MIaxhx0TfOVLgP+LV8vKwvZhL16WbU UOIMyk+PgYJ2f/av5vAP8LwdmT7mXKtcTor+rfqWTVjMfoX8B3EezsOR2gZgNMjTzT2G P8nQ== X-Gm-Message-State: AD7BkJI/2WXeflgGp54p7cJYOvtU7RfM1AjMY9cp5ohfUjmIrO92npgqqp8HMCMPB24MFVTAscq014hilNA36WUa X-Received: by 10.28.135.4 with SMTP id j4mr18072241wmd.80.1458618196182; Mon, 21 Mar 2016 20:43:16 -0700 (PDT) MIME-Version: 1.0 References: <56F07A95.4050904@KingsMountain.com> In-Reply-To: <56F07A95.4050904@KingsMountain.com> From: Dirk Balfanz <balfanz@google.com> Date: Tue, 22 Mar 2016 03:43:06 +0000 Message-ID: <CADHfa2DzJ4UAvjtUPfp0QfeBnR4HbuVy9VRqO15=x7raRKSLAA@mail.gmail.com> To: "=JeffH" <Jeff.Hodges@kingsmountain.com>, IETF Tokbind WG <unbearable@ietf.org> Content-Type: multipart/alternative; boundary=001a1144278e728fa4052e9b03c0 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/LxeXHEh0bQbEDOeGx3nnQHv-q0o> Subject: Re: [Unbearable] Sec- prefix for Token-Binding headers (was: new draft-ietf-tokbind-https-03 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Mar 2016 03:43:20 -0000 --001a1144278e728fa4052e9b03c0 Content-Type: text/plain; charset=UTF-8 Hi Jeff, I was told that in Yokohama it was decided to add the Sec- prefix again. (I wasn't at that meeting.) As for the security considerations, they already state that a man-in-the-middle shouldn't be able to pick the value of the (Sec-)Token-Binding header. One corollary of that is that the value of the (Sec-)Token-Binding header can't be set by application (Javascript) code (since that is potentially controlled by a man-in-the-middle). But perhaps it bears saying that explicitly. Wanna open an Issue? Dirk. On Mon, Mar 21, 2016 at 3:50 PM =JeffH <Jeff.Hodges@kingsmountain.com> wrote: > original issue: > Give the header a Sec-* prefix > https://github.com/TokenBinding/Internet-Drafts/issues/1 > > > > On 30 June 2015 at 03:09, Dirk Balfanz <balfanz@google.com> wrote: > >> Hi guys, > >> > >> following Leif's request to mirror discussions here, I wanted to point > out > >> one discussion we're having over there regarding the Sec- prefix for > the > >> Token-Binding header: > >> https://github.com/TokenBinding/Internet-Drafts/issues/1 > >> > >> Anne favors a Sec- prefix (meaning it can't be set directly from > >> Javascript), whereas Martin doesn't. > >> > >> I find Anne's arguments persuasive. > > On 30 Jun 2015 09:41:09 Martin Thomson said: > > This is wholly confused, as I explained in the issue. The security of > > token binding is based on the private key. If it is not, then I think > > we need to discuss how that is not sufficient. > > > On Mon, 21 Mar 2016 Dirk said: > > > > https://tools.ietf.org/html/draft-ietf-tokbind-https-03 > > > > Changes since the last version: > > > > - The header has a Sec- prefix again. > > ... > > > Hm. I don't see discussion of adding the "Sec-" header field prefix back to > the token-binding header field. What's the motivation for doing so? issue > #1 > was closed 30-Jun-2015. > > > in any case, here are relevant references into the fetch() spec.. > > https://fetch.spec.whatwg.org/#forbidden-header-name > > https://fetch.spec.whatwg.org/#http-header-layer-division > > > So, from the above references, it seems that if we have the "Sec-" prefix > to > the token-binding header field, we are essentially saying that the user > agent will automagically handle TB negotiation at the TLS layer, and also > automagically include the token-binding header in any and all HTTP request > messages sent to a server with which TG was successfully negotiated, and > this is /not/ under the control of any web application that may be being > served by said server, yes? > > Are folks imagining giving a client-side web app the ability to control > whether TB is negotiated when HTTPS connections are established? Or is it > intended to be automatic? > > Having it be automatic sounds nominally ok to me in the case of only one > server, but I'm wondering whether it would be an issue in the federation > use > case(s) where the client-side web application may need to craft a TBMSG > (and > thus token-binding header conveying that TBMSG) containing the correct > referred TBID, and thus may need an API to facilitate doing so. [see the > "Referred token binding IDs" thread] > > Hm, I'm curious, to what extent are federated Web SSO protocols being baked > directly into the browsers? The answer was "none" a while back, but is that > changing? > > > In terms of the actual -tokbind-https-03 spec, if the Sec- header prefix is > kept, the implications ought to be described and security considerations > added. > > One consideration I can think of if there is no "Sec-" header prefix is > whether we recommend that the TBMSG creation and sending of the TBMSG be > done in by the user agent or the web app, and if it ends up being embedded > in browsers, then the web app code could still craft TBMSGs and add them to > requests. > > in any case we need to stipulate whether or not the server honors any, only > one, or all received token-binding headers in a received HTTP msg. In HSTS > and HPKP we explictly state the server honors on the first header field in > a > received HTTP msg. > > HTH, > > =JeffH > > > > > > > > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a1144278e728fa4052e9b03c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi Jeff,=C2=A0<div><br></div><div>I was told that in Yokoh= ama it was decided to add the Sec- prefix again. (I wasn't at that meet= ing.)</div><div><br></div><div>As for the security considerations, they alr= eady state that a man-in-the-middle shouldn't be able to pick the value= of the (Sec-)Token-Binding header. One corollary of that is that the value= of the (Sec-)Token-Binding header can't be set by application (Javascr= ipt) code (since that is potentially controlled by a man-in-the-middle). Bu= t perhaps it bears saying that explicitly. Wanna open an Issue?</div><div><= br></div><div>Dirk.</div></div><br><div class=3D"gmail_quote"><div dir=3D"l= tr">On Mon, Mar 21, 2016 at 3:50 PM =3DJeffH <<a href=3D"mailto:Jeff.Hod= ges@kingsmountain.com">Jeff.Hodges@kingsmountain.com</a>> wrote:<br></di= v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 1px #ccc solid;padding-left:1ex">original issue:<br> Give the header a Sec-* prefix<br> <a href=3D"https://github.com/TokenBinding/Internet-Drafts/issues/1" rel=3D= "noreferrer" target=3D"_blank">https://github.com/TokenBinding/Internet-Dra= fts/issues/1</a><br> <br> <br> =C2=A0> On 30 June 2015 at 03:09, Dirk Balfanz <<a href=3D"mailto:bal= fanz@google.com" target=3D"_blank">balfanz@google.com</a>> wrote:<br> =C2=A0>> Hi guys,<br> =C2=A0>><br> =C2=A0>> following Leif's request to mirror discussions here, I w= anted to point out<br> =C2=A0>> one discussion we're having over there regarding the Sec= - prefix for the<br> =C2=A0>> Token-Binding header:<br> =C2=A0>> <a href=3D"https://github.com/TokenBinding/Internet-Drafts/i= ssues/1" rel=3D"noreferrer" target=3D"_blank">https://github.com/TokenBindi= ng/Internet-Drafts/issues/1</a><br> =C2=A0>><br> =C2=A0>> Anne favors a Sec- prefix (meaning it can't be set direc= tly from<br> =C2=A0>> Javascript), whereas Martin doesn't.<br> =C2=A0>><br> =C2=A0>> I find Anne's arguments persuasive.<br> <br> On 30 Jun 2015 09:41:09 Martin Thomson said:<br> =C2=A0> This is wholly confused, as I explained in the issue.=C2=A0 The = security of<br> =C2=A0> token binding is based on the private key.=C2=A0 If it is not, t= hen I think<br> =C2=A0> we need to discuss how that is not sufficient.<br> <br> <br> On Mon, 21 Mar 2016 Dirk said:<br> =C2=A0><br> =C2=A0> <a href=3D"https://tools.ietf.org/html/draft-ietf-tokbind-https-= 03" rel=3D"noreferrer" target=3D"_blank">https://tools.ietf.org/html/draft-= ietf-tokbind-https-03</a><br> =C2=A0><br> =C2=A0> Changes since the last version:<br> =C2=A0><br> =C2=A0> - The header has a Sec- prefix again.<br> =C2=A0> ...<br> <br> <br> Hm. I don't see discussion of adding the "Sec-" header field = prefix back to<br> the token-binding header field. What's the motivation for doing so? iss= ue #1<br> was closed 30-Jun-2015.<br> <br> <br> in any case, here are relevant references into the fetch() spec..<br> <br> <a href=3D"https://fetch.spec.whatwg.org/#forbidden-header-name" rel=3D"nor= eferrer" target=3D"_blank">https://fetch.spec.whatwg.org/#forbidden-header-= name</a><br> <br> <a href=3D"https://fetch.spec.whatwg.org/#http-header-layer-division" rel= =3D"noreferrer" target=3D"_blank">https://fetch.spec.whatwg.org/#http-heade= r-layer-division</a><br> <br> <br> So, from the above references, it seems that if we have the "Sec-"= ; prefix to<br> the token-binding header field, we are essentially saying that the user<br> agent will automagically handle TB negotiation at the TLS layer, and also<b= r> automagically include the token-binding header in any and all HTTP request<= br> messages sent to a server with which TG was successfully negotiated, and<br= > this is /not/ under the control of any web application that may be being<br= > served by said server, yes?<br> <br> Are folks imagining giving a client-side web app the ability to control<br> whether TB is negotiated when HTTPS connections are established? Or is it<b= r> intended to be automatic?<br> <br> Having it be automatic sounds nominally ok to me in the case of only one<br= > server, but I'm wondering whether it would be an issue in the federatio= n use<br> case(s) where the client-side web application may need to craft a TBMSG (an= d<br> thus token-binding header conveying that TBMSG) containing the correct<br> referred TBID, and thus may need an API to facilitate doing so. [see the<br= > "Referred token binding IDs" thread]<br> <br> Hm, I'm curious, to what extent are federated Web SSO protocols being b= aked<br> directly into the browsers? The answer was "none" a while back, b= ut is that<br> changing?<br> <br> <br> In terms of the actual -tokbind-https-03 spec, if the Sec- header prefix is= <br> kept, the implications ought to be described and security considerations ad= ded.<br> <br> One consideration I can think of if there is no "Sec-" header pre= fix is<br> whether we recommend that the TBMSG creation and sending of the TBMSG be<br= > done in by the user agent or the web app, and if it ends up being embedded<= br> in browsers, then the web app code could still craft TBMSGs and add them to= <br> requests.<br> <br> in any case we need to stipulate whether or not the server honors any, only= <br> one, or all received token-binding headers in a received HTTP msg. In HSTS<= br> and HPKP we explictly state the server honors on the first header field in = a<br> received HTTP msg.<br> <br> HTH,<br> <br> =3DJeffH<br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> </blockquote></div> --001a1144278e728fa4052e9b03c0-- From nobody Mon Mar 21 23:09:20 2016 Return-Path: <squid3@treenet.co.nz> 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 442D412D5CF for <unbearable@ietfa.amsl.com>; Mon, 21 Mar 2016 23:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 6eWzBtSw4FEQ for <unbearable@ietfa.amsl.com>; Mon, 21 Mar 2016 23:09:14 -0700 (PDT) Received: from treenet.co.nz (unknown [121.99.228.82]) by ietfa.amsl.com (Postfix) with ESMTP id 7901E12D55B for <unbearable@ietf.org>; Mon, 21 Mar 2016 23:09:12 -0700 (PDT) Received: from [192.168.20.251] (unknown [121.98.45.158]) by treenet.co.nz (Postfix) with ESMTP id C3B85E6F49 for <unbearable@ietf.org>; Tue, 22 Mar 2016 18:09:10 +1200 (NZST) To: unbearable@ietf.org References: <56F07A95.4050904@KingsMountain.com> <CADHfa2DzJ4UAvjtUPfp0QfeBnR4HbuVy9VRqO15=x7raRKSLAA@mail.gmail.com> From: Amos Jeffries <squid3@treenet.co.nz> Message-ID: <56F0E177.8000706@treenet.co.nz> Date: Tue, 22 Mar 2016 19:08:55 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <CADHfa2DzJ4UAvjtUPfp0QfeBnR4HbuVy9VRqO15=x7raRKSLAA@mail.gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/v7xYFsfZSgV-9yIIRyRnqQtPpJ4> Subject: [Unbearable] draft-ietf-tokbind-https-03 BCP90 compliance (was Sec- prefix for Token-Binding headers) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Mar 2016 06:09:16 -0000 On 22/03/2016 4:43 p.m., Dirk Balfanz wrote: > Hi Jeff, > > I was told that in Yokohama it was decided to add the Sec- prefix again. (I > wasn't at that meeting.) > Note that HTTP (RFC 7231 section 8.2.1) header naming requirements state: "Authors of specifications defining new fields are advised to keep the name as short as practical" HTTP also does not define anything like namespaces within header names. So "Sec-" has no meaning according to HTTP. If there is a document defining such a namespace that means "Sec-" needs to be added in violation of the "short as practical" consideration, then it should be referenced for context in section 2. This has prompted me to take a look at this draft in regards to the HTTP requirements. I'm afraid to report that its in rather bad state in respect to BCP 90 compliance. <http://tools.ietf.org/html/bcp90> * Sec-Token-Binding does have section 2 to itself, but is still lacking mention of many of the semantic details required by BCP 90 section 4. I did see some details spread out elswhere around the draft, so its likely they are mostly there somewhere. But they should be a far more coherent set of semantic statements for HTTP implementers just wanting to ensure the header is handled correctly by the HTTP layer without caring about any Token Binding or TLS layer logics. * Include-Referer-Token-Binding-ID semantics are buried in section 3.3 This may also be an overly-long header name in respect to the above mentioned RFC7231 requirement about header naming. IMO the header should have a section 2.x to itself outlining explicitly and clearly the details required by BCP 90 section 4. The document structure something along the lines of: Section 2 HTTP Headers Section 2.1 The Sec-Token-Binding Header Section 2.2 The Include-Referer-Token-Binding-ID Header Section 3 First Party Use Cases ... Section 4 Federation Use Cases ... * complete lack of "IANA considerations" section for header registry templates. Editorial Issues: * section 1 states that the draft covers both first-party and federated use cases. But there is only section 3 outlining federated cases. No clearly visible section for the first-party use case. * in section 3.1 it says "the Sec-Token-Binding HTTP header defined above". Should that not be an explicit "section 2" (2.1?) reference instead of the word "above" ? * in section 4.2 "manterial" -> material * in section 4.3 paragraph 4 it says "A client shouldn't be tricked into sending a Sec-Token-Binding header to a server that" That specific wording is just telling malicious actors "dont be bad". Which is useless. Surely it should be saying to clients not to let themselves be tricked. * I spy several lower-case "must", "must not", "should", "should not" and "may" dotted around the document. Are those normative requirements or just confusing wording? * please pick a consistent formula for the Security Considerations and Privacy Consuderations entries before this goes to LC. Right now there is a mix of conceptual orderings: - problem, solution requirements - requirements, problem, solution requirements - problem, detailed examples, requirements - problem, detailed examples, some requirements, detailed examples, more requirements If one wants to skip the rather dense explanatinos and details of attacks and just check that the requirements are met its quite hard to see what those actually are. I suggest sticking with problem and requirements in quick prefix paragraphs, _then_ details and examples (if necessary). Cheers AYJ From nobody Tue Mar 22 09:37:11 2016 Return-Path: <karthikeyan.bhargavan@inria.fr> 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 D434D12DB80 for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 09:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 VasHKqpLObxe for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 09:37:08 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E5E12D55D for <unbearable@ietf.org>; Tue, 22 Mar 2016 09:37:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,377,1454972400"; d="scan'208";a="170223029" Received: from unknown (HELO [128.93.83.21]) ([128.93.83.21]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Mar 2016 17:36:50 +0100 From: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <099CAE22-2ED5-447B-BE5B-92CD4F5EFAD5@inria.fr> Date: Tue, 22 Mar 2016 17:36:50 +0100 To: unbearable@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/AF2RKbeijKubZS8fZ7nmURNiC8A> Subject: [Unbearable] Limitations to Man-in-the-Middle Detection in Token Binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Mar 2016 16:37:10 -0000 I was staring at the latest draft of draft-ietf-tokbind-https-03 and the = text on man-in-the-middle detection in Section 4.3 seems a bit too = strong, and I would suggest adding caveats here, or in the security = considerations. By using EKM, and by relying on extended master secret, the token = binding protocol indeed protects against MitM attacks where either (a) the attacker has a mis-issued certificate for the server (token = consumer or token provider), or (b) the attacker has fooled the user agent into accepting a bogus = certificate for the server, or (c) the attacker is a malicious server who is seeking to forward the = user=E2=80=99s token to a different server. However, there are other MitM scenarios that are not protected by Token = Binding (d) if the server=E2=80=99s certificate private key is compromised and = the TLS connection between the client and server uses RSA key transport,=20= then the attacker can tamper with the connection (and hence with the = Token Binding HTTPS headers) without being detected (e) if the server is vulnerable to RSA Bleichenbacher attacks (as in = Drown),=20 then the attacker can obtain the PMS, hence the MS, and again tamper = with the application data without being detected (f) if the attacker obtains the session master secret between the = client and server,=20 either by stealing it from a session cache, or by breaking the ticket = encryption key, then in subsequent resumption handshakes the attacker can tamper with = the application data without being detected. These last three scenarios are undoubtedly very strong attackers and may = be out-of-scope for Token Binding, but I think it is important not to give the impression that the use of EKM + EMS in = token binding will prevent all MitM attacks on TLS. If it is indeed important to prevent (d,e,f), then Token Binding should = further recommend that the TLS client or server should only enable forward-secure DHE/ECDHE ciphersuites (this is what = ChannelId did) and warn about the risks of compromised session secrets or ticket encryption keys. Best, Karthik= From nobody Tue Mar 22 10:44:17 2016 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 86B1912D0CA for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 10:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_HELO_PASS=-0.001, SPF_PASS=-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 Z6hIVlZs6vGc for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 10:44:11 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::719]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DFDD12D1D0 for <unbearable@ietf.org>; Tue, 22 Mar 2016 10:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vzbOQOwVCwnutidV/y9Z9EKfjmbqc7ttwGoE79Sdkig=; b=HRq6/NSlv+6Oy9JLJCYTuZPGBqpOXuBLURFB0MpnlwYM+5aksHhc1hZkWoPYOw7K86+JSwD+gfd8mnPGXGfLvZslR15vfqnSFXkfRbpA8NVqy7hn+u1ciblgHXvvMwH6U9phb4PGyyLThUcMUclW/6HSbvOGdeIcPFfGn6lQIBQ= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.434.16; Tue, 22 Mar 2016 17:43:50 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0434.021; Tue, 22 Mar 2016 17:43:50 +0000 From: Andrei Popov <Andrei.Popov@microsoft.com> To: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>, "unbearable@ietf.org" <unbearable@ietf.org> Thread-Topic: [Unbearable] Limitations to Man-in-the-Middle Detection in Token Binding Thread-Index: AQHRhFkWbi72tPesXkKT/1iXKJI44p9ludfA Date: Tue, 22 Mar 2016 17:43:50 +0000 Message-ID: <BLUPR03MB13967C3EEAB0B0FEAF0D3AD18C800@BLUPR03MB1396.namprd03.prod.outlook.com> References: <099CAE22-2ED5-447B-BE5B-92CD4F5EFAD5@inria.fr> In-Reply-To: <099CAE22-2ED5-447B-BE5B-92CD4F5EFAD5@inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: inria.fr; dkim=none (message not signed) header.d=none;inria.fr; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:1::1d2] x-ms-office365-filtering-correlation-id: 0c22c466-5404-426b-20cb-08d35279874a x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:LlnMctKiLQ/0udtMiF5CGTxEhsyl9jzV1F7zeEclhWgPAPy8nXmSFIHTRNpqXfLNpX41NNaDG6vE7tVr2Mgl75GeGB8fzBMLEcUkWP/LJBWEseHr+A9vge9Ny7TZQpKM5TJbqWFDmSh+mHG0eQ0juw==; 24:CMbYMRBLSLtAvO2NmAMT2kWT4Gdhf/e8OpR5rUvcM+bjbzVaXoGvHJ2tWTYjzVrOokingdQHqE+/ptCKbBwrspAmg5AzZM20bxwHc/If4ik= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: <BLUPR03MB1396E3A78E86515F441B0ED28C800@BLUPR03MB1396.namprd03.prod.outlook.com> x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 08897B549D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(52604005)(377454003)(230783001)(54356999)(2900100001)(76176999)(50986999)(2950100001)(99286002)(15975445007)(77096005)(106116001)(74316001)(8990500004)(5004730100002)(5008740100001)(11100500001)(122556002)(81166005)(19580405001)(19580395003)(87936001)(2906002)(86362001)(86612001)(3280700002)(5005710100001)(10400500002)(33656002)(10290500002)(1220700001)(1096002)(5001770100001)(189998001)(102836003)(5002640100001)(92566002)(575784001)(76576001)(107886002)(3660700001)(10090500001)(6116002)(2501003)(5003600100002)(586003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2016 17:43:50.1432 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/vVMwROLNiTg7r3WtTwbEUKCQAaU> Subject: Re: [Unbearable] Limitations to Man-in-the-Middle Detection in Token Binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Mar 2016 17:44:13 -0000 VGhhbmtzIGZvciByZXZpZXdpbmcgdGhlIEktRHMsIEthcnRoaWsuDQoNCihkKSwgKGUpIGFuZCAo ZikgZXNzZW50aWFsbHkgaW52b2x2ZSB0b3RhbCBicmVha2FnZSBvZiBUTFMuIFRydWx5LCBpZiBv bmUncyBiaW5kaW5nIGlzIHRvIGEgY29tcGxldGVseSBicm9rZW4gVExTIGNoYW5uZWwsIHRoZW4g dGhlIGJpbmRpbmcgZG9lcyBub3QgaGVscCBhdCBhbGwuIFRoaXMgc2VlbXMgdG8gYmUgZmFpcmx5 IG9idmlvdXMsIGJ1dCBwZXJoYXBzIHdlIGNhbiBhZGQgdGhpcyBjYXZlYXQgdG8gdGhlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIGlmIHRoZSBncm91cCBiZWxpZXZlcyBpdCdzIHVzZWZ1bC4NCg0K Q2hlZXJzLA0KDQpBbmRyZWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFVu YmVhcmFibGUgW21haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBLYXJ0aGlrIEJoYXJnYXZhbg0KU2VudDogVHVlc2RheSwgTWFyY2ggMjIsIDIwMTYgOTozNyBB TQ0KVG86IHVuYmVhcmFibGVAaWV0Zi5vcmcNClN1YmplY3Q6IFtVbmJlYXJhYmxlXSBMaW1pdGF0 aW9ucyB0byBNYW4taW4tdGhlLU1pZGRsZSBEZXRlY3Rpb24gaW4gVG9rZW4gQmluZGluZw0KDQpJ IHdhcyBzdGFyaW5nIGF0IHRoZSBsYXRlc3QgZHJhZnQgb2YgZHJhZnQtaWV0Zi10b2tiaW5kLWh0 dHBzLTAzIGFuZCB0aGUgdGV4dCBvbiBtYW4taW4tdGhlLW1pZGRsZSBkZXRlY3Rpb24gaW4gU2Vj dGlvbiA0LjMgc2VlbXMgYSBiaXQgdG9vIHN0cm9uZywgYW5kIEkgd291bGQgc3VnZ2VzdCBhZGRp bmcgY2F2ZWF0cyBoZXJlLCBvciBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuDQoNCkJ5 IHVzaW5nIEVLTSwgYW5kIGJ5IHJlbHlpbmcgb24gZXh0ZW5kZWQgbWFzdGVyIHNlY3JldCwgdGhl IHRva2VuIGJpbmRpbmcgcHJvdG9jb2wgaW5kZWVkIHByb3RlY3RzIGFnYWluc3QgTWl0TSBhdHRh Y2tzIHdoZXJlIGVpdGhlcg0KKGEpIHRoZSBhdHRhY2tlciBoYXMgYSBtaXMtaXNzdWVkIGNlcnRp ZmljYXRlIGZvciB0aGUgc2VydmVyICh0b2tlbiBjb25zdW1lciBvciB0b2tlbiBwcm92aWRlciks IG9yDQooYikgdGhlIGF0dGFja2VyIGhhcyBmb29sZWQgdGhlIHVzZXIgYWdlbnQgaW50byBhY2Nl cHRpbmcgYSBib2d1cyBjZXJ0aWZpY2F0ZSBmb3IgdGhlIHNlcnZlciwgb3INCihjKSB0aGUgYXR0 YWNrZXIgaXMgYSBtYWxpY2lvdXMgc2VydmVyIHdobyBpcyBzZWVraW5nIHRvIGZvcndhcmQgdGhl IHVzZXLigJlzIHRva2VuIHRvIGEgZGlmZmVyZW50IHNlcnZlci4NCg0KSG93ZXZlciwgdGhlcmUg YXJlIG90aGVyIE1pdE0gc2NlbmFyaW9zIHRoYXQgYXJlIG5vdCBwcm90ZWN0ZWQgYnkgVG9rZW4g QmluZGluZw0KKGQpIGlmIHRoZSBzZXJ2ZXLigJlzIGNlcnRpZmljYXRlIHByaXZhdGUga2V5IGlz IGNvbXByb21pc2VkIGFuZCB0aGUgVExTIGNvbm5lY3Rpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFu ZCBzZXJ2ZXIgdXNlcyBSU0Ega2V5IHRyYW5zcG9ydCwgDQogICB0aGVuIHRoZSBhdHRhY2tlciBj YW4gdGFtcGVyIHdpdGggdGhlIGNvbm5lY3Rpb24gKGFuZCBoZW5jZSB3aXRoIHRoZSBUb2tlbiBC aW5kaW5nIEhUVFBTIGhlYWRlcnMpIHdpdGhvdXQgYmVpbmcgZGV0ZWN0ZWQNCihlKSBpZiB0aGUg c2VydmVyIGlzIHZ1bG5lcmFibGUgdG8gUlNBIEJsZWljaGVuYmFjaGVyIGF0dGFja3MgKGFzIGlu IERyb3duKSwgDQogICB0aGVuIHRoZSBhdHRhY2tlciBjYW4gb2J0YWluIHRoZSBQTVMsIGhlbmNl IHRoZSBNUywgYW5kIGFnYWluIHRhbXBlciB3aXRoIHRoZSBhcHBsaWNhdGlvbiBkYXRhIHdpdGhv dXQgYmVpbmcgZGV0ZWN0ZWQNCihmKSAgaWYgdGhlIGF0dGFja2VyIG9idGFpbnMgdGhlIHNlc3Np b24gbWFzdGVyIHNlY3JldCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHNlcnZlciwgDQogICBlaXRo ZXIgYnkgc3RlYWxpbmcgaXQgZnJvbSBhIHNlc3Npb24gY2FjaGUsIG9yIGJ5IGJyZWFraW5nIHRo ZSB0aWNrZXQgZW5jcnlwdGlvbiBrZXksDQogICB0aGVuIGluIHN1YnNlcXVlbnQgcmVzdW1wdGlv biBoYW5kc2hha2VzIHRoZSBhdHRhY2tlciBjYW4gdGFtcGVyIHdpdGggdGhlIGFwcGxpY2F0aW9u IGRhdGEgd2l0aG91dCBiZWluZyBkZXRlY3RlZC4NCg0KVGhlc2UgbGFzdCB0aHJlZSBzY2VuYXJp b3MgYXJlIHVuZG91YnRlZGx5IHZlcnkgc3Ryb25nIGF0dGFja2VycyBhbmQgbWF5IGJlIG91dC1v Zi1zY29wZSBmb3IgVG9rZW4gQmluZGluZywgYnV0IEkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IG5v dCB0byBnaXZlIHRoZSBpbXByZXNzaW9uIHRoYXQgdGhlIHVzZSBvZiBFS00gKyBFTVMgaW4gdG9r ZW4gYmluZGluZyB3aWxsIHByZXZlbnQgYWxsIE1pdE0gYXR0YWNrcyBvbiBUTFMuDQoNCklmIGl0 IGlzIGluZGVlZCBpbXBvcnRhbnQgdG8gcHJldmVudCAoZCxlLGYpLCB0aGVuIFRva2VuIEJpbmRp bmcgc2hvdWxkIGZ1cnRoZXIgcmVjb21tZW5kIHRoYXQgdGhlIFRMUyBjbGllbnQgb3Igc2VydmVy IHNob3VsZCBvbmx5IGVuYWJsZSBmb3J3YXJkLXNlY3VyZSBESEUvRUNESEUgY2lwaGVyc3VpdGVz ICAodGhpcyBpcyB3aGF0IENoYW5uZWxJZCBkaWQpIGFuZCB3YXJuIGFib3V0IHRoZSByaXNrcyBv ZiBjb21wcm9taXNlZCBzZXNzaW9uIHNlY3JldHMgb3IgdGlja2V0IGVuY3J5cHRpb24ga2V5cy4N Cg0KQmVzdCwNCkthcnRoaWsNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KVW5iZWFyYWJsZUBpZXRmLm9yZw0K aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZ1bmJlYXJhYmxlJTBh JmRhdGE9MDElN2MwMSU3Y0FuZHJlaS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN2M1NjhmYmZmNzJk YjY0OTQyNGQzMjA4ZDM1MjcwMzgzYiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3 JTdjMSZzZGF0YT1rekswZlVoTUdtc3VDdFFiODZUOFA3aGYlMmIwUjFJMk4ySnBEa05yU25BdlUl M2QNCg== From nobody Tue Mar 22 11:15:44 2016 Return-Path: <balfanz@google.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 059BE12D17E for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 11:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 LFevp8w9I9we for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 11:15:39 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F9012D50A for <unbearable@ietf.org>; Tue, 22 Mar 2016 11:15:39 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id p65so175249537wmp.0 for <unbearable@ietf.org>; Tue, 22 Mar 2016 11:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=39w55EjZLu3HjdEB5ZB1JyV/fYHakPidVLEWU5YMhxw=; b=c/3yZ7jq7w9o2gquXFmyHIqqgrJR/Uw1JzNmtHkbwBLZk8X8+xb9WJRniOrJzmqXwt OUSvaIwRIeDDROpB5FPC8iZqdfxwL9Rb5vF4Qdf20ff1OTKmSIvRYHf1y0UAlxTB5h/O plvLPTCTQivjIZ+WfESibHh1gf1jU4wGXMdVDlBl90gDZCciKp6ZaEIf1PRe4OW+1bz7 80IJDDIMx9wR7Di6j9Rag/eikbghlsQwNU82uHknlPONzcQxrstg3LHBIWGkZbDK6Ljc VhKubtawR0CqcR0ZhTfUo1Ap3z6F9Bb71f+OoQ2u3YI10TnSG8OlMMFi8Nl+B7rPpwSX 8RAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=39w55EjZLu3HjdEB5ZB1JyV/fYHakPidVLEWU5YMhxw=; b=VGWut+cfhi3mzEOmJ+DT/EVXw+q03Kdg1R/yT1mzaUOQBJchclIKVlRqaFcNXAvdgX me19vSmpYTMBd0Nppf1qgL7Sr/M9jyY76sIi4h+otO23rrVrJ6U32/1urjy4EfQhLE2L KDY/tHaGz39c9qKe0f3MrB0T/f1J2MJy9SKZKmO3xIi8KdpXIS1p82bYL+4qD4B9F2I1 N6U96wrwJbkAzIc+uEF2QCkerdmtr7aLLvXtX3yGVCRp6Cp8JWUzp+KHSpszCUAJ4qBo ZwWfoGUVa91ysm+d38fMJBhfg2VLMdUZm70xuASk5vKUfB244WnrY1xdP2HLgCIvsiJ1 QBSw== X-Gm-Message-State: AD7BkJIGdRhB2P+9eo2O1GAqT+s9Z/IDz0atsoXkAKxV9Salm3giteA2HcxS5CZgV41zGs478yOH8bCz29Nqz/je X-Received: by 10.194.143.82 with SMTP id sc18mr36754608wjb.14.1458670537543; Tue, 22 Mar 2016 11:15:37 -0700 (PDT) MIME-Version: 1.0 References: <099CAE22-2ED5-447B-BE5B-92CD4F5EFAD5@inria.fr> <BLUPR03MB13967C3EEAB0B0FEAF0D3AD18C800@BLUPR03MB1396.namprd03.prod.outlook.com> In-Reply-To: <BLUPR03MB13967C3EEAB0B0FEAF0D3AD18C800@BLUPR03MB1396.namprd03.prod.outlook.com> From: Dirk Balfanz <balfanz@google.com> Date: Tue, 22 Mar 2016 18:15:28 +0000 Message-ID: <CADHfa2DbV1pAm6-Da26WFUs0dA4NA7OjZwvn4mc195pFR9pqjw@mail.gmail.com> To: Andrei Popov <Andrei.Popov@microsoft.com>, Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>, "unbearable@ietf.org" <unbearable@ietf.org> Content-Type: multipart/alternative; boundary=089e011823a03c8ceb052ea733c3 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/E0ZRlI4Cm4sN0Tegju3Mh3dnujQ> Subject: Re: [Unbearable] Limitations to Man-in-the-Middle Detection in Token Binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Mar 2016 18:15:42 -0000 --089e011823a03c8ceb052ea733c3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Karthik, can you explain a little more? Token Binding doesn't (claim to) prevent any of these - (a) through (f). What it *does* claim is that authentication tokens obtained as a side effect of such attacks won't be usable by anyone other than the legitimate client to which they were issued. For an attacker to be able to successfully use a stolen authentication token, he would have to produce a legitimate signature over the EKM of a new connection, using the client's private key. Since none of the attacks assume that the attacker actually knows the client's private key, the attacker can only do this if he can create a connection to the server with an EKM that is identical to previous connection (and re-use a previous signature). It's not sufficient to *know* what the MS (and EKM) of that previous connection is - he must be able to *establish a new connection* with that same EKM with the server (so that he can re-play a previous signature to that server). Are you saying that (d) through (f) allow the attacker to do that? Dirk. On Tue, Mar 22, 2016 at 10:44 AM Andrei Popov <Andrei.Popov@microsoft.com> wrote: > Thanks for reviewing the I-Ds, Karthik. > > (d), (e) and (f) essentially involve total breakage of TLS. Truly, if > one's binding is to a completely broken TLS channel, then the binding doe= s > not help at all. This seems to be fairly obvious, but perhaps we can add > this caveat to the security considerations if the group believes it's > useful. > > Cheers, > > Andrei > > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of > Karthik Bhargavan > Sent: Tuesday, March 22, 2016 9:37 AM > To: unbearable@ietf.org > Subject: [Unbearable] Limitations to Man-in-the-Middle Detection in Token > Binding > > I was staring at the latest draft of draft-ietf-tokbind-https-03 and the > text on man-in-the-middle detection in Section 4.3 seems a bit too strong= , > and I would suggest adding caveats here, or in the security consideration= s. > > By using EKM, and by relying on extended master secret, the token binding > protocol indeed protects against MitM attacks where either > (a) the attacker has a mis-issued certificate for the server (token > consumer or token provider), or > (b) the attacker has fooled the user agent into accepting a bogus > certificate for the server, or > (c) the attacker is a malicious server who is seeking to forward the > user=E2=80=99s token to a different server. > > However, there are other MitM scenarios that are not protected by Token > Binding > (d) if the server=E2=80=99s certificate private key is compromised and th= e TLS > connection between the client and server uses RSA key transport, > then the attacker can tamper with the connection (and hence with the > Token Binding HTTPS headers) without being detected > (e) if the server is vulnerable to RSA Bleichenbacher attacks (as in > Drown), > then the attacker can obtain the PMS, hence the MS, and again tamper > with the application data without being detected > (f) if the attacker obtains the session master secret between the client > and server, > either by stealing it from a session cache, or by breaking the ticket > encryption key, > then in subsequent resumption handshakes the attacker can tamper with > the application data without being detected. > > These last three scenarios are undoubtedly very strong attackers and may > be out-of-scope for Token Binding, but I think it is important not to giv= e > the impression that the use of EKM + EMS in token binding will prevent al= l > MitM attacks on TLS. > > If it is indeed important to prevent (d,e,f), then Token Binding should > further recommend that the TLS client or server should only enable > forward-secure DHE/ECDHE ciphersuites (this is what ChannelId did) and > warn about the risks of compromised session secrets or ticket encryption > keys. > > Best, > Karthik > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2fmailman%2flistinfo%2funbearable%0a&data=3D01%7c01%7cAndrei.Popov%4= 0microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988bf86f141af91ab2d7= cd011db47%7c1&sdata=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2JpDkNrSnAvU%3d > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --089e011823a03c8ceb052ea733c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi Karthik,=C2=A0</div><div><br></div><div>can you ex= plain a little more?=C2=A0<span style=3D"line-height:1.5">Token Binding doe= sn't (claim to) prevent any of these - (a) through (f). What it *does* = claim is that authentication tokens obtained as a side effect of such attac= ks won't be usable by anyone other than the legitimate client to which = they were issued.=C2=A0</span></div><div><span style=3D"line-height:1.5"><b= r></span></div><div><span style=3D"line-height:1.5">For an attacker to be a= ble to successfully use a stolen authentication token, he would have to pro= duce a legitimate signature over the EKM of a new connection, using the cli= ent's private key. Since none of the attacks assume that the attacker a= ctually knows the client's private key, the attacker can only do this i= f he can create a connection to the server with an EKM that is identical to= previous connection (and re-use a previous signature). It's not suffic= ient to *know* what the MS (and EKM) of that previous connection is - he mu= st be able to *establish a new connection* with that same EKM with the serv= er (so that he can re-play a previous signature to that server). Are you sa= ying that (d) through (f) allow the attacker to do that?</span></div><div d= ir=3D"ltr"><div><span style=3D"line-height:1.5"><br></span></div><div>Dirk.= </div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">= On Tue, Mar 22, 2016 at 10:44 AM Andrei Popov <<a href=3D"mailto:Andrei.= Popov@microsoft.com" target=3D"_blank">Andrei.Popov@microsoft.com</a>> w= rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex">Thanks for reviewing the I-Ds= , Karthik.<br> <br> (d), (e) and (f) essentially involve total breakage of TLS. Truly, if one&#= 39;s binding is to a completely broken TLS channel, then the binding does n= ot help at all. This seems to be fairly obvious, but perhaps we can add thi= s caveat to the security considerations if the group believes it's usef= ul.<br> <br> Cheers,<br> <br> Andrei<br> <br> -----Original Message-----<br> From: Unbearable [mailto:<a href=3D"mailto:unbearable-bounces@ietf.org" tar= get=3D"_blank">unbearable-bounces@ietf.org</a>] On Behalf Of Karthik Bharga= van<br> Sent: Tuesday, March 22, 2016 9:37 AM<br> To: <a href=3D"mailto:unbearable@ietf.org" target=3D"_blank">unbearable@iet= f.org</a><br> Subject: [Unbearable] Limitations to Man-in-the-Middle Detection in Token B= inding<br> <br> I was staring at the latest draft of draft-ietf-tokbind-https-03 and the te= xt on man-in-the-middle detection in Section 4.3 seems a bit too strong, an= d I would suggest adding caveats here, or in the security considerations.<b= r> <br> By using EKM, and by relying on extended master secret, the token binding p= rotocol indeed protects against MitM attacks where either<br> (a) the attacker has a mis-issued certificate for the server (token consume= r or token provider), or<br> (b) the attacker has fooled the user agent into accepting a bogus certifica= te for the server, or<br> (c) the attacker is a malicious server who is seeking to forward the user= =E2=80=99s token to a different server.<br> <br> However, there are other MitM scenarios that are not protected by Token Bin= ding<br> (d) if the server=E2=80=99s certificate private key is compromised and the = TLS connection between the client and server uses RSA key transport,<br> =C2=A0 =C2=A0then the attacker can tamper with the connection (and hence wi= th the Token Binding HTTPS headers) without being detected<br> (e) if the server is vulnerable to RSA Bleichenbacher attacks (as in Drown)= ,<br> =C2=A0 =C2=A0then the attacker can obtain the PMS, hence the MS, and again = tamper with the application data without being detected<br> (f)=C2=A0 if the attacker obtains the session master secret between the cli= ent and server,<br> =C2=A0 =C2=A0either by stealing it from a session cache, or by breaking the= ticket encryption key,<br> =C2=A0 =C2=A0then in subsequent resumption handshakes the attacker can tamp= er with the application data without being detected.<br> <br> These last three scenarios are undoubtedly very strong attackers and may be= out-of-scope for Token Binding, but I think it is important not to give th= e impression that the use of EKM + EMS in token binding will prevent all Mi= tM attacks on TLS.<br> <br> If it is indeed important to prevent (d,e,f), then Token Binding should fur= ther recommend that the TLS client or server should only enable forward-sec= ure DHE/ECDHE ciphersuites=C2=A0 (this is what ChannelId did) and warn abou= t the risks of compromised session secrets or ticket encryption keys.<br> <br> Best,<br> Karthik<br> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f= %2fwww.ietf.org%2fmailman%2flistinfo%2funbearable%0a&data=3D01%7c01%7cA= ndrei.Popov%40microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988bf86= f141af91ab2d7cd011db47%7c1&sdata=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2Jp= DkNrSnAvU%3d" rel=3D"noreferrer" target=3D"_blank">https://na01.safelinks.p= rotection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf.org%2fmailman%2flistinf= o%2funbearable%0a&data=3D01%7c01%7cAndrei.Popov%40microsoft.com%7c568fb= ff72db649424d3208d35270383b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdat= a=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2JpDkNrSnAvU%3d</a><br> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> </blockquote></div></div> --089e011823a03c8ceb052ea733c3-- From nobody Tue Mar 22 11:32:49 2016 Return-Path: <karthikeyan.bhargavan@inria.fr> 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 D8F6312D770 for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 11:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 k7DMO2IXfmXc for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 11:32:45 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E2112D132 for <unbearable@ietf.org>; Tue, 22 Mar 2016 11:32:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,378,1454972400"; d="scan'208,217";a="170241172" Received: from 89-156-8-219.rev.numericable.fr (HELO [192.168.0.16]) ([89.156.8.219]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Mar 2016 19:32:43 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_2C29A0B0-D8AC-4C9E-AF73-5BB8D8B0DA3B" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr> In-Reply-To: <CADHfa2DbV1pAm6-Da26WFUs0dA4NA7OjZwvn4mc195pFR9pqjw@mail.gmail.com> Date: Tue, 22 Mar 2016 19:32:42 +0100 Message-Id: <A671F64C-124B-453F-B066-426984AD32E8@inria.fr> References: <099CAE22-2ED5-447B-BE5B-92CD4F5EFAD5@inria.fr> <BLUPR03MB13967C3EEAB0B0FEAF0D3AD18C800@BLUPR03MB1396.namprd03.prod.outlook.com> <CADHfa2DbV1pAm6-Da26WFUs0dA4NA7OjZwvn4mc195pFR9pqjw@mail.gmail.com> To: Dirk Balfanz <balfanz@google.com> X-Mailer: Apple Mail (2.3112) Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/ndle26IYXOpuJPUyAC80c-rs-_Q> Cc: "unbearable@ietf.org" <unbearable@ietf.org>, Andrei Popov <Andrei.Popov@microsoft.com>, Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr> Subject: Re: [Unbearable] Limitations to Man-in-the-Middle Detection in Token Binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Mar 2016 18:32:48 -0000 --Apple-Mail=_2C29A0B0-D8AC-4C9E-AF73-5BB8D8B0DA3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Dirk, Andrei, To be clear, I am not really claiming that Token Binding should protect = against these kinds of attacks, because as Andrei points out, a binding to a broken channel is not all = that useful.=20 I am mainly concerned that the text in 4.3 referring to a = man-in-the-middle attacker may need to be toned down to clarify what kinds of man-in-the-middle attackers = can be detected by binding mismatch. For example, if the server=E2=80=99s certificate private key is known to = the attacker, then he can mount a man-in-the-middle attack where he relays all TLS handshake messages = unchanged to the real server, resulting in the same EKM on both connections. At this = point Token Binding cannot detect the attacker. (Of course, this kind of attacker can break RSA = connections at leisure and is quite powerful.) Similarly, an attacker who knows the MS can MitM a resumption handshake = in a way that the EKM on both connections is the same.=20 Perhaps surprisingly, forward-secure TLS handshakes (such as ECDHE/DHE) = cannot obviously be attacked this way, but resumption and RSA can. That is all I meant to indicate. Best, Karthik > On 22 Mar 2016, at 19:15, Dirk Balfanz <balfanz@google.com> wrote: >=20 > Hi Karthik,=20 >=20 > can you explain a little more? Token Binding doesn't (claim to) = prevent any of these - (a) through (f). What it *does* claim is that = authentication tokens obtained as a side effect of such attacks won't be = usable by anyone other than the legitimate client to which they were = issued.=20 >=20 > For an attacker to be able to successfully use a stolen authentication = token, he would have to produce a legitimate signature over the EKM of a = new connection, using the client's private key. Since none of the = attacks assume that the attacker actually knows the client's private = key, the attacker can only do this if he can create a connection to the = server with an EKM that is identical to previous connection (and re-use = a previous signature). It's not sufficient to *know* what the MS (and = EKM) of that previous connection is - he must be able to *establish a = new connection* with that same EKM with the server (so that he can = re-play a previous signature to that server). Are you saying that (d) = through (f) allow the attacker to do that? >=20 > Dirk. >=20 >=20 > On Tue, Mar 22, 2016 at 10:44 AM Andrei Popov = <Andrei.Popov@microsoft.com <mailto:Andrei.Popov@microsoft.com>> wrote: > Thanks for reviewing the I-Ds, Karthik. >=20 > (d), (e) and (f) essentially involve total breakage of TLS. Truly, if = one's binding is to a completely broken TLS channel, then the binding = does not help at all. This seems to be fairly obvious, but perhaps we = can add this caveat to the security considerations if the group believes = it's useful. >=20 > Cheers, >=20 > Andrei >=20 > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org = <mailto:unbearable-bounces@ietf.org>] On Behalf Of Karthik Bhargavan > Sent: Tuesday, March 22, 2016 9:37 AM > To: unbearable@ietf.org <mailto:unbearable@ietf.org> > Subject: [Unbearable] Limitations to Man-in-the-Middle Detection in = Token Binding >=20 > I was staring at the latest draft of draft-ietf-tokbind-https-03 and = the text on man-in-the-middle detection in Section 4.3 seems a bit too = strong, and I would suggest adding caveats here, or in the security = considerations. >=20 > By using EKM, and by relying on extended master secret, the token = binding protocol indeed protects against MitM attacks where either > (a) the attacker has a mis-issued certificate for the server (token = consumer or token provider), or > (b) the attacker has fooled the user agent into accepting a bogus = certificate for the server, or > (c) the attacker is a malicious server who is seeking to forward the = user=E2=80=99s token to a different server. >=20 > However, there are other MitM scenarios that are not protected by = Token Binding > (d) if the server=E2=80=99s certificate private key is compromised and = the TLS connection between the client and server uses RSA key transport, > then the attacker can tamper with the connection (and hence with = the Token Binding HTTPS headers) without being detected > (e) if the server is vulnerable to RSA Bleichenbacher attacks (as in = Drown), > then the attacker can obtain the PMS, hence the MS, and again = tamper with the application data without being detected > (f) if the attacker obtains the session master secret between the = client and server, > either by stealing it from a session cache, or by breaking the = ticket encryption key, > then in subsequent resumption handshakes the attacker can tamper = with the application data without being detected. >=20 > These last three scenarios are undoubtedly very strong attackers and = may be out-of-scope for Token Binding, but I think it is important not = to give the impression that the use of EKM + EMS in token binding will = prevent all MitM attacks on TLS. >=20 > If it is indeed important to prevent (d,e,f), then Token Binding = should further recommend that the TLS client or server should only = enable forward-secure DHE/ECDHE ciphersuites (this is what ChannelId = did) and warn about the risks of compromised session secrets or ticket = encryption keys. >=20 > Best, > Karthik > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org <mailto:Unbearable@ietf.org> > = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.iet= f.org%2fmailman%2flistinfo%2funbearable%0a&data=3D01%7c01%7cAndrei.Popov%4= 0microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988bf86f141af91ab2d= 7cd011db47%7c1&sdata=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2JpDkNrSnAvU%3d = <https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2fmailman%2flistinfo%2funbearable%0a&data=3D01%7c01%7cAndrei.Popov%= 40microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988bf86f141af91ab2= d7cd011db47%7c1&sdata=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2JpDkNrSnAvU%3d> > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org <mailto:Unbearable@ietf.org> > https://www.ietf.org/mailman/listinfo/unbearable = <https://www.ietf.org/mailman/listinfo/unbearable> --Apple-Mail=_2C29A0B0-D8AC-4C9E-AF73-5BB8D8B0DA3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D"">Hi Dirk, Andrei,<div class=3D""><br class=3D""></div><div = class=3D"">To be clear, I am not really claiming that Token Binding = should protect against these kinds of attacks,</div><div = class=3D"">because as Andrei points out, a binding to a broken channel = is not all that useful. </div><div class=3D"">I am mainly concerned = that the text in 4.3 referring to a man-in-the-middle attacker may = need</div><div class=3D"">to be toned down to clarify what kinds of = man-in-the-middle attackers can be detected by binding = mismatch.</div><div class=3D""><br class=3D""></div><div class=3D"">For = example, if the server=E2=80=99s certificate private key is known to the = attacker, then he can mount</div><div class=3D"">a man-in-the-middle = attack where he relays all TLS handshake messages unchanged to = the</div><div class=3D"">real server, resulting in the same EKM on both = connections. At this point Token Binding cannot</div><div = class=3D"">detect the attacker. (Of course, this kind of attacker can = break RSA connections at leisure and is quite powerful.)</div><div = class=3D""><br class=3D""></div><div class=3D"">Similarly, an attacker = who knows the MS can MitM a resumption handshake in a way that the EKM = on</div><div class=3D"">both connections is the same. </div><div = class=3D""><br class=3D""></div><div class=3D"">Perhaps surprisingly, = forward-secure TLS handshakes (such as ECDHE/DHE) cannot obviously be = attacked this</div><div class=3D"">way, but resumption and RSA can. That = is all I meant to indicate.</div><div class=3D""><br class=3D""></div><div= class=3D"">Best,</div><div class=3D"">Karthik</div><div class=3D""><br = class=3D""></div><div class=3D""><br class=3D""></div><div class=3D""><br = class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On = 22 Mar 2016, at 19:15, Dirk Balfanz <<a = href=3D"mailto:balfanz@google.com" class=3D"">balfanz@google.com</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = dir=3D"ltr" class=3D""><div class=3D"">Hi Karthik, </div><div = class=3D""><br class=3D""></div><div class=3D"">can you explain a little = more? <span style=3D"line-height:1.5" class=3D"">Token Binding = doesn't (claim to) prevent any of these - (a) through (f). What it = *does* claim is that authentication tokens obtained as a side effect of = such attacks won't be usable by anyone other than the legitimate client = to which they were issued. </span></div><div class=3D""><span = style=3D"line-height:1.5" class=3D""><br class=3D""></span></div><div = class=3D""><span style=3D"line-height:1.5" class=3D"">For an attacker to = be able to successfully use a stolen authentication token, he would have = to produce a legitimate signature over the EKM of a new connection, = using the client's private key. Since none of the attacks assume that = the attacker actually knows the client's private key, the attacker can = only do this if he can create a connection to the server with an EKM = that is identical to previous connection (and re-use a previous = signature). It's not sufficient to *know* what the MS (and EKM) of that = previous connection is - he must be able to *establish a new connection* = with that same EKM with the server (so that he can re-play a previous = signature to that server). Are you saying that (d) through (f) allow the = attacker to do that?</span></div><div dir=3D"ltr" class=3D""><div = class=3D""><span style=3D"line-height:1.5" class=3D""><br = class=3D""></span></div><div class=3D"">Dirk.</div><div class=3D""><br = class=3D""></div></div><br class=3D""><div class=3D"gmail_quote"><div = dir=3D"ltr" class=3D"">On Tue, Mar 22, 2016 at 10:44 AM Andrei Popov = <<a href=3D"mailto:Andrei.Popov@microsoft.com" target=3D"_blank" = class=3D"">Andrei.Popov@microsoft.com</a>> wrote:<br = class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for reviewing = the I-Ds, Karthik.<br class=3D""> <br class=3D""> (d), (e) and (f) essentially involve total breakage of TLS. Truly, if = one's binding is to a completely broken TLS channel, then the binding = does not help at all. This seems to be fairly obvious, but perhaps we = can add this caveat to the security considerations if the group believes = it's useful.<br class=3D""> <br class=3D""> Cheers,<br class=3D""> <br class=3D""> Andrei<br class=3D""> <br class=3D""> -----Original Message-----<br class=3D""> From: Unbearable [mailto:<a href=3D"mailto:unbearable-bounces@ietf.org" = target=3D"_blank" class=3D"">unbearable-bounces@ietf.org</a>] On Behalf = Of Karthik Bhargavan<br class=3D""> Sent: Tuesday, March 22, 2016 9:37 AM<br class=3D""> To: <a href=3D"mailto:unbearable@ietf.org" target=3D"_blank" = class=3D"">unbearable@ietf.org</a><br class=3D""> Subject: [Unbearable] Limitations to Man-in-the-Middle Detection in = Token Binding<br class=3D""> <br class=3D""> I was staring at the latest draft of draft-ietf-tokbind-https-03 and the = text on man-in-the-middle detection in Section 4.3 seems a bit too = strong, and I would suggest adding caveats here, or in the security = considerations.<br class=3D""> <br class=3D""> By using EKM, and by relying on extended master secret, the token = binding protocol indeed protects against MitM attacks where either<br = class=3D""> (a) the attacker has a mis-issued certificate for the server (token = consumer or token provider), or<br class=3D""> (b) the attacker has fooled the user agent into accepting a bogus = certificate for the server, or<br class=3D""> (c) the attacker is a malicious server who is seeking to forward the = user=E2=80=99s token to a different server.<br class=3D""> <br class=3D""> However, there are other MitM scenarios that are not protected by Token = Binding<br class=3D""> (d) if the server=E2=80=99s certificate private key is compromised and = the TLS connection between the client and server uses RSA key = transport,<br class=3D"">    then the attacker can tamper with the connection (and hence = with the Token Binding HTTPS headers) without being detected<br = class=3D""> (e) if the server is vulnerable to RSA Bleichenbacher attacks (as in = Drown),<br class=3D"">    then the attacker can obtain the PMS, hence the MS, and = again tamper with the application data without being detected<br = class=3D""> (f)  if the attacker obtains the session master secret between the = client and server,<br class=3D"">    either by stealing it from a session cache, or by breaking = the ticket encryption key,<br class=3D"">    then in subsequent resumption handshakes the attacker can = tamper with the application data without being detected.<br class=3D""> <br class=3D""> These last three scenarios are undoubtedly very strong attackers and may = be out-of-scope for Token Binding, but I think it is important not to = give the impression that the use of EKM + EMS in token binding will = prevent all MitM attacks on TLS.<br class=3D""> <br class=3D""> If it is indeed important to prevent (d,e,f), then Token Binding should = further recommend that the TLS client or server should only enable = forward-secure DHE/ECDHE ciphersuites  (this is what ChannelId did) = and warn about the risks of compromised session secrets or ticket = encryption keys.<br class=3D""> <br class=3D""> Best,<br class=3D""> Karthik<br class=3D""> _______________________________________________<br class=3D""> Unbearable mailing list<br class=3D""> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank" = class=3D"">Unbearable@ietf.org</a><br class=3D""> <a = href=3D"https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2= fwww.ietf.org%2fmailman%2flistinfo%2funbearable%0a&data=3D01%7c01%7cAn= drei.Popov%40microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988bf86= f141af91ab2d7cd011db47%7c1&sdata=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2J= pDkNrSnAvU%3d" rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2= f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable%0a&data=3D01%7c01%7= cAndrei.Popov%40microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988b= f86f141af91ab2d7cd011db47%7c1&sdata=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2= N2JpDkNrSnAvU%3d</a><br class=3D""> _______________________________________________<br class=3D""> Unbearable mailing list<br class=3D""> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank" = class=3D"">Unbearable@ietf.org</a><br class=3D""> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" = rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://www.ietf.org/mailman/listinfo/unbearable</a><br = class=3D""> </blockquote></div></div> </div></blockquote></div><br class=3D""></div></body></html>= --Apple-Mail=_2C29A0B0-D8AC-4C9E-AF73-5BB8D8B0DA3B-- From nobody Tue Mar 22 12:21:52 2016 Return-Path: <karthikeyan.bhargavan@inria.fr> 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 61DDD12D7D6 for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 12:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.911 X-Spam-Level: X-Spam-Status: No, score=-4.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 KZQDXRoGstjR for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 12:21:48 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D7B12D7A4 for <unbearable@ietf.org>; Tue, 22 Mar 2016 12:21:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,378,1454972400"; d="scan'208,217";a="170247034" Received: from 89-156-8-219.rev.numericable.fr (HELO [192.168.0.16]) ([89.156.8.219]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Mar 2016 20:21:45 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_843D2367-850F-491F-8E2A-88EC1E1BBBE2" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr> In-Reply-To: <CADHfa2DbV1pAm6-Da26WFUs0dA4NA7OjZwvn4mc195pFR9pqjw@mail.gmail.com> Date: Tue, 22 Mar 2016 20:21:44 +0100 Message-Id: <111E07FD-0182-4EA1-A753-69B84C243F05@inria.fr> References: <099CAE22-2ED5-447B-BE5B-92CD4F5EFAD5@inria.fr> <BLUPR03MB13967C3EEAB0B0FEAF0D3AD18C800@BLUPR03MB1396.namprd03.prod.outlook.com> <CADHfa2DbV1pAm6-Da26WFUs0dA4NA7OjZwvn4mc195pFR9pqjw@mail.gmail.com> To: Dirk Balfanz <balfanz@google.com> X-Mailer: Apple Mail (2.3112) Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/5o6Y4T__DWrN_yZLd0j2ubnCEz8> Cc: "unbearable@ietf.org" <unbearable@ietf.org>, Andrei Popov <Andrei.Popov@microsoft.com>, Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr> Subject: Re: [Unbearable] Limitations to Man-in-the-Middle Detection in Token Binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Mar 2016 19:21:50 -0000 --Apple-Mail=_843D2367-850F-491F-8E2A-88EC1E1BBBE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > For an attacker to be able to successfully use a stolen authentication = token, he would have to produce a legitimate signature over the EKM of a = new connection, using the client's private key. Since none of the = attacks assume that the attacker actually knows the client's private = key, the attacker can only do this if he can create a connection to the = server with an EKM that is identical to previous connection (and re-use = a previous signature). It's not sufficient to *know* what the MS (and = EKM) of that previous connection is - he must be able to *establish a = new connection* with that same EKM with the server (so that he can = re-play a previous signature to that server). Are you saying that (d) = through (f) allow the attacker to do that? I am saying that there are certain powerful attackers (d-f) that can = persistently MitM connections between the client and the server. In that case, they don=E2=80=99t need to now the client=E2=80=99s = private key, they can simply forward the client=E2=80=99s signature over = the EKM along with=20 the token-bound credentials to the server, and then freely tamper with = the connection afterward. =20 This is an obvious =E2=80=9Cattack=E2=80=9D on the HTTPS channel and = arguably should not be Token Binding=E2=80=99s concern.=20 Perhaps this is already clear to Token Binding users, but if not, adding = a sentence to clarify the claims would perhaps be useful. -K >=20 > Dirk. >=20 >=20 > On Tue, Mar 22, 2016 at 10:44 AM Andrei Popov = <Andrei.Popov@microsoft.com <mailto:Andrei.Popov@microsoft.com>> wrote: > Thanks for reviewing the I-Ds, Karthik. >=20 > (d), (e) and (f) essentially involve total breakage of TLS. Truly, if = one's binding is to a completely broken TLS channel, then the binding = does not help at all. This seems to be fairly obvious, but perhaps we = can add this caveat to the security considerations if the group believes = it's useful. >=20 > Cheers, >=20 > Andrei >=20 > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org = <mailto:unbearable-bounces@ietf.org>] On Behalf Of Karthik Bhargavan > Sent: Tuesday, March 22, 2016 9:37 AM > To: unbearable@ietf.org <mailto:unbearable@ietf.org> > Subject: [Unbearable] Limitations to Man-in-the-Middle Detection in = Token Binding >=20 > I was staring at the latest draft of draft-ietf-tokbind-https-03 and = the text on man-in-the-middle detection in Section 4.3 seems a bit too = strong, and I would suggest adding caveats here, or in the security = considerations. >=20 > By using EKM, and by relying on extended master secret, the token = binding protocol indeed protects against MitM attacks where either > (a) the attacker has a mis-issued certificate for the server (token = consumer or token provider), or > (b) the attacker has fooled the user agent into accepting a bogus = certificate for the server, or > (c) the attacker is a malicious server who is seeking to forward the = user=E2=80=99s token to a different server. >=20 > However, there are other MitM scenarios that are not protected by = Token Binding > (d) if the server=E2=80=99s certificate private key is compromised and = the TLS connection between the client and server uses RSA key transport, > then the attacker can tamper with the connection (and hence with = the Token Binding HTTPS headers) without being detected > (e) if the server is vulnerable to RSA Bleichenbacher attacks (as in = Drown), > then the attacker can obtain the PMS, hence the MS, and again = tamper with the application data without being detected > (f) if the attacker obtains the session master secret between the = client and server, > either by stealing it from a session cache, or by breaking the = ticket encryption key, > then in subsequent resumption handshakes the attacker can tamper = with the application data without being detected. >=20 > These last three scenarios are undoubtedly very strong attackers and = may be out-of-scope for Token Binding, but I think it is important not = to give the impression that the use of EKM + EMS in token binding will = prevent all MitM attacks on TLS. >=20 > If it is indeed important to prevent (d,e,f), then Token Binding = should further recommend that the TLS client or server should only = enable forward-secure DHE/ECDHE ciphersuites (this is what ChannelId = did) and warn about the risks of compromised session secrets or ticket = encryption keys. >=20 > Best, > Karthik > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org <mailto:Unbearable@ietf.org> > = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.iet= f.org%2fmailman%2flistinfo%2funbearable%0a&data=3D01%7c01%7cAndrei.Popov%4= 0microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988bf86f141af91ab2d= 7cd011db47%7c1&sdata=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2JpDkNrSnAvU%3d = <https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2fmailman%2flistinfo%2funbearable%0a&data=3D01%7c01%7cAndrei.Popov%= 40microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988bf86f141af91ab2= d7cd011db47%7c1&sdata=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2JpDkNrSnAvU%3d> > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org <mailto:Unbearable@ietf.org> > https://www.ietf.org/mailman/listinfo/unbearable = <https://www.ietf.org/mailman/listinfo/unbearable> --Apple-Mail=_843D2367-850F-491F-8E2A-88EC1E1BBBE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"ltr" class=3D""><div class=3D""><span style=3D"line-height:1.5" = class=3D"">For an attacker to be able to successfully use a stolen = authentication token, he would have to produce a legitimate signature = over the EKM of a new connection, using the client's private key. Since = none of the attacks assume that the attacker actually knows the client's = private key, the attacker can only do this if he can create a connection = to the server with an EKM that is identical to previous connection (and = re-use a previous signature). It's not sufficient to *know* what the MS = (and EKM) of that previous connection is - he must be able to *establish = a new connection* with that same EKM with the server (so that he can = re-play a previous signature to that server). Are you saying that (d) = through (f) allow the attacker to do = that?</span></div></div></div></blockquote><div><br = class=3D""></div><div>I am saying that there are certain powerful = attackers (d-f) that can persistently MitM connections between the = client and the server.</div><div>In that case, they don=E2=80=99t need = to now the client=E2=80=99s private key, they can simply forward the = client=E2=80=99s signature over the EKM along with </div><div>the = token-bound credentials to the server, and then freely tamper with the = connection afterward.  </div><div>This is an obvious =E2=80=9Cattack=E2= =80=9D on the HTTPS channel and arguably should not be Token Binding=E2=80= =99s concern. </div><div>Perhaps this is already clear to Token = Binding users, but if not, adding a sentence to clarify the claims would = perhaps be useful.</div><div><br class=3D""></div><div>-K</div><div><br = class=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D""><div dir=3D"ltr" class=3D""><div dir=3D"ltr" class=3D""><div = class=3D""><span style=3D"line-height:1.5" class=3D""><br = class=3D""></span></div><div class=3D"">Dirk.</div><div class=3D""><br = class=3D""></div></div><br class=3D""><div class=3D"gmail_quote"><div = dir=3D"ltr" class=3D"">On Tue, Mar 22, 2016 at 10:44 AM Andrei Popov = <<a href=3D"mailto:Andrei.Popov@microsoft.com" target=3D"_blank" = class=3D"">Andrei.Popov@microsoft.com</a>> wrote:<br = class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for reviewing = the I-Ds, Karthik.<br class=3D""> <br class=3D""> (d), (e) and (f) essentially involve total breakage of TLS. Truly, if = one's binding is to a completely broken TLS channel, then the binding = does not help at all. This seems to be fairly obvious, but perhaps we = can add this caveat to the security considerations if the group believes = it's useful.<br class=3D""> <br class=3D""> Cheers,<br class=3D""> <br class=3D""> Andrei<br class=3D""> <br class=3D""> -----Original Message-----<br class=3D""> From: Unbearable [mailto:<a href=3D"mailto:unbearable-bounces@ietf.org" = target=3D"_blank" class=3D"">unbearable-bounces@ietf.org</a>] On Behalf = Of Karthik Bhargavan<br class=3D""> Sent: Tuesday, March 22, 2016 9:37 AM<br class=3D""> To: <a href=3D"mailto:unbearable@ietf.org" target=3D"_blank" = class=3D"">unbearable@ietf.org</a><br class=3D""> Subject: [Unbearable] Limitations to Man-in-the-Middle Detection in = Token Binding<br class=3D""> <br class=3D""> I was staring at the latest draft of draft-ietf-tokbind-https-03 and the = text on man-in-the-middle detection in Section 4.3 seems a bit too = strong, and I would suggest adding caveats here, or in the security = considerations.<br class=3D""> <br class=3D""> By using EKM, and by relying on extended master secret, the token = binding protocol indeed protects against MitM attacks where either<br = class=3D""> (a) the attacker has a mis-issued certificate for the server (token = consumer or token provider), or<br class=3D""> (b) the attacker has fooled the user agent into accepting a bogus = certificate for the server, or<br class=3D""> (c) the attacker is a malicious server who is seeking to forward the = user=E2=80=99s token to a different server.<br class=3D""> <br class=3D""> However, there are other MitM scenarios that are not protected by Token = Binding<br class=3D""> (d) if the server=E2=80=99s certificate private key is compromised and = the TLS connection between the client and server uses RSA key = transport,<br class=3D"">    then the attacker can tamper with the connection (and hence = with the Token Binding HTTPS headers) without being detected<br = class=3D""> (e) if the server is vulnerable to RSA Bleichenbacher attacks (as in = Drown),<br class=3D"">    then the attacker can obtain the PMS, hence the MS, and = again tamper with the application data without being detected<br = class=3D""> (f)  if the attacker obtains the session master secret between the = client and server,<br class=3D"">    either by stealing it from a session cache, or by breaking = the ticket encryption key,<br class=3D"">    then in subsequent resumption handshakes the attacker can = tamper with the application data without being detected.<br class=3D""> <br class=3D""> These last three scenarios are undoubtedly very strong attackers and may = be out-of-scope for Token Binding, but I think it is important not to = give the impression that the use of EKM + EMS in token binding will = prevent all MitM attacks on TLS.<br class=3D""> <br class=3D""> If it is indeed important to prevent (d,e,f), then Token Binding should = further recommend that the TLS client or server should only enable = forward-secure DHE/ECDHE ciphersuites  (this is what ChannelId did) = and warn about the risks of compromised session secrets or ticket = encryption keys.<br class=3D""> <br class=3D""> Best,<br class=3D""> Karthik<br class=3D""> _______________________________________________<br class=3D""> Unbearable mailing list<br class=3D""> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank" = class=3D"">Unbearable@ietf.org</a><br class=3D""> <a = href=3D"https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2= fwww.ietf.org%2fmailman%2flistinfo%2funbearable%0a&data=3D01%7c01%7cAn= drei.Popov%40microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988bf86= f141af91ab2d7cd011db47%7c1&sdata=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2J= pDkNrSnAvU%3d" rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2= f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable%0a&data=3D01%7c01%7= cAndrei.Popov%40microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988b= f86f141af91ab2d7cd011db47%7c1&sdata=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2= N2JpDkNrSnAvU%3d</a><br class=3D""> _______________________________________________<br class=3D""> Unbearable mailing list<br class=3D""> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank" = class=3D"">Unbearable@ietf.org</a><br class=3D""> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" = rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://www.ietf.org/mailman/listinfo/unbearable</a><br = class=3D""> </blockquote></div></div> </div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_843D2367-850F-491F-8E2A-88EC1E1BBBE2-- From nobody Tue Mar 22 12:28:53 2016 Return-Path: <vanupam@google.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 34A8312D796 for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 12:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 0e1q9PZgrZgw for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 12:28:48 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF9312D6E0 for <unbearable@ietf.org>; Tue, 22 Mar 2016 12:28:47 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id p65so206424409wmp.1 for <unbearable@ietf.org>; Tue, 22 Mar 2016 12:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=2NqZ9ILbVgJ6TRnt4wumv4KSu7w2RIajnitd3yzUk4I=; b=eJTklK2SzX3cSUPsBHeLkUPEICMNeeXuO19GEmN1R+O4mOeT7UAQ7KgY646TzEAPdd QGsPyR2cMEuJlCHxo0cifnxrxPIkxH7Ur5cMm+/dlRJ88VGRoXFZtcOc3cYIpchsYgU4 hMzlGX8HT2TR39+wNytRYNCFKvVLZCs+WMqv8VKchdVaCyVFGFsYsRM1mDrQLJnHDPEt YbcvTzJ9YQ/hdT4q5y68ViPcVEPkXYScyj13+8njgl84KbfKYVPIh4pDgkzbtZS7sSo0 iUwL0g5fpmluh5WMOFjAsxbKS8LjM1IuQJyZsuG+xrpAfHwQHed+baBCxgFVG6XyLZpk Zu0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2NqZ9ILbVgJ6TRnt4wumv4KSu7w2RIajnitd3yzUk4I=; b=KC4aRbMz3euNV0WcokM5YJeJMKsnGgTSMGRlC6jDNW2jIUtNl7NDuAErQcdwWIfVVu hGjn8A8MRxHM6I+571BUTvvVWSTwBRgU2xTFHb+G1PPQzQDCZFBaAiR6x9BDsnFyCG0h az2uuxWACQY0rDC4o3RZN0e935bFl4wqzAh+FMdkEM9/iMRcPlPXh9P6twbfIxBAegRH +k9f7qjh2z4ETwwkTzYF2rdA0BcbhA8rccITS/oijCh5smQlnJbUJl7FqrwxOuLWgCIz 4dGLoEQ3/rS6KiVYm6L73fxvA4SbsP9QgvmFVrDfxikCHQ+gDzM/Mm9UwIuNU40nZ01k 0oeg== X-Gm-Message-State: AD7BkJLWqdkYg6SnyBKH90gsCS3KMcaUoZifUlXV0xSAzr8q/yX5hFljKFXxwHdHaEs2+/ZTV3GDUG0tU4rjviNL MIME-Version: 1.0 X-Received: by 10.28.142.213 with SMTP id q204mr20997759wmd.69.1458674925947; Tue, 22 Mar 2016 12:28:45 -0700 (PDT) Received: by 10.28.184.201 with HTTP; Tue, 22 Mar 2016 12:28:45 -0700 (PDT) In-Reply-To: <111E07FD-0182-4EA1-A753-69B84C243F05@inria.fr> References: <099CAE22-2ED5-447B-BE5B-92CD4F5EFAD5@inria.fr> <BLUPR03MB13967C3EEAB0B0FEAF0D3AD18C800@BLUPR03MB1396.namprd03.prod.outlook.com> <CADHfa2DbV1pAm6-Da26WFUs0dA4NA7OjZwvn4mc195pFR9pqjw@mail.gmail.com> <111E07FD-0182-4EA1-A753-69B84C243F05@inria.fr> Date: Tue, 22 Mar 2016 12:28:45 -0700 Message-ID: <CAOVPt=vRbzU6qdHJuLvqFHU8=C+bhnKE4RcdqY04YEeP+Lc2Gg@mail.gmail.com> From: Vinod Anupam <vanupam@google.com> To: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr> Content-Type: multipart/alternative; boundary=001a11442ef8ce1401052ea83825 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/_vFjB4qss6CRfx5ni4WKvkij4FE> Cc: "unbearable@ietf.org" <unbearable@ietf.org>, Dirk Balfanz <balfanz@google.com>, Andrei Popov <Andrei.Popov@microsoft.com> Subject: Re: [Unbearable] Limitations to Man-in-the-Middle Detection in Token Binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Mar 2016 19:28:52 -0000 --001a11442ef8ce1401052ea83825 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 22, 2016 at 12:21 PM, Karthik Bhargavan < karthikeyan.bhargavan@inria.fr> wrote: > For an attacker to be able to successfully use a stolen authentication > token, he would have to produce a legitimate signature over the EKM of a > new connection, using the client's private key. Since none of the attacks > assume that the attacker actually knows the client's private key, the > attacker can only do this if he can create a connection to the server wit= h > an EKM that is identical to previous connection (and re-use a previous > signature). It's not sufficient to *know* what the MS (and EKM) of that > previous connection is - he must be able to *establish a new connection* > with that same EKM with the server (so that he can re-play a previous > signature to that server). Are you saying that (d) through (f) allow the > attacker to do that? > > > I am saying that there are certain powerful attackers (d-f) that can > persistently MitM connections between the client and the server. > In that case, they don=E2=80=99t need to now the client=E2=80=99s private= key, they can > simply forward the client=E2=80=99s signature over the EKM along with > the token-bound credentials to the server, and then freely tamper with th= e > connection afterward. > This is an obvious =E2=80=9Cattack=E2=80=9D on the HTTPS channel and argu= ably should not > be Token Binding=E2=80=99s concern. > Perhaps this is already clear to Token Binding users, but if not, adding = a > sentence to clarify the claims would perhaps be useful. > > -K > > > Per https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-02, Token Binding negotiation requires that Extended Master Secret [RFC7627] and Renegotiation Indication [RFC5746] TLS extensions have also been negotiated= . Does that not address the attack that you are referring to? cheers, -Anupam > > Dirk. > > > On Tue, Mar 22, 2016 at 10:44 AM Andrei Popov <Andrei.Popov@microsoft.com= > > wrote: > >> Thanks for reviewing the I-Ds, Karthik. >> >> (d), (e) and (f) essentially involve total breakage of TLS. Truly, if >> one's binding is to a completely broken TLS channel, then the binding do= es >> not help at all. This seems to be fairly obvious, but perhaps we can add >> this caveat to the security considerations if the group believes it's >> useful. >> >> Cheers, >> >> Andrei >> >> -----Original Message----- >> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of >> Karthik Bhargavan >> Sent: Tuesday, March 22, 2016 9:37 AM >> To: unbearable@ietf.org >> Subject: [Unbearable] Limitations to Man-in-the-Middle Detection in Toke= n >> Binding >> >> I was staring at the latest draft of draft-ietf-tokbind-https-03 and the >> text on man-in-the-middle detection in Section 4.3 seems a bit too stron= g, >> and I would suggest adding caveats here, or in the security consideratio= ns. >> >> By using EKM, and by relying on extended master secret, the token bindin= g >> protocol indeed protects against MitM attacks where either >> (a) the attacker has a mis-issued certificate for the server (token >> consumer or token provider), or >> (b) the attacker has fooled the user agent into accepting a bogus >> certificate for the server, or >> (c) the attacker is a malicious server who is seeking to forward the >> user=E2=80=99s token to a different server. >> >> However, there are other MitM scenarios that are not protected by Token >> Binding >> (d) if the server=E2=80=99s certificate private key is compromised and t= he TLS >> connection between the client and server uses RSA key transport, >> then the attacker can tamper with the connection (and hence with the >> Token Binding HTTPS headers) without being detected >> (e) if the server is vulnerable to RSA Bleichenbacher attacks (as in >> Drown), >> then the attacker can obtain the PMS, hence the MS, and again tamper >> with the application data without being detected >> (f) if the attacker obtains the session master secret between the clien= t >> and server, >> either by stealing it from a session cache, or by breaking the ticket >> encryption key, >> then in subsequent resumption handshakes the attacker can tamper with >> the application data without being detected. >> >> These last three scenarios are undoubtedly very strong attackers and may >> be out-of-scope for Token Binding, but I think it is important not to gi= ve >> the impression that the use of EKM + EMS in token binding will prevent a= ll >> MitM attacks on TLS. >> >> If it is indeed important to prevent (d,e,f), then Token Binding should >> further recommend that the TLS client or server should only enable >> forward-secure DHE/ECDHE ciphersuites (this is what ChannelId did) and >> warn about the risks of compromised session secrets or ticket encryption >> keys. >> >> Best, >> Karthik >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i= etf.org%2fmailman%2flistinfo%2funbearable%0a&data=3D01%7c01%7cAndrei.Popov%= 40microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988bf86f141af91ab2d= 7cd011db47%7c1&sdata=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2JpDkNrSnAvU%3d >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >> > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --001a11442ef8ce1401052ea83825 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div><br></div><div class=3D"gmail_extra"><br><div cla= ss=3D"gmail_quote">On Tue, Mar 22, 2016 at 12:21 PM, Karthik Bhargavan <spa= n dir=3D"ltr"><<a href=3D"mailto:karthikeyan.bhargavan@inria.fr" target= =3D"_blank">karthikeyan.bhargavan@inria.fr</a>></span> wrote:<br><blockq= uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi= dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-= left:1ex"><div style=3D"word-wrap:break-word"><div><span class=3D""><blockq= uote type=3D"cite"><div><div dir=3D"ltr"><div><span style=3D"line-height:1.= 5">For an attacker to be able to successfully use a stolen authentication t= oken, he would have to produce a legitimate signature over the EKM of a new= connection, using the client's private key. Since none of the attacks = assume that the attacker actually knows the client's private key, the a= ttacker can only do this if he can create a connection to the server with a= n EKM that is identical to previous connection (and re-use a previous signa= ture). It's not sufficient to *know* what the MS (and EKM) of that prev= ious connection is - he must be able to *establish a new connection* with t= hat same EKM with the server (so that he can re-play a previous signature t= o that server). Are you saying that (d) through (f) allow the attacker to d= o that?</span></div></div></div></blockquote><div><br></div></span><div>I a= m saying that there are certain powerful attackers (d-f) that can persisten= tly MitM connections between the client and the server.</div><div>In that c= ase, they don=E2=80=99t need to now the client=E2=80=99s private key, they = can simply forward the client=E2=80=99s signature over the EKM along with= =C2=A0</div><div>the token-bound credentials to the server, and then freely= tamper with the connection afterward. =C2=A0</div><div>This is an obvious = =E2=80=9Cattack=E2=80=9D on the HTTPS channel and arguably should not be To= ken Binding=E2=80=99s concern.=C2=A0</div><div>Perhaps this is already clea= r to Token Binding users, but if not, adding a sentence to clarify the clai= ms would perhaps be useful.</div><span class=3D""><font color=3D"#888888"><= div><br></div><div>-K</div></font></span><div><div class=3D"h5"><div><br></= div><br></div></div></div></div></blockquote><div><br></div>Per <a href=3D"= https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-02">https://tool= s.ietf.org/html/draft-ietf-tokbind-negotiation-02</a>,<div>Token Binding ne= gotiation requires that<div>Extended Master Secret=C2=A0[RFC7627] and</div>= <div>Renegotiation Indication [RFC5746] TLS extensions have=C2=A0also been = negotiated.<br></div><div><br></div></div><div>Does that not address the at= tack that you are referring to?</div><div><br></div><div>cheers,</div><div>= -Anupam</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,= 204);border-left-style:solid;padding-left:1ex"><div style=3D"word-wrap:brea= k-word"><div><div><div class=3D"h5"><blockquote type=3D"cite"><div><div dir= =3D"ltr"><div dir=3D"ltr"><div><span style=3D"line-height:1.5"><br></span><= /div><div>Dirk.</div><div><br></div></div><br><div class=3D"gmail_quote"><d= iv dir=3D"ltr">On Tue, Mar 22, 2016 at 10:44 AM Andrei Popov <<a href=3D= "mailto:Andrei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov@microsof= t.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,= 204);border-left-style:solid;padding-left:1ex">Thanks for reviewing the I-D= s, Karthik.<br> <br> (d), (e) and (f) essentially involve total breakage of TLS. Truly, if one&#= 39;s binding is to a completely broken TLS channel, then the binding does n= ot help at all. This seems to be fairly obvious, but perhaps we can add thi= s caveat to the security considerations if the group believes it's usef= ul.<br> <br> Cheers,<br> <br> Andrei<br> <br> -----Original Message-----<br> From: Unbearable [mailto:<a href=3D"mailto:unbearable-bounces@ietf.org" tar= get=3D"_blank">unbearable-bounces@ietf.org</a>] On Behalf Of Karthik Bharga= van<br> Sent: Tuesday, March 22, 2016 9:37 AM<br> To: <a href=3D"mailto:unbearable@ietf.org" target=3D"_blank">unbearable@iet= f.org</a><br> Subject: [Unbearable] Limitations to Man-in-the-Middle Detection in Token B= inding<br> <br> I was staring at the latest draft of draft-ietf-tokbind-https-03 and the te= xt on man-in-the-middle detection in Section 4.3 seems a bit too strong, an= d I would suggest adding caveats here, or in the security considerations.<b= r> <br> By using EKM, and by relying on extended master secret, the token binding p= rotocol indeed protects against MitM attacks where either<br> (a) the attacker has a mis-issued certificate for the server (token consume= r or token provider), or<br> (b) the attacker has fooled the user agent into accepting a bogus certifica= te for the server, or<br> (c) the attacker is a malicious server who is seeking to forward the user= =E2=80=99s token to a different server.<br> <br> However, there are other MitM scenarios that are not protected by Token Bin= ding<br> (d) if the server=E2=80=99s certificate private key is compromised and the = TLS connection between the client and server uses RSA key transport,<br> =C2=A0 =C2=A0then the attacker can tamper with the connection (and hence wi= th the Token Binding HTTPS headers) without being detected<br> (e) if the server is vulnerable to RSA Bleichenbacher attacks (as in Drown)= ,<br> =C2=A0 =C2=A0then the attacker can obtain the PMS, hence the MS, and again = tamper with the application data without being detected<br> (f)=C2=A0 if the attacker obtains the session master secret between the cli= ent and server,<br> =C2=A0 =C2=A0either by stealing it from a session cache, or by breaking the= ticket encryption key,<br> =C2=A0 =C2=A0then in subsequent resumption handshakes the attacker can tamp= er with the application data without being detected.<br> <br> These last three scenarios are undoubtedly very strong attackers and may be= out-of-scope for Token Binding, but I think it is important not to give th= e impression that the use of EKM + EMS in token binding will prevent all Mi= tM attacks on TLS.<br> <br> If it is indeed important to prevent (d,e,f), then Token Binding should fur= ther recommend that the TLS client or server should only enable forward-sec= ure DHE/ECDHE ciphersuites=C2=A0 (this is what ChannelId did) and warn abou= t the risks of compromised session secrets or ticket encryption keys.<br> <br> Best,<br> Karthik<br> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f= %2fwww.ietf.org%2fmailman%2flistinfo%2funbearable%0a&data=3D01%7c01%7cA= ndrei.Popov%40microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988bf86= f141af91ab2d7cd011db47%7c1&sdata=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2Jp= DkNrSnAvU%3d" rel=3D"noreferrer" target=3D"_blank">https://na01.safelinks.p= rotection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf.org%2fmailman%2flistinf= o%2funbearable%0a&data=3D01%7c01%7cAndrei.Popov%40microsoft.com%7c568fb= ff72db649424d3208d35270383b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdat= a=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2JpDkNrSnAvU%3d</a><br> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> </blockquote></div></div> </div></blockquote></div></div></div><br></div><br>________________________= _______________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org">Unbearable@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> <br></blockquote></div><br></div></div> --001a11442ef8ce1401052ea83825-- From nobody Tue Mar 22 13:59:52 2016 Return-Path: <balfanz@google.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 839E412D97E for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 13:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Zg0JzrX57t8D for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 13:59:49 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D0812D787 for <unbearable@ietf.org>; Tue, 22 Mar 2016 13:59:48 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id l68so209192221wml.0 for <unbearable@ietf.org>; Tue, 22 Mar 2016 13:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DYTpt6c3rYOactBhcL8bui1g6rJYsOkAqzp+iC4m7Eo=; b=Le3rtea4Tyr0xyY9uZg7fdNsM87f4M60wRA94F0km9u3b9bM63rTN5Ht6B+bDX3I1p jIWymn8sIheWe0t5N9zKHcFl6uVGIbbLffoVtfW8kXIJCC+8LuEoUqmxTnM310EXHHKE ObgZpqOdviK9nuTdPlf8Xg+1D11+u1nfu0V74owtdU/DcHRlpQBrepmslV6pJBQ20T6g s26K2MNY9V8e2V+E1HndQbbPw+ogEP5EBIgyY8V+GQopl9XMCtXlmstP4IKw2STmTP8h wmTHHK3zcQWWfKxiJkkb4aJCtgsMn/7yyJMbeBwY4nAkctm++r6RGdausM9sZO8P1I1g 16HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DYTpt6c3rYOactBhcL8bui1g6rJYsOkAqzp+iC4m7Eo=; b=TrIaNGHWglkIfQkU4UMveTwUJ6zpg4RYpS3x/u+NSSG7aPgB4r85vlPFSm6GRROWAg pjY6Wmmd0WGkAd+1xozHAroYsHt9LhS4puoduOLT4LfjD65AkF3rLVGrugYQRoqCqujq /pLFK+gnkoIdRW2Sr9BysA2je+vyRC5/qsEtLl8z5eU4fNj+nTz27j8aJby1DnIyjG2D ECPksK65s6gZnEZqKKEPqiYVGFQnG27SPLGeQ1Oy7cx4x2tVg6YBXYRUJ3Q2x9KQMhV9 JsmhqyVnt7LOIxdPqKTVhFOHqMtTh22RjukV7sKLKhZNs7nCHT1jSv9S3yEIY0IOY6Ks 1o/A== X-Gm-Message-State: AD7BkJJZrBpC7VhId1XKbdViccP08XOZRF3azDxSwfCuerm+SkBo6PhivdA18iRN/zyOVf78PPB+gj1snroslR2j X-Received: by 10.194.143.82 with SMTP id sc18mr37354470wjb.14.1458680386772; Tue, 22 Mar 2016 13:59:46 -0700 (PDT) MIME-Version: 1.0 References: <099CAE22-2ED5-447B-BE5B-92CD4F5EFAD5@inria.fr> <BLUPR03MB13967C3EEAB0B0FEAF0D3AD18C800@BLUPR03MB1396.namprd03.prod.outlook.com> <CADHfa2DbV1pAm6-Da26WFUs0dA4NA7OjZwvn4mc195pFR9pqjw@mail.gmail.com> <111E07FD-0182-4EA1-A753-69B84C243F05@inria.fr> In-Reply-To: <111E07FD-0182-4EA1-A753-69B84C243F05@inria.fr> From: Dirk Balfanz <balfanz@google.com> Date: Tue, 22 Mar 2016 20:59:35 +0000 Message-ID: <CADHfa2DCaKqiTs6BefB2STFeuAmEF9Mfeq4m0wU03ZJFNF9T4A@mail.gmail.com> To: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr> Content-Type: multipart/alternative; boundary=089e011823a04badbe052ea97e27 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/7rCotU1vK0rPZMqAEdEK6oAGkjI> Cc: Andrei Popov <Andrei.Popov@microsoft.com>, "unbearable@ietf.org" <unbearable@ietf.org> Subject: Re: [Unbearable] Limitations to Man-in-the-Middle Detection in Token Binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Mar 2016 20:59:51 -0000 --089e011823a04badbe052ea97e27 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 22, 2016 at 12:21 PM Karthik Bhargavan < karthikeyan.bhargavan@inria.fr> wrote: > For an attacker to be able to successfully use a stolen authentication > token, he would have to produce a legitimate signature over the EKM of a > new connection, using the client's private key. Since none of the attacks > assume that the attacker actually knows the client's private key, the > attacker can only do this if he can create a connection to the server wit= h > an EKM that is identical to previous connection (and re-use a previous > signature). It's not sufficient to *know* what the MS (and EKM) of that > previous connection is - he must be able to *establish a new connection* > with that same EKM with the server (so that he can re-play a previous > signature to that server). Are you saying that (d) through (f) allow the > attacker to do that? > > > I am saying that there are certain powerful attackers (d-f) that can > persistently MitM connections between the client and the server. > In that case, they don=E2=80=99t need to now the client=E2=80=99s private= key, they can > simply forward the client=E2=80=99s signature over the EKM along with > the token-bound credentials to the server, and then freely tamper with th= e > connection afterward. > This is an obvious =E2=80=9Cattack=E2=80=9D on the HTTPS channel and argu= ably should not > be Token Binding=E2=80=99s concern. > Well, Token Binding does, in a sense, claim to protect the user when certain things break in TLS. So the specs should be clear about what those "certain things" are. :-) For example, the hearbleed attack was a flaw in (some implementations of) TLS that exposed authentication tokens. Token Binding inoculates the user against such vulnerabilities. On the other hand, we thought (until the triple-handshake attack was discovered) that a man-in-the-middle couldn't force the same EKM on two unrelated connections, and that therefore Token Binding protects the user from MitM attacks. Now that the triple-handshake attack is known, we require the extended master secret for Token Binding, again putting us in a position where we believe a MitM can't force the same EKM on two unrelated connections. MitMs not being able to do that (even if they can "break" TLS in other ways, like in heartbleed) is an important precondition for the security claims of Token Binding. But it's certainly possible that saying "the extended master secret guarantees that no MitM can force the same EKM on two unrelated connections" is too strong. Maybe a MitM in possession of the server's private key, using RSA modes, can still force the EKM to be the same on two different connections? I'm not sure whether that was within the threat model of the triple handshake attack, or the extended master secret remediation. If such a MitM can still force the same EKM, I'd agree that (d) is indeed a situation that we need to explain we don't protect against. What do you think? Is (d) an example in which the same EKM can be forced on two connections? How about (e) and (f)? Dirk. > Perhaps this is already clear to Token Binding users, but if not, adding = a > sentence to clarify the claims would perhaps be useful. > > -K > > > > Dirk. > > > On Tue, Mar 22, 2016 at 10:44 AM Andrei Popov <Andrei.Popov@microsoft.com= > > wrote: > >> Thanks for reviewing the I-Ds, Karthik. >> >> (d), (e) and (f) essentially involve total breakage of TLS. Truly, if >> one's binding is to a completely broken TLS channel, then the binding do= es >> not help at all. This seems to be fairly obvious, but perhaps we can add >> this caveat to the security considerations if the group believes it's >> useful. >> >> Cheers, >> >> Andrei >> >> -----Original Message----- >> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of >> Karthik Bhargavan >> Sent: Tuesday, March 22, 2016 9:37 AM >> To: unbearable@ietf.org >> Subject: [Unbearable] Limitations to Man-in-the-Middle Detection in Toke= n >> Binding >> >> I was staring at the latest draft of draft-ietf-tokbind-https-03 and the >> text on man-in-the-middle detection in Section 4.3 seems a bit too stron= g, >> and I would suggest adding caveats here, or in the security consideratio= ns. >> >> By using EKM, and by relying on extended master secret, the token bindin= g >> protocol indeed protects against MitM attacks where either >> (a) the attacker has a mis-issued certificate for the server (token >> consumer or token provider), or >> (b) the attacker has fooled the user agent into accepting a bogus >> certificate for the server, or >> (c) the attacker is a malicious server who is seeking to forward the >> user=E2=80=99s token to a different server. >> >> However, there are other MitM scenarios that are not protected by Token >> Binding >> (d) if the server=E2=80=99s certificate private key is compromised and t= he TLS >> connection between the client and server uses RSA key transport, >> then the attacker can tamper with the connection (and hence with the >> Token Binding HTTPS headers) without being detected >> (e) if the server is vulnerable to RSA Bleichenbacher attacks (as in >> Drown), >> then the attacker can obtain the PMS, hence the MS, and again tamper >> with the application data without being detected >> (f) if the attacker obtains the session master secret between the clien= t >> and server, >> either by stealing it from a session cache, or by breaking the ticket >> encryption key, >> then in subsequent resumption handshakes the attacker can tamper with >> the application data without being detected. >> >> These last three scenarios are undoubtedly very strong attackers and may >> be out-of-scope for Token Binding, but I think it is important not to gi= ve >> the impression that the use of EKM + EMS in token binding will prevent a= ll >> MitM attacks on TLS. >> >> If it is indeed important to prevent (d,e,f), then Token Binding should >> further recommend that the TLS client or server should only enable >> forward-secure DHE/ECDHE ciphersuites (this is what ChannelId did) and >> warn about the risks of compromised session secrets or ticket encryption >> keys. >> >> Best, >> Karthik >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.i= etf.org%2fmailman%2flistinfo%2funbearable%0a&data=3D01%7c01%7cAndrei.Popov%= 40microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988bf86f141af91ab2d= 7cd011db47%7c1&sdata=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2JpDkNrSnAvU%3d >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >> > --089e011823a04badbe052ea97e27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue= , Mar 22, 2016 at 12:21 PM Karthik Bhargavan <<a href=3D"mailto:karthike= yan.bhargavan@inria.fr">karthikeyan.bhargavan@inria.fr</a>> wrote:<br></= div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef= t:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div= ><blockquote type=3D"cite"><div><div dir=3D"ltr"><div><span style=3D"line-h= eight:1.5">For an attacker to be able to successfully use a stolen authenti= cation token, he would have to produce a legitimate signature over the EKM = of a new connection, using the client's private key. Since none of the = attacks assume that the attacker actually knows the client's private ke= y, the attacker can only do this if he can create a connection to the serve= r with an EKM that is identical to previous connection (and re-use a previo= us signature). It's not sufficient to *know* what the MS (and EKM) of t= hat previous connection is - he must be able to *establish a new connection= * with that same EKM with the server (so that he can re-play a previous sig= nature to that server). Are you saying that (d) through (f) allow the attac= ker to do that?</span></div></div></div></blockquote><div><br></div></div><= /div><div style=3D"word-wrap:break-word"><div><div>I am saying that there a= re certain powerful attackers (d-f) that can persistently MitM connections = between the client and the server.</div><div>In that case, they don=E2=80= =99t need to now the client=E2=80=99s private key, they can simply forward = the client=E2=80=99s signature over the EKM along with=C2=A0</div><div>the = token-bound credentials to the server, and then freely tamper with the conn= ection afterward. =C2=A0</div><div>This is an obvious =E2=80=9Cattack=E2=80= =9D on the HTTPS channel and arguably should not be Token Binding=E2=80=99s= concern.=C2=A0</div></div></div></blockquote><div><br></div><div>Well, Tok= en Binding does, in a sense, claim to protect the user when certain things = break in TLS. So the specs should be clear about what those "certain t= hings" are. :-)</div><div><br></div><div>For example, the hearbleed at= tack was a flaw in (some implementations of) TLS that exposed authenticatio= n tokens. Token Binding inoculates the user against such vulnerabilities.</= div><div><br></div><div>On the other hand, we thought (until the triple-han= dshake attack was discovered) that a man-in-the-middle couldn't force t= he same EKM on two unrelated connections, and that therefore Token Binding = protects the user from MitM attacks. Now that the triple-handshake attack i= s known, we require the extended master secret for Token Binding, again put= ting us in a position where we believe a MitM can't force the same EKM = on two unrelated connections. MitMs not being able to do that (even if they= can "break" TLS in other ways, like in heartbleed) is an importa= nt precondition for the security claims of Token Binding.=C2=A0</div><div><= br></div><div>But it's certainly possible that saying "the extende= d master secret guarantees that no MitM can force the same EKM on two unrel= ated connections" is too strong. Maybe a MitM in possession of the ser= ver's private key, using RSA modes, can still force the EKM to be the s= ame on two different connections? I'm not sure whether that was within = the threat model of the triple handshake attack, or the extended master sec= ret remediation. If such a MitM can still force the same EKM, I'd agree= that (d) is indeed a situation that we need to explain we don't protec= t against.=C2=A0</div><div><br></div><div>What do you think? Is (d) an exam= ple in which the same EKM can be forced on two connections? How about (e) a= nd (f)?</div><div><br></div><div>Dirk.</div><div>=C2=A0</div><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:1ex"><div style=3D"word-wrap:break-word"><div><div>Perhaps this= is already clear to Token Binding users, but if not, adding a sentence to = clarify the claims would perhaps be useful.</div></div></div><div style=3D"= word-wrap:break-word"><div><div><br></div><div>-K</div></div></div><div sty= le=3D"word-wrap:break-word"><div><div><br></div><br><blockquote type=3D"cit= e"><div><div dir=3D"ltr"><div dir=3D"ltr"><div><span style=3D"line-height:1= .5"><br></span></div><div>Dirk.</div><div><br></div></div><br><div class=3D= "gmail_quote"><div dir=3D"ltr">On Tue, Mar 22, 2016 at 10:44 AM Andrei Popo= v <<a href=3D"mailto:Andrei.Popov@microsoft.com" target=3D"_blank">Andre= i.Popov@microsoft.com</a>> wrote:<br></div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex= ">Thanks for reviewing the I-Ds, Karthik.<br> <br> (d), (e) and (f) essentially involve total breakage of TLS. Truly, if one&#= 39;s binding is to a completely broken TLS channel, then the binding does n= ot help at all. This seems to be fairly obvious, but perhaps we can add thi= s caveat to the security considerations if the group believes it's usef= ul.<br> <br> Cheers,<br> <br> Andrei<br> <br> -----Original Message-----<br> From: Unbearable [mailto:<a href=3D"mailto:unbearable-bounces@ietf.org" tar= get=3D"_blank">unbearable-bounces@ietf.org</a>] On Behalf Of Karthik Bharga= van<br> Sent: Tuesday, March 22, 2016 9:37 AM<br> To: <a href=3D"mailto:unbearable@ietf.org" target=3D"_blank">unbearable@iet= f.org</a><br> Subject: [Unbearable] Limitations to Man-in-the-Middle Detection in Token B= inding<br> <br> I was staring at the latest draft of draft-ietf-tokbind-https-03 and the te= xt on man-in-the-middle detection in Section 4.3 seems a bit too strong, an= d I would suggest adding caveats here, or in the security considerations.<b= r> <br> By using EKM, and by relying on extended master secret, the token binding p= rotocol indeed protects against MitM attacks where either<br> (a) the attacker has a mis-issued certificate for the server (token consume= r or token provider), or<br> (b) the attacker has fooled the user agent into accepting a bogus certifica= te for the server, or<br> (c) the attacker is a malicious server who is seeking to forward the user= =E2=80=99s token to a different server.<br> <br> However, there are other MitM scenarios that are not protected by Token Bin= ding<br> (d) if the server=E2=80=99s certificate private key is compromised and the = TLS connection between the client and server uses RSA key transport,<br> =C2=A0 =C2=A0then the attacker can tamper with the connection (and hence wi= th the Token Binding HTTPS headers) without being detected<br> (e) if the server is vulnerable to RSA Bleichenbacher attacks (as in Drown)= ,<br> =C2=A0 =C2=A0then the attacker can obtain the PMS, hence the MS, and again = tamper with the application data without being detected<br> (f)=C2=A0 if the attacker obtains the session master secret between the cli= ent and server,<br> =C2=A0 =C2=A0either by stealing it from a session cache, or by breaking the= ticket encryption key,<br> =C2=A0 =C2=A0then in subsequent resumption handshakes the attacker can tamp= er with the application data without being detected.<br> <br> These last three scenarios are undoubtedly very strong attackers and may be= out-of-scope for Token Binding, but I think it is important not to give th= e impression that the use of EKM + EMS in token binding will prevent all Mi= tM attacks on TLS.<br> <br> If it is indeed important to prevent (d,e,f), then Token Binding should fur= ther recommend that the TLS client or server should only enable forward-sec= ure DHE/ECDHE ciphersuites=C2=A0 (this is what ChannelId did) and warn abou= t the risks of compromised session secrets or ticket encryption keys.<br> <br> Best,<br> Karthik<br> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f= %2fwww.ietf.org%2fmailman%2flistinfo%2funbearable%0a&data=3D01%7c01%7cA= ndrei.Popov%40microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988bf86= f141af91ab2d7cd011db47%7c1&sdata=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2Jp= DkNrSnAvU%3d" rel=3D"noreferrer" target=3D"_blank">https://na01.safelinks.p= rotection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf.org%2fmailman%2flistinf= o%2funbearable%0a&data=3D01%7c01%7cAndrei.Popov%40microsoft.com%7c568fb= ff72db649424d3208d35270383b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdat= a=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2JpDkNrSnAvU%3d</a><br> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> </blockquote></div></div> </div></blockquote></div></div></blockquote></div></div> --089e011823a04badbe052ea97e27-- From nobody Tue Mar 22 15:09:11 2016 Return-Path: <karthikeyan.bhargavan@inria.fr> 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 A7F5112DAAA for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 15:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.911 X-Spam-Level: X-Spam-Status: No, score=-4.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 3gPAISco1LNJ for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 15:09:07 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5B812DAC5 for <unbearable@ietf.org>; Tue, 22 Mar 2016 15:08:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,379,1454972400"; d="scan'208,217";a="209571308" Received: from 89-156-8-219.rev.numericable.fr (HELO [192.168.0.16]) ([89.156.8.219]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Mar 2016 23:08:46 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_D8DE97A8-D272-49F4-B84E-66AA0CB34F54" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr> In-Reply-To: <CADHfa2DCaKqiTs6BefB2STFeuAmEF9Mfeq4m0wU03ZJFNF9T4A@mail.gmail.com> Date: Tue, 22 Mar 2016 23:08:44 +0100 Message-Id: <C42FCAD0-0EA1-4698-B833-E65A1EAA038B@inria.fr> References: <099CAE22-2ED5-447B-BE5B-92CD4F5EFAD5@inria.fr> <BLUPR03MB13967C3EEAB0B0FEAF0D3AD18C800@BLUPR03MB1396.namprd03.prod.outlook.com> <CADHfa2DbV1pAm6-Da26WFUs0dA4NA7OjZwvn4mc195pFR9pqjw@mail.gmail.com> <111E07FD-0182-4EA1-A753-69B84C243F05@inria.fr> <CADHfa2DCaKqiTs6BefB2STFeuAmEF9Mfeq4m0wU03ZJFNF9T4A@mail.gmail.com> To: Dirk Balfanz <balfanz@google.com> X-Mailer: Apple Mail (2.3112) Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/9JeoYX5vsoXwc7hIDp-yVoo6Dvw> Cc: Andrei Popov <Andrei.Popov@microsoft.com>, "unbearable@ietf.org" <unbearable@ietf.org> Subject: Re: [Unbearable] Limitations to Man-in-the-Middle Detection in Token Binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Mar 2016 22:09:10 -0000 --Apple-Mail=_D8DE97A8-D272-49F4-B84E-66AA0CB34F54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > But it's certainly possible that saying "the extended master secret = guarantees that no MitM can force the same EKM on two unrelated = connections" is too strong. Maybe a MitM in possession of the server's = private key, using RSA modes, can still force the EKM to be the same on = two different connections? I'm not sure whether that was within the = threat model of the triple handshake attack, or the extended master = secret remediation. If such a MitM can still force the same EKM, I'd = agree that (d) is indeed a situation that we need to explain we don't = protect against.=20 Yes, you got it right. As you can guess I am worried about people = expecting too much from RFC7627 :) (d), (e), and (f) and more generally any TLS attack that exposes the = record encryption key to the attacker without the need for an active attack on the handshake will result in a = case that the attacker can make the EKM on two connections the same. Whether these two connections are =E2=80=9Cunrelated=E2=80=9D is = debatable, since the attacker is forwarding messages from one connection = to the other, until the point that the handshake is complete.=20 > What do you think? Is (d) an example in which the same EKM can be = forced on two connections? How about (e) and (f)? Yes, compromised server private key (for RSA connections), DROWN, = compromised ticket encryption key (for resumption), are all cases where the attacker can force EKM on two connections to be the same = (simply by forwarding messages from one to another.) The above are powerful attackers but the reason for EKM synchronization = is pretty trivial: i.e the attacker breaks the TLS key. Another, more expensive attack I can think of is when because of the = SLOTH attack, the attacker can force the EKM on both connections to be = the same by causing a transcript collision in the session hash (this costs = 2^128 SHA-256 hashes in TLS 1.2 and 2^77 SHA-1 hashes in TLS 1.0/1.1). Best, Karthik >=20 > Dirk. > =20 > Perhaps this is already clear to Token Binding users, but if not, = adding a sentence to clarify the claims would perhaps be useful. >=20 > -K >=20 >=20 >>=20 >> Dirk. >>=20 >>=20 >> On Tue, Mar 22, 2016 at 10:44 AM Andrei Popov = <Andrei.Popov@microsoft.com <mailto:Andrei.Popov@microsoft.com>> wrote: >> Thanks for reviewing the I-Ds, Karthik. >>=20 >> (d), (e) and (f) essentially involve total breakage of TLS. Truly, if = one's binding is to a completely broken TLS channel, then the binding = does not help at all. This seems to be fairly obvious, but perhaps we = can add this caveat to the security considerations if the group believes = it's useful. >>=20 >> Cheers, >>=20 >> Andrei >>=20 >> -----Original Message----- >> From: Unbearable [mailto:unbearable-bounces@ietf.org = <mailto:unbearable-bounces@ietf.org>] On Behalf Of Karthik Bhargavan >> Sent: Tuesday, March 22, 2016 9:37 AM >> To: unbearable@ietf.org <mailto:unbearable@ietf.org> >> Subject: [Unbearable] Limitations to Man-in-the-Middle Detection in = Token Binding >>=20 >> I was staring at the latest draft of draft-ietf-tokbind-https-03 and = the text on man-in-the-middle detection in Section 4.3 seems a bit too = strong, and I would suggest adding caveats here, or in the security = considerations. >>=20 >> By using EKM, and by relying on extended master secret, the token = binding protocol indeed protects against MitM attacks where either >> (a) the attacker has a mis-issued certificate for the server (token = consumer or token provider), or >> (b) the attacker has fooled the user agent into accepting a bogus = certificate for the server, or >> (c) the attacker is a malicious server who is seeking to forward the = user=E2=80=99s token to a different server. >>=20 >> However, there are other MitM scenarios that are not protected by = Token Binding >> (d) if the server=E2=80=99s certificate private key is compromised = and the TLS connection between the client and server uses RSA key = transport, >> then the attacker can tamper with the connection (and hence with = the Token Binding HTTPS headers) without being detected >> (e) if the server is vulnerable to RSA Bleichenbacher attacks (as in = Drown), >> then the attacker can obtain the PMS, hence the MS, and again = tamper with the application data without being detected >> (f) if the attacker obtains the session master secret between the = client and server, >> either by stealing it from a session cache, or by breaking the = ticket encryption key, >> then in subsequent resumption handshakes the attacker can tamper = with the application data without being detected. >>=20 >> These last three scenarios are undoubtedly very strong attackers and = may be out-of-scope for Token Binding, but I think it is important not = to give the impression that the use of EKM + EMS in token binding will = prevent all MitM attacks on TLS. >>=20 >> If it is indeed important to prevent (d,e,f), then Token Binding = should further recommend that the TLS client or server should only = enable forward-secure DHE/ECDHE ciphersuites (this is what ChannelId = did) and warn about the risks of compromised session secrets or ticket = encryption keys. >>=20 >> Best, >> Karthik >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org <mailto:Unbearable@ietf.org> >> = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.iet= f.org%2fmailman%2flistinfo%2funbearable%0a&data=3D01%7c01%7cAndrei.Popov%4= 0microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988bf86f141af91ab2d= 7cd011db47%7c1&sdata=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2JpDkNrSnAvU%3d = <https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2fmailman%2flistinfo%2funbearable%0a&data=3D01%7c01%7cAndrei.Popov%= 40microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988bf86f141af91ab2= d7cd011db47%7c1&sdata=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2JpDkNrSnAvU%3d> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org <mailto:Unbearable@ietf.org> >> https://www.ietf.org/mailman/listinfo/unbearable = <https://www.ietf.org/mailman/listinfo/unbearable> > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org <mailto:Unbearable@ietf.org> > https://www.ietf.org/mailman/listinfo/unbearable = <https://www.ietf.org/mailman/listinfo/unbearable> --Apple-Mail=_D8DE97A8-D272-49F4-B84E-66AA0CB34F54 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"ltr" style=3D"font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><div = class=3D"gmail_quote"><div class=3D"">But it's certainly possible that = saying "the extended master secret guarantees that no MitM can force the = same EKM on two unrelated connections" is too strong. Maybe a MitM in = possession of the server's private key, using RSA modes, can still force = the EKM to be the same on two different connections? I'm not sure = whether that was within the threat model of the triple handshake attack, = or the extended master secret remediation. If such a MitM can still = force the same EKM, I'd agree that (d) is indeed a situation that we = need to explain we don't protect = against. </div></div></div></div></blockquote><div><br = class=3D""></div><div>Yes, you got it right. As you can guess I am = worried about people expecting too much from RFC7627 :)</div><div>(d), = (e), and (f) and more generally any TLS attack that exposes the record = encryption key to the attacker</div><div>without the need for an active = attack on the handshake will result in a case that the attacker can make = the EKM on two connections the same.</div><div>Whether these two = connections are =E2=80=9Cunrelated=E2=80=9D is debatable, since the = attacker is forwarding messages from one connection to the = other,</div><div>until the point that the handshake is = complete. </div><br class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D""><div dir=3D"ltr" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" = class=3D""><div class=3D"gmail_quote"><div class=3D"">What do you think? = Is (d) an example in which the same EKM can be forced on two = connections? How about (e) and = (f)?</div></div></div></div></blockquote><div><br = class=3D""></div><div>Yes, compromised server private key (for RSA = connections), DROWN, compromised ticket encryption key (for resumption), = are all</div><div>cases where the attacker can force EKM on two = connections to be the same (simply by forwarding messages from one to = another.)</div><div><br class=3D""></div><div>The above are powerful = attackers but the reason for EKM synchronization is pretty trivial: i.e = the attacker breaks the TLS key.</div><div>Another, more expensive = attack I can think of is when because of the SLOTH attack, the attacker = can force the EKM on both connections to be the</div><div>same by = causing a transcript collision in the session hash (this costs 2^128 = SHA-256 hashes in TLS 1.2 and 2^77 SHA-1 hashes in TLS = 1.0/1.1).</div><div><br = class=3D""></div><div>Best,</div><div>Karthik</div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"ltr" style=3D"font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><div = class=3D"gmail_quote"><div class=3D""><br class=3D""></div><div = class=3D"">Dirk.</div><div class=3D""> </div><blockquote = class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; = border-left-width: 1px; border-left-color: rgb(204, 204, 204); = border-left-style: solid; padding-left: 1ex;"><div style=3D"word-wrap: = break-word;" class=3D""><div class=3D""><div class=3D"">Perhaps this is = already clear to Token Binding users, but if not, adding a sentence to = clarify the claims would perhaps be useful.</div></div></div><div = style=3D"word-wrap: break-word;" class=3D""><div class=3D""><div = class=3D""><br class=3D""></div><div class=3D"">-K</div></div></div><div = style=3D"word-wrap: break-word;" class=3D""><div class=3D""><div = class=3D""><br class=3D""></div><br class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div dir=3D"ltr" = class=3D""><div class=3D""><span style=3D"line-height: 1.5;" = class=3D""><br class=3D""></span></div><div class=3D"">Dirk.</div><div = class=3D""><br class=3D""></div></div><br class=3D""><div = class=3D"gmail_quote"><div dir=3D"ltr" class=3D"">On Tue, Mar 22, 2016 = at 10:44 AM Andrei Popov <<a href=3D"mailto:Andrei.Popov@microsoft.com"= target=3D"_blank" class=3D"">Andrei.Popov@microsoft.com</a>> = wrote:<br class=3D""></div><blockquote class=3D"gmail_quote" = style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; = border-left-color: rgb(204, 204, 204); border-left-style: solid; = padding-left: 1ex;">Thanks for reviewing the I-Ds, Karthik.<br = class=3D""><br class=3D"">(d), (e) and (f) essentially involve total = breakage of TLS. Truly, if one's binding is to a completely broken TLS = channel, then the binding does not help at all. This seems to be fairly = obvious, but perhaps we can add this caveat to the security = considerations if the group believes it's useful.<br class=3D""><br = class=3D"">Cheers,<br class=3D""><br class=3D"">Andrei<br class=3D""><br = class=3D"">-----Original Message-----<br class=3D"">From: Unbearable = [mailto:<a href=3D"mailto:unbearable-bounces@ietf.org" target=3D"_blank" = class=3D"">unbearable-bounces@ietf.org</a>] On Behalf Of Karthik = Bhargavan<br class=3D"">Sent: Tuesday, March 22, 2016 9:37 AM<br = class=3D"">To:<span class=3D"Apple-converted-space"> </span><a = href=3D"mailto:unbearable@ietf.org" target=3D"_blank" = class=3D"">unbearable@ietf.org</a><br class=3D"">Subject: [Unbearable] = Limitations to Man-in-the-Middle Detection in Token Binding<br = class=3D""><br class=3D"">I was staring at the latest draft of = draft-ietf-tokbind-https-03 and the text on man-in-the-middle detection = in Section 4.3 seems a bit too strong, and I would suggest adding = caveats here, or in the security considerations.<br class=3D""><br = class=3D"">By using EKM, and by relying on extended master secret, the = token binding protocol indeed protects against MitM attacks where = either<br class=3D"">(a) the attacker has a mis-issued certificate for = the server (token consumer or token provider), or<br class=3D"">(b) the = attacker has fooled the user agent into accepting a bogus certificate = for the server, or<br class=3D"">(c) the attacker is a malicious server = who is seeking to forward the user=E2=80=99s token to a different = server.<br class=3D""><br class=3D"">However, there are other MitM = scenarios that are not protected by Token Binding<br class=3D"">(d) if = the server=E2=80=99s certificate private key is compromised and the TLS = connection between the client and server uses RSA key transport,<br = class=3D"">   then the attacker can tamper with the connection = (and hence with the Token Binding HTTPS headers) without being = detected<br class=3D"">(e) if the server is vulnerable to RSA = Bleichenbacher attacks (as in Drown),<br class=3D"">   then = the attacker can obtain the PMS, hence the MS, and again tamper with the = application data without being detected<br class=3D"">(f)  if the = attacker obtains the session master secret between the client and = server,<br class=3D"">   either by stealing it from a session = cache, or by breaking the ticket encryption key,<br class=3D"">  =  then in subsequent resumption handshakes the attacker can tamper = with the application data without being detected.<br class=3D""><br = class=3D"">These last three scenarios are undoubtedly very strong = attackers and may be out-of-scope for Token Binding, but I think it is = important not to give the impression that the use of EKM + EMS in token = binding will prevent all MitM attacks on TLS.<br class=3D""><br = class=3D"">If it is indeed important to prevent (d,e,f), then Token = Binding should further recommend that the TLS client or server should = only enable forward-secure DHE/ECDHE ciphersuites  (this is what = ChannelId did) and warn about the risks of compromised session secrets = or ticket encryption keys.<br class=3D""><br class=3D"">Best,<br = class=3D"">Karthik<br = class=3D"">_______________________________________________<br = class=3D"">Unbearable mailing list<br class=3D""><a = href=3D"mailto:Unbearable@ietf.org" target=3D"_blank" = class=3D"">Unbearable@ietf.org</a><br class=3D""><a = href=3D"https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2= fwww.ietf.org%2fmailman%2flistinfo%2funbearable%0a&data=3D01%7c01%7cAn= drei.Popov%40microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988bf86= f141af91ab2d7cd011db47%7c1&sdata=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2N2J= pDkNrSnAvU%3d" rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2= f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable%0a&data=3D01%7c01%7= cAndrei.Popov%40microsoft.com%7c568fbff72db649424d3208d35270383b%7c72f988b= f86f141af91ab2d7cd011db47%7c1&sdata=3DkzK0fUhMGmsuCtQb86T8P7hf%2b0R1I2= N2JpDkNrSnAvU%3d</a><br = class=3D"">_______________________________________________<br = class=3D"">Unbearable mailing list<br class=3D""><a = href=3D"mailto:Unbearable@ietf.org" target=3D"_blank" = class=3D"">Unbearable@ietf.org</a><br class=3D""><a = href=3D"https://www.ietf.org/mailman/listinfo/unbearable" = rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://www.ietf.org/mailman/listinfo/unbearable</a><br = class=3D""></blockquote></div></div></div></blockquote></div></div></block= quote></div></div><span style=3D"font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: = inline !important;" = class=3D"">_______________________________________________</span><br = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: = none; display: inline !important;" class=3D"">Unbearable mailing = list</span><br style=3D"font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><a = href=3D"mailto:Unbearable@ietf.org" style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; orphans: auto; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: = auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" = class=3D"">Unbearable@ietf.org</a><br style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; orphans: auto; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: = auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><a = href=3D"https://www.ietf.org/mailman/listinfo/unbearable" = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" = class=3D"">https://www.ietf.org/mailman/listinfo/unbearable</a></div></blo= ckquote></div><br class=3D""></body></html>= --Apple-Mail=_D8DE97A8-D272-49F4-B84E-66AA0CB34F54-- From nobody Tue Mar 22 18:11:09 2016 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 B543412D11A for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 18:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 HfprF6vZ9mCP for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 18:11:06 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 3E64A12DAED for <unbearable@ietf.org>; Tue, 22 Mar 2016 18:11:01 -0700 (PDT) Received: (qmail 10123 invoked by uid 0); 23 Mar 2016 01:11:00 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy2.mail.unifiedlayer.com with SMTP; 23 Mar 2016 01:11:00 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id ZLAt1s00g2UhLwi01LAwHg; Wed, 23 Mar 2016 02:10:57 -0600 X-Authority-Analysis: v=2.1 cv=Maz/5fPf c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7OsogOcEt9IA:10 a=XZJWYD8qrbbRC2S9nJUA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=VAEBb9xRs2qZ6ECBmxc/VYblWGqRk8EKvNBmGkJRPfU=; b=rn0Ohfb0tUAZv8RAlSNo7pDtga WHHvWfgV20Ly9kUU59ayT+8u4g94BldAIdlTLfL9PBiwi1ivLewKUFpCmLnBJL47a5zeWNPTWoMPG le+eOgJKbYx25LtJVErvfr3Vt; Received: from [73.202.80.238] (port=56652 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1aiXK4-0000Re-Mq for unbearable@ietf.org; Tue, 22 Mar 2016 19:10:56 -0600 To: IETF Tokbind WG <unbearable@ietf.org> From: =JeffH <Jeff.Hodges@KingsMountain.com> Message-ID: <56F1ED1D.2060804@KingsMountain.com> Date: Tue, 22 Mar 2016 18:10:53 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/7A2OfGHAL9qKgtKsctFUI7Yq8Rc> Subject: Re: [Unbearable] Potential privacy bug if Include-Referer-Token-Binding-ID is improperly implemented client-side X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Mar 2016 01:11:07 -0000 thx for clarifications, Nick. further questions & thoughts.. > Here's the problem: Suppose the connection to server A is over http. > Now a network attacker B injects into some http page (from server C) code > that will cause the client to make an http request to server A. > The attacker B intercepts the request and responds with a redirect to > server B (with the Include-Referer-Token-Binding-ID header). the redirect to B will be an HTTP 30x response not over TLS, regardless of whether the Location: header field contains a https URI, yes? > The client > dutifully follows that request and forwards the TokenBindingID it has for > A to the attacker-controlled B. Should we not explicitly stipulate in -tokbind-https that the client MUST NOT honor any Include-Referer-Token-Binding-ID header received over insecure transport? This is how we addressed similar situations in the HSTS and HPKP specs. > It would certainly be nice for the transport to be established error > free, and to use HSTS and HPKP, but I don't think those need to be made > as requirements for using Token Binding. I was not proposing stating any requirements wrt employing HSTS and HPKP -- rather, I am thinking that we should have some deployment considerations where HSTS and HPKP are dutifully mentioned and how their use composes with TB to the benefit of the web app provider and their users. HTH, =JeffH From nobody Tue Mar 22 18:15:55 2016 Return-Path: <nharper@google.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 E6DFC12D5BD for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 18:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 sJHmZFG5y3Yb for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 18:15:50 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2EB812D555 for <unbearable@ietf.org>; Tue, 22 Mar 2016 18:15:50 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id e6so1304051vkh.2 for <unbearable@ietf.org>; Tue, 22 Mar 2016 18:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Am4DDmXcmQc5D+XiW9PNPTMrhzRvuZfKmNE6LhJbpGM=; b=BOt2Eexa+AVzJc83J6qlU2e+bsPeUUC0mwFoxKxsIkwLgt4X4YV2UdJOq4FqYmQ0/6 NL5aNXoYN6z83QQYhEe0TQLK4RlNZSkui5wkUoikU0jNFgEn6Z2d40zNiSkYK0f6CQuj XTLOFk1BWHe/9G68fvZ6CL46ww76L3ggIj2OkpzE20t6pfezdM0J/1EZEeDWg/nGiush 8tIDNlPXs1YrF4Uy+CYOG4cD2F+q0J/pLNqd2iCI66EWQbDIcwIiROy4Qjz+7ma5O8VI cYUknSxdBQvZU2v5r4RX0E2/ORoQO1QDY3Gl2CJTXzH5WyFjpmhcRRcz7g6jquthlrg0 OX5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Am4DDmXcmQc5D+XiW9PNPTMrhzRvuZfKmNE6LhJbpGM=; b=hn2MjKMR+63IoCWzbFz2PRUPsCFuBhKRjy0x7R0WQZ2wfWltcouD1MMVnDY/iMtFYq NIialUVN4kgMKkKTgvbBglE4MZol77g8sJ/5y59lq3ondt7Dtb4LobXcOydwVmQVnMtu JwMmAQznWmCLATItmBv6opHMIlb/DWsm0pl24IcWo7LeLB4RuUvRqn4wMPWb4v3eAad2 T1MsgGOeLsANhXwcyJg43JC6vdWTP4WoILvOy9GGWrn+bz85IEWtEw4uTbxijghXbJR2 Kax8EFaWLScDvR6LmXQG/aOJsO/RebDaTrpeLiobEq0y9j+3SM+dA7nWkWUNJsPuw0hx rCZg== X-Gm-Message-State: AD7BkJLH81SKdw3AvK8wyKcNnqWrK/ekVBL8tn13qDFOJapyTBk1wm+u+g3aQpGwRDNpm4dJUkHW4GhXVJNPHzQy X-Received: by 10.31.162.3 with SMTP id l3mr99165vke.68.1458695749528; Tue, 22 Mar 2016 18:15:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.76.198 with HTTP; Tue, 22 Mar 2016 18:15:29 -0700 (PDT) In-Reply-To: <56F1ED1D.2060804@KingsMountain.com> References: <56F1ED1D.2060804@KingsMountain.com> From: Nick Harper <nharper@google.com> Date: Tue, 22 Mar 2016 18:15:29 -0700 Message-ID: <CACdeXiLZV9ueinLa4amhrCzdvdbhz_q_KGwREOg7CNjmCcJ7AA@mail.gmail.com> To: "=JeffH" <Jeff.Hodges@kingsmountain.com> Content-Type: multipart/alternative; boundary=001a114406eafcb240052ead1181 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/XL04YjVRf2rsFYHO4EUAbaEYGRg> Cc: IETF Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Potential privacy bug if Include-Referer-Token-Binding-ID is improperly implemented client-side X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Mar 2016 01:15:53 -0000 --001a114406eafcb240052ead1181 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 22, 2016 at 6:10 PM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote: > thx for clarifications, Nick. further questions & thoughts.. > > > Here's the problem: Suppose the connection to server A is over http. > > Now a network attacker B injects into some http page (from server C) code > > that will cause the client to make an http request to server A. > > The attacker B intercepts the request and responds with a redirect to > > server B (with the Include-Referer-Token-Binding-ID header). > > the redirect to B will be an HTTP 30x response not over TLS, regardless of > whether the Location: header field contains a https URI, yes? > > Correct. > > > The client > > dutifully follows that request and forwards the TokenBindingID it has for > > A to the attacker-controlled B. > > Should we not explicitly stipulate in -tokbind-https that the client MUST > NOT honor any Include-Referer-Token-Binding-ID header received over > insecure transport? This is how we addressed similar situations in the HSTS > and HPKP specs. > > The addition of https://github.com/TokenBinding/Internet-Drafts/commit/2033a64397590a55811cb78af8f5aa739cb8c981 implicitly states that (since the Token-Binding header is not sent over an insecure transport). I don't have strong feelings for whether this needs to be more explicit. > > > It would certainly be nice for the transport to be established error > > free, and to use HSTS and HPKP, but I don't think those need to be made > > as requirements for using Token Binding. > > I was not proposing stating any requirements wrt employing HSTS and HPKP > -- rather, I am thinking that we should have some deployment considerations > where HSTS and HPKP are dutifully mentioned and how their use composes with > TB to the benefit of the web app provider and their users. > > > HTH, > > =JeffH > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a114406eafcb240052ead1181 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On Tue, Mar 22, 2016 at 6:10 PM, =3DJeffH <span dir=3D"ltr"><<a href= =3D"mailto:Jeff.Hodges@kingsmountain.com" target=3D"_blank">Jeff.Hodges@kin= gsmountain.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg= b(204,204,204);border-left-style:solid;padding-left:1ex">thx for clarificat= ions, Nick. further questions & thoughts..<span class=3D""><br> <br> > Here's the problem: Suppose the connection to server A is over htt= p.<br></span><span class=3D""> > Now a network attacker B injects into some http page (from server C) c= ode<br> > that will cause the client to make an http request to server A.<br></s= pan><span class=3D""> > The attacker B intercepts the request and responds with a redirect to<= br> > server B (with the Include-Referer-Token-Binding-ID header).<br> <br></span> the redirect to B will be an HTTP 30x response not over TLS, regardless of = whether the Location: header field contains a https URI, yes?<span class=3D= ""><br> <br></span></blockquote><div>Correct.=C2=A0</div><blockquote class=3D"gmail= _quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left= -color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span cla= ss=3D""> <br> > The client<br> > dutifully follows that request and forwards the TokenBindingID it has = for<br> > A to the attacker-controlled B.<br> <br></span> Should we not explicitly stipulate in -tokbind-https that the client MUST N= OT honor any Include-Referer-Token-Binding-ID header received over insecure= transport? This is how we addressed similar situations in the HSTS and HPK= P specs.<span class=3D""><br> <br></span></blockquote><div>The addition of <a href=3D"https://github.com/= TokenBinding/Internet-Drafts/commit/2033a64397590a55811cb78af8f5aa739cb8c98= 1">https://github.com/TokenBinding/Internet-Drafts/commit/2033a64397590a558= 11cb78af8f5aa739cb8c981</a> implicitly states that (since the Token-Binding= header is not sent over an insecure transport). I don't have strong fe= elings for whether this needs to be more explicit.</div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo= rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">= <span class=3D""> <br> > It would certainly be nice for the transport to be established error<b= r> > free, and to use HSTS and HPKP, but I don't think those need to be= made<br> > as requirements for using Token Binding.<br> <br></span> I was not proposing stating any requirements wrt employing HSTS and HPKP --= rather, I am thinking that we should have some deployment considerations w= here HSTS and HPKP are dutifully mentioned and how their use composes with = TB to the benefit of the web app provider and their users.<div class=3D""><= div class=3D"h5"><br> <br> HTH,<br> <br> =3DJeffH<br> <br> <br> <br> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> </div></div></blockquote></div><br></div></div> --001a114406eafcb240052ead1181-- From nobody Tue Mar 22 18:23:08 2016 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 B7DA912DB05 for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 18:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 eK3m9kX8yQdV for <unbearable@ietfa.amsl.com>; Tue, 22 Mar 2016 18:23:05 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 581B912D5E6 for <unbearable@ietf.org>; Tue, 22 Mar 2016 18:23:05 -0700 (PDT) Received: (qmail 27507 invoked by uid 0); 23 Mar 2016 01:23:03 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy6.mail.unifiedlayer.com with SMTP; 23 Mar 2016 01:23:03 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id ZLNx1s00G2UhLwi01LP0EW; Wed, 23 Mar 2016 02:23:00 -0600 X-Authority-Analysis: v=2.1 cv=Maz/5fPf c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=Un061Cu7J_r3vH8WTQIA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:To:Subject:From; bh=cIYjbQlr/i8YqtscrkFB5Ly3i+DILjP2kwqamxL4kf4=; b=ksTIWe2uOt/KZePHeC38Ix6EiK SJh9lhxtsjMdURVEepdyJvydApNBVK7U6FHI8ENHp3VkU6G2jE2LnP8wFBlkMUOVU+Wz0UfZEBehJ VAd5clXs7+NMlhrGkA8qOW5dZ; Received: from [73.202.80.238] (port=56694 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1aiXVk-0001S2-B5 for unbearable@ietf.org; Tue, 22 Mar 2016 19:23:00 -0600 From: =JeffH <Jeff.Hodges@KingsMountain.com> To: IETF Tokbind WG <unbearable@ietf.org> Message-ID: <56F1EFF0.80303@KingsMountain.com> Date: Tue, 22 Mar 2016 18:22:56 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/W87_l_pSKasFvGy0iW4E2UB9eBA> Subject: Re: [Unbearable] Sec- prefix for Token-Binding headers (was: new draft-ietf-tokbind-https-03 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Mar 2016 01:23:06 -0000 Hey Dirk, > I was told that in Yokohama it was decided to add the Sec- prefix again. (I > wasn't at that meeting.) doh, yeah, I only checked mailing list traffic and my modest notes from the tokbind session at ietf-94 Yok and didn't check the (also modest) minutes.. https://www.ietf.org/proceedings/94/minutes/minutes-94-tokbind ..which state.. Questions about threats: victim's private key should not only be kept secret, but also protected from signing arbitrary attacker-controlled data. EKR: why does EKM need to be secret. EKR: if EKM is leaked, attacker can impose their own sec header. MThomson: if we know about the header we can make ... EKR: sec header by default makes it impossible to inject. What is the argument for not using a sec header ..so it seems to me EKR was posing similar questions to those in my original msg. > As for the security considerations, they already state that a > man-in-the-middle shouldn't be able to pick the value of the > (Sec-)Token-Binding header. yes. > One corollary of that is that the value of the > (Sec-)Token-Binding header can't be set by application (Javascript) code > (since that is potentially controlled by a man-in-the-middle). yes, and that would seem to be justification for using the Sec- header field prefix. > But perhaps > it bears saying that explicitly. Wanna open an Issue? Sure. I've added it to my review comments notes (which I'll get sent to the list here before ietf-95 BA (of all three tokbind drafts) HTH, =JeffH From nobody Wed Mar 23 06:22:58 2016 Return-Path: <waywardgeek@google.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 3AC7812D7FC for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 06:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 DzFhsK6UbeD8 for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 06:22:53 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1653D12DD3D for <unbearable@ietf.org>; Wed, 23 Mar 2016 06:09:32 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id k1so18009824vkb.0 for <unbearable@ietf.org>; Wed, 23 Mar 2016 06:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=4E/VqT7bzkhO+jGjlUFIk5EqW4hMfBkgPfmDvFyRvOM=; b=a9XJFQVC2TYRWfgebPgMTN2nVi7rPcSS028TXji3g1M9x0ZgiRHjbuSWVbTtVQdedK 7sxKywPMLWfnB4dI9dN0IQmlPNMw1M5W/AJXYHCUz5TDv1Kt8YRTf8aMnEGKbA0INDnR APAPtDg8cMxZqQbc8RMggCrGrC70/AZb6437qgnBkZ4pcq4hUup8MrZaxZCbok/zhQei Cop6voKQnavl6kMSuP0Dlt7sgxOvUf2utSGhq4lXsUnKxXD8NgE9QijbjNJHLbA8oIyE 5ZC4xqa1AQtZfReqWguL1xoFNdlj37kr3XfzVZlghnU2HbEkpKbzR01TWy09qpbVf6v3 geTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=4E/VqT7bzkhO+jGjlUFIk5EqW4hMfBkgPfmDvFyRvOM=; b=TZBDMkBFQ/iwlUpUrbMNptOSk8u9fA7iPVLAajpDGlxYBavyLWOhTr1s96k4wnpP9+ 5ltUn/maRyNnfh/f3s4mrtJ9uYSd0wWHjtI6wlwc34Aeso6aFXB4XCpbrDIrBUqVxAEX f92Am633VhlY5yY2Tso4ijuHZucmpunmeotUzmoB/ZHDV8EEWszTXkXZRUWgfnJX4pzX vSeuPZoS8zrE+YRGuw5CIem9IQzJ1Ts4U7d67QoRNhbCAsUrkBSGtsr50gx5/g1OMvsO +Ld0AAZJO9pVIEZRHCJhjpS2JwM4SQJEZTMUpaZ44XZafPhF+K8FLV01G3bFwBhmaA3w 02pQ== X-Gm-Message-State: AD7BkJIbO9V7yJduZ5il1w2nyJFUQ9XBuRg48GTJuD1JK9UKYEJUOtj/XrCL35OweErBUFkqQIgoIIAmV37SCMrs MIME-Version: 1.0 X-Received: by 10.176.0.139 with SMTP id 11mr1358292uaj.36.1458738570930; Wed, 23 Mar 2016 06:09:30 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Wed, 23 Mar 2016 06:09:30 -0700 (PDT) Date: Wed, 23 Mar 2016 06:09:30 -0700 Message-ID: <CAH9QtQFLWGLgKGkD8BeuEsGAaumuqzheBgaiuOHKuUvZucuRWw@mail.gmail.com> From: Bill Cox <waywardgeek@google.com> To: Tokbind WG <unbearable@ietf.org> Content-Type: multipart/alternative; boundary=001a11c15dac576f86052eb70a26 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/mnyYSqfPafGDHpiX-gNF2GlwdeE> Subject: [Unbearable] Thoughts on TLS 0-RTT 1.3 compatibility X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Mar 2016 13:22:56 -0000 --001a11c15dac576f86052eb70a26 Content-Type: text/plain; charset=UTF-8 Summary: For HTTP connections, use session caches on both client and server, and support 0-RTT stateful resumption. Disallow token binding to be used to authenticate a stateless 0-RTT connection. Secure all secret keys close to the device (including TLS session secrets), and save the browser's session cache to disk. As we know, stateless 0-RTT breaks strong client authentication. All stateless servers running 0-RTT will fail to finish valid token binding proofs-of-possession in time to protect first-flight data, leading to various new and exciting attacks. IMO, this limitation makes using either token binding or client certificates with stateless 0-RTT enabled servers a bad idea. Even offering support for such a mode reduces security, and should be avoided. I have difficulty finding significant real attacks that are defeated by token binding or client certificates when used over a stateless 0-RTT connection. IMO, without a proof of possession, both token binding and client certificates are nearly pointless. However, we can safely support one TLS 1.3 0-RTT mode. IMO, the right way to do 0-RTT token binding over TLS 1.3 is to use session caches on both the client and server, and to only do 0-RTT during a resumption. That way, the proof-of-possession is done on the initial secure 1-RTT handshake, and the security properties are inherited by future resumed connections. The steps in the handshakes are: During the initial 1-RTT handshake: - negotiate TB as in TLS 1.2 - server creates a small encrypted ticket containing only the session ID and a "resumption count" set to 0 - server sends the ticket to the client During a 0-RTT resumption handshake: - client sends TB extension, because this might fall back to 1-RTT - client sends the ticket to the server - server decrypts the ticket, checks for a cache hit, and drop to 1-RTT if not found - server compares the resumption counts in the session state and ticket, and drops to 1-RTT if they do not match - server increments the resumption counts in the ticket and session state - server encryptes the updated ticket and sends it to the client - server executes 0-RTT HTTP requests from the client's first flight of packets Other stateful schemes are possible, such as using strike registers. However, there is growing evidence that using other stateful server modes tends to fail in practice. These schemes are simply too tricky to get right. However, session caches have worked for many years and are widely deployed. Surprisingly (to me), this even provides full perfect forward secrecy (PFS). This is because TLS 1.3 uses a "master resumption secret" to resume a session, so that even first flight 0-RTT packets are encrypted with new keys. The server never writes old session secrets to the cache. The long lifetime of the ticket decryption key does not hurt PFS in servers using session caching with TLS 1.3, unlike stateless servers doing 0-RTT resumption. One issue to be resolved is exactly what TLS-unique should be signed during resumed sessions. My preference is to remember the original TLS-unique from the initial session and continue to sign that. This would allow servers to also remember which TB headers have already been validated between connections, greatly reducing the CPU overhead of TB. A nice way to enable this to happen would be to specify in TLS 1.3 that the Export Key Material API should provide the same results in resumed sessions as in the original 1-RTT connection. I would prefer this for TLS 1.2 as well, though I suspect that ship has already sailed. The security of session-cache based 0-RTT appears to be nearly equivalent to TLS 1.2 resumption. The only new security issue I see is that sometimes the TLS layer will automatically replay 0-RTT application data. This happens when the server rejects a 0-RTT handshake and drops to a full 1-RTT handshake. In this case, the client is required to resend the 0-RTT application data. An attacker can make use of this to cause the first-flight data to be replayed once. However, for HTTP, the attacker already has this capability <http://blog.valverde.me/2015/12/07/bad-life-advice/#.VvKEt2ErKlG>, and it applies to all HTTP requests, not just first-flight requests. Because of this, I see no reason to restrict first-flight application data from sending POST requests. This means that potentially, stateful 0-RTT servers can be slightly faster than stateless 0-RTT servers. Making stateful 0-RTT servers really fast means we need high resumption rates. I think the #1 reason that QUIC achieves very high 0-RTT rates compared to either session caches or tickets is that browsers typically do not write the session cache to disk, while QUIC does write the server config to disk. The motivation for not writing the cache to disk is that this creates a new bearer token, where malware can steal the resumption data from disk and resume a session elsewhere. However, as soon as my laptop hibernates, the session cache is written to disk anyway, and there is often nothing stopping malware from stealing the cached session from memory. The right model, IMO, for protecting secrets is to keep them secured as close to hardware as possible. All secret keys should be cryptographically bound to the device, and unusable on any other device. This includes the TLS session secrets. Using a TPM is too slow, but Skylake Intel processors have an SGX mode that is clearly fast enough. Android devices offer trusted execution environment, which can be fast enough, depending on the device and software stack. Alternatively, the OS can employ disk encryption and modern secure jails for all applications. Either way, the result is that secrets are cryptographically bound to the device, even when written to disk. On such systems, the browser should just go ahead and save the cache. If we do all this, the future for token binding seems promising to me. If we instead go down the stateless 0-RTT path, strong client authentication gets thrown under the bus. Bill --001a11c15dac576f86052eb70a26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Summary: For HTTP connections, use session caches on = both client and server, and support 0-RTT stateful resumption.=C2=A0 Disall= ow token binding to be used to authenticate a stateless 0-RTT connection.= =C2=A0 Secure all secret keys close to the device (including TLS session se= crets), and save the browser's session cache to disk.</div><div><br></d= iv>As we know, stateless 0-RTT breaks strong client authentication.=C2=A0 A= ll stateless servers running 0-RTT will fail to finish valid token binding = proofs-of-possession in time to protect first-flight data, leading to vario= us new and exciting attacks.=C2=A0 IMO, this limitation makes using either = token binding or client certificates with stateless 0-RTT enabled servers a= bad idea.=C2=A0 Even offering support for such a mode reduces security, an= d should be avoided.=C2=A0 I have difficulty finding significant real attac= ks that are defeated by token binding or client certificates when used over= a stateless 0-RTT connection.=C2=A0 IMO, without a proof of possession, bo= th token binding and client certificates are nearly pointless.<div><br></di= v><div>However, we can safely support one TLS 1.3 0-RTT mode.</div><div><br= ></div><div>IMO, the right way to do 0-RTT token binding over TLS 1.3 is to= use session caches on both the client and server, and to only do 0-RTT dur= ing a resumption.=C2=A0 That way, the proof-of-possession is done on the in= itial secure 1-RTT handshake, and the security properties are inherited by = future resumed connections.=C2=A0 The steps in the handshakes are:</div><di= v><br></div><div><div>During the initial 1-RTT handshake:</div><div>- negot= iate TB as in TLS 1.2</div><div>- server creates a small encrypted ticket c= ontaining only the session ID and a "resumption count" set to 0</= div><div>- server sends the ticket to the client</div><div><br></div><div>D= uring a 0-RTT resumption handshake:</div><div>- client sends TB extension, = because this might fall back to 1-RTT</div><div>- client sends the ticket t= o the server</div><div>- server decrypts the ticket, checks for a cache hit= , and drop to 1-RTT if not found</div><div>- server compares the resumption= counts in the session state and ticket, and drops to 1-RTT if they do not = match</div><div>- server increments the resumption counts in the ticket and= session state</div><div>- server encryptes the updated ticket and sends it= to the client</div></div><div>- server executes 0-RTT HTTP requests from t= he client's first flight of packets</div><div><br></div><div>Other stat= eful schemes are possible, such as using strike registers.=C2=A0 However, t= here is growing evidence that using other stateful server modes tends to fa= il in practice.=C2=A0 These schemes are simply too tricky to get right.=C2= =A0 However, session caches have worked for many years and are widely deplo= yed.</div><div><br></div><div>Surprisingly (to me), this even provides full= perfect forward secrecy (PFS).=C2=A0 This is because TLS 1.3 uses a "= master resumption secret" to resume a session, so that even first flig= ht 0-RTT packets are encrypted with new keys.=C2=A0 The server never writes= old session secrets to the cache.=C2=A0 The long lifetime of the ticket de= cryption key does not hurt PFS in servers using session caching with TLS 1.= 3, unlike stateless servers doing 0-RTT resumption.</div><div><br></div><di= v>One issue to be resolved is exactly what TLS-unique should be signed duri= ng resumed sessions.=C2=A0 My preference is to remember the original TLS-un= ique from the initial session and continue to sign that.=C2=A0 This would a= llow servers to also remember which TB headers have already been validated = between connections, greatly reducing the CPU overhead of TB.=C2=A0 A nice = way to enable this to happen would be to specify in TLS 1.3 that the Export= Key Material API should provide the same results in resumed sessions as in= the original 1-RTT connection.=C2=A0 I would prefer this for TLS 1.2 as we= ll, though I suspect that ship has already sailed.</div><div><br></div><div= >The security of session-cache based 0-RTT appears to be nearly equivalent = to TLS 1.2 resumption.=C2=A0 The only new security issue I see is that some= times the TLS layer will automatically replay 0-RTT application data.=C2=A0= This happens when the server rejects a 0-RTT handshake and drops to a full= 1-RTT handshake.=C2=A0 In this case, the client is required to resend the = 0-RTT application data.=C2=A0 An attacker can make use of this to cause the= first-flight data to be replayed once.=C2=A0 However, for HTTP, the attack= er <a href=3D"http://blog.valverde.me/2015/12/07/bad-life-advice/#.VvKEt2Er= KlG">already has this capability</a>, and it applies to all HTTP requests, = not just first-flight requests.=C2=A0 Because of this, I see no reason to r= estrict first-flight application data from sending POST requests.=C2=A0 Thi= s means that potentially, stateful 0-RTT servers can be slightly faster tha= n stateless 0-RTT servers.</div><div><br></div><div>Making stateful 0-RTT s= ervers really fast means we need high resumption rates.=C2=A0 I think the #= 1 reason that QUIC achieves very high 0-RTT rates compared to either sessio= n caches or tickets is that browsers typically do not write the session cac= he to disk, while QUIC does write the server config to disk.=C2=A0 The moti= vation for not writing the cache to disk is that this creates a new bearer = token, where malware can steal the resumption data from disk and resume a s= ession elsewhere.=C2=A0 However, as soon as my laptop hibernates, the sessi= on cache is written to disk anyway, and there is often nothing stopping mal= ware from stealing the cached session from memory.</div><div><br></div><div= >The right model, IMO, for protecting secrets is to keep them secured as cl= ose to hardware as possible.=C2=A0 All secret keys should be cryptographica= lly bound to the device, and unusable on any other device.=C2=A0 This inclu= des the TLS session secrets.=C2=A0 Using a TPM is too slow, but Skylake Int= el processors have an SGX mode that is clearly fast enough.=C2=A0 Android d= evices offer trusted execution environment, which can be fast enough, depen= ding on the device and software stack.=C2=A0 Alternatively, the OS can empl= oy disk encryption and modern secure jails for all applications.=C2=A0 Eith= er way, the result is that secrets are cryptographically bound to the devic= e, even when written to disk.=C2=A0 On such systems, the browser should jus= t go ahead and save the cache.</div><div><br></div><div>If we do all this, = the future for token binding seems promising to me.=C2=A0 If we instead go = down the stateless 0-RTT path, strong client authentication gets thrown und= er the bus.</div><div><br></div><div>Bill</div></div> --001a11c15dac576f86052eb70a26-- From nobody Wed Mar 23 06:35:21 2016 Return-Path: <waywardgeek@google.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 4EEE512D6D7 for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 06:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 MaVsgV7FKh9c for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 06:35:13 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0F212DC9D for <unbearable@ietf.org>; Wed, 23 Mar 2016 06:19:58 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id e185so18351339vkb.1 for <unbearable@ietf.org>; Wed, 23 Mar 2016 06:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=J7Lf+BC60M+SDJAvgE40RCJZXcf/5qKU6idog/+9OIk=; b=VaYb7pFnvwe7yT11WgDSPg4EaELBq1TzIZPPUINcGFGl7mIeJHeLvYCEGu0lUgzhKx IyTXnEPDYcNlkKKxa/AlUzixbxZEPN1tSl2jDy70sHB1PFVdZ0WlGYAzNLpmrQOBI1eI v/CXki+ndk288wiG0eoVrMgVlkBKTRNm1z3DSg3TluunXfiJ2wtd/tDSy8Z7DCN/ZXkP A6vhYxsdKpwxOQWt4pC4LWV10JY7iwW7fn8fV2J0Q+GoYsUAspvVYiVX2UFbMroNu2QN 22ph2qY3/FoLTdptUK4YwnurMWkMizKdWj192SnU6eSClY9diHwvYKZggohMMpXZecX6 glag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=J7Lf+BC60M+SDJAvgE40RCJZXcf/5qKU6idog/+9OIk=; b=VI3O4JRPoc1gD4tPkbS0XVVgmEiUDW8+IhiaZbZiHt0BEiepcB1CZM53cRqIogX9X6 RqLdqp7dh+FsVdDvVDymBWuOpYvbUm3Sf603FB6LzA7AbbITcVQOjTV/uvZNSDk9bxwY 4iX9NSQfjU4jAqm0fsp6zF40obm4dwPwZRU6b/p6QgaGoW2omH8RyEV2JVv73pmb89JH AiUoIqvimJ6mXGjSCAQucOHZkDXcx0CQncUaJrlc/jQSX1LVi1MwoJQc2t3L/eVxYT18 V9xdvwjwVqhT0lM8YE0Yje1QMbJS5fBMcM5jFmc34/VO/Jo9btWXYuWeH/87VxkSZ1gJ jhMw== X-Gm-Message-State: AD7BkJJbuPMMr29Rc7o2p4oQ9U4Xx8ji3tBezIZ2plYspfQOlMK1uWApuw6j1qzBShWHZjhJaSTNmcHTtV3Q9dev MIME-Version: 1.0 X-Received: by 10.31.180.213 with SMTP id d204mr1241116vkf.80.1458739197351; Wed, 23 Mar 2016 06:19:57 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Wed, 23 Mar 2016 06:19:57 -0700 (PDT) Date: Wed, 23 Mar 2016 06:19:57 -0700 Message-ID: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> From: Bill Cox <waywardgeek@google.com> To: Tokbind WG <unbearable@ietf.org> Content-Type: multipart/alternative; boundary=001a1144030eadedb5052eb72fe6 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/Unr0ou8af84UF2_iJaM6AbQ6Ii8> Subject: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Mar 2016 13:35:19 -0000 --001a1144030eadedb5052eb72fe6 Content-Type: text/plain; charset=UTF-8 I think of this as a thing we should consider when we upgrade token binding to support TLS 1.3. Since TLS 1.3 seems to be getting close to finalized, is this a reasonable time to start discussing a MitM extension? I've written up an internal proposal for this, but in short, for token binding to be enforced globally, we have to deal with the problem of corporate proxies and anti-virus MitMs. We can do this with a token binding extension that provides the material signed by the client. It would be used whenever the client detects that it is being MitM-ed with a locally installed cert. I've evaluated every attack I can think of, and in each case this is at least as secure as the alternative: issuing unbound auth tokens. There are further steps that can improve security, such as having the server initiate a proof-of-possession at the application layer when a MitM extension is received from the client. However, this is above the token-binding layer, and does not need to be an official part of token binding. Bill --001a1144030eadedb5052eb72fe6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div>I think of this as a thing we should consider wh= en we upgrade token binding to support TLS 1.3.=C2=A0 Since TLS 1.3 seems t= o be getting close to finalized, is this a reasonable time to start discuss= ing a MitM extension?</div></div><div><br></div>I've written up an inte= rnal proposal for this, but in short, for token binding to be enforced glob= ally, we have to deal with the problem of corporate proxies and anti-virus = MitMs.=C2=A0 We can do this with a token binding extension that provides th= e material signed by the client.=C2=A0 It would be used whenever the client= detects that it is being MitM-ed with a locally installed cert.=C2=A0 I= 9;ve evaluated every attack I can think of, and in each case this is at lea= st as secure as the alternative: issuing unbound auth tokens.<div><br></div= ><div>There are further steps that can improve security, such as having the= server initiate a proof-of-possession at the application layer when a MitM= extension is received from the client.=C2=A0 However, this is above the to= ken-binding layer, and does not need to be an official part of token bindin= g.</div><div><br></div><div>Bill<br></div></div> --001a1144030eadedb5052eb72fe6-- From nobody Wed Mar 23 07:07:50 2016 Return-Path: <squid3@treenet.co.nz> 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 7E42512D57D for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 07:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 tqzcKaL2g0Um for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 07:07:45 -0700 (PDT) Received: from treenet.co.nz (unknown [121.99.228.82]) by ietfa.amsl.com (Postfix) with ESMTP id D123B12D6C9 for <unbearable@ietf.org>; Wed, 23 Mar 2016 06:51:48 -0700 (PDT) Received: from [192.168.20.251] (unknown [121.98.45.158]) by treenet.co.nz (Postfix) with ESMTP id 3FBFEE6D7F for <unbearable@ietf.org>; Thu, 24 Mar 2016 01:51:47 +1200 (NZST) To: unbearable@ietf.org References: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> From: Amos Jeffries <squid3@treenet.co.nz> Message-ID: <56F29F69.1080105@treenet.co.nz> Date: Thu, 24 Mar 2016 02:51:37 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/SPmY4xWNJc5emv8B_HdngCCVYq4> Subject: Re: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Mar 2016 14:07:48 -0000 On 24/03/2016 2:19 a.m., Bill Cox wrote: > I think of this as a thing we should consider when we upgrade token binding > to support TLS 1.3. Since TLS 1.3 seems to be getting close to finalized, > is this a reasonable time to start discussing a MitM extension? > > I've written up an internal proposal for this, but in short, for token > binding to be enforced globally, we have to deal with the problem of > corporate proxies and anti-virus MitMs. We can do this with a token > binding extension that provides the material signed by the client. It > would be used whenever the client detects that it is being MitM-ed with a > locally installed cert. I've evaluated every attack I can think of, and in > each case this is at least as secure as the alternative: issuing unbound > auth tokens. Having a locally installed cert is no guaratee of MITM being performed. Nor a reliable indicator that an MITM isn't using a rogue CA cert. A more reliable indicator is that these active MITM use different TLS keying material on the server connection as compared to the client connection. So the signed tokens should be detectible. Passive MITM (if possible) are not touching the TLS content, so the clients tokens will get through anyway. > > There are further steps that can improve security, such as having the > server initiate a proof-of-possession at the application layer when a MitM > extension is received from the client. However, this is above the > token-binding layer, and does not need to be an official part of token > binding. > IMHO, any active MITM which is legitimately present should be able to hook into the system as a federated agent. Being known to the Identity Provider as a client in its own right allows it to generate its own tokens for the server connection and replace the ones the end-client is using. This allows the MITM to operate, as well as still detecting any unexpected ones that try to MITM the traffic. Amos From nobody Wed Mar 23 08:47:26 2016 Return-Path: <waywardgeek@google.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 0B73912D67C for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 08:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 gKMOzEPacxSI for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 08:47:23 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F4D12D520 for <unbearable@ietf.org>; Wed, 23 Mar 2016 08:47:22 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id e6so24620686vkh.2 for <unbearable@ietf.org>; Wed, 23 Mar 2016 08:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=++2Zf5tEEorEq4NdW5MzDEzUXchnEU/QRkRgO2ZBvOA=; b=HHR0JgQpERnITRawQlGEGiXAJcoXvdJh/atBBQYVh9Cbk18R69b8q/ADfScIe0M4IR /JK6k3KYNObs/jV66NheA9Iz01qKYVEFW8Xe23kvCqjfU8Vh8JOb01AftBtdsyy/9tyN Q1zK9fvhedpy/LVtz9TYsfGpLawOVswYLJzUqOeS1J5DwmWiIpa5aPjLY63bTZ4d1S3c 4LBr/QCKT3QN8Qt3zKpq2xQL+bO4B7u4nn/5ZY0CkAGqtDbKQkRA5Jc7oBgtooGbzsvx Wthz5cg0aY2ZHn3It7MdgywHKN5zfTo5HopcJG10lnAGZZ2oQNu3X8G7QEXV06MOUGZ0 qYHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=++2Zf5tEEorEq4NdW5MzDEzUXchnEU/QRkRgO2ZBvOA=; b=QQFEx3SjRWqUHP7OYrG+j+zdxdPUZj16tg2syvhfeREoenvxCaGNao2iFZL6gtcxrb mKNw088pZKQa4ElBLUXlAtFDIOnYWoN+s9iEVojNw5eOxU7H2Rgb10YGpfnT5koTwdWI nmIkNdqYuQhHHcus2JGJsxe5bVK8Ud92f9Pi8HewlBpEK+Uma4uxTm8Mwj64ko4+kYMq 2O1DglWIMzgPTa3wCNxqBgHGuNvNaNdYuZU+eg8Pk8+q5RTKoAre7TtjTa7UtXiQsx7T kXbWo5YqcABx7jp3CNhGRio0gkquJ+ZXeG76YllKi7ZFo8s5dWl5vWk1gR42pYei1mIg nH/w== X-Gm-Message-State: AD7BkJKjbjCliXfYWdo24ROkVZ5TOQU9UYltswPPfrLizSIO9XyPkpAmTplvfdjgH6xrEsNSkxDimFYnmZlfGheG MIME-Version: 1.0 X-Received: by 10.31.134.71 with SMTP id i68mr1890991vkd.46.1458748041164; Wed, 23 Mar 2016 08:47:21 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Wed, 23 Mar 2016 08:47:21 -0700 (PDT) In-Reply-To: <56F29F69.1080105@treenet.co.nz> References: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> <56F29F69.1080105@treenet.co.nz> Date: Wed, 23 Mar 2016 08:47:21 -0700 Message-ID: <CAH9QtQHs61xW9P_4TjQq-Jz=QPbVH9aDsYUUZc3fCNScQvcZPw@mail.gmail.com> From: Bill Cox <waywardgeek@google.com> To: Amos Jeffries <squid3@treenet.co.nz> Content-Type: multipart/alternative; boundary=001a11458eb4cfcc9d052eb93e40 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/1msen8P01Ld3eOg8K_8YyzvUZJY> Cc: Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Mar 2016 15:47:26 -0000 --001a11458eb4cfcc9d052eb93e40 Content-Type: text/plain; charset=UTF-8 We have a chicken-and-the-egg problem. Legit MitM boxes will only support TB once TB is both widely deployed and enforced. On the other hand, we cannot enforce TB globally until we have a solution for users who travel to work and back so that they often connect direct, and often through a corporate proxy. This MitM extension is needed to get past this deadlock. I think we should "detect" a MitM this way: If the browser has a valid TB key pair for the eTLD+1 domain, yet the server failed to negotiate token binding using the TLS extension, then it is likely that there is a MitM that does not speak TB. In this case, enable the MitM extension and send TB headers anyway. The server will see TB headers from a client that did not negotiate TB, and the signature will mismatch. However, the server can verify the TB signature over the value in the extension. If requests contain an auth token specifically authorizing use behind this MitM, then the server should allow requests to be processed. The following detail is important: When a server sees the TB extension and a mismatch of the TLS-unique vs the value in the extension, but the auth token does not authorize this MitM, it needs to authenticate the user and issue an enhanced auth token that additionally authenticates the user behind this MitM. Otherwise, attackers could simply MitM themselves and authenticate with stolen auth tokens. Bill On Wed, Mar 23, 2016 at 6:51 AM, Amos Jeffries <squid3@treenet.co.nz> wrote: > On 24/03/2016 2:19 a.m., Bill Cox wrote: > > I think of this as a thing we should consider when we upgrade token > binding > > to support TLS 1.3. Since TLS 1.3 seems to be getting close to > finalized, > > is this a reasonable time to start discussing a MitM extension? > > > > I've written up an internal proposal for this, but in short, for token > > binding to be enforced globally, we have to deal with the problem of > > corporate proxies and anti-virus MitMs. We can do this with a token > > binding extension that provides the material signed by the client. It > > would be used whenever the client detects that it is being MitM-ed with a > > locally installed cert. I've evaluated every attack I can think of, and > in > > each case this is at least as secure as the alternative: issuing unbound > > auth tokens. > > Having a locally installed cert is no guaratee of MITM being performed. > Nor a reliable indicator that an MITM isn't using a rogue CA cert. > > A more reliable indicator is that these active MITM use different TLS > keying material on the server connection as compared to the client > connection. So the signed tokens should be detectible. > > Passive MITM (if possible) are not touching the TLS content, so the > clients tokens will get through anyway. > > > > > There are further steps that can improve security, such as having the > > server initiate a proof-of-possession at the application layer when a > MitM > > extension is received from the client. However, this is above the > > token-binding layer, and does not need to be an official part of token > > binding. > > > > IMHO, any active MITM which is legitimately present should be able to > hook into the system as a federated agent. Being known to the Identity > Provider as a client in its own right allows it to generate its own > tokens for the server connection and replace the ones the end-client is > using. > > This allows the MITM to operate, as well as still detecting any > unexpected ones that try to MITM the traffic. > > Amos > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a11458eb4cfcc9d052eb93e40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">We have a chicken-and-the-egg problem.=C2=A0 Legit MitM bo= xes will only support TB once TB is both widely deployed and enforced.=C2= =A0 On the other hand, we cannot enforce TB globally until we have a soluti= on for users who travel to work and back so that they often connect direct,= and often through a corporate proxy.=C2=A0 This MitM extension is needed t= o get past this deadlock.<div><br></div><div>I think we should "detect= " a MitM this way:<br></div><div><br></div><div>If the browser has a v= alid TB key pair for the eTLD+1 domain, yet the server failed to negotiate = token binding using the TLS extension, then it is likely that there is a Mi= tM that does not speak TB.=C2=A0 In this case, enable the MitM extension an= d send TB headers anyway.=C2=A0 The server will see TB headers from a clien= t that did not negotiate TB, and the signature will mismatch.=C2=A0 However= , the server can verify the TB signature over the value in the extension.= =C2=A0 If requests contain an auth token specifically authorizing use behin= d this MitM, then the server should allow requests to be processed.</div><d= iv><br></div><div>The following detail is important: When a server sees the= TB extension and a mismatch of the TLS-unique vs the value in the extensio= n, but the auth token does not authorize this MitM, it needs to authenticat= e the user and issue an enhanced auth token that additionally authenticates= the user behind this MitM.=C2=A0 Otherwise, attackers could simply MitM th= emselves and authenticate with stolen auth tokens.</div><div><br></div><div= >Bill</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">= On Wed, Mar 23, 2016 at 6:51 AM, Amos Jeffries <span dir=3D"ltr"><<a hre= f=3D"mailto:squid3@treenet.co.nz" target=3D"_blank">squid3@treenet.co.nz</a= >></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 = 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 2= 4/03/2016 2:19 a.m., Bill Cox wrote:<br> > I think of this as a thing we should consider when we upgrade token bi= nding<br> > to support TLS 1.3.=C2=A0 Since TLS 1.3 seems to be getting close to f= inalized,<br> > is this a reasonable time to start discussing a MitM extension?<br> ><br> > I've written up an internal proposal for this, but in short, for t= oken<br> > binding to be enforced globally, we have to deal with the problem of<b= r> > corporate proxies and anti-virus MitMs.=C2=A0 We can do this with a to= ken<br> > binding extension that provides the material signed by the client.=C2= =A0 It<br> > would be used whenever the client detects that it is being MitM-ed wit= h a<br> > locally installed cert.=C2=A0 I've evaluated every attack I can th= ink of, and in<br> > each case this is at least as secure as the alternative: issuing unbou= nd<br> > auth tokens.<br> <br> </span>Having a locally installed cert is no guaratee of MITM being perform= ed.<br> Nor a reliable indicator that an MITM isn't using a rogue CA cert.<br> <br> A more reliable indicator is that these active MITM use different TLS<br> keying material on the server connection as compared to the client<br> connection. So the signed tokens should be detectible.<br> <br> Passive MITM (if possible) are not touching the TLS content, so the<br> clients tokens will get through anyway.<br> <span class=3D""><br> ><br> > There are further steps that can improve security, such as having the<= br> > server initiate a proof-of-possession at the application layer when a = MitM<br> > extension is received from the client.=C2=A0 However, this is above th= e<br> > token-binding layer, and does not need to be an official part of token= <br> > binding.<br> ><br> <br> </span>IMHO, any active MITM which is legitimately present should be able t= o<br> hook into the system as a federated agent. Being known to the Identity<br> Provider as a client in its own right allows it to generate its own<br> tokens for the server connection and replace the ones the end-client is<br> using.<br> <br> This allows the MITM to operate, as well as still detecting any<br> unexpected ones that try to MITM the traffic.<br> <br> Amos<br> <br> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org">Unbearable@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> </blockquote></div><br></div> --001a11458eb4cfcc9d052eb93e40-- From nobody Wed Mar 23 10:09:14 2016 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 2BDAA12D1DC for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 10:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 KMx2dlpKAc8A for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 10:09:10 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0115.outbound.protection.outlook.com [65.55.169.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9AD612D0E1 for <unbearable@ietf.org>; Wed, 23 Mar 2016 10:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P/7NT/JYXMqCS3I+YzS+ueYp84zTkDXOGXu+s79ZJq4=; b=BRT4FRXn+ancVP5BFCJhrp/wi8SmAsgPFI5KItz7DAsecm72ECBbEihMnKqV6oeR3ZRXSM8BgyrsCPFmV0JGW5eQNS5fU+RZEZMWVCX+Q40qgIV13mraMA40slLa+gWbVCYsAkk/cSxxU2cTjPx+J7UidKYxXmJBVRrKwbbYRXc= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1394.namprd03.prod.outlook.com (10.163.81.140) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 23 Mar 2016 17:09:07 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0434.021; Wed, 23 Mar 2016 17:09:07 +0000 From: Andrei Popov <Andrei.Popov@microsoft.com> To: Bill Cox <waywardgeek@google.com>, Tokbind WG <unbearable@ietf.org> Thread-Topic: [Unbearable] Thoughts on TLS 0-RTT 1.3 compatibility Thread-Index: AQHRhQcgxIK280Rw4Uycc/vXubnt6Z9nP4hw Date: Wed, 23 Mar 2016 17:09:07 +0000 Message-ID: <BLUPR03MB139616608F68A44A25D7A6758C810@BLUPR03MB1396.namprd03.prod.outlook.com> References: <CAH9QtQFLWGLgKGkD8BeuEsGAaumuqzheBgaiuOHKuUvZucuRWw@mail.gmail.com> In-Reply-To: <CAH9QtQFLWGLgKGkD8BeuEsGAaumuqzheBgaiuOHKuUvZucuRWw@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:1::1d2] x-ms-office365-filtering-correlation-id: 27f68ccc-65e2-47c0-13bf-08d3533dd84b x-microsoft-exchange-diagnostics: 1; BLUPR03MB1394; 5:3TgQfIla3uO4D3PN2rBedVkGLp46AWa5L0g75PhCk4BufI1rjl3hPach2hQdFKfZfDkyohObZjWOR72z43aPhMO6g2lBShivwZZHEeIFo2coMsBd3p7uTGtu4oofvnfPPKrEeGzYA3+VrBtlEhvqgw==; 24:lkg90vmLm4CJkEUYsio6SLod6Rf+TcizG3Qn8t3q70Szfeqi2dEuLL6WSoSbIGPauIXepMhMBIsBZbD8xUZRIe34018VNdLhCJ+OnDTNeXA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1394; x-microsoft-antispam-prvs: <BLUPR03MB1394D323A5FA555E597E24FD8C810@BLUPR03MB1394.namprd03.prod.outlook.com> x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1394; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1394; x-forefront-prvs: 08902E536D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(52314003)(86362001)(19300405004)(16236675004)(19609705001)(19580395003)(33656002)(19580405001)(19625215002)(561944003)(5005710100001)(10400500002)(10290500002)(74316001)(54356999)(76176999)(50986999)(2950100001)(2900100001)(15975445007)(19617315012)(77096005)(76576001)(106116001)(99286002)(10090500001)(5008740100001)(586003)(107886002)(5004730100002)(81166005)(790700001)(1096002)(189998001)(6116002)(102836003)(87936001)(5003600100002)(92566002)(5001770100001)(11100500001)(2906002)(1220700001)(3660700001)(3280700002)(5002640100001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1394; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB139616608F68A44A25D7A6758C810BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2016 17:09:07.3659 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1394 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/_0LycccGcYso695yFLeqaOsjonw> Subject: Re: [Unbearable] Thoughts on TLS 0-RTT 1.3 compatibility X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Mar 2016 17:09:13 -0000 --_000_BLUPR03MB139616608F68A44A25D7A6758C810BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIGNvcnJlY3QgbWUgaWYgSSByZWFkIHRoaXMgd3JvbmcsIGJ1dCB0aGUgVEItcmVsYXRl ZCBwYXJ0IG9mIHRoaXMgcHJvcG9zYWwgZXNzZW50aWFsbHkgYW1vdW50cyB0byByZW1vdmluZyB0 aGUgcmVxdWlyZW1lbnQgdGhhdCB0aGUgY2xpZW50IHByb3ZlIHBvc3Nlc3Npb24gb2YgdGhlIFRC IGtleSBvbiByZXN1bXB0aW9uLg0KDQpUaGlzIHJlcXVpcmVtZW50IGV4aXN0cyB0b2RheSBiZWNh dXNlIFRMUyByZXN1bXB0aW9uIHN0YXRlIGlzIGRlZW1lZCBlYXNpZXIgdG8gc3RlYWwgdGhhbiBh IGhhcmR3YXJlLWJvdW5kIFRCIGtleS4gT25jZSBUTFMgcmVzdW1wdGlvbiBzdGF0ZSBpcyBwcm90 ZWN0ZWQgaW4gdGhlIHNhbWUgd2F5IGFzIHRoZSBUQiBrZXksIHRoZW4gdGhlcmUgd2lsbCBwcm9i YWJseSBiZSBubyBuZWVkIGZvciB0aGUgY2xpZW50IHRvIHNpZ24gd2l0aCBpdHMgVEIga2V5IHdo ZW4gcmVzdW1pbmcgYSBUTFMgc2Vzc2lvbi4NCg0KT25jZSBUTFMgMS4zIHN0YWJpbGl6ZXMgc29t ZSBtb3JlLCBJIHRoaW5rIHdl4oCZbGwgbmVlZCB0byB3cml0ZSBhIG5ldyBkb2N1bWVudCBleHBs YWluaW5nIGhvdyBUQiBjYW4gYmUgdXNlZCB3aXRoIFRMUyAxLjMuDQoNCkNoZWVycywNCg0KQW5k cmVpDQoNCkZyb206IFVuYmVhcmFibGUgW21haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBCaWxsIENveA0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyMywgMjAx NiA2OjEwIEFNDQpUbzogVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz4NClN1YmplY3Q6 IFtVbmJlYXJhYmxlXSBUaG91Z2h0cyBvbiBUTFMgMC1SVFQgMS4zIGNvbXBhdGliaWxpdHkNCg0K U3VtbWFyeTogRm9yIEhUVFAgY29ubmVjdGlvbnMsIHVzZSBzZXNzaW9uIGNhY2hlcyBvbiBib3Ro IGNsaWVudCBhbmQgc2VydmVyLCBhbmQgc3VwcG9ydCAwLVJUVCBzdGF0ZWZ1bCByZXN1bXB0aW9u LiAgRGlzYWxsb3cgdG9rZW4gYmluZGluZyB0byBiZSB1c2VkIHRvIGF1dGhlbnRpY2F0ZSBhIHN0 YXRlbGVzcyAwLVJUVCBjb25uZWN0aW9uLiAgU2VjdXJlIGFsbCBzZWNyZXQga2V5cyBjbG9zZSB0 byB0aGUgZGV2aWNlIChpbmNsdWRpbmcgVExTIHNlc3Npb24gc2VjcmV0cyksIGFuZCBzYXZlIHRo ZSBicm93c2VyJ3Mgc2Vzc2lvbiBjYWNoZSB0byBkaXNrLg0KDQpBcyB3ZSBrbm93LCBzdGF0ZWxl c3MgMC1SVFQgYnJlYWtzIHN0cm9uZyBjbGllbnQgYXV0aGVudGljYXRpb24uICBBbGwgc3RhdGVs ZXNzIHNlcnZlcnMgcnVubmluZyAwLVJUVCB3aWxsIGZhaWwgdG8gZmluaXNoIHZhbGlkIHRva2Vu IGJpbmRpbmcgcHJvb2ZzLW9mLXBvc3Nlc3Npb24gaW4gdGltZSB0byBwcm90ZWN0IGZpcnN0LWZs aWdodCBkYXRhLCBsZWFkaW5nIHRvIHZhcmlvdXMgbmV3IGFuZCBleGNpdGluZyBhdHRhY2tzLiAg SU1PLCB0aGlzIGxpbWl0YXRpb24gbWFrZXMgdXNpbmcgZWl0aGVyIHRva2VuIGJpbmRpbmcgb3Ig Y2xpZW50IGNlcnRpZmljYXRlcyB3aXRoIHN0YXRlbGVzcyAwLVJUVCBlbmFibGVkIHNlcnZlcnMg YSBiYWQgaWRlYS4gIEV2ZW4gb2ZmZXJpbmcgc3VwcG9ydCBmb3Igc3VjaCBhIG1vZGUgcmVkdWNl cyBzZWN1cml0eSwgYW5kIHNob3VsZCBiZSBhdm9pZGVkLiAgSSBoYXZlIGRpZmZpY3VsdHkgZmlu ZGluZyBzaWduaWZpY2FudCByZWFsIGF0dGFja3MgdGhhdCBhcmUgZGVmZWF0ZWQgYnkgdG9rZW4g YmluZGluZyBvciBjbGllbnQgY2VydGlmaWNhdGVzIHdoZW4gdXNlZCBvdmVyIGEgc3RhdGVsZXNz IDAtUlRUIGNvbm5lY3Rpb24uICBJTU8sIHdpdGhvdXQgYSBwcm9vZiBvZiBwb3NzZXNzaW9uLCBi b3RoIHRva2VuIGJpbmRpbmcgYW5kIGNsaWVudCBjZXJ0aWZpY2F0ZXMgYXJlIG5lYXJseSBwb2lu dGxlc3MuDQoNCkhvd2V2ZXIsIHdlIGNhbiBzYWZlbHkgc3VwcG9ydCBvbmUgVExTIDEuMyAwLVJU VCBtb2RlLg0KDQpJTU8sIHRoZSByaWdodCB3YXkgdG8gZG8gMC1SVFQgdG9rZW4gYmluZGluZyBv dmVyIFRMUyAxLjMgaXMgdG8gdXNlIHNlc3Npb24gY2FjaGVzIG9uIGJvdGggdGhlIGNsaWVudCBh bmQgc2VydmVyLCBhbmQgdG8gb25seSBkbyAwLVJUVCBkdXJpbmcgYSByZXN1bXB0aW9uLiAgVGhh dCB3YXksIHRoZSBwcm9vZi1vZi1wb3NzZXNzaW9uIGlzIGRvbmUgb24gdGhlIGluaXRpYWwgc2Vj dXJlIDEtUlRUIGhhbmRzaGFrZSwgYW5kIHRoZSBzZWN1cml0eSBwcm9wZXJ0aWVzIGFyZSBpbmhl cml0ZWQgYnkgZnV0dXJlIHJlc3VtZWQgY29ubmVjdGlvbnMuICBUaGUgc3RlcHMgaW4gdGhlIGhh bmRzaGFrZXMgYXJlOg0KDQpEdXJpbmcgdGhlIGluaXRpYWwgMS1SVFQgaGFuZHNoYWtlOg0KLSBu ZWdvdGlhdGUgVEIgYXMgaW4gVExTIDEuMg0KLSBzZXJ2ZXIgY3JlYXRlcyBhIHNtYWxsIGVuY3J5 cHRlZCB0aWNrZXQgY29udGFpbmluZyBvbmx5IHRoZSBzZXNzaW9uIElEIGFuZCBhICJyZXN1bXB0 aW9uIGNvdW50IiBzZXQgdG8gMA0KLSBzZXJ2ZXIgc2VuZHMgdGhlIHRpY2tldCB0byB0aGUgY2xp ZW50DQoNCkR1cmluZyBhIDAtUlRUIHJlc3VtcHRpb24gaGFuZHNoYWtlOg0KLSBjbGllbnQgc2Vu ZHMgVEIgZXh0ZW5zaW9uLCBiZWNhdXNlIHRoaXMgbWlnaHQgZmFsbCBiYWNrIHRvIDEtUlRUDQot IGNsaWVudCBzZW5kcyB0aGUgdGlja2V0IHRvIHRoZSBzZXJ2ZXINCi0gc2VydmVyIGRlY3J5cHRz IHRoZSB0aWNrZXQsIGNoZWNrcyBmb3IgYSBjYWNoZSBoaXQsIGFuZCBkcm9wIHRvIDEtUlRUIGlm IG5vdCBmb3VuZA0KLSBzZXJ2ZXIgY29tcGFyZXMgdGhlIHJlc3VtcHRpb24gY291bnRzIGluIHRo ZSBzZXNzaW9uIHN0YXRlIGFuZCB0aWNrZXQsIGFuZCBkcm9wcyB0byAxLVJUVCBpZiB0aGV5IGRv IG5vdCBtYXRjaA0KLSBzZXJ2ZXIgaW5jcmVtZW50cyB0aGUgcmVzdW1wdGlvbiBjb3VudHMgaW4g dGhlIHRpY2tldCBhbmQgc2Vzc2lvbiBzdGF0ZQ0KLSBzZXJ2ZXIgZW5jcnlwdGVzIHRoZSB1cGRh dGVkIHRpY2tldCBhbmQgc2VuZHMgaXQgdG8gdGhlIGNsaWVudA0KLSBzZXJ2ZXIgZXhlY3V0ZXMg MC1SVFQgSFRUUCByZXF1ZXN0cyBmcm9tIHRoZSBjbGllbnQncyBmaXJzdCBmbGlnaHQgb2YgcGFj a2V0cw0KDQpPdGhlciBzdGF0ZWZ1bCBzY2hlbWVzIGFyZSBwb3NzaWJsZSwgc3VjaCBhcyB1c2lu ZyBzdHJpa2UgcmVnaXN0ZXJzLiAgSG93ZXZlciwgdGhlcmUgaXMgZ3Jvd2luZyBldmlkZW5jZSB0 aGF0IHVzaW5nIG90aGVyIHN0YXRlZnVsIHNlcnZlciBtb2RlcyB0ZW5kcyB0byBmYWlsIGluIHBy YWN0aWNlLiAgVGhlc2Ugc2NoZW1lcyBhcmUgc2ltcGx5IHRvbyB0cmlja3kgdG8gZ2V0IHJpZ2h0 LiAgSG93ZXZlciwgc2Vzc2lvbiBjYWNoZXMgaGF2ZSB3b3JrZWQgZm9yIG1hbnkgeWVhcnMgYW5k IGFyZSB3aWRlbHkgZGVwbG95ZWQuDQoNClN1cnByaXNpbmdseSAodG8gbWUpLCB0aGlzIGV2ZW4g cHJvdmlkZXMgZnVsbCBwZXJmZWN0IGZvcndhcmQgc2VjcmVjeSAoUEZTKS4gIFRoaXMgaXMgYmVj YXVzZSBUTFMgMS4zIHVzZXMgYSAibWFzdGVyIHJlc3VtcHRpb24gc2VjcmV0IiB0byByZXN1bWUg YSBzZXNzaW9uLCBzbyB0aGF0IGV2ZW4gZmlyc3QgZmxpZ2h0IDAtUlRUIHBhY2tldHMgYXJlIGVu Y3J5cHRlZCB3aXRoIG5ldyBrZXlzLiAgVGhlIHNlcnZlciBuZXZlciB3cml0ZXMgb2xkIHNlc3Np b24gc2VjcmV0cyB0byB0aGUgY2FjaGUuICBUaGUgbG9uZyBsaWZldGltZSBvZiB0aGUgdGlja2V0 IGRlY3J5cHRpb24ga2V5IGRvZXMgbm90IGh1cnQgUEZTIGluIHNlcnZlcnMgdXNpbmcgc2Vzc2lv biBjYWNoaW5nIHdpdGggVExTIDEuMywgdW5saWtlIHN0YXRlbGVzcyBzZXJ2ZXJzIGRvaW5nIDAt UlRUIHJlc3VtcHRpb24uDQoNCk9uZSBpc3N1ZSB0byBiZSByZXNvbHZlZCBpcyBleGFjdGx5IHdo YXQgVExTLXVuaXF1ZSBzaG91bGQgYmUgc2lnbmVkIGR1cmluZyByZXN1bWVkIHNlc3Npb25zLiAg TXkgcHJlZmVyZW5jZSBpcyB0byByZW1lbWJlciB0aGUgb3JpZ2luYWwgVExTLXVuaXF1ZSBmcm9t IHRoZSBpbml0aWFsIHNlc3Npb24gYW5kIGNvbnRpbnVlIHRvIHNpZ24gdGhhdC4gIFRoaXMgd291 bGQgYWxsb3cgc2VydmVycyB0byBhbHNvIHJlbWVtYmVyIHdoaWNoIFRCIGhlYWRlcnMgaGF2ZSBh bHJlYWR5IGJlZW4gdmFsaWRhdGVkIGJldHdlZW4gY29ubmVjdGlvbnMsIGdyZWF0bHkgcmVkdWNp bmcgdGhlIENQVSBvdmVyaGVhZCBvZiBUQi4gIEEgbmljZSB3YXkgdG8gZW5hYmxlIHRoaXMgdG8g aGFwcGVuIHdvdWxkIGJlIHRvIHNwZWNpZnkgaW4gVExTIDEuMyB0aGF0IHRoZSBFeHBvcnQgS2V5 IE1hdGVyaWFsIEFQSSBzaG91bGQgcHJvdmlkZSB0aGUgc2FtZSByZXN1bHRzIGluIHJlc3VtZWQg c2Vzc2lvbnMgYXMgaW4gdGhlIG9yaWdpbmFsIDEtUlRUIGNvbm5lY3Rpb24uICBJIHdvdWxkIHBy ZWZlciB0aGlzIGZvciBUTFMgMS4yIGFzIHdlbGwsIHRob3VnaCBJIHN1c3BlY3QgdGhhdCBzaGlw IGhhcyBhbHJlYWR5IHNhaWxlZC4NCg0KVGhlIHNlY3VyaXR5IG9mIHNlc3Npb24tY2FjaGUgYmFz ZWQgMC1SVFQgYXBwZWFycyB0byBiZSBuZWFybHkgZXF1aXZhbGVudCB0byBUTFMgMS4yIHJlc3Vt cHRpb24uICBUaGUgb25seSBuZXcgc2VjdXJpdHkgaXNzdWUgSSBzZWUgaXMgdGhhdCBzb21ldGlt ZXMgdGhlIFRMUyBsYXllciB3aWxsIGF1dG9tYXRpY2FsbHkgcmVwbGF5IDAtUlRUIGFwcGxpY2F0 aW9uIGRhdGEuICBUaGlzIGhhcHBlbnMgd2hlbiB0aGUgc2VydmVyIHJlamVjdHMgYSAwLVJUVCBo YW5kc2hha2UgYW5kIGRyb3BzIHRvIGEgZnVsbCAxLVJUVCBoYW5kc2hha2UuICBJbiB0aGlzIGNh c2UsIHRoZSBjbGllbnQgaXMgcmVxdWlyZWQgdG8gcmVzZW5kIHRoZSAwLVJUVCBhcHBsaWNhdGlv biBkYXRhLiAgQW4gYXR0YWNrZXIgY2FuIG1ha2UgdXNlIG9mIHRoaXMgdG8gY2F1c2UgdGhlIGZp cnN0LWZsaWdodCBkYXRhIHRvIGJlIHJlcGxheWVkIG9uY2UuICBIb3dldmVyLCBmb3IgSFRUUCwg dGhlIGF0dGFja2VyIGFscmVhZHkgaGFzIHRoaXMgY2FwYWJpbGl0eTxodHRwczovL25hMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmYmxvZy52YWx2 ZXJkZS5tZSUyZjIwMTUlMmYxMiUyZjA3JTJmYmFkLWxpZmUtYWR2aWNlJTJmJTIzLlZ2S0V0MkVy S2xHJmRhdGE9MDElN2MwMSU3Y0FuZHJlaS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN2NkMzk2N2Fi MDJkMGM0MmFhNWFlOTA4ZDM1MzFlNDBlZCU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdjMSZzZGF0YT05YTh3Q3RVQm5HWTdYRHBrNzVTSG1ab1hHY29sN3BJZ043WVVDNW9KRVJB JTNkPiwgYW5kIGl0IGFwcGxpZXMgdG8gYWxsIEhUVFAgcmVxdWVzdHMsIG5vdCBqdXN0IGZpcnN0 LWZsaWdodCByZXF1ZXN0cy4gIEJlY2F1c2Ugb2YgdGhpcywgSSBzZWUgbm8gcmVhc29uIHRvIHJl c3RyaWN0IGZpcnN0LWZsaWdodCBhcHBsaWNhdGlvbiBkYXRhIGZyb20gc2VuZGluZyBQT1NUIHJl cXVlc3RzLiAgVGhpcyBtZWFucyB0aGF0IHBvdGVudGlhbGx5LCBzdGF0ZWZ1bCAwLVJUVCBzZXJ2 ZXJzIGNhbiBiZSBzbGlnaHRseSBmYXN0ZXIgdGhhbiBzdGF0ZWxlc3MgMC1SVFQgc2VydmVycy4N Cg0KTWFraW5nIHN0YXRlZnVsIDAtUlRUIHNlcnZlcnMgcmVhbGx5IGZhc3QgbWVhbnMgd2UgbmVl ZCBoaWdoIHJlc3VtcHRpb24gcmF0ZXMuICBJIHRoaW5rIHRoZSAjMSByZWFzb24gdGhhdCBRVUlD IGFjaGlldmVzIHZlcnkgaGlnaCAwLVJUVCByYXRlcyBjb21wYXJlZCB0byBlaXRoZXIgc2Vzc2lv biBjYWNoZXMgb3IgdGlja2V0cyBpcyB0aGF0IGJyb3dzZXJzIHR5cGljYWxseSBkbyBub3Qgd3Jp dGUgdGhlIHNlc3Npb24gY2FjaGUgdG8gZGlzaywgd2hpbGUgUVVJQyBkb2VzIHdyaXRlIHRoZSBz ZXJ2ZXIgY29uZmlnIHRvIGRpc2suICBUaGUgbW90aXZhdGlvbiBmb3Igbm90IHdyaXRpbmcgdGhl IGNhY2hlIHRvIGRpc2sgaXMgdGhhdCB0aGlzIGNyZWF0ZXMgYSBuZXcgYmVhcmVyIHRva2VuLCB3 aGVyZSBtYWx3YXJlIGNhbiBzdGVhbCB0aGUgcmVzdW1wdGlvbiBkYXRhIGZyb20gZGlzayBhbmQg cmVzdW1lIGEgc2Vzc2lvbiBlbHNld2hlcmUuICBIb3dldmVyLCBhcyBzb29uIGFzIG15IGxhcHRv cCBoaWJlcm5hdGVzLCB0aGUgc2Vzc2lvbiBjYWNoZSBpcyB3cml0dGVuIHRvIGRpc2sgYW55d2F5 LCBhbmQgdGhlcmUgaXMgb2Z0ZW4gbm90aGluZyBzdG9wcGluZyBtYWx3YXJlIGZyb20gc3RlYWxp bmcgdGhlIGNhY2hlZCBzZXNzaW9uIGZyb20gbWVtb3J5Lg0KDQpUaGUgcmlnaHQgbW9kZWwsIElN TywgZm9yIHByb3RlY3Rpbmcgc2VjcmV0cyBpcyB0byBrZWVwIHRoZW0gc2VjdXJlZCBhcyBjbG9z ZSB0byBoYXJkd2FyZSBhcyBwb3NzaWJsZS4gIEFsbCBzZWNyZXQga2V5cyBzaG91bGQgYmUgY3J5 cHRvZ3JhcGhpY2FsbHkgYm91bmQgdG8gdGhlIGRldmljZSwgYW5kIHVudXNhYmxlIG9uIGFueSBv dGhlciBkZXZpY2UuICBUaGlzIGluY2x1ZGVzIHRoZSBUTFMgc2Vzc2lvbiBzZWNyZXRzLiAgVXNp bmcgYSBUUE0gaXMgdG9vIHNsb3csIGJ1dCBTa3lsYWtlIEludGVsIHByb2Nlc3NvcnMgaGF2ZSBh biBTR1ggbW9kZSB0aGF0IGlzIGNsZWFybHkgZmFzdCBlbm91Z2guICBBbmRyb2lkIGRldmljZXMg b2ZmZXIgdHJ1c3RlZCBleGVjdXRpb24gZW52aXJvbm1lbnQsIHdoaWNoIGNhbiBiZSBmYXN0IGVu b3VnaCwgZGVwZW5kaW5nIG9uIHRoZSBkZXZpY2UgYW5kIHNvZnR3YXJlIHN0YWNrLiAgQWx0ZXJu YXRpdmVseSwgdGhlIE9TIGNhbiBlbXBsb3kgZGlzayBlbmNyeXB0aW9uIGFuZCBtb2Rlcm4gc2Vj dXJlIGphaWxzIGZvciBhbGwgYXBwbGljYXRpb25zLiAgRWl0aGVyIHdheSwgdGhlIHJlc3VsdCBp cyB0aGF0IHNlY3JldHMgYXJlIGNyeXB0b2dyYXBoaWNhbGx5IGJvdW5kIHRvIHRoZSBkZXZpY2Us IGV2ZW4gd2hlbiB3cml0dGVuIHRvIGRpc2suICBPbiBzdWNoIHN5c3RlbXMsIHRoZSBicm93c2Vy IHNob3VsZCBqdXN0IGdvIGFoZWFkIGFuZCBzYXZlIHRoZSBjYWNoZS4NCg0KSWYgd2UgZG8gYWxs IHRoaXMsIHRoZSBmdXR1cmUgZm9yIHRva2VuIGJpbmRpbmcgc2VlbXMgcHJvbWlzaW5nIHRvIG1l LiAgSWYgd2UgaW5zdGVhZCBnbyBkb3duIHRoZSBzdGF0ZWxlc3MgMC1SVFQgcGF0aCwgc3Ryb25n IGNsaWVudCBhdXRoZW50aWNhdGlvbiBnZXRzIHRocm93biB1bmRlciB0aGUgYnVzLg0KDQpCaWxs DQo= --_000_BLUPR03MB139616608F68A44A25D7A6758C810BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBy ZWFkIHRoaXMgd3JvbmcsIGJ1dCB0aGUgVEItcmVsYXRlZCBwYXJ0IG9mIHRoaXMgcHJvcG9zYWwg ZXNzZW50aWFsbHkgYW1vdW50cyB0byByZW1vdmluZyB0aGUgcmVxdWlyZW1lbnQgdGhhdCB0aGUg Y2xpZW50IHByb3ZlIHBvc3Nlc3Npb24NCiBvZiB0aGUgVEIga2V5IG9uIHJlc3VtcHRpb24uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzIHJlcXVpcmVtZW50 IGV4aXN0cyB0b2RheSBiZWNhdXNlIFRMUyByZXN1bXB0aW9uIHN0YXRlIGlzIGRlZW1lZCBlYXNp ZXIgdG8gc3RlYWwgdGhhbiBhIGhhcmR3YXJlLWJvdW5kIFRCIGtleS4gT25jZSBUTFMgcmVzdW1w dGlvbiBzdGF0ZSBpcyBwcm90ZWN0ZWQgaW4gdGhlDQogc2FtZSB3YXkgYXMgdGhlIFRCIGtleSwg dGhlbiB0aGVyZSB3aWxsIHByb2JhYmx5IGJlIG5vIG5lZWQgZm9yIHRoZSBjbGllbnQgdG8gc2ln biB3aXRoIGl0cyBUQiBrZXkgd2hlbiByZXN1bWluZyBhIFRMUyBzZXNzaW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T25jZSBUTFMgMS4zIHN0YWJpbGl6ZXMg c29tZSBtb3JlLCBJIHRoaW5rIHdl4oCZbGwgbmVlZCB0byB3cml0ZSBhIG5ldyBkb2N1bWVudCBl eHBsYWluaW5nIGhvdyBUQiBjYW4gYmUgdXNlZCB3aXRoIFRMUyAxLjMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVW5iZWFyYWJsZSBbbWFpbHRv OnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmlsbCBD b3g8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXJjaCAyMywgMjAxNiA2OjEwIEFNPGJy Pg0KPGI+VG86PC9iPiBUb2tiaW5kIFdHICZsdDt1bmJlYXJhYmxlQGlldGYub3JnJmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBbVW5iZWFyYWJsZV0gVGhvdWdodHMgb24gVExTIDAtUlRUIDEuMyBj b21wYXRpYmlsaXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlN1bW1hcnk6IEZvciBIVFRQIGNvbm5lY3Rpb25zLCB1c2Ugc2Vzc2lvbiBjYWNoZXMgb24gYm90 aCBjbGllbnQgYW5kIHNlcnZlciwgYW5kIHN1cHBvcnQgMC1SVFQgc3RhdGVmdWwgcmVzdW1wdGlv bi4mbmJzcDsgRGlzYWxsb3cgdG9rZW4gYmluZGluZyB0byBiZSB1c2VkIHRvIGF1dGhlbnRpY2F0 ZSBhIHN0YXRlbGVzcyAwLVJUVCBjb25uZWN0aW9uLiZuYnNwOyBTZWN1cmUgYWxsIHNlY3JldCBr ZXlzIGNsb3NlIHRvIHRoZSBkZXZpY2UNCiAoaW5jbHVkaW5nIFRMUyBzZXNzaW9uIHNlY3JldHMp LCBhbmQgc2F2ZSB0aGUgYnJvd3NlcidzIHNlc3Npb24gY2FjaGUgdG8gZGlzay48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyB3ZSBrbm93LCBzdGF0ZWxl c3MgMC1SVFQgYnJlYWtzIHN0cm9uZyBjbGllbnQgYXV0aGVudGljYXRpb24uJm5ic3A7IEFsbCBz dGF0ZWxlc3Mgc2VydmVycyBydW5uaW5nIDAtUlRUIHdpbGwgZmFpbCB0byBmaW5pc2ggdmFsaWQg dG9rZW4gYmluZGluZyBwcm9vZnMtb2YtcG9zc2Vzc2lvbiBpbiB0aW1lIHRvIHByb3RlY3QgZmly c3QtZmxpZ2h0IGRhdGEsIGxlYWRpbmcgdG8gdmFyaW91cyBuZXcgYW5kIGV4Y2l0aW5nDQogYXR0 YWNrcy4mbmJzcDsgSU1PLCB0aGlzIGxpbWl0YXRpb24gbWFrZXMgdXNpbmcgZWl0aGVyIHRva2Vu IGJpbmRpbmcgb3IgY2xpZW50IGNlcnRpZmljYXRlcyB3aXRoIHN0YXRlbGVzcyAwLVJUVCBlbmFi bGVkIHNlcnZlcnMgYSBiYWQgaWRlYS4mbmJzcDsgRXZlbiBvZmZlcmluZyBzdXBwb3J0IGZvciBz dWNoIGEgbW9kZSByZWR1Y2VzIHNlY3VyaXR5LCBhbmQgc2hvdWxkIGJlIGF2b2lkZWQuJm5ic3A7 IEkgaGF2ZSBkaWZmaWN1bHR5IGZpbmRpbmcgc2lnbmlmaWNhbnQgcmVhbA0KIGF0dGFja3MgdGhh dCBhcmUgZGVmZWF0ZWQgYnkgdG9rZW4gYmluZGluZyBvciBjbGllbnQgY2VydGlmaWNhdGVzIHdo ZW4gdXNlZCBvdmVyIGEgc3RhdGVsZXNzIDAtUlRUIGNvbm5lY3Rpb24uJm5ic3A7IElNTywgd2l0 aG91dCBhIHByb29mIG9mIHBvc3Nlc3Npb24sIGJvdGggdG9rZW4gYmluZGluZyBhbmQgY2xpZW50 IGNlcnRpZmljYXRlcyBhcmUgbmVhcmx5IHBvaW50bGVzcy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIHdlIGNhbiBzYWZlbHkgc3VwcG9ydCBv bmUgVExTIDEuMyAwLVJUVCBtb2RlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JTU8sIHRoZSByaWdodCB3YXkgdG8gZG8gMC1SVFQgdG9rZW4g YmluZGluZyBvdmVyIFRMUyAxLjMgaXMgdG8gdXNlIHNlc3Npb24gY2FjaGVzIG9uIGJvdGggdGhl IGNsaWVudCBhbmQgc2VydmVyLCBhbmQgdG8gb25seSBkbyAwLVJUVCBkdXJpbmcgYSByZXN1bXB0 aW9uLiZuYnNwOyBUaGF0IHdheSwgdGhlIHByb29mLW9mLXBvc3Nlc3Npb24gaXMgZG9uZSBvbiB0 aGUgaW5pdGlhbCBzZWN1cmUgMS1SVFQgaGFuZHNoYWtlLA0KIGFuZCB0aGUgc2VjdXJpdHkgcHJv cGVydGllcyBhcmUgaW5oZXJpdGVkIGJ5IGZ1dHVyZSByZXN1bWVkIGNvbm5lY3Rpb25zLiZuYnNw OyBUaGUgc3RlcHMgaW4gdGhlIGhhbmRzaGFrZXMgYXJlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RHVyaW5nIHRoZSBpbml0aWFs IDEtUlRUIGhhbmRzaGFrZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0gbmVnb3RpYXRlIFRCIGFzIGluIFRMUyAxLjI8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gc2VydmVyIGNyZWF0ZXMgYSBz bWFsbCBlbmNyeXB0ZWQgdGlja2V0IGNvbnRhaW5pbmcgb25seSB0aGUgc2Vzc2lvbiBJRCBhbmQg YSAmcXVvdDtyZXN1bXB0aW9uIGNvdW50JnF1b3Q7IHNldCB0byAwPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHNlcnZlciBzZW5kcyB0aGUgdGlj a2V0IHRvIHRoZSBjbGllbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RHVyaW5nIGEgMC1SVFQgcmVzdW1wdGlvbiBoYW5kc2hha2U6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIGNsaWVudCBz ZW5kcyBUQiBleHRlbnNpb24sIGJlY2F1c2UgdGhpcyBtaWdodCBmYWxsIGJhY2sgdG8gMS1SVFQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gY2xp ZW50IHNlbmRzIHRoZSB0aWNrZXQgdG8gdGhlIHNlcnZlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBzZXJ2ZXIgZGVjcnlwdHMgdGhlIHRpY2tl dCwgY2hlY2tzIGZvciBhIGNhY2hlIGhpdCwgYW5kIGRyb3AgdG8gMS1SVFQgaWYgbm90IGZvdW5k PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHNl cnZlciBjb21wYXJlcyB0aGUgcmVzdW1wdGlvbiBjb3VudHMgaW4gdGhlIHNlc3Npb24gc3RhdGUg YW5kIHRpY2tldCwgYW5kIGRyb3BzIHRvIDEtUlRUIGlmIHRoZXkgZG8gbm90IG1hdGNoPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHNlcnZlciBp bmNyZW1lbnRzIHRoZSByZXN1bXB0aW9uIGNvdW50cyBpbiB0aGUgdGlja2V0IGFuZCBzZXNzaW9u IHN0YXRlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tIHNlcnZlciBlbmNyeXB0ZXMgdGhlIHVwZGF0ZWQgdGlja2V0IGFuZCBzZW5kcyBpdCB0byB0 aGUgY2xpZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0gc2VydmVyIGV4ZWN1dGVzIDAtUlRUIEhUVFAgcmVxdWVzdHMgZnJvbSB0 aGUgY2xpZW50J3MgZmlyc3QgZmxpZ2h0IG9mIHBhY2tldHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3RoZXIgc3RhdGVmdWwgc2NoZW1lcyBh cmUgcG9zc2libGUsIHN1Y2ggYXMgdXNpbmcgc3RyaWtlIHJlZ2lzdGVycy4mbmJzcDsgSG93ZXZl ciwgdGhlcmUgaXMgZ3Jvd2luZyBldmlkZW5jZSB0aGF0IHVzaW5nIG90aGVyIHN0YXRlZnVsIHNl cnZlciBtb2RlcyB0ZW5kcyB0byBmYWlsIGluIHByYWN0aWNlLiZuYnNwOyBUaGVzZSBzY2hlbWVz IGFyZSBzaW1wbHkgdG9vIHRyaWNreSB0byBnZXQgcmlnaHQuJm5ic3A7IEhvd2V2ZXIsIHNlc3Np b24NCiBjYWNoZXMgaGF2ZSB3b3JrZWQgZm9yIG1hbnkgeWVhcnMgYW5kIGFyZSB3aWRlbHkgZGVw bG95ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlN1cnByaXNpbmdseSAodG8gbWUpLCB0aGlzIGV2ZW4gcHJvdmlkZXMgZnVsbCBwZXJmZWN0 IGZvcndhcmQgc2VjcmVjeSAoUEZTKS4mbmJzcDsgVGhpcyBpcyBiZWNhdXNlIFRMUyAxLjMgdXNl cyBhICZxdW90O21hc3RlciByZXN1bXB0aW9uIHNlY3JldCZxdW90OyB0byByZXN1bWUgYSBzZXNz aW9uLCBzbyB0aGF0IGV2ZW4gZmlyc3QgZmxpZ2h0IDAtUlRUIHBhY2tldHMgYXJlIGVuY3J5cHRl ZCB3aXRoIG5ldyBrZXlzLiZuYnNwOyBUaGUgc2VydmVyDQogbmV2ZXIgd3JpdGVzIG9sZCBzZXNz aW9uIHNlY3JldHMgdG8gdGhlIGNhY2hlLiZuYnNwOyBUaGUgbG9uZyBsaWZldGltZSBvZiB0aGUg dGlja2V0IGRlY3J5cHRpb24ga2V5IGRvZXMgbm90IGh1cnQgUEZTIGluIHNlcnZlcnMgdXNpbmcg c2Vzc2lvbiBjYWNoaW5nIHdpdGggVExTIDEuMywgdW5saWtlIHN0YXRlbGVzcyBzZXJ2ZXJzIGRv aW5nIDAtUlRUIHJlc3VtcHRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBpc3N1ZSB0byBiZSByZXNvbHZlZCBpcyBleGFjdGx5IHdo YXQgVExTLXVuaXF1ZSBzaG91bGQgYmUgc2lnbmVkIGR1cmluZyByZXN1bWVkIHNlc3Npb25zLiZu YnNwOyBNeSBwcmVmZXJlbmNlIGlzIHRvIHJlbWVtYmVyIHRoZSBvcmlnaW5hbCBUTFMtdW5pcXVl IGZyb20gdGhlIGluaXRpYWwgc2Vzc2lvbiBhbmQgY29udGludWUgdG8gc2lnbiB0aGF0LiZuYnNw OyBUaGlzIHdvdWxkIGFsbG93IHNlcnZlcnMgdG8gYWxzbyByZW1lbWJlcg0KIHdoaWNoIFRCIGhl YWRlcnMgaGF2ZSBhbHJlYWR5IGJlZW4gdmFsaWRhdGVkIGJldHdlZW4gY29ubmVjdGlvbnMsIGdy ZWF0bHkgcmVkdWNpbmcgdGhlIENQVSBvdmVyaGVhZCBvZiBUQi4mbmJzcDsgQSBuaWNlIHdheSB0 byBlbmFibGUgdGhpcyB0byBoYXBwZW4gd291bGQgYmUgdG8gc3BlY2lmeSBpbiBUTFMgMS4zIHRo YXQgdGhlIEV4cG9ydCBLZXkgTWF0ZXJpYWwgQVBJIHNob3VsZCBwcm92aWRlIHRoZSBzYW1lIHJl c3VsdHMgaW4gcmVzdW1lZCBzZXNzaW9ucw0KIGFzIGluIHRoZSBvcmlnaW5hbCAxLVJUVCBjb25u ZWN0aW9uLiZuYnNwOyBJIHdvdWxkIHByZWZlciB0aGlzIGZvciBUTFMgMS4yIGFzIHdlbGwsIHRo b3VnaCBJIHN1c3BlY3QgdGhhdCBzaGlwIGhhcyBhbHJlYWR5IHNhaWxlZC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNlY3VyaXR5IG9m IHNlc3Npb24tY2FjaGUgYmFzZWQgMC1SVFQgYXBwZWFycyB0byBiZSBuZWFybHkgZXF1aXZhbGVu dCB0byBUTFMgMS4yIHJlc3VtcHRpb24uJm5ic3A7IFRoZSBvbmx5IG5ldyBzZWN1cml0eSBpc3N1 ZSBJIHNlZSBpcyB0aGF0IHNvbWV0aW1lcyB0aGUgVExTIGxheWVyIHdpbGwgYXV0b21hdGljYWxs eSByZXBsYXkgMC1SVFQgYXBwbGljYXRpb24gZGF0YS4mbmJzcDsgVGhpcyBoYXBwZW5zIHdoZW4g dGhlDQogc2VydmVyIHJlamVjdHMgYSAwLVJUVCBoYW5kc2hha2UgYW5kIGRyb3BzIHRvIGEgZnVs bCAxLVJUVCBoYW5kc2hha2UuJm5ic3A7IEluIHRoaXMgY2FzZSwgdGhlIGNsaWVudCBpcyByZXF1 aXJlZCB0byByZXNlbmQgdGhlIDAtUlRUIGFwcGxpY2F0aW9uIGRhdGEuJm5ic3A7IEFuIGF0dGFj a2VyIGNhbiBtYWtlIHVzZSBvZiB0aGlzIHRvIGNhdXNlIHRoZSBmaXJzdC1mbGlnaHQgZGF0YSB0 byBiZSByZXBsYXllZCBvbmNlLiZuYnNwOyBIb3dldmVyLCBmb3IgSFRUUCwgdGhlDQogYXR0YWNr ZXIgPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cCUzYSUyZiUyZmJsb2cudmFsdmVyZGUubWUlMmYyMDE1JTJmMTIlMmYwNyUyZmJh ZC1saWZlLWFkdmljZSUyZiUyMy5WdktFdDJFcktsRyZhbXA7ZGF0YT0wMSU3YzAxJTdjQW5kcmVp LlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3Y2QzOTY3YWIwMmQwYzQyYWE1YWU5MDhkMzUzMWU0MGVk JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT05YTh3Q3RV Qm5HWTdYRHBrNzVTSG1ab1hHY29sN3BJZ043WVVDNW9KRVJBJTNkIj4NCmFscmVhZHkgaGFzIHRo aXMgY2FwYWJpbGl0eTwvYT4sIGFuZCBpdCBhcHBsaWVzIHRvIGFsbCBIVFRQIHJlcXVlc3RzLCBu b3QganVzdCBmaXJzdC1mbGlnaHQgcmVxdWVzdHMuJm5ic3A7IEJlY2F1c2Ugb2YgdGhpcywgSSBz ZWUgbm8gcmVhc29uIHRvIHJlc3RyaWN0IGZpcnN0LWZsaWdodCBhcHBsaWNhdGlvbiBkYXRhIGZy b20gc2VuZGluZyBQT1NUIHJlcXVlc3RzLiZuYnNwOyBUaGlzIG1lYW5zIHRoYXQgcG90ZW50aWFs bHksIHN0YXRlZnVsIDAtUlRUIHNlcnZlcnMNCiBjYW4gYmUgc2xpZ2h0bHkgZmFzdGVyIHRoYW4g c3RhdGVsZXNzIDAtUlRUIHNlcnZlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1ha2luZyBzdGF0ZWZ1bCAwLVJUVCBzZXJ2ZXJzIHJlYWxs eSBmYXN0IG1lYW5zIHdlIG5lZWQgaGlnaCByZXN1bXB0aW9uIHJhdGVzLiZuYnNwOyBJIHRoaW5r IHRoZSAjMSByZWFzb24gdGhhdCBRVUlDIGFjaGlldmVzIHZlcnkgaGlnaCAwLVJUVCByYXRlcyBj b21wYXJlZCB0byBlaXRoZXIgc2Vzc2lvbiBjYWNoZXMgb3IgdGlja2V0cyBpcyB0aGF0IGJyb3dz ZXJzIHR5cGljYWxseSBkbyBub3Qgd3JpdGUgdGhlIHNlc3Npb24NCiBjYWNoZSB0byBkaXNrLCB3 aGlsZSBRVUlDIGRvZXMgd3JpdGUgdGhlIHNlcnZlciBjb25maWcgdG8gZGlzay4mbmJzcDsgVGhl IG1vdGl2YXRpb24gZm9yIG5vdCB3cml0aW5nIHRoZSBjYWNoZSB0byBkaXNrIGlzIHRoYXQgdGhp cyBjcmVhdGVzIGEgbmV3IGJlYXJlciB0b2tlbiwgd2hlcmUgbWFsd2FyZSBjYW4gc3RlYWwgdGhl IHJlc3VtcHRpb24gZGF0YSBmcm9tIGRpc2sgYW5kIHJlc3VtZSBhIHNlc3Npb24gZWxzZXdoZXJl LiZuYnNwOyBIb3dldmVyLCBhcyBzb29uDQogYXMgbXkgbGFwdG9wIGhpYmVybmF0ZXMsIHRoZSBz ZXNzaW9uIGNhY2hlIGlzIHdyaXR0ZW4gdG8gZGlzayBhbnl3YXksIGFuZCB0aGVyZSBpcyBvZnRl biBub3RoaW5nIHN0b3BwaW5nIG1hbHdhcmUgZnJvbSBzdGVhbGluZyB0aGUgY2FjaGVkIHNlc3Np b24gZnJvbSBtZW1vcnkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZSByaWdodCBtb2RlbCwgSU1PLCBmb3IgcHJvdGVjdGluZyBzZWNyZXRz IGlzIHRvIGtlZXAgdGhlbSBzZWN1cmVkIGFzIGNsb3NlIHRvIGhhcmR3YXJlIGFzIHBvc3NpYmxl LiZuYnNwOyBBbGwgc2VjcmV0IGtleXMgc2hvdWxkIGJlIGNyeXB0b2dyYXBoaWNhbGx5IGJvdW5k IHRvIHRoZSBkZXZpY2UsIGFuZCB1bnVzYWJsZSBvbiBhbnkgb3RoZXIgZGV2aWNlLiZuYnNwOyBU aGlzIGluY2x1ZGVzIHRoZSBUTFMgc2Vzc2lvbiBzZWNyZXRzLiZuYnNwOw0KIFVzaW5nIGEgVFBN IGlzIHRvbyBzbG93LCBidXQgU2t5bGFrZSBJbnRlbCBwcm9jZXNzb3JzIGhhdmUgYW4gU0dYIG1v ZGUgdGhhdCBpcyBjbGVhcmx5IGZhc3QgZW5vdWdoLiZuYnNwOyBBbmRyb2lkIGRldmljZXMgb2Zm ZXIgdHJ1c3RlZCBleGVjdXRpb24gZW52aXJvbm1lbnQsIHdoaWNoIGNhbiBiZSBmYXN0IGVub3Vn aCwgZGVwZW5kaW5nIG9uIHRoZSBkZXZpY2UgYW5kIHNvZnR3YXJlIHN0YWNrLiZuYnNwOyBBbHRl cm5hdGl2ZWx5LCB0aGUgT1MgY2FuIGVtcGxveQ0KIGRpc2sgZW5jcnlwdGlvbiBhbmQgbW9kZXJu IHNlY3VyZSBqYWlscyBmb3IgYWxsIGFwcGxpY2F0aW9ucy4mbmJzcDsgRWl0aGVyIHdheSwgdGhl IHJlc3VsdCBpcyB0aGF0IHNlY3JldHMgYXJlIGNyeXB0b2dyYXBoaWNhbGx5IGJvdW5kIHRvIHRo ZSBkZXZpY2UsIGV2ZW4gd2hlbiB3cml0dGVuIHRvIGRpc2suJm5ic3A7IE9uIHN1Y2ggc3lzdGVt cywgdGhlIGJyb3dzZXIgc2hvdWxkIGp1c3QgZ28gYWhlYWQgYW5kIHNhdmUgdGhlIGNhY2hlLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3 ZSBkbyBhbGwgdGhpcywgdGhlIGZ1dHVyZSBmb3IgdG9rZW4gYmluZGluZyBzZWVtcyBwcm9taXNp bmcgdG8gbWUuJm5ic3A7IElmIHdlIGluc3RlYWQgZ28gZG93biB0aGUgc3RhdGVsZXNzIDAtUlRU IHBhdGgsIHN0cm9uZyBjbGllbnQgYXV0aGVudGljYXRpb24gZ2V0cyB0aHJvd24gdW5kZXIgdGhl IGJ1cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QmlsbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BLUPR03MB139616608F68A44A25D7A6758C810BLUPR03MB1396namp_-- From nobody Wed Mar 23 10:41:55 2016 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 DDA8312D612 for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 10:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 jylgf2AKSv0Q for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 10:41:50 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0730.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:730]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2E912D160 for <unbearable@ietf.org>; Wed, 23 Mar 2016 10:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KSbv/Md8PGzL9wBbpQ/kB/zF/hwRO7u2EYakCYqFRvE=; b=oLdSkn1VelaNifzYp9DR+DFt9oKqwzublJVvoY3UlsmMO15s6L9WMsPa3mt0hjKfA/DZ6PV+jAicg0cG1PZhy7FIATSGYeXKHouDmaPGMq4CxnL/W1rQjFf9kU0ykQZUeCA3Vvsb3PmkGhOZokjndtSy99oWWAddtUy+pBP8Qyo= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 23 Mar 2016 17:41:33 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0434.021; Wed, 23 Mar 2016 17:41:33 +0000 From: Andrei Popov <Andrei.Popov@microsoft.com> To: Bill Cox <waywardgeek@google.com>, Amos Jeffries <squid3@treenet.co.nz> Thread-Topic: [Unbearable] We need a MitM extension Thread-Index: AQHRhQjbyqLX1j9mpk2vEEn9PLwpbZ9nDCqAgAAgVoCAABk0cA== Date: Wed, 23 Mar 2016 17:41:33 +0000 Message-ID: <BLUPR03MB13964D90AE484B2639F816878C810@BLUPR03MB1396.namprd03.prod.outlook.com> References: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> <56F29F69.1080105@treenet.co.nz> <CAH9QtQHs61xW9P_4TjQq-Jz=QPbVH9aDsYUUZc3fCNScQvcZPw@mail.gmail.com> In-Reply-To: <CAH9QtQHs61xW9P_4TjQq-Jz=QPbVH9aDsYUUZc3fCNScQvcZPw@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:1::1d2] x-ms-office365-filtering-correlation-id: e7934564-010e-42d4-9e4d-08d35342602c x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 5:7+0YkYZ90T5IwUzMf23vPHl4qRqaSrurlR+5iswbpErC7lufJLQ+KwWDN66+NFAap8MfWgtU2L3J/xetlcJVJVvHjQYlQffACN8I29fgFIJNcq1jbpEX0BqKnKPEeP0pfcMPKOEmO+y27WCXbIIe5w==; 24:kNhiDofTmN0BmZc2D6ZxG6d9SZVs+m23tDl0Sm101Xg31Oh3FutJdNVPCzGitB67Qd/Adj5rgLbRagXT6iN0antyhPeLGg1IyHV0++n5Txk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1393; x-microsoft-antispam-prvs: <BLUPR03MB13933653789593EB4AB103EA8C810@BLUPR03MB1393.namprd03.prod.outlook.com> x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; x-forefront-prvs: 08902E536D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(4326007)(2906002)(586003)(102836003)(790700001)(6116002)(5003600100002)(86362001)(5001770100001)(5002640100001)(189998001)(3660700001)(5005710100001)(10400500002)(81166005)(10290500002)(3280700002)(74316001)(16236675004)(5004730100002)(15975445007)(2950100001)(2900100001)(1220700001)(1096002)(92566002)(10090500001)(77096005)(99286002)(19617315012)(87936001)(50986999)(54356999)(76176999)(19609705001)(19580395003)(11100500001)(19580405001)(122556002)(5008740100001)(561944003)(19625215002)(33656002)(19300405004)(106116001)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB13964D90AE484B2639F816878C810BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2016 17:41:33.4484 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/NGXBpUpTC05hn3yjAjHfzEi8ETA> Cc: Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Mar 2016 17:41:54 -0000 --_000_BLUPR03MB13964D90AE484B2639F816878C810BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXh0ZW5kaW5nIGEgTUlUTS1kZWZlYXRpbmcgZmVhdHVyZSB0byBzdXBwb3J0IOKAnGxlZ2l0aW1h dGXigJ0gTUlUTSBtYWtlcyBtZSBzYWQuIEl0IHJlbWluZHMgbWUgb2YgdGhlIOKAnGRvdWJsZSBj ZXJ0aWZpY2F0ZeKAnSBUTFMgYXV0aGVudGljYXRpb24gc2NoZW1lcyB1c2VkIGJ5IHNvbWUgbmF0 aW9uYWwgVExTIHN0YW5kYXJkcy4gSW4gdGhlIHBhc3QsIGJvdGggVExTIFdHIGFuZCBIVFRQYmlz IFdHIGhhdmUgcmVwZWF0ZWRseSByZWplY3RlZCBwcm9wb3NhbHMgdGhhdCBlbmFibGUg4oCcbGVn aXRpbWF0ZeKAnSBNSVRNLg0KDQoNCsOYICBPbiB0aGUgb3RoZXIgaGFuZCwgd2UgY2Fubm90IGVu Zm9yY2UgVEIgZ2xvYmFsbHkgdW50aWwgd2UgaGF2ZSBhIHNvbHV0aW9uIGZvciB1c2VycyB3aG8g dHJhdmVsIHRvIHdvcmsgYW5kIGJhY2sgc28gdGhhdCB0aGV5IG9mdGVuIGNvbm5lY3QgZGlyZWN0 LCBhbmQgb2Z0ZW4gdGhyb3VnaCBhIGNvcnBvcmF0ZSBwcm94eS4NCg0KSSB0aGluayB0aGVyZSBh cmUgYXQgbGVhc3QgdHdvIGRpZmZlcmVudCBjYXNlcyBoZXJlOiBzZXJ2ZXJzIHRoYXQgYXJlIGFz c29jaWF0ZWQgd2l0aCB0aGUgTUlUTSBhbmQgc2VydmVycyB0aGF0IGFyZW7igJl0LiBUaGUgZm9y bWVyIGNhbiBwcm9iYWJseSB1c2UgdGhlIHNjaGVtZSB0aGF0IEFtb3MgZGVzY3JpYmVkLCBhdm9p ZGluZyB0aGUgbmVlZCBmb3IgdGhlIGV4dGVuc2lvbi4gVGhlIGxhdHRlciBjb3VsZCBpc3N1ZSBs ZXNzIHByaXZpbGVnZWQvc2hvcnQtdGltZSBiZWFyZXIgdG9rZW5zIHdoZW4gVEIgaXMgbm90IHVz ZWQgYW5kIG1vcmUgcHJpdmlsZWdlZC9sb25nZXItdGVybSBib3VuZCB0b2tlbnMgd2hlbiBUQiBp cyBuZWdvdGlhdGVkLiBCaWxsLCBkbyB5b3UgdGhpbmsgdGhpcyB3b3VsZCB3b3JrIGZvciB5b3U/ DQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206IFVuYmVhcmFibGUgW21haWx0bzp1bmJlYXJh YmxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCaWxsIENveA0KU2VudDogV2VkbmVz ZGF5LCBNYXJjaCAyMywgMjAxNiA4OjQ3IEFNDQpUbzogQW1vcyBKZWZmcmllcyA8c3F1aWQzQHRy ZWVuZXQuY28ubno+DQpDYzogVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbVW5iZWFyYWJsZV0gV2UgbmVlZCBhIE1pdE0gZXh0ZW5zaW9uDQoNCldlIGhhdmUg YSBjaGlja2VuLWFuZC10aGUtZWdnIHByb2JsZW0uICBMZWdpdCBNaXRNIGJveGVzIHdpbGwgb25s eSBzdXBwb3J0IFRCIG9uY2UgVEIgaXMgYm90aCB3aWRlbHkgZGVwbG95ZWQgYW5kIGVuZm9yY2Vk LiAgT24gdGhlIG90aGVyIGhhbmQsIHdlIGNhbm5vdCBlbmZvcmNlIFRCIGdsb2JhbGx5IHVudGls IHdlIGhhdmUgYSBzb2x1dGlvbiBmb3IgdXNlcnMgd2hvIHRyYXZlbCB0byB3b3JrIGFuZCBiYWNr IHNvIHRoYXQgdGhleSBvZnRlbiBjb25uZWN0IGRpcmVjdCwgYW5kIG9mdGVuIHRocm91Z2ggYSBj b3Jwb3JhdGUgcHJveHkuICBUaGlzIE1pdE0gZXh0ZW5zaW9uIGlzIG5lZWRlZCB0byBnZXQgcGFz dCB0aGlzIGRlYWRsb2NrLg0KDQpJIHRoaW5rIHdlIHNob3VsZCAiZGV0ZWN0IiBhIE1pdE0gdGhp cyB3YXk6DQoNCklmIHRoZSBicm93c2VyIGhhcyBhIHZhbGlkIFRCIGtleSBwYWlyIGZvciB0aGUg ZVRMRCsxIGRvbWFpbiwgeWV0IHRoZSBzZXJ2ZXIgZmFpbGVkIHRvIG5lZ290aWF0ZSB0b2tlbiBi aW5kaW5nIHVzaW5nIHRoZSBUTFMgZXh0ZW5zaW9uLCB0aGVuIGl0IGlzIGxpa2VseSB0aGF0IHRo ZXJlIGlzIGEgTWl0TSB0aGF0IGRvZXMgbm90IHNwZWFrIFRCLiAgSW4gdGhpcyBjYXNlLCBlbmFi bGUgdGhlIE1pdE0gZXh0ZW5zaW9uIGFuZCBzZW5kIFRCIGhlYWRlcnMgYW55d2F5LiAgVGhlIHNl cnZlciB3aWxsIHNlZSBUQiBoZWFkZXJzIGZyb20gYSBjbGllbnQgdGhhdCBkaWQgbm90IG5lZ290 aWF0ZSBUQiwgYW5kIHRoZSBzaWduYXR1cmUgd2lsbCBtaXNtYXRjaC4gIEhvd2V2ZXIsIHRoZSBz ZXJ2ZXIgY2FuIHZlcmlmeSB0aGUgVEIgc2lnbmF0dXJlIG92ZXIgdGhlIHZhbHVlIGluIHRoZSBl eHRlbnNpb24uICBJZiByZXF1ZXN0cyBjb250YWluIGFuIGF1dGggdG9rZW4gc3BlY2lmaWNhbGx5 IGF1dGhvcml6aW5nIHVzZSBiZWhpbmQgdGhpcyBNaXRNLCB0aGVuIHRoZSBzZXJ2ZXIgc2hvdWxk IGFsbG93IHJlcXVlc3RzIHRvIGJlIHByb2Nlc3NlZC4NCg0KVGhlIGZvbGxvd2luZyBkZXRhaWwg aXMgaW1wb3J0YW50OiBXaGVuIGEgc2VydmVyIHNlZXMgdGhlIFRCIGV4dGVuc2lvbiBhbmQgYSBt aXNtYXRjaCBvZiB0aGUgVExTLXVuaXF1ZSB2cyB0aGUgdmFsdWUgaW4gdGhlIGV4dGVuc2lvbiwg YnV0IHRoZSBhdXRoIHRva2VuIGRvZXMgbm90IGF1dGhvcml6ZSB0aGlzIE1pdE0sIGl0IG5lZWRz IHRvIGF1dGhlbnRpY2F0ZSB0aGUgdXNlciBhbmQgaXNzdWUgYW4gZW5oYW5jZWQgYXV0aCB0b2tl biB0aGF0IGFkZGl0aW9uYWxseSBhdXRoZW50aWNhdGVzIHRoZSB1c2VyIGJlaGluZCB0aGlzIE1p dE0uICBPdGhlcndpc2UsIGF0dGFja2VycyBjb3VsZCBzaW1wbHkgTWl0TSB0aGVtc2VsdmVzIGFu ZCBhdXRoZW50aWNhdGUgd2l0aCBzdG9sZW4gYXV0aCB0b2tlbnMuDQoNCkJpbGwNCg0KT24gV2Vk LCBNYXIgMjMsIDIwMTYgYXQgNjo1MSBBTSwgQW1vcyBKZWZmcmllcyA8c3F1aWQzQHRyZWVuZXQu Y28ubno8bWFpbHRvOnNxdWlkM0B0cmVlbmV0LmNvLm56Pj4gd3JvdGU6DQpPbiAyNC8wMy8yMDE2 IDI6MTkgYS5tLiwgQmlsbCBDb3ggd3JvdGU6DQo+IEkgdGhpbmsgb2YgdGhpcyBhcyBhIHRoaW5n IHdlIHNob3VsZCBjb25zaWRlciB3aGVuIHdlIHVwZ3JhZGUgdG9rZW4gYmluZGluZw0KPiB0byBz dXBwb3J0IFRMUyAxLjMuICBTaW5jZSBUTFMgMS4zIHNlZW1zIHRvIGJlIGdldHRpbmcgY2xvc2Ug dG8gZmluYWxpemVkLA0KPiBpcyB0aGlzIGEgcmVhc29uYWJsZSB0aW1lIHRvIHN0YXJ0IGRpc2N1 c3NpbmcgYSBNaXRNIGV4dGVuc2lvbj8NCj4NCj4gSSd2ZSB3cml0dGVuIHVwIGFuIGludGVybmFs IHByb3Bvc2FsIGZvciB0aGlzLCBidXQgaW4gc2hvcnQsIGZvciB0b2tlbg0KPiBiaW5kaW5nIHRv IGJlIGVuZm9yY2VkIGdsb2JhbGx5LCB3ZSBoYXZlIHRvIGRlYWwgd2l0aCB0aGUgcHJvYmxlbSBv Zg0KPiBjb3Jwb3JhdGUgcHJveGllcyBhbmQgYW50aS12aXJ1cyBNaXRNcy4gIFdlIGNhbiBkbyB0 aGlzIHdpdGggYSB0b2tlbg0KPiBiaW5kaW5nIGV4dGVuc2lvbiB0aGF0IHByb3ZpZGVzIHRoZSBt YXRlcmlhbCBzaWduZWQgYnkgdGhlIGNsaWVudC4gIEl0DQo+IHdvdWxkIGJlIHVzZWQgd2hlbmV2 ZXIgdGhlIGNsaWVudCBkZXRlY3RzIHRoYXQgaXQgaXMgYmVpbmcgTWl0TS1lZCB3aXRoIGENCj4g bG9jYWxseSBpbnN0YWxsZWQgY2VydC4gIEkndmUgZXZhbHVhdGVkIGV2ZXJ5IGF0dGFjayBJIGNh biB0aGluayBvZiwgYW5kIGluDQo+IGVhY2ggY2FzZSB0aGlzIGlzIGF0IGxlYXN0IGFzIHNlY3Vy ZSBhcyB0aGUgYWx0ZXJuYXRpdmU6IGlzc3VpbmcgdW5ib3VuZA0KPiBhdXRoIHRva2Vucy4NCg0K SGF2aW5nIGEgbG9jYWxseSBpbnN0YWxsZWQgY2VydCBpcyBubyBndWFyYXRlZSBvZiBNSVRNIGJl aW5nIHBlcmZvcm1lZC4NCk5vciBhIHJlbGlhYmxlIGluZGljYXRvciB0aGF0IGFuIE1JVE0gaXNu J3QgdXNpbmcgYSByb2d1ZSBDQSBjZXJ0Lg0KDQpBIG1vcmUgcmVsaWFibGUgaW5kaWNhdG9yIGlz IHRoYXQgdGhlc2UgYWN0aXZlIE1JVE0gdXNlIGRpZmZlcmVudCBUTFMNCmtleWluZyBtYXRlcmlh bCBvbiB0aGUgc2VydmVyIGNvbm5lY3Rpb24gYXMgY29tcGFyZWQgdG8gdGhlIGNsaWVudA0KY29u bmVjdGlvbi4gU28gdGhlIHNpZ25lZCB0b2tlbnMgc2hvdWxkIGJlIGRldGVjdGlibGUuDQoNClBh c3NpdmUgTUlUTSAoaWYgcG9zc2libGUpIGFyZSBub3QgdG91Y2hpbmcgdGhlIFRMUyBjb250ZW50 LCBzbyB0aGUNCmNsaWVudHMgdG9rZW5zIHdpbGwgZ2V0IHRocm91Z2ggYW55d2F5Lg0KDQo+DQo+ IFRoZXJlIGFyZSBmdXJ0aGVyIHN0ZXBzIHRoYXQgY2FuIGltcHJvdmUgc2VjdXJpdHksIHN1Y2gg YXMgaGF2aW5nIHRoZQ0KPiBzZXJ2ZXIgaW5pdGlhdGUgYSBwcm9vZi1vZi1wb3NzZXNzaW9uIGF0 IHRoZSBhcHBsaWNhdGlvbiBsYXllciB3aGVuIGEgTWl0TQ0KPiBleHRlbnNpb24gaXMgcmVjZWl2 ZWQgZnJvbSB0aGUgY2xpZW50LiAgSG93ZXZlciwgdGhpcyBpcyBhYm92ZSB0aGUNCj4gdG9rZW4t YmluZGluZyBsYXllciwgYW5kIGRvZXMgbm90IG5lZWQgdG8gYmUgYW4gb2ZmaWNpYWwgcGFydCBv ZiB0b2tlbg0KPiBiaW5kaW5nLg0KPg0KDQpJTUhPLCBhbnkgYWN0aXZlIE1JVE0gd2hpY2ggaXMg bGVnaXRpbWF0ZWx5IHByZXNlbnQgc2hvdWxkIGJlIGFibGUgdG8NCmhvb2sgaW50byB0aGUgc3lz dGVtIGFzIGEgZmVkZXJhdGVkIGFnZW50LiBCZWluZyBrbm93biB0byB0aGUgSWRlbnRpdHkNClBy b3ZpZGVyIGFzIGEgY2xpZW50IGluIGl0cyBvd24gcmlnaHQgYWxsb3dzIGl0IHRvIGdlbmVyYXRl IGl0cyBvd24NCnRva2VucyBmb3IgdGhlIHNlcnZlciBjb25uZWN0aW9uIGFuZCByZXBsYWNlIHRo ZSBvbmVzIHRoZSBlbmQtY2xpZW50IGlzDQp1c2luZy4NCg0KVGhpcyBhbGxvd3MgdGhlIE1JVE0g dG8gb3BlcmF0ZSwgYXMgd2VsbCBhcyBzdGlsbCBkZXRlY3RpbmcgYW55DQp1bmV4cGVjdGVkIG9u ZXMgdGhhdCB0cnkgdG8gTUlUTSB0aGUgdHJhZmZpYy4NCg0KQW1vcw0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVW5iZWFyYWJsZSBtYWlsaW5nIGxp c3QNClVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGU8aHR0cHM6Ly9uYTAx LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cu aWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZ1bmJlYXJhYmxlJmRhdGE9MDElN2MwMSU3 Y0FuZHJlaS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN2NmMjVhZGMxNTg1NWE0ZWNiMjM5MjA4ZDM1 MzMyNmZkZSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1ySnMl MmZMSm4lMmJtc0RYWVdqdXJsJTJiVFl5VTFmUUdsTjdyVzl5ejFCMlJ5MDFrJTNkPg0KDQo= --_000_BLUPR03MB13964D90AE484B2639F816878C810BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjMwNTE2NzQ1NjsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NTM4NzI3NzM2IC02OTk1OTIx OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpD YWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0 IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ RXh0ZW5kaW5nIGEgTUlUTS1kZWZlYXRpbmcgZmVhdHVyZSB0byBzdXBwb3J0IOKAnGxlZ2l0aW1h dGXigJ0gTUlUTSBtYWtlcyBtZSBzYWQuIEl0IHJlbWluZHMgbWUgb2YgdGhlIOKAnGRvdWJsZSBj ZXJ0aWZpY2F0ZeKAnSBUTFMgYXV0aGVudGljYXRpb24gc2NoZW1lcyB1c2VkIGJ5IHNvbWUNCiBu YXRpb25hbCBUTFMgc3RhbmRhcmRzLiBJbiB0aGUgcGFzdCwgYm90aCBUTFMgV0cgYW5kIEhUVFBi aXMgV0cgaGF2ZSByZXBlYXRlZGx5IHJlamVjdGVkIHByb3Bvc2FscyB0aGF0IGVuYWJsZSDigJxs ZWdpdGltYXRl4oCdIE1JVE0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFG NDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPk9uIHRoZSBvdGhlciBoYW5kLCB3ZSBjYW5ub3QgZW5mb3JjZSBUQiBn bG9iYWxseSB1bnRpbCB3ZSBoYXZlIGEgc29sdXRpb24gZm9yIHVzZXJzIHdobyB0cmF2ZWwgdG8g d29yayBhbmQgYmFjayBzbyB0aGF0IHRoZXkgb2Z0ZW4gY29ubmVjdCBkaXJlY3QsIGFuZCBvZnRl biB0aHJvdWdoIGEgY29ycG9yYXRlIHByb3h5LiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgdGhp bmsgdGhlcmUgYXJlIGF0IGxlYXN0IHR3byBkaWZmZXJlbnQgY2FzZXMgaGVyZTogc2VydmVycyB0 aGF0IGFyZSBhc3NvY2lhdGVkIHdpdGggdGhlIE1JVE0gYW5kIHNlcnZlcnMgdGhhdCBhcmVu4oCZ dC4gVGhlIGZvcm1lciBjYW4gcHJvYmFibHkgdXNlIHRoZSBzY2hlbWUNCiB0aGF0IEFtb3MgZGVz Y3JpYmVkLCBhdm9pZGluZyB0aGUgbmVlZCBmb3IgdGhlIGV4dGVuc2lvbi4gVGhlIGxhdHRlciBj b3VsZCBpc3N1ZSBsZXNzIHByaXZpbGVnZWQvc2hvcnQtdGltZSBiZWFyZXIgdG9rZW5zIHdoZW4g VEIgaXMgbm90IHVzZWQgYW5kIG1vcmUgcHJpdmlsZWdlZC9sb25nZXItdGVybSBib3VuZCB0b2tl bnMgd2hlbiBUQiBpcyBuZWdvdGlhdGVkLiBCaWxsLCBkbyB5b3UgdGhpbmsgdGhpcyB3b3VsZCB3 b3JrIGZvciB5b3U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5D aGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbmRyZWk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+QmlsbCBDb3g8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBNYXJjaCAyMywgMjAxNiA4OjQ3IEFNPGJyPg0KPGI+VG86PC9iPiBBbW9zIEplZmZyaWVzICZs dDtzcXVpZDNAdHJlZW5ldC5jby5ueiZndDs8YnI+DQo8Yj5DYzo8L2I+IFRva2JpbmQgV0cgJmx0 O3VuYmVhcmFibGVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFy YWJsZV0gV2UgbmVlZCBhIE1pdE0gZXh0ZW5zaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V2UgaGF2ZSBhIGNoaWNrZW4tYW5kLXRoZS1lZ2cgcHJvYmxlbS4mbmJzcDsg TGVnaXQgTWl0TSBib3hlcyB3aWxsIG9ubHkgc3VwcG9ydCBUQiBvbmNlIFRCIGlzIGJvdGggd2lk ZWx5IGRlcGxveWVkIGFuZCBlbmZvcmNlZC4mbmJzcDsgT24gdGhlIG90aGVyIGhhbmQsIHdlIGNh bm5vdCBlbmZvcmNlIFRCIGdsb2JhbGx5IHVudGlsIHdlIGhhdmUgYSBzb2x1dGlvbiBmb3IgdXNl cnMgd2hvIHRyYXZlbCB0byB3b3JrIGFuZCBiYWNrDQogc28gdGhhdCB0aGV5IG9mdGVuIGNvbm5l Y3QgZGlyZWN0LCBhbmQgb2Z0ZW4gdGhyb3VnaCBhIGNvcnBvcmF0ZSBwcm94eS4mbmJzcDsgVGhp cyBNaXRNIGV4dGVuc2lvbiBpcyBuZWVkZWQgdG8gZ2V0IHBhc3QgdGhpcyBkZWFkbG9jay48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgd2Ugc2hv dWxkICZxdW90O2RldGVjdCZxdW90OyBhIE1pdE0gdGhpcyB3YXk6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBicm93c2VyIGhhcyBh IHZhbGlkIFRCIGtleSBwYWlyIGZvciB0aGUgZVRMRCYjNDM7MSBkb21haW4sIHlldCB0aGUgc2Vy dmVyIGZhaWxlZCB0byBuZWdvdGlhdGUgdG9rZW4gYmluZGluZyB1c2luZyB0aGUgVExTIGV4dGVu c2lvbiwgdGhlbiBpdCBpcyBsaWtlbHkgdGhhdCB0aGVyZSBpcyBhIE1pdE0gdGhhdCBkb2VzIG5v dCBzcGVhayBUQi4mbmJzcDsgSW4gdGhpcyBjYXNlLCBlbmFibGUgdGhlIE1pdE0gZXh0ZW5zaW9u DQogYW5kIHNlbmQgVEIgaGVhZGVycyBhbnl3YXkuJm5ic3A7IFRoZSBzZXJ2ZXIgd2lsbCBzZWUg VEIgaGVhZGVycyBmcm9tIGEgY2xpZW50IHRoYXQgZGlkIG5vdCBuZWdvdGlhdGUgVEIsIGFuZCB0 aGUgc2lnbmF0dXJlIHdpbGwgbWlzbWF0Y2guJm5ic3A7IEhvd2V2ZXIsIHRoZSBzZXJ2ZXIgY2Fu IHZlcmlmeSB0aGUgVEIgc2lnbmF0dXJlIG92ZXIgdGhlIHZhbHVlIGluIHRoZSBleHRlbnNpb24u Jm5ic3A7IElmIHJlcXVlc3RzIGNvbnRhaW4gYW4gYXV0aCB0b2tlbiBzcGVjaWZpY2FsbHkNCiBh dXRob3JpemluZyB1c2UgYmVoaW5kIHRoaXMgTWl0TSwgdGhlbiB0aGUgc2VydmVyIHNob3VsZCBh bGxvdyByZXF1ZXN0cyB0byBiZSBwcm9jZXNzZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBmb2xsb3dpbmcgZGV0YWlsIGlzIGltcG9y dGFudDogV2hlbiBhIHNlcnZlciBzZWVzIHRoZSBUQiBleHRlbnNpb24gYW5kIGEgbWlzbWF0Y2gg b2YgdGhlIFRMUy11bmlxdWUgdnMgdGhlIHZhbHVlIGluIHRoZSBleHRlbnNpb24sIGJ1dCB0aGUg YXV0aCB0b2tlbiBkb2VzIG5vdCBhdXRob3JpemUgdGhpcyBNaXRNLCBpdCBuZWVkcyB0byBhdXRo ZW50aWNhdGUgdGhlIHVzZXIgYW5kIGlzc3VlIGFuIGVuaGFuY2VkDQogYXV0aCB0b2tlbiB0aGF0 IGFkZGl0aW9uYWxseSBhdXRoZW50aWNhdGVzIHRoZSB1c2VyIGJlaGluZCB0aGlzIE1pdE0uJm5i c3A7IE90aGVyd2lzZSwgYXR0YWNrZXJzIGNvdWxkIHNpbXBseSBNaXRNIHRoZW1zZWx2ZXMgYW5k IGF1dGhlbnRpY2F0ZSB3aXRoIHN0b2xlbiBhdXRoIHRva2Vucy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmlsbDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1hciAyMywgMjAx NiBhdCA2OjUxIEFNLCBBbW9zIEplZmZyaWVzICZsdDs8YSBocmVmPSJtYWlsdG86c3F1aWQzQHRy ZWVuZXQuY28ubnoiIHRhcmdldD0iX2JsYW5rIj5zcXVpZDNAdHJlZW5ldC5jby5uejwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIDI0LzAzLzIwMTYgMjoxOSBhLm0uLCBCaWxsIENveCB3cm90ZTo8YnI+DQomZ3Q7IEkgdGhp bmsgb2YgdGhpcyBhcyBhIHRoaW5nIHdlIHNob3VsZCBjb25zaWRlciB3aGVuIHdlIHVwZ3JhZGUg dG9rZW4gYmluZGluZzxicj4NCiZndDsgdG8gc3VwcG9ydCBUTFMgMS4zLiZuYnNwOyBTaW5jZSBU TFMgMS4zIHNlZW1zIHRvIGJlIGdldHRpbmcgY2xvc2UgdG8gZmluYWxpemVkLDxicj4NCiZndDsg aXMgdGhpcyBhIHJlYXNvbmFibGUgdGltZSB0byBzdGFydCBkaXNjdXNzaW5nIGEgTWl0TSBleHRl bnNpb24/PGJyPg0KJmd0Ozxicj4NCiZndDsgSSd2ZSB3cml0dGVuIHVwIGFuIGludGVybmFsIHBy b3Bvc2FsIGZvciB0aGlzLCBidXQgaW4gc2hvcnQsIGZvciB0b2tlbjxicj4NCiZndDsgYmluZGlu ZyB0byBiZSBlbmZvcmNlZCBnbG9iYWxseSwgd2UgaGF2ZSB0byBkZWFsIHdpdGggdGhlIHByb2Js ZW0gb2Y8YnI+DQomZ3Q7IGNvcnBvcmF0ZSBwcm94aWVzIGFuZCBhbnRpLXZpcnVzIE1pdE1zLiZu YnNwOyBXZSBjYW4gZG8gdGhpcyB3aXRoIGEgdG9rZW48YnI+DQomZ3Q7IGJpbmRpbmcgZXh0ZW5z aW9uIHRoYXQgcHJvdmlkZXMgdGhlIG1hdGVyaWFsIHNpZ25lZCBieSB0aGUgY2xpZW50LiZuYnNw OyBJdDxicj4NCiZndDsgd291bGQgYmUgdXNlZCB3aGVuZXZlciB0aGUgY2xpZW50IGRldGVjdHMg dGhhdCBpdCBpcyBiZWluZyBNaXRNLWVkIHdpdGggYTxicj4NCiZndDsgbG9jYWxseSBpbnN0YWxs ZWQgY2VydC4mbmJzcDsgSSd2ZSBldmFsdWF0ZWQgZXZlcnkgYXR0YWNrIEkgY2FuIHRoaW5rIG9m LCBhbmQgaW48YnI+DQomZ3Q7IGVhY2ggY2FzZSB0aGlzIGlzIGF0IGxlYXN0IGFzIHNlY3VyZSBh cyB0aGUgYWx0ZXJuYXRpdmU6IGlzc3VpbmcgdW5ib3VuZDxicj4NCiZndDsgYXV0aCB0b2tlbnMu PGJyPg0KPGJyPg0KSGF2aW5nIGEgbG9jYWxseSBpbnN0YWxsZWQgY2VydCBpcyBubyBndWFyYXRl ZSBvZiBNSVRNIGJlaW5nIHBlcmZvcm1lZC48YnI+DQpOb3IgYSByZWxpYWJsZSBpbmRpY2F0b3Ig dGhhdCBhbiBNSVRNIGlzbid0IHVzaW5nIGEgcm9ndWUgQ0EgY2VydC48YnI+DQo8YnI+DQpBIG1v cmUgcmVsaWFibGUgaW5kaWNhdG9yIGlzIHRoYXQgdGhlc2UgYWN0aXZlIE1JVE0gdXNlIGRpZmZl cmVudCBUTFM8YnI+DQprZXlpbmcgbWF0ZXJpYWwgb24gdGhlIHNlcnZlciBjb25uZWN0aW9uIGFz IGNvbXBhcmVkIHRvIHRoZSBjbGllbnQ8YnI+DQpjb25uZWN0aW9uLiBTbyB0aGUgc2lnbmVkIHRv a2VucyBzaG91bGQgYmUgZGV0ZWN0aWJsZS48YnI+DQo8YnI+DQpQYXNzaXZlIE1JVE0gKGlmIHBv c3NpYmxlKSBhcmUgbm90IHRvdWNoaW5nIHRoZSBUTFMgY29udGVudCwgc28gdGhlPGJyPg0KY2xp ZW50cyB0b2tlbnMgd2lsbCBnZXQgdGhyb3VnaCBhbnl3YXkuPGJyPg0KPGJyPg0KJmd0Ozxicj4N CiZndDsgVGhlcmUgYXJlIGZ1cnRoZXIgc3RlcHMgdGhhdCBjYW4gaW1wcm92ZSBzZWN1cml0eSwg c3VjaCBhcyBoYXZpbmcgdGhlPGJyPg0KJmd0OyBzZXJ2ZXIgaW5pdGlhdGUgYSBwcm9vZi1vZi1w b3NzZXNzaW9uIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciB3aGVuIGEgTWl0TTxicj4NCiZndDsg ZXh0ZW5zaW9uIGlzIHJlY2VpdmVkIGZyb20gdGhlIGNsaWVudC4mbmJzcDsgSG93ZXZlciwgdGhp cyBpcyBhYm92ZSB0aGU8YnI+DQomZ3Q7IHRva2VuLWJpbmRpbmcgbGF5ZXIsIGFuZCBkb2VzIG5v dCBuZWVkIHRvIGJlIGFuIG9mZmljaWFsIHBhcnQgb2YgdG9rZW48YnI+DQomZ3Q7IGJpbmRpbmcu PGJyPg0KJmd0Ozxicj4NCjxicj4NCklNSE8sIGFueSBhY3RpdmUgTUlUTSB3aGljaCBpcyBsZWdp dGltYXRlbHkgcHJlc2VudCBzaG91bGQgYmUgYWJsZSB0bzxicj4NCmhvb2sgaW50byB0aGUgc3lz dGVtIGFzIGEgZmVkZXJhdGVkIGFnZW50LiBCZWluZyBrbm93biB0byB0aGUgSWRlbnRpdHk8YnI+ DQpQcm92aWRlciBhcyBhIGNsaWVudCBpbiBpdHMgb3duIHJpZ2h0IGFsbG93cyBpdCB0byBnZW5l cmF0ZSBpdHMgb3duPGJyPg0KdG9rZW5zIGZvciB0aGUgc2VydmVyIGNvbm5lY3Rpb24gYW5kIHJl cGxhY2UgdGhlIG9uZXMgdGhlIGVuZC1jbGllbnQgaXM8YnI+DQp1c2luZy48YnI+DQo8YnI+DQpU aGlzIGFsbG93cyB0aGUgTUlUTSB0byBvcGVyYXRlLCBhcyB3ZWxsIGFzIHN0aWxsIGRldGVjdGlu ZyBhbnk8YnI+DQp1bmV4cGVjdGVkIG9uZXMgdGhhdCB0cnkgdG8gTUlUTSB0aGUgdHJhZmZpYy48 YnI+DQo8YnI+DQpBbW9zPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnIj5VbmJlYXJhYmxlQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJm dW5iZWFyYWJsZSZhbXA7ZGF0YT0wMSU3YzAxJTdjQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNv bSU3Y2YyNWFkYzE1ODU1YTRlY2IyMzkyMDhkMzUzMzI2ZmRlJTdjNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1ySnMlMmZMSm4lMmJtc0RYWVdqdXJsJTJiVFl5 VTFmUUdsTjdyVzl5ejFCMlJ5MDFrJTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BLUPR03MB13964D90AE484B2639F816878C810BLUPR03MB1396namp_-- From nobody Wed Mar 23 11:24:36 2016 Return-Path: <waywardgeek@google.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 40AE712D6AA for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 11:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 CpoY0mPed0Qv for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 11:24:32 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2463B12D5BF for <unbearable@ietf.org>; Wed, 23 Mar 2016 11:24:32 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id e185so29992411vkb.1 for <unbearable@ietf.org>; Wed, 23 Mar 2016 11:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=tz0mNscsXUBynw+bCL6vxqOKgDj7dtmdBL2dgFRWlhA=; b=auEdtgVTPy+e+Ay95fEFPMdpbR0B+ZlRCU/UNCmvRywuXM6ac1CsZRp94jjFOtjXAo IdtBjQfdKX3vgUITNxNhL4QZpnqqpyysHwoKOxUkMY0r1CHqhaZRHIC4i0rIX6rjbLk/ a/ACWPXjw66+yNpODN6oCzucjvQXsWouDAB0pSCKLD+NxwIMm656SLKuJzpHb85lN0B3 lIGq1cCcvevoXxGUvZUrK6epkELSqwL2v8HqalpdSkwjdNovNRbaOgoMw8vcMKxRjSzH f5MBFoLSrbWz+HaG1mKmJXyvqc10HTWV37q1/iHIh433Iyvv6+5zgVyYhqvYnUHjfVbw 1MBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=tz0mNscsXUBynw+bCL6vxqOKgDj7dtmdBL2dgFRWlhA=; b=OGqI5+oZlNudaufFWYT+4+hHsivIGrnjjx3dJ3k1e++EwA6m19N5oi+QiHO5N7tzXq kjnbMo9zGs2XSN8nVSekyjnk1APUxWJkjFuLLgzAoQIobu5f4Vv6ItmsHJyV5/SGVK+Z uz3Fv56863WvJRbMw0Fu6WqoONfgoO5Gp8jjsBwEevDCOs+TTwSwAp+ruqw+l6KolTPI 8u18IrQl/UOuy+ryfAghw7vNlhP5qaIPF/iUJAiVxHXZL64nElsAhIP1WdmcdqLOTYb3 /q2tasFxmPUezL+WRiiLS9A66KU90hAxnFJFWtrP/Iov2bvNw0PpgwukXJP6ZEJaIPwi a65A== X-Gm-Message-State: AD7BkJLShzP0zpJ+KUlqpC0t/BJNgp4DIPtiZXt1F1N3/oztQa/eIQXwjSVFHHfYGT4xlmIghEN19frO6VgNjlCv MIME-Version: 1.0 X-Received: by 10.176.3.110 with SMTP id 101mr2333224uat.34.1458757471088; Wed, 23 Mar 2016 11:24:31 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Wed, 23 Mar 2016 11:24:30 -0700 (PDT) In-Reply-To: <BLUPR03MB13964D90AE484B2639F816878C810@BLUPR03MB1396.namprd03.prod.outlook.com> References: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> <56F29F69.1080105@treenet.co.nz> <CAH9QtQHs61xW9P_4TjQq-Jz=QPbVH9aDsYUUZc3fCNScQvcZPw@mail.gmail.com> <BLUPR03MB13964D90AE484B2639F816878C810@BLUPR03MB1396.namprd03.prod.outlook.com> Date: Wed, 23 Mar 2016 11:24:30 -0700 Message-ID: <CAH9QtQG1ObEsxhZO_pUjAp0Tp=dRkSRnm8eV7YSKXS-JZauxQw@mail.gmail.com> From: Bill Cox <waywardgeek@google.com> To: Andrei Popov <Andrei.Popov@microsoft.com> Content-Type: multipart/alternative; boundary=001a11c15a0ce11eb3052ebb70c4 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/-Gy4cTh91w5um1ST-NWBmVOOzaM> Cc: Amos Jeffries <squid3@treenet.co.nz>, Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Mar 2016 18:24:34 -0000 --001a11c15a0ce11eb3052ebb70c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 23, 2016 at 10:41 AM, Andrei Popov <Andrei.Popov@microsoft.com> wrote: > Extending a MITM-defeating feature to support =E2=80=9Clegitimate=E2=80= =9D MITM makes me > sad. > Me, too... I think there are at least two different cases here: servers that are > associated with the MITM and servers that aren=E2=80=99t. The former can = probably > use the scheme that Amos described, avoiding the need for the extension. > The latter could issue less privileged/short-time bearer tokens when TB i= s > not used and more privileged/longer-term bound tokens when TB is > negotiated. Bill, do you think this would work for you? > That is the current default plan, I think. The new auth token would authorize non-TB-enabled access for a while, and TB-enabled access for longer. This is a bit less secure, since the auth token can be used from anywhere, not just behind the specific MitM. Bill --001a11c15a0ce11eb3052ebb70c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W= ed, Mar 23, 2016 at 10:41 AM, Andrei Popov <span dir=3D"ltr"><<a href=3D= "mailto:Andrei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov@microsof= t.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri",sans-serif;color:#1f497d">Extending a MITM-defeating feature to= support =E2=80=9Clegitimate=E2=80=9D MITM makes me sad.</span></p></div></= div></blockquote><div><br></div><div>Me, too...</div><div><br></div><blockq= uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">= <div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&qu= ot;Calibri",sans-serif;color:#1f497d">I think there are at least two d= ifferent cases here: servers that are associated with the MITM and servers = that aren=E2=80=99t. The former can probably use the scheme that Amos described, avoiding the need for the extension. The latter could= issue less privileged/short-time bearer tokens when TB is not used and mor= e privileged/longer-term bound tokens when TB is negotiated. Bill, do you t= hink this would work for you?</span></p></div></div></blockquote><div><br><= /div><div>That is the current default plan, I think.=C2=A0 The new auth tok= en would authorize non-TB-enabled access for a while, and TB-enabled access= for longer.=C2=A0 This is a bit less secure, since the auth token can be u= sed from anywhere, not just behind the specific MitM.</div><div><br></div><= div>Bill</div></div></div></div> --001a11c15a0ce11eb3052ebb70c4-- From nobody Wed Mar 23 11:44:08 2016 Return-Path: <waywardgeek@google.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 6AB4A12D735 for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 11:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 tyGGPvy4prmm for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 11:43:59 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F38212D76A for <unbearable@ietf.org>; Wed, 23 Mar 2016 11:43:58 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id e6so30675584vkh.2 for <unbearable@ietf.org>; Wed, 23 Mar 2016 11:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=iLFrNfYedoFEydokDj5TclS8cWXhZ96xICTmMau3vfg=; b=mQULmTWOY8y7nkRHgPwUeQdd8t/idFKwsKUgNUVQiTXrV7GrT4QhqTQqz5AlFQ2izW CfgsPMb7GFNIHtLsG6ZMlvu8T7f0Ybr+Iak7Q5PaaEyoQirV7kI599oG4DRhyZwzBy+I KKd66QWWqDM8WHXY9hXST/Nup+5gFbOJMxkjbfRj2kmR9FJoWLPXXe93wyjaKgfmdKE+ Zuya1cOJzIQP0v1T2y9caxE08nz1yEH1ezI8xq/Abkxs1q8juSXdBMMW+H4+8bZySi91 MDD80hFrafwhRmzkrMGLWvuwLU7TfygcDbPexs3LD8a2RlVDfsEpmgLey5Abj5skYuCv 2+Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=iLFrNfYedoFEydokDj5TclS8cWXhZ96xICTmMau3vfg=; b=c2ySnIhvhippbZzgPg1Y/uVh9rNicTJ1ORWi9tNhnk7QAKg8fgdAyOH95SEaN0uGCD Wgs1wwf5daTqK7eRz928i+8J2qJg6FG+lhltCbBBeHaSZn9tawgeYYIdiuSQIBu+qGeY DkjfUwIwW2oG/RANVO6R3jvjuXbB5EzF/bgiL20LVUvlyB0NLfc+7mmuIvwZEeXHWcMx kgNqRHjkIDBgZkhEUr+YlANN8ku0EjjUM6K/RY6I36BrZt5ISviuuNQDlOPHnv0hqFUN 5qsPJJVyFaR3P3iLQA2QSKZTqW+1KC/Wxw40DblIokH2LLa1QDHTsEepHGWY8yOX1de4 LVtQ== X-Gm-Message-State: AD7BkJKK3JKcJ9yMHRpQu279tqF7HX0k7+2SNUZXfTw9QqWIWK3IYcMHwsHNAWFaSR6/uiPgoMTaSDm6XvTQlrmj MIME-Version: 1.0 X-Received: by 10.31.1.138 with SMTP id 132mr2301401vkb.140.1458758637496; Wed, 23 Mar 2016 11:43:57 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Wed, 23 Mar 2016 11:43:57 -0700 (PDT) In-Reply-To: <BLUPR03MB139616608F68A44A25D7A6758C810@BLUPR03MB1396.namprd03.prod.outlook.com> References: <CAH9QtQFLWGLgKGkD8BeuEsGAaumuqzheBgaiuOHKuUvZucuRWw@mail.gmail.com> <BLUPR03MB139616608F68A44A25D7A6758C810@BLUPR03MB1396.namprd03.prod.outlook.com> Date: Wed, 23 Mar 2016 11:43:57 -0700 Message-ID: <CAH9QtQFFppvqu42B_TuKDfO_6pMkTCBtzhDWbTh+PVfyPVGGyw@mail.gmail.com> From: Bill Cox <waywardgeek@google.com> To: Andrei Popov <Andrei.Popov@microsoft.com> Content-Type: multipart/alternative; boundary=001a113da7dc673699052ebbb672 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/oI1Idudxy5dFqJWlfJUMiaCaPN0> Cc: Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Thoughts on TLS 0-RTT 1.3 compatibility X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Mar 2016 18:44:07 -0000 --001a113da7dc673699052ebbb672 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 23, 2016 at 10:09 AM, Andrei Popov <Andrei.Popov@microsoft.com> wrote: > Please correct me if I read this wrong, but the TB-related part of this > proposal essentially amounts to removing the requirement that the client > prove possession of the TB key on resumption. > Correct. There is no opportunity to prove possession again on a 0-RTT resumption. In any case, protecting all secrets rather than just the private keys will better protect the client. > > > This requirement exists today because TLS resumption state is deemed > easier to steal than a hardware-bound TB key. Once TLS resumption state is > protected in the same way as the TB key, then there will probably be no > need for the client to sign with its TB key when resuming a TLS session. > Yep. This was done for token binding because the session state should be easier to steal. However, it is not done for client certificates, and an attacker with the saved session state does not need access to the cert to resume the connection. Instead of encrypting the session cache, I would prefer to have just the session secrets protected. That would let us use a cross-platform generic crypto API that could be used with any TLS implementation. I would prefer that we start thinking in terms of protecting all secrets rather than just a few private keys. If we secure the secrets, we can have secure 0-RTT resumption. Bill --001a113da7dc673699052ebbb672 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W= ed, Mar 23, 2016 at 10:09 AM, Andrei Popov <span dir=3D"ltr"><<a href=3D= "mailto:Andrei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov@microsof= t.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri",sans-serif;color:#1f497d">Please correct me if I read this wron= g, but the TB-related part of this proposal essentially amounts to removing= the requirement that the client prove possession of the TB key on resumption.</span></p></div></div></blockquote><div><br><= /div><div>Correct.=C2=A0 There is no opportunity to prove possession again = on a 0-RTT resumption.=C2=A0 In any case, protecting all secrets rather tha= n just the private keys will better protect the client.</div><div>=C2=A0</d= iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left= :1px #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink= =3D"purple"><div><p class=3D"MsoNormal"><span style=3D"color:rgb(31,73,125)= ;font-family:Calibri,sans-serif;font-size:11pt">=C2=A0</span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri",sans-serif;color:#1f497d">This requirement exists today because= TLS resumption state is deemed easier to steal than a hardware-bound TB ke= y. Once TLS resumption state is protected in the same way as the TB key, then there will probably be no need for the client= to sign with its TB key when resuming a TLS session.</span></p></div></div= ></blockquote><div><br></div><div>Yep.=C2=A0 This was done for token bindin= g because the session state should be easier to steal.=C2=A0 However, it is= not done for client certificates, and an attacker with the saved session = =C2=A0state does not need access to the cert to resume the connection.</div= ><div><br></div><div>Instead of encrypting the session cache, I would prefe= r to have just the session secrets protected.=C2=A0 That would let us use a= cross-platform generic crypto API that could be used with any TLS implemen= tation.</div><div><br></div><div>I would prefer that we start thinking in t= erms of protecting all secrets rather than just a few private keys.=C2=A0 I= f we secure the secrets, we can have secure 0-RTT resumption.</div><div><br= ></div><div>Bill</div><div><br></div></div></div></div> --001a113da7dc673699052ebbb672-- From nobody Wed Mar 23 11:54:40 2016 Return-Path: <nharper@google.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 3342F12D82E for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 11:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 OYLSxZSjjlwq for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 11:54:23 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E7AA12D826 for <unbearable@ietf.org>; Wed, 23 Mar 2016 11:54:23 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id e185so30955068vkb.1 for <unbearable@ietf.org>; Wed, 23 Mar 2016 11:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LqMa3EYWLzm2XLdqf3WRbOvBe9tkQl4jamkSi9T0gf4=; b=Cn1PwNUt9Y0l/essYfuyppuTSYmXsytUVFXCGKd2vmdj4gAekgB3tQShfvYKJINTH+ nMJU6sB6+CP0sKR3wqjQUk94CToP44jANHyFnRzkCPeMMDUdXlWAT1pltLE1Xt1gBL+X AEMIwjSaX18b97jLrYyqF+BO39G5C+7oJa71d/Y58FCTxiwTpOUQXU7uCR+wVnleTdvk B1ZbggvleZfvyR9uDYm+VLl9zbDm9zY4n/oeTvwnK4rMXcIHNTf1QSUrn/s8Y71q5z4s H3LzneAjGEjT8ARLza9EVLy7rFN3saGb/HrDxzRy0yJQFdkfHC0t4zup+wvZww9fULrJ FIFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LqMa3EYWLzm2XLdqf3WRbOvBe9tkQl4jamkSi9T0gf4=; b=dL1z1zMCFC54YnkgNAwvQcYX45bbBrNHhn5RkPhGGBjMaezmpjZ9wczQQ8aELpKhAx VDUpcLcZ+Iw14ncs3LnCiu0+yHc39D81iN5+OfJ+yFr3m5EzxQxxxqmUfAqhnf4jiL7E 3Bpp4PJrXICwP033uw7SCOUgc6Q2lUXDa1qvNTdg3haIqo5XL7reMO7UzbgjuWJA7GMK ZP4u1BoQciYhwivgV8mgx41H4tjgGx1EZV3ba2sUEUcu0OUFC6uHsghK/ErH3VOU/EtY GV239Hdo3UY0mk26KEbCImcOUFLyxfSd4rl85brmrSKODP0aGp9Ds1K9Mb1BuLyrqeC7 ZMxA== X-Gm-Message-State: AD7BkJI5OFJKDdrtD7eTd2xhUkeopvldUv1HWVqkGjJRrQwu/kMRgYO0yxcUhbb+exCiNhxkO1I354NPMj13TbUA X-Received: by 10.176.0.22 with SMTP id 22mr2387437uai.6.1458759261901; Wed, 23 Mar 2016 11:54:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.76.198 with HTTP; Wed, 23 Mar 2016 11:54:02 -0700 (PDT) In-Reply-To: <CAH9QtQG1ObEsxhZO_pUjAp0Tp=dRkSRnm8eV7YSKXS-JZauxQw@mail.gmail.com> References: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> <56F29F69.1080105@treenet.co.nz> <CAH9QtQHs61xW9P_4TjQq-Jz=QPbVH9aDsYUUZc3fCNScQvcZPw@mail.gmail.com> <BLUPR03MB13964D90AE484B2639F816878C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CAH9QtQG1ObEsxhZO_pUjAp0Tp=dRkSRnm8eV7YSKXS-JZauxQw@mail.gmail.com> From: Nick Harper <nharper@google.com> Date: Wed, 23 Mar 2016 11:54:02 -0700 Message-ID: <CACdeXiLsw2i+BEv-EUj=5fHBAdFHYaR64191pN6dJo+HGRpocw@mail.gmail.com> To: Bill Cox <waywardgeek@google.com> Content-Type: multipart/alternative; boundary=001a113bd80a9eddc8052ebbdb1d Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/0WGA5Le0qA-hZOEa5XSGcGeSwTc> Cc: Tokbind WG <unbearable@ietf.org>, Andrei Popov <Andrei.Popov@microsoft.com>, Amos Jeffries <squid3@treenet.co.nz> Subject: Re: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Mar 2016 18:54:39 -0000 --001a113bd80a9eddc8052ebbdb1d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm having trouble figuring out how this provides any more security than not doing it at all. My understanding of this MitM proposal is as follows: 1. Client establishes (direct) connection to server with TBID1; server replies with cookie C1 bound to TBID1 2. User changes networks, and is now behind a MitM 3. Client connects to server (thru MitM), tries (and fails) to negotiate TB in TLS handshake. 4. Client sends Sec-Token-Binding header anyways, with MitM extension, and TBID1. Client also sends cookie C1. 5. Server has user re-auth, and issues new cookie C2 that is half-bound to TBID1 (i.e. the server either expects it to be bound to TBID1, or to see the token binding message with the MitM extension with TBID1) 6. Client can use C2 with TBID1 with or without MitM extension to authenticate to the server. In steps 5 and 6, C2 plus the value of the Sec-Token-Binding header effectively becomes a bearer token. If we don't do any sort of MitM extension, steps 1 thru 3 stay the same. In step 4, the client doesn't send a Sec-Token-Binding header, but still sends cookie C1. Step 5 still has the server asking the user to re-auth, but now the new cookie C2 is unbound. On Wed, Mar 23, 2016 at 11:24 AM, Bill Cox <waywardgeek@google.com> wrote: > On Wed, Mar 23, 2016 at 10:41 AM, Andrei Popov <Andrei.Popov@microsoft.co= m > > wrote: > >> Extending a MITM-defeating feature to support =E2=80=9Clegitimate=E2=80= =9D MITM makes me >> sad. >> > > Me, too... > > I think there are at least two different cases here: servers that are >> associated with the MITM and servers that aren=E2=80=99t. The former can= probably >> use the scheme that Amos described, avoiding the need for the extension. >> The latter could issue less privileged/short-time bearer tokens when TB = is >> not used and more privileged/longer-term bound tokens when TB is >> negotiated. Bill, do you think this would work for you? >> > > That is the current default plan, I think. The new auth token would > authorize non-TB-enabled access for a while, and TB-enabled access for > longer. This is a bit less secure, since the auth token can be used from > anywhere, not just behind the specific MitM. > > Bill > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --001a113bd80a9eddc8052ebbdb1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I'm having trouble figuring out how this provides any = more security than not doing it at all. My understanding of this MitM propo= sal is as follows:<div>1. Client establishes (direct) connection to server = with TBID1; server replies with cookie C1 bound to TBID1</div><div>2. User = changes networks, and is now behind a MitM</div><div>3. Client connects to = server (thru MitM), tries (and fails) to negotiate TB in TLS handshake.</di= v><div>4. Client sends Sec-Token-Binding header anyways, with MitM extensio= n, and TBID1. Client also sends cookie C1.</div><div>5. Server has user re-= auth, and issues new cookie C2 that is half-bound to TBID1 (i.e. the server= either expects it to be bound to TBID1, or to see the token binding messag= e with the MitM extension with TBID1)</div><div>6. Client can use C2 with T= BID1 with or without MitM extension to authenticate to the server.</div><di= v><br></div><div>In steps 5 and 6, C2 plus the value of the Sec-Token-Bindi= ng header effectively becomes a bearer token.</div><div><br></div><div>If w= e don't do any sort of MitM extension, steps 1 thru 3 stay the same. In= step 4, the client doesn't send a Sec-Token-Binding header, but still = sends cookie C1. Step 5 still has the server asking the user to re-auth, bu= t now the new cookie C2 is unbound.</div></div><div class=3D"gmail_extra"><= br><div class=3D"gmail_quote">On Wed, Mar 23, 2016 at 11:24 AM, Bill Cox <s= pan dir=3D"ltr"><<a href=3D"mailto:waywardgeek@google.com" target=3D"_bl= ank">waywardgeek@google.com</a>></span> wrote:<br><blockquote class=3D"g= mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l= eft:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_qu= ote"><span class=3D"">On Wed, Mar 23, 2016 at 10:41 AM, Andrei Popov <span = dir=3D"ltr"><<a href=3D"mailto:Andrei.Popov@microsoft.com" target=3D"_bl= ank">Andrei.Popov@microsoft.com</a>></span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri",sans-serif;color:#1f497d">Extending a MITM-defeating feature to= support =E2=80=9Clegitimate=E2=80=9D MITM makes me sad.</span></p></div></= div></blockquote><div><br></div></span><div>Me, too...</div><span class=3D"= "><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D= "blue" vlink=3D"purple"><div><p class=3D"MsoNormal"><span style=3D"font-siz= e:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I think = there are at least two different cases here: servers that are associated wi= th the MITM and servers that aren=E2=80=99t. The former can probably use th= e scheme that Amos described, avoiding the need for the extension. The latter could= issue less privileged/short-time bearer tokens when TB is not used and mor= e privileged/longer-term bound tokens when TB is negotiated. Bill, do you t= hink this would work for you?</span></p></div></div></blockquote><div><br><= /div></span><div>That is the current default plan, I think.=C2=A0 The new a= uth token would authorize non-TB-enabled access for a while, and TB-enabled= access for longer.=C2=A0 This is a bit less secure, since the auth token c= an be used from anywhere, not just behind the specific MitM.</div><span cla= ss=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>Bill</div></font>= </span></div></div></div> <br>_______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org">Unbearable@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> <br></blockquote></div><br></div> --001a113bd80a9eddc8052ebbdb1d-- From nobody Wed Mar 23 12:35:11 2016 Return-Path: <waywardgeek@google.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 240A512D84C for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 12:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 z0n6rkQYIPUl for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 12:35:02 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A09BC12D80D for <unbearable@ietf.org>; Wed, 23 Mar 2016 12:35:02 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id z68so32326684vkg.3 for <unbearable@ietf.org>; Wed, 23 Mar 2016 12:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=0JRFZjUjb3FuObze0ZcxNSy4LfdVZZVkSuYATl7dkS8=; b=JZlsc36ntgZ4DrjCyA7fe/RSUKVRvafM2wfBvU0W/Q8G41pKifApvcXihiDV4Hucrr TveGCBdYJtP1nsQT8cxEhist1Kk7bPL8PKRpXwuTe9dMUeZbmUnXvTVjwdThRylMiY1C Q262b41CTXgcT+yri2AQyxxO8l1RW3DpHEodcAXxipP/61x0xE+trfOJ/vr0tiOOJWxr x7EA7a+gIZaj0Sv4g77hD3/i0rx8liQpNm4vZeVG6XluAvZ/RXt1opPA+Zv36RI0ray4 0kyCTCwVjPQ/CgtORF4qJPCN2Qy41KgpiP4GPImMH7qeRU7q2PACzhYmZ6wJiqBi4q39 WBhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=0JRFZjUjb3FuObze0ZcxNSy4LfdVZZVkSuYATl7dkS8=; b=YRurTDF5tNvDEpJOLeDBvomcmH/p9+JOr7phSWZijiffF37avAyftomo5xHXZSRvLL EUtSozA/MJDjfdnE3IgqGcoDNDHqJERjAFkCY6Y6HP+1LliwNazyBkQnSyzXf2WPHaxh Je1xAiNHrFx/FXATGhBzdglpQUzGUBeR7CeaRDNU3zU5JAZDr/YPPBfh+wQr5DuBP0J/ 5GUQ57ZeRsTPi3pIUyrMWT+GCYm2Yv+TFtbeiHXtpgUSMoxUMcIhFZ1R81RlUo8hn+OU yOG4QwXUEnBAd8DBmjw8IQ6lF7cU5/kfYlGRXL3BLOWQAJzc4VvnBsfELRD+c1tocrzp yezw== X-Gm-Message-State: AD7BkJIBcQLdmfsvdWxfyh3HUToA07qEm50pTAUVyWc6YtgkthnH/UZxfgq/rnypQh4TnQXhA4ijEiCO7vkGM7Y3 MIME-Version: 1.0 X-Received: by 10.31.1.138 with SMTP id 132mr2410596vkb.140.1458761701633; Wed, 23 Mar 2016 12:35:01 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Wed, 23 Mar 2016 12:35:01 -0700 (PDT) In-Reply-To: <CACdeXiLsw2i+BEv-EUj=5fHBAdFHYaR64191pN6dJo+HGRpocw@mail.gmail.com> References: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> <56F29F69.1080105@treenet.co.nz> <CAH9QtQHs61xW9P_4TjQq-Jz=QPbVH9aDsYUUZc3fCNScQvcZPw@mail.gmail.com> <BLUPR03MB13964D90AE484B2639F816878C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CAH9QtQG1ObEsxhZO_pUjAp0Tp=dRkSRnm8eV7YSKXS-JZauxQw@mail.gmail.com> <CACdeXiLsw2i+BEv-EUj=5fHBAdFHYaR64191pN6dJo+HGRpocw@mail.gmail.com> Date: Wed, 23 Mar 2016 12:35:01 -0700 Message-ID: <CAH9QtQF64FvtHv8moaJGxYWaZGybA58R6xqiNYmmTZv=PABKSg@mail.gmail.com> From: Bill Cox <waywardgeek@google.com> To: Nick Harper <nharper@google.com> Content-Type: multipart/alternative; boundary=001a113da7dc0a016b052ebc6d4f Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/XfQB95KqnkXJWWq1RrMJoseyM7Y> Cc: Tokbind WG <unbearable@ietf.org>, Andrei Popov <Andrei.Popov@microsoft.com>, Amos Jeffries <squid3@treenet.co.nz> Subject: Re: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Mar 2016 19:35:10 -0000 --001a113da7dc0a016b052ebc6d4f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You are reading it correctly. The partially bound cookie + TB header become a bearer token. There are places in the pipeline where only the cookie exists. Bill On Wed, Mar 23, 2016 at 11:54 AM, Nick Harper <nharper@google.com> wrote: > I'm having trouble figuring out how this provides any more security than > not doing it at all. My understanding of this MitM proposal is as follows= : > 1. Client establishes (direct) connection to server with TBID1; server > replies with cookie C1 bound to TBID1 > 2. User changes networks, and is now behind a MitM > 3. Client connects to server (thru MitM), tries (and fails) to negotiate > TB in TLS handshake. > 4. Client sends Sec-Token-Binding header anyways, with MitM extension, an= d > TBID1. Client also sends cookie C1. > 5. Server has user re-auth, and issues new cookie C2 that is half-bound t= o > TBID1 (i.e. the server either expects it to be bound to TBID1, or to see > the token binding message with the MitM extension with TBID1) > 6. Client can use C2 with TBID1 with or without MitM extension to > authenticate to the server. > > In steps 5 and 6, C2 plus the value of the Sec-Token-Binding header > effectively becomes a bearer token. > > If we don't do any sort of MitM extension, steps 1 thru 3 stay the same. > In step 4, the client doesn't send a Sec-Token-Binding header, but still > sends cookie C1. Step 5 still has the server asking the user to re-auth, > but now the new cookie C2 is unbound. > > On Wed, Mar 23, 2016 at 11:24 AM, Bill Cox <waywardgeek@google.com> wrote= : > >> On Wed, Mar 23, 2016 at 10:41 AM, Andrei Popov < >> Andrei.Popov@microsoft.com> wrote: >> >>> Extending a MITM-defeating feature to support =E2=80=9Clegitimate=E2=80= =9D MITM makes me >>> sad. >>> >> >> Me, too... >> >> I think there are at least two different cases here: servers that are >>> associated with the MITM and servers that aren=E2=80=99t. The former ca= n probably >>> use the scheme that Amos described, avoiding the need for the extension= . >>> The latter could issue less privileged/short-time bearer tokens when TB= is >>> not used and more privileged/longer-term bound tokens when TB is >>> negotiated. Bill, do you think this would work for you? >>> >> >> That is the current default plan, I think. The new auth token would >> authorize non-TB-enabled access for a while, and TB-enabled access for >> longer. This is a bit less secure, since the auth token can be used fro= m >> anywhere, not just behind the specific MitM. >> >> Bill >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >> >> > --001a113da7dc0a016b052ebc6d4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">You are reading it correctly.=C2=A0 The partially bound co= okie + TB header become a bearer token.=C2=A0 There are places in the pipel= ine where only the cookie exists.<div><br></div><div>Bill<br><div><div clas= s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Mar 23, 2016 at 11= :54 AM, Nick Harper <span dir=3D"ltr"><<a href=3D"mailto:nharper@google.= com" target=3D"_blank">nharper@google.com</a>></span> wrote:<br><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex"><div dir=3D"ltr">I'm having trouble figuring out= how this provides any more security than not doing it at all. My understan= ding of this MitM proposal is as follows:<div>1. Client establishes (direct= ) connection to server with TBID1; server replies with cookie C1 bound to T= BID1</div><div>2. User changes networks, and is now behind a MitM</div><div= >3. Client connects to server (thru MitM), tries (and fails) to negotiate T= B in TLS handshake.</div><div>4. Client sends Sec-Token-Binding header anyw= ays, with MitM extension, and TBID1. Client also sends cookie C1.</div><div= >5. Server has user re-auth, and issues new cookie C2 that is half-bound to= TBID1 (i.e. the server either expects it to be bound to TBID1, or to see t= he token binding message with the MitM extension with TBID1)</div><div>6. C= lient can use C2 with TBID1 with or without MitM extension to authenticate = to the server.</div><div><br></div><div>In steps 5 and 6, C2 plus the value= of the Sec-Token-Binding header effectively becomes a bearer token.</div><= div><br></div><div>If we don't do any sort of MitM extension, steps 1 t= hru 3 stay the same. In step 4, the client doesn't send a Sec-Token-Bin= ding header, but still sends cookie C1. Step 5 still has the server asking = the user to re-auth, but now the new cookie C2 is unbound.</div></div><div = class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div class=3D"h5"= >On Wed, Mar 23, 2016 at 11:24 AM, Bill Cox <span dir=3D"ltr"><<a href= =3D"mailto:waywardgeek@google.com" target=3D"_blank">waywardgeek@google.com= </a>></span> wrote:<br></div></div><blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><= div class=3D"h5"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"= gmail_quote"><span>On Wed, Mar 23, 2016 at 10:41 AM, Andrei Popov <span dir= =3D"ltr"><<a href=3D"mailto:Andrei.Popov@microsoft.com" target=3D"_blank= ">Andrei.Popov@microsoft.com</a>></span> wrote:<br><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri",sans-serif;color:#1f497d">Extending a MITM-defeating feature to= support =E2=80=9Clegitimate=E2=80=9D MITM makes me sad.</span></p></div></= div></blockquote><div><br></div></span><div>Me, too...</div><span><div><br>= </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlin= k=3D"purple"><div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;fo= nt-family:"Calibri",sans-serif;color:#1f497d">I think there are a= t least two different cases here: servers that are associated with the MITM= and servers that aren=E2=80=99t. The former can probably use the scheme that Amos described, avoiding the need for the extension. The latter could= issue less privileged/short-time bearer tokens when TB is not used and mor= e privileged/longer-term bound tokens when TB is negotiated. Bill, do you t= hink this would work for you?</span></p></div></div></blockquote><div><br><= /div></span><div>That is the current default plan, I think.=C2=A0 The new a= uth token would authorize non-TB-enabled access for a while, and TB-enabled= access for longer.=C2=A0 This is a bit less secure, since the auth token c= an be used from anywhere, not just behind the specific MitM.</div><span><fo= nt color=3D"#888888"><div><br></div><div>Bill</div></font></span></div></di= v></div> <br></div></div><span class=3D"">__________________________________________= _____<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> <br></span></blockquote></div><br></div> </blockquote></div><br></div></div></div></div> --001a113da7dc0a016b052ebc6d4f-- From nobody Wed Mar 23 12:37:25 2016 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 2FDFA12D85B for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 12:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 4a6qlR_e-8ek for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 12:37:20 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0117.outbound.protection.outlook.com [207.46.100.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A24AF12D850 for <unbearable@ietf.org>; Wed, 23 Mar 2016 12:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9x+3cgKqlOSUArilHhGH7+wM7VMsc8BBWyOGdG0nyZY=; b=KzCNCTROSGhRTRnZt5W9symk8768BBdUJFFEbDutkQoeEs0EJre5me2T/yZ747nenixbT2TMTltl7wXJeUjAyRTT0Bu+5qEOO3ygvh6m9vV5B84BP8Sn0XtYLV7cBsrkHRmKfPN5AauUX4eVYWd8qXPMuHuQUBEcJ8hFKTwrAFw= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 23 Mar 2016 19:37:19 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0434.021; Wed, 23 Mar 2016 19:37:19 +0000 From: Andrei Popov <Andrei.Popov@microsoft.com> To: Bill Cox <waywardgeek@google.com> Thread-Topic: [Unbearable] Thoughts on TLS 0-RTT 1.3 compatibility Thread-Index: AQHRhQcgxIK280Rw4Uycc/vXubnt6Z9nP4hwgAAeU4CAAAHIgA== Date: Wed, 23 Mar 2016 19:37:19 +0000 Message-ID: <BLUPR03MB13961CA8EF0DE7D342ADDDC78C810@BLUPR03MB1396.namprd03.prod.outlook.com> References: <CAH9QtQFLWGLgKGkD8BeuEsGAaumuqzheBgaiuOHKuUvZucuRWw@mail.gmail.com> <BLUPR03MB139616608F68A44A25D7A6758C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CAH9QtQFFppvqu42B_TuKDfO_6pMkTCBtzhDWbTh+PVfyPVGGyw@mail.gmail.com> In-Reply-To: <CAH9QtQFFppvqu42B_TuKDfO_6pMkTCBtzhDWbTh+PVfyPVGGyw@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:1::1d2] x-ms-office365-filtering-correlation-id: 7c84a3a4-d501-4cf5-a1bb-08d353528c3d x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:yDLb3gzze+K2HjME+g6VXjj82F4MAxZcIwQ4lQaCTxjHGXJHPrf/jVWBtCpjCvMlt46UnUTNvHNWxtYpdGXb5TVVl1hsSJBcuUw5f0wD/NjYkZEkWKkLkicJlpV/duPCLqVekIjrU4mNj+8ZzsEU9w==; 24:4CTVokN85ZS5P2GB31MiEcL7ZsGbJsbnSpW9RkIQFz/E7RLupDFF6k9ihbUHEtF8x0c7ZZ7B/pLQgpenrmnYq/2ngv/jk9+PITOb34P8oN8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; x-microsoft-antispam-prvs: <BLUPR03MB1395958096F0D2AEE480B1598C810@BLUPR03MB1395.namprd03.prod.outlook.com> x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 08902E536D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(106116001)(110136002)(10400500002)(189998001)(10290500002)(6116002)(92566002)(74316001)(1096002)(2900100001)(102836003)(790700001)(5008740100001)(3660700001)(2906002)(1220700001)(5005710100001)(76576001)(2950100001)(4326007)(586003)(3280700002)(5002640100001)(10090500001)(76176999)(5003600100002)(33656002)(54356999)(15975445007)(16236675004)(11100500001)(19625215002)(99286002)(50986999)(77096005)(561944003)(87936001)(5004730100002)(19580395003)(19580405001)(86362001)(122556002)(19300405004)(81166005); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB13961CA8EF0DE7D342ADDDC78C810BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2016 19:37:19.3394 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/IM4-pCcTOujYEmirVkhJoEf_Z1c> Cc: Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Thoughts on TLS 0-RTT 1.3 compatibility X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Mar 2016 19:37:23 -0000 --_000_BLUPR03MB13961CA8EF0DE7D342ADDDC78C810BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEkgd291bGQgcHJlZmVyIHRoYXQgd2Ugc3RhcnQgdGhpbmtpbmcgaW4gdGVybXMgb2YgcHJv dGVjdGluZyBhbGwgc2VjcmV0cyByYXRoZXIgdGhhbiBqdXN0IGEgZmV3IHByaXZhdGUga2V5cy4g IElmIHdlIHNlY3VyZSB0aGUgc2VjcmV0cywgd2UgY2FuIGhhdmUgc2VjdXJlIDAtUlRUIHJlc3Vt cHRpb24uDQoNClllcywgSSBhZ3JlZSB3aXRoIHRoaXMuIEZvciBUTFMgMS4zLCB0aGlzIGNvdWxk IGJlIG91ciB3YXkgdG8gZW5hYmxlIFRCIHdpdGggMC1SVFQsIGF0IGxlYXN0IHdoZXJlIHRoZSBo YXJkd2FyZSBhbGxvd3Mgc2VjdXJlIHN0b3JhZ2Ugb2YgVExTIHNlY3JldHMgKGFuZCBub3QganVz dCBUQiBwcml2YXRlIGtleXMpLg0KDQpGcm9tOiBCaWxsIENveCBbbWFpbHRvOndheXdhcmRnZWVr QGdvb2dsZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDIzLCAyMDE2IDExOjQ0IEFNDQpU bzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4NCkNjOiBUb2tiaW5k IFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBUaG91 Z2h0cyBvbiBUTFMgMC1SVFQgMS4zIGNvbXBhdGliaWxpdHkNCg0KT24gV2VkLCBNYXIgMjMsIDIw MTYgYXQgMTA6MDkgQU0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208 bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpQbGVhc2UgY29ycmVj dCBtZSBpZiBJIHJlYWQgdGhpcyB3cm9uZywgYnV0IHRoZSBUQi1yZWxhdGVkIHBhcnQgb2YgdGhp cyBwcm9wb3NhbCBlc3NlbnRpYWxseSBhbW91bnRzIHRvIHJlbW92aW5nIHRoZSByZXF1aXJlbWVu dCB0aGF0IHRoZSBjbGllbnQgcHJvdmUgcG9zc2Vzc2lvbiBvZiB0aGUgVEIga2V5IG9uIHJlc3Vt cHRpb24uDQoNCkNvcnJlY3QuICBUaGVyZSBpcyBubyBvcHBvcnR1bml0eSB0byBwcm92ZSBwb3Nz ZXNzaW9uIGFnYWluIG9uIGEgMC1SVFQgcmVzdW1wdGlvbi4gIEluIGFueSBjYXNlLCBwcm90ZWN0 aW5nIGFsbCBzZWNyZXRzIHJhdGhlciB0aGFuIGp1c3QgdGhlIHByaXZhdGUga2V5cyB3aWxsIGJl dHRlciBwcm90ZWN0IHRoZSBjbGllbnQuDQoNCg0KVGhpcyByZXF1aXJlbWVudCBleGlzdHMgdG9k YXkgYmVjYXVzZSBUTFMgcmVzdW1wdGlvbiBzdGF0ZSBpcyBkZWVtZWQgZWFzaWVyIHRvIHN0ZWFs IHRoYW4gYSBoYXJkd2FyZS1ib3VuZCBUQiBrZXkuIE9uY2UgVExTIHJlc3VtcHRpb24gc3RhdGUg aXMgcHJvdGVjdGVkIGluIHRoZSBzYW1lIHdheSBhcyB0aGUgVEIga2V5LCB0aGVuIHRoZXJlIHdp bGwgcHJvYmFibHkgYmUgbm8gbmVlZCBmb3IgdGhlIGNsaWVudCB0byBzaWduIHdpdGggaXRzIFRC IGtleSB3aGVuIHJlc3VtaW5nIGEgVExTIHNlc3Npb24uDQoNClllcC4gIFRoaXMgd2FzIGRvbmUg Zm9yIHRva2VuIGJpbmRpbmcgYmVjYXVzZSB0aGUgc2Vzc2lvbiBzdGF0ZSBzaG91bGQgYmUgZWFz aWVyIHRvIHN0ZWFsLiAgSG93ZXZlciwgaXQgaXMgbm90IGRvbmUgZm9yIGNsaWVudCBjZXJ0aWZp Y2F0ZXMsIGFuZCBhbiBhdHRhY2tlciB3aXRoIHRoZSBzYXZlZCBzZXNzaW9uICBzdGF0ZSBkb2Vz IG5vdCBuZWVkIGFjY2VzcyB0byB0aGUgY2VydCB0byByZXN1bWUgdGhlIGNvbm5lY3Rpb24uDQoN Ckluc3RlYWQgb2YgZW5jcnlwdGluZyB0aGUgc2Vzc2lvbiBjYWNoZSwgSSB3b3VsZCBwcmVmZXIg dG8gaGF2ZSBqdXN0IHRoZSBzZXNzaW9uIHNlY3JldHMgcHJvdGVjdGVkLiAgVGhhdCB3b3VsZCBs ZXQgdXMgdXNlIGEgY3Jvc3MtcGxhdGZvcm0gZ2VuZXJpYyBjcnlwdG8gQVBJIHRoYXQgY291bGQg YmUgdXNlZCB3aXRoIGFueSBUTFMgaW1wbGVtZW50YXRpb24uDQoNCkkgd291bGQgcHJlZmVyIHRo YXQgd2Ugc3RhcnQgdGhpbmtpbmcgaW4gdGVybXMgb2YgcHJvdGVjdGluZyBhbGwgc2VjcmV0cyBy YXRoZXIgdGhhbiBqdXN0IGEgZmV3IHByaXZhdGUga2V5cy4gIElmIHdlIHNlY3VyZSB0aGUgc2Vj cmV0cywgd2UgY2FuIGhhdmUgc2VjdXJlIDAtUlRUIHJlc3VtcHRpb24uDQoNCkJpbGwNCg0K --_000_BLUPR03MB13961CA8EF0DE7D342ADDDC78C810BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2Nzc1MTEzNDc7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNDI4MDcyNTYgLTIyMTUwMDExOCA2NzY5 ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJp Ow0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT5JIHdvdWxkIHByZWZlciB0aGF0IHdlIHN0YXJ0IHRoaW5raW5nIGluIHRlcm1zIG9mIHBy b3RlY3RpbmcgYWxsIHNlY3JldHMgcmF0aGVyIHRoYW4ganVzdCBhIGZldyBwcml2YXRlIGtleXMu Jm5ic3A7IElmIHdlIHNlY3VyZSB0aGUgc2VjcmV0cywgd2UgY2FuIGhhdmUgc2VjdXJlIDAtUlRU IHJlc3VtcHRpb24uPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WWVzLCBJIGFncmVlIHdpdGggdGhpcy4gRm9y IFRMUyAxLjMsIHRoaXMgY291bGQgYmUgb3VyIHdheSB0byBlbmFibGUgVEIgd2l0aCAwLVJUVCwg YXQgbGVhc3Qgd2hlcmUgdGhlIGhhcmR3YXJlIGFsbG93cyBzZWN1cmUgc3RvcmFnZSBvZiBUTFMg c2VjcmV0cyAoYW5kIG5vdA0KIGp1c3QgVEIgcHJpdmF0ZSBrZXlzKS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQmlsbCBD b3ggW21haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdl ZG5lc2RheSwgTWFyY2ggMjMsIDIwMTYgMTE6NDQgQU08YnI+DQo8Yj5Ubzo8L2I+IEFuZHJlaSBQ b3BvdiAmbHQ7QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBU b2tiaW5kIFdHICZsdDt1bmJlYXJhYmxlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW1VuYmVhcmFibGVdIFRob3VnaHRzIG9uIFRMUyAwLVJUVCAxLjMgY29tcGF0aWJpbGl0 eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g V2VkLCBNYXIgMjMsIDIwMTYgYXQgMTA6MDkgQU0sIEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0i bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmVp LlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgcmVhZCB0aGlzIHdyb25n LCBidXQgdGhlIFRCLXJlbGF0ZWQgcGFydCBvZiB0aGlzIHByb3Bvc2FsIGVzc2VudGlhbGx5IGFt b3VudHMNCiB0byByZW1vdmluZyB0aGUgcmVxdWlyZW1lbnQgdGhhdCB0aGUgY2xpZW50IHByb3Zl IHBvc3Nlc3Npb24gb2YgdGhlIFRCIGtleSBvbiByZXN1bXB0aW9uLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Db3JyZWN0LiZuYnNwOyBUaGVyZSBpcyBubyBvcHBvcnR1bml0eSB0byBwcm92 ZSBwb3NzZXNzaW9uIGFnYWluIG9uIGEgMC1SVFQgcmVzdW1wdGlvbi4mbmJzcDsgSW4gYW55IGNh c2UsIHByb3RlY3RpbmcgYWxsIHNlY3JldHMgcmF0aGVyIHRoYW4ganVzdCB0aGUgcHJpdmF0ZSBr ZXlzIHdpbGwgYmV0dGVyIHByb3RlY3QgdGhlIGNsaWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5U aGlzIHJlcXVpcmVtZW50IGV4aXN0cyB0b2RheSBiZWNhdXNlIFRMUyByZXN1bXB0aW9uIHN0YXRl IGlzIGRlZW1lZCBlYXNpZXIgdG8gc3RlYWwgdGhhbiBhIGhhcmR3YXJlLWJvdW5kDQogVEIga2V5 LiBPbmNlIFRMUyByZXN1bXB0aW9uIHN0YXRlIGlzIHByb3RlY3RlZCBpbiB0aGUgc2FtZSB3YXkg YXMgdGhlIFRCIGtleSwgdGhlbiB0aGVyZSB3aWxsIHByb2JhYmx5IGJlIG5vIG5lZWQgZm9yIHRo ZSBjbGllbnQgdG8gc2lnbiB3aXRoIGl0cyBUQiBrZXkgd2hlbiByZXN1bWluZyBhIFRMUyBzZXNz aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXAuJm5ic3A7IFRoaXMgd2FzIGRvbmUg Zm9yIHRva2VuIGJpbmRpbmcgYmVjYXVzZSB0aGUgc2Vzc2lvbiBzdGF0ZSBzaG91bGQgYmUgZWFz aWVyIHRvIHN0ZWFsLiZuYnNwOyBIb3dldmVyLCBpdCBpcyBub3QgZG9uZSBmb3IgY2xpZW50IGNl cnRpZmljYXRlcywgYW5kIGFuIGF0dGFja2VyIHdpdGggdGhlIHNhdmVkIHNlc3Npb24gJm5ic3A7 c3RhdGUgZG9lcyBub3QgbmVlZCBhY2Nlc3MgdG8gdGhlIGNlcnQgdG8gcmVzdW1lIHRoZSBjb25u ZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JbnN0ZWFkIG9mIGVuY3J5cHRpbmcgdGhlIHNlc3Npb24gY2FjaGUsIEkgd291bGQgcHJl ZmVyIHRvIGhhdmUganVzdCB0aGUgc2Vzc2lvbiBzZWNyZXRzIHByb3RlY3RlZC4mbmJzcDsgVGhh dCB3b3VsZCBsZXQgdXMgdXNlIGEgY3Jvc3MtcGxhdGZvcm0gZ2VuZXJpYyBjcnlwdG8gQVBJIHRo YXQgY291bGQgYmUgdXNlZCB3aXRoIGFueSBUTFMgaW1wbGVtZW50YXRpb24uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgcHJlZmVy IHRoYXQgd2Ugc3RhcnQgdGhpbmtpbmcgaW4gdGVybXMgb2YgcHJvdGVjdGluZyBhbGwgc2VjcmV0 cyByYXRoZXIgdGhhbiBqdXN0IGEgZmV3IHByaXZhdGUga2V5cy4mbmJzcDsgSWYgd2Ugc2VjdXJl IHRoZSBzZWNyZXRzLCB3ZSBjYW4gaGF2ZSBzZWN1cmUgMC1SVFQgcmVzdW1wdGlvbi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmlsbDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_BLUPR03MB13961CA8EF0DE7D342ADDDC78C810BLUPR03MB1396namp_-- From nobody Wed Mar 23 12:50:13 2016 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 7F24912D860 for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 12:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 NrsYzWnp17be for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 12:50:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0119.outbound.protection.outlook.com [207.46.100.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A97F12D85A for <unbearable@ietf.org>; Wed, 23 Mar 2016 12:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UH7rqXe1uyKI2vjS4OqWcA3E/9VcsfdP36aROtKGOzE=; b=dYNtcMiQAvf+Uibwt6noY0NNRe9V478lOzYUs7nZ9JlFnnKKH7yEobX3mb11fLPJRgeIPeUCLEqcd+oaY6NpA8KCYsJkI+1Xjr8v9jiNm5Y1hdC0cAcvufUBomEXlw6IxJ6oxb+b7cu5lKGt1S1voHsr9yRDFSHXLVjVPblXTMI= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 23 Mar 2016 19:50:05 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0434.021; Wed, 23 Mar 2016 19:50:05 +0000 From: Andrei Popov <Andrei.Popov@microsoft.com> To: Bill Cox <waywardgeek@google.com>, Nick Harper <nharper@google.com> Thread-Topic: [Unbearable] We need a MitM extension Thread-Index: AQHRhQjbyqLX1j9mpk2vEEn9PLwpbZ9nDCqAgAAgVoCAABk0cIAAErUAgAAIQACAAAtzgIAAA0kA Date: Wed, 23 Mar 2016 19:50:05 +0000 Message-ID: <BLUPR03MB13966C99E463B0A3252B9F258C810@BLUPR03MB1396.namprd03.prod.outlook.com> References: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> <56F29F69.1080105@treenet.co.nz> <CAH9QtQHs61xW9P_4TjQq-Jz=QPbVH9aDsYUUZc3fCNScQvcZPw@mail.gmail.com> <BLUPR03MB13964D90AE484B2639F816878C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CAH9QtQG1ObEsxhZO_pUjAp0Tp=dRkSRnm8eV7YSKXS-JZauxQw@mail.gmail.com> <CACdeXiLsw2i+BEv-EUj=5fHBAdFHYaR64191pN6dJo+HGRpocw@mail.gmail.com> <CAH9QtQF64FvtHv8moaJGxYWaZGybA58R6xqiNYmmTZv=PABKSg@mail.gmail.com> In-Reply-To: <CAH9QtQF64FvtHv8moaJGxYWaZGybA58R6xqiNYmmTZv=PABKSg@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:1::1d2] x-ms-office365-filtering-correlation-id: 60c39d97-a8af-4171-455e-08d3535454e7 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:5lrBYVadhHTw+JMRQEXyojv4TghhcLNtTD3ii1CGBBdS+D72YDpOcRVzl3A9aqc6ZosFi9yHwoxp6XPFHtdo0sKpKXNV8X3H9FUeKktbC5+bxMSfYns6zekgoZDXK49zqHfJTsVfPXnMPGmHuM0oCQ==; 24:5dtJbgC1pUTpgsKrw6Uj7gmihOOBqmEVX8ypSb5wWfu7P246rwdcqI61o205cXe/fXOxQ0tnwKBuseT6od8ur8kggHEXzan2TCXJDg8dST4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; x-microsoft-antispam-prvs: <BLUPR03MB1395759F277306D4CF7A1D008C810@BLUPR03MB1395.namprd03.prod.outlook.com> x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 08902E536D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(99286002)(11100500001)(19625215002)(561944003)(50986999)(77096005)(54356999)(76176999)(33656002)(19609705001)(5003600100002)(16236675004)(15975445007)(122556002)(81166005)(19300405004)(86362001)(93886004)(19580395003)(5004730100002)(87936001)(19617315012)(19580405001)(2900100001)(74316001)(6116002)(92566002)(1096002)(1220700001)(2906002)(5005710100001)(76576001)(3660700001)(102836003)(790700001)(5008740100001)(106116001)(10400500002)(189998001)(10290500002)(5002640100001)(10090500001)(5001770100001)(586003)(2950100001)(4326007)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB13966C99E463B0A3252B9F258C810BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2016 19:50:05.4610 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/u85DXxTPXfjhN2Q_VZTViqnbIVw> Cc: Amos Jeffries <squid3@treenet.co.nz>, Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Mar 2016 19:50:11 -0000 --_000_BLUPR03MB13966C99E463B0A3252B9F258C810BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aG91Z2h0IHRoZXJlIHdhcyBhbiBhZGRpdGlvbmFsIHBpZWNlIGluIEJpbGzigJlzIHByb3Bv c2FsOiB0aGUgc2VydmVyIGtub3dzIGFib3V0IHRoZSBzcGVjaWZpYyBNSVRNLCBhdXRoZW50aWNh dGVzIHRoZSBNSVRNLCBhbmQgYXV0aG9yaXplcyB0aGUgdXNlIG9mIGEgdG9rZW4gdGhyb3VnaCB0 aGlzIHBhcnRpY3VsYXIgTUlUTS4gRGlkIEkgZ2V0IHRoaXMgd3Jvbmc/IE90aGVyd2lzZSwgTmlj ayBpcyByaWdodCBhbmQgYSBNSVRNIFRCIGV4dGVuc2lvbiBpcyBub3QgYnV5aW5nIHVzIG11Y2gu DQoNCkZyb206IEJpbGwgQ294IFttYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbV0NClNlbnQ6 IFdlZG5lc2RheSwgTWFyY2ggMjMsIDIwMTYgMTI6MzUgUE0NClRvOiBOaWNrIEhhcnBlciA8bmhh cnBlckBnb29nbGUuY29tPg0KQ2M6IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29m dC5jb20+OyBBbW9zIEplZmZyaWVzIDxzcXVpZDNAdHJlZW5ldC5jby5uej47IFRva2JpbmQgV0cg PHVuYmVhcmFibGVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFdlIG5lZWQg YSBNaXRNIGV4dGVuc2lvbg0KDQpZb3UgYXJlIHJlYWRpbmcgaXQgY29ycmVjdGx5LiAgVGhlIHBh cnRpYWxseSBib3VuZCBjb29raWUgKyBUQiBoZWFkZXIgYmVjb21lIGEgYmVhcmVyIHRva2VuLiAg VGhlcmUgYXJlIHBsYWNlcyBpbiB0aGUgcGlwZWxpbmUgd2hlcmUgb25seSB0aGUgY29va2llIGV4 aXN0cy4NCg0KQmlsbA0KDQpPbiBXZWQsIE1hciAyMywgMjAxNiBhdCAxMTo1NCBBTSwgTmljayBI YXJwZXIgPG5oYXJwZXJAZ29vZ2xlLmNvbTxtYWlsdG86bmhhcnBlckBnb29nbGUuY29tPj4gd3Jv dGU6DQpJJ20gaGF2aW5nIHRyb3VibGUgZmlndXJpbmcgb3V0IGhvdyB0aGlzIHByb3ZpZGVzIGFu eSBtb3JlIHNlY3VyaXR5IHRoYW4gbm90IGRvaW5nIGl0IGF0IGFsbC4gTXkgdW5kZXJzdGFuZGlu ZyBvZiB0aGlzIE1pdE0gcHJvcG9zYWwgaXMgYXMgZm9sbG93czoNCjEuIENsaWVudCBlc3RhYmxp c2hlcyAoZGlyZWN0KSBjb25uZWN0aW9uIHRvIHNlcnZlciB3aXRoIFRCSUQxOyBzZXJ2ZXIgcmVw bGllcyB3aXRoIGNvb2tpZSBDMSBib3VuZCB0byBUQklEMQ0KMi4gVXNlciBjaGFuZ2VzIG5ldHdv cmtzLCBhbmQgaXMgbm93IGJlaGluZCBhIE1pdE0NCjMuIENsaWVudCBjb25uZWN0cyB0byBzZXJ2 ZXIgKHRocnUgTWl0TSksIHRyaWVzIChhbmQgZmFpbHMpIHRvIG5lZ290aWF0ZSBUQiBpbiBUTFMg aGFuZHNoYWtlLg0KNC4gQ2xpZW50IHNlbmRzIFNlYy1Ub2tlbi1CaW5kaW5nIGhlYWRlciBhbnl3 YXlzLCB3aXRoIE1pdE0gZXh0ZW5zaW9uLCBhbmQgVEJJRDEuIENsaWVudCBhbHNvIHNlbmRzIGNv b2tpZSBDMS4NCjUuIFNlcnZlciBoYXMgdXNlciByZS1hdXRoLCBhbmQgaXNzdWVzIG5ldyBjb29r aWUgQzIgdGhhdCBpcyBoYWxmLWJvdW5kIHRvIFRCSUQxIChpLmUuIHRoZSBzZXJ2ZXIgZWl0aGVy IGV4cGVjdHMgaXQgdG8gYmUgYm91bmQgdG8gVEJJRDEsIG9yIHRvIHNlZSB0aGUgdG9rZW4gYmlu ZGluZyBtZXNzYWdlIHdpdGggdGhlIE1pdE0gZXh0ZW5zaW9uIHdpdGggVEJJRDEpDQo2LiBDbGll bnQgY2FuIHVzZSBDMiB3aXRoIFRCSUQxIHdpdGggb3Igd2l0aG91dCBNaXRNIGV4dGVuc2lvbiB0 byBhdXRoZW50aWNhdGUgdG8gdGhlIHNlcnZlci4NCg0KSW4gc3RlcHMgNSBhbmQgNiwgQzIgcGx1 cyB0aGUgdmFsdWUgb2YgdGhlIFNlYy1Ub2tlbi1CaW5kaW5nIGhlYWRlciBlZmZlY3RpdmVseSBi ZWNvbWVzIGEgYmVhcmVyIHRva2VuLg0KDQpJZiB3ZSBkb24ndCBkbyBhbnkgc29ydCBvZiBNaXRN IGV4dGVuc2lvbiwgc3RlcHMgMSB0aHJ1IDMgc3RheSB0aGUgc2FtZS4gSW4gc3RlcCA0LCB0aGUg Y2xpZW50IGRvZXNuJ3Qgc2VuZCBhIFNlYy1Ub2tlbi1CaW5kaW5nIGhlYWRlciwgYnV0IHN0aWxs IHNlbmRzIGNvb2tpZSBDMS4gU3RlcCA1IHN0aWxsIGhhcyB0aGUgc2VydmVyIGFza2luZyB0aGUg dXNlciB0byByZS1hdXRoLCBidXQgbm93IHRoZSBuZXcgY29va2llIEMyIGlzIHVuYm91bmQuDQoN Ck9uIFdlZCwgTWFyIDIzLCAyMDE2IGF0IDExOjI0IEFNLCBCaWxsIENveCA8d2F5d2FyZGdlZWtA Z29vZ2xlLmNvbTxtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KT24gV2Vk LCBNYXIgMjMsIDIwMTYgYXQgMTA6NDEgQU0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1p Y3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpF eHRlbmRpbmcgYSBNSVRNLWRlZmVhdGluZyBmZWF0dXJlIHRvIHN1cHBvcnQg4oCcbGVnaXRpbWF0 ZeKAnSBNSVRNIG1ha2VzIG1lIHNhZC4NCg0KTWUsIHRvby4uLg0KDQpJIHRoaW5rIHRoZXJlIGFy ZSBhdCBsZWFzdCB0d28gZGlmZmVyZW50IGNhc2VzIGhlcmU6IHNlcnZlcnMgdGhhdCBhcmUgYXNz b2NpYXRlZCB3aXRoIHRoZSBNSVRNIGFuZCBzZXJ2ZXJzIHRoYXQgYXJlbuKAmXQuIFRoZSBmb3Jt ZXIgY2FuIHByb2JhYmx5IHVzZSB0aGUgc2NoZW1lIHRoYXQgQW1vcyBkZXNjcmliZWQsIGF2b2lk aW5nIHRoZSBuZWVkIGZvciB0aGUgZXh0ZW5zaW9uLiBUaGUgbGF0dGVyIGNvdWxkIGlzc3VlIGxl c3MgcHJpdmlsZWdlZC9zaG9ydC10aW1lIGJlYXJlciB0b2tlbnMgd2hlbiBUQiBpcyBub3QgdXNl ZCBhbmQgbW9yZSBwcml2aWxlZ2VkL2xvbmdlci10ZXJtIGJvdW5kIHRva2VucyB3aGVuIFRCIGlz IG5lZ290aWF0ZWQuIEJpbGwsIGRvIHlvdSB0aGluayB0aGlzIHdvdWxkIHdvcmsgZm9yIHlvdT8N Cg0KVGhhdCBpcyB0aGUgY3VycmVudCBkZWZhdWx0IHBsYW4sIEkgdGhpbmsuICBUaGUgbmV3IGF1 dGggdG9rZW4gd291bGQgYXV0aG9yaXplIG5vbi1UQi1lbmFibGVkIGFjY2VzcyBmb3IgYSB3aGls ZSwgYW5kIFRCLWVuYWJsZWQgYWNjZXNzIGZvciBsb25nZXIuICBUaGlzIGlzIGEgYml0IGxlc3Mg c2VjdXJlLCBzaW5jZSB0aGUgYXV0aCB0b2tlbiBjYW4gYmUgdXNlZCBmcm9tIGFueXdoZXJlLCBu b3QganVzdCBiZWhpbmQgdGhlIHNwZWNpZmljIE1pdE0uDQoNCkJpbGwNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClVuYmVhcmFibGUgbWFpbGluZyBs aXN0DQpVbmJlYXJhYmxlQGlldGYub3JnPG1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlDQoNCg0K --_000_BLUPR03MB13966C99E463B0A3252B9F258C810BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSB0aG91Z2h0IHRoZXJlIHdhcyBhbiBh ZGRpdGlvbmFsIHBpZWNlIGluIEJpbGzigJlzIHByb3Bvc2FsOiB0aGUgc2VydmVyIGtub3dzIGFi b3V0IHRoZSBzcGVjaWZpYyBNSVRNLCBhdXRoZW50aWNhdGVzIHRoZSBNSVRNLCBhbmQgYXV0aG9y aXplcyB0aGUgdXNlIG9mIGEgdG9rZW4NCiB0aHJvdWdoIHRoaXMgcGFydGljdWxhciBNSVRNLiBE aWQgSSBnZXQgdGhpcyB3cm9uZz8gT3RoZXJ3aXNlLCBOaWNrIGlzIHJpZ2h0IGFuZCBhIE1JVE0g VEIgZXh0ZW5zaW9uIGlzIG5vdCBidXlpbmcgdXMgbXVjaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQmlsbCBDb3ggW21h aWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2Rh eSwgTWFyY2ggMjMsIDIwMTYgMTI6MzUgUE08YnI+DQo8Yj5Ubzo8L2I+IE5pY2sgSGFycGVyICZs dDtuaGFycGVyQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBBbmRyZWkgUG9wb3YgJmx0 O0FuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tJmd0OzsgQW1vcyBKZWZmcmllcyAmbHQ7c3F1aWQz QHRyZWVuZXQuY28ubnomZ3Q7OyBUb2tiaW5kIFdHICZsdDt1bmJlYXJhYmxlQGlldGYub3JnJmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFibGVdIFdlIG5lZWQgYSBNaXRNIGV4 dGVuc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBhcmUgcmVh ZGluZyBpdCBjb3JyZWN0bHkuJm5ic3A7IFRoZSBwYXJ0aWFsbHkgYm91bmQgY29va2llICYjNDM7 IFRCIGhlYWRlciBiZWNvbWUgYSBiZWFyZXIgdG9rZW4uJm5ic3A7IFRoZXJlIGFyZSBwbGFjZXMg aW4gdGhlIHBpcGVsaW5lIHdoZXJlIG9ubHkgdGhlIGNvb2tpZSBleGlzdHMuPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CaWxsPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTWFyIDIzLCAyMDE2IGF0IDExOjU0 IEFNLCBOaWNrIEhhcnBlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPm5oYXJwZXJAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gaGF2 aW5nIHRyb3VibGUgZmlndXJpbmcgb3V0IGhvdyB0aGlzIHByb3ZpZGVzIGFueSBtb3JlIHNlY3Vy aXR5IHRoYW4gbm90IGRvaW5nIGl0IGF0IGFsbC4gTXkgdW5kZXJzdGFuZGluZyBvZiB0aGlzIE1p dE0gcHJvcG9zYWwgaXMgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4xLiBDbGllbnQgZXN0YWJsaXNoZXMgKGRpcmVjdCkgY29ubmVjdGlvbiB0 byBzZXJ2ZXIgd2l0aCBUQklEMTsgc2VydmVyIHJlcGxpZXMgd2l0aCBjb29raWUgQzEgYm91bmQg dG8gVEJJRDE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjIuIFVzZXIgY2hhbmdlcyBuZXR3b3JrcywgYW5kIGlzIG5vdyBiZWhpbmQgYSBNaXRNPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiBDbGll bnQgY29ubmVjdHMgdG8gc2VydmVyICh0aHJ1IE1pdE0pLCB0cmllcyAoYW5kIGZhaWxzKSB0byBu ZWdvdGlhdGUgVEIgaW4gVExTIGhhbmRzaGFrZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQuIENsaWVudCBzZW5kcyBTZWMtVG9rZW4tQmluZGlu ZyBoZWFkZXIgYW55d2F5cywgd2l0aCBNaXRNIGV4dGVuc2lvbiwgYW5kIFRCSUQxLiBDbGllbnQg YWxzbyBzZW5kcyBjb29raWUgQzEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj41LiBTZXJ2ZXIgaGFzIHVzZXIgcmUtYXV0aCwgYW5kIGlzc3VlcyBu ZXcgY29va2llIEMyIHRoYXQgaXMgaGFsZi1ib3VuZCB0byBUQklEMSAoaS5lLiB0aGUgc2VydmVy IGVpdGhlciBleHBlY3RzIGl0IHRvIGJlIGJvdW5kIHRvIFRCSUQxLCBvciB0byBzZWUgdGhlIHRv a2VuIGJpbmRpbmcgbWVzc2FnZSB3aXRoIHRoZSBNaXRNIGV4dGVuc2lvbiB3aXRoIFRCSUQxKTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Ni4gQ2xp ZW50IGNhbiB1c2UgQzIgd2l0aCBUQklEMSB3aXRoIG9yIHdpdGhvdXQgTWl0TSBleHRlbnNpb24g dG8gYXV0aGVudGljYXRlIHRvIHRoZSBzZXJ2ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHN0ZXBzIDUgYW5kIDYsIEMyIHBsdXMgdGhl IHZhbHVlIG9mIHRoZSBTZWMtVG9rZW4tQmluZGluZyBoZWFkZXIgZWZmZWN0aXZlbHkgYmVjb21l cyBhIGJlYXJlciB0b2tlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SWYgd2UgZG9uJ3QgZG8gYW55IHNvcnQgb2YgTWl0TSBleHRlbnNpb24s IHN0ZXBzIDEgdGhydSAzIHN0YXkgdGhlIHNhbWUuIEluIHN0ZXAgNCwgdGhlIGNsaWVudCBkb2Vz bid0IHNlbmQgYSBTZWMtVG9rZW4tQmluZGluZyBoZWFkZXIsIGJ1dCBzdGlsbCBzZW5kcyBjb29r aWUgQzEuIFN0ZXAgNSBzdGlsbCBoYXMgdGhlIHNlcnZlciBhc2tpbmcgdGhlIHVzZXIgdG8gcmUt YXV0aCwgYnV0IG5vdyB0aGUgbmV3IGNvb2tpZQ0KIEMyIGlzIHVuYm91bmQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gV2VkLCBNYXIgMjMsIDIwMTYgYXQgMTE6MjQgQU0sIEJpbGwgQ294ICZsdDs8YSBocmVmPSJt YWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndheXdhcmRnZWVr QGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1hciAyMywgMjAxNiBhdCAxMDo0MSBBTSwgQW5kcmVpIFBv cG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20iIHRhcmdl dD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RXh0ZW5kaW5nIGEgTUlUTS1kZWZl YXRpbmcgZmVhdHVyZSB0byBzdXBwb3J0IOKAnGxlZ2l0aW1hdGXigJ0gTUlUTSBtYWtlcyBtZSBz YWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1lLCB0b28uLi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoZXJlIGFyZSBhdCBs ZWFzdCB0d28gZGlmZmVyZW50IGNhc2VzIGhlcmU6IHNlcnZlcnMgdGhhdCBhcmUgYXNzb2NpYXRl ZCB3aXRoIHRoZSBNSVRNIGFuZA0KIHNlcnZlcnMgdGhhdCBhcmVu4oCZdC4gVGhlIGZvcm1lciBj YW4gcHJvYmFibHkgdXNlIHRoZSBzY2hlbWUgdGhhdCBBbW9zIGRlc2NyaWJlZCwgYXZvaWRpbmcg dGhlIG5lZWQgZm9yIHRoZSBleHRlbnNpb24uIFRoZSBsYXR0ZXIgY291bGQgaXNzdWUgbGVzcyBw cml2aWxlZ2VkL3Nob3J0LXRpbWUgYmVhcmVyIHRva2VucyB3aGVuIFRCIGlzIG5vdCB1c2VkIGFu ZCBtb3JlIHByaXZpbGVnZWQvbG9uZ2VyLXRlcm0gYm91bmQgdG9rZW5zIHdoZW4gVEIgaXMNCiBu ZWdvdGlhdGVkLiBCaWxsLCBkbyB5b3UgdGhpbmsgdGhpcyB3b3VsZCB3b3JrIGZvciB5b3U/PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgaXMgdGhlIGN1cnJlbnQgZGVmYXVsdCBwbGFu LCBJIHRoaW5rLiZuYnNwOyBUaGUgbmV3IGF1dGggdG9rZW4gd291bGQgYXV0aG9yaXplIG5vbi1U Qi1lbmFibGVkIGFjY2VzcyBmb3IgYSB3aGlsZSwgYW5kIFRCLWVuYWJsZWQgYWNjZXNzIGZvciBs b25nZXIuJm5ic3A7IFRoaXMgaXMgYSBiaXQgbGVzcyBzZWN1cmUsIHNpbmNlIHRoZSBhdXRoIHRv a2VuIGNhbiBiZSB1c2VkIGZyb20gYW55d2hlcmUsIG5vdCBqdXN0IGJlaGluZA0KIHRoZSBzcGVj aWZpYyBNaXRNLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojODg4ODg4Ij5CaWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VW5i ZWFyYWJsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlVuYmVhcmFibGVAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJl YXJhYmxlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby91bmJlYXJhYmxlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_BLUPR03MB13966C99E463B0A3252B9F258C810BLUPR03MB1396namp_-- From nobody Wed Mar 23 12:56:08 2016 Return-Path: <waywardgeek@google.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 D662A12D87C for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 12:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 UzjhG8JHVOR6 for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 12:56:04 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C756F12D876 for <unbearable@ietf.org>; Wed, 23 Mar 2016 12:56:03 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id e6so33003400vkh.2 for <unbearable@ietf.org>; Wed, 23 Mar 2016 12:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=T1QMPM1rAV3ijX5aEWrx6IHJhnwRFE9qTPIxZqWhHeU=; b=crfYKQu1il7MujIMxdmUXDs60J0MLHV7WXyMOxzBsW2WVW1qHrJoIsQeUlKqP8FS4R 6mnHhXyijMPiRPRJ22E75kpNGVqA01bEJ4c0t0TlqhssF15g59iR6SpjWRBKUhaVLgDh MZQFZNZXENo5ktXPHyYqN1RppRMbWJtOA5E4OIl2N8LdvP/ZhFpLBHCTrl0fabdp0wPE 24oG3y/vMb4/6FPvvNAV6+sX21JQIq4mZnZHouDDRn5sGkZBAE8CtZ//xu1MHPLfuskI DGyfPd1cI+JQTi+u1W+Lwj+UIL9O2y+V5T3otSA+4jB6RXS7yv+Dp7ERFKO/gTAd1TXz 44zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=T1QMPM1rAV3ijX5aEWrx6IHJhnwRFE9qTPIxZqWhHeU=; b=dcbfKA2Z3EQWMkZXJKvubq3DFJ3tAusRswcOujiVrBLECUPTW0CZdcoGWqQesQ9KpV 82rhHFuIs3Xg+bECOrHDk8VU9MzN81NxzP+z6GqDln9dspyGWbZfWg1X8wLGxGu22Jl0 W8nL6SpX3m7KW76tYnBBih6nY8lkWUOk8350vRNGwHLXq/lKHmG0KrC3BEi803bO1c5/ m+n1E1feds6nW1qBLccr2iNxQaE/3xBWtgNgRN/N4rYOXJojAxIHY1/W+6h8M/+dBm7u UV2r61u3s29iaV+qiaCaoDfsfZvWg0l+R2fc2gOZlBhtc6RftrGkUm6NddhLncYPalNZ pbtA== X-Gm-Message-State: AD7BkJKVbpDJBRWrLb3m9uYoDaGKXuoDOaWA9VBDV4pnHWnyUM3QbpPFetZcy6teyEkVgGcAVysnSrlDBTXCQcPw MIME-Version: 1.0 X-Received: by 10.31.150.215 with SMTP id y206mr2468076vkd.63.1458762962721; Wed, 23 Mar 2016 12:56:02 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Wed, 23 Mar 2016 12:56:02 -0700 (PDT) In-Reply-To: <BLUPR03MB13966C99E463B0A3252B9F258C810@BLUPR03MB1396.namprd03.prod.outlook.com> References: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> <56F29F69.1080105@treenet.co.nz> <CAH9QtQHs61xW9P_4TjQq-Jz=QPbVH9aDsYUUZc3fCNScQvcZPw@mail.gmail.com> <BLUPR03MB13964D90AE484B2639F816878C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CAH9QtQG1ObEsxhZO_pUjAp0Tp=dRkSRnm8eV7YSKXS-JZauxQw@mail.gmail.com> <CACdeXiLsw2i+BEv-EUj=5fHBAdFHYaR64191pN6dJo+HGRpocw@mail.gmail.com> <CAH9QtQF64FvtHv8moaJGxYWaZGybA58R6xqiNYmmTZv=PABKSg@mail.gmail.com> <BLUPR03MB13966C99E463B0A3252B9F258C810@BLUPR03MB1396.namprd03.prod.outlook.com> Date: Wed, 23 Mar 2016 12:56:02 -0700 Message-ID: <CAH9QtQGbO8p0XcqaQmuA94Xojn-XB4KKd1vqX7VquEovq86GXw@mail.gmail.com> From: Bill Cox <waywardgeek@google.com> To: Andrei Popov <Andrei.Popov@microsoft.com> Content-Type: multipart/alternative; boundary=001a1140fdd834a8d3052ebcb88e Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/UGO_lBpqCdx8Cr2fohJ2iPvVtBk> Cc: Amos Jeffries <squid3@treenet.co.nz>, Tokbind WG <unbearable@ietf.org>, Nick Harper <nharper@google.com> Subject: Re: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Mar 2016 19:56:07 -0000 --001a1140fdd834a8d3052ebcb88e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 23, 2016 at 12:50 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote: > I thought there was an additional piece in Bill=E2=80=99s proposal: the s= erver > knows about the specific MITM, authenticates the MITM, and authorizes the > use of a token through this particular MITM. Did I get this wrong? > Otherwise, Nick is right and a MITM TB extension is not buying us much. > By itself, the extension would not buy much. I think I'm OK with just issuing authorizing non-TB access for a shorter time. Nick is correct that given the cookie and also a plain-text version of the TB header with MitM extension, an attacker can authenticate without being behind the MitM. This isn't quite as bad as an unbound auth token, but it does not buy a lot of protection. Bill --001a1140fdd834a8d3052ebcb88e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W= ed, Mar 23, 2016 at 12:50 PM, Andrei Popov <span dir=3D"ltr"><<a href=3D= "mailto:Andrei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov@microsof= t.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri",sans-serif;color:#1f497d">I thought there was an additional pie= ce in Bill=E2=80=99s proposal: the server knows about the specific MITM, au= thenticates the MITM, and authorizes the use of a token through this particular MITM. Did I get this wrong? Otherwise, Nick is rig= ht and a MITM TB extension is not buying us much.</span></p></div></div></b= lockquote><div><br></div><div>By itself, the extension would not buy much.= =C2=A0 I think I'm OK with just issuing authorizing non-TB access for a= shorter time.</div><div><br></div><div>Nick is correct that given the cook= ie and also a plain-text version of the TB header with MitM extension, an a= ttacker can authenticate without being behind the MitM.=C2=A0 This isn'= t quite as bad as an unbound auth token, but it does not buy a lot of prote= ction.</div><div><br></div><div>Bill=C2=A0</div></div></div></div> --001a1140fdd834a8d3052ebcb88e-- From nobody Wed Mar 23 13:24:21 2016 Return-Path: <stephen.farrell@cs.tcd.ie> 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 2E0FC12D8A3 for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 13:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 xFyHM0RosgRo for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 13:24:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57A612D74A for <unbearable@ietf.org>; Wed, 23 Mar 2016 13:24:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9FFB1BE35; Wed, 23 Mar 2016 20:24:16 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SstMdCPtuuj; Wed, 23 Mar 2016 20:24:15 +0000 (GMT) Received: from [10.1.0.167] (host-160-196-68-109.arq1.ldn.uk.sharedband.net [109.68.196.160]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4C077BE33; Wed, 23 Mar 2016 20:24:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458764655; bh=xHp7WXJw4OnGSQcMA5A1AfyXypdjsuPVUJSc69rnJZ0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=gGxz5Rygk3SP8Uc1R8qjLAKnuj0y/P4SVxoBpWSeFj1eVDouTSS7DE2+wC6GOQFUk lOtM7Q4lI0Q3NFgG6R7N+j8sZ3z/OIpaTVpXTyvDNLP0JUYkOW2ZBbajeq2BP98lzZ flKvprMmKWcMebY6+rf0GD5mcZwCqKZL9OBDFMEU= To: Bill Cox <waywardgeek@google.com>, Andrei Popov <Andrei.Popov@microsoft.com> References: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> <56F29F69.1080105@treenet.co.nz> <CAH9QtQHs61xW9P_4TjQq-Jz=QPbVH9aDsYUUZc3fCNScQvcZPw@mail.gmail.com> <BLUPR03MB13964D90AE484B2639F816878C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CAH9QtQG1ObEsxhZO_pUjAp0Tp=dRkSRnm8eV7YSKXS-JZauxQw@mail.gmail.com> <CACdeXiLsw2i+BEv-EUj=5fHBAdFHYaR64191pN6dJo+HGRpocw@mail.gmail.com> <CAH9QtQF64FvtHv8moaJGxYWaZGybA58R6xqiNYmmTZv=PABKSg@mail.gmail.com> <BLUPR03MB13966C99E463B0A3252B9F258C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CAH9QtQGbO8p0XcqaQmuA94Xojn-XB4KKd1vqX7VquEovq86GXw@mail.gmail.com> From: Stephen Farrell <stephen.farrell@cs.tcd.ie> Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56F2FB6D.9090908@cs.tcd.ie> Date: Wed, 23 Mar 2016 20:24:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <CAH9QtQGbO8p0XcqaQmuA94Xojn-XB4KKd1vqX7VquEovq86GXw@mail.gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090401040408010807020803" Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/sf5Hcap7j801EfeCzR3bIJ1SA8U> Cc: Amos Jeffries <squid3@treenet.co.nz>, Tokbind WG <unbearable@ietf.org>, Nick Harper <nharper@google.com> Subject: Re: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Mar 2016 20:24:20 -0000 This is a cryptographically signed message in MIME format. --------------ms090401040408010807020803 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 23/03/16 19:56, Bill Cox wrote: > On Wed, Mar 23, 2016 at 12:50 PM, Andrei Popov <Andrei.Popov@microsoft.= com> > wrote: >=20 >> I thought there was an additional piece in Bill=E2=80=99s proposal: th= e server >> knows about the specific MITM, authenticates the MITM, and authorizes = the >> use of a token through this particular MITM. Did I get this wrong? >> Otherwise, Nick is right and a MITM TB extension is not buying us much= =2E >> >=20 > By itself, the extension would not buy much. I think I'm OK with just > issuing authorizing non-TB access for a shorter time. >=20 > Nick is correct that given the cookie and also a plain-text version of = the > TB header with MitM extension, an attacker can authenticate without bei= ng > behind the MitM. This isn't quite as bad as an unbound auth token, but= it > does not buy a lot of protection. (no hats, but with an openly-declared bias I've publicly stated many times now;-) I don't see how there's any real scenario where any browser or server can "authenticate" an HTTP MitM as being an HTTP MieM, whether or not that is supposedly legitimate. So I'm very confused by the above. Bill - can you re-state the security and privacy benefits of what you're proposing? Maybe phrasing it differently will help but I'm just not seeing how anyone benefits from basically pretending to not notice a MitM. Wouldn't doing so really call into question the whole point of TB and put us back to to where the name of this list becomes relevant? Ta, S. >=20 > Bill >=20 >=20 >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable >=20 --------------ms090401040408010807020803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMjMy MDI0MTNaMC8GCSqGSIb3DQEJBDEiBCDJbHPv8GWDhWsn6ywkQH464Plcn5JvaInD/kLGvMlb TzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBMbPZeVji9rcXIzvSfG9PpOXJ5siisGQQskobP9fqIM1wFGQjnNjFV Csr+VRAkPuIKgcP9YJ+gHR08zV+5OB7BrXzP4NqrWTHt6VQ8CTi+bv2xQ2s3rtZ0zQLMdofM fGklgXGlI5UiUlUXlfWb4w1pyM4uogOGlF4cLRAPrGzWuU3ONp4KYx0zNrcVaYD6qSThxnqj NuaTr/atAUAPDjzL/Z81Zxg0fua/jH8hVVcNuM9WN11YUtQNQbJA0RQ0NoUCC/CCRF9763g7 blPpMLM+GbtDLWFQYJSJmdEFivzTVvLbTlw4j27xQNTavXqG9y4PbKsP/rxgsTH1nggSCwY4 AAAAAAAA --------------ms090401040408010807020803-- From nobody Wed Mar 23 19:17:27 2016 Return-Path: <waywardgeek@google.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 8E1CC12D555 for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 19:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 JjfOtSzepFcz for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 19:17:25 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E126512D1A3 for <unbearable@ietf.org>; Wed, 23 Mar 2016 19:17:23 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id e6so42239405vkh.2 for <unbearable@ietf.org>; Wed, 23 Mar 2016 19:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=D/JiuhV5oQ30Lz4Kw19qeEpkpD7SSuOKSkniyJFLIE4=; b=aMhSVLFlJd9/jigfo+DVLjGbWYhjlZt9qC9wfP/V0bipov5AibQEKXLTMxIwM91Wiv GhzYIheHTmem6e01XZpVlLXlwM3AYS600WYKVuos2RgIA8E3lWJEFIWSmekdDbkLFmPe 5D0OSCTA2cESkCqwkgl07y4VLYcOeOZeWAcce6EKs5wu4MeRaGof3l8KKDnZUHfzWaEw imajXXXfwBlSIigZHVq1yRJA9Zf+D34wpiY2i7+oadYr+cc+Ls4IIt5PZhuzmjQHe5a5 jr14oeiS7Tama0R1KfUsCUWUFMsF7f3tQyXFI4ogmH93uhRmskvsNdoO6kpGeH+uWiSc ucUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=D/JiuhV5oQ30Lz4Kw19qeEpkpD7SSuOKSkniyJFLIE4=; b=VAeL0+4csWb1aXOW16+FZOjJITZbgnQ3UUZZ+SZCeTry6YMElmYyn2i/dG8X7GiqGj zxQDhwDo3UJ7hoidTpZPvAMVg0KT3WbTSjreILuAc3jSY5M+bertAgtHtPohklhGvHpU Qkw9SeXoTGWApujQyhgNGwpZv+bK/yRt9GlV397u/OgBTaDSqipgSi1JxLHAECgFqftf 9DcXlJQz8mFpya7+t5hGtduRXn+cdgDxc02Ogm8zWZL3xbBo5KNE02EDCqZqa8ePcFT4 MB+vLR2yys/9c9r37YNTjrw+lSNLPtkBTim5tFhFR7dJdT3uyeI2SDCCz8uryr7CcPwJ GJ0w== X-Gm-Message-State: AD7BkJIQQgWnujYxNuSUCO3AjwKxceL5g/sOIzLW7asSeW0m4vHyn+pbE/HzVjpyB4lz+cE2MWZpvYXmrjjYSumN MIME-Version: 1.0 X-Received: by 10.159.37.242 with SMTP id 105mr3233692uaf.27.1458785842436; Wed, 23 Mar 2016 19:17:22 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Wed, 23 Mar 2016 19:17:22 -0700 (PDT) Date: Wed, 23 Mar 2016 19:17:22 -0700 Message-ID: <CAH9QtQH1jcVTf9G4ZQKNFqBHzvOzb+Zepk+J4UynWP3b_hLaiQ@mail.gmail.com> From: Bill Cox <waywardgeek@google.com> To: Tokbind WG <unbearable@ietf.org> Content-Type: multipart/alternative; boundary=001a113ac86af16567052ec20b5f Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/9M4NWUQwCbssFxO8Zi5EOV6iTaU> Subject: [Unbearable] Multiplexed connections X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 02:17:26 -0000 --001a113ac86af16567052ec20b5f Content-Type: text/plain; charset=UTF-8 Both SPDY and QUIC protocols used by Google multiplex multiple HTTP streams over one connection to reduce handshake latency. QUIC is really awesome at this, and will significantly improve speed generally, I think. What happens when a user talks to 2 or more eTLD+1 sites over a multiplexed connection? There is only one chance to negotiate TB key parameters, and it is possible that the key types for requests multiplexed over the same connection will be different. Even scarier, although I think we simply have to agree this is beyond what we can deal with: are there proxies out there that send multiple user streams multiplexed over one connection to popular sites? Bill --001a113ac86af16567052ec20b5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Both SPDY and QUIC protocols used by Google multiplex mult= iple HTTP streams over one connection to reduce handshake latency.=C2=A0 QU= IC is really awesome at this, and will significantly improve speed generall= y, I think.<div><br></div><div>What happens when a user talks to 2 or more = eTLD+1 sites over a multiplexed connection?=C2=A0 There is only one chance = to negotiate TB key parameters, and it is possible that the key types for r= equests multiplexed over the same connection will be different.</div><div><= br></div><div>Even scarier, although I think we simply have to agree this i= s beyond what we can deal with: are there proxies out there that send multi= ple user streams multiplexed over one connection to popular sites?</div><di= v><br></div><div>Bill</div></div> --001a113ac86af16567052ec20b5f-- From nobody Wed Mar 23 23:06:55 2016 Return-Path: <martin.thomson@gmail.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 7928712D159 for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 23:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1BsT0CjoCGai for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 23:06:51 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C034B12D14B for <unbearable@ietf.org>; Wed, 23 Mar 2016 23:06:51 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id c63so79026808iof.0 for <unbearable@ietf.org>; Wed, 23 Mar 2016 23:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=v3XPYBoKiQCanxgy9pOt2FzW4+yR3u01tkmqZmz+B8c=; b=nS6LKsB1bOeYG0cgWzJh2q4LlR34tm+XHRScL2Na4uRTtyweR3a6qfNEH0+yOJ/0Pw vOlGjJ6F2zNa3kZbLzpUCcp6RrKJnSeiCzXaWnYmNyzhddjV6pFZcyX7ajva2Lees3Te cUT/zzu2TR4HFiS9Lcq2gjzVRc9AP32odiP3/h7LWZNHDyeXxYJyhYywjm3oq39Rq1dX x7l9zs1VoDaINsAEw8FrkihFGLLBocUzBru5eQZOnkUvpsoJkSx2luctjel9MkRLdyYD 2s2EbF5/WDGzV/S8krcTWUa+NuKHagSMB0KyMzKsMAQeJ4yWTgBQC5vknbA4Ky7jQ2SX 4HWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=v3XPYBoKiQCanxgy9pOt2FzW4+yR3u01tkmqZmz+B8c=; b=MLbX2lRuICBLafm+N2U5M3NTtMCAbFAwTdFd7ZUV5BfCD3Qs7FfdDJio+qHhfLxFU8 7gqELIxJ5BENHM+2vmWNxSMfj8PjlddhcNes4B7hNfkh8lIhOOQMqYqYFZDeJyo6uQZY 30qiTuLF+MvXWeLj4gyTkMdhS49dO7yHIvN2ApJRTPygehn/2VCidA0LRoc/Ju0l+SVL BEHYopEIHbJmh136ajsb127kSvLj3NF8XUYKLXsVoUAGidWK41tlSUMrvSfhmTwlKRPZ cwJPi0fq5Y+8P58v8lcNi13Lr9ZMFCLUbqvqqaR5kN5sVORVxOCb4s0cnu+QZHD0iSyD J04w== X-Gm-Message-State: AD7BkJJuzNCDHb5NvF9TjMZqqvoF9EcJ7mefd3KAIos10xqwQJ3JmaRFSJ/+dZ8gYhkhoyQtOhlOTkn7QpmpQg== MIME-Version: 1.0 X-Received: by 10.107.137.100 with SMTP id l97mr7427530iod.100.1458799611035; Wed, 23 Mar 2016 23:06:51 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Wed, 23 Mar 2016 23:06:50 -0700 (PDT) In-Reply-To: <BLUPR03MB13961CA8EF0DE7D342ADDDC78C810@BLUPR03MB1396.namprd03.prod.outlook.com> References: <CAH9QtQFLWGLgKGkD8BeuEsGAaumuqzheBgaiuOHKuUvZucuRWw@mail.gmail.com> <BLUPR03MB139616608F68A44A25D7A6758C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CAH9QtQFFppvqu42B_TuKDfO_6pMkTCBtzhDWbTh+PVfyPVGGyw@mail.gmail.com> <BLUPR03MB13961CA8EF0DE7D342ADDDC78C810@BLUPR03MB1396.namprd03.prod.outlook.com> Date: Thu, 24 Mar 2016 17:06:50 +1100 Message-ID: <CABkgnnW2v2cK-FRm59c5x3b3pWq6Lbbfvv65oSo2VjY9xdPYiQ@mail.gmail.com> From: Martin Thomson <martin.thomson@gmail.com> To: Andrei Popov <Andrei.Popov@microsoft.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/Gf0c7VQZJHFbjbXTicr0LLo6UcM> Cc: Tokbind WG <unbearable@ietf.org>, Bill Cox <waywardgeek@google.com> Subject: Re: [Unbearable] Thoughts on TLS 0-RTT 1.3 compatibility X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 06:06:53 -0000 On 24 March 2016 at 06:37, Andrei Popov <Andrei.Popov@microsoft.com> wrote: > =C3=98 I would prefer that we start thinking in terms of protecting all = secrets > rather than just a few private keys. If we secure the secrets, we can ha= ve > secure 0-RTT resumption. > > > > Yes, I agree with this. For TLS 1.3, this could be our way to enable TB w= ith > 0-RTT, at least where the hardware allows secure storage of TLS secrets (= and > not just TB private keys). I think that I disagree. A token binding key has an opportunity to be much better protected than whatever is used for resumption (which, accordingly, has a much shorter lifetime). I don't have an answer for the 0-RTT aspects of this. I suspect that the right answer is to not send any token binding proofs until the handshake is complete, but I can appreciate how that might make people sad. From nobody Wed Mar 23 23:09:01 2016 Return-Path: <martin.thomson@gmail.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 50CF212D159 for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 23:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 4RP3RziGum3P for <unbearable@ietfa.amsl.com>; Wed, 23 Mar 2016 23:08:58 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D1F12D14B for <unbearable@ietf.org>; Wed, 23 Mar 2016 23:08:58 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id v187so46108015ioe.2 for <unbearable@ietf.org>; Wed, 23 Mar 2016 23:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=XLKkZ5Wdg3RLPiq6Wz3B5alJIrw4gT3L+LutwNIKY9Q=; b=sC79G96NC9vsBP0hF1mJ8XaFTCWKIcyH22wDCigojrBIZD/Zbsp1IFqoxhLjlbv2eS jE/7z9hAkgGe/SwdwKdVtUzOGbJKdv0e7e8bJ4M+QSfYi2idVghKzs6gEhuymq82N7hB zEWb5uv9Cxj8Fbk9eSH/hZLxrzmRPL0nGRowJAhXiG+b2+gXidMCX1SCaGZOX/0BTxcZ /qTGANCQzRJeDF16c4+k2Xg3/zWgR67aJUb3YUdSjT/cAso7f0Nvj7mB3HP1TFHjvb01 pBWySMDC+TWfs28rOd5J/XGLny+onEl25PExNuOxJ8QfpVTTYvfQqx2HdarVOu6yarnd KPbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=XLKkZ5Wdg3RLPiq6Wz3B5alJIrw4gT3L+LutwNIKY9Q=; b=Pv160fptQGQYnNbOEAj1SXq+7vD7FrHCiKghBzPWGubhJ0SVGguGKTvCLVuK4LAYfX rTj1rZ1MT7MNuLUhTmHdSFmD8NSxcbG78aZCYPVIDSGlTixdNA2u2PRyVHMJhkio2EPV EWXmJs59W8P6OSZD/2IDmqUsVIP1lvxJ6N0TjIwxHBqupuem4Nb6H00o55KUJq9Nwq4G SDXuaQHDl9DG5UB2Dh/3iFB6iaOqg9ARvPa6WCp9xiXJ0rLGsM2sAPArJ6Rr7waZdSiR HRqjCpGZU8CbS/xc0BVLnd0ru5FcHCKrUbTCU2RMOh+5bxw/NM09YSs9OnwAEqzGs27b CnvQ== X-Gm-Message-State: AD7BkJLYccvonX5XJLnxPk93aCPr3raEG4JZ+Ia69cKDxXo48mNLmCA3XPlNLZIigonK2qRq6Xvaah0zgOEVnA== MIME-Version: 1.0 X-Received: by 10.107.131.105 with SMTP id f102mr7798054iod.190.1458799738129; Wed, 23 Mar 2016 23:08:58 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Wed, 23 Mar 2016 23:08:58 -0700 (PDT) In-Reply-To: <BLUPR03MB13964D90AE484B2639F816878C810@BLUPR03MB1396.namprd03.prod.outlook.com> References: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> <56F29F69.1080105@treenet.co.nz> <CAH9QtQHs61xW9P_4TjQq-Jz=QPbVH9aDsYUUZc3fCNScQvcZPw@mail.gmail.com> <BLUPR03MB13964D90AE484B2639F816878C810@BLUPR03MB1396.namprd03.prod.outlook.com> Date: Thu, 24 Mar 2016 17:08:58 +1100 Message-ID: <CABkgnnWo5rriOpMzxsf=Yt1RFporTQJr5uMJ4QZ1Bhvhf93wRQ@mail.gmail.com> From: Martin Thomson <martin.thomson@gmail.com> To: Andrei Popov <Andrei.Popov@microsoft.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/TlPOzsOiTAN2usGMZUZbS2J91_M> Cc: Amos Jeffries <squid3@treenet.co.nz>, Tokbind WG <unbearable@ietf.org>, Bill Cox <waywardgeek@google.com> Subject: Re: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 06:09:00 -0000 On 24 March 2016 at 04:41, Andrei Popov <Andrei.Popov@microsoft.com> wrote: > Extending a MITM-defeating feature to support =E2=80=9Clegitimate=E2=80= =9D MITM makes me > sad. I know that Stephen has said it, but I think that it behooves me to +1 this. I'm opposed to "fixing" this "problem". From nobody Thu Mar 24 01:09:28 2016 Return-Path: <leifj@sunet.se> 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 4D3A012D5B3 for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 01:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sunet.se 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 2qVQRR3QP6Fg for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 01:09:23 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 B1AA212D0C6 for <unbearable@ietf.org>; Thu, 24 Mar 2016 01:09:22 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id u2O89JLU029659 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <unbearable@ietf.org>; Thu, 24 Mar 2016 09:09:19 +0100 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id u2O89G3j020207 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for <unbearable@ietf.org>; Thu, 24 Mar 2016 09:09:18 +0100 (CET) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1458806958; bh=/BofdU3SOLCPkLq/KtHIKXWWq3Z6A4H+IKpSKlpvAgo=; h=Subject:To:References:From:Date:In-Reply-To; b=M0OXvCeIDIn5yOOpQZXPJYiKKRtSY4nssGkArNUJO91N4zY1zgLbwG/1SuMfnMudV +4Jj4NB2eo8l6cdp7raDxi7rF2QzENXpspHK8uJ5Iz2996nvdl7GOyXiYLIDKNMxiQ /9nKL7CyUWOvXoLr5Fk1WcGDWXzrNIhOabi3a8sM= X-Footer: c3VuZXQuc2U= Received: from [193.10.0.92] ([193.10.0.92]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 9.0.1) with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)) for unbearable@ietf.org; Thu, 24 Mar 2016 09:09:13 +0100 To: unbearable@ietf.org References: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> <56F29F69.1080105@treenet.co.nz> <CAH9QtQHs61xW9P_4TjQq-Jz=QPbVH9aDsYUUZc3fCNScQvcZPw@mail.gmail.com> <BLUPR03MB13964D90AE484B2639F816878C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CABkgnnWo5rriOpMzxsf=Yt1RFporTQJr5uMJ4QZ1Bhvhf93wRQ@mail.gmail.com> From: Leif Johansson <leifj@sunet.se> Message-ID: <56F3A0A9.7000008@sunet.se> Date: Thu, 24 Mar 2016 09:09:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <CABkgnnWo5rriOpMzxsf=Yt1RFporTQJr5uMJ4QZ1Bhvhf93wRQ@mail.gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09QxI9jir - 025c1773c58a - 20160324 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=<leifj@sunet.se>; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/7QczqwjLJG-xexTS9Fxspm8FKPc> Subject: Re: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 08:09:26 -0000 On 2016-03-24 07:08, Martin Thomson wrote: > On 24 March 2016 at 04:41, Andrei Popov <Andrei.Popov@microsoft.com> wrote: >> Extending a MITM-defeating feature to support “legitimate” MITM makes me >> sad. > > I know that Stephen has said it, but I think that it behooves me to +1 > this. I'm opposed to "fixing" this "problem". Reading the thread (as chair) I don't see this proposal getting the level support it needs to have for the WG to spend resources on it. Feel free to disagree but lets also get the rest of the work done. Cheers Leif From nobody Thu Mar 24 01:17:19 2016 Return-Path: <leifj@mnt.se> 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 45AB112D674 for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 01:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.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 Q4VYoIk5-RSZ for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 01:17:16 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1033012D5B3 for <unbearable@ietf.org>; Thu, 24 Mar 2016 01:17:16 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id d82so28717224lfe.3 for <unbearable@ietf.org>; Thu, 24 Mar 2016 01:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=D9FZqbaVlWqfsbduti5x6swwr1ApmEuUcwPNWJiveB4=; b=kJ0zpWV+6hP5gUsKacPTVK+R7n85nW2iiDuca4RC5uvOScv5PVhlY/CQrB3zb/oLUQ jBGk7H5mT0i/Mx3SV3OpQnvkiJ7ZvrO52ZvfzqHETJLhoYHvbiu3ZX0II8u0ERKQoudh uB7iT4W/Cq3xMraTzWff8nbGGdYTzB6VOMWRvKKcUVoyk6NzG8fgoCb5JTH0cQZC3QtS aNb2JLuHVLmOs5L/FvXndhPTpcKa9jXnpK36ue+RatLYfl/DMlNmv4pUeewBcwjpHC/0 Fm6q/BgEvUMkg7WfR5FrEQ3iRxweLAs9j5j87SlH4ZsvAxneIpp1k7VeSPkqDstaEfHH sXwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=D9FZqbaVlWqfsbduti5x6swwr1ApmEuUcwPNWJiveB4=; b=Ea+6U4tcba/XyNqN9H3kUSbyXL99Ef7LwhucUp+UiHm3fBKt15RHmNkCOtTr4G5S0G boFd5LAz34YGIhiCyz+yC2gHwJoN4simplRWnQj01PxKvayGodHUZ0gkiKce6jVWorug v4CZkYsjRvA04cVD8lCqhGwvIgHlRCwbyb2/xQZWC3KWeHNsfL/wGsySfzTPVsElk1Al t5hgLY1qeX+RuuCAUTyc57klukfWvcg+6fCXiJJLRA+njDKM//0+Yz2HIy/51OaqCmp5 o558MKBISznIx7RiCQFVRFUWACqzMg/LumBUOSBxXNVZy09R/3xTalG94qera5ZY1e0B CXvQ== X-Gm-Message-State: AD7BkJKLtPUbkTwEQytwnLvZVI4fjEDJe11BqBC71WgMiGyQ95UU2iOBw0JipsLO26e7sQ== X-Received: by 10.25.65.5 with SMTP id o5mr2954766lfa.12.1458807434273; Thu, 24 Mar 2016 01:17:14 -0700 (PDT) Received: from ?IPv6:2001:6b0:7:1:e81f:3435:79af:bce6? ([2001:6b0:7:1:e81f:3435:79af:bce6]) by smtp.googlemail.com with ESMTPSA id j205sm1008006lfd.0.2016.03.24.01.17.13 for <unbearable@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Mar 2016 01:17:13 -0700 (PDT) To: unbearable@ietf.org References: <56F07A95.4050904@KingsMountain.com> <CADHfa2DzJ4UAvjtUPfp0QfeBnR4HbuVy9VRqO15=x7raRKSLAA@mail.gmail.com> From: Leif Johansson <leifj@mnt.se> Message-ID: <56F3A288.2080504@mnt.se> Date: Thu, 24 Mar 2016 09:17:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <CADHfa2DzJ4UAvjtUPfp0QfeBnR4HbuVy9VRqO15=x7raRKSLAA@mail.gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/rfzmxIBX_xeWfUXBDWa_UQWZVxc> Subject: Re: [Unbearable] Sec- prefix for Token-Binding headers (was: new draft-ietf-tokbind-https-03 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 08:17:18 -0000 On 2016-03-22 04:43, Dirk Balfanz wrote: > Hi Jeff, > > I was told that in Yokohama it was decided to add the Sec- prefix again. > (I wasn't at that meeting.) There was consensus to that effect. From nobody Thu Mar 24 01:32:15 2016 Return-Path: <squid3@treenet.co.nz> 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 807CE12D55B for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 01:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 HontoaC5Fp-l for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 01:32:13 -0700 (PDT) Received: from treenet.co.nz (unknown [121.99.228.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1C20812D107 for <unbearable@ietf.org>; Thu, 24 Mar 2016 01:32:12 -0700 (PDT) Received: from [192.168.20.251] (unknown [121.98.45.158]) by treenet.co.nz (Postfix) with ESMTP id 458AEE6EE5 for <unbearable@ietf.org>; Thu, 24 Mar 2016 20:32:11 +1200 (NZST) To: unbearable@ietf.org References: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> <56F29F69.1080105@treenet.co.nz> <CAH9QtQHs61xW9P_4TjQq-Jz=QPbVH9aDsYUUZc3fCNScQvcZPw@mail.gmail.com> <BLUPR03MB13964D90AE484B2639F816878C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CABkgnnWo5rriOpMzxsf=Yt1RFporTQJr5uMJ4QZ1Bhvhf93wRQ@mail.gmail.com> From: Amos Jeffries <squid3@treenet.co.nz> Message-ID: <56F3A5FD.3060705@treenet.co.nz> Date: Thu, 24 Mar 2016 21:31:57 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <CABkgnnWo5rriOpMzxsf=Yt1RFporTQJr5uMJ4QZ1Bhvhf93wRQ@mail.gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/i5MLq_mjgcMU2eKcbQ23pJSyXrk> Subject: Re: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 08:32:14 -0000 On 24/03/2016 7:08 p.m., Martin Thomson wrote: > On 24 March 2016 at 04:41, Andrei Popov wrote: >> Extending a MITM-defeating feature to support “legitimate” MITM makes me >> sad. > > I know that Stephen has said it, but I think that it behooves me to +1 > this. I'm opposed to "fixing" this "problem". > "Me too" +1 on not lowering this security barrier, however painful. And I'm saying that with my hat on as maintainer of software commonly used as an MITM for TLS traffic. AYJ From nobody Thu Mar 24 01:36:24 2016 Return-Path: <karthikeyan.bhargavan@inria.fr> 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 56DAB12D702 for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 01:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 XU4ioN-W-vJu for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 01:36:14 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4E912D6E9 for <unbearable@ietf.org>; Thu, 24 Mar 2016 01:36:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,384,1454972400"; d="scan'208";a="170551522" Received: from unknown (HELO [128.93.82.51]) ([128.93.82.51]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2016 09:36:12 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr> In-Reply-To: <C656BF88-97E9-4B0C-8482-DC8E2B4AFEBE@gmail.com> Date: Thu, 24 Mar 2016 09:36:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <B3384273-C6C0-4C09-8795-866B1EE288E6@inria.fr> References: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> <56F29F69.1080105@treenet.co.nz> <CAH9QtQHs61xW9P_4TjQq-Jz=QPbVH9aDsYUUZc3fCNScQvcZPw@mail.gmail.com> <BLUPR03MB13964D90AE484B2639F816878C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CABkgnnWo5rriOpMzxsf=Yt1RFporTQJr5uMJ4QZ1Bhvhf93wRQ@mail.gmail.com> <56F3A5FD.3060705@treenet.co.nz> <C656BF88-97E9-4B0C-8482-DC8E2B4AFEBE@gmail.com> To: Amos Jeffries <squid3@treenet.co.nz> X-Mailer: Apple Mail (2.3112) Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/oEPMZTUfhIe71cJepOMihVFdgw8> Cc: unbearable@ietf.org Subject: Re: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 08:36:23 -0000 Is there value in designing a secure protocol =E2=80=9Cextension=E2=80=9D = that plays nice with middle-boxes? How common/important is this problem? (with the researcher hat on) -Karthik > On 24 Mar 2016, at 09:31, Amos Jeffries <squid3@treenet.co.nz> wrote: >=20 > On 24/03/2016 7:08 p.m., Martin Thomson wrote: >> On 24 March 2016 at 04:41, Andrei Popov wrote: >>> Extending a MITM-defeating feature to support =E2=80=9Clegitimate=E2=80= =9D MITM makes me >>> sad. >>=20 >> I know that Stephen has said it, but I think that it behooves me to = +1 >> this. I'm opposed to "fixing" this "problem". >>=20 >=20 > "Me too" +1 on not lowering this security barrier, however painful. >=20 > And I'm saying that with my hat on as maintainer of software commonly > used as an MITM for TLS traffic. >=20 > AYJ >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Thu Mar 24 01:38:56 2016 Return-Path: <ve7jtb@ve7jtb.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 ADD4012D59F for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 01:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.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 YjhjegZkv-7n for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 01:38:53 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656A012D107 for <unbearable@ietf.org>; Thu, 24 Mar 2016 01:38:53 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id u125so3330922wmg.1 for <unbearable@ietf.org>; Thu, 24 Mar 2016 01:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TAaDi05iWdSmUk1E7BLG0F43oDO1b8sHFpONIcUVzGk=; b=l5pMBaoENw8yC/KXP97sAzboHucVZ942CBU4+MsxtKSdRLppzNDVpObaY1jU1gIE55 cuoAG87fNyg1zl3ZCRg39c2Wk5AR82uiagRS7L45bjOpp2XFFpuO86rzLC7UkfNndIFU NA0Mg0tzXHu8sB47P8rAJlO3620/Qe+0MZiqo6Rd7L81CF7bxEUIhSmyatbKcL+DxEdZ Z596c0Ya49JQAHGb3/94Qs9jh1ZMcqn/Aglrk/08TX7HU4RgbVWXeqj+CkJYTTuGv9QW tmavvVqEe4Wn+UtenIcnVcyipRNBo05WAuqAHhxuLQoDtHQqjDTfWK5Uhz+nyqx8VeLj b6SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TAaDi05iWdSmUk1E7BLG0F43oDO1b8sHFpONIcUVzGk=; b=bo8O0VH7PDksFtpqeirSv3TbDQCOo6+7SZJs2+cmtsK/eup+A1PE0UUJLmu406GoF5 yRNV4mRHICdWx5RqHNb2HXiv6yTHw12Lvjs1iMlK3ICmYS0JRvO6hwV+bHbgifb5nNH2 9kZf0owQaomNG+CZQfNqmpq51IWW+ks6zlIjVLuwwqVaWn3gEY6UYLzRzLmtimMhAbQv /7kb+w0jGyANUotWsUN0aVYzTKz63NP0uKYahvoITSyrZajjm0HGnkpe6JKcNq0xZBmm 7v9z9JHSA5KJjX4h2cgW6tah85baiCTxvgU7s9WTlcqdMdzWEgfj0yeOOHoSagbknfaz Cweg== X-Gm-Message-State: AD7BkJKh05XyUtUqDOtHARaZrzm6Mm/LPcAl2piAjjlRKSOLT7RsbgMS7O+gmCVBKZpRyw== X-Received: by 10.28.54.156 with SMTP id y28mr9250985wmh.63.1458808731677; Thu, 24 Mar 2016 01:38:51 -0700 (PDT) Received: from [10.199.1.6] ([46.166.188.212]) by smtp.gmail.com with ESMTPSA id j10sm6250757wjb.46.2016.03.24.01.38.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 24 Mar 2016 01:38:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley <ve7jtb@ve7jtb.com> In-Reply-To: <56F3A0A9.7000008@sunet.se> Date: Thu, 24 Mar 2016 08:38:49 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2661CA8D-EDFB-4830-BC5D-1A31E81502AB@ve7jtb.com> References: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> <56F29F69.1080105@treenet.co.nz> <CAH9QtQHs61xW9P_4TjQq-Jz=QPbVH9aDsYUUZc3fCNScQvcZPw@mail.gmail.com> <BLUPR03MB13964D90AE484B2639F816878C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CABkgnnWo5rriOpMzxsf=Yt1RFporTQJr5uMJ4QZ1Bhvhf93wRQ@mail.gmail.com> <56F3A0A9.7000008@sunet.se> To: Leif Johansson <leifj@sunet.se> X-Mailer: Apple Mail (2.3112) Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/MOeWDqH0pWHEkHpRLvFvt1mG8E4> Cc: unbearable@ietf.org Subject: Re: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 08:38:55 -0000 +1 > On Mar 24, 2016, at 8:09 AM, Leif Johansson <leifj@sunet.se> wrote: >=20 > On 2016-03-24 07:08, Martin Thomson wrote: >> On 24 March 2016 at 04:41, Andrei Popov <Andrei.Popov@microsoft.com> = wrote: >>> Extending a MITM-defeating feature to support =E2=80=9Clegitimate=E2=80= =9D MITM makes me >>> sad. >>=20 >> I know that Stephen has said it, but I think that it behooves me to = +1 >> this. I'm opposed to "fixing" this "problem". >=20 > Reading the thread (as chair) I don't see this proposal getting > the level support it needs to have for the WG to spend resources > on it. >=20 > Feel free to disagree but lets also get the rest of the work done. >=20 > Cheers Leif >=20 >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Thu Mar 24 01:41:57 2016 Return-Path: <ve7jtb@ve7jtb.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 9870A12D14B for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 01:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.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 qJesQGL-gZT4 for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 01:41:53 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776B512D107 for <unbearable@ietf.org>; Thu, 24 Mar 2016 01:41:53 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id u125so3414368wmg.1 for <unbearable@ietf.org>; Thu, 24 Mar 2016 01:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fUWFnOg8DlcAaCEv8m/ExDE32tS/mVQ8YJPgC2OYHRY=; b=zEQtEgJxZleG6DCRmZst/WFlrn3hOehRvYKA+aitdYwwjxt/J1S9cig8Ug2MH+vc/v In67giosRApgjeJ5k23XpGyCS9ySCcQ3rr7l+4sqnwvy1tnjmOhF5k9SJ4svl3mo7eKP 6WGAfJQwndPBV3b9vn8Wxs44r5wR3u104wK8aer3YPaD0VerknDiokvNJKrJF4DOGMKc jF2SokxzbrAgKokYeRRdtiw+7WpjNTJjPrC1QygsZkTkzVRlU3OGKAAhQmF6GCwIYmtN 9eYj77T2Wp6GhfwI05Dg97WICy8oiQFGM0mWUvMv/Xs3REi4Ai9TImoZjg3SqQKOTeX4 8ZTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fUWFnOg8DlcAaCEv8m/ExDE32tS/mVQ8YJPgC2OYHRY=; b=KqEndwmLTV5RQiZkhCmpiQkGnN73k90lvRn9Z1Ir+WJph5aQqZSB6dUUfM22UnYWgu rhQjzWVzRzbP3AhcrtBouuSX2Jd+5TetxAN2vOhJsoHz4SAlpOm3LfxrDlKZpgPY6x0g k5IWddLdWsz+2JSO7+FcGjOV+yK8iir9bsqTxOShSXgk/UH4GOkKnv/kif/jKQiqh51F OHi53u64jQAAX+pY5vmqGUXa8s+GOMuGhnnDowQGdUGoStMfgdW2yM15CT6skOLsLnk4 JK+psJaRRFyOXAEvAhAJPigQXUzRPT0qe7qA8vVAxz46MNmi0pAfHDFWZxddYr2xv4xc eU0A== X-Gm-Message-State: AD7BkJLWucgLxck4GxtSo39YJEAP7P6curPpd9crSUohIwhTiXALTo18oSRiMJP2tSJeYg== X-Received: by 10.28.145.8 with SMTP id t8mr31992626wmd.103.1458808911972; Thu, 24 Mar 2016 01:41:51 -0700 (PDT) Received: from [10.199.1.6] ([46.166.188.212]) by smtp.gmail.com with ESMTPSA id g203sm25913533wmf.23.2016.03.24.01.41.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 24 Mar 2016 01:41:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley <ve7jtb@ve7jtb.com> In-Reply-To: <56F3A288.2080504@mnt.se> Date: Thu, 24 Mar 2016 08:41:50 +0000 Content-Transfer-Encoding: 7bit Message-Id: <64533C2A-931A-4A5F-B4EB-2CAE357EAC00@ve7jtb.com> References: <56F07A95.4050904@KingsMountain.com> <CADHfa2DzJ4UAvjtUPfp0QfeBnR4HbuVy9VRqO15=x7raRKSLAA@mail.gmail.com> <56F3A288.2080504@mnt.se> To: Leif Johansson <leifj@mnt.se> X-Mailer: Apple Mail (2.3112) Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/Neqg5xeT7RedFa4kBvjXIphXKP8> Cc: unbearable@ietf.org Subject: Re: [Unbearable] Sec- prefix for Token-Binding headers (was: new draft-ietf-tokbind-https-03 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 08:41:55 -0000 Yes > On Mar 24, 2016, at 8:17 AM, Leif Johansson <leifj@mnt.se> wrote: > > On 2016-03-22 04:43, Dirk Balfanz wrote: >> Hi Jeff, >> >> I was told that in Yokohama it was decided to add the Sec- prefix again. >> (I wasn't at that meeting.) > > There was consensus to that effect. > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Thu Mar 24 08:17:36 2016 Return-Path: <waywardgeek@google.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 E9D9712DD82 for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 08:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 4lFojPKalZ-6 for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 08:17:09 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2E812DC17 for <unbearable@ietf.org>; Thu, 24 Mar 2016 08:02:30 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id z68so62271824vkg.3 for <unbearable@ietf.org>; Thu, 24 Mar 2016 08:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=bV4ZCg8T9wSnkfNliYRyWQWvX4xyKvM/6Qh9n4DEMCs=; b=ACyliaP5ElAqxsguJrgWdc+kSv+p3V8BYU1Q6p2BUqeHbaoWcWa47KeFFHBuHqbp5y bPbMzUyNvzNM/95mYlmbbovtKFRMO5YWgkOv6ZqCZ54FjZpQ3tebkkTW2DVZ2UDdrKXM F7cyMNC8NO2HJaNq1WsKKZyH79cTg4DC8TJzEsvLRE0x4oeXbVWo3B9jZMGNalj20LWe MZWsaRfoe3N5agS9V8XrlDdccdHofyy23tzgN6nW7k1nBrsMSXsEz3MJpQ8vl3EdMWLh M2TxCIVn5SMZUtrhfPG+NXNup4DdrbYOAgcKwE1uw6ZnR1yVlwA4+0RwzO89ufpRObZM h7FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=bV4ZCg8T9wSnkfNliYRyWQWvX4xyKvM/6Qh9n4DEMCs=; b=Jw8uDN2EPHGaKFM6MXiAL9ZPVIWg3GH3AyZ/oPg37RtHFHWEBTwHDm6P7R3FCFtzhV IrEzvVWLZT2kyLIdmO4NWoWVLfLL+wPnrSi5CWSrVdyBeCsyREon0UN2KQ7/saC+LkCn aKZhIRb/GIhkHsXuHR1wL0hXfTn58FG7ZJm4KbEItaSxfbBEH817ZI6+cBNeUh3MRBlL +VpPA2naMRunLvw8OIbrR4wU/26koKMAWvUohzAAOssaMMeboNv5hk7YNF7BdbNED62Q kGJnBfdI74K7lYF0XS31YRjcSxv0XGZOnMhQl33W0hNfpeMQoIkRit2xTshCi2Ecdm4k PQwQ== X-Gm-Message-State: AD7BkJJptqf1pP5sIDwVC07q6c0TbnujhH9fwcB0IJPWSoFPhwRa1XnHdn6aoibnZijZVrBw91bpODdCrbJYLhLV MIME-Version: 1.0 X-Received: by 10.31.180.213 with SMTP id d204mr4223200vkf.80.1458831742780; Thu, 24 Mar 2016 08:02:22 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Thu, 24 Mar 2016 08:02:22 -0700 (PDT) In-Reply-To: <2661CA8D-EDFB-4830-BC5D-1A31E81502AB@ve7jtb.com> References: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> <56F29F69.1080105@treenet.co.nz> <CAH9QtQHs61xW9P_4TjQq-Jz=QPbVH9aDsYUUZc3fCNScQvcZPw@mail.gmail.com> <BLUPR03MB13964D90AE484B2639F816878C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CABkgnnWo5rriOpMzxsf=Yt1RFporTQJr5uMJ4QZ1Bhvhf93wRQ@mail.gmail.com> <56F3A0A9.7000008@sunet.se> <2661CA8D-EDFB-4830-BC5D-1A31E81502AB@ve7jtb.com> Date: Thu, 24 Mar 2016 08:02:22 -0700 Message-ID: <CAH9QtQFJHPvaUY1nNjfqvi=E=iHbyvuO4YdoUiMGjbKSyQpwPA@mail.gmail.com> From: Bill Cox <waywardgeek@google.com> To: John Bradley <ve7jtb@ve7jtb.com> Content-Type: multipart/alternative; boundary=001a1144030ed134b4052eccbbf3 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/UC6PimXMh1B5dVHXcOeBdD8kXYI> Cc: Tokbind WG <unbearable@ietf.org>, Leif Johansson <leifj@sunet.se> Subject: Re: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 15:17:19 -0000 --001a1144030ed134b4052eccbbf3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree. Let's let this idea drop. Thanks for considering it. On Thu, Mar 24, 2016 at 1:38 AM, John Bradley <ve7jtb@ve7jtb.com> wrote: > +1 > > > On Mar 24, 2016, at 8:09 AM, Leif Johansson <leifj@sunet.se> wrote: > > > > On 2016-03-24 07:08, Martin Thomson wrote: > >> On 24 March 2016 at 04:41, Andrei Popov <Andrei.Popov@microsoft.com> > wrote: > >>> Extending a MITM-defeating feature to support =E2=80=9Clegitimate=E2= =80=9D MITM makes > me > >>> sad. > >> > >> I know that Stephen has said it, but I think that it behooves me to +1 > >> this. I'm opposed to "fixing" this "problem". > > > > Reading the thread (as chair) I don't see this proposal getting > > the level support it needs to have for the WG to spend resources > > on it. > > > > Feel free to disagree but lets also get the rest of the work done. > > > > Cheers Leif > > > > > > _______________________________________________ > > Unbearable mailing list > > Unbearable@ietf.org > > https://www.ietf.org/mailman/listinfo/unbearable > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a1144030ed134b4052eccbbf3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I agree.=C2=A0 Let's let this idea drop.=C2=A0 Thanks = for considering it.</div><div class=3D"gmail_extra"><br><div class=3D"gmail= _quote">On Thu, Mar 24, 2016 at 1:38 AM, John Bradley <span dir=3D"ltr"><= ;<a href=3D"mailto:ve7jtb@ve7jtb.com" target=3D"_blank">ve7jtb@ve7jtb.com</= a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1<br> <div class=3D"HOEnZb"><div class=3D"h5"><br> > On Mar 24, 2016, at 8:09 AM, Leif Johansson <<a href=3D"mailto:leif= j@sunet.se">leifj@sunet.se</a>> wrote:<br> ><br> > On 2016-03-24 07:08, Martin Thomson wrote:<br> >> On 24 March 2016 at 04:41, Andrei Popov <<a href=3D"mailto:Andr= ei.Popov@microsoft.com">Andrei.Popov@microsoft.com</a>> wrote:<br> >>> Extending a MITM-defeating feature to support =E2=80=9Clegitim= ate=E2=80=9D MITM makes me<br> >>> sad.<br> >><br> >> I know that Stephen has said it, but I think that it behooves me t= o +1<br> >> this.=C2=A0 I'm opposed to "fixing" this "probl= em".<br> ><br> > Reading the thread (as chair) I don't see this proposal getting<br= > > the level support it needs to have for the WG to spend resources<br> > on it.<br> ><br> > Feel free to disagree but lets also get the rest of the work done.<br> ><br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Cheers Leif<br> ><br> ><br> > _______________________________________________<br> > Unbearable mailing list<br> > <a href=3D"mailto:Unbearable@ietf.org">Unbearable@ietf.org</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"no= referrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearabl= e</a><br> <br> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org">Unbearable@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> </div></div></blockquote></div><br></div> --001a1144030ed134b4052eccbbf3-- From nobody Thu Mar 24 08:47:59 2016 Return-Path: <waywardgeek@google.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 3C6C212DB8E for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 08:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 o4Of5Wq-BeIb for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 08:47:56 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD4A12DD76 for <unbearable@ietf.org>; Thu, 24 Mar 2016 08:34:22 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id k1so63912720vkb.0 for <unbearable@ietf.org>; Thu, 24 Mar 2016 08:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=YhmI9snjsv3GoEGcmmUiQV++Pvy9y/wUaomCWcvngN0=; b=BjvhExw40SuBhjCknV5uhy7sQMFjKgU6BmSJ3BGRMDHDXatEXyo7yNfXY9j6gukB5m gnelyYVSqnvhRGnnflmG0NNpRhsSLGfouXOIR80zHjSv51fZ9R4aUt1+2DA6Eq+cCbvz RuP7mejw4jc2cSf4WsMZP6haqt+uoeueF5HYEZcErA+R2iSe0Y0uyfgcD1ZUAvy6qESn YDf3SyqgWo8iLzAFXEBjgHzpDPROyu4KVfp65v/IRcT9yrULkxHUwvl989C0a39bXZ37 zzT07Dy3IImsdC+XteTNWGWPq1kH8VFVS2MYAGDt5MxF1Dtr3i4BS8pmiG35ugBhI9H1 g8AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=YhmI9snjsv3GoEGcmmUiQV++Pvy9y/wUaomCWcvngN0=; b=PRKxnEPzmi3TMghLxSvYKObog7u7eyHGX3eMS6PW9p+QY40CVOxHPHZzNv7kiIyb+d baKJfdOnbO+bQ1SCtrCmWRsxyncQsxuG5BE61S9xSewT23QzvJaYk/pB9wnWy+8Isblq Ckp9GQNgq1f1abGFsRtonCr0X1OXY+M4v7ApWQjsJy9gFjOZKdxiOw6bJOahZg/e7hlM 5CFxwr5IaNziWfwBPYjf57HoMv896dfi7km1OAS7AEJQ8n5TL88NosJm/6SFnKhoYOoZ bRThKax0OZ+0H6s+q6FM29J3+vNIdUUP+kdnaRjYxFvPXi1ecjBY+3LlsUf6oyJ4MFF8 lWfg== X-Gm-Message-State: AD7BkJLAvOxfO2hpbVvcnSZ8wa90utDbcunAZpgw1q4NAXCF2ymnUHQP9poDj+c5XhQqJs5dLVuR9iFQSTSkEmqU MIME-Version: 1.0 X-Received: by 10.159.37.150 with SMTP id 22mr1410086uaf.36.1458833661089; Thu, 24 Mar 2016 08:34:21 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Thu, 24 Mar 2016 08:34:21 -0700 (PDT) In-Reply-To: <CABkgnnW2v2cK-FRm59c5x3b3pWq6Lbbfvv65oSo2VjY9xdPYiQ@mail.gmail.com> References: <CAH9QtQFLWGLgKGkD8BeuEsGAaumuqzheBgaiuOHKuUvZucuRWw@mail.gmail.com> <BLUPR03MB139616608F68A44A25D7A6758C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CAH9QtQFFppvqu42B_TuKDfO_6pMkTCBtzhDWbTh+PVfyPVGGyw@mail.gmail.com> <BLUPR03MB13961CA8EF0DE7D342ADDDC78C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CABkgnnW2v2cK-FRm59c5x3b3pWq6Lbbfvv65oSo2VjY9xdPYiQ@mail.gmail.com> Date: Thu, 24 Mar 2016 08:34:21 -0700 Message-ID: <CAH9QtQFOWqXaon4xNHxRdxOb-EvDGoZXo=EdPbvi-nNTFKZA0g@mail.gmail.com> From: Bill Cox <waywardgeek@google.com> To: Martin Thomson <martin.thomson@gmail.com> Content-Type: multipart/alternative; boundary=001a113c8236282a4c052ecd2e4b Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/1rWQ9ZW1C1SlTTmvlB9m66ayNvc> Cc: Andrei Popov <Andrei.Popov@microsoft.com>, Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Thoughts on TLS 0-RTT 1.3 compatibility X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 15:47:58 -0000 --001a113c8236282a4c052ecd2e4b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 23, 2016 at 11:06 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > On 24 March 2016 at 06:37, Andrei Popov <Andrei.Popov@microsoft.com> > wrote: > > =C3=98 I would prefer that we start thinking in terms of protecting al= l > secrets > > rather than just a few private keys. If we secure the secrets, we can > have > > secure 0-RTT resumption. > > > > > > > > Yes, I agree with this. For TLS 1.3, this could be our way to enable TB > with > > 0-RTT, at least where the hardware allows secure storage of TLS secrets > (and > > not just TB private keys). > > I think that I disagree. A token binding key has an opportunity to be > much better protected than whatever is used for resumption (which, > accordingly, has a much shorter lifetime). > I think I might be able to convince you :) In TLS 1.3, the master resumption secret in a secure 0-RTT mode gets used exactly once per resumption, the same as TB keys in TLS 1.2. If we protect the resumption secret exactly like we protect the TB private key, then TLS 1.3 0-RTT will have essentially the same TB latency as TLS 1.2. If we use the 0-RTT mode I described above, It should also have the same security. 0-RTT is coming on like a freight train. I suspect the world will mostly run on 0-RTT in about 3 years. This is the only way I see for TB to be effective for everyone in that future. I don't have an answer for the 0-RTT aspects of this. I suspect that > the right answer is to not send any token binding proofs until the > handshake is complete, but I can appreciate how that might make people > sad. > I also think we should not send any application requests before the TB proof. That means we must choose between two options: 1) Don't allow 0-RTT in any form. 2) Secure the master resumption secrets as well as TB private keys, and don't do TB proofs on 0-RTT resumption. If there more positive stories about companies choosing security over short-term profits, I would prefer option 1. Bill --001a113c8236282a4c052ecd2e4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W= ed, Mar 23, 2016 at 11:06 PM, Martin Thomson <span dir=3D"ltr"><<a href= =3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson@gmail= .com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,= 204);border-left-style:solid;padding-left:1ex"><span class=3D"">On 24 March= 2016 at 06:37, Andrei Popov <<a href=3D"mailto:Andrei.Popov@microsoft.c= om">Andrei.Popov@microsoft.com</a>> wrote:<br> > =C3=98=C2=A0 I would prefer that we start thinking in terms of protect= ing all secrets<br> > rather than just a few private keys.=C2=A0 If we secure the secrets, w= e can have<br> > secure 0-RTT resumption.<br> ><br> ><br> ><br> > Yes, I agree with this. For TLS 1.3, this could be our way to enable T= B with<br> > 0-RTT, at least where the hardware allows secure storage of TLS secret= s (and<br> > not just TB private keys).<br> <br> </span>I think that I disagree.=C2=A0 A token binding key has an opportunit= y to be<br> much better protected than whatever is used for resumption (which,<br> accordingly, has a much shorter lifetime).<br></blockquote><div><br></div><= div>I think I might be able to convince you :)</div><div><br></div><div>In = TLS 1.3, the master resumption secret in a secure 0-RTT mode gets used exac= tly once per resumption, the same as TB keys in TLS 1.2.=C2=A0 If we protec= t the resumption secret exactly like we protect the TB private key, then TL= S 1.3 0-RTT will have essentially the same TB latency as TLS 1.2.=C2=A0 If = we use the 0-RTT mode I described above, It should also have the same secur= ity.<br></div><div><br></div><div>0-RTT is coming on like a freight train.= =C2=A0 I suspect the world will mostly run on 0-RTT in about 3 years.=C2=A0= This is the only way I see for TB to be effective for everyone in that fut= ure.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:= 0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);= border-left-style:solid;padding-left:1ex"> I don't have an answer for the 0-RTT aspects of this.=C2=A0 I suspect t= hat<br> the right answer is to not send any token binding proofs until the<br> handshake is complete, but I can appreciate how that might make people<br> sad.<br> </blockquote></div><br></div><div class=3D"gmail_extra">I also think we sho= uld not send any application requests before the TB proof.=C2=A0 That means= we must choose between two options:</div><div class=3D"gmail_extra"><br></= div><div class=3D"gmail_extra">1) Don't allow 0-RTT in any form.</div><= div class=3D"gmail_extra">2) Secure the master resumption secrets as well a= s TB private keys, and don't do TB proofs on 0-RTT resumption.</div><di= v class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">If there more = positive stories about companies choosing security over short-term profits,= I would prefer option 1.</div><div class=3D"gmail_extra"><br></div><div cl= ass=3D"gmail_extra">Bill</div></div> --001a113c8236282a4c052ecd2e4b-- From nobody Thu Mar 24 09:21:48 2016 Return-Path: <ynir.ietf@gmail.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 7344612D52D for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 09:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 hA0Qj4RsqXIM for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 09:21:46 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986FC12DBDF for <unbearable@ietf.org>; Thu, 24 Mar 2016 09:15:19 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id p65so281582991wmp.1 for <unbearable@ietf.org>; Thu, 24 Mar 2016 09:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=flKc/dbWrz9fzbDC7u2vd15YC1t10mWRUVjfPjTanPM=; b=p9sOgrPKMfw7C3mzsiy99IqWl8StkdgSQGuFReYB4FxMo/q/b58AwsBaI/tilsmOgg P1vafzXpIvdNcRDYaixIAHOMoLuKlGMoRhEG2ymNiCdgmEhXyQ8fPL4il2KoXIpLkzJ5 McOJGBfxo226uCn25hJpqRkMqU8qK9LHmT4rxBybGKEdkRl817LdhwuOlaKsg5M6TjzT qKeaJpzd25icbTz9cQNmpOk/ffeescGKd0C+vfklsNr8vm2KokworJkX1vjC33rCZ9/D ErgD0/Yvf9xOVmjBY+w92ysgqSlgKXl5cLVKrXL7iRvdns+LQp7I0hYfWq/1ltelAxMb c54w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=flKc/dbWrz9fzbDC7u2vd15YC1t10mWRUVjfPjTanPM=; b=EY9b08GAPzhvjSiATTjTjEEDayrw8HgfgNm26J9TS+hIcXMedlwfQGjBmH6TerL/WE DfL7H3GrqUqe6gyW9KZuxJ3I+TBkrfUQqSbrb8Tjm0Tp/h1uLbyCnAUClFajqnQxGe2X D9MHjx3paddj3njFlUw2iH9TkbXdwvUZMBVb0iQ1NtDRejx0QWrOLcfpu6VzDBCDIovI FnfSz/Vo2Q5l8nnDmcLKXAPnaBrYIMUU0lHaDVKf0/1/SrUEZDvnMd0IGI1H/MiDEiSP xFjEJKpTLtSUiy18fVrQBWGWdamfxrWQi4kSK+7DFEwZKIQJVq///wAE5KMT0PqRSCsd ZNPQ== X-Gm-Message-State: AD7BkJKevCadI5mODsCO8nEWInRBrIgpFZQDjR4Ka9G58XV4ZWGGqDOOf5PJah9V1olQzw== X-Received: by 10.28.195.136 with SMTP id t130mr36081416wmf.27.1458836118093; Thu, 24 Mar 2016 09:15:18 -0700 (PDT) Received: from [192.168.1.13] (bzq-84-109-9-199.red.bezeqint.net. [84.109.9.199]) by smtp.gmail.com with ESMTPSA id u4sm8045907wjz.4.2016.03.24.09.15.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 24 Mar 2016 09:15:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir <ynir.ietf@gmail.com> In-Reply-To: <B3384273-C6C0-4C09-8795-866B1EE288E6@inria.fr> Date: Thu, 24 Mar 2016 18:15:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4BD383BB-84D1-4152-867E-22E52B47A331@gmail.com> References: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> <56F29F69.1080105@treenet.co.nz> <CAH9QtQHs61xW9P_4TjQq-Jz=QPbVH9aDsYUUZc3fCNScQvcZPw@mail.gmail.com> <BLUPR03MB13964D90AE484B2639F816878C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CABkgnnWo5rriOpMzxsf=Yt1RFporTQJr5uMJ4QZ1Bhvhf93wRQ@mail.gmail.com> <56F3A5FD.3060705@treenet.co.nz> <C656BF88-97E9-4B0C-8482-DC8E2B4AFEBE@gmail.com> <B3384273-C6C0-4C09-8795-866B1EE288E6@inria.fr> To: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr> X-Mailer: Apple Mail (2.3124) Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/NRDvEf-T_Fh4zyHeTsu72n3KNho> Cc: Amos Jeffries <squid3@treenet.co.nz>, unbearable@ietf.org Subject: Re: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 16:21:47 -0000 > On 24 Mar 2016, at 10:36 AM, Karthik Bhargavan = <karthikeyan.bhargavan@inria.fr> wrote: >=20 > Is there value in designing a secure protocol =E2=80=9Cextension=E2=80=9D= that plays nice > with middle-boxes? How common/important is this problem? >=20 > (with the researcher hat on) > -Karthik I use the same laptop both when I=E2=80=99m at home (where there is not = TLS proxy) and at work (where there is one). My situation is not unique. We don=E2=80=99t necessarily need a protocol = extension to play nice with these proxies, but we need some kind of good = story of how things work for such a use case. If websites that use our = protocol will fail to display when I go to work, then major websites = will not deploy it. If OTOH security is only degraded when behind the proxy (similar to how = we lose the EV indication) then it=E2=80=99s probably fine. Yoav From nobody Thu Mar 24 09:58:19 2016 Return-Path: <balfanz@google.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 B217912D5D3 for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 09:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Db6PYpztN0Xr for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 09:58:15 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95DA712D0FF for <unbearable@ietf.org>; Thu, 24 Mar 2016 09:58:15 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id l68so245074719wml.0 for <unbearable@ietf.org>; Thu, 24 Mar 2016 09:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=RxYQpRbKdFn5HcyAFZuTsnSEZYrSNJ84FnD6up9I/1w=; b=lPeBG/0NH4BZSvsG3oeCTra+Iq3GGJ43CThTi+Mz4JEKbNKs36TRIz78oPcv9q1pF3 Pqv2PvdOgFvew3TwC3LBSICKPGF4Kh2VdcMuvG6OPrsDOZuN/UMdqn4iQVsHJvip2b/n 5F3EcSE/ZTfBBCdWnroO6lj6qH6giFM33xSwMg4cZZWy8qwSwMexnY/09aHoZmyXK7HX Ksc4CPFeCT8NEc8qbMimcJ1KPPjam2/Yen17ztF5ix5ETzsblsrbWZFm/kc8yVqW6mTw ybP17/Igr2+Pmt2u5A+ipsggWrOirw6M2aNh3yvJG6iQV9iy6aVreXP0PadLu7MR/8xr wh+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=RxYQpRbKdFn5HcyAFZuTsnSEZYrSNJ84FnD6up9I/1w=; b=BLj+wGXfH2KmPq+IrucpX0etgoU0fhVRASPEu2tbT7cWua7D2Rr6kOgAJf6urLdu8o 4zCQqMMZgyyMvWnrD4cODTlxVCEsJMhAa2mFyq31SvKxKH+BLsj9m3zDqOc0/OSHFLU1 33bgIqwFyRm53WURScCuXaNa39vr4uaiYXOGnMkvIWbawO2VziqWq1zT5zcqU6WK+AR1 zNHBnlmOWESrzCzr27cSKzoaKrftfRSc6L/fNjYkTA4ddxuUTiQrCltGL4klXlILzkq9 sM/7YxhzcyYxsntpfD8ZdUFncIqqO7IjLJ/vYtrFeXMH7+zXAtBjOUlzHyDHV/YAcYPz toFg== X-Gm-Message-State: AD7BkJJP3zgB6xWbDLvj4DjT29mQPg1SOACmtijruwwWIPgorP01tLkp71cK8IQjadgd8Kgb0Rq86b0/z95I17EN X-Received: by 10.28.95.131 with SMTP id t125mr35356357wmb.80.1458838693961; Thu, 24 Mar 2016 09:58:13 -0700 (PDT) MIME-Version: 1.0 References: <CAH9QtQH1jcVTf9G4ZQKNFqBHzvOzb+Zepk+J4UynWP3b_hLaiQ@mail.gmail.com> In-Reply-To: <CAH9QtQH1jcVTf9G4ZQKNFqBHzvOzb+Zepk+J4UynWP3b_hLaiQ@mail.gmail.com> From: Dirk Balfanz <balfanz@google.com> Date: Thu, 24 Mar 2016 16:58:04 +0000 Message-ID: <CADHfa2BR_tda3ppScHc69nATbYLDo8fN1tqQTnc4NdY_GaoXfw@mail.gmail.com> To: Bill Cox <waywardgeek@google.com>, Tokbind WG <unbearable@ietf.org> Content-Type: multipart/alternative; boundary=001a114a440623b4cf052ece5a8c Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/pqwE7s7KmiZTZQn3cLnQMNMNHWI> Subject: Re: [Unbearable] Multiplexed connections X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 16:58:17 -0000 --001a114a440623b4cf052ece5a8c Content-Type: text/plain; charset=UTF-8 My thoughts on this: The scenario you're describing implies that the two domains sit behind a single TLS terminator, right? In that case it seems to me it's ok to delegate negotiation of TB key parameters to that TLS terminator, and in particular assume that the parameters will be identical. If one domain or the other doesn't like the TB parameters that the TLS terminator negotiates, it should probably go looking for a new hosting provider. :-) Of course, the actual keys used by the clients will be different, so although the domains share a TLS terminator, they won't share user identifiers. Dirk. On Wed, Mar 23, 2016 at 7:17 PM Bill Cox <waywardgeek@google.com> wrote: > Both SPDY and QUIC protocols used by Google multiplex multiple HTTP > streams over one connection to reduce handshake latency. QUIC is really > awesome at this, and will significantly improve speed generally, I think. > > What happens when a user talks to 2 or more eTLD+1 sites over a > multiplexed connection? There is only one chance to negotiate TB key > parameters, and it is possible that the key types for requests multiplexed > over the same connection will be different. > > Even scarier, although I think we simply have to agree this is beyond what > we can deal with: are there proxies out there that send multiple user > streams multiplexed over one connection to popular sites? > > Bill > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a114a440623b4cf052ece5a8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">My thoughts on this: The scenario you're describing im= plies that the two domains sit behind a single TLS terminator, right? In th= at case it seems to me it's ok to delegate negotiation of TB key parame= ters to that TLS terminator, and in particular assume that the parameters w= ill be identical. If one domain or the other doesn't like the TB parame= ters that the TLS terminator negotiates, it should probably go looking for = a new hosting provider. :-)<div><br></div><div>Of course, the actual keys u= sed by the clients will be different, so although the domains share a TLS t= erminator, they won't share user identifiers.=C2=A0</div><div><br></div= ><div>Dirk.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On W= ed, Mar 23, 2016 at 7:17 PM Bill Cox <<a href=3D"mailto:waywardgeek@goog= le.com">waywardgeek@google.com</a>> wrote:<br></div><blockquote class=3D= "gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding= -left:1ex"><div dir=3D"ltr">Both SPDY and QUIC protocols used by Google mul= tiplex multiple HTTP streams over one connection to reduce handshake latenc= y.=C2=A0 QUIC is really awesome at this, and will significantly improve spe= ed generally, I think.<div><br></div><div>What happens when a user talks to= 2 or more eTLD+1 sites over a multiplexed connection?=C2=A0 There is only = one chance to negotiate TB key parameters, and it is possible that the key = types for requests multiplexed over the same connection will be different.<= /div><div><br></div><div>Even scarier, although I think we simply have to a= gree this is beyond what we can deal with: are there proxies out there that= send multiple user streams multiplexed over one connection to popular site= s?</div><div><br></div><div>Bill</div></div> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> </blockquote></div> --001a114a440623b4cf052ece5a8c-- From nobody Thu Mar 24 10:08:34 2016 Return-Path: <phil.hunt@oracle.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 2517712D5B5 for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 10:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 aHlGA0OMofYa for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 10:08:31 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 CE62712D0B8 for <unbearable@ietf.org>; Thu, 24 Mar 2016 10:08:31 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2OH8R7Y021386 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Mar 2016 17:08:27 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2OH8QZK007950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Mar 2016 17:08:26 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u2OH8Lpm028139; Thu, 24 Mar 2016 17:08:21 GMT Received: from [25.173.218.24] (/72.143.228.255) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 24 Mar 2016 10:08:21 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" <phil.hunt@oracle.com> X-Mailer: iPhone Mail (13E233) In-Reply-To: <4BD383BB-84D1-4152-867E-22E52B47A331@gmail.com> Date: Thu, 24 Mar 2016 10:08:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <42ADE97F-A7B4-43CF-81C3-BF5D64076917@oracle.com> References: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> <56F29F69.1080105@treenet.co.nz> <CAH9QtQHs61xW9P_4TjQq-Jz=QPbVH9aDsYUUZc3fCNScQvcZPw@mail.gmail.com> <BLUPR03MB13964D90AE484B2639F816878C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CABkgnnWo5rriOpMzxsf=Yt1RFporTQJr5uMJ4QZ1Bhvhf93wRQ@mail.gmail.com> <56F3A5FD.3060705@treenet.co.nz> <C656BF88-97E9-4B0C-8482-DC8E2B4AFEBE@gmail.com> <B3384273-C6C0-4C09-8795-866B1EE288E6@inria.fr> <4BD383BB-84D1-4152-867E-22E52B47A331@gmail.com> To: Yoav Nir <ynir.ietf@gmail.com> X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/1fd_R0PUc3xncsI3CApeYivEqjY> Cc: unbearable@ietf.org, Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>, Amos Jeffries <squid3@treenet.co.nz> Subject: Re: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 17:08:33 -0000 What about client side proxies? Such as when employees take laptops in and o= ut of work? Web gateways/balancers that terminate tls are also an issue but I understand= the challenge. Can binding still be extended to the web service? Probably need to cover the limitations in detail even if not addressed or ad= dressable.=20 Phil > On Mar 24, 2016, at 09:15, Yoav Nir <ynir.ietf@gmail.com> wrote: >=20 >=20 >> On 24 Mar 2016, at 10:36 AM, Karthik Bhargavan <karthikeyan.bhargavan@inr= ia.fr> wrote: >>=20 >> Is there value in designing a secure protocol =E2=80=9Cextension=E2=80=9D= that plays nice >> with middle-boxes? How common/important is this problem? >>=20 >> (with the researcher hat on) >> -Karthik >=20 > I use the same laptop both when I=E2=80=99m at home (where there is not TL= S proxy) and at work (where there is one). >=20 > My situation is not unique. We don=E2=80=99t necessarily need a protocol e= xtension to play nice with these proxies, but we need some kind of good stor= y of how things work for such a use case. If websites that use our protocol w= ill fail to display when I go to work, then major websites will not deploy i= t. >=20 > If OTOH security is only degraded when behind the proxy (similar to how we= lose the EV indication) then it=E2=80=99s probably fine. >=20 > Yoav >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Thu Mar 24 10:21:17 2016 Return-Path: <nharper@google.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 E614412D668 for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 10:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 TXw1JHMDKaR3 for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 10:21:14 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E83512D1D8 for <unbearable@ietf.org>; Thu, 24 Mar 2016 10:21:14 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id e6so67975905vkh.2 for <unbearable@ietf.org>; Thu, 24 Mar 2016 10:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HrpBqI647D2C0vsfN3Of8ZOKWVxmrww/Kv+hBOVmflE=; b=Pw1s52J6mbAdzEzzLUbfg+0aukeIK73Yt1MhYIu60EcBQOzyv3//EO7/BCD5hzbg4c 5jPIJ6MgKEnaIWNnSBcjf/+U4G2DSITIah3MqOXwsn6U+GQwZ48kgDQ8U7Py88zqFPEA kIiLCEs4nQt/3d9eX+X4LLdJPE/jEoAq9R/fwBdU/xSqONGvcaWfGzHsxW/mhQbTbNyO ABPh0wN1eGE3gZbA5PmlnKx15Co+zN7a/7dvQ5zwRr2XZRfKK7uIDc7460dQNmJme+vW /xlE2Vj9gFZHDf/EkKNFvxhPYGnBY0ww9KE6sBlioepnahvc2hKpaCL68tc5GZfgXZiG sEfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HrpBqI647D2C0vsfN3Of8ZOKWVxmrww/Kv+hBOVmflE=; b=H7y0VRX9NHVg9RebNhc3hdqhxOpEMMteSuOwxuH8GJbPhKUhXm8LbMLxZ0ke4wdtMz 2xv4cL/VHXZtBMk4tgSwnXt+/D7Zb/+vYMC/pLvsIwgKlwJSUelpYtiOi27Kdkw98VjY TVKz79517vAn+FYiCGT5zb/jWHXLk2zwsvmK9awCpwAWtky82rg+rTSXniljlQfxdYmk 1HNx4a4POfTGCa18IYzJlWkJqMTErranMS2vI2XmLiDnI1vkjLqHH2905PBHdocjRbhV /DYooHN1UN/WDbBFTLHSkMhQCmVWPI/DpZoBYbk+IN3IfdsTmW04PfDVlOy5B+ZBRMkv ni3A== X-Gm-Message-State: AD7BkJILjE0jIYxc+sSYkvJ8OhykuTkc7r67U/FVpjJ/Uqq1buGFlI5swKWP6zUESYgU0ZdzYXJuZntDQRp4JbW7 X-Received: by 10.176.0.111 with SMTP id 102mr5158932uai.15.1458840072895; Thu, 24 Mar 2016 10:21:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.76.198 with HTTP; Thu, 24 Mar 2016 10:20:53 -0700 (PDT) In-Reply-To: <CAH9QtQH1jcVTf9G4ZQKNFqBHzvOzb+Zepk+J4UynWP3b_hLaiQ@mail.gmail.com> References: <CAH9QtQH1jcVTf9G4ZQKNFqBHzvOzb+Zepk+J4UynWP3b_hLaiQ@mail.gmail.com> From: Nick Harper <nharper@google.com> Date: Thu, 24 Mar 2016 10:20:53 -0700 Message-ID: <CACdeXiL+JHj+ieWxuDpYJZfdfGOLpy6onbSemBb-aeRxyirPgA@mail.gmail.com> To: Bill Cox <waywardgeek@google.com> Content-Type: multipart/alternative; boundary=001a113e3b2454d756052eceacb3 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/n_bO8H62s85TqHa4K3YVC1OJgM8> Cc: Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Multiplexed connections X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 17:21:16 -0000 --001a113e3b2454d756052eceacb3 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 23, 2016 at 7:17 PM, Bill Cox <waywardgeek@google.com> wrote: > Both SPDY and QUIC protocols used by Google multiplex multiple HTTP > streams over one connection to reduce handshake latency. QUIC is really > awesome at this, and will significantly improve speed generally, I think. > > What happens when a user talks to 2 or more eTLD+1 sites over a > multiplexed connection? There is only one chance to negotiate TB key > parameters, and it is possible that the key types for requests multiplexed > over the same connection will be different. > > Even scarier, although I think we simply have to agree this is beyond what > we can deal with: are there proxies out there that send multiple user > streams multiplexed over one connection to popular sites? > Chrome's spdy proxy code (https://www.chromium.org/spdy/spdy-proxy) provides support for just that. The browser makes one ssl connection to the proxy, but then tunnels multiple ssl connections to the sites it wishes to connect to through the connection to the proxy. So there shouldn't be any Token Binding concerns because the client will negotiate TB separately for each site it connects to on the tunneled ssl connection for that site. > > Bill > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --001a113e3b2454d756052eceacb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On Wed, Mar 23, 2016 at 7:17 PM, Bill Cox <span dir=3D"ltr"><<a href= =3D"mailto:waywardgeek@google.com" target=3D"_blank">waywardgeek@google.com= </a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin= :0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)= ;border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">Both SPDY and Q= UIC protocols used by Google multiplex multiple HTTP streams over one conne= ction to reduce handshake latency.=C2=A0 QUIC is really awesome at this, an= d will significantly improve speed generally, I think.<div><br></div><div>W= hat happens when a user talks to 2 or more eTLD+1 sites over a multiplexed = connection?=C2=A0 There is only one chance to negotiate TB key parameters, = and it is possible that the key types for requests multiplexed over the sam= e connection will be different.</div><div><br></div><div>Even scarier, alth= ough I think we simply have to agree this is beyond what we can deal with: = are there proxies out there that send multiple user streams multiplexed ove= r one connection to popular sites?</div></div></blockquote><div><br></div><= div>Chrome's spdy proxy code (<a href=3D"https://www.chromium.org/spdy/= spdy-proxy">https://www.chromium.org/spdy/spdy-proxy</a>) provides support = for just that. The browser makes one ssl connection to the proxy, but then = tunnels multiple ssl connections to the sites it wishes to connect to throu= gh the connection to the proxy. So there shouldn't be any Token Binding= concerns because the client will negotiate TB separately for each site it = connects to on the tunneled ssl connection for that site.</div><blockquote = class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1= px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:= 1ex"><div dir=3D"ltr"><span class=3D""><font color=3D"#888888"><div><br></d= iv><div>Bill</div></font></span></div> <br>_______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org">Unbearable@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> <br></blockquote></div><br></div></div> --001a113e3b2454d756052eceacb3-- From nobody Thu Mar 24 10:48:17 2016 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 65F0B12D67C for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 10:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 6FYMGKoSErSG for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 10:48:10 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA3712D709 for <unbearable@ietf.org>; Thu, 24 Mar 2016 10:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DIVPpc9lPNZjXjuwScF3xZcx1VrnIWRiWg+Kkkk3GuU=; b=iTo1upBlGNMLZb3Ytc8d6IZjS45PH5RloDlJt882lG3/Vdi5gRq9yfNJU27XDHRcBcSm+wTxe30gz0lEVYRXW8VlX8mqDw8+ADXj1QJaqH1NGBUuDY84hYuh3A4wxFGwiuDU51bn2F68602FFr7NzBWdSUXm+vzvZ6Psy0A0yVo= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.434.16; Thu, 24 Mar 2016 17:47:34 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0434.023; Thu, 24 Mar 2016 17:47:34 +0000 From: Andrei Popov <Andrei.Popov@microsoft.com> To: Bill Cox <waywardgeek@google.com>, Martin Thomson <martin.thomson@gmail.com> Thread-Topic: [Unbearable] Thoughts on TLS 0-RTT 1.3 compatibility Thread-Index: AQHRhQcgxIK280Rw4Uycc/vXubnt6Z9nP4hwgAAeU4CAAAHIgIAAvQQAgACekICAACIeUA== Date: Thu, 24 Mar 2016 17:47:34 +0000 Message-ID: <BLUPR03MB1396D4C18D5D082283D481DA8C820@BLUPR03MB1396.namprd03.prod.outlook.com> References: <CAH9QtQFLWGLgKGkD8BeuEsGAaumuqzheBgaiuOHKuUvZucuRWw@mail.gmail.com> <BLUPR03MB139616608F68A44A25D7A6758C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CAH9QtQFFppvqu42B_TuKDfO_6pMkTCBtzhDWbTh+PVfyPVGGyw@mail.gmail.com> <BLUPR03MB13961CA8EF0DE7D342ADDDC78C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CABkgnnW2v2cK-FRm59c5x3b3pWq6Lbbfvv65oSo2VjY9xdPYiQ@mail.gmail.com> <CAH9QtQFOWqXaon4xNHxRdxOb-EvDGoZXo=EdPbvi-nNTFKZA0g@mail.gmail.com> In-Reply-To: <CAH9QtQFOWqXaon4xNHxRdxOb-EvDGoZXo=EdPbvi-nNTFKZA0g@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:d::1d2] x-ms-office365-filtering-correlation-id: 9470d372-506e-4f65-335d-08d3540c61ed x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:h4zbTNr2jl2P5bG45QHq1NLfsUU6gNLFm0Wk8WF0ifP4fs7BElgmTiRRVJxVydo/VGXKHI8VO+zs4OVGBYdCChC41nsmk5eppHdKDVmGHVu6ooZ5W2h8AodbOSvluXTEGMJJhAurIbd6zdYWjnLopA==; 24:8e/EKF5HT1CrDeDrs/5WbgvGMgXBEhQAkgGN2/SEs+sUyyTrDFjrFFwzkoZzqRAc+hrvgGwHphLsvMguO6oY/zsN59ZwEN1Whsyr4owBMIM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: <BLUPR03MB139606BCB1C9EA4A342B19068C820@BLUPR03MB1396.namprd03.prod.outlook.com> x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 0891BC3F3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(51444003)(77096005)(2900100001)(2950100001)(15975445007)(74316001)(11100500001)(5004730100002)(5008740100001)(19580405001)(93886004)(33656002)(19625215002)(50986999)(54356999)(76176999)(87936001)(19580395003)(106116001)(99286002)(122556002)(86362001)(1096002)(5001770100001)(76576001)(5003600100002)(16236675004)(1220700001)(4326007)(10090500001)(2906002)(19300405004)(92566002)(10290500002)(586003)(10400500002)(189998001)(3280700002)(6116002)(102836003)(5005710100001)(5002640100001)(790700001)(3660700001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1396D4C18D5D082283D481DA8C820BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2016 17:47:34.6536 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/mg-9GrJhnRUqLB7NYpNDGHVHd5U> Cc: Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Thoughts on TLS 0-RTT 1.3 compatibility X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 17:48:14 -0000 --_000_BLUPR03MB1396D4C18D5D082283D481DA8C820BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEkgc3VzcGVjdCB0aGF0IHRoZSByaWdodCBhbnN3ZXIgaXMgdG8gbm90IHNlbmQgYW55IHRv a2VuIGJpbmRpbmcgcHJvb2ZzIHVudGlsIHRoZSBoYW5kc2hha2UgaXMgY29tcGxldGUsIGJ1dCBJ IGNhbiBhcHByZWNpYXRlIGhvdyB0aGF0IG1pZ2h0IG1ha2UgcGVvcGxlIHNhZC4NClRoaXMgd2Fz IG15IHRoaW5raW5nIG9yaWdpbmFsbHksIGJ1dCBpZiByZXN1bXB0aW9uIHNlY3JldHMgYXJlIGVx dWFsbHkgd2VsbC1wcm90ZWN0ZWQgYXMgdGhlIFRCIGtleSwgdGhlbiB3aHkgcHJvdmUgcG9zc2Vz c2lvbiBvZiB0aGUgVEIga2V5IGF0IHJlc3VtcHRpb24gdGltZT8NCg0KT25lIGNhdmVhdCBpcyB0 aGF0IGZvciBUQiBrZXlzIHdlIGNvdWxkIHBvdGVudGlhbGx5IGF0dGVzdCB0byB0aGUgc2VydmVy IHRoYXQgdGhlIGtleSB1cyBoYXJkd2FyZS1ib3VuZCwgaG93ZXZlciBzaW1pbGFyIGF0dGVzdGF0 aW9uIGZvciByZXN1bXB0aW9uIHNlY3JldHMgc2VlbXMgdW5saWtlbHkgdG8gaGFwcGVuLiBCdXQg dGhlbiB0aG9zZSBoaWdoLXNlY3VyaXR5IHNlcnZlcnMgdGhhdCB3aWxsIGluc2lzdCBvbiBhdHRl c3RlZCBoYXJkd2FyZS1ib3VuZCBUQiBrZXlzIGNhbiBwcm9iYWJseSBkaXNhYmxlIHJlc3VtcHRp b24gYW5kIGFjY2VwdCBpbmNyZWFzZWQgbGF0ZW5jeS4NCg0KRnJvbTogQmlsbCBDb3ggW21haWx0 bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tXQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDI0LCAyMDE2 IDg6MzQgQU0NClRvOiBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPg0K Q2M6IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+OyBUb2tiaW5kIFdH IDx1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBUaG91Z2h0 cyBvbiBUTFMgMC1SVFQgMS4zIGNvbXBhdGliaWxpdHkNCg0KT24gV2VkLCBNYXIgMjMsIDIwMTYg YXQgMTE6MDYgUE0sIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFp bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KT24gMjQgTWFyY2ggMjAxNiBh dCAwNjozNywgQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86 QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCj4gw5ggIEkgd291bGQgcHJlZmVy IHRoYXQgd2Ugc3RhcnQgdGhpbmtpbmcgaW4gdGVybXMgb2YgcHJvdGVjdGluZyBhbGwgc2VjcmV0 cw0KPiByYXRoZXIgdGhhbiBqdXN0IGEgZmV3IHByaXZhdGUga2V5cy4gIElmIHdlIHNlY3VyZSB0 aGUgc2VjcmV0cywgd2UgY2FuIGhhdmUNCj4gc2VjdXJlIDAtUlRUIHJlc3VtcHRpb24uDQo+DQo+ DQo+DQo+IFllcywgSSBhZ3JlZSB3aXRoIHRoaXMuIEZvciBUTFMgMS4zLCB0aGlzIGNvdWxkIGJl IG91ciB3YXkgdG8gZW5hYmxlIFRCIHdpdGgNCj4gMC1SVFQsIGF0IGxlYXN0IHdoZXJlIHRoZSBo YXJkd2FyZSBhbGxvd3Mgc2VjdXJlIHN0b3JhZ2Ugb2YgVExTIHNlY3JldHMgKGFuZA0KPiBub3Qg anVzdCBUQiBwcml2YXRlIGtleXMpLg0KDQpJIHRoaW5rIHRoYXQgSSBkaXNhZ3JlZS4gIEEgdG9r ZW4gYmluZGluZyBrZXkgaGFzIGFuIG9wcG9ydHVuaXR5IHRvIGJlDQptdWNoIGJldHRlciBwcm90 ZWN0ZWQgdGhhbiB3aGF0ZXZlciBpcyB1c2VkIGZvciByZXN1bXB0aW9uICh3aGljaCwNCmFjY29y ZGluZ2x5LCBoYXMgYSBtdWNoIHNob3J0ZXIgbGlmZXRpbWUpLg0KDQpJIHRoaW5rIEkgbWlnaHQg YmUgYWJsZSB0byBjb252aW5jZSB5b3UgOikNCg0KSW4gVExTIDEuMywgdGhlIG1hc3RlciByZXN1 bXB0aW9uIHNlY3JldCBpbiBhIHNlY3VyZSAwLVJUVCBtb2RlIGdldHMgdXNlZCBleGFjdGx5IG9u Y2UgcGVyIHJlc3VtcHRpb24sIHRoZSBzYW1lIGFzIFRCIGtleXMgaW4gVExTIDEuMi4gIElmIHdl IHByb3RlY3QgdGhlIHJlc3VtcHRpb24gc2VjcmV0IGV4YWN0bHkgbGlrZSB3ZSBwcm90ZWN0IHRo ZSBUQiBwcml2YXRlIGtleSwgdGhlbiBUTFMgMS4zIDAtUlRUIHdpbGwgaGF2ZSBlc3NlbnRpYWxs eSB0aGUgc2FtZSBUQiBsYXRlbmN5IGFzIFRMUyAxLjIuICBJZiB3ZSB1c2UgdGhlIDAtUlRUIG1v ZGUgSSBkZXNjcmliZWQgYWJvdmUsIEl0IHNob3VsZCBhbHNvIGhhdmUgdGhlIHNhbWUgc2VjdXJp dHkuDQoNCjAtUlRUIGlzIGNvbWluZyBvbiBsaWtlIGEgZnJlaWdodCB0cmFpbi4gIEkgc3VzcGVj dCB0aGUgd29ybGQgd2lsbCBtb3N0bHkgcnVuIG9uIDAtUlRUIGluIGFib3V0IDMgeWVhcnMuICBU aGlzIGlzIHRoZSBvbmx5IHdheSBJIHNlZSBmb3IgVEIgdG8gYmUgZWZmZWN0aXZlIGZvciBldmVy eW9uZSBpbiB0aGF0IGZ1dHVyZS4NCg0KSSBkb24ndCBoYXZlIGFuIGFuc3dlciBmb3IgdGhlIDAt UlRUIGFzcGVjdHMgb2YgdGhpcy4gIEkgc3VzcGVjdCB0aGF0DQp0aGUgcmlnaHQgYW5zd2VyIGlz IHRvIG5vdCBzZW5kIGFueSB0b2tlbiBiaW5kaW5nIHByb29mcyB1bnRpbCB0aGUNCmhhbmRzaGFr ZSBpcyBjb21wbGV0ZSwgYnV0IEkgY2FuIGFwcHJlY2lhdGUgaG93IHRoYXQgbWlnaHQgbWFrZSBw ZW9wbGUNCnNhZC4NCg0KSSBhbHNvIHRoaW5rIHdlIHNob3VsZCBub3Qgc2VuZCBhbnkgYXBwbGlj YXRpb24gcmVxdWVzdHMgYmVmb3JlIHRoZSBUQiBwcm9vZi4gIFRoYXQgbWVhbnMgd2UgbXVzdCBj aG9vc2UgYmV0d2VlbiB0d28gb3B0aW9uczoNCg0KMSkgRG9uJ3QgYWxsb3cgMC1SVFQgaW4gYW55 IGZvcm0uDQoyKSBTZWN1cmUgdGhlIG1hc3RlciByZXN1bXB0aW9uIHNlY3JldHMgYXMgd2VsbCBh cyBUQiBwcml2YXRlIGtleXMsIGFuZCBkb24ndCBkbyBUQiBwcm9vZnMgb24gMC1SVFQgcmVzdW1w dGlvbi4NCg0KSWYgdGhlcmUgbW9yZSBwb3NpdGl2ZSBzdG9yaWVzIGFib3V0IGNvbXBhbmllcyBj aG9vc2luZyBzZWN1cml0eSBvdmVyIHNob3J0LXRlcm0gcHJvZml0cywgSSB3b3VsZCBwcmVmZXIg b3B0aW9uIDEuDQoNCkJpbGwNCg== --_000_BLUPR03MB1396D4C18D5D082283D481DA8C820BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjc5OTY4NDUyNzsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTUyNTg1NzI1NCAxNjM5NDc0 MDMwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQt YXQ6MjAxNzsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkkgc3VzcGVjdCB0aGF0IHRo ZSByaWdodCBhbnN3ZXIgaXMgdG8gbm90IHNlbmQgYW55IHRva2VuIGJpbmRpbmcgcHJvb2ZzIHVu dGlsIHRoZSBoYW5kc2hha2UgaXMgY29tcGxldGUsIGJ1dCBJIGNhbiBhcHByZWNpYXRlIGhvdyB0 aGF0IG1pZ2h0IG1ha2UgcGVvcGxlIHNhZC48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgd2FzIG15IHRoaW5raW5nIG9yaWdpbmFsbHksIGJ1dCBp ZiByZXN1bXB0aW9uIHNlY3JldHMgYXJlIGVxdWFsbHkgd2VsbC1wcm90ZWN0ZWQgYXMgdGhlIFRC IGtleSwgdGhlbiB3aHkgcHJvdmUgcG9zc2Vzc2lvbiBvZiB0aGUgVEIga2V5IGF0IHJlc3VtcHRp b24gdGltZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9uZSBj YXZlYXQgaXMgdGhhdCBmb3IgVEIga2V5cyB3ZSBjb3VsZCBwb3RlbnRpYWxseSBhdHRlc3QgdG8g dGhlIHNlcnZlciB0aGF0IHRoZSBrZXkgdXMgaGFyZHdhcmUtYm91bmQsIGhvd2V2ZXIgc2ltaWxh ciBhdHRlc3RhdGlvbiBmb3IgcmVzdW1wdGlvbiBzZWNyZXRzIHNlZW1zDQogdW5saWtlbHkgdG8g aGFwcGVuLiBCdXQgdGhlbiB0aG9zZSBoaWdoLXNlY3VyaXR5IHNlcnZlcnMgdGhhdCB3aWxsIGlu c2lzdCBvbiBhdHRlc3RlZCBoYXJkd2FyZS1ib3VuZCBUQiBrZXlzIGNhbiBwcm9iYWJseSBkaXNh YmxlIHJlc3VtcHRpb24gYW5kIGFjY2VwdCBpbmNyZWFzZWQgbGF0ZW5jeS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQmls bCBDb3ggW21haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFRodXJzZGF5LCBNYXJjaCAyNCwgMjAxNiA4OjM0IEFNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4g VGhvbXNvbiAmbHQ7bWFydGluLnRob21zb25AZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4g QW5kcmVpIFBvcG92ICZsdDtBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSZndDs7IFRva2JpbmQg V0cgJmx0O3VuYmVhcmFibGVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb VW5iZWFyYWJsZV0gVGhvdWdodHMgb24gVExTIDAtUlRUIDEuMyBjb21wYXRpYmlsaXR5PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1h ciAyMywgMjAxNiBhdCAxMTowNiBQTSwgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0 bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNv bkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyNCBNYXJjaCAyMDE2IGF0IDA2OjM3LCBBbmRyZWkgUG9w b3YgJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSI+QW5kcmVp LlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IMOYJm5ic3A7IEkg d291bGQgcHJlZmVyIHRoYXQgd2Ugc3RhcnQgdGhpbmtpbmcgaW4gdGVybXMgb2YgcHJvdGVjdGlu ZyBhbGwgc2VjcmV0czxicj4NCiZndDsgcmF0aGVyIHRoYW4ganVzdCBhIGZldyBwcml2YXRlIGtl eXMuJm5ic3A7IElmIHdlIHNlY3VyZSB0aGUgc2VjcmV0cywgd2UgY2FuIGhhdmU8YnI+DQomZ3Q7 IHNlY3VyZSAwLVJUVCByZXN1bXB0aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDsgWWVzLCBJIGFncmVlIHdpdGggdGhpcy4gRm9yIFRMUyAxLjMsIHRoaXMgY291bGQg YmUgb3VyIHdheSB0byBlbmFibGUgVEIgd2l0aDxicj4NCiZndDsgMC1SVFQsIGF0IGxlYXN0IHdo ZXJlIHRoZSBoYXJkd2FyZSBhbGxvd3Mgc2VjdXJlIHN0b3JhZ2Ugb2YgVExTIHNlY3JldHMgKGFu ZDxicj4NCiZndDsgbm90IGp1c3QgVEIgcHJpdmF0ZSBrZXlzKS48YnI+DQo8YnI+DQpJIHRoaW5r IHRoYXQgSSBkaXNhZ3JlZS4mbmJzcDsgQSB0b2tlbiBiaW5kaW5nIGtleSBoYXMgYW4gb3Bwb3J0 dW5pdHkgdG8gYmU8YnI+DQptdWNoIGJldHRlciBwcm90ZWN0ZWQgdGhhbiB3aGF0ZXZlciBpcyB1 c2VkIGZvciByZXN1bXB0aW9uICh3aGljaCw8YnI+DQphY2NvcmRpbmdseSwgaGFzIGEgbXVjaCBz aG9ydGVyIGxpZmV0aW1lKS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgSSBtaWdodCBiZSBhYmxlIHRvIGNvbnZpbmNl IHlvdSA6KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JbiBUTFMgMS4zLCB0aGUgbWFzdGVyIHJlc3VtcHRpb24gc2VjcmV0IGluIGEgc2VjdXJl IDAtUlRUIG1vZGUgZ2V0cyB1c2VkIGV4YWN0bHkgb25jZSBwZXIgcmVzdW1wdGlvbiwgdGhlIHNh bWUgYXMgVEIga2V5cyBpbiBUTFMgMS4yLiZuYnNwOyBJZiB3ZSBwcm90ZWN0IHRoZSByZXN1bXB0 aW9uIHNlY3JldCBleGFjdGx5IGxpa2Ugd2UgcHJvdGVjdCB0aGUgVEIgcHJpdmF0ZSBrZXksIHRo ZW4gVExTIDEuMyAwLVJUVCB3aWxsDQogaGF2ZSBlc3NlbnRpYWxseSB0aGUgc2FtZSBUQiBsYXRl bmN5IGFzIFRMUyAxLjIuJm5ic3A7IElmIHdlIHVzZSB0aGUgMC1SVFQgbW9kZSBJIGRlc2NyaWJl ZCBhYm92ZSwgSXQgc2hvdWxkIGFsc28gaGF2ZSB0aGUgc2FtZSBzZWN1cml0eS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MC1SVFQgaXMgY29t aW5nIG9uIGxpa2UgYSBmcmVpZ2h0IHRyYWluLiZuYnNwOyBJIHN1c3BlY3QgdGhlIHdvcmxkIHdp bGwgbW9zdGx5IHJ1biBvbiAwLVJUVCBpbiBhYm91dCAzIHllYXJzLiZuYnNwOyBUaGlzIGlzIHRo ZSBvbmx5IHdheSBJIHNlZSBmb3IgVEIgdG8gYmUgZWZmZWN0aXZlIGZvciBldmVyeW9uZSBpbiB0 aGF0IGZ1dHVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBkb24ndCBoYXZlIGFuIGFuc3dlciBmb3IgdGhlIDAtUlRUIGFzcGVj dHMgb2YgdGhpcy4mbmJzcDsgSSBzdXNwZWN0IHRoYXQ8YnI+DQp0aGUgcmlnaHQgYW5zd2VyIGlz IHRvIG5vdCBzZW5kIGFueSB0b2tlbiBiaW5kaW5nIHByb29mcyB1bnRpbCB0aGU8YnI+DQpoYW5k c2hha2UgaXMgY29tcGxldGUsIGJ1dCBJIGNhbiBhcHByZWNpYXRlIGhvdyB0aGF0IG1pZ2h0IG1h a2UgcGVvcGxlPGJyPg0Kc2FkLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyB0aGluayB3ZSBzaG91bGQgbm90IHNlbmQg YW55IGFwcGxpY2F0aW9uIHJlcXVlc3RzIGJlZm9yZSB0aGUgVEIgcHJvb2YuJm5ic3A7IFRoYXQg bWVhbnMgd2UgbXVzdCBjaG9vc2UgYmV0d2VlbiB0d28gb3B0aW9uczo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkgRG9uJ3QgYWxsb3cgMC1S VFQgaW4gYW55IGZvcm0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4yKSBTZWN1cmUgdGhlIG1hc3RlciByZXN1bXB0aW9uIHNlY3JldHMgYXMgd2Vs bCBhcyBUQiBwcml2YXRlIGtleXMsIGFuZCBkb24ndCBkbyBUQiBwcm9vZnMgb24gMC1SVFQgcmVz dW1wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SWYgdGhlcmUgbW9yZSBwb3NpdGl2ZSBzdG9yaWVzIGFib3V0IGNvbXBhbmllcyBjaG9v c2luZyBzZWN1cml0eSBvdmVyIHNob3J0LXRlcm0gcHJvZml0cywgSSB3b3VsZCBwcmVmZXIgb3B0 aW9uIDEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkJpbGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_BLUPR03MB1396D4C18D5D082283D481DA8C820BLUPR03MB1396namp_-- From nobody Thu Mar 24 10:48:43 2016 Return-Path: <ynir.ietf@gmail.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 A9C8F12D713 for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 10:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 5rAqS6iM-QdH for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 10:48:26 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F0912D709 for <unbearable@ietf.org>; Thu, 24 Mar 2016 10:48:19 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id p65so76672314wmp.0 for <unbearable@ietf.org>; Thu, 24 Mar 2016 10:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j4qoyaawLbiheKy9Vcb6UIqOjF6M/htLFMEpdRjt7+s=; b=Lngv+kKcZaIW/k+9FPosy6Ml96PjOas2KD3ODh710v4LNQ//YigiDQ/PZ7eubyMN11 ZY8EP9RyyIxP19QQu64qcb7w8mHXOrF32lkU2abt1apUKy6KmFjlMyJXK8nnz/gIUIY4 8ogOs37bh8M2rIPzlZrkAs+H//0tjbxycd6gauBPkwNyPnBP5LP5bcRXmZfzaas/kdf5 ffbkg0+mQ+hrNrgZkGGlD2NWaYeFyjWxbyI1VjwxFP8rEbyscmgahzDrIdc74Tfe0/gu SjGlsJDEtBVyIyrMyT/bhQ2LqS/og1OgfklFFdl8Cvq1OvxApFuxC3cBKPxPhOQWBKWh dYkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j4qoyaawLbiheKy9Vcb6UIqOjF6M/htLFMEpdRjt7+s=; b=b7YFaof2wmcwR4hdJ4h+mCmvFHGBvB3IXAg0rlcDu7MMbdO/Op9lF5iBIMnwUnzv8B lFf/u+J5t+VIWWVN5m8BQFYzXZHt7GhhlllKxGrapcWBQNBxTaza6jsg7ELUkwx3fwAp rc/0d66JOBhge20rTn700JDQCIN0vKovlZRJFzCGAOrcplihQhB3KfqCVH5YGlQY+I3V iWEllKs5thQA6FFb2QyTjtQiUZSeGx9dRrZt3si3PwraFnF8iEyJQTJBW3v2B+L2tcZF VTZQ/kKMeNPFuLCF5GbI4KKmTwxQCHVtO0iA+qQAQhEsKt94NUfMBmr9Nuv6DZqkt7Bs yLFw== X-Gm-Message-State: AD7BkJLaEbLRhHEBoIhOwyaZU5xqSBwqaow2+CxAemr0UvMIavm0I5wZXvXccWat0+VNlw== X-Received: by 10.28.234.201 with SMTP id g70mr11788972wmi.40.1458841698185; Thu, 24 Mar 2016 10:48:18 -0700 (PDT) Received: from [192.168.1.13] (bzq-84-109-9-199.red.bezeqint.net. [84.109.9.199]) by smtp.gmail.com with ESMTPSA id m6sm8369988wje.21.2016.03.24.10.48.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 24 Mar 2016 10:48:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir <ynir.ietf@gmail.com> In-Reply-To: <42ADE97F-A7B4-43CF-81C3-BF5D64076917@oracle.com> Date: Thu, 24 Mar 2016 19:48:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <DE888F45-7258-47DD-89B8-85183AFADDE7@gmail.com> References: <CAH9QtQHpN=hh6Yg05vZ=vE=iVQc+91favOyqtutmMkqy14LX-A@mail.gmail.com> <56F29F69.1080105@treenet.co.nz> <CAH9QtQHs61xW9P_4TjQq-Jz=QPbVH9aDsYUUZc3fCNScQvcZPw@mail.gmail.com> <BLUPR03MB13964D90AE484B2639F816878C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CABkgnnWo5rriOpMzxsf=Yt1RFporTQJr5uMJ4QZ1Bhvhf93wRQ@mail.gmail.com> <56F3A5FD.3060705@treenet.co.nz> <C656BF88-97E9-4B0C-8482-DC8E2B4AFEBE@gmail.com> <B3384273-C6C0-4C09-8795-866B1EE288E6@inria.fr> <4BD383BB-84D1-4152-867E-22E52B47A331@gmail.com> <42ADE97F-A7B4-43CF-81C3-BF5D64076917@oracle.com> To: "Phil Hunt (IDM)" <phil.hunt@oracle.com> X-Mailer: Apple Mail (2.3124) Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/vJyvaAMYh5Dfm-LMNREpcZo-0w4> Cc: unbearable@ietf.org, Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>, Amos Jeffries <squid3@treenet.co.nz> Subject: Re: [Unbearable] We need a MitM extension X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 17:48:33 -0000 > On 24 Mar 2016, at 7:08 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> = wrote: >=20 > What about client side proxies? Such as when employees take laptops in = and out of work? >=20 > Web gateways/balancers that terminate tls are also an issue but I = understand the challenge. Can binding still be extended to the web = service? server-side proxies can share as much server-side state (including = private keys) with the server and/or with each other. They might need to = be upgraded, but they will work. Whatever implementers do to share state = between them and the servers is also fine because those proxies are as = trusted as the servers - they=E2=80=99re part of the stack. Client-side proxies are not part of the stack. They can forward tokens = (such as cookies) from client to server and back again, but any kind of = channel binding or key pinning will defeat them.=20 > Probably need to cover the limitations in detail even if not addressed = or addressable.=20 I agree. > Phil >=20 >> On Mar 24, 2016, at 09:15, Yoav Nir <ynir.ietf@gmail.com> wrote: >>=20 >>=20 >>> On 24 Mar 2016, at 10:36 AM, Karthik Bhargavan = <karthikeyan.bhargavan@inria.fr> wrote: >>>=20 >>> Is there value in designing a secure protocol =E2=80=9Cextension=E2=80= =9D that plays nice >>> with middle-boxes? How common/important is this problem? >>>=20 >>> (with the researcher hat on) >>> -Karthik >>=20 >> I use the same laptop both when I=E2=80=99m at home (where there is = not TLS proxy) and at work (where there is one). >>=20 >> My situation is not unique. We don=E2=80=99t necessarily need a = protocol extension to play nice with these proxies, but we need some = kind of good story of how things work for such a use case. If websites = that use our protocol will fail to display when I go to work, then major = websites will not deploy it. >>=20 >> If OTOH security is only degraded when behind the proxy (similar to = how we lose the EV indication) then it=E2=80=99s probably fine. >>=20 >> Yoav >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >=20 From nobody Thu Mar 24 14:35:48 2016 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 99D4F12D8EE for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 14:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 f28VO8xACR8j for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 14:35:45 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id BD3CF12D703 for <unbearable@ietf.org>; Thu, 24 Mar 2016 14:35:45 -0700 (PDT) Received: (qmail 21472 invoked by uid 0); 24 Mar 2016 21:35:42 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy2.mail.unifiedlayer.com with SMTP; 24 Mar 2016 21:35:42 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id a4bc1s00j2UhLwi014bf7Q; Thu, 24 Mar 2016 22:35:39 -0600 X-Authority-Analysis: v=2.1 cv=Maz/5fPf c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=1XWaLZrsAAAA:8 a=ieNpE_y6AAAA:8 a=NEAV23lmAAAA:8 a=EkAHJowxOGRsXTFdaesA:9 a=PJPA6yce8iprwTF8:21 a=Ja_CG1mvxYR2NZGz:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:To:From; bh=TjWOmRYJZM8zwyv4xWQtMOmBB4ND5Bmw2fXMKCMY9uE=; b=C83/wqB5B5HQYNCJxLssjx3Rxh bkxGULRL2WVkh0s/R05qQs5K0F0hMO6sxNABP/kykB+bstnUsf1grhouEWzkElDcJg7ArU9L48jZP ls34AaZKpkEhQg9SZbIdY7aHb; Received: from [73.202.80.238] (port=32882 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1ajCup-0006O8-Dc for unbearable@ietf.org; Thu, 24 Mar 2016 15:35:39 -0600 From: =JeffH <Jeff.Hodges@KingsMountain.com> To: IETF Tokbind WG <unbearable@ietf.org> Message-ID: <56F45DA8.6070303@KingsMountain.com> Date: Thu, 24 Mar 2016 14:35:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/aNCU6QSRbkqZbPAkEt_tP9yailw> Subject: Re: [Unbearable] Potential privacy bug if Include-Referer-Token-Binding-ID is improperly implemented client-side X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 21:35:47 -0000 On 3/22/16, 6:15 PM, "Unbearable on behalf of Nick Harper" <unbearable-bounces@ietf.org on behalf of nharper@google.com> wrote: >On Tue, Mar 22, 2016 at 6:10 PM, =JeffH ><Jeff.Hodges@kingsmountain.com> wrote: > >thx for clarifications, Nick. further questions & thoughts.. > >> Here's the problem: Suppose the connection to server A is over http. >> Now a network attacker B injects into some http page (from server C) >> code that will cause the client to make an http request to server A. >> The attacker B intercepts the request and responds with a redirect to >> server B (with the Include-Referer-Token-Binding-ID header). > >the redirect to B will be an HTTP 30x response not over TLS, regardless >of whether the Location: header field contains a https URI, yes? > >Correct. > >> The client dutifully follows that request and forwards the >> TokenBindingID it has for A to the attacker-controlled B. > >Should we not explicitly stipulate in -tokbind-https that the client MUST >NOT honor any Include-Referer-Token-Binding-ID header received over >insecure transport? This is how we addressed similar situations in the >HSTS and HPKP specs. > >The addition of >https://github.com/TokenBinding/Internet-Drafts/commit/2033a64397590a55811 >cb78af8f5aa739cb8c981 ><https://github.com/TokenBinding/Internet-Drafts/commit/2033a64397590a5581 >1cb78af8f5aa739cb8c981> implicitly states that (since the Token-Binding >header is not sent over an insecure transport). agreed, it does implicitly state that requirement, thx -- I had not thorougly reviewed Dirk's updates in -03. >I don't have strong feelings for whether this needs to be more > explicit. I would make it explicit. >> It would certainly be nice for the transport to be established error >> free, and to use HSTS and HPKP, but I don't think those need to be made >> as requirements for using Token Binding. > >I was not proposing stating any requirements wrt employing HSTS and HPKP >-- rather, I am thinking that we should have some deployment >considerations where HSTS and HPKP are dutifully mentioned and how their >use composes with TB to the benefit of the > web app provider and their users. From nobody Thu Mar 24 15:16:18 2016 Return-Path: <nharper@google.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 80F7C12D717 for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 15:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 1KiYWJdPMjLy for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 15:16:10 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC4E12D5D7 for <unbearable@ietf.org>; Thu, 24 Mar 2016 15:16:09 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id g127so77831596ywf.2 for <unbearable@ietf.org>; Thu, 24 Mar 2016 15:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1qP96EAk70j6J5XfIkIPZrbryfwuiYRTphb3uqoYXR0=; b=ZujpCTSz8u6PuSpjUaE98vo9pN76+V8zO2oFuJJz42m/bWFD8xXVhUGNSen5hfVvzU 148zlq4DOhonN4AZ1siZj2kNtcagwq6s1f9fp40VfsBz/62EgxCESBWOUbN822T+M6Yi M1K0pzao84n5sXS0ph5ULYjEmQlyifDTHcAERErcbe+Oe5AFq4tT+8AhYQFynuU5czY9 7wKL/hiI4qW9MrfEEQVQgvKQvvFwq9ykYsEF5omOCyjfzeTcXolxc/pLLKxfrCOlmKxX FeNDWd6EK6MjF6pLOa9sn6YeCxwNybMtGhwqS+Ax3GqHfjQ1KKGa8PPVWQXS/0FnL8Sb 38pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1qP96EAk70j6J5XfIkIPZrbryfwuiYRTphb3uqoYXR0=; b=Q1r8zt+JsLD/ov2563HmHS5b07n9fYzgCbkAOgwAVL77ZM/Zg7RhafAfLqHwY/NJXZ rmHAMXuc6BUAdiO6OwmfgCO+MWovAUru9IdVUnceW0LF+UhIY7mX0OqxvfaSt7Kj3z5y +7LfGTEH7SIhfaE2XOb1pedOnMFom2EH3bAbl8tB/vvFVyXdK2AzPHjJkIIiqs9SMTof /Nf87CZ8JfrskCFxwtr/XM1fXynm41iw/qSNWaUOmPoEQN0aGl6i2LQnDY09K6YAIyQP 1kXi22q1BacjsOxOldbMBfK3EC1LLqXymKQOUNR+GVWrutceFa6k6fQLg3tOZnJsJ/0N c2Mg== X-Gm-Message-State: AD7BkJKVpfYH8vP1zdm91/C9cOXc0fIMEHOhn/XJW9w/TSpo1pakheO+ludcpT/lwbQEHf4V2Pk4fq+judIebLVB X-Received: by 10.159.37.100 with SMTP id 91mr5261152uaz.79.1458857768824; Thu, 24 Mar 2016 15:16:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.76.198 with HTTP; Thu, 24 Mar 2016 15:15:49 -0700 (PDT) In-Reply-To: <CACdeXiLKjN3-ePh=PCX_sh8+cDAyEhJxa=mxM543OL6KQFUGvg@mail.gmail.com> References: <56EF4B9B.7000609@KingsMountain.com> <CADHfa2ACdV_mdm-R-23PajYUzHJ8nG2QN680aXxN2zqKLtB0Vw@mail.gmail.com> <CACdeXiLKjN3-ePh=PCX_sh8+cDAyEhJxa=mxM543OL6KQFUGvg@mail.gmail.com> From: Nick Harper <nharper@google.com> Date: Thu, 24 Mar 2016 15:15:49 -0700 Message-ID: <CACdeXiLN7LH1=efHSUKx6hc=L2sWuZrzcJHSuQV0T_UG_KFb+Q@mail.gmail.com> To: Dirk Balfanz <balfanz@google.com> Content-Type: multipart/alternative; boundary=94eb2c122da417357d052ed2cb0c Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/UUACl935R7Z_MupdJ4alcJRKHCs> Cc: IETF Tokbind WG <unbearable@ietf.org>, David Benjamin <davidben@google.com>, =JeffH <Jeff.Hodges@kingsmountain.com> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 22:16:16 -0000 --94eb2c122da417357d052ed2cb0c Content-Type: text/plain; charset=UTF-8 TL;DR: Use Include-Referer-Token-Binding-ID. Binding a token to an ID that hasn't been verified can result in a MitM getting control of a bound token. Dirk and I chatted about my/David's proposal, and how it applies to Jeff's scenario. In steps 3a and 3b from figure 1, TBID3 needs to be referred to TP4 (in addition to conveying TBID2). The problem with the current setup of figure 1 is when there is an attacker MitMing connections to TP3. In step 2b, the TokenBindingMessage contains TBID3' and TBID2', both under attacker control. Then, in step 3b, when the client follows the redirect from (the MitM'd) TP3 to TP4, it includes TBID4, but not TBID3, in the TokenBindingMessage. When TP4 authenticates the user, TBID4 is correct, and then TP4 creates a token for the user's identity with an attacker-controlled TBID. Even if TP3 and TP4 are somehow cooperating, and the provided and referred token bindings from the request in step 2b are passed from TP3 to TP4 out-of-band, the token still has an attacker controlled TBID, since the token bindings sent in step 2b are attacker controlled. I think the takeaway from this is when a federated token is created and bound to a referred TBID, the provided TBID (that the user's identity is bound to) and the referred TBID must both be verified as being possessed by the *same* client. The easiest way to do this is to have the provided TBID and the referred TBID in the same TokenBindingMessage. On Mon, Mar 21, 2016 at 1:40 PM, Nick Harper <nharper@google.com> wrote: > My understanding of the problem in figure 1 is that 1) in the redirect > from TC2 to TP3, the referred TBID is is TBID2, while the redirect uri is > to TC1, and 2) when TP3 redirects to TP4, somehow TBID2 needs to be > relayed. Please correct me if that is wrong or incomplete. > > One way to solve problem 2 is to treat the TP3->TP4 redirect like the > "identity-as-a-service" scenario that Dirk mentioned. Instead of TP4 > redirecting to TC1, it can create a token to be consumed by TP3, and > redirect to TP3, which will then create a token to send back to TC1. > > For problem 1, I am going to assume that TC1 and TC2 are cooperating. The > easiest way to fix this is to have TC2 transmit to TC1 out-of-band what > TBID2 is so that TC1 can verify it. > > Here's another solution (for both problems) that I think could work > (credit to David Benjamin for initially proposing it). I'm going to use > OpenID Connect terminology here, but I imagine this could be adapted for > other federated protocols. When the clients makes the OIDC authentication > request, it includes the TBID in the nonce query param. Regardless of what > happens in terms of redirects from TP3->TP4 (or anything else), the token > that the client sends back to the token consumer will have the TBID in the > nonce claim. For the case of TC1 redirects to TC2 which then does the > redirect for the authentication request, TC1 can pass the TBID to TC2 in a > query param. > > By moving the referred Token Binding ID from the tbproto (and tbhttps) to > the federation protocol, it simplifies the setup and implementation of > both. User-agents no longer have to handle the > Include-Referer-Token-Binding-ID header; identity providers don't have to > do anything additional with creating a new claim and plumbing the TBID from > the Sec-Token-Binding header into the new claim; the token consumer doesn't > have to worry about whether the token provider supports token binding (or > the same key params), as it will always get back a bound token. > > The only downside I see (so far) to this approach is that the token > provider has no way to verify that the client has possession of the private > key for the referred Token Binding ID. What security benefits are provided > by the token provider verifying proof of possession? As far as I could > tell, it could open up a token injection attack, but that would be thwarted > by the federation protocol's CSRF protection. > > On Sun, Mar 20, 2016 at 11:03 PM, Dirk Balfanz <balfanz@google.com> wrote: > >> >> >> On Sun, Mar 20, 2016 at 6:17 PM =JeffH <Jeff.Hodges@kingsmountain.com> >> wrote: >> >>> >> On 3/7/16, 4:24 PM nharper@google.com> wrote: >>> >>> >>> >>> If a client receives an "Include-Referer-Token-Binding-ID" header in >>> >>> response to a request that already had a referred TBID in the >>> >>> TokenBindingMessage, should it include both of those TBIDs as >>> referred >>> >>> TBIDs in the next request? >>> >>> >>> >>> I.e. >>> >>> - client sends request to server A w/ provided TBID A >>> >>> - gets back Include-Referer-Token-Binding-ID header on a redirect to >>> B >>> >>> - client sends request to B w/ provided TBID B, referred TBID A >>> >>> - gets back Include-Referer-Token-Binding-ID header on a redirect to >>> C >>> >>> Possible behaviors: >>> >>> i) client sends request to C w/ provided TBID C, referred TBID B, >>> >>> referred TBID A >>> >>> ii) client sends request to C w/ provided TBID C, referred TBID B >>> >>> >>> >>> iii) client sends request to C w/ provided TBID C, referred TBID A, >>> >>> referred TBID B >>> >>> >>> On Fri, 11 Mar 2016 Dirk replied: >>> > The intended semantics in the current spec is ii). >>> >>> what you mean that is that the TokenBindingMessage (TBMSG) contains only >>> two >>> TokenBindings in this case, and the TBMSG is included in an HTTP request >>> from the client to server only when satisfying a redirect that is >>> crossing >>> "functional boundaries" as noted below, yes? >>> >>> [ "current spec" discussed herein = -tokbind-https-02 aka HTTPSTB, >>> other specs.. >>> -tokbind-negotiation-02 aka TBNEGO >>> -tokbind-protocol-04 aka TBPROTO ] >>> >>> On Fri, 11 Mar 2016 Dirk further replied: >>> > I believe that covers all the use cases that you're describing: Let's >>> first >>> > consider the case where there is one Relying Party, and one Identity >>> > Provider. The RP might go through a bunch of redirects before >>> ultimately >>> > handing things off to the IdP, and the IdP might go through a bunch of >>> > redirects before ultimately handling the RP request. Same on the way >>> back >>> > from the IdP to the RP. >>> >>> understood. >>> >>> > The one redirect where the referred token binding is necessary is the >>> > redirect that crosses functional boundaries: from the RP to the IdP. >>> >>> agreed. >>> >>> > If the >>> > first endpoint at the IdP isn't the one that is processing the RP >>> request >>> > (because, say, it's the old one and it's now redirecting to the new >>> one), >>> > that endpoint needs to encode the information it learns (i.e., what is >>> the >>> > public key that the client is using with the RP) in some way (which >>> can be >>> > proprietary to the IdP) and pass that along as the request is handed >>> off. >>> >>> agreed that the above works in the case where the Token Consumer (RP) >>> that >>> redirects to IdP1 is the intended recipient of the eventual token-bound >>> ID >>> token. >>> >>> However, federation protocols have a notion of a 'return address' that's >>> typically included in the RP's 'authn request'. E.g., in OIDC it is the >>> "redirect_uri" [1], and in SAML the equivalent is the >>> "AssertionConsumerServiceURL" [2]. >>> >>> Upon issuance of the security token, the IDP redirects the UA to the >>> specified 'return address', which does not necessarily point to the RP >>> entity that redirected the UA to the IDP, nor even any of the entities in >>> the RP's "redirect chain". >>> >>> So there needs to be some means for the IDP to receive the _correct_ >>> referred TBID to include in the security token it generates and then >>> returns >>> -- this is not necessarily the RP entity that redirected to the IDP. A >>> few >>> ways to address this in HTTPSTB perhaps are.. >>> >>> We could mandate in HTTPSTB that the receiving RP entity (aka Token >>> Consumer) MUST have the same eTLD+1 as the RP entity that redirected (aka >>> "handed off") to the IDP. (see below for discussion of TB scoping rules) >>> >>> Or, we could attempt to devise a means for the RP entities to signal the >>> correct referred TBID to the IDP via HTTPSTB/TBPROTO. >>> >>> Or, we could punt the problem to deployers and say something like "the >>> referred TBID in the TBMSG MUST map to the entity specified in the authn >>> request's return address -- i.e., the TBID included in the issued >>> security >>> token by the IDP needs to match the client's TLS connection with the >>> entity >>> who will _receive_ the security token, even if the latter entity is not >>> the >>> one to redirect to the IDP" -- it is implementers' and deployers' >>> responsibility to get this right. >>> >>> See [figure 1] at end below. >>> >>> >>> > On the way back, after the IdP redirects back to the RP, the RP just >>> needs >>> > to make sure that one of the endpoints in the redirect chain is on the >>> same >>> > eTLD+1 as the endpoint that did the hand-off to the IdP, so it can >>> process >>> > the IdP response there. >>> >>> hm, perhaps there are some issues here.. >>> >>> * with regards to processing the IDP response ... is the above-stated >>> eTLD+1 >>> requirement because the client aka user agent (UA) will use the same >>> provided TBID with servers whose hostnames map to the same eTLD+1 ? >>> -tokbind-protocol aka TBPROTO says.. >>> >>> ... In order to prevent cooperating servers from linking user >>> identities, different keys SHOULD be used by the client for >>> connections to different servers, according to the token scoping >>> rules of the application protocol. >>> >>> ..so it seems we are assuming (in HTTPSTB) that HTTPS clients map the >>> servers to eTLD+1 when generating their TB key pairs, and afix >>> Token-Binding >>> header fields to their HTTP msgs per said mapping, yes? >>> >>> some thoughts/issues.. >>> >>> - eTLD and eTLD+1 are not mentioned in HTTPSTB >>> >>> - HTTPSTB does not explicitly define which particular "token scoping >>> rules" impls must adhere to. Is the client-side TBID >>> storage-and-mapping >>> model intended to map only to domain names, and in this case be >>> "domain >>> lowered" to eTLD+1 (modulo publicsuffix.org) similarly to how >>> cookies' >>> domain-matching works? [3][4] >>> >> >> Just added language to that effect in a new "Privacy Considerations" >> section in -03. Take a look and see whether you like it / have some ideas >> to improve on it. >> >> >>> >>> - what about servers that are identified by IP address? Note that in >>> HSTS >>> we punted on supporting servers identified by IP addresses [5]. Tho, >>> in >>> RFC6265 a server addressed by IP address can set cookies, but only >>> for >>> itself (i.e., the host-only flag is set to true [6]; i.e., cookie >>> "domain lowering" is undefined for IP addresses). Is >>> allowing/disallowing a host-only IP address-based TBID mapping >>> something we should consider generally for TBPROTO, or >>> just specifically consider for HTTSTB? >>> >> >> I'd say that servers identified by IP addresses will get keys scoped to >> that exact IP address - just like cookies. I think it belongs in HTTPSTB as >> a SHOULD for web browsers. >> >> Dirk. >> >> >>> >>> >>> > Next, let's consider what happens if there are multiple IdP's >>> involved, say >>> > something like rp.com -> identity-as-a-service.com -> idp.com. In that >>> > case, identity-as-a-service.com acts like an IdP to rp.com, and as an >>> RP to >>> > idp.com, so we play the game described above twice. It wouldn't make >>> sense >>> > here if idp.com somehow knew what public key the client is using with >>> rp.com >>> > - it's useless information. In a scenario like this, idp.com needs to >>> > strongly authenticate the client to identity-as-a-service.com, not to >>> rp.com >>> >>> Agreed, in this particular, tightly-constrained scenario. >>> >>> HTH, >>> >>> =JeffH >>> >>> >>> [1] https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest >>> >>> [2] https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf >>> >>> [3] https://tools.ietf.org/html/rfc6265#section-5.1.3 >>> >>> [4] http://identitymeme.org/http-cookie-processing-algorithm-etlds/ >>> >>> [5] https://tools.ietf.org/html/rfc6797#appendix-A >>> >>> [6] https://tools.ietf.org/html/rfc6265#section-5.3 - step 6. >>> >>> >>> >>> [figure 1] >>> >>> What: Analysis of redirect hops at RP aka TC and at IDP aka TP >>> >>> Legend: >>> >>> EKM: TLS Exported Keying Material [RFC5705] >>> >>> {EKMn}Ksm: EKM for server "n", signed by private key of TBID "m", >>> where "n" must represent server receiving the ETBMSG, >>> if a conveyed TB's type is provided_token_binding, then >>> m = n, else if TB's type is referred_token_binding, then >>> m != n. E.g., see step 1b in diagram below. >>> >>> ETBMSG: "Token-Binding" HTTP header field conveying an >>> EncodedTokenBindingMessage, in turn conveying >>> TokenBinding (TB)struct(s), e.g.: >>> ETBMSG[[TB]] or ETBMSG[[TB1],[TB2]] >>> >>> ID Token: the "ID Token" in OIDC, it is the semantic equivalent >>> of a SAML "authentication assertion". "ID Token w/TBIDn" >>> denotes a "token bound" ID Token containing TBIDn. >>> >>> Ks & Kp: private (aka secret) key, and public key, respectively, >>> of client-side Token Binding key pair >>> >>> OIDC: Open ID Connect >>> >>> TB: TokenBinding struct containing signed EKM, TBID, and >>> TB type, e.g.: [{EKM1}Ks1,TBID1,provided_token_binding] >>> >>> TBIDn: Token Binding ID for client and server n's token-bound >>> TLS association. TBIDn contains Kpn. >>> >>> >>> >>> Token Consumer, Token Provider, >>> aka: aka: >>> OpenID Client, OpenID Provider, >>> Client, OIDC Relying Party, OIDC Provider, >>> aka: SAML Relying Party SAML Identity >>> Provider >>> User Agent [ servers "1", "2" ] [ servers "3", "4" >>> ] >>> +--------+ +-----+ +-----+ +-----+ +-----+ >>> | Client | | TC1 | | TC2 | | TP3 | | TP4 | >>> +--------+ +-----+ +-----+ +-----+ +-----+ >>> | | | | | >>> | | | | | >>> | 0. Client interacts w/TC1 | | >>> | over HTTPS, establishes Ks1 & Kp1, TBID1 | | >>> | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | | >>> |------------------------------>| | | | >>> | | | | | >>> | | | | | >>> | 1a. redirect to TC2 for TC-specific reasons | | >>> | any security-relevant cookies should contain TBID1 | | >>> +<- - - - - - - - - - - - - - - - | | | | >>> . | | | | | >>> +----------------------------------------->| | | >>> | 1b. establishes Ks2 & Kp2, TBID2 | | | >>> | ETBMSG[[{EKM2}Ks2,TBID2,provided_token_binding]] | | >>> | | | | | >>> | | | | | >>> | | | | | >>> | 2a. OIDC ID Token request, | | | | >>> | aka "Authentication Request" w/ redirect_uri=TC1; <-- note well >>> | conveyed w/ HTTP response header field of: >>> | Include-Referer-Token-Binding-ID:true | | >>> | any security-relevant cookies should contain TBID2 | | >>> +<- - - - - - - - - - - - - - - - - - - - -| | | >>> . | (redirect to TP via 301, 302, | | | | >>> . | 303, 307, or 308) | | | | >>> . | | | | | >>> +----------------------------------------------------->| | >>> | 2b. client opens HTTPS w/ TP3, | | | >>> | establishes Ks3, Kp3, TBID3; | | | >>> | sends GET or POST with | | | >>> | ID Token request w/ redirect_uri=TC1, | | | >>> | ETBMSG[[{EKM3}Ks3,TBID3,provided_token_binding], | >>> | [{EKM3}Ks2,TBID2,referred_token_binding]] <-- but ID Tok >>> request >>> | | | <-- is for TC1 >>> | | | >>> | | | | | >>> | | | | | >>> | 3a. redirect to TP4 for TP-specific reasons | | >>> | any security-relevant cookies should contain TBID3 | | >>> +<- - - - - - - - - - - - - - - - - - - - - - - - - - -| | >>> . | | | | | >>> +--------------------------------------------------------------->| >>> | 3b. client opens HTTPS w/ TP4, | | | >>> | establishes Ks4 & Kp4, TBID4 | | | >>> | ETBMSG[[{EKM4}Ks4,TBID4,provided_token_binding]] | | >>> | *** as well as the ID Token request w/ redirect_uri=TC1; >>> | *** also, somehow conveys TBID2 to TP4 ? >>> | | | | | >>> | | | | | >>> | | | | | >>> | 4. user authentication (if applicable, | | >>> | methods vary, particulars are out of scope) | | >>> |<============================================================>| >>> | (TP generates ID Token for TC1 containing TBID1 - TP4 has only >>> TBID2 >>> | also set cookie(s) containing TBID4 and/or TBID3 >>> | details vary) | | | | >>> | | | | | >>> | | | | | >>> | | | | | >>> | 5a. ID Token issued for TC1, containing TBID1, <-- how do this if >>> | conveyed via OIDC "Authentication Response" <-- don't have >>> TBID1? >>> +<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| >>> . | (redirect to TC1) | | | | >>> . | | | | | >>> +-------------------------------->| | | | >>> | 5b. HTTPS GET or POST with | | | | >>> | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | | >>> | conveying Authn Reponse containing ID Token w/TBID1, | >>> | issued for TC1 | >>> | | | | | >>> | | | | | >>> | | | | | >>> | | | | | >>> | 6. user is signed-on, any security-relevant cookie(s) | >>> | that are set SHOULD contain TBID1 | | | >>> |<------------------------------| | | | >>> | | | | | >>> | | | | | >>> >>> >>> end >>> >>> >>> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >> >> > --94eb2c122da417357d052ed2cb0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">TL;DR: Use Include-Referer-Token-Binding-ID. Binding a tok= en to an ID that hasn't been verified can result in a MitM getting cont= rol of a bound token.<div><br></div><div>Dirk and I chatted about my/David&= #39;s proposal, and how it applies to Jeff's scenario. In steps 3a and = 3b from figure 1, TBID3 needs to be referred to TP4 (in addition to conveyi= ng TBID2). The problem with the current setup of figure 1 is when there is = an attacker MitMing connections to TP3. In step 2b, the TokenBindingMessage= contains TBID3' and TBID2', both under attacker control. Then, in = step 3b, when the client follows the redirect from (the MitM'd) TP3 to = TP4, it includes TBID4, but not TBID3, in the TokenBindingMessage. When TP4= authenticates the user, TBID4 is correct, and then TP4 creates a token for= the user's identity with an attacker-controlled TBID. Even if TP3 and = TP4 are somehow cooperating, and the provided and referred token bindings f= rom the request in step 2b are passed from TP3 to TP4 out-of-band, the toke= n still has an attacker controlled TBID, since the token bindings sent in s= tep 2b are attacker controlled.=C2=A0</div><div><br></div><div>I think the = takeaway from this is when a federated token is created and bound to a refe= rred TBID, the provided TBID (that the user's identity is bound to) and= the referred TBID must both be verified as being possessed by the *same* c= lient. The easiest way to do this is to have the provided TBID and the refe= rred TBID in the same TokenBindingMessage.<br></div><div><div class=3D"gmai= l_extra"><br><div class=3D"gmail_quote">On Mon, Mar 21, 2016 at 1:40 PM, Ni= ck Harper <span dir=3D"ltr"><<a href=3D"mailto:nharper@google.com" targe= t=3D"_blank">nharper@google.com</a>></span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"><div dir=3D"ltr">My understanding of the problem in figure 1 = is that 1) in the redirect from TC2 to TP3, the referred TBID is is TBID2, = while the redirect uri is to TC1, and 2) when TP3 redirects to TP4, somehow= TBID2 needs to be relayed. Please correct me if that is wrong or incomplet= e.<div><br></div><div>One way to solve problem 2 is to treat the TP3->TP= 4 redirect like the "identity-as-a-service" scenario that Dirk me= ntioned. Instead of TP4 redirecting to TC1, it can create a token to be con= sumed by TP3, and redirect to TP3, which will then create a token to send b= ack to TC1.</div><div><br></div><div>For problem 1, I am going to assume th= at TC1 and TC2 are cooperating. The easiest way to fix this is to have TC2 = transmit to TC1 out-of-band what TBID2 is so that TC1 can verify it.</div><= div><br></div><div>Here's another solution (for both problems) that I t= hink could work (credit to David Benjamin for initially proposing it). I= 9;m going to use OpenID Connect terminology here, but I imagine this could = be adapted for other federated protocols. When the clients makes the OIDC a= uthentication request, it includes the TBID in the nonce query param. Regar= dless of what happens in terms of redirects from TP3->TP4 (or anything e= lse), the token that the client sends back to the token consumer will have = the TBID in the nonce claim. For the case of TC1 redirects to TC2 which the= n does the redirect for the authentication request, TC1 can pass the TBID t= o TC2 in a query param.</div><div><br></div><div>By moving the referred Tok= en Binding ID from the tbproto (and tbhttps) to the federation protocol, it= simplifies the setup and implementation of both. User-agents no longer hav= e to handle the Include-Referer-Token-Binding-ID header; identity providers= don't have to do anything additional with creating a new claim and plu= mbing the TBID from the Sec-Token-Binding header into the new claim; the to= ken consumer doesn't have to worry about whether the token provider sup= ports token binding (or the same key params), as it will always get back a = bound token.</div><div><br></div><div>The only downside I see (so far) to t= his approach is that the token provider has no way to verify that the clien= t has possession of the private key for the referred Token Binding ID. What= security benefits are provided by the token provider verifying proof of po= ssession? As far as I could tell, it could open up a token injection attack= , but that would be thwarted by the federation protocol's CSRF protecti= on.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><d= iv><div>On Sun, Mar 20, 2016 at 11:03 PM, Dirk Balfanz <span dir=3D"ltr">&l= t;<a href=3D"mailto:balfanz@google.com" target=3D"_blank">balfanz@google.co= m</a>></span> wrote:<br></div></div><blockquote class=3D"gmail_quote" st= yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>= <div><div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div><div><div dir= =3D"ltr">On Sun, Mar 20, 2016 at 6:17 PM =3DJeffH <<a href=3D"mailto:Jef= f.Hodges@kingsmountain.com" target=3D"_blank">Jeff.Hodges@kingsmountain.com= </a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:= 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>> On 3/7/16,= 4:24 PM <a href=3D"mailto:nharper@google.com" target=3D"_blank">nharper@go= ogle.com</a>> wrote:<br> >>><br> >>> If a client receives an "Include-Referer-Token-Binding-ID= " header in<br> >>> response to a request that already had a referred TBID in the<= br> >>> TokenBindingMessage, should it include both of those TBIDs as = referred<br> >>> TBIDs in the next request?<br> >>><br> >>> I.e.<br> >>> - client sends request to server A w/ provided TBID A<br> >>> - gets back Include-Referer-Token-Binding-ID header on a redir= ect to B<br> >>> - client sends request to B w/ provided TBID B, referred TBID = A<br> >>> - gets back Include-Referer-Token-Binding-ID header on a redir= ect to C<br> >>> Possible behaviors:<br> >>> i) client sends request to C w/ provided TBID C, referred TBID= B,<br> >>> referred TBID A<br> >>> ii) client sends request to C w/ provided TBID C, referred TBI= D B<br> >>><br> >>> iii) client sends request to C w/ provided TBID C, referred TB= ID A,<br> >>> referred TBID B<br> <br> <br> On Fri, 11 Mar 2016 Dirk replied:<br> > The intended semantics in the current spec is=C2=A0 ii).<br> <br> what you mean that is that the TokenBindingMessage (TBMSG) contains only tw= o<br> TokenBindings in this case, and the TBMSG is included in an HTTP request<br= > from the client to server only when satisfying a redirect that is crossing<= br> "functional boundaries" as noted below, yes?<br> <br> [ "current spec" discussed herein =3D -tokbind-https-02 aka HTTPS= TB,<br> =C2=A0 =C2=A0other specs..<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -tokbind-neg= otiation-02 aka TBNEGO<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -tokbind-pro= tocol-04 aka TBPROTO ]<br> <br> On Fri, 11 Mar 2016 Dirk further replied:<br> > I believe that covers all the use cases that you're describing: Le= t's first<br> > consider the case where there is one Relying Party, and one Identity<b= r> > Provider. The RP might go through a bunch of redirects before ultimate= ly<br> > handing things off to the IdP, and the IdP might go through a bunch of= <br> > redirects before ultimately handling the RP request. Same on the way b= ack<br> > from the IdP to the RP.<br> <br> understood.<br> <br> > The one redirect where the referred token binding is necessary is the<= br> > redirect that crosses functional boundaries: from the RP to the IdP.<b= r> <br> agreed.<br> <br> > If the<br> > first endpoint at the IdP isn't the one that is processing the RP = request<br> > (because, say, it's the old one and it's now redirecting to th= e new one),<br> > that endpoint needs to encode the information it learns (i.e., what is= the<br> > public key that the client is using with the RP) in some way (which ca= n be<br> > proprietary to the IdP) and pass that along as the request is handed o= ff.<br> <br> agreed that the above works in the case where the Token Consumer (RP) that<= br> redirects to IdP1 is the intended recipient of the eventual token-bound ID<= br> token.<br> <br> However, federation protocols have a notion of a 'return address' t= hat's<br> typically included in the RP's 'authn request'. E.g., in OIDC i= t is the<br> "redirect_uri" [1], and in SAML the equivalent is the<br> "AssertionConsumerServiceURL" [2].<br> <br> Upon issuance of the security token, the IDP redirects the UA to the<br> specified 'return address', which does not necessarily point to the= RP<br> entity that redirected the UA to the IDP, nor even any of the entities in<b= r> the RP's "redirect chain".<br> <br> So there needs to be some means for the IDP to receive the _correct_<br> referred TBID to include in the security token it generates and then return= s<br> -- this is not necessarily the RP entity that redirected to the IDP. A few<= br> ways to address this in HTTPSTB perhaps are..<br> <br> We could mandate in HTTPSTB that the receiving RP entity (aka Token<br> Consumer) MUST have the same eTLD+1 as the RP entity that redirected (aka<b= r> "handed off") to the IDP. (see below for discussion of TB scoping= rules)<br> <br> Or, we could attempt to devise a means for the RP entities to signal the<br= > correct referred TBID to the IDP via HTTPSTB/TBPROTO.<br> <br> Or, we could punt the problem to deployers and say something like "the= <br> referred TBID in the TBMSG MUST map to the entity specified in the authn<br= > request's return address -- i.e., the TBID included in the issued secur= ity<br> token by the IDP needs to match the client's TLS connection with the en= tity<br> who will _receive_ the security token, even if the latter entity is not the= <br> one to redirect to the IDP" -- it is implementers' and deployers&#= 39;<br> responsibility to get this right.<br> <br> See [figure 1] at end below.<br> <br> <br> > On the way back, after the IdP redirects back to the RP, the RP just n= eeds<br> > to make sure that one of the endpoints in the redirect chain is on the= same<br> > eTLD+1 as the endpoint that did the hand-off to the IdP, so it can pro= cess<br> > the IdP response there.<br> <br> hm, perhaps there are some issues here..<br> <br> * with regards to processing the IDP response ... is the above-stated eTLD+= 1<br> requirement because the client aka user agent (UA) will use the same<br> provided TBID with servers whose hostnames map to the same eTLD+1 ?<br> -tokbind-protocol aka TBPROTO says..<br> <br> =C2=A0 =C2=A0 ... In order to prevent cooperating servers from linking user= <br> =C2=A0 =C2=A0 identities, different keys SHOULD be used by the client for<b= r> =C2=A0 =C2=A0 connections to different servers, according to the token scop= ing<br> =C2=A0 =C2=A0 rules of the application protocol.<br> <br> ..so it seems we are assuming (in HTTPSTB) that HTTPS clients map the<br> servers to eTLD+1 when generating their TB key pairs, and afix Token-Bindin= g<br> header fields to their HTTP msgs per said mapping, yes?<br> <br> some thoughts/issues..<br> <br> =C2=A0 - eTLD and eTLD+1 are not mentioned in HTTPSTB<br> <br> =C2=A0 - HTTPSTB does not explicitly define which particular "token sc= oping<br> =C2=A0 =C2=A0 rules" impls must adhere to. Is the client-side TBID sto= rage-and-mapping<br> =C2=A0 =C2=A0 model intended to map only to domain names, and in this case = be "domain<br> =C2=A0 =C2=A0 lowered" to eTLD+1 (modulo <a href=3D"http://publicsuffi= x.org" rel=3D"noreferrer" target=3D"_blank">publicsuffix.org</a>) similarly= to how cookies'<br> =C2=A0 =C2=A0 domain-matching works? [3][4]<br></blockquote><div><br></div>= </div></div><div>Just added language to that effect in a new "Privacy = Considerations" section in -03. Take a look and see whether you like i= t / have some ideas to improve on it.</div><span><div>=C2=A0</div><blockquo= te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so= lid;padding-left:1ex"> <br> =C2=A0 - what about servers that are identified by IP address? Note that in= HSTS<br> =C2=A0 =C2=A0 we punted on supporting servers identified by IP addresses [5= ]. Tho, in<br> =C2=A0 =C2=A0 RFC6265 a server addressed by IP address can set cookies, but= only for<br> =C2=A0 =C2=A0 itself (i.e., the host-only flag is set to true [6]; i.e., co= okie<br> =C2=A0 =C2=A0 "domain lowering" is undefined for IP addresses). I= s<br> =C2=A0 =C2=A0 allowing/disallowing a host-only IP address-based TBID mappin= g<br> =C2=A0 =C2=A0 something=C2=A0 we should consider generally for TBPROTO, or<= br> =C2=A0 =C2=A0 just specifically consider for HTTSTB?<br></blockquote><div><= br></div></span><div>I'd say that servers identified by IP addresses wi= ll get keys scoped to that exact IP address - just like cookies. I think it= belongs in HTTPSTB as a SHOULD for web browsers.=C2=A0</div><span><font co= lor=3D"#888888"><div><br></div><div>Dirk.</div></font></span><div><div><div= >=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex"> <br> <br> > Next, let's consider what happens if there are multiple IdP's = involved, say<br> > something like <a href=3D"http://rp.com" rel=3D"noreferrer" target=3D"= _blank">rp.com</a> -> <a href=3D"http://identity-as-a-service.com" rel= =3D"noreferrer" target=3D"_blank">identity-as-a-service.com</a> -> <a hr= ef=3D"http://idp.com" rel=3D"noreferrer" target=3D"_blank">idp.com</a>. In = that<br> > case, <a href=3D"http://identity-as-a-service.com" rel=3D"noreferrer" = target=3D"_blank">identity-as-a-service.com</a> acts like an IdP to <a href= =3D"http://rp.com" rel=3D"noreferrer" target=3D"_blank">rp.com</a>, and as = an RP to<br> > <a href=3D"http://idp.com" rel=3D"noreferrer" target=3D"_blank">idp.co= m</a>, so we play the game described above twice. It wouldn't make sens= e<br> > here if <a href=3D"http://idp.com" rel=3D"noreferrer" target=3D"_blank= ">idp.com</a> somehow knew what public key the client is using with <a href= =3D"http://rp.com" rel=3D"noreferrer" target=3D"_blank">rp.com</a><br> > - it's useless information. In a scenario like this, <a href=3D"ht= tp://idp.com" rel=3D"noreferrer" target=3D"_blank">idp.com</a> needs to<br> > strongly authenticate the client to <a href=3D"http://identity-as-a-se= rvice.com" rel=3D"noreferrer" target=3D"_blank">identity-as-a-service.com</= a>, not to <a href=3D"http://rp.com" rel=3D"noreferrer" target=3D"_blank">r= p.com</a><br> <br> Agreed, in this particular, tightly-constrained scenario.<br> <br> HTH,<br> <br> =3DJeffH<br> <br> <br> [1] <a href=3D"https://openid.net/specs/openid-connect-core-1_0.html#AuthRe= quest" rel=3D"noreferrer" target=3D"_blank">https://openid.net/specs/openid= -connect-core-1_0.html#AuthRequest</a><br> <br> [2] <a href=3D"https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0= -os.pdf" rel=3D"noreferrer" target=3D"_blank">https://docs.oasis-open.org/s= ecurity/saml/v2.0/saml-core-2.0-os.pdf</a><br> <br> [3] <a href=3D"https://tools.ietf.org/html/rfc6265#section-5.1.3" rel=3D"no= referrer" target=3D"_blank">https://tools.ietf.org/html/rfc6265#section-5.1= .3</a><br> <br> [4] <a href=3D"http://identitymeme.org/http-cookie-processing-algorithm-etl= ds/" rel=3D"noreferrer" target=3D"_blank">http://identitymeme.org/http-cook= ie-processing-algorithm-etlds/</a><br> <br> [5] <a href=3D"https://tools.ietf.org/html/rfc6797#appendix-A" rel=3D"noref= errer" target=3D"_blank">https://tools.ietf.org/html/rfc6797#appendix-A</a>= <br> <br> [6] <a href=3D"https://tools.ietf.org/html/rfc6265#section-5.3" rel=3D"nore= ferrer" target=3D"_blank">https://tools.ietf.org/html/rfc6265#section-5.3</= a> - step 6.<br> <br> <br> <br> [figure 1]<br> <br> What: Analysis of redirect hops at RP aka TC and at IDP aka TP<br> <br> Legend:<br> <br> =C2=A0 =C2=A0EKM:=C2=A0 =C2=A0 =C2=A0 =C2=A0TLS Exported Keying Material [R= FC5705]<br> <br> =C2=A0 =C2=A0{EKMn}Ksm: EKM for server "n", signed by private key= of TBID "m",<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 where "n" must r= epresent server receiving the ETBMSG,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if a conveyed TB's typ= e is provided_token_binding, then<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m =3D n, else if TB's = type is referred_token_binding, then<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m !=3D n. E.g., see step 1= b in diagram below.<br> <br> =C2=A0 =C2=A0ETBMSG:=C2=A0 =C2=A0 "Token-Binding" HTTP header fie= ld conveying an<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 EncodedTokenBindingMessage= , in turn conveying<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TokenBinding (TB)struct(s)= , e.g.:<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ETBMSG[[TB]] or ETBMSG[[TB= 1],[TB2]]<br> <br> =C2=A0 =C2=A0ID Token:=C2=A0 the "ID Token" in OIDC, it is the se= mantic equivalent<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of a SAML "authentica= tion assertion". "ID Token w/TBIDn"<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 denotes a "token boun= d" ID Token containing TBIDn.<br> <br> =C2=A0 =C2=A0Ks & Kp:=C2=A0 =C2=A0private (aka secret) key, and public = key, respectively,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of client-side Token Bindi= ng key pair<br> <br> =C2=A0 =C2=A0OIDC:=C2=A0 =C2=A0 =C2=A0 Open ID Connect<br> <br> =C2=A0 =C2=A0TB:=C2=A0 =C2=A0 =C2=A0 =C2=A0 TokenBinding struct containing = signed EKM, TBID, and<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TB type, e.g.: [{EKM1}Ks1,= TBID1,provided_token_binding]<br> <br> =C2=A0 =C2=A0TBIDn:=C2=A0 =C2=A0 =C2=A0Token Binding ID for client and serv= er n's token-bound<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TLS association. TBIDn con= tains Kpn.<br> <br> <br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Token Consumer,=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Token Provider,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 aka:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0aka:<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OpenID Client,=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0OpenID Provider,<br> Client,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 OIDC Relying Party,=C2=A0 =C2=A0 OIDC Provider,<br> aka:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0SAML Relying Party=C2=A0 =C2=A0 =C2=A0SAML Ident= ity Provider<br> User Agent=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0[ servers "1", "2" ]=C2=A0 =C2=A0[ servers= "3", "4" ]<br> +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+-----+=C2=A0 +-----+=C2=A0 =C2=A0 =C2=A0+-----+=C2=A0 = =C2=A0+-----+<br> | Client |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| TC1 |=C2=A0 | TC2 |=C2=A0 =C2=A0 =C2=A0| TP3 |=C2=A0 = =C2=A0| TP4 |<br> +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+-----+=C2=A0 +-----+=C2=A0 =C2=A0 =C2=A0+-----+=C2=A0 = =C2=A0+-----+<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 0. Client interacts w/TC1=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| over HTTPS, establishes Ks1 & Kp1, TBID1=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]]=C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|------------------------------>|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 1a. redirect to TC2 for TC-specific reasons=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| any security-relevant cookies should contain TBID1 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0+<- - - - - - - - - - - - - - - - |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|<br> =C2=A0 =C2=A0. |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|<br> =C2=A0 =C2=A0+----------------------------------------->|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 1b. establishes Ks2 & Kp2, TBID2=C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| ETBMSG[[{EKM2}Ks2,TBID2,provided_token_binding]]=C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 2a. OIDC ID Token request,=C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| aka "Authentication Request" w/ redirect_ur= i=3DTC1;=C2=A0 <-- note well<br> =C2=A0 =C2=A0 =C2=A0| conveyed w/ HTTP response header field of:<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0Include-Referer-Token-Binding-ID:true=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= <br> =C2=A0 =C2=A0 =C2=A0| any security-relevant cookies should contain TBID2 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0+<- - - - - - - - - - - - - - - - - - - - -|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0. | (redirect to TP via 301, 302, |=C2=A0 =C2=A0 =C2=A0 =C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|<br> =C2=A0 =C2=A0. |=C2=A0 303, 307, or 308)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0. |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|<br> =C2=A0 =C2=A0+----------------------------------------------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 2b. client opens HTTPS w/ TP3,=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| establishes Ks3, Kp3, TBID3;=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| sends GET or POST with=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| ID Token request w/ redirect_uri=3DTC1,=C2=A0 |=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| ETBMSG[[{EKM3}Ks3,TBID3,provided_token_binding],=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0[{EKM3}Ks2,TBID2,referred_t= oken_binding]] <-- but ID Tok request<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 <-- is for TC1<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 3a. redirect to TP4 for TP-specific reasons=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| any security-relevant cookies should contain TBID3 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0+<- - - - - - - - - - - - - - - - - - - - - - - - - - -|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0. |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|<br> =C2=A0 =C2=A0+-------------------------------------------------------------= -->|<br> =C2=A0 =C2=A0 =C2=A0| 3b. client opens HTTPS w/ TP4,=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| establishes Ks4 & Kp4, TBID4=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| ETBMSG[[{EKM4}Ks4,TBID4,provided_token_binding]]=C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*** as well as the I= D Token request w/ redirect_uri=3DTC1;<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*** also, somehow co= nveys TBID2 to TP4 ?<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 4. user authentication (if applicable,=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 methods vary, particulars are out of sco= pe)=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|<br> =C2=A0 =C2=A0 =C2=A0| (TP generates ID Token for TC1 containing TBID1 - TP4= has only TBID2<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 also set cookie(s) containing TBID4 and/or TBID= 3<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 details vary)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 5a. ID Token issued for TC1, containing TBID1, <--= how do this if<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 conveyed via OIDC "Authentication R= esponse" <-- don't have TBID1?<br> =C2=A0 =C2=A0+<- - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - - -|<br> =C2=A0 =C2=A0. |=C2=A0 =C2=A0(redirect to TC1)=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0. |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|<br> =C2=A0 =C2=A0+-------------------------------->|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 5b. HTTPS GET or POST with=C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]]=C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| conveying Authn Reponse containing ID Token w/TBID1,= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i= ssued for TC1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 6. user is signed-on, any security-relevant cookie(s)= =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br> =C2=A0 =C2=A0 =C2=A0| that are set SHOULD contain TBID1=C2=A0 =C2=A0 =C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|<br> =C2=A0 =C2=A0 =C2=A0|<------------------------------|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> <br> <br> end<br> <br> <br> </blockquote></div></div></div></div> <br></div></div><span>_______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> <br></span></blockquote></div><br></div> </blockquote></div><br></div></div></div> --94eb2c122da417357d052ed2cb0c-- From nobody Thu Mar 24 21:42:09 2016 Return-Path: <martin.thomson@gmail.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 783BE12D14C for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 21:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 w4VcnEGVD7fC for <unbearable@ietfa.amsl.com>; Thu, 24 Mar 2016 21:42:07 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D00A12D12A for <unbearable@ietf.org>; Thu, 24 Mar 2016 21:42:07 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id m184so104562479iof.1 for <unbearable@ietf.org>; Thu, 24 Mar 2016 21:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=BeLFkiBct68bWgXyce+mBed97ObKLHsqz2UkDfn3o9E=; b=ANla5L14PB70FaP3a/5j3+HjOCqZ2yZg8o19x51J/Pw4BEXE7az212gw2//NeDMy02 p2/2OWd6JgWgST2zImUywcl7SzEBv0vmn8LR4zYrlEXEx3DelBv3R7i+n9cdvzwqaIaG zetuowc86wFvCsujpSE7l/1T+dKSM5o921Q4gDLpc1qlnMpfINMGL1LY4eaXFbO3vqlR A3jgTen8Ajr95tXyMt1x8BQv9Kk9PEmQk2/JSlo2vddJr6UWakJIDtPaDlhCplV+1CFj noaHgNdq0oZ4ly7SxknybRAXLpcPlQ4n5JVws6n7yfVnAPFz6IkNlyNmUoCM/lhVwBh5 mjKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=BeLFkiBct68bWgXyce+mBed97ObKLHsqz2UkDfn3o9E=; b=ajTZzXxbqpOJsw4UCP8cTf9yhtetBTEFb+ZnvTil3Bblw5EYU0bsYkLw3ncouVaLKU jAweCLvKdL6dOmud4G+rQHnhwEtItljY8nM/Sxh55GtonukEUqUXEnXtfyhGlnyYbEbc QNNWzQqGkSbQ6WnTkeVfcOv0QYr6M2MWjpPJU8chc9XgQas9YVb8wa8BGXwj26rsfabP 9XqvIiMIWE0CXRfvokqLm4a+aZTjK0uvyUJ7TEDi01bK1qXM1Kwh5DWBs+F8uyaa47uu I3i7YIExXZrD1dSBwGIYt9OoprnOBbRZ3MCEPhgcfAMG2YK9GBqxF56xKki6pvs3P2ww 1fwg== X-Gm-Message-State: AD7BkJLRRyO5zHNehf+hwMuhkMnVyx93chdnRe43vu1rBXNWegqtY1UuC/WHhH03jZAQyCvaghP+kunN5KmX1Q== MIME-Version: 1.0 X-Received: by 10.107.34.139 with SMTP id i133mr11329523ioi.108.1458880926493; Thu, 24 Mar 2016 21:42:06 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Thu, 24 Mar 2016 21:42:06 -0700 (PDT) In-Reply-To: <BLUPR03MB1396D4C18D5D082283D481DA8C820@BLUPR03MB1396.namprd03.prod.outlook.com> References: <CAH9QtQFLWGLgKGkD8BeuEsGAaumuqzheBgaiuOHKuUvZucuRWw@mail.gmail.com> <BLUPR03MB139616608F68A44A25D7A6758C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CAH9QtQFFppvqu42B_TuKDfO_6pMkTCBtzhDWbTh+PVfyPVGGyw@mail.gmail.com> <BLUPR03MB13961CA8EF0DE7D342ADDDC78C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CABkgnnW2v2cK-FRm59c5x3b3pWq6Lbbfvv65oSo2VjY9xdPYiQ@mail.gmail.com> <CAH9QtQFOWqXaon4xNHxRdxOb-EvDGoZXo=EdPbvi-nNTFKZA0g@mail.gmail.com> <BLUPR03MB1396D4C18D5D082283D481DA8C820@BLUPR03MB1396.namprd03.prod.outlook.com> Date: Fri, 25 Mar 2016 15:42:06 +1100 Message-ID: <CABkgnnW-L9WHFFPHvGATGnC7pV2mANggEYAzZ2aUwfp3uPwHMA@mail.gmail.com> From: Martin Thomson <martin.thomson@gmail.com> To: Andrei Popov <Andrei.Popov@microsoft.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/JqH1uuMB6GUeWbS9WlhCvtrQ5TI> Cc: Tokbind WG <unbearable@ietf.org>, Bill Cox <waywardgeek@google.com> Subject: Re: [Unbearable] Thoughts on TLS 0-RTT 1.3 compatibility X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 25 Mar 2016 04:42:08 -0000 On 25 March 2016 at 04:47, Andrei Popov <Andrei.Popov@microsoft.com> wrote: > This was my thinking originally, but if resumption secrets are equally > well-protected as the TB key, then why prove possession of the TB key at > resumption time? I don't get this line of reasoning at all. Resumption secrets don't get this enhanced level of protection without effort, and I'm not seeing any incentive to protect something like this to that degree. It's short-lived, and easily regenerated. A TB key is, at least to some degree, valuable over a moderately long period. A TB key[46] can benefit from existing infrastructure for storing asymmetric keys for authentication. Resumption secrets need TLS-version-specific logic in their use, which makes integration into HSM-like implementations much less appealing. --Martin [46] I really hope we aren't talking about the product of the exporter, because that's something that you generate and discard immediately. From nobody Fri Mar 25 10:10:38 2016 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 9296D12D1DB for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 10:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 gi0b0yVisg3d for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 10:10:36 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42E112D15F for <unbearable@ietf.org>; Fri, 25 Mar 2016 10:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mvww7GrtIx3Zq2Jn0BM/t2lV2V7nY/8uL0S4fq4wRbY=; b=MEWWyTJd6W5AkIfT92muLH4Y319AU409OdDf2Gzy167k2HbiqDPA+Bs9+J7+T4nhu/xv4VHXttmg4mI2DVjfwywi1kwM77CtfVU3+1RhzDYHLbmrW1R2qWG7JFgs39t5Irk6L2ykwNnGBD6TiYy1Uf8Zk/+klnhB/g49uqiAvFo= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.434.16; Fri, 25 Mar 2016 17:10:33 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0434.023; Fri, 25 Mar 2016 17:10:33 +0000 From: Andrei Popov <Andrei.Popov@microsoft.com> To: Martin Thomson <martin.thomson@gmail.com> Thread-Topic: [Unbearable] Thoughts on TLS 0-RTT 1.3 compatibility Thread-Index: AQHRhQcgxIK280Rw4Uycc/vXubnt6Z9nP4hwgAAeU4CAAAHIgIAAvQQAgACekICAACIeUIAAufoAgADL4xA= Date: Fri, 25 Mar 2016 17:10:33 +0000 Message-ID: <BLUPR03MB1396745AEBAA9911312ABD488C830@BLUPR03MB1396.namprd03.prod.outlook.com> References: <CAH9QtQFLWGLgKGkD8BeuEsGAaumuqzheBgaiuOHKuUvZucuRWw@mail.gmail.com> <BLUPR03MB139616608F68A44A25D7A6758C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CAH9QtQFFppvqu42B_TuKDfO_6pMkTCBtzhDWbTh+PVfyPVGGyw@mail.gmail.com> <BLUPR03MB13961CA8EF0DE7D342ADDDC78C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CABkgnnW2v2cK-FRm59c5x3b3pWq6Lbbfvv65oSo2VjY9xdPYiQ@mail.gmail.com> <CAH9QtQFOWqXaon4xNHxRdxOb-EvDGoZXo=EdPbvi-nNTFKZA0g@mail.gmail.com> <BLUPR03MB1396D4C18D5D082283D481DA8C820@BLUPR03MB1396.namprd03.prod.outlook.com> <CABkgnnW-L9WHFFPHvGATGnC7pV2mANggEYAzZ2aUwfp3uPwHMA@mail.gmail.com> In-Reply-To: <CABkgnnW-L9WHFFPHvGATGnC7pV2mANggEYAzZ2aUwfp3uPwHMA@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:3::1d2] x-ms-office365-filtering-correlation-id: d540a25e-cb71-4ece-396e-08d354d06087 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:0glIU+PF7u7o1zK6i7c4X0GbZ1rFZAHOOOqFQSYJTFJRe82+hrjsF6/z+gVB0qskaUPOTMw4Ume1k0J07gKD5PPQ9U/t+yhWqeKcccfh0GEKR8U1qRxUETmYFHI5SzJwrzKSILAGj4Ew9RnIRBa+Kw==; 24:cMFwd7R9gB9JAQ/AbGu+0QyThx0ZpJa27fKhD/sKIBLY7Zml3nbTUh9g84nnN0hFSFAhYFkeLNxr7snbRnhlzj8flEEnP2Ry9lw4ueSxgoI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: <BLUPR03MB1396A0C610D3C548FBDA09158C830@BLUPR03MB1396.namprd03.prod.outlook.com> x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 0892FA9A88 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(2950100001)(77096005)(2900100001)(74316001)(11100500001)(5004730100002)(5008740100001)(86612001)(93886004)(19580405001)(19580395003)(81166005)(54356999)(50986999)(76176999)(87936001)(33656002)(106116001)(8990500004)(99286002)(1096002)(86362001)(76576001)(1220700001)(5003600100002)(10090500001)(4326007)(122556002)(10290500002)(586003)(92566002)(3660700001)(189998001)(2906002)(10400500002)(3280700002)(6116002)(110136002)(102836003)(5002640100001)(5005710100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2016 17:10:33.5244 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/--ndbSPPdJgIH9DyIji9VoaNYTA> Cc: Tokbind WG <unbearable@ietf.org>, Bill Cox <waywardgeek@google.com> Subject: Re: [Unbearable] Thoughts on TLS 0-RTT 1.3 compatibility X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 25 Mar 2016 17:10:37 -0000 PiBBIFRCIGtleVs0Nl0gY2FuIGJlbmVmaXQgZnJvbSBleGlzdGluZyBpbmZyYXN0cnVjdHVyZSBm b3Igc3RvcmluZyBhc3ltbWV0cmljIGtleXMgZm9yIGF1dGhlbnRpY2F0aW9uLiAgDQo+IFJlc3Vt cHRpb24gc2VjcmV0cyBuZWVkIFRMUy12ZXJzaW9uLXNwZWNpZmljIGxvZ2ljIGluIHRoZWlyIHVz ZSwgd2hpY2ggbWFrZXMgaW50ZWdyYXRpb24gaW50byBIU00tbGlrZSBpbXBsZW1lbnRhdGlvbnMg bXVjaCBsZXNzIGFwcGVhbGluZy4NCg0KQ29ycmVjdCwgZXh0ZW5kaW5nIHN0cm9uZyBwcm90ZWN0 aW9uIHRvIFRMUyByZXN1bXB0aW9uIHNlY3JldHMgaXMgYSBzaWduaWZpY2FudCBhbW91bnQgb2Yg d29yayBmb3IgYSBUTFMgaW1wbGVtZW50ZXIuIEkgYWxzbyB0aGluayB0aGF0IHRoZSBhcHByb3By aWF0ZSBoYXJkd2FyZSB3aWxsIG5vdCBiZSB1bml2ZXJzYWxseSBhdmFpbGFibGUuIEhvd2V2ZXIs IGluIHRob3NlIGNhc2VzIHdoZXJlIHRoZSBUTFMgcmVzdW1wdGlvbiBzZWNyZXRzIGFyZSBzdHJv bmdseSBwcm90ZWN0ZWQsIHdpdGggYXBwcm9wcmlhdGUgSFcgc3VwcG9ydCBwcmVzZW50LCBpdCBt YXkgYmUgcG9zc2libGUgdG8gYXZvaWQgcHJvdmluZyBwb3NzZXNzaW9uIG9mIHRoZSBUQiBrZXkg b24gVExTIHJlc3VtcHRpb24uIEFuZCBpdCBtYXkgYmUgdGhlIG9ubHkgd2F5IHRvIHVzZSBUQiBp biBUTFMxLjMgMC1SVFQgbW9kZSwgd2hpbGUgcHJlc2VydmluZyBzZWN1cml0eSBhbmQgd2l0aG91 dCBhZGRpbmcgcm91bmQtdHJpcHMuDQoNCj4gUmVzdW1wdGlvbiBzZWNyZXRzIGRvbid0IGdldCB0 aGlzIGVuaGFuY2VkIGxldmVsIG9mIHByb3RlY3Rpb24gd2l0aG91dCBlZmZvcnQsIGFuZCBJJ20g bm90IHNlZWluZyBhbnkgaW5jZW50aXZlIHRvIHByb3RlY3Qgc29tZXRoaW5nIGxpa2UgdGhpcyB0 byB0aGF0IGRlZ3JlZS4NCg0KVG90YWxseSBhZ3JlZSBhYm91dCB0aGUgZWZmb3J0LCBidXQgaG93 IGFib3V0IHRoZXNlIGluY2VudGl2ZXM6DQoxLiBQcmV2ZW50IGF0dGFja2VycyBmcm9tIGV4cG9y dGluZyBUTFMgc2Vzc2lvbiByZXN1bXB0aW9uIHNlY3JldHM7DQoyLiBFbmFibGUgbW9yZSAwLVJU VCByZXN1bXB0aW9uIGluIFRMUyAoc2VjdXJlIHJlc3VtcHRpb24gc2VjcmV0cyBtaWdodCBiZSBs b25nZXItbGl2ZWQpOw0KMy4gRW5hYmxlIFRCIGluIDAtUlRUIG1vZGUuDQoNCkNoZWVycywNCg0K QW5kcmVpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNv biBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgTWFy Y2ggMjQsIDIwMTYgOTo0MiBQTQ0KVG86IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jv c29mdC5jb20+DQpDYzogQmlsbCBDb3ggPHdheXdhcmRnZWVrQGdvb2dsZS5jb20+OyBUb2tiaW5k IFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBUaG91 Z2h0cyBvbiBUTFMgMC1SVFQgMS4zIGNvbXBhdGliaWxpdHkNCg0KT24gMjUgTWFyY2ggMjAxNiBh dCAwNDo0NywgQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4gd3JvdGU6 DQo+IFRoaXMgd2FzIG15IHRoaW5raW5nIG9yaWdpbmFsbHksIGJ1dCBpZiByZXN1bXB0aW9uIHNl Y3JldHMgYXJlIGVxdWFsbHkgDQo+IHdlbGwtcHJvdGVjdGVkIGFzIHRoZSBUQiBrZXksIHRoZW4g d2h5IHByb3ZlIHBvc3Nlc3Npb24gb2YgdGhlIFRCIGtleSANCj4gYXQgcmVzdW1wdGlvbiB0aW1l Pw0KDQpJIGRvbid0IGdldCB0aGlzIGxpbmUgb2YgcmVhc29uaW5nIGF0IGFsbC4gIFJlc3VtcHRp b24gc2VjcmV0cyBkb24ndCBnZXQgdGhpcyBlbmhhbmNlZCBsZXZlbCBvZiBwcm90ZWN0aW9uIHdp dGhvdXQgZWZmb3J0LCBhbmQgSSdtIG5vdCBzZWVpbmcgYW55IGluY2VudGl2ZSB0byBwcm90ZWN0 IHNvbWV0aGluZyBsaWtlIHRoaXMgdG8gdGhhdCBkZWdyZWUuDQpJdCdzIHNob3J0LWxpdmVkLCBh bmQgZWFzaWx5IHJlZ2VuZXJhdGVkLiAgQSBUQiBrZXkgaXMsIGF0IGxlYXN0IHRvIHNvbWUgZGVn cmVlLCB2YWx1YWJsZSBvdmVyIGEgbW9kZXJhdGVseSBsb25nIHBlcmlvZC4NCg0KQSBUQiBrZXlb NDZdIGNhbiBiZW5lZml0IGZyb20gZXhpc3RpbmcgaW5mcmFzdHJ1Y3R1cmUgZm9yIHN0b3Jpbmcg YXN5bW1ldHJpYyBrZXlzIGZvciBhdXRoZW50aWNhdGlvbi4gIFJlc3VtcHRpb24gc2VjcmV0cyBu ZWVkIFRMUy12ZXJzaW9uLXNwZWNpZmljIGxvZ2ljIGluIHRoZWlyIHVzZSwgd2hpY2ggbWFrZXMg aW50ZWdyYXRpb24gaW50byBIU00tbGlrZSBpbXBsZW1lbnRhdGlvbnMgbXVjaCBsZXNzIGFwcGVh bGluZy4NCg0KLS1NYXJ0aW4NCg0KWzQ2XSBJIHJlYWxseSBob3BlIHdlIGFyZW4ndCB0YWxraW5n IGFib3V0IHRoZSBwcm9kdWN0IG9mIHRoZSBleHBvcnRlciwgYmVjYXVzZSB0aGF0J3Mgc29tZXRo aW5nIHRoYXQgeW91IGdlbmVyYXRlIGFuZCBkaXNjYXJkIGltbWVkaWF0ZWx5Lg0K From nobody Fri Mar 25 10:50:04 2016 Return-Path: <balfanz@google.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 5425912D527 for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 10:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 4lgwXLjynX9O for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 10:49:59 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE6112D553 for <unbearable@ietf.org>; Fri, 25 Mar 2016 10:49:57 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id l68so25007685wml.0 for <unbearable@ietf.org>; Fri, 25 Mar 2016 10:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z55sgiFfhkYXBkkHS9zEXwCCspJpYF7UPyz68tb/Jic=; b=KyST05S6nwC4L0SyzxZhht96E8BycTRJvI+3nogVP5mqCJR68nY0+qZZcXSBP7z/ia 33oZvOVjmDGzr7cgiO7rUwn6zRKVp9EGpEYMemNdBG+DBLG0ZNoFku5oibMVlndrG5FY H4EUykQ72bZe9D51PiPzs4GmFp5QwPOexFDF4lQSCSsR0xe1aWBb+Z+x0sYiueXyvN5s 8NfKsixlVZuTS4VCfnM9Tp7R6FJOt+JPTUFrcSl7iavQqxBBU6/YOty2J/O0RxbcBZ6j /sza3b+K7LWUX0U4Iyje7K550W0H2HRUZwFiDsgEIUXxYbJRR8+eq8Ok9SFM2bXDIXau +ulQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z55sgiFfhkYXBkkHS9zEXwCCspJpYF7UPyz68tb/Jic=; b=YAjQMcJkj7wAQo13zjfif5mKoN9VlTgjE9eoRMbTncBUMTZ0vnweNoEe1pQKdn6rYa 8Gn8p/KgLF8Q1YwVjEjTVLBiqH42WTOVprTOCCu8obq8ItPklOom3PQjrTFfokPzeH6a kLQvPT3ZvriXdz+Q/bsrYnAVakbapGLcy7K7MzMP25nsvFdPZeKqtlmhiFaIkkUFEcxZ msjqRpoJbfTcjU34gbyuPKblO/TdMbxodvEftl91TMqaCj5ZVnmseOaoSX0q0Wsz+MY7 41upFLg2uIDwTx49BJG0dz+HoOx5ITeuB2IJiEFo/7bdIbeEd9f0ER626d68F8gliI1p 0N1w== X-Gm-Message-State: AD7BkJJRAPIgOgo77MaaFxUqqa0Gpln18rui9ecP0CuB++zlaJ8aoFzwmm/gwcLcQiiiZDBTDYdfbFZuRJM4lj/z X-Received: by 10.28.135.4 with SMTP id j4mr17690644wmd.80.1458928196181; Fri, 25 Mar 2016 10:49:56 -0700 (PDT) MIME-Version: 1.0 References: <56EF4B9B.7000609@KingsMountain.com> <CADHfa2ACdV_mdm-R-23PajYUzHJ8nG2QN680aXxN2zqKLtB0Vw@mail.gmail.com> <CACdeXiLKjN3-ePh=PCX_sh8+cDAyEhJxa=mxM543OL6KQFUGvg@mail.gmail.com> <CACdeXiLN7LH1=efHSUKx6hc=L2sWuZrzcJHSuQV0T_UG_KFb+Q@mail.gmail.com> In-Reply-To: <CACdeXiLN7LH1=efHSUKx6hc=L2sWuZrzcJHSuQV0T_UG_KFb+Q@mail.gmail.com> From: Dirk Balfanz <balfanz@google.com> Date: Fri, 25 Mar 2016 17:49:44 +0000 Message-ID: <CADHfa2AwNU=Rjqavi6=TqX5RUgTXMmp9YzUUkKqqKoWV+t1_Zg@mail.gmail.com> To: Nick Harper <nharper@google.com> Content-Type: multipart/alternative; boundary=001a1144278ee33b0f052ee3301a Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/undP0OsWJVxl7VtAC_61-VRZ540> Cc: IETF Tokbind WG <unbearable@ietf.org>, David Benjamin <davidben@google.com>, =JeffH <Jeff.Hodges@kingsmountain.com> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 25 Mar 2016 17:50:03 -0000 --001a1144278ee33b0f052ee3301a Content-Type: text/plain; charset=UTF-8 Agreed. Bottom line is that I still believe that a single referred token binding (even on repeated redirects) gives us all we need. Having said that, it probably is a good idea to document best practices (as Nick has done here) to make sure IdPs and RPs don't shoot themselves in the foot. For example, when I first responded (on the other thread) and explained why I think that a single referred token binding is enough, I didn't realize that you have to redirect with Include-Referer-Token-Binding-ID *twice*, from RP to IdP, and also within the IdP (as Nick explains here). Dirk. On Thu, Mar 24, 2016 at 3:16 PM Nick Harper <nharper@google.com> wrote: > TL;DR: Use Include-Referer-Token-Binding-ID. Binding a token to an ID that > hasn't been verified can result in a MitM getting control of a bound token. > > Dirk and I chatted about my/David's proposal, and how it applies to Jeff's > scenario. In steps 3a and 3b from figure 1, TBID3 needs to be referred to > TP4 (in addition to conveying TBID2). The problem with the current setup of > figure 1 is when there is an attacker MitMing connections to TP3. In step > 2b, the TokenBindingMessage contains TBID3' and TBID2', both under attacker > control. Then, in step 3b, when the client follows the redirect from (the > MitM'd) TP3 to TP4, it includes TBID4, but not TBID3, in the > TokenBindingMessage. When TP4 authenticates the user, TBID4 is correct, and > then TP4 creates a token for the user's identity with an > attacker-controlled TBID. Even if TP3 and TP4 are somehow cooperating, and > the provided and referred token bindings from the request in step 2b are > passed from TP3 to TP4 out-of-band, the token still has an attacker > controlled TBID, since the token bindings sent in step 2b are attacker > controlled. > > I think the takeaway from this is when a federated token is created and > bound to a referred TBID, the provided TBID (that the user's identity is > bound to) and the referred TBID must both be verified as being possessed by > the *same* client. The easiest way to do this is to have the provided TBID > and the referred TBID in the same TokenBindingMessage. > > On Mon, Mar 21, 2016 at 1:40 PM, Nick Harper <nharper@google.com> wrote: > >> My understanding of the problem in figure 1 is that 1) in the redirect >> from TC2 to TP3, the referred TBID is is TBID2, while the redirect uri is >> to TC1, and 2) when TP3 redirects to TP4, somehow TBID2 needs to be >> relayed. Please correct me if that is wrong or incomplete. >> >> One way to solve problem 2 is to treat the TP3->TP4 redirect like the >> "identity-as-a-service" scenario that Dirk mentioned. Instead of TP4 >> redirecting to TC1, it can create a token to be consumed by TP3, and >> redirect to TP3, which will then create a token to send back to TC1. >> >> For problem 1, I am going to assume that TC1 and TC2 are cooperating. The >> easiest way to fix this is to have TC2 transmit to TC1 out-of-band what >> TBID2 is so that TC1 can verify it. >> >> Here's another solution (for both problems) that I think could work >> (credit to David Benjamin for initially proposing it). I'm going to use >> OpenID Connect terminology here, but I imagine this could be adapted for >> other federated protocols. When the clients makes the OIDC authentication >> request, it includes the TBID in the nonce query param. Regardless of what >> happens in terms of redirects from TP3->TP4 (or anything else), the token >> that the client sends back to the token consumer will have the TBID in the >> nonce claim. For the case of TC1 redirects to TC2 which then does the >> redirect for the authentication request, TC1 can pass the TBID to TC2 in a >> query param. >> >> By moving the referred Token Binding ID from the tbproto (and tbhttps) to >> the federation protocol, it simplifies the setup and implementation of >> both. User-agents no longer have to handle the >> Include-Referer-Token-Binding-ID header; identity providers don't have to >> do anything additional with creating a new claim and plumbing the TBID from >> the Sec-Token-Binding header into the new claim; the token consumer doesn't >> have to worry about whether the token provider supports token binding (or >> the same key params), as it will always get back a bound token. >> >> The only downside I see (so far) to this approach is that the token >> provider has no way to verify that the client has possession of the private >> key for the referred Token Binding ID. What security benefits are provided >> by the token provider verifying proof of possession? As far as I could >> tell, it could open up a token injection attack, but that would be thwarted >> by the federation protocol's CSRF protection. >> >> On Sun, Mar 20, 2016 at 11:03 PM, Dirk Balfanz <balfanz@google.com> >> wrote: >> >>> >>> >>> On Sun, Mar 20, 2016 at 6:17 PM =JeffH <Jeff.Hodges@kingsmountain.com> >>> wrote: >>> >>>> >> On 3/7/16, 4:24 PM nharper@google.com> wrote: >>>> >>> >>>> >>> If a client receives an "Include-Referer-Token-Binding-ID" header in >>>> >>> response to a request that already had a referred TBID in the >>>> >>> TokenBindingMessage, should it include both of those TBIDs as >>>> referred >>>> >>> TBIDs in the next request? >>>> >>> >>>> >>> I.e. >>>> >>> - client sends request to server A w/ provided TBID A >>>> >>> - gets back Include-Referer-Token-Binding-ID header on a redirect >>>> to B >>>> >>> - client sends request to B w/ provided TBID B, referred TBID A >>>> >>> - gets back Include-Referer-Token-Binding-ID header on a redirect >>>> to C >>>> >>> Possible behaviors: >>>> >>> i) client sends request to C w/ provided TBID C, referred TBID B, >>>> >>> referred TBID A >>>> >>> ii) client sends request to C w/ provided TBID C, referred TBID B >>>> >>> >>>> >>> iii) client sends request to C w/ provided TBID C, referred TBID A, >>>> >>> referred TBID B >>>> >>>> >>>> On Fri, 11 Mar 2016 Dirk replied: >>>> > The intended semantics in the current spec is ii). >>>> >>>> what you mean that is that the TokenBindingMessage (TBMSG) contains >>>> only two >>>> TokenBindings in this case, and the TBMSG is included in an HTTP request >>>> from the client to server only when satisfying a redirect that is >>>> crossing >>>> "functional boundaries" as noted below, yes? >>>> >>>> [ "current spec" discussed herein = -tokbind-https-02 aka HTTPSTB, >>>> other specs.. >>>> -tokbind-negotiation-02 aka TBNEGO >>>> -tokbind-protocol-04 aka TBPROTO ] >>>> >>>> On Fri, 11 Mar 2016 Dirk further replied: >>>> > I believe that covers all the use cases that you're describing: Let's >>>> first >>>> > consider the case where there is one Relying Party, and one Identity >>>> > Provider. The RP might go through a bunch of redirects before >>>> ultimately >>>> > handing things off to the IdP, and the IdP might go through a bunch of >>>> > redirects before ultimately handling the RP request. Same on the way >>>> back >>>> > from the IdP to the RP. >>>> >>>> understood. >>>> >>>> > The one redirect where the referred token binding is necessary is the >>>> > redirect that crosses functional boundaries: from the RP to the IdP. >>>> >>>> agreed. >>>> >>>> > If the >>>> > first endpoint at the IdP isn't the one that is processing the RP >>>> request >>>> > (because, say, it's the old one and it's now redirecting to the new >>>> one), >>>> > that endpoint needs to encode the information it learns (i.e., what >>>> is the >>>> > public key that the client is using with the RP) in some way (which >>>> can be >>>> > proprietary to the IdP) and pass that along as the request is handed >>>> off. >>>> >>>> agreed that the above works in the case where the Token Consumer (RP) >>>> that >>>> redirects to IdP1 is the intended recipient of the eventual token-bound >>>> ID >>>> token. >>>> >>>> However, federation protocols have a notion of a 'return address' that's >>>> typically included in the RP's 'authn request'. E.g., in OIDC it is the >>>> "redirect_uri" [1], and in SAML the equivalent is the >>>> "AssertionConsumerServiceURL" [2]. >>>> >>>> Upon issuance of the security token, the IDP redirects the UA to the >>>> specified 'return address', which does not necessarily point to the RP >>>> entity that redirected the UA to the IDP, nor even any of the entities >>>> in >>>> the RP's "redirect chain". >>>> >>>> So there needs to be some means for the IDP to receive the _correct_ >>>> referred TBID to include in the security token it generates and then >>>> returns >>>> -- this is not necessarily the RP entity that redirected to the IDP. A >>>> few >>>> ways to address this in HTTPSTB perhaps are.. >>>> >>>> We could mandate in HTTPSTB that the receiving RP entity (aka Token >>>> Consumer) MUST have the same eTLD+1 as the RP entity that redirected >>>> (aka >>>> "handed off") to the IDP. (see below for discussion of TB scoping rules) >>>> >>>> Or, we could attempt to devise a means for the RP entities to signal the >>>> correct referred TBID to the IDP via HTTPSTB/TBPROTO. >>>> >>>> Or, we could punt the problem to deployers and say something like "the >>>> referred TBID in the TBMSG MUST map to the entity specified in the authn >>>> request's return address -- i.e., the TBID included in the issued >>>> security >>>> token by the IDP needs to match the client's TLS connection with the >>>> entity >>>> who will _receive_ the security token, even if the latter entity is not >>>> the >>>> one to redirect to the IDP" -- it is implementers' and deployers' >>>> responsibility to get this right. >>>> >>>> See [figure 1] at end below. >>>> >>>> >>>> > On the way back, after the IdP redirects back to the RP, the RP just >>>> needs >>>> > to make sure that one of the endpoints in the redirect chain is on >>>> the same >>>> > eTLD+1 as the endpoint that did the hand-off to the IdP, so it can >>>> process >>>> > the IdP response there. >>>> >>>> hm, perhaps there are some issues here.. >>>> >>>> * with regards to processing the IDP response ... is the above-stated >>>> eTLD+1 >>>> requirement because the client aka user agent (UA) will use the same >>>> provided TBID with servers whose hostnames map to the same eTLD+1 ? >>>> -tokbind-protocol aka TBPROTO says.. >>>> >>>> ... In order to prevent cooperating servers from linking user >>>> identities, different keys SHOULD be used by the client for >>>> connections to different servers, according to the token scoping >>>> rules of the application protocol. >>>> >>>> ..so it seems we are assuming (in HTTPSTB) that HTTPS clients map the >>>> servers to eTLD+1 when generating their TB key pairs, and afix >>>> Token-Binding >>>> header fields to their HTTP msgs per said mapping, yes? >>>> >>>> some thoughts/issues.. >>>> >>>> - eTLD and eTLD+1 are not mentioned in HTTPSTB >>>> >>>> - HTTPSTB does not explicitly define which particular "token scoping >>>> rules" impls must adhere to. Is the client-side TBID >>>> storage-and-mapping >>>> model intended to map only to domain names, and in this case be >>>> "domain >>>> lowered" to eTLD+1 (modulo publicsuffix.org) similarly to how >>>> cookies' >>>> domain-matching works? [3][4] >>>> >>> >>> Just added language to that effect in a new "Privacy Considerations" >>> section in -03. Take a look and see whether you like it / have some ideas >>> to improve on it. >>> >>> >>>> >>>> - what about servers that are identified by IP address? Note that in >>>> HSTS >>>> we punted on supporting servers identified by IP addresses [5]. >>>> Tho, in >>>> RFC6265 a server addressed by IP address can set cookies, but only >>>> for >>>> itself (i.e., the host-only flag is set to true [6]; i.e., cookie >>>> "domain lowering" is undefined for IP addresses). Is >>>> allowing/disallowing a host-only IP address-based TBID mapping >>>> something we should consider generally for TBPROTO, or >>>> just specifically consider for HTTSTB? >>>> >>> >>> I'd say that servers identified by IP addresses will get keys scoped to >>> that exact IP address - just like cookies. I think it belongs in HTTPSTB as >>> a SHOULD for web browsers. >>> >>> Dirk. >>> >>> >>>> >>>> >>>> > Next, let's consider what happens if there are multiple IdP's >>>> involved, say >>>> > something like rp.com -> identity-as-a-service.com -> idp.com. In >>>> that >>>> > case, identity-as-a-service.com acts like an IdP to rp.com, and as >>>> an RP to >>>> > idp.com, so we play the game described above twice. It wouldn't make >>>> sense >>>> > here if idp.com somehow knew what public key the client is using >>>> with rp.com >>>> > - it's useless information. In a scenario like this, idp.com needs to >>>> > strongly authenticate the client to identity-as-a-service.com, not >>>> to rp.com >>>> >>>> Agreed, in this particular, tightly-constrained scenario. >>>> >>>> HTH, >>>> >>>> =JeffH >>>> >>>> >>>> [1] https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest >>>> >>>> [2] https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf >>>> >>>> [3] https://tools.ietf.org/html/rfc6265#section-5.1.3 >>>> >>>> [4] http://identitymeme.org/http-cookie-processing-algorithm-etlds/ >>>> >>>> [5] https://tools.ietf.org/html/rfc6797#appendix-A >>>> >>>> [6] https://tools.ietf.org/html/rfc6265#section-5.3 - step 6. >>>> >>>> >>>> >>>> [figure 1] >>>> >>>> What: Analysis of redirect hops at RP aka TC and at IDP aka TP >>>> >>>> Legend: >>>> >>>> EKM: TLS Exported Keying Material [RFC5705] >>>> >>>> {EKMn}Ksm: EKM for server "n", signed by private key of TBID "m", >>>> where "n" must represent server receiving the ETBMSG, >>>> if a conveyed TB's type is provided_token_binding, then >>>> m = n, else if TB's type is referred_token_binding, then >>>> m != n. E.g., see step 1b in diagram below. >>>> >>>> ETBMSG: "Token-Binding" HTTP header field conveying an >>>> EncodedTokenBindingMessage, in turn conveying >>>> TokenBinding (TB)struct(s), e.g.: >>>> ETBMSG[[TB]] or ETBMSG[[TB1],[TB2]] >>>> >>>> ID Token: the "ID Token" in OIDC, it is the semantic equivalent >>>> of a SAML "authentication assertion". "ID Token w/TBIDn" >>>> denotes a "token bound" ID Token containing TBIDn. >>>> >>>> Ks & Kp: private (aka secret) key, and public key, respectively, >>>> of client-side Token Binding key pair >>>> >>>> OIDC: Open ID Connect >>>> >>>> TB: TokenBinding struct containing signed EKM, TBID, and >>>> TB type, e.g.: [{EKM1}Ks1,TBID1,provided_token_binding] >>>> >>>> TBIDn: Token Binding ID for client and server n's token-bound >>>> TLS association. TBIDn contains Kpn. >>>> >>>> >>>> >>>> Token Consumer, Token Provider, >>>> aka: aka: >>>> OpenID Client, OpenID Provider, >>>> Client, OIDC Relying Party, OIDC Provider, >>>> aka: SAML Relying Party SAML Identity >>>> Provider >>>> User Agent [ servers "1", "2" ] [ servers "3", >>>> "4" ] >>>> +--------+ +-----+ +-----+ +-----+ +-----+ >>>> | Client | | TC1 | | TC2 | | TP3 | | TP4 | >>>> +--------+ +-----+ +-----+ +-----+ +-----+ >>>> | | | | | >>>> | | | | | >>>> | 0. Client interacts w/TC1 | | >>>> | over HTTPS, establishes Ks1 & Kp1, TBID1 | | >>>> | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | | >>>> |------------------------------>| | | | >>>> | | | | | >>>> | | | | | >>>> | 1a. redirect to TC2 for TC-specific reasons | | >>>> | any security-relevant cookies should contain TBID1 | | >>>> +<- - - - - - - - - - - - - - - - | | | | >>>> . | | | | | >>>> +----------------------------------------->| | | >>>> | 1b. establishes Ks2 & Kp2, TBID2 | | | >>>> | ETBMSG[[{EKM2}Ks2,TBID2,provided_token_binding]] | | >>>> | | | | | >>>> | | | | | >>>> | | | | | >>>> | 2a. OIDC ID Token request, | | | | >>>> | aka "Authentication Request" w/ redirect_uri=TC1; <-- note well >>>> | conveyed w/ HTTP response header field of: >>>> | Include-Referer-Token-Binding-ID:true | | >>>> | any security-relevant cookies should contain TBID2 | | >>>> +<- - - - - - - - - - - - - - - - - - - - -| | | >>>> . | (redirect to TP via 301, 302, | | | | >>>> . | 303, 307, or 308) | | | | >>>> . | | | | | >>>> +----------------------------------------------------->| | >>>> | 2b. client opens HTTPS w/ TP3, | | | >>>> | establishes Ks3, Kp3, TBID3; | | | >>>> | sends GET or POST with | | | >>>> | ID Token request w/ redirect_uri=TC1, | | | >>>> | ETBMSG[[{EKM3}Ks3,TBID3,provided_token_binding], | >>>> | [{EKM3}Ks2,TBID2,referred_token_binding]] <-- but ID Tok >>>> request >>>> | | | <-- is for TC1 >>>> | | | >>>> | | | | | >>>> | | | | | >>>> | 3a. redirect to TP4 for TP-specific reasons | | >>>> | any security-relevant cookies should contain TBID3 | | >>>> +<- - - - - - - - - - - - - - - - - - - - - - - - - - -| | >>>> . | | | | | >>>> +--------------------------------------------------------------->| >>>> | 3b. client opens HTTPS w/ TP4, | | | >>>> | establishes Ks4 & Kp4, TBID4 | | | >>>> | ETBMSG[[{EKM4}Ks4,TBID4,provided_token_binding]] | | >>>> | *** as well as the ID Token request w/ redirect_uri=TC1; >>>> | *** also, somehow conveys TBID2 to TP4 ? >>>> | | | | | >>>> | | | | | >>>> | | | | | >>>> | 4. user authentication (if applicable, | | >>>> | methods vary, particulars are out of scope) | | >>>> |<============================================================>| >>>> | (TP generates ID Token for TC1 containing TBID1 - TP4 has only >>>> TBID2 >>>> | also set cookie(s) containing TBID4 and/or TBID3 >>>> | details vary) | | | | >>>> | | | | | >>>> | | | | | >>>> | | | | | >>>> | 5a. ID Token issued for TC1, containing TBID1, <-- how do this if >>>> | conveyed via OIDC "Authentication Response" <-- don't have >>>> TBID1? >>>> +<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| >>>> . | (redirect to TC1) | | | | >>>> . | | | | | >>>> +-------------------------------->| | | | >>>> | 5b. HTTPS GET or POST with | | | | >>>> | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | | >>>> | conveying Authn Reponse containing ID Token w/TBID1, | >>>> | issued for TC1 | >>>> | | | | | >>>> | | | | | >>>> | | | | | >>>> | | | | | >>>> | 6. user is signed-on, any security-relevant cookie(s) | >>>> | that are set SHOULD contain TBID1 | | | >>>> |<------------------------------| | | | >>>> | | | | | >>>> | | | | | >>>> >>>> >>>> end >>>> >>>> >>>> >>> _______________________________________________ >>> Unbearable mailing list >>> Unbearable@ietf.org >>> https://www.ietf.org/mailman/listinfo/unbearable >>> >>> >> > --001a1144278ee33b0f052ee3301a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Agreed. Bottom line is that I still believe that a single = referred token binding (even on repeated redirects) gives us all we need. H= aving said that, it probably is a good idea to document best practices (as = Nick has done here) to make sure IdPs and RPs don't shoot themselves in= the foot. For example, when I first responded (on the other thread) and ex= plained why I think that a single referred token binding is enough, I didn&= #39;t realize that you have to redirect with Include-Referer-Token-Binding-= ID *twice*, from RP to IdP, and also within the IdP (as Nick explains here)= .<div><br></div><div>Dirk.</div><div><br></div></div><br><div class=3D"gmai= l_quote"><div dir=3D"ltr">On Thu, Mar 24, 2016 at 3:16 PM Nick Harper <<= a href=3D"mailto:nharper@google.com">nharper@google.com</a>> wrote:<br><= /div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">TL;DR: Use Include-Ref= erer-Token-Binding-ID. Binding a token to an ID that hasn't been verifi= ed can result in a MitM getting control of a bound token.<div><br></div><di= v>Dirk and I chatted about my/David's proposal, and how it applies to J= eff's scenario. In steps 3a and 3b from figure 1, TBID3 needs to be ref= erred to TP4 (in addition to conveying TBID2). The problem with the current= setup of figure 1 is when there is an attacker MitMing connections to TP3.= In step 2b, the TokenBindingMessage contains TBID3' and TBID2', bo= th under attacker control. Then, in step 3b, when the client follows the re= direct from (the MitM'd) TP3 to TP4, it includes TBID4, but not TBID3, = in the TokenBindingMessage. When TP4 authenticates the user, TBID4 is corre= ct, and then TP4 creates a token for the user's identity with an attack= er-controlled TBID. Even if TP3 and TP4 are somehow cooperating, and the pr= ovided and referred token bindings from the request in step 2b are passed f= rom TP3 to TP4 out-of-band, the token still has an attacker controlled TBID= , since the token bindings sent in step 2b are attacker controlled.=C2=A0</= div><div><br></div><div>I think the takeaway from this is when a federated = token is created and bound to a referred TBID, the provided TBID (that the = user's identity is bound to) and the referred TBID must both be verifie= d as being possessed by the *same* client. The easiest way to do this is to= have the provided TBID and the referred TBID in the same TokenBindingMessa= ge.<br></div></div><div dir=3D"ltr"><div><div class=3D"gmail_extra"><br><di= v class=3D"gmail_quote">On Mon, Mar 21, 2016 at 1:40 PM, Nick Harper <span = dir=3D"ltr"><<a href=3D"mailto:nharper@google.com" target=3D"_blank">nha= rper@google.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di= v dir=3D"ltr">My understanding of the problem in figure 1 is that 1) in the= redirect from TC2 to TP3, the referred TBID is is TBID2, while the redirec= t uri is to TC1, and 2) when TP3 redirects to TP4, somehow TBID2 needs to b= e relayed. Please correct me if that is wrong or incomplete.<div><br></div>= <div>One way to solve problem 2 is to treat the TP3->TP4 redirect like t= he "identity-as-a-service" scenario that Dirk mentioned. Instead = of TP4 redirecting to TC1, it can create a token to be consumed by TP3, and= redirect to TP3, which will then create a token to send back to TC1.</div>= <div><br></div><div>For problem 1, I am going to assume that TC1 and TC2 ar= e cooperating. The easiest way to fix this is to have TC2 transmit to TC1 o= ut-of-band what TBID2 is so that TC1 can verify it.</div><div><br></div><di= v>Here's another solution (for both problems) that I think could work (= credit to David Benjamin for initially proposing it). I'm going to use = OpenID Connect terminology here, but I imagine this could be adapted for ot= her federated protocols. When the clients makes the OIDC authentication req= uest, it includes the TBID in the nonce query param. Regardless of what hap= pens in terms of redirects from TP3->TP4 (or anything else), the token t= hat the client sends back to the token consumer will have the TBID in the n= once claim. For the case of TC1 redirects to TC2 which then does the redire= ct for the authentication request, TC1 can pass the TBID to TC2 in a query = param.</div><div><br></div><div>By moving the referred Token Binding ID fro= m the tbproto (and tbhttps) to the federation protocol, it simplifies the s= etup and implementation of both. User-agents no longer have to handle the I= nclude-Referer-Token-Binding-ID header; identity providers don't have t= o do anything additional with creating a new claim and plumbing the TBID fr= om the Sec-Token-Binding header into the new claim; the token consumer does= n't have to worry about whether the token provider supports token bindi= ng (or the same key params), as it will always get back a bound token.</div= ><div><br></div><div>The only downside I see (so far) to this approach is t= hat the token provider has no way to verify that the client has possession = of the private key for the referred Token Binding ID. What security benefit= s are provided by the token provider verifying proof of possession? As far = as I could tell, it could open up a token injection attack, but that would = be thwarted by the federation protocol's CSRF protection.</div></div><d= iv class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div>On Sun, M= ar 20, 2016 at 11:03 PM, Dirk Balfanz <span dir=3D"ltr"><<a href=3D"mail= to:balfanz@google.com" target=3D"_blank">balfanz@google.com</a>></span> = wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir=3D"= ltr"><br><br><div class=3D"gmail_quote"><div><div><div dir=3D"ltr">On Sun, = Mar 20, 2016 at 6:17 PM =3DJeffH <<a href=3D"mailto:Jeff.Hodges@kingsmou= ntain.com" target=3D"_blank">Jeff.Hodges@kingsmountain.com</a>> wrote:<b= r></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border= -left:1px #ccc solid;padding-left:1ex">>> On 3/7/16, 4:24 PM <a href= =3D"mailto:nharper@google.com" target=3D"_blank">nharper@google.com</a>>= wrote:<br> >>><br> >>> If a client receives an "Include-Referer-Token-Binding-ID= " header in<br> >>> response to a request that already had a referred TBID in the<= br> >>> TokenBindingMessage, should it include both of those TBIDs as = referred<br> >>> TBIDs in the next request?<br> >>><br> >>> I.e.<br> >>> - client sends request to server A w/ provided TBID A<br> >>> - gets back Include-Referer-Token-Binding-ID header on a redir= ect to B<br> >>> - client sends request to B w/ provided TBID B, referred TBID = A<br> >>> - gets back Include-Referer-Token-Binding-ID header on a redir= ect to C<br> >>> Possible behaviors:<br> >>> i) client sends request to C w/ provided TBID C, referred TBID= B,<br> >>> referred TBID A<br> >>> ii) client sends request to C w/ provided TBID C, referred TBI= D B<br> >>><br> >>> iii) client sends request to C w/ provided TBID C, referred TB= ID A,<br> >>> referred TBID B<br> <br> <br> On Fri, 11 Mar 2016 Dirk replied:<br> > The intended semantics in the current spec is=C2=A0 ii).<br> <br> what you mean that is that the TokenBindingMessage (TBMSG) contains only tw= o<br> TokenBindings in this case, and the TBMSG is included in an HTTP request<br= > from the client to server only when satisfying a redirect that is crossing<= br> "functional boundaries" as noted below, yes?<br> <br> [ "current spec" discussed herein =3D -tokbind-https-02 aka HTTPS= TB,<br> =C2=A0 =C2=A0other specs..<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -tokbind-neg= otiation-02 aka TBNEGO<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -tokbind-pro= tocol-04 aka TBPROTO ]<br> <br> On Fri, 11 Mar 2016 Dirk further replied:<br> > I believe that covers all the use cases that you're describing: Le= t's first<br> > consider the case where there is one Relying Party, and one Identity<b= r> > Provider. The RP might go through a bunch of redirects before ultimate= ly<br> > handing things off to the IdP, and the IdP might go through a bunch of= <br> > redirects before ultimately handling the RP request. Same on the way b= ack<br> > from the IdP to the RP.<br> <br> understood.<br> <br> > The one redirect where the referred token binding is necessary is the<= br> > redirect that crosses functional boundaries: from the RP to the IdP.<b= r> <br> agreed.<br> <br> > If the<br> > first endpoint at the IdP isn't the one that is processing the RP = request<br> > (because, say, it's the old one and it's now redirecting to th= e new one),<br> > that endpoint needs to encode the information it learns (i.e., what is= the<br> > public key that the client is using with the RP) in some way (which ca= n be<br> > proprietary to the IdP) and pass that along as the request is handed o= ff.<br> <br> agreed that the above works in the case where the Token Consumer (RP) that<= br> redirects to IdP1 is the intended recipient of the eventual token-bound ID<= br> token.<br> <br> However, federation protocols have a notion of a 'return address' t= hat's<br> typically included in the RP's 'authn request'. E.g., in OIDC i= t is the<br> "redirect_uri" [1], and in SAML the equivalent is the<br> "AssertionConsumerServiceURL" [2].<br> <br> Upon issuance of the security token, the IDP redirects the UA to the<br> specified 'return address', which does not necessarily point to the= RP<br> entity that redirected the UA to the IDP, nor even any of the entities in<b= r> the RP's "redirect chain".<br> <br> So there needs to be some means for the IDP to receive the _correct_<br> referred TBID to include in the security token it generates and then return= s<br> -- this is not necessarily the RP entity that redirected to the IDP. A few<= br> ways to address this in HTTPSTB perhaps are..<br> <br> We could mandate in HTTPSTB that the receiving RP entity (aka Token<br> Consumer) MUST have the same eTLD+1 as the RP entity that redirected (aka<b= r> "handed off") to the IDP. (see below for discussion of TB scoping= rules)<br> <br> Or, we could attempt to devise a means for the RP entities to signal the<br= > correct referred TBID to the IDP via HTTPSTB/TBPROTO.<br> <br> Or, we could punt the problem to deployers and say something like "the= <br> referred TBID in the TBMSG MUST map to the entity specified in the authn<br= > request's return address -- i.e., the TBID included in the issued secur= ity<br> token by the IDP needs to match the client's TLS connection with the en= tity<br> who will _receive_ the security token, even if the latter entity is not the= <br> one to redirect to the IDP" -- it is implementers' and deployers&#= 39;<br> responsibility to get this right.<br> <br> See [figure 1] at end below.<br> <br> <br> > On the way back, after the IdP redirects back to the RP, the RP just n= eeds<br> > to make sure that one of the endpoints in the redirect chain is on the= same<br> > eTLD+1 as the endpoint that did the hand-off to the IdP, so it can pro= cess<br> > the IdP response there.<br> <br> hm, perhaps there are some issues here..<br> <br> * with regards to processing the IDP response ... is the above-stated eTLD+= 1<br> requirement because the client aka user agent (UA) will use the same<br> provided TBID with servers whose hostnames map to the same eTLD+1 ?<br> -tokbind-protocol aka TBPROTO says..<br> <br> =C2=A0 =C2=A0 ... In order to prevent cooperating servers from linking user= <br> =C2=A0 =C2=A0 identities, different keys SHOULD be used by the client for<b= r> =C2=A0 =C2=A0 connections to different servers, according to the token scop= ing<br> =C2=A0 =C2=A0 rules of the application protocol.<br> <br> ..so it seems we are assuming (in HTTPSTB) that HTTPS clients map the<br> servers to eTLD+1 when generating their TB key pairs, and afix Token-Bindin= g<br> header fields to their HTTP msgs per said mapping, yes?<br> <br> some thoughts/issues..<br> <br> =C2=A0 - eTLD and eTLD+1 are not mentioned in HTTPSTB<br> <br> =C2=A0 - HTTPSTB does not explicitly define which particular "token sc= oping<br> =C2=A0 =C2=A0 rules" impls must adhere to. Is the client-side TBID sto= rage-and-mapping<br> =C2=A0 =C2=A0 model intended to map only to domain names, and in this case = be "domain<br> =C2=A0 =C2=A0 lowered" to eTLD+1 (modulo <a href=3D"http://publicsuffi= x.org" rel=3D"noreferrer" target=3D"_blank">publicsuffix.org</a>) similarly= to how cookies'<br> =C2=A0 =C2=A0 domain-matching works? [3][4]<br></blockquote><div><br></div>= </div></div><div>Just added language to that effect in a new "Privacy = Considerations" section in -03. Take a look and see whether you like i= t / have some ideas to improve on it.</div><span><div>=C2=A0</div><blockquo= te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so= lid;padding-left:1ex"> <br> =C2=A0 - what about servers that are identified by IP address? Note that in= HSTS<br> =C2=A0 =C2=A0 we punted on supporting servers identified by IP addresses [5= ]. Tho, in<br> =C2=A0 =C2=A0 RFC6265 a server addressed by IP address can set cookies, but= only for<br> =C2=A0 =C2=A0 itself (i.e., the host-only flag is set to true [6]; i.e., co= okie<br> =C2=A0 =C2=A0 "domain lowering" is undefined for IP addresses). I= s<br> =C2=A0 =C2=A0 allowing/disallowing a host-only IP address-based TBID mappin= g<br> =C2=A0 =C2=A0 something=C2=A0 we should consider generally for TBPROTO, or<= br> =C2=A0 =C2=A0 just specifically consider for HTTSTB?<br></blockquote><div><= br></div></span><div>I'd say that servers identified by IP addresses wi= ll get keys scoped to that exact IP address - just like cookies. I think it= belongs in HTTPSTB as a SHOULD for web browsers.=C2=A0</div><span><font co= lor=3D"#888888"><div><br></div><div>Dirk.</div></font></span><div><div><div= >=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex"> <br> <br> > Next, let's consider what happens if there are multiple IdP's = involved, say<br> > something like <a href=3D"http://rp.com" rel=3D"noreferrer" target=3D"= _blank">rp.com</a> -> <a href=3D"http://identity-as-a-service.com" rel= =3D"noreferrer" target=3D"_blank">identity-as-a-service.com</a> -> <a hr= ef=3D"http://idp.com" rel=3D"noreferrer" target=3D"_blank">idp.com</a>. In = that<br> > case, <a href=3D"http://identity-as-a-service.com" rel=3D"noreferrer" = target=3D"_blank">identity-as-a-service.com</a> acts like an IdP to <a href= =3D"http://rp.com" rel=3D"noreferrer" target=3D"_blank">rp.com</a>, and as = an RP to<br> > <a href=3D"http://idp.com" rel=3D"noreferrer" target=3D"_blank">idp.co= m</a>, so we play the game described above twice. It wouldn't make sens= e<br> > here if <a href=3D"http://idp.com" rel=3D"noreferrer" target=3D"_blank= ">idp.com</a> somehow knew what public key the client is using with <a href= =3D"http://rp.com" rel=3D"noreferrer" target=3D"_blank">rp.com</a><br> > - it's useless information. In a scenario like this, <a href=3D"ht= tp://idp.com" rel=3D"noreferrer" target=3D"_blank">idp.com</a> needs to<br> > strongly authenticate the client to <a href=3D"http://identity-as-a-se= rvice.com" rel=3D"noreferrer" target=3D"_blank">identity-as-a-service.com</= a>, not to <a href=3D"http://rp.com" rel=3D"noreferrer" target=3D"_blank">r= p.com</a><br> <br> Agreed, in this particular, tightly-constrained scenario.<br> <br> HTH,<br> <br> =3DJeffH<br> <br> <br> [1] <a href=3D"https://openid.net/specs/openid-connect-core-1_0.html#AuthRe= quest" rel=3D"noreferrer" target=3D"_blank">https://openid.net/specs/openid= -connect-core-1_0.html#AuthRequest</a><br> <br> [2] <a href=3D"https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0= -os.pdf" rel=3D"noreferrer" target=3D"_blank">https://docs.oasis-open.org/s= ecurity/saml/v2.0/saml-core-2.0-os.pdf</a><br> <br> [3] <a href=3D"https://tools.ietf.org/html/rfc6265#section-5.1.3" rel=3D"no= referrer" target=3D"_blank">https://tools.ietf.org/html/rfc6265#section-5.1= .3</a><br> <br> [4] <a href=3D"http://identitymeme.org/http-cookie-processing-algorithm-etl= ds/" rel=3D"noreferrer" target=3D"_blank">http://identitymeme.org/http-cook= ie-processing-algorithm-etlds/</a><br> <br> [5] <a href=3D"https://tools.ietf.org/html/rfc6797#appendix-A" rel=3D"noref= errer" target=3D"_blank">https://tools.ietf.org/html/rfc6797#appendix-A</a>= <br> <br> [6] <a href=3D"https://tools.ietf.org/html/rfc6265#section-5.3" rel=3D"nore= ferrer" target=3D"_blank">https://tools.ietf.org/html/rfc6265#section-5.3</= a> - step 6.<br> <br> <br> <br> [figure 1]<br> <br> What: Analysis of redirect hops at RP aka TC and at IDP aka TP<br> <br> Legend:<br> <br> =C2=A0 =C2=A0EKM:=C2=A0 =C2=A0 =C2=A0 =C2=A0TLS Exported Keying Material [R= FC5705]<br> <br> =C2=A0 =C2=A0{EKMn}Ksm: EKM for server "n", signed by private key= of TBID "m",<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 where "n" must r= epresent server receiving the ETBMSG,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if a conveyed TB's typ= e is provided_token_binding, then<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m =3D n, else if TB's = type is referred_token_binding, then<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m !=3D n. E.g., see step 1= b in diagram below.<br> <br> =C2=A0 =C2=A0ETBMSG:=C2=A0 =C2=A0 "Token-Binding" HTTP header fie= ld conveying an<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 EncodedTokenBindingMessage= , in turn conveying<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TokenBinding (TB)struct(s)= , e.g.:<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ETBMSG[[TB]] or ETBMSG[[TB= 1],[TB2]]<br> <br> =C2=A0 =C2=A0ID Token:=C2=A0 the "ID Token" in OIDC, it is the se= mantic equivalent<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of a SAML "authentica= tion assertion". "ID Token w/TBIDn"<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 denotes a "token boun= d" ID Token containing TBIDn.<br> <br> =C2=A0 =C2=A0Ks & Kp:=C2=A0 =C2=A0private (aka secret) key, and public = key, respectively,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of client-side Token Bindi= ng key pair<br> <br> =C2=A0 =C2=A0OIDC:=C2=A0 =C2=A0 =C2=A0 Open ID Connect<br> <br> =C2=A0 =C2=A0TB:=C2=A0 =C2=A0 =C2=A0 =C2=A0 TokenBinding struct containing = signed EKM, TBID, and<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TB type, e.g.: [{EKM1}Ks1,= TBID1,provided_token_binding]<br> <br> =C2=A0 =C2=A0TBIDn:=C2=A0 =C2=A0 =C2=A0Token Binding ID for client and serv= er n's token-bound<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TLS association. TBIDn con= tains Kpn.<br> <br> <br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Token Consumer,=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Token Provider,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 aka:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0aka:<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OpenID Client,=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0OpenID Provider,<br> Client,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 OIDC Relying Party,=C2=A0 =C2=A0 OIDC Provider,<br> aka:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0SAML Relying Party=C2=A0 =C2=A0 =C2=A0SAML Ident= ity Provider<br> User Agent=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0[ servers "1", "2" ]=C2=A0 =C2=A0[ servers= "3", "4" ]<br> +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+-----+=C2=A0 +-----+=C2=A0 =C2=A0 =C2=A0+-----+=C2=A0 = =C2=A0+-----+<br> | Client |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| TC1 |=C2=A0 | TC2 |=C2=A0 =C2=A0 =C2=A0| TP3 |=C2=A0 = =C2=A0| TP4 |<br> +--------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+-----+=C2=A0 +-----+=C2=A0 =C2=A0 =C2=A0+-----+=C2=A0 = =C2=A0+-----+<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 0. Client interacts w/TC1=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| over HTTPS, establishes Ks1 & Kp1, TBID1=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]]=C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|------------------------------>|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 1a. redirect to TC2 for TC-specific reasons=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| any security-relevant cookies should contain TBID1 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0+<- - - - - - - - - - - - - - - - |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|<br> =C2=A0 =C2=A0. |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|<br> =C2=A0 =C2=A0+----------------------------------------->|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 1b. establishes Ks2 & Kp2, TBID2=C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| ETBMSG[[{EKM2}Ks2,TBID2,provided_token_binding]]=C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 2a. OIDC ID Token request,=C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| aka "Authentication Request" w/ redirect_ur= i=3DTC1;=C2=A0 <-- note well<br> =C2=A0 =C2=A0 =C2=A0| conveyed w/ HTTP response header field of:<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0Include-Referer-Token-Binding-ID:true=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= <br> =C2=A0 =C2=A0 =C2=A0| any security-relevant cookies should contain TBID2 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0+<- - - - - - - - - - - - - - - - - - - - -|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0. | (redirect to TP via 301, 302, |=C2=A0 =C2=A0 =C2=A0 =C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|<br> =C2=A0 =C2=A0. |=C2=A0 303, 307, or 308)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0. |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|<br> =C2=A0 =C2=A0+----------------------------------------------------->|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 2b. client opens HTTPS w/ TP3,=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| establishes Ks3, Kp3, TBID3;=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| sends GET or POST with=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| ID Token request w/ redirect_uri=3DTC1,=C2=A0 |=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| ETBMSG[[{EKM3}Ks3,TBID3,provided_token_binding],=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0[{EKM3}Ks2,TBID2,referred_t= oken_binding]] <-- but ID Tok request<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 <-- is for TC1<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 3a. redirect to TP4 for TP-specific reasons=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| any security-relevant cookies should contain TBID3 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0+<- - - - - - - - - - - - - - - - - - - - - - - - - - -|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0. |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|<br> =C2=A0 =C2=A0+-------------------------------------------------------------= -->|<br> =C2=A0 =C2=A0 =C2=A0| 3b. client opens HTTPS w/ TP4,=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| establishes Ks4 & Kp4, TBID4=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| ETBMSG[[{EKM4}Ks4,TBID4,provided_token_binding]]=C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*** as well as the I= D Token request w/ redirect_uri=3DTC1;<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*** also, somehow co= nveys TBID2 to TP4 ?<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 4. user authentication (if applicable,=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 methods vary, particulars are out of sco= pe)=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|<br> =C2=A0 =C2=A0 =C2=A0| (TP generates ID Token for TC1 containing TBID1 - TP4= has only TBID2<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 also set cookie(s) containing TBID4 and/or TBID= 3<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 details vary)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 5a. ID Token issued for TC1, containing TBID1, <--= how do this if<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 conveyed via OIDC "Authentication R= esponse" <-- don't have TBID1?<br> =C2=A0 =C2=A0+<- - - - - - - - - - - - - - - - - - - - - - - - - - - - -= - - -|<br> =C2=A0 =C2=A0. |=C2=A0 =C2=A0(redirect to TC1)=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0. |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|<br> =C2=A0 =C2=A0+-------------------------------->|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 5b. HTTPS GET or POST with=C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]]=C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| conveying Authn Reponse containing ID Token w/TBID1,= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i= ssued for TC1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0| 6. user is signed-on, any security-relevant cookie(s)= =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br> =C2=A0 =C2=A0 =C2=A0| that are set SHOULD contain TBID1=C2=A0 =C2=A0 =C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|<br> =C2=A0 =C2=A0 =C2=A0|<------------------------------|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|<br> <br> <br> end<br> <br> <br> </blockquote></div></div></div></div> <br></div></div><span>_______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> <br></span></blockquote></div><br></div> </blockquote></div><br></div></div></div></blockquote></div> --001a1144278ee33b0f052ee3301a-- From nobody Fri Mar 25 11:28:23 2016 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 2889A12D5B4 for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 11:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 9tS2cxXjop0g for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 11:28:19 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0118.outbound.protection.outlook.com [65.55.169.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7440912D5CD for <unbearable@ietf.org>; Fri, 25 Mar 2016 11:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+1GkLr2UGJnrRtBZD3sIQv33v1GX2RUgxqJlPrBL0QE=; b=KEWeVywBD5RAVn4ulJ9u2+nRovrEqD0pIRFnKzGaG+yLTNN+z/mjxWmXSELJe5mjBctD5knovDwl0uy+noxjLreDB0T/e3Cf9TJMBH1SWYEw8GwKmPYnVYjqDuwbkvzKCaOz70Z8vU3gYgaC8pdfChSIx3HUdIjqMZAPZAJwdbg= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.434.16; Fri, 25 Mar 2016 18:28:17 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0434.023; Fri, 25 Mar 2016 18:28:17 +0000 From: Andrei Popov <Andrei.Popov@microsoft.com> To: "Hodges, Jeff" <jeff.hodges@paypal.com>, Tokbind WG <unbearable@ietf.org> Thread-Topic: triple handshake admonitions -- pare 'em down to one ? Thread-Index: AQHReZm4xsDOY3MKnE6xWMJZ/2S/IZ9qk5eQ Date: Fri, 25 Mar 2016 18:28:17 +0000 Message-ID: <BLUPR03MB139672AF19528CCD27B52CDB8C830@BLUPR03MB1396.namprd03.prod.outlook.com> References: <D304ACB3.91D00%jehodges@paypalcorp.com> In-Reply-To: <D304ACB3.91D00%jehodges@paypalcorp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: paypal.com; dkim=none (message not signed) header.d=none;paypal.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:3::1d2] x-ms-office365-filtering-correlation-id: e2fa6a4b-c9e4-4737-9104-08d354db3c41 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:2vn5dVHfmjVkJkGpA3T1oglBnxbg1kSIjDFb4+O+e7N2UcW+OisscXBFLfoI4EwHVk6QXVcNooizPA1ehNjXAEj7CGCl27ZpyFIgziVDFbtHB56YYghB+BiiIs7SaXYYGuSBeuPDPVoJBwN5MZHWNQ==; 24:xRleWCZVNixaAb3O0Pnnwa/AqqKRV98Jl0A/s5z7rTRR3crs4sg4xt5PmwKgSMhATV/nG/vOgQ8fJ+fzPgtcMP4l2ohZF31IUjMMdzMygc0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; x-microsoft-antispam-prvs: <BLUPR03MB139563765355930187E426AF8C830@BLUPR03MB1395.namprd03.prod.outlook.com> x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 0892FA9A88 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(2950100001)(74316001)(99286002)(106116001)(19625215002)(5003600100002)(76576001)(3280700002)(15975445007)(3660700001)(5008740100001)(1096002)(2900100001)(1220700001)(102836003)(2906002)(6116002)(790700001)(87936001)(77096005)(189998001)(19300405004)(8990500004)(5004730100002)(5001770100001)(10400500002)(11100500001)(586003)(10290500002)(10090500001)(5002640100001)(19580405001)(122556002)(92566002)(107886002)(54356999)(16236675004)(5005710100001)(81166005)(86612001)(19580395003)(33656002)(86362001)(50986999)(76176999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB139672AF19528CCD27B52CDB8C830BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2016 18:28:17.2841 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/JF_1eTfppO9VWWmbVw261lwydrA> Subject: Re: [Unbearable] triple handshake admonitions -- pare 'em down to one ? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 25 Mar 2016 18:28:22 -0000 --_000_BLUPR03MB139672AF19528CCD27B52CDB8C830BLUPR03MB1396namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't feel strongly about this, but perhaps section 4 "Establishing a TLS= Token Binding" would not be complete without mentioning the EMS requiremen= t, among others. If folks think that reducing the repetition of the EMS man= tra is important, I'll remove it from section 4. Cheers, Andrei From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Hodges, = Jeff Sent: Tuesday, March 8, 2016 4:22 PM To: Tokbind WG <unbearable@ietf.org> Subject: [Unbearable] triple handshake admonitions -- pare 'em down to one = ? The admonition wrt "triple handshake vuln" appears four times in the three = specs -- twice in TBPROTO, once each in TBNEGO and HTTPSTB. Yes, it is important, but arguably, it only needs to appear in TBNEGO becau= se it is TBNEGO that defines the TLS session establishment. The other spec= s are at the next layer up and refer to TBNEGO wrt TLS establishment. If y'all really want to keep the admonition in all three specs, then I'd pa= re TBPROTO down to one occurance, in security considerations. HTH, =3DJeffH > grep -Hi "triple handshake" *xml draft-ietf-tokbind-https-02.xml: <section title=3D"Triple Handshake Vu= lnerability in TLS"> draft-ietf-tokbind-https-02.xml: TLS Token Binding. The triple han= dshake attack <xref draft-ietf-tokbind-https-02.xml: <title>Triple Handshakes and Cook= ie Cutters: Breaking and Fixing Authentication over draft-ietf-tokbind-negotiation-02.xml: <section title=3D"Triple Handsh= ake Vulnerability in TLS 1.2 and Older TLS Versions"> draft-ietf-tokbind-negotiation-02.xml: associate a TLS connection wi= th a Token Binding. The triple handshake attack draft-ietf-tokbind-negotiation-02.xml: <title>Triple Handshakes an= d Cookie Cutters: Breaking and Fixing Authentication over draft-ietf-tokbind-protocol-04.xml: <t>The triple handshake vulnerab= ility in TLS 1.2 and older TLS versions affects the security draft-ietf-tokbind-protocol-04.xml: <section title=3D"Triple Handshake= Vulnerability in TLS 1.2 and Older TLS Versions"> draft-ietf-tokbind-protocol-04.xml: TLS connection with a Token Bind= ing. The triple handshake attack draft-ietf-tokbind-protocol-04.xml: <title>Triple Handshakes and C= ookie Cutters: Breaking and Fixing Authentication over --_000_BLUPR03MB139672AF19528CCD27B52CDB8C830BLUPR03MB1396namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Menlo; panose-1:0 0 0 0 0 0 0 0 0 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman",serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:#0563C1; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:#954F72; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman",serif;} p.msonormal0, li.msonormal0, div.msonormal0 {mso-style-name:msonormal; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman",serif;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Calibri",sans-serif; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri",sans-serif;color:#1F497D">I don’t feel strongly about thi= s, but perhaps section 4 “Establishing a TLS Token Binding” wou= ld not be complete without mentioning the EMS requirement, among others. If folks think that reducing the repetition of the EMS mantra is i= mportant, I’ll remove it from section 4.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri",sans-serif;color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri",sans-serif;color:#1F497D">Cheers,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri",sans-serif;color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri",sans-serif;color:#1F497D">Andrei<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri",sans-serif;color:#1F497D"><o:p> </o:p></span></p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"= ;Calibri",sans-serif">From:</span></b><span style=3D"font-size:11.0pt;= font-family:"Calibri",sans-serif"> Unbearable [mailto:unbearable-= bounces@ietf.org] <b>On Behalf Of </b>Hodges, Jeff<br> <b>Sent:</b> Tuesday, March 8, 2016 4:22 PM<br> <b>To:</b> Tokbind WG <unbearable@ietf.org><br> <b>Subject:</b> [Unbearable] triple handshake admonitions -- pare 'em down = to one ?<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri",sans-serif;color:black">The admonition wrt "triple handsha= ke vuln" appears four times in the three specs -- twice in TBPROTO, on= ce each in TBNEGO and HTTPSTB.<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri",sans-serif;color:black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri",sans-serif;color:black">Yes, it is important, but arguably, it = only needs to appear in TBNEGO because it is TBNEGO that defines = the TLS session establishment.  The other specs are at the next layer up and refer to TBNEGO wrt TLS establishment. <o:p></o:p><= /span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri",sans-serif;color:black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri",sans-serif;color:black">If y'all really want to keep the admoni= tion in all three specs, then I'd pare TBPROTO down to one occurance, in se= curity considerations. <o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri",sans-serif;color:black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri",sans-serif;color:black">HTH,<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri",sans-serif;color:black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri",sans-serif;color:black">=3DJeffH<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri",sans-serif;color:black"><o:p> </o:p></span></p> </div> <div> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:7.5p= t;font-family:"Menlo",serif;color:black">> grep -Hi "trip= le handshake" *xml<o:p></o:p></span></p> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:7.5p= t;font-family:"Menlo",serif;color:black">draft-ietf-tokbind-https= -02.xml:      <section title=3D"Triple Handshake Vul= nerability in TLS"><o:p></o:p></span></p> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:7.5p= t;font-family:"Menlo",serif;color:black">draft-ietf-tokbind-https= -02.xml:          TLS Token Binding. The triple ha= ndshake attack <xref<o:p></o:p></span></p> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:7.5p= t;font-family:"Menlo",serif;color:black">draft-ietf-tokbind-https= -02.xml:          <title>Triple Handshakes a= nd Cookie Cutters: Breaking and Fixing Authentication over <o:p></o:p>= </span></p> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:7.5p= t;font-family:"Menlo",serif;color:black"><o:p> </o:p></span>= </p> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:7.5p= t;font-family:"Menlo",serif;color:black"><o:p> </o:p></span>= </p> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:7.5p= t;font-family:"Menlo",serif;color:black">draft-ietf-tokbind-negot= iation-02.xml:      <section title=3D"Triple Handsha= ke Vulnerability in TLS 1.2 and Older TLS Versions"><o:p></o:p></sp= an></p> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:7.5p= t;font-family:"Menlo",serif;color:black">draft-ietf-tokbind-negot= iation-02.xml:        associate a TLS connection with a= Token Binding. The triple handshake attack <o:p></o:p></span></p> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:7.5p= t;font-family:"Menlo",serif;color:black">draft-ietf-tokbind-negot= iation-02.xml:          <title>Triple Handsh= akes and Cookie Cutters: Breaking and Fixing Authentication over <o:p>= </o:p></span></p> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:7.5p= t;font-family:"Menlo",serif;color:black"><o:p> </o:p></span>= </p> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:7.5p= t;font-family:"Menlo",serif;color:black"><o:p> </o:p></span>= </p> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:7.5p= t;font-family:"Menlo",serif;color:black"><o:p> </o:p></span>= </p> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:7.5p= t;font-family:"Menlo",serif;color:black">draft-ietf-tokbind-proto= col-04.xml:        <t>The triple handshake vulner= ability in TLS 1.2 and older TLS versions affects the security<o:p></o:p></= span></p> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:7.5p= t;font-family:"Menlo",serif;color:black">draft-ietf-tokbind-proto= col-04.xml:      <section title=3D"Triple Handshake = Vulnerability in TLS 1.2 and Older TLS Versions"><o:p></o:p></span>= </p> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:7.5p= t;font-family:"Menlo",serif;color:black">draft-ietf-tokbind-proto= col-04.xml:        TLS connection with a Token Binding.= The triple handshake attack <o:p></o:p></span></p> <p style=3D"margin:0in;margin-bottom:.0001pt"><span style=3D"font-size:7.5p= t;font-family:"Menlo",serif;color:black">draft-ietf-tokbind-proto= col-04.xml:          <title>Triple Handshake= s and Cookie Cutters: Breaking and Fixing Authentication over <o:p></o= :p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri",sans-serif;color:black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri",sans-serif;color:black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri",sans-serif;color:black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri",sans-serif;color:black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri",sans-serif;color:black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri",sans-serif;color:black"><o:p> </o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ca= libri",sans-serif;color:black"><o:p> </o:p></span></p> </div> </div> </body> </html> --_000_BLUPR03MB139672AF19528CCD27B52CDB8C830BLUPR03MB1396namp_-- From nobody Fri Mar 25 11:57:57 2016 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 458F312D0B3 for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 11:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_HELO_PASS=-0.001, SPF_PASS=-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 wOPUMn5B_TS5 for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 11:57:54 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0753.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::753]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF3A512D09A for <unbearable@ietf.org>; Fri, 25 Mar 2016 11:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VtQ4nV4USHJoZ3PUSVosmgkvk034CJD8+f7In86S1yw=; b=A4rApZ3drb37Px9xrfHxnMGtQDbRBHqLZ7JgZfVfp+IRvOPVPd+tn8er34iz5lkmV7cRq7lDWNxxnQwpiRgdlM2KSLu6jA53pHBr6ZdF8RnAai4SbXNXSyDhNcdygEpTea1VPX3xSAITzHRoOrSe++DIi1yW+Iz2W2bA5JlKFcg= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.434.16; Fri, 25 Mar 2016 18:57:33 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0434.023; Fri, 25 Mar 2016 18:57:33 +0000 From: Andrei Popov <Andrei.Popov@microsoft.com> To: =JeffH <Jeff.Hodges@KingsMountain.com>, IETF Tokbind WG <unbearable@ietf.org> Thread-Topic: [Unbearable] -tokbind-protocol-04: version mismatch between negotiation and TB msg? Thread-Index: AQHRdcI1b3LeMTdm/E+ZOG2PO6e5659qndoQ Date: Fri, 25 Mar 2016 18:57:33 +0000 Message-ID: <BLUPR03MB1396CA960139284F4ED623768C830@BLUPR03MB1396.namprd03.prod.outlook.com> References: <56D8FA93.6000900@KingsMountain.com> In-Reply-To: <56D8FA93.6000900@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: KingsMountain.com; dkim=none (message not signed) header.d=none;KingsMountain.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:3::1d2] x-ms-office365-filtering-correlation-id: c585072c-1bdb-4dab-8fdd-08d354df531b x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:CME4udGnXMUGf3qe9/ki2gFBG0eCD7vYArPY+yxddbUmgmL5fz+A4p7eyuMCj5GAZ4gpGT9B9w7OhnxAcJ6qbYHWjFIv4YNbpCBD5jMwyYCZ7y9PEznAq+yeW01DVgCgJI41Hs/gae1gBZwfmwfRrg==; 24:erspTrfrnC29CkoPYm47m29kL/IZ013GRQC/0/zskcSiLz4hwWuPmKbW1i8KXdYa0Z+y4OkhO5cNrJzMEYx1PlyKKA4Jo9+YbFKRAGs0beo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; x-microsoft-antispam-prvs: <BLUPR03MB13954DEFD1DFC223FF0BE5568C830@BLUPR03MB1395.namprd03.prod.outlook.com> x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 0892FA9A88 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(2950100001)(74316001)(99286002)(106116001)(5003600100002)(76576001)(3280700002)(15975445007)(3660700001)(5008740100001)(1096002)(2900100001)(1220700001)(102836003)(2906002)(87936001)(77096005)(6116002)(189998001)(8990500004)(5004730100002)(5001770100001)(230783001)(10400500002)(11100500001)(586003)(10090500001)(10290500002)(19580405001)(5002640100001)(122556002)(92566002)(107886002)(54356999)(5005710100001)(81166005)(86612001)(19580395003)(33656002)(86362001)(575784001)(50986999)(76176999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2016 18:57:33.6877 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/fR58B_u7skvjYHftSmRAYX5QdAE> Subject: Re: [Unbearable] -tokbind-protocol-04: version mismatch between negotiation and TB msg? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 25 Mar 2016 18:57:56 -0000 > The TB ProtocolVersion and TokenBindingKeyParameters are negotiated in th= e TLS handshake as specified in -tokbind-negotiation-02, but there is no ve= rsion indication in TokenBindingMessage (defined in tokbind-protocol-04 aka= TBPROTO). Yes, the thinking is that you only get V1 TB message format if you negotiat= ed TB V1, and that V2 will define what TB message looks like for V2 (either= a different format or the same). > Also, the criteria for incrementing the TB protocol version is not stipul= ated in either spec. It seems that the decision to define a new TB protocol version could be mot= ivated by a variety of reasons, many of them we may not be able to anticipa= te. Is it common for RFCs to stipulate criteria for incrementing the protoc= ol version? > Would the TB protocol version be incremented only due to changes to any o= f the structs defined in TBPROTO? This would be a good reason, but not necessarily the only one. E.g. in the = future we could decide to use something other than EKM, or EKM based on a d= ifferent set of parameters, etc. > It seems that defining a TB extension would not necessitate a TB protocol= version increment because TBPROTO says that impls must ignore extensions t= hey do not understand. Correct; this is part of the reason why we have the extensions mechanism. > However, what about if a new TokenBindingType is defined? I suppose that = it could be side-stepped by stipulating that servers must ignore any TokenB= indingMessage. TokenBinding.tokenbinding_type they do not understand.=20 This is not presently stated AFAICT. Good catch; I think an implementation should skip unknown TB types. Unless = there are objections, I'll add text to this effect. > Also there are no stipulations in TBPROTO that the TokenBindingMessage MU= ST be of the same version negotiated at the TLS layer -- however, there are= such stipulations wrt key parameters. Right, if we add a version indicator to the message, then it will make sens= e to require that it matches the negotiated TB version. I'd really like to = stick to one message format per protocol version, therefore I'm not keen on= message version indicators. Cheers, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of =3DJeffH Sent: Thursday, March 3, 2016 7:02 PM To: IETF Tokbind WG <unbearable@ietf.org> Subject: [Unbearable] -tokbind-protocol-04: version mismatch between negoti= ation and TB msg? Hi, The TB ProtocolVersion and TokenBindingKeyParameters are negotiated in the = TLS handshake as specified in -tokbind-negotiation-02, but there is no vers= ion indication in TokenBindingMessage (defined in tokbind-protocol-04 aka T= BPROTO). Also, the criteria for incrementing the TB protocol version is not stipulat= ed in either spec. Would the TB protocol version be incremented only due to= changes to any of the structs defined in TBPROTO? It seems that defining a TB extension would not necessitate a TB protocol v= ersion increment because TBPROTO says that impls must ignore extensions the= y do not understand. However, what about if a new TokenBindingType is defined? I suppose that it= could be side-stepped by stipulating that servers must ignore any TokenBin= dingMessage. TokenBinding.tokenbinding_type they do not understand.=20 This is not presently stated AFAICT. Also there are no stipulations in TBPROTO that the TokenBindingMessage MUST= be of the same version negotiated at the TLS layer -- however, there are s= uch stipulations wrt key parameters. HTH, =3DJeffH _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7cAndrei.Popov%40micr= osoft.com%7c11bb9dcbf26243fd621c08d343d955d8%7c72f988bf86f141af91ab2d7cd011= db47%7c1&sdata=3DH5%2bibhlYMzYMhZpX4WKpcLcBUWHX7mIfZgslCR0hsyo%3d From nobody Fri Mar 25 14:18:02 2016 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 CF45C12D136 for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 14:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 b9ObqriyqguO for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 14:17:59 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 5C62112D744 for <unbearable@ietf.org>; Fri, 25 Mar 2016 14:17:59 -0700 (PDT) Received: (qmail 10465 invoked by uid 0); 25 Mar 2016 21:17:56 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy9.mail.unifiedlayer.com with SMTP; 25 Mar 2016 21:17:56 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id aMHq1s00B2UhLwi01MHtKt; Fri, 25 Mar 2016 15:17:54 -0600 X-Authority-Analysis: v=2.1 cv=Nal1iQz4 c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=zEHBB4O0i18A:10 a=7OsogOcEt9IA:10 a=upKeV8_c0J3EufQPI9MA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=OZhwqT5Rbq1Ybhv5OHIXb62Un5OKLgZ8K2xJoVSn+hE=; b=yJaaIFDllQDKHzH+SxRwV1K3jU olQUd+rLrF42GeNuRI3JF07AJ34aotwXZEe5PAP8jT3zKgvdisPnLrf2kHpol1Gsqvw6fl3dLfum7 g17o6PqRpmByNtD5o7RO8OroG; Received: from [70.213.3.154] (port=6183 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1ajZ79-0006TE-P6 for unbearable@ietf.org; Fri, 25 Mar 2016 15:17:51 -0600 To: IETF Tokbind WG <unbearable@ietf.org> From: =JeffH <Jeff.Hodges@KingsMountain.com> Message-ID: <56F5AB0A.4070202@KingsMountain.com> Date: Fri, 25 Mar 2016 14:18:02 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.213.3.154 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/ZYJJU827_idl1j9plbDrDrSpE7Q> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 25 Mar 2016 21:18:01 -0000 I wish to clarify just this one little point here.. > I think the takeaway from this is when a federated token is created > and bound to a referred TBID, the provided TBID (that the user's > identity is bound to) and the referred TBID ... ..shouldn't the above rather read.. I think the takeaway from this is when a federated token is created and bound to a referred TBID, the provided TBID and the referred TBID (that the user's identity is bound to) ... ..? I am interpreting "user's identity is bound to" as being the ID Token (in OIDC case) or SAML assertion (in SAML case) that the IDP generates (and which needs to be bound to the correct TBID). thanks, =JeffH From nobody Fri Mar 25 14:25:17 2016 Return-Path: <nharper@google.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 163A512D19A for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 14:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 2Ljk4UrnIOuf for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 14:25:14 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42E212D136 for <unbearable@ietf.org>; Fri, 25 Mar 2016 14:25:13 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id e6so102374924vkh.2 for <unbearable@ietf.org>; Fri, 25 Mar 2016 14:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qlj0QQl1F631fBKPwwmUdKMvrcIK4wRLSLj1TqjOoR8=; b=CDs7005ztPtb/dsPnTtQU7mcr7Nf0UFqWXe7hYWgPpPddQreGGkrf8MwZNrp8TY/2B IE6950m7hiTq/HvaeYgtQJfvJL/k+WC3ggRt9sP48G2/apOEf7bi47mvyJYeKjHLPZ89 FzxImw3ocOjxgQAQBFGgm4wsxMLUwYbcioZHrVq/OATlDBAU1IdMMS6sXBQn4H1iSgoy HI31oQgDQ8rEqVOYwzIrBqr8JDw5Z6BC/gGYCvGyHUUopfql0Tfuy9yP8XcpS1TrAAaS trWkeaGX401qBRtioFo6TDM7A75RgbSkPC79CRejOkTvw9+o1cEhmrlub7rhIqvM9+dz XQ6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qlj0QQl1F631fBKPwwmUdKMvrcIK4wRLSLj1TqjOoR8=; b=d/TV2/akeY+ALKIN/oLrtBPmyJ4hdKud3jdDQcK9CXbZlrybXOqktAPIEwhfr8Rxek TYd6gOPVaM1pDsD2ZdL+cRnIdOkz1sIHaGONOD1PO8FljC7Ied66Qb72nJEDya97YNBX EVuHH7p/thd8XwrmGtQsc3OueGVKKOkmIGeG9cqJcyHFtK+Vu0y4VmyDwutTilfpgPc6 x/fR8W/aP5hWpVO0BLA12K9nkiptj0ghivRe2nJdK0AzOro9xs5+b/VgTBv/uHVHsbD7 EElbVpgYm15PmP4P8vAT/01c4P1H2do01e/EQ8L62ykoQsCnLtQxD95oPDrRvn+JsH1R 3jaA== X-Gm-Message-State: AD7BkJLA1sr7HRieUyc3WzvNGk4Xyo70ZX2KeBhhVIwLgvCKgQi5c8b8Msc7pK5vyIIJuW2FFtq9UW1OgAbd7Ur5 X-Received: by 10.176.0.111 with SMTP id 102mr8528493uai.15.1458941112850; Fri, 25 Mar 2016 14:25:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.76.198 with HTTP; Fri, 25 Mar 2016 14:24:53 -0700 (PDT) In-Reply-To: <56F5AB0A.4070202@KingsMountain.com> References: <56F5AB0A.4070202@KingsMountain.com> From: Nick Harper <nharper@google.com> Date: Fri, 25 Mar 2016 14:24:53 -0700 Message-ID: <CACdeXiKi=Ft=L_M_nkpvJLbLqN-KPWC+S0+=UOUAgzuSOKCmgw@mail.gmail.com> To: "=JeffH" <Jeff.Hodges@kingsmountain.com> Content-Type: multipart/alternative; boundary=001a113e3b24c7dc23052ee632dd Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/aR3Tpvz_fWLOzDZ1LKkDqT2lg4k> Cc: IETF Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 25 Mar 2016 21:25:16 -0000 --001a113e3b24c7dc23052ee632dd Content-Type: text/plain; charset=UTF-8 I did intend for the parenthetical to follow "provided TBID", but I see how I was not clear. My meaning is that the user's identity has already been bound to the provided TBID, and we wish to bind it to the referred TBID. That is, the client has a cookie (or cookies) for the IdP that are bound to a TBID. When the IdP creates a federated token and binds it to a referred TBID, it needs to verify that the provided TBID (which it knows already belongs to the user) and the referred TBID belong to the same client. On Fri, Mar 25, 2016 at 2:18 PM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote: > I wish to clarify just this one little point here.. > > > I think the takeaway from this is when a federated token is created > > and bound to a referred TBID, the provided TBID (that the user's > > identity is bound to) and the referred TBID ... > > ..shouldn't the above rather read.. > > I think the takeaway from this is when a federated token is created > and bound to a referred TBID, the provided TBID and the referred > TBID (that the user's identity is bound to) ... > > ..? > > I am interpreting "user's identity is bound to" as being the ID Token (in > OIDC case) or SAML assertion (in SAML case) that the IDP generates (and > which needs to be bound to the correct TBID). > > thanks, > > =JeffH > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a113e3b24c7dc23052ee632dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I did intend for the parenthetical to follow "provide= d TBID", but I see how I was not clear. My meaning is that the user= 9;s identity has already been bound to the provided TBID, and we wish to bi= nd it to the referred TBID.<div><br></div><div>That is, the client has a co= okie (or cookies) for the IdP that are bound to a TBID. When the IdP create= s a federated token and binds it to a referred TBID, it needs to verify tha= t the provided TBID (which it knows already belongs to the user) and the re= ferred TBID belong to the same client.</div></div><div class=3D"gmail_extra= "><br><div class=3D"gmail_quote">On Fri, Mar 25, 2016 at 2:18 PM, =3DJeffH = <span dir=3D"ltr"><<a href=3D"mailto:Jeff.Hodges@kingsmountain.com" targ= et=3D"_blank">Jeff.Hodges@kingsmountain.com</a>></span> wrote:<br><block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex">I wish to clarify just this one little point here.= .<span class=3D""><br> <br> > I think the takeaway from this is when a federated token is created<br= > > and bound to a referred TBID, the provided TBID (that the user's<b= r></span> > identity is bound to) and the referred TBID ...<br> <br> ..shouldn't the above rather read..<span class=3D""><br> <br> =C2=A0 I think the takeaway from this is when a federated token is created<= br></span> =C2=A0 and bound to a referred TBID, the provided TBID and the referred<br> =C2=A0 TBID (that the user's identity is bound to) ...<br> <br> ..?<br> <br> I am interpreting "user's identity is bound to" as being the = ID Token (in<br> OIDC case) or SAML assertion (in SAML case) that the IDP generates (and<br> which needs to be bound to the correct TBID).<br> <br> thanks,<br> <br> =3DJeffH<div class=3D"HOEnZb"><div class=3D"h5"><br> <br> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> </div></div></blockquote></div><br></div> --001a113e3b24c7dc23052ee632dd-- From nobody Fri Mar 25 15:10:23 2016 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 661D312D854 for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 15:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_HELO_PASS=-0.001, SPF_PASS=-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 00a6BasKkmhq for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 15:10:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0798.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::798]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5667112D799 for <unbearable@ietf.org>; Fri, 25 Mar 2016 15:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cj35Lt3iVYYUgkuf0M8kusn9hyFbjAIIBsBp+1wvca0=; b=NjFLKim89nK5RTXIjrsgFr0oqNU43E32iMy1aIWkttHJ/ZpWTGpIbGMZ52wOU2TFKNFhTjvJqXzsIqrziXIfDGwzvuPUPtXuMkQX/v9Xgy0rF/nu+wWOGJaRajuu9LuetKJNNoiEGW+l2FfUUiD0YDA7C8BmWn2HVAb1lCivTag= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.434.16; Fri, 25 Mar 2016 22:10:00 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0434.023; Fri, 25 Mar 2016 22:10:00 +0000 From: Andrei Popov <Andrei.Popov@microsoft.com> To: =JeffH <Jeff.Hodges@KingsMountain.com>, IETF Tokbind WG <unbearable@ietf.org> Thread-Topic: [Unbearable] -protocol-04 & -https-02: MITM TBID substitution in bound security tokens? Thread-Index: AQHRdZctvc3dlqoZJEC3hnQkeEhsN59q2pdg Date: Fri, 25 Mar 2016 22:10:00 +0000 Message-ID: <BLUPR03MB1396732835701A4C46AFD3088C830@BLUPR03MB1396.namprd03.prod.outlook.com> References: <56D8B256.60702@KingsMountain.com> In-Reply-To: <56D8B256.60702@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: KingsMountain.com; dkim=none (message not signed) header.d=none;KingsMountain.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:3::1d2] x-ms-office365-filtering-correlation-id: b314aab2-2b74-41ac-7a91-08d354fa3578 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:YqDoDlmFpFZiaYvjdeJ+QeywfGVbk5Umt/EERvY90UwbsTdDiCkrjNgSyKigEqHL9vRVhB4xMsrLsO9VqYrl+EWeXkxRzduo5XCso9T1Kivj5inAqOftJ1hwUdVqomdQXEznS+/6ae1t9Medb4KHcA==; 24:t3Uth+t0nzPpI4FUypzeIoBRK83D2opXByOeLg25mUbJN/iC791aJYxF/fHf2XkzprEdXaaDxIrrvTJLxpuqSKR+6enjGeZQTjrbwUXbhmM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: <BLUPR03MB13960CD09CC0B7B1E62494758C830@BLUPR03MB1396.namprd03.prod.outlook.com> x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 0892FA9A88 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(164054003)(13464003)(2950100001)(2900100001)(77096005)(15975445007)(74316001)(11100500001)(5004730100002)(5008740100001)(19580405001)(81166005)(19580395003)(54356999)(50986999)(76176999)(87936001)(33656002)(106116001)(8990500004)(99286002)(575784001)(5003600100002)(1096002)(86362001)(5001770100001)(1220700001)(76576001)(15650500001)(10090500001)(122556002)(586003)(92566002)(10290500002)(3660700001)(189998001)(2906002)(3280700002)(6116002)(102836003)(5002640100001)(5005710100001)(107886002)(3826002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2016 22:10:00.4556 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/oivoyOY7stej6Q34v9mJeJDPako> Subject: Re: [Unbearable] -protocol-04 & -https-02: MITM TBID substitution in bound security tokens? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 25 Mar 2016 22:10:22 -0000 Yes, the token needs to be integrity-protected. Will add this security cons= ideration to TBPROTO. Thanks, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of =3DJeffH Sent: Thursday, March 3, 2016 1:53 PM To: IETF Tokbind WG <unbearable@ietf.org> Subject: [Unbearable] -protocol-04 & -https-02: MITM TBID substitution in b= ound security tokens? summary: if TokenBindingIDs (TBIDs) are contained within application secur= ity tokens (e.g., authn cookies, OIDC ID Tokens, SAML authn assertions, etc= ), or by reference, without the binding to said security tokens being integ= rity-protected in some fashion, then what prevents a man-in-the-middle (MITM) entity, as contextually defined in S 4.5 of -tokbind-https-02, from = (in the simplest case) performing a cut-and-paste substitution of their TBI= D with the server, into said security token before conveying it to the serv= er? This sec cons wrinkle doesn't seem to be addressed in either spec -- a secu= rity considerations suggestion is at the end below. HTH, =3DJeffH details: From HTTPSTB https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2ftools.ie= tf.org%2fhtml%2fdraft-ietf-tokbind-https-02%23section-4.5%3a&data=3D01%7c01= %7cAndrei.Popov%40microsoft.com%7c0994d7e8f3ac46a1cdaa08d343ae4e0c%7c72f988= bf86f141af91ab2d7cd011db47%7c1&sdata=3DOrOoi9teVWJ6htB086I6nCu7i7jleChQrV1p= o7ZMoDE%3d > 4.5. Securing Federated Sign-On Protocols > > [...] > > o A man-in-the-middle is allowed to intercept the connection between > client and Token Consumer or between Client and Token Provider (or > both). > > The goal is to detect the presence of the man-in-the-middle in these > scenarios. > > First, consider a man-in-the-middle between the client and the Token > Provider. Recall that we assume that the client possesses a bound > authentication token (e.g., cookie) for the Token Provider. The man- > in-the-middle can intercept and modify any message sent by the client > to the Token Provider, and any message sent by the Token Provider to > the client. (This means, among other things, that the man-in-the- > middle controls the Javascript running at the client in the origin of > the Token Provider.) It is not, however, in possession of the > client's Token Binding key. Therefore, it can either choose to > replace the Token Binding key in requests from the client to the > Token Provider, and create a Token-Binding header that matches the > TLS connection between the man-in-the-middle and the Token Provider; > or it can choose to leave the Token-Binding header unchanged. > > If it chooses the latter, the signature in the Token Binding message > (created by the original client on the exported keying material (EKM) > for the connection between client and man-in-the-middle) will not > match the EKM between man-in-the-middle and the Token Provider. > > If it chooses the former (and creates its own signature, with its own > Token Binding key, over the EKM for the connection between man-in- > the-middle and Token Provider), then the Token Binding message will > match the connection between man-in-the-middle and Token Provider, > but the Token Binding key in the message will not match the Token > Binding key that the client's authentication token is bound to. In the case where the TBID is contained directly within the authn token, wh= at is preventing the MITM from substituting its own TBID, for the MITM's to= ken-bound TLS session with the Token Provider, within the client's authn to= ken? See also S 6 (below) from TBPROTO -- >From TBPROTO https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2ftools.ie= tf.org%2fhtml%2fdraft-ietf-tokbind-protocol-04%23section-6&data=3D01%7c01%7= cAndrei.Popov%40microsoft.com%7c0994d7e8f3ac46a1cdaa08d343ae4e0c%7c72f988bf= 86f141af91ab2d7cd011db47%7c1&sdata=3DKAsvD1MIU18OHAsT7asxtIT6FkJQ%2bdUz5yCV= esw3PKU%3d : > 6. Security Token Validation > > Security tokens can be bound to the TLS layer either by embedding the > Token Binding ID in the token, or by maintaining a database mapping > tokens to Token Binding IDs. The specific method of generating bound > security tokens is application-defined and beyond the scope of this > document. > > [...] Although I agree with the latter statement above wrt details of generating = bound security tokens, are there not some overall security considerations t= hat TBPROTO could/should mention? E.g.. The manner in which a Token Binding ID is bound to an application security token is application-defined, however, there are overall security considerations which the application developers and deployers should be aware of: it should not be possible for a MITM to substitute another TBID for the one bound to an app security token without detection. This can be accomplished in various ways, e.g., a directly-bound security token can be cryptographically integrity- protected, or, the TBID may be bound to the security token by reference in a fashion that is not susceptible to direct substitution. end _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7cAndrei.Popov%40micr= osoft.com%7c0994d7e8f3ac46a1cdaa08d343ae4e0c%7c72f988bf86f141af91ab2d7cd011= db47%7c1&sdata=3DiYoMPO22FAoGFtrAaczPCvW7q8qoP5A6%2beI52XCZ%2bfA%3d From nobody Fri Mar 25 16:50:08 2016 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 D17BC12D86E for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 16:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 R9zLq7FbXdY8 for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 16:50:04 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0104.outbound.protection.outlook.com [65.55.169.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA5512D7D2 for <unbearable@ietf.org>; Fri, 25 Mar 2016 16:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=J3jdnoqdRBUFaS2eF0BSYYz29bE9BQk/KYrBMRsHuUE=; b=QQT/SiahblpOwLzTqtR2FnsmVhDMIo2Ir1Ax+agst7MPd9OXsYLwLWXRP7M/+As+ngpZgarkC5VnJmnkXWcWOdXePRbNdEGtCNmWz+KZNLh7g9DC678E4JKYNfs5JKTQlGBYyBbF0oQ1hapn88l8U4mDwQzVgVh1gtdTWYJqUwo= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.434.16; Fri, 25 Mar 2016 23:50:02 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0434.023; Fri, 25 Mar 2016 23:50:02 +0000 From: Andrei Popov <Andrei.Popov@microsoft.com> To: IETF Tokbind WG <unbearable@ietf.org> Thread-Topic: draft-ietf-tokbind-protocol-05 is available on GitHub Thread-Index: AdGG8B5FiYagYD6+R1S0U9qWohfJsA== Date: Fri, 25 Mar 2016 23:50:02 +0000 Message-ID: <BLUPR03MB1396970663B5B579CDEF59D78C830@BLUPR03MB1396.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:3::1d2] x-ms-office365-filtering-correlation-id: 774de706-6a70-4ea4-3aa8-08d355082f10 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:s/frf1UI9qDnzV41Pu+1+ErdzeYlT6U2zQo0RqSfzbMH5J3wPkwUgmtwmsPy2k4F5uoUb+eThtMEz5x+KLqDu29FCFQzP3chK6dmWUC88wfA/8C3agpfQ4NZ71GNaUdCa+5XSXPLcuhFzxu/2iEUDw==; 24:voFcsXNmPOZbzPc/hw6VT9STjFQjZ3X9e3yZfU7GBR90Rq4QWIrUin4QeolBtNCPJjYMOs5pqKsfKZBtRG1IYTh1wgBgmPq0Ct0DZ0EY+bY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: <BLUPR03MB139633888A7DE92A688F4F4A8C830@BLUPR03MB1396.namprd03.prod.outlook.com> x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 0892FA9A88 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(52044002)(164054003)(77096005)(450100001)(2900100001)(15975445007)(230783001)(11100500001)(5004730100002)(74316001)(229853001)(19617315012)(5008740100001)(19625215002)(81166005)(19580395003)(50986999)(54356999)(87936001)(33656002)(8990500004)(99286002)(5003600100002)(1096002)(86362001)(76576001)(1220700001)(16236675004)(10090500001)(122556002)(586003)(92566002)(10290500002)(3660700001)(19300405004)(3280700002)(189998001)(2906002)(6116002)(110136002)(102836003)(790700001)(5002640100001)(5005710100001)(107886002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1396970663B5B579CDEF59D78C830BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2016 23:50:02.4876 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/iJrlS0v8swCB_lq6RmTpp6UFR0U> Subject: [Unbearable] draft-ietf-tokbind-protocol-05 is available on GitHub X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 25 Mar 2016 23:50:07 -0000 --_000_BLUPR03MB1396970663B5B579CDEF59D78C830BLUPR03MB1396namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The updated draft-ietf-tokbind-protocol-05 is available on GitHub: https://= github.com/TokenBinding/Internet-Drafts Will upload to IETF once the submission tool re-opens. The -05 revision contains mostly editorial changes based on review feedback= : - IANA considerations updated to include a registration for the TL= S exporter label. - Security considerations updated to warn about the need to integr= ity-protect bound tokens. I believe I've either responded to or incorporated all feedback received so= far, but please feel free to bring it up again if I've missed something. Looking forward to further comments and pull requests, Thanks, Andrei --_000_BLUPR03MB1396970663B5B579CDEF59D78C830BLUPR03MB1396namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:#0563C1; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:#954F72; text-decoration:underline;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri",sans-serif;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri",sans-serif; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-family:"Calibri",sans-serif;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} /* List Definitions */ @list l0 {mso-list-id:374818733; mso-list-type:hybrid; mso-list-template-ids:-889713586 -449686048 67698691 67698693 67698689 676= 98691 67698693 67698689 67698691 67698693;} @list l0:level1 {mso-level-start-at:113; mso-level-number-format:bullet; mso-level-text:-; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:"Calibri",sans-serif; mso-fareast-font-family:Calibri; mso-bidi-font-family:"Times New Roman";} @list l0:level2 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:"Courier New";} @list l0:level3 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings;} @list l0:level4 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Symbol;} @list l0:level5 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:"Courier New";} @list l0:level6 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings;} @list l0:level7 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Symbol;} @list l0:level8 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:"Courier New";} @list l0:level9 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in; font-family:Wingdings;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">The updated draft-ietf-tokbind-protocol-05 is availa= ble on GitHub: <a href=3D"https://github.com/TokenBinding/Internet-Drafts">https://github.= com/TokenBinding/Internet-Drafts</a><o:p></o:p></p> <p class=3D"MsoNormal">Will upload to IETF once the submission tool re-open= s.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">The -05 revision contains mostly editorial changes b= ased on review feedback:<o:p></o:p></p> <p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level= 1 lfo1"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style= =3D"font:7.0pt "Times New Roman"">     &= nbsp;    </span></span><![endif]>IANA considerations updated to include a registrati= on for the TLS exporter label.<o:p></o:p></p> <p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level= 1 lfo1"><![if !supportLists]><span style=3D"mso-list:Ignore">-<span style= =3D"font:7.0pt "Times New Roman"">     &= nbsp;    </span></span><![endif]>Security considerations updated to warn about the n= eed to integrity-protect bound tokens.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">I believe I’ve either responded to or incorpor= ated all feedback received so far, but please feel free to bring it up agai= n if I’ve missed something.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Looking forward to further comments and pull request= s,<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Thanks,<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Andrei<o:p></o:p></p> </div> </body> </html> --_000_BLUPR03MB1396970663B5B579CDEF59D78C830BLUPR03MB1396namp_-- From nobody Fri Mar 25 19:56:05 2016 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 7940E12D1A9 for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 19:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 REfPwQaa96rC for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 19:56:00 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 14AB612D1D9 for <unbearable@ietf.org>; Fri, 25 Mar 2016 19:56:00 -0700 (PDT) Received: (qmail 26051 invoked by uid 0); 26 Mar 2016 02:55:56 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 26 Mar 2016 02:55:56 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id aSvo1s0082UhLwi01SvrNr; Fri, 25 Mar 2016 20:55:54 -0600 X-Authority-Analysis: v=2.1 cv=Nal1iQz4 c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7OsogOcEt9IA:10 a=LxdYO_XFJReRysEQjTIA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=gtU0V03+J8aOBohgN60pGxGNVU+GClz9MSOlXUfE87k=; b=CsHaGhBUi9l86ocr9jgUNxdwwN N3WivZthphbgZHHxXld+BpIIK6SnX+dfk8R+FLiFWsWIHEgRqbXzFQlnvmuSv+tUym8QoTt/k96oD I6svqNhnspp/DGSuhytD2O9M9; Received: from [73.202.80.238] (port=45661 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1ajeOE-0002PI-3U for unbearable@ietf.org; Fri, 25 Mar 2016 20:55:50 -0600 To: IETF Tokbind WG <unbearable@ietf.org> From: =JeffH <Jeff.Hodges@KingsMountain.com> Message-ID: <56F5FA41.4020705@KingsMountain.com> Date: Fri, 25 Mar 2016 19:56:01 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/mOxTYPcH9u4sVAc9ietKxeP_HHU> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 26 Mar 2016 02:56:02 -0000 On Monday, March 21, 2016 at 1:40 PM, Nick wrote: > My understanding of the problem in figure 1 is that > > 1) in the redirect from TC2 to TP3 (step 2b), the referred TBID > is TBID2, while the redirect uri is to TC1, and.. yes, this is an issue -- in this case TBID1 needs to be (somehow) relayed. > 2) when TP3 redirects to TP4, somehow TBID2 needs to be relayed. actually, TBID1 needs to be relayed (somehow) rather then TBID2 because that is what is being called for in the "fed layer's" authn request's redirect_uri. > One way to solve problem 2 is to treat the TP3->TP4 redirect like the > "identity-as-a-service" scenario that Dirk mentioned. Instead of TP4 > redirecting to TC1, it can create a token to be consumed by TP3, and > redirect to TP3, which will then create a token to send back to TC1. IMV it is inappropriate for us to specify a solution like that (i.e., chaining IDPs) in -tokbind-https aka HTTPSTB -- such a configuration is up to how the fed layer is config'd and deployed. It may or may not be appropriate for a given federation. > For problem 1, I am going to assume that TC1 and TC2 are cooperating. > The easiest way to fix this is to have TC2 transmit to TC1 > out-of-band what TBID2 is so that TC1 can verify it. did you mean to say: have TC1 transmit out-of-band TBID1 to TC2 ? ..because the issue here in needing to relay TBID1 somehow, unless I'm missing something. > Here's another solution (for both problems) that I think could work... > ..<elided>.. The above other solution elided due to the below subsequent analysis. On Thursday, March 24, 2016 at 3:15 PM, Nick wrote: > TL;DR: Use Include-Referer-Token-Binding-ID. Binding a token to an > ID that hasn't been verified can result in a MitM getting control of > a bound token. > > Dirk and I chatted about my/David's proposal, and how it applies to > Jeff's scenario. In steps 3a and 3b from figure 1, TBID3 needs to be > referred to TP4 (in addition to conveying TBID2). actually, conveying TBID3 to TP4 is optional IMV and one would only need to do it if TP4 is also minting other bound sec tokens eg cookies with TBID3 in 'em. Also, it is TBID1 that actually needs to be referred, in order to properly issue the ID Token. The remark in (the old) figure 1 wrt "somehow conveys TBID2 ?" is simply a reference to Dirk's comments where he suggested that that is what we'd do here. See updated figure 1a below. > The problem with the current setup of figure 1 is when there is an > attacker MitMing connections to TP3. In step 2b, the > TokenBindingMessage contains TBID3' and TBID2', both under attacker > control. Then, in step 3b, when the client follows the redirect from > (the MitM'd) TP3 to TP4, it includes TBID4, but not TBID3, in the > TokenBindingMessage. When TP4 authenticates the user, TBID4 is > correct, and then TP4 creates a token for the user's identity with an > attacker-controlled TBID. Even if TP3 and TP4 are somehow > cooperating, and the provided and referred token bindings from the > request in step 2b are passed from TP3 to TP4 out-of-band, the token > still has an attacker controlled TBID, since the token bindings sent > in step 2b are attacker controlled. agreed with the above except that it is TBID1 that really needs to be conveyed to ultimately to TP4 in order for the latter to correctly issue the OIDC ID Token, or SAML assertion or whatever, at the fed layer. On Friday, March 25, 2016 at 10:49 AM, Dirk wrote: > Agreed. Bottom line is that I still believe that a single referred > token binding (even on repeated redirects) gives us all we need. I agree it is "all we need" _if_ we are saying that it is out-of-scope for HTTPSTB to specify how, in a multi-redirect scenario such as fig 1a, for the correct referred TBID to be conveyed to the TC's point-of-handoff-to-TP, and similarly out-of-scope for any redirects among TP entities per HTTPSTB spec (i.e., they figger it out themselves). I.e., we _can_ say the above I think -- tho some may perceive it as sub-optimal to just leave it unspecified -- but it may not be that big a deal, I don't know. (federation folk please speak up here !) We could devise some means of signaling in the HTTPSTB header field layer from TC-to-TC and TP-to-TP what the correct TBID to use is (hm, it will require integrity protection from the postulated MITMs) and that might save the fed layer folks from inventing disjoint ways to do it (and hm, however they do it will need integrity protection)... But we may not want to go there, I'm not sure myself. HTH, =JeffH ------ Figure 1a: ( Note: if this fig gets inserted into the spec it will likely _not_ be labeled "fig 1" there ) What: Analysis of redirect hops at RP aka TC and at IDP aka TP Legend: (see figure 1 in a prior email msg) Client, Token Consumer, Token Provider, aka: aka: aka: User Agent OpenID Client, OpenID Provider, OIDC Relying Party, OIDC Provider, SAML Relying Party SAML Identity Provider [ servers "1", "2" ] [ servers "3", "4" ] +--------+ +-----+ +-----+ +-----+ +-----+ | Client | | TC1 | | TC2 | | TP3 | | TP4 | +--------+ +-----+ +-----+ +-----+ +-----+ | | | | | | | | | | | 0. Client interacts w/TC1 | | | over HTTPS, establishes Ks1 & Kp1, TBID1 | | | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | | |------------------------------>| | | | | | | | | | | | | | | 1a. redirect to TC2 for TC-specific reasons | | | any security-relevant cookies should contain TBID1 | | +<- - - - - - - - - - - - - - - - | | | | . | | | | | +----------------------------------------->| | | | 1b. establishes Ks2 & Kp2, TBID2 | | | | ETBMSG[[{EKM2}Ks2,TBID2,provided_token_binding]] | | | | | | | | | | | | | | | | | | 2a. OIDC ID Token request, | | | | | aka "Authentication Request" w/ redirect_uri=TC1; <-- note well | conveyed w/ HTTP response header field of: | | | Include-Referer-Token-Binding-ID:true | | | any security-relevant cookies should contain TBID2 | | +<- - - - - - - - - - - - - - - - - - - - -| | | . | (redirect to TP via 301, 302, | | | | . | 303, 307, or 308) | | | | . | | | | | +----------------------------------------------------->| | | 2b. client opens HTTPS w/ TP3, | | | | establishes Ks3, Kp3, TBID3; | | | | sends GET or POST with | | | | ID Token request w/ redirect_uri=TC1, | | | | ETBMSG[[{EKM3}Ks3,TBID3,provided_token_binding], | | [{EKM3}Ks2,TBID2,referred_token_binding]] <-- but ID Tok request | | | <-- is for TC1 | | | | | | | | | | | | | | | | 3a. redirect to TP4 for TP-specific reasons | | | any security-relevant cookies should contain TBID3 | | +<- - - - - - - - - - - - - - - - - - - - - - - - - - -| | . | | | | | +--------------------------------------------------------------->| | 3b. client opens HTTPS w/ TP4, | | | | establishes Ks4 & Kp4, TBID4 | | | | ETBMSG[[{EKM4}Ks4,TBID4,provided_token_binding]] | | | *** as well as the ID Token request w/ redirect_uri=TC1; | *** also, somehow conveys TBID1 to TP4 <-- Need this to | | | <-- issue bound | | | <-- ID Token | | | | | | 4. user authentication (if applicable, | | | methods vary, particulars are out of scope) | | |<============================================================>| | (TP generates ID Token for TC1 containing TBID1 <-- Need to get | also set cookie(s) containing TBID4 and/or TBID3 <-- TBID1 here | details vary) | | | | | | | | | | | | | | | | | | | | 5a. ID Token issued for TC1, containing TBID1, <-- how do this if | conveyed via OIDC "Authentication Response" <-- don't have TBID1? +<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| . | (redirect to TC1) | | | | . | | | | | +-------------------------------->| | | | | 5b. HTTPS GET or POST with | | | | | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | | | conveying Authn Reponse containing ID Token w/TBID1, | | issued for TC1 | | | | | | | | | | | | | | | | | | | | | | 6. user is signed-on, any security-relevant cookie(s) | | that are set SHOULD contain TBID1 | | | |<------------------------------| | | | | | | | | | | | | | From nobody Fri Mar 25 20:34:10 2016 Return-Path: <nharper@google.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 EC68A12D1A9 for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 20:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 512--vUEjGIq for <unbearable@ietfa.amsl.com>; Fri, 25 Mar 2016 20:34:06 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FBB712D1BC for <unbearable@ietf.org>; Fri, 25 Mar 2016 20:34:06 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id e6so107344119vkh.2 for <unbearable@ietf.org>; Fri, 25 Mar 2016 20:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M0kC5pM+KiNsTh76t6UQkthV61uSY5gvkp8OEvNjpmc=; b=ctj1jl7It8EU0Ik3zV74k+7bZvpZjACgIrno6oW6C3wsRZFA5iDzfOXTRs/P+gK4WK Y0L3fF8e4KaBOYNkyAOw5gnN9mCDZgx7pbBeb1PDZXBF2UjVTGMaORvEDcsLUVJRfJ9O lkxCISpFGNM2x85RbaM9+X71FmlESE+5WvKM4oZQDcsi/WIivGdBca5NyVygXu9hRKvl DYavlQT7BOyJtN+xNcx5Ad9VN2+mLv4wN09J0DtO5cTpo5rL6utR3n1eiKWxYqtbbXPU xiuixhb1kdwQ7q4F/46hGxmW2DPMTcxEGY6PXYec0M9MGPClMXx5IWfhiceaQUqN9XTe 7PXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M0kC5pM+KiNsTh76t6UQkthV61uSY5gvkp8OEvNjpmc=; b=er6BAIEH1MoAzW+M/Zf/nIuU2b2KBUT1mzzPmkqGySo/yOm9A6zmD5IW70/WW7N+Ut /sSVzOv9/Wsdf9oam0k3/cm+XFdQT9dSgBi9WZtbdcNb3apB2hNugYQlALqlfJN/oFYN A8h5jUWywYeh27fFIruPbgYi0PBefGY672bCXStPV7HwVTPqOYjlnR17QZdjo89Cj9W7 0AjfRCYO8pp23lcjaInIidF75HINJGJIbBasE3QXF4b2KN0AVqfUp4lue0Aw6c4mUIHe bsp8tl3CuZq2n4eRNRBbnU9Rx9zWQtThKa/6HmDjsb4N+NgL0L4Go7Sl373ROvd2NFPA BrjA== X-Gm-Message-State: AD7BkJIxNaY8tkhS7NydGMxvKMMwQIekr4A1F5RpioUKMy9qsfn5O6FXPvt5RyT7D7XjkLjyqpkFlrZlbMdlDtCJ X-Received: by 10.159.35.51 with SMTP id 48mr9248670uae.121.1458963244924; Fri, 25 Mar 2016 20:34:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.76.198 with HTTP; Fri, 25 Mar 2016 20:33:45 -0700 (PDT) In-Reply-To: <56F5FA41.4020705@KingsMountain.com> References: <56F5FA41.4020705@KingsMountain.com> From: Nick Harper <nharper@google.com> Date: Fri, 25 Mar 2016 20:33:45 -0700 Message-ID: <CACdeXi+NoqixLVO1zCogPoKaZrbDDspV8mZ_W2DQG8RWBQSNtA@mail.gmail.com> To: "=JeffH" <Jeff.Hodges@kingsmountain.com> Content-Type: multipart/alternative; boundary=001a113d0ad2f48d20052eeb5983 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/52-dY8gpa7DzyWeJ5WHhk_MaEyE> Cc: IETF Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 26 Mar 2016 03:34:09 -0000 --001a113d0ad2f48d20052eeb5983 Content-Type: text/plain; charset=UTF-8 If you want TP4 to generate a token bound to TBID1, then TP4 needs to verify that TBID4 and TBID1 are both owned by the same client. IMO, the easiest way to do this is to have both TBIDs in the same TokenBindingMessage. I'm curious if this scenario (with TC1, TC2, TP3, and TP4) is hypothetical, or if there are real-world setups that work like this where TC1 can't redirect directly to TP4, or you can't have TP4 issue a token for TP3, which then issues a token for TC2, which issues a token for TC1 (as Dirk suggests). I can think of a federated scenario that currently exists where there are multiple token consumers and producers, but it works with a single referred token binding from Include-Referer-Token-Binding-ID. 1) Some app A wishes to let users log in with their google account. When the user clicks A's login button, they get redirected to google's login page G (with Include-Referer-Token-Binding-ID). 2) The user wishes to log in to google with their university's gmail account. They start working through the login flow for their username@university.edu account, and G redirects them to the university's IdP to log in. 3) The user logs in to the university's IdP, which generates a SAML token bound to TBID_G. The university's IdP passes this SAML token back to google. 4) Google verifies this token, and now generates an OpenID Connect token to pass back to A, and binds it to the referred TBID_A that was passed to G in the initial redirect A->G. 5) A now has a token from G that is bound to TBID_A. If there are situations where there is a need for TP4 to generate a token for TC1, then I think changes would be needed to TBHTTPS to support that. One such change could be for Include-Referer-Token-Binding-ID to pass along all TBIDs from the previous request instead of just one. This would only work if there was a single chain of redirects from TC1 all the way to TP4. Once TP4 receives this TokenBindingMessage with TBID1, TBID2, TBID3, and TBID4 (and verifies all of them), it could issue a token that is bound to all of them, and then TC1 iterates through the bound TBIDs to find one that it recognizes. On Fri, Mar 25, 2016 at 7:56 PM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote: > On Monday, March 21, 2016 at 1:40 PM, Nick wrote: > > My understanding of the problem in figure 1 is that > > > > 1) in the redirect from TC2 to TP3 (step 2b), the referred TBID > > is TBID2, while the redirect uri is to TC1, and.. > > yes, this is an issue -- in this case TBID1 needs to be (somehow) relayed. > > > > 2) when TP3 redirects to TP4, somehow TBID2 needs to be relayed. > > actually, TBID1 needs to be relayed (somehow) rather then TBID2 because > that is what is being called for in the "fed layer's" authn request's > redirect_uri. > > > > One way to solve problem 2 is to treat the TP3->TP4 redirect like the > > "identity-as-a-service" scenario that Dirk mentioned. Instead of TP4 > > redirecting to TC1, it can create a token to be consumed by TP3, and > > redirect to TP3, which will then create a token to send back to TC1. > > IMV it is inappropriate for us to specify a solution like that (i.e., > chaining IDPs) in -tokbind-https aka HTTPSTB -- such a configuration is up > to how the fed layer is config'd and deployed. It may or may not be > appropriate for a given federation. > > > > For problem 1, I am going to assume that TC1 and TC2 are cooperating. > > The easiest way to fix this is to have TC2 transmit to TC1 > > out-of-band what TBID2 is so that TC1 can verify it. > > did you mean to say: have TC1 transmit out-of-band TBID1 to TC2 ? > ..because the issue here in needing to relay TBID1 somehow, unless I'm > missing something. > > > > Here's another solution (for both problems) that I think could work... > > ..<elided>.. > > The above other solution elided due to the below subsequent analysis. > > > On Thursday, March 24, 2016 at 3:15 PM, Nick wrote: > > TL;DR: Use Include-Referer-Token-Binding-ID. Binding a token to an > > ID that hasn't been verified can result in a MitM getting control of > > a bound token. > > > > Dirk and I chatted about my/David's proposal, and how it applies to > > Jeff's scenario. In steps 3a and 3b from figure 1, TBID3 needs to be > > referred to TP4 (in addition to conveying TBID2). > > actually, conveying TBID3 to TP4 is optional IMV and one would only need > to do it if TP4 is also minting other bound sec tokens eg cookies with > TBID3 in 'em. > > Also, it is TBID1 that actually needs to be referred, in order to properly > issue the ID Token. The remark in (the old) figure 1 wrt "somehow conveys > TBID2 ?" is simply a reference to Dirk's comments where he suggested that > that is what we'd do here. See updated figure 1a below. > > > > The problem with the current setup of figure 1 is when there is an > > attacker MitMing connections to TP3. In step 2b, the > > TokenBindingMessage contains TBID3' and TBID2', both under attacker > > control. Then, in step 3b, when the client follows the redirect from > > (the MitM'd) TP3 to TP4, it includes TBID4, but not TBID3, in the > > TokenBindingMessage. When TP4 authenticates the user, TBID4 is > > correct, and then TP4 creates a token for the user's identity with an > > attacker-controlled TBID. Even if TP3 and TP4 are somehow > > cooperating, and the provided and referred token bindings from the > > request in step 2b are passed from TP3 to TP4 out-of-band, the token > > still has an attacker controlled TBID, since the token bindings sent > > in step 2b are attacker controlled. > > agreed with the above except that it is TBID1 that really needs to be > conveyed to ultimately to TP4 in order for the latter to correctly issue > the OIDC ID Token, or SAML assertion or whatever, at the fed layer. > > > On Friday, March 25, 2016 at 10:49 AM, Dirk wrote: > > Agreed. Bottom line is that I still believe that a single referred > > token binding (even on repeated redirects) gives us all we need. > > I agree it is "all we need" _if_ we are saying that it is out-of-scope for > HTTPSTB to specify how, in a multi-redirect scenario such as fig 1a, for > the correct referred TBID to be conveyed to the TC's > point-of-handoff-to-TP, and similarly out-of-scope for any redirects among > TP entities per HTTPSTB spec (i.e., they figger it out themselves). > > I.e., we _can_ say the above I think -- tho some may perceive it as > sub-optimal to just leave it unspecified -- but it may not be that big a > deal, I don't know. (federation folk please speak up here !) > > We could devise some means of signaling in the HTTPSTB header field layer > from TC-to-TC and TP-to-TP what the correct TBID to use is (hm, it will > require integrity protection from the postulated MITMs) and that might save > the fed layer folks from inventing disjoint ways to do it (and hm, however > they do it will need integrity protection)... > > But we may not want to go there, I'm not sure myself. > > HTH, > > =JeffH > ------ > > > Figure 1a: ( Note: if this fig gets inserted into the spec it will > likely _not_ be labeled "fig 1" there ) > What: Analysis of redirect hops at RP aka TC and at IDP aka TP > > Legend: (see figure 1 in a prior email msg) > > > Client, Token Consumer, Token Provider, > aka: aka: aka: > User Agent OpenID Client, OpenID Provider, > OIDC Relying Party, OIDC Provider, > SAML Relying Party SAML Identity Provider > [ servers "1", "2" ] [ servers "3", "4" ] > +--------+ +-----+ +-----+ +-----+ +-----+ > | Client | | TC1 | | TC2 | | TP3 | | TP4 | > +--------+ +-----+ +-----+ +-----+ +-----+ > | | | | | > | | | | | > | 0. Client interacts w/TC1 | | > | over HTTPS, establishes Ks1 & Kp1, TBID1 | | > | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | | > |------------------------------>| | | | > | | | | | > | | | | | > | 1a. redirect to TC2 for TC-specific reasons | | > | any security-relevant cookies should contain TBID1 | | > +<- - - - - - - - - - - - - - - - | | | | > . | | | | | > +----------------------------------------->| | | > | 1b. establishes Ks2 & Kp2, TBID2 | | | > | ETBMSG[[{EKM2}Ks2,TBID2,provided_token_binding]] | | > | | | | | > | | | | | > | | | | | > | 2a. OIDC ID Token request, | | | | > | aka "Authentication Request" w/ redirect_uri=TC1; <-- note well > | conveyed w/ HTTP response header field of: | | > | Include-Referer-Token-Binding-ID:true | | > | any security-relevant cookies should contain TBID2 | | > +<- - - - - - - - - - - - - - - - - - - - -| | | > . | (redirect to TP via 301, 302, | | | | > . | 303, 307, or 308) | | | | > . | | | | | > +----------------------------------------------------->| | > | 2b. client opens HTTPS w/ TP3, | | | > | establishes Ks3, Kp3, TBID3; | | | > | sends GET or POST with | | | > | ID Token request w/ redirect_uri=TC1, | | | > | ETBMSG[[{EKM3}Ks3,TBID3,provided_token_binding], | > | [{EKM3}Ks2,TBID2,referred_token_binding]] <-- but ID Tok > request > | | | <-- is for TC1 > | | | | | > | | | | | > | | | | | > | 3a. redirect to TP4 for TP-specific reasons | | > | any security-relevant cookies should contain TBID3 | | > +<- - - - - - - - - - - - - - - - - - - - - - - - - - -| | > . | | | | | > +--------------------------------------------------------------->| > | 3b. client opens HTTPS w/ TP4, | | | > | establishes Ks4 & Kp4, TBID4 | | | > | ETBMSG[[{EKM4}Ks4,TBID4,provided_token_binding]] | | > | *** as well as the ID Token request w/ redirect_uri=TC1; > | *** also, somehow conveys TBID1 to TP4 <-- Need this to > | | | <-- issue bound > | | | <-- ID Token > | | | | | > | 4. user authentication (if applicable, | | > | methods vary, particulars are out of scope) | | > |<============================================================>| > | (TP generates ID Token for TC1 containing TBID1 <-- Need to get > | also set cookie(s) containing TBID4 and/or TBID3 <-- TBID1 here > | details vary) | | | | > | | | | | > | | | | | > | | | | | > | 5a. ID Token issued for TC1, containing TBID1, <-- how do this if > | conveyed via OIDC "Authentication Response" <-- don't have TBID1? > +<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| > . | (redirect to TC1) | | | | > . | | | | | > +-------------------------------->| | | | > | 5b. HTTPS GET or POST with | | | | > | ETBMSG[[{EKM1}Ks1,TBID1,provided_token_binding]] | | > | conveying Authn Reponse containing ID Token w/TBID1, | > | issued for TC1 | > | | | | | > | | | | | > | | | | | > | | | | | > | 6. user is signed-on, any security-relevant cookie(s) | > | that are set SHOULD contain TBID1 | | | > |<------------------------------| | | | > | | | | | > | | | | | > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a113d0ad2f48d20052eeb5983 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+SWYgeW91IHdhbnQgVFA0IHRvIGdlbmVyYXRlIGEgdG9rZW4gYm91bmQg dG8gVEJJRDEsIHRoZW4gVFA0IG5lZWRzIHRvIHZlcmlmeSB0aGF0IFRCSUQ0IGFuZCBUQklEMSBh cmUgYm90aCBvd25lZCBieSB0aGUgc2FtZSBjbGllbnQuIElNTywgdGhlIGVhc2llc3Qgd2F5IHRv IGRvIHRoaXMgaXMgdG8gaGF2ZSBib3RoIFRCSURzIGluIHRoZSBzYW1lIFRva2VuQmluZGluZ01l c3NhZ2UuIEkmIzM5O20gY3VyaW91cyBpZiB0aGlzIHNjZW5hcmlvICh3aXRoIFRDMSwgVEMyLCBU UDMsIGFuZCBUUDQpIGlzIGh5cG90aGV0aWNhbCwgb3IgaWYgdGhlcmUgYXJlIHJlYWwtd29ybGQg c2V0dXBzIHRoYXQgd29yayBsaWtlIHRoaXMgd2hlcmUgVEMxIGNhbiYjMzk7dCByZWRpcmVjdCBk aXJlY3RseSB0byBUUDQsIG9yIHlvdSBjYW4mIzM5O3QgaGF2ZSBUUDQgaXNzdWUgYSB0b2tlbiBm b3IgVFAzLCB3aGljaCB0aGVuIGlzc3VlcyBhIHRva2VuIGZvciBUQzIsIHdoaWNoIGlzc3VlcyBh IHRva2VuIGZvciBUQzEgKGFzIERpcmsgc3VnZ2VzdHMpLjxkaXY+PGJyPjwvZGl2PjxkaXY+SSBj YW4gdGhpbmsgb2YgYSBmZWRlcmF0ZWQgc2NlbmFyaW8gdGhhdCBjdXJyZW50bHkgZXhpc3RzIHdo ZXJlIHRoZXJlIGFyZSBtdWx0aXBsZSB0b2tlbiBjb25zdW1lcnMgYW5kIHByb2R1Y2VycywgYnV0 IGl0IHdvcmtzIHdpdGggYSBzaW5nbGUgcmVmZXJyZWQgdG9rZW4gYmluZGluZyBmcm9tIEluY2x1 ZGUtUmVmZXJlci1Ub2tlbi1CaW5kaW5nLUlELjwvZGl2PjxkaXY+MSkgU29tZSBhcHAgQSB3aXNo ZXMgdG8gbGV0IHVzZXJzIGxvZyBpbiB3aXRoIHRoZWlyIGdvb2dsZSBhY2NvdW50LiBXaGVuIHRo ZSB1c2VyIGNsaWNrcyBBJiMzOTtzIGxvZ2luIGJ1dHRvbiwgdGhleSBnZXQgcmVkaXJlY3RlZCB0 byBnb29nbGUmIzM5O3MgbG9naW4gcGFnZSBHICh3aXRoIEluY2x1ZGUtUmVmZXJlci1Ub2tlbi1C aW5kaW5nLUlEKS48L2Rpdj48ZGl2PjIpIFRoZSB1c2VyIHdpc2hlcyB0byBsb2cgaW4gdG8gZ29v Z2xlIHdpdGggdGhlaXIgdW5pdmVyc2l0eSYjMzk7cyBnbWFpbCBhY2NvdW50LiBUaGV5IHN0YXJ0 IHdvcmtpbmcgdGhyb3VnaCB0aGUgbG9naW4gZmxvdyBmb3IgdGhlaXIgPGEgaHJlZj0ibWFpbHRv OnVzZXJuYW1lQHVuaXZlcnNpdHkuZWR1Ij51c2VybmFtZUB1bml2ZXJzaXR5LmVkdTwvYT4gYWNj b3VudCwgYW5kIEcgcmVkaXJlY3RzIHRoZW0gdG8gdGhlIHVuaXZlcnNpdHkmIzM5O3MgSWRQIHRv IGxvZyBpbi48L2Rpdj48ZGl2PjMpIFRoZSB1c2VyIGxvZ3MgaW4gdG8gdGhlIHVuaXZlcnNpdHkm IzM5O3MgSWRQLCB3aGljaCBnZW5lcmF0ZXMgYSBTQU1MIHRva2VuIGJvdW5kIHRvIFRCSURfRy4g VGhlIHVuaXZlcnNpdHkmIzM5O3MgSWRQIHBhc3NlcyB0aGlzIFNBTUwgdG9rZW4gYmFjayB0byBn b29nbGUuPC9kaXY+PGRpdj40KSBHb29nbGUgdmVyaWZpZXMgdGhpcyB0b2tlbiwgYW5kIG5vdyBn ZW5lcmF0ZXMgYW4gT3BlbklEIENvbm5lY3QgdG9rZW4gdG8gcGFzcyBiYWNrIHRvIEEsIGFuZCBi aW5kcyBpdCB0byB0aGUgcmVmZXJyZWQgVEJJRF9BIHRoYXQgd2FzIHBhc3NlZCB0byBHIGluIHRo ZSBpbml0aWFsIHJlZGlyZWN0IEEtJmd0O0cuPC9kaXY+PGRpdj41KSBBIG5vdyBoYXMgYSB0b2tl biBmcm9tIEcgdGhhdCBpcyBib3VuZCB0byBUQklEX0EuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp dj5JZiB0aGVyZSBhcmUgc2l0dWF0aW9ucyB3aGVyZSB0aGVyZSBpcyBhIG5lZWQgZm9yIFRQNCB0 byBnZW5lcmF0ZSBhIHRva2VuIGZvciBUQzEsIHRoZW4gSSB0aGluayBjaGFuZ2VzIHdvdWxkIGJl IG5lZWRlZCB0byBUQkhUVFBTIHRvIHN1cHBvcnQgdGhhdC4gT25lIHN1Y2ggY2hhbmdlIGNvdWxk IGJlIGZvciBJbmNsdWRlLVJlZmVyZXItVG9rZW4tQmluZGluZy1JRCB0byBwYXNzIGFsb25nIGFs bCBUQklEcyBmcm9tIHRoZSBwcmV2aW91cyByZXF1ZXN0IGluc3RlYWQgb2YganVzdCBvbmUuIFRo aXMgd291bGQgb25seSB3b3JrIGlmIHRoZXJlIHdhcyBhIHNpbmdsZSBjaGFpbiBvZiByZWRpcmVj dHMgZnJvbSBUQzEgYWxsIHRoZSB3YXkgdG8gVFA0LiBPbmNlIFRQNCByZWNlaXZlcyB0aGlzIFRv a2VuQmluZGluZ01lc3NhZ2Ugd2l0aCBUQklEMSwgVEJJRDIsIFRCSUQzLCBhbmQgVEJJRDQgKGFu ZCB2ZXJpZmllcyBhbGwgb2YgdGhlbSksIGl0IGNvdWxkIGlzc3VlIGEgdG9rZW4gdGhhdCBpcyBi b3VuZCB0byBhbGwgb2YgdGhlbSwgYW5kIHRoZW4gVEMxIGl0ZXJhdGVzIHRocm91Z2ggdGhlIGJv dW5kIFRCSURzIHRvIGZpbmQgb25lIHRoYXQgaXQgcmVjb2duaXplcy48L2Rpdj48L2Rpdj48ZGl2 IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBGcmks IE1hciAyNSwgMjAxNiBhdCA3OjU2IFBNLCA9SmVmZkggPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBo cmVmPSJtYWlsdG86SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20iIHRhcmdldD0iX2JsYW5r Ij5KZWZmLkhvZGdlc0BraW5nc21vdW50YWluLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+ PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7 Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PHNwYW4gY2xhc3M9 IiI+T24gTW9uZGF5LCBNYXJjaCAyMSwgMjAxNiBhdCAxOjQwIFBNLCBOaWNrIHdyb3RlOjxicj4N CiZndDsgTXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgcHJvYmxlbSBpbiBmaWd1cmUgMSBpcyB0aGF0 PGJyPg0KJmd0Ozxicj48L3NwYW4+DQomZ3Q7IDEpIGluIHRoZSByZWRpcmVjdCBmcm9tIFRDMiB0 byBUUDMgKHN0ZXAgMmIpLCB0aGUgcmVmZXJyZWQgVEJJRDxicj4NCiZndDsgaXMgVEJJRDIsIHdo aWxlIHRoZSByZWRpcmVjdCB1cmkgaXMgdG8gVEMxLCBhbmQuLjxicj4NCjxicj4NCnllcywgdGhp cyBpcyBhbiBpc3N1ZSAtLSBpbiB0aGlzIGNhc2UgVEJJRDEgbmVlZHMgdG8gYmUgKHNvbWVob3cp IHJlbGF5ZWQuPHNwYW4gY2xhc3M9IiI+PGJyPg0KPGJyPg0KPGJyPg0KJmd0OyAyKSB3aGVuIFRQ MyByZWRpcmVjdHMgdG8gVFA0LCBzb21laG93IFRCSUQyIG5lZWRzIHRvIGJlIHJlbGF5ZWQuPGJy Pg0KPGJyPjwvc3Bhbj4NCmFjdHVhbGx5LCBUQklEMSBuZWVkcyB0byBiZSByZWxheWVkIChzb21l aG93KSByYXRoZXIgdGhlbiBUQklEMiBiZWNhdXNlIHRoYXQgaXMgd2hhdCBpcyBiZWluZyBjYWxs ZWQgZm9yIGluIHRoZSAmcXVvdDtmZWQgbGF5ZXImIzM5O3MmcXVvdDsgYXV0aG4gcmVxdWVzdCYj Mzk7cyByZWRpcmVjdF91cmkuPHNwYW4gY2xhc3M9IiI+PGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBP bmUgd2F5IHRvIHNvbHZlIHByb2JsZW0gMiBpcyB0byB0cmVhdCB0aGUgVFAzLSZndDtUUDQgcmVk aXJlY3QgbGlrZSB0aGU8YnI+DQomZ3Q7ICZxdW90O2lkZW50aXR5LWFzLWEtc2VydmljZSZxdW90 OyBzY2VuYXJpbyB0aGF0IERpcmsgbWVudGlvbmVkLiBJbnN0ZWFkIG9mIFRQNDxicj4NCiZndDsg cmVkaXJlY3RpbmcgdG8gVEMxLCBpdCBjYW4gY3JlYXRlIGEgdG9rZW4gdG8gYmUgY29uc3VtZWQg YnkgVFAzLCBhbmQ8YnI+DQomZ3Q7IHJlZGlyZWN0IHRvIFRQMywgd2hpY2ggd2lsbCB0aGVuIGNy ZWF0ZSBhIHRva2VuIHRvIHNlbmQgYmFjayB0byBUQzEuPGJyPg0KPGJyPjwvc3Bhbj4NCklNViBp dCBpcyBpbmFwcHJvcHJpYXRlIGZvciB1cyB0byBzcGVjaWZ5IGEgc29sdXRpb24gbGlrZSB0aGF0 IChpLmUuLCBjaGFpbmluZyBJRFBzKSBpbiAtdG9rYmluZC1odHRwcyBha2EgSFRUUFNUQiAtLSBz dWNoIGEgY29uZmlndXJhdGlvbiBpcyB1cCB0byBob3cgdGhlIGZlZCBsYXllciBpcyBjb25maWcm IzM5O2QgYW5kIGRlcGxveWVkLiBJdCBtYXkgb3IgbWF5IG5vdCBiZSBhcHByb3ByaWF0ZSBmb3Ig YSBnaXZlbiBmZWRlcmF0aW9uLjxzcGFuIGNsYXNzPSIiPjxicj4NCjxicj4NCjxicj4NCiZndDsg Rm9yIHByb2JsZW0gMSwgSSBhbSBnb2luZyB0byBhc3N1bWUgdGhhdCBUQzEgYW5kIFRDMiBhcmUg Y29vcGVyYXRpbmcuPGJyPg0KJmd0OyBUaGUgZWFzaWVzdCB3YXkgdG8gZml4IHRoaXMgaXMgdG8g aGF2ZSBUQzIgdHJhbnNtaXQgdG8gVEMxPGJyPg0KJmd0OyBvdXQtb2YtYmFuZCB3aGF0IFRCSUQy IGlzIHNvIHRoYXQgVEMxIGNhbiB2ZXJpZnkgaXQuPGJyPg0KPGJyPjwvc3Bhbj4NCmRpZCB5b3Ug bWVhbiB0byBzYXk6IGhhdmUgVEMxIHRyYW5zbWl0IG91dC1vZi1iYW5kIFRCSUQxIHRvIFRDMiA/ IC4uYmVjYXVzZSB0aGUgaXNzdWUgaGVyZSBpbiBuZWVkaW5nIHRvIHJlbGF5IFRCSUQxIHNvbWVo b3csIHVubGVzcyBJJiMzOTttIG1pc3Npbmcgc29tZXRoaW5nLjxicj4NCjxicj4NCjxicj4NCiZn dDsgSGVyZSYjMzk7cyBhbm90aGVyIHNvbHV0aW9uIChmb3IgYm90aCBwcm9ibGVtcykgdGhhdCBJ IHRoaW5rIGNvdWxkIHdvcmsuLi48YnI+DQomZ3Q7IC4uJmx0O2VsaWRlZCZndDsuLjxicj4NCjxi cj4NClRoZSBhYm92ZSBvdGhlciBzb2x1dGlvbiBlbGlkZWQgZHVlIHRvIHRoZSBiZWxvdyBzdWJz ZXF1ZW50IGFuYWx5c2lzLjxzcGFuIGNsYXNzPSIiPjxicj4NCjxicj4NCjxicj4NCk9uIFRodXJz ZGF5LCBNYXJjaCAyNCwgMjAxNiBhdCAzOjE1IFBNLCBOaWNrIHdyb3RlOjxicj4NCiZndDsgVEw7 RFI6IFVzZSBJbmNsdWRlLVJlZmVyZXItVG9rZW4tQmluZGluZy1JRC4gQmluZGluZyBhIHRva2Vu IHRvIGFuPGJyPg0KJmd0OyBJRCB0aGF0IGhhc24mIzM5O3QgYmVlbiB2ZXJpZmllZCBjYW4gcmVz dWx0IGluIGEgTWl0TSBnZXR0aW5nIGNvbnRyb2wgb2Y8YnI+DQomZ3Q7IGEgYm91bmQgdG9rZW4u PGJyPg0KJmd0Ozxicj4NCiZndDsgRGlyayBhbmQgSSBjaGF0dGVkIGFib3V0IG15L0RhdmlkJiMz OTtzIHByb3Bvc2FsLCBhbmQgaG93IGl0IGFwcGxpZXMgdG88YnI+DQomZ3Q7IEplZmYmIzM5O3Mg c2NlbmFyaW8uIEluIHN0ZXBzIDNhIGFuZCAzYiBmcm9tIGZpZ3VyZSAxLCBUQklEMyBuZWVkcyB0 byBiZTxicj4NCiZndDsgcmVmZXJyZWQgdG8gVFA0IChpbiBhZGRpdGlvbiB0byBjb252ZXlpbmcg VEJJRDIpLjxicj4NCjxicj48L3NwYW4+DQphY3R1YWxseSwgY29udmV5aW5nIFRCSUQzIHRvIFRQ NCBpcyBvcHRpb25hbCBJTVYgYW5kIG9uZSB3b3VsZCBvbmx5IG5lZWQgdG8gZG8gaXQgaWYgVFA0 IGlzIGFsc28gbWludGluZyBvdGhlciBib3VuZCBzZWMgdG9rZW5zIGVnIGNvb2tpZXMgd2l0aCBU QklEMyBpbiAmIzM5O2VtLjxicj4NCjxicj4NCkFsc28sIGl0IGlzIFRCSUQxIHRoYXQgYWN0dWFs bHkgbmVlZHMgdG8gYmUgcmVmZXJyZWQsIGluIG9yZGVyIHRvIHByb3Blcmx5IGlzc3VlIHRoZSBJ RCBUb2tlbi4gVGhlIHJlbWFyayBpbiAodGhlIG9sZCkgZmlndXJlIDEgd3J0ICZxdW90O3NvbWVo b3cgY29udmV5cyBUQklEMiA/JnF1b3Q7IGlzIHNpbXBseSBhIHJlZmVyZW5jZSB0byBEaXJrJiMz OTtzIGNvbW1lbnRzIHdoZXJlIGhlIHN1Z2dlc3RlZCB0aGF0IHRoYXQgaXMgd2hhdCB3ZSYjMzk7 ZCBkbyBoZXJlLiBTZWUgdXBkYXRlZCBmaWd1cmUgMWEgYmVsb3cuPHNwYW4gY2xhc3M9IiI+PGJy Pg0KPGJyPg0KPGJyPg0KJmd0OyBUaGUgcHJvYmxlbSB3aXRoIHRoZSBjdXJyZW50IHNldHVwIG9m IGZpZ3VyZSAxIGlzIHdoZW4gdGhlcmUgaXMgYW48YnI+DQomZ3Q7IGF0dGFja2VyIE1pdE1pbmcg Y29ubmVjdGlvbnMgdG8gVFAzLiBJbiBzdGVwIDJiLCB0aGU8YnI+DQomZ3Q7IFRva2VuQmluZGlu Z01lc3NhZ2UgY29udGFpbnMgVEJJRDMmIzM5OyBhbmQgVEJJRDImIzM5OywgYm90aCB1bmRlciBh dHRhY2tlcjxicj4NCiZndDsgY29udHJvbC4gVGhlbiwgaW4gc3RlcCAzYiwgd2hlbiB0aGUgY2xp ZW50IGZvbGxvd3MgdGhlIHJlZGlyZWN0IGZyb208YnI+DQomZ3Q7ICh0aGUgTWl0TSYjMzk7ZCkg VFAzIHRvIFRQNCwgaXQgaW5jbHVkZXMgVEJJRDQsIGJ1dCBub3QgVEJJRDMsIGluIHRoZTxicj4N CiZndDsgVG9rZW5CaW5kaW5nTWVzc2FnZS4gV2hlbiBUUDQgYXV0aGVudGljYXRlcyB0aGUgdXNl ciwgVEJJRDQgaXM8YnI+DQomZ3Q7IGNvcnJlY3QsIGFuZCB0aGVuIFRQNCBjcmVhdGVzIGEgdG9r ZW4gZm9yIHRoZSB1c2VyJiMzOTtzIGlkZW50aXR5IHdpdGggYW48YnI+DQomZ3Q7IGF0dGFja2Vy LWNvbnRyb2xsZWQgVEJJRC4gRXZlbiBpZiBUUDMgYW5kIFRQNCBhcmUgc29tZWhvdzxicj4NCiZn dDsgY29vcGVyYXRpbmcsIGFuZCB0aGUgcHJvdmlkZWQgYW5kIHJlZmVycmVkIHRva2VuIGJpbmRp bmdzIGZyb20gdGhlPGJyPg0KJmd0OyByZXF1ZXN0IGluIHN0ZXAgMmIgYXJlIHBhc3NlZCBmcm9t IFRQMyB0byBUUDQgb3V0LW9mLWJhbmQsIHRoZSB0b2tlbjxicj4NCiZndDsgc3RpbGwgaGFzIGFu IGF0dGFja2VyIGNvbnRyb2xsZWQgVEJJRCwgc2luY2UgdGhlIHRva2VuIGJpbmRpbmdzIHNlbnQ8 YnI+DQomZ3Q7IGluIHN0ZXAgMmIgYXJlIGF0dGFja2VyIGNvbnRyb2xsZWQuPGJyPg0KPGJyPjwv c3Bhbj4NCmFncmVlZCB3aXRoIHRoZSBhYm92ZSBleGNlcHQgdGhhdCBpdCBpcyBUQklEMSB0aGF0 IHJlYWxseSBuZWVkcyB0byBiZSBjb252ZXllZCB0byB1bHRpbWF0ZWx5IHRvIFRQNCBpbiBvcmRl ciBmb3IgdGhlIGxhdHRlciB0byBjb3JyZWN0bHkgaXNzdWUgdGhlIE9JREMgSUQgVG9rZW4sIG9y IFNBTUwgYXNzZXJ0aW9uIG9yIHdoYXRldmVyLCBhdCB0aGUgZmVkIGxheWVyLjxzcGFuIGNsYXNz PSIiPjxicj4NCjxicj4NCjxicj4NCk9uIEZyaWRheSwgTWFyY2ggMjUsIDIwMTYgYXQgMTA6NDkg QU0sIERpcmsgd3JvdGU6PGJyPg0KJmd0OyBBZ3JlZWQuIEJvdHRvbSBsaW5lIGlzIHRoYXQgSSBz dGlsbCBiZWxpZXZlIHRoYXQgYSBzaW5nbGUgcmVmZXJyZWQ8YnI+DQomZ3Q7IHRva2VuIGJpbmRp bmcgKGV2ZW4gb24gcmVwZWF0ZWQgcmVkaXJlY3RzKSBnaXZlcyB1cyBhbGwgd2UgbmVlZC48YnI+ DQo8YnI+PC9zcGFuPg0KSSBhZ3JlZSBpdCBpcyAmcXVvdDthbGwgd2UgbmVlZCZxdW90OyBfaWZf IHdlIGFyZSBzYXlpbmcgdGhhdCBpdCBpcyBvdXQtb2Ytc2NvcGUgZm9yIEhUVFBTVEIgdG8gc3Bl Y2lmeSBob3csIGluIGEgbXVsdGktcmVkaXJlY3Qgc2NlbmFyaW8gc3VjaCBhcyBmaWcgMWEsIGZv ciB0aGUgY29ycmVjdCByZWZlcnJlZCBUQklEIHRvIGJlIGNvbnZleWVkIHRvIHRoZSBUQyYjMzk7 cyBwb2ludC1vZi1oYW5kb2ZmLXRvLVRQLCBhbmQgc2ltaWxhcmx5IG91dC1vZi1zY29wZSBmb3Ig YW55IHJlZGlyZWN0cyBhbW9uZyBUUCBlbnRpdGllcyBwZXIgSFRUUFNUQiBzcGVjIChpLmUuLCB0 aGV5IGZpZ2dlciBpdCBvdXQgdGhlbXNlbHZlcykuPGJyPg0KPGJyPg0KSS5lLiwgd2UgX2Nhbl8g c2F5IHRoZSBhYm92ZSBJIHRoaW5rIC0tIHRobyBzb21lIG1heSBwZXJjZWl2ZSBpdCBhcyBzdWIt b3B0aW1hbCB0byBqdXN0IGxlYXZlIGl0IHVuc3BlY2lmaWVkIC0tIGJ1dCBpdCBtYXkgbm90IGJl IHRoYXQgYmlnIGEgZGVhbCwgSSBkb24mIzM5O3Qga25vdy4gKGZlZGVyYXRpb24gZm9sayBwbGVh c2Ugc3BlYWsgdXAgaGVyZSAhKTxicj4NCjxicj4NCldlIGNvdWxkIGRldmlzZSBzb21lIG1lYW5z IG9mIHNpZ25hbGluZyBpbiB0aGUgSFRUUFNUQiBoZWFkZXIgZmllbGQgbGF5ZXIgZnJvbSBUQy10 by1UQyBhbmQgVFAtdG8tVFAgd2hhdCB0aGUgY29ycmVjdCBUQklEIHRvIHVzZSBpcyAoaG0sIGl0 IHdpbGwgcmVxdWlyZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBmcm9tIHRoZSBwb3N0dWxhdGVkIE1J VE1zKSBhbmQgdGhhdCBtaWdodCBzYXZlIHRoZSBmZWQgbGF5ZXIgZm9sa3MgZnJvbSBpbnZlbnRp bmcgZGlzam9pbnQgd2F5cyB0byBkbyBpdCAoYW5kIGhtLCBob3dldmVyIHRoZXkgZG8gaXQgd2ls bCBuZWVkIGludGVncml0eSBwcm90ZWN0aW9uKS4uLjxicj4NCjxicj4NCkJ1dCB3ZSBtYXkgbm90 IHdhbnQgdG8gZ28gdGhlcmUsIEkmIzM5O20gbm90IHN1cmUgbXlzZWxmLjxicj4NCjxicj4NCkhU SCw8YnI+DQo8YnI+DQo9SmVmZkg8YnI+DQotLS0tLS08YnI+DQo8YnI+DQo8YnI+DQpGaWd1cmUg MWE6wqAgwqAoIE5vdGU6IGlmIHRoaXMgZmlnIGdldHMgaW5zZXJ0ZWQgaW50byB0aGUgc3BlYyBp dCB3aWxsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBsaWtlbHkgX25vdF8g YmUgbGFiZWxlZCAmcXVvdDtmaWcgMSZxdW90OyB0aGVyZSApPHNwYW4gY2xhc3M9IiI+PGJyPg0K V2hhdDogQW5hbHlzaXMgb2YgcmVkaXJlY3QgaG9wcyBhdCBSUCBha2EgVEMgYW5kIGF0IElEUCBh a2EgVFA8YnI+DQo8YnI+PC9zcGFuPg0KTGVnZW5kOiAoc2VlIGZpZ3VyZSAxIGluIGEgcHJpb3Ig ZW1haWwgbXNnKTxicj4NCjxicj4NCjxicj4NCkNsaWVudCzCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBUb2tlbiBDb25zdW1lcizCoCDCoCDCoCDCoCDCoFRva2VuIFByb3ZpZGVyLDxi cj4NCmFrYTrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGFrYTrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBha2E6PGJyPg0KVXNlciBBZ2VudMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgT3BlbklEIENsaWVudCzCoCDCoCDCoCDCoCDCoCBPcGVuSUQgUHJvdmlk ZXIsPHNwYW4gY2xhc3M9IiI+PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBPSURDIFJlbHlpbmcgUGFydHkswqAgwqAgwqBPSURDIFByb3ZpZGVyLDxicj48 L3NwYW4+PHNwYW4gY2xhc3M9IiI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoFNBTUwgUmVseWluZyBQYXJ0ecKgIMKgIMKgIFNBTUwgSWRlbnRpdHkgUHJvdmlk ZXI8YnI+PC9zcGFuPjxkaXY+PGRpdiBjbGFzcz0iaDUiPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBbIHNlcnZlcnMgJnF1b3Q7MSZxdW90OywgJnF1b3Q7MiZx dW90OyBdwqAgwqAgWyBzZXJ2ZXJzICZxdW90OzMmcXVvdDssICZxdW90OzQmcXVvdDsgXTxicj4N CistLS0tLS0tLSvCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCstLS0tLSvCoCAr LS0tLS0rwqAgwqAgwqArLS0tLS0rwqAgwqArLS0tLS0rPGJyPg0KfCBDbGllbnQgfMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfCBUQzEgfMKgIHwgVEMyIHzCoCDCoCDCoHwgVFAz IHzCoCDCoHwgVFA0IHw8YnI+DQorLS0tLS0tLS0rwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqArLS0tLS0rwqAgKy0tLS0tK8KgIMKgIMKgKy0tLS0tK8KgIMKgKy0tLS0tKzxicj4N CsKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzC oCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAg fMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKg IMKgIHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCB8IDAuIENs aWVudCBpbnRlcmFjdHMgdy9UQzHCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfCBvdmVyIEhUVFBTLCBlc3RhYmxpc2hlcyBL czEgJmFtcDsgS3AxLCBUQklEMcKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgfDxicj4N CsKgIMKgIHwgRVRCTVNHW1t7RUtNMX1LczEsVEJJRDEscHJvdmlkZWRfdG9rZW5fYmluZGluZ11d wqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSZndDt8wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKg fDxicj4NCsKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHzCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0K wqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKg IMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCB8 IDFhLiByZWRpcmVjdCB0byBUQzIgZm9yIFRDLXNwZWNpZmljIHJlYXNvbnPCoCDCoCDCoCDCoCB8 wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfCBhbnkgc2VjdXJpdHktcmVsZXZhbnQgY29va2ll cyBzaG91bGQgY29udGFpbiBUQklEMSB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgKyZsdDstIC0g LSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIHzCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAg wqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgLiB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKg IMKgIMKgIMKgfDxicj4NCsKgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSZndDt8wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfCAx Yi4gZXN0YWJsaXNoZXMgS3MyICZhbXA7IEtwMiwgVEJJRDLCoCDCoCDCoCDCoHzCoCDCoCDCoCDC oCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCB8IEVUQk1TR1tbe0VLTTJ9S3MyLFRC SUQyLHByb3ZpZGVkX3Rva2VuX2JpbmRpbmddXcKgIMKgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKg IMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDC oCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKg IHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCB8wqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgfMKgIMKg IMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIHwgMmEuIE9JREMgSUQgVG9r ZW4gcmVxdWVzdCzCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKg IMKgIMKgfDxicj4NCsKgIMKgIHwgYWthICZxdW90O0F1dGhlbnRpY2F0aW9uIFJlcXVlc3QmcXVv dDsgdy8gcmVkaXJlY3RfdXJpPVRDMTvCoCAmbHQ7LS0gbm90ZSB3ZWxsPGJyPg0KwqAgwqAgfCBj b252ZXllZCB3LyBIVFRQIHJlc3BvbnNlIGhlYWRlciBmaWVsZCBvZjrCoCDCoCDCoCDCoCDCoHzC oCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCB8wqAgwqBJbmNsdWRlLVJlZmVyZXItVG9rZW4tQmlu ZGluZy1JRDp0cnVlwqAgwqAgwqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKg IHwgYW55IHNlY3VyaXR5LXJlbGV2YW50IGNvb2tpZXMgc2hvdWxkIGNvbnRhaW4gVEJJRDIgfMKg IMKgIMKgIMKgIMKgfDxicj4NCsKgICsmbHQ7LSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0g LSAtIC0gLSAtIC18wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgLiB8 IChyZWRpcmVjdCB0byBUUCB2aWEgMzAxLCAzMDIsIHzCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAg wqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgLiB8wqAgMzAzLCAzMDcsIG9yIDMwOCnCoCDC oCDCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKg IMKgfDxicj4NCsKgIC4gfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgfMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+ DQrCoCArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0mZ3Q7fMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIHwgMmIuIGNsaWVudCBvcGVucyBIVFRQ UyB3LyBUUDMswqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8 PGJyPg0KwqAgwqAgfCBlc3RhYmxpc2hlcyBLczMsIEtwMywgVEJJRDM7wqAgwqAgwqAgwqAgwqAg wqB8wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfCBzZW5kcyBH RVQgb3IgUE9TVCB3aXRowqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAg wqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfCBJRCBUb2tlbiByZXF1ZXN0IHcvIHJlZGly ZWN0X3VyaT1UQzEswqAgfMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKg IMKgIHwgRVRCTVNHW1t7RUtNM31LczMsVEJJRDMscHJvdmlkZWRfdG9rZW5fYmluZGluZ10swqAg wqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfMKgIMKgIMKgIMKgW3tFS00zfUtzMixUQklE MixyZWZlcnJlZF90b2tlbl9iaW5kaW5nXV0gJmx0Oy0tIGJ1dCBJRCBUb2sgcmVxdWVzdDxicj4N CsKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzC oCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgJmx0Oy0tIGlzIGZvciBUQzE8YnI+DQrCoCDCoCB8wqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAg fMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIHzCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8wqAgwqAg wqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDC oCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCB8IDNhLiByZWRpcmVjdCB0byBUUDQgZm9y IFRQLXNwZWNpZmljIHJlYXNvbnPCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAg wqAgfCBhbnkgc2VjdXJpdHktcmVsZXZhbnQgY29va2llcyBzaG91bGQgY29udGFpbiBUQklEMyB8 wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgKyZsdDstIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0g LSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLXzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCAuIHzCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8 wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8PGJy Pg0KwqAgwqAgfCAzYi4gY2xpZW50IG9wZW5zIEhUVFBTIHcvIFRQNCzCoCDCoCDCoCDCoCDCoHzC oCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCB8IGVzdGFibGlzaGVz IEtzNCAmYW1wOyBLcDQsIFRCSUQ0wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqB8 wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfCBFVEJNU0dbW3tFS000fUtzNCxUQklENCxwcm92 aWRlZF90b2tlbl9iaW5kaW5nXV3CoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCB8wqAg wqAgwqAgwqAgwqAqKiogYXMgd2VsbCBhcyB0aGUgSUQgVG9rZW4gcmVxdWVzdCB3LyByZWRpcmVj dF91cmk9VEMxOzxicj48L2Rpdj48L2Rpdj4NCsKgIMKgIHzCoCDCoCDCoCDCoCDCoCoqKiBhbHNv LCBzb21laG93IGNvbnZleXMgVEJJRDEgdG8gVFA0ICZsdDstLSBOZWVkIHRoaXMgdG88YnI+DQrC oCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAg wqAgwqAgwqAgfMKgIMKgIMKgIMKgJmx0Oy0tIGlzc3VlIGJvdW5kPGJyPg0KwqAgwqAgfMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIHzC oCDCoCDCoCDCoCZsdDstLSBJRCBUb2tlbjxzcGFuIGNsYXNzPSIiPjxicj4NCsKgIMKgIHzCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8 wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfCA0LiB1c2VyIGF1 dGhlbnRpY2F0aW9uIChpZiBhcHBsaWNhYmxlLMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKg IMKgIMKgfDxicj4NCsKgIMKgIHzCoCDCoCBtZXRob2RzIHZhcnksIHBhcnRpY3VsYXJzIGFyZSBv dXQgb2Ygc2NvcGUpwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfCZsdDs9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0m Z3Q7fDxicj48L3NwYW4+DQrCoCDCoCB8IChUUCBnZW5lcmF0ZXMgSUQgVG9rZW4gZm9yIFRDMSBj b250YWluaW5nIFRCSUQxwqAgwqAmbHQ7LS0gTmVlZCB0byBnZXQ8YnI+DQrCoCDCoCB8wqAgYWxz byBzZXQgY29va2llKHMpIGNvbnRhaW5pbmcgVEJJRDQgYW5kL29yIFRCSUQzICZsdDstLSBUQklE MSBoZXJlPHNwYW4gY2xhc3M9ImltIEhPRW5aYiI+PGJyPg0KwqAgwqAgfMKgIGRldGFpbHMgdmFy eSnCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKg fMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAg wqAgwqAgwqB8PGJyPg0KwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDC oHw8YnI+DQrCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqB8wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgfDxicj4N CsKgIMKgIHwgNWEuIElEIFRva2VuIGlzc3VlZCBmb3IgVEMxLCBjb250YWluaW5nIFRCSUQxLCAm bHQ7LS0gaG93IGRvIHRoaXMgaWY8YnI+DQrCoCDCoCB8wqAgwqAgY29udmV5ZWQgdmlhIE9JREMg JnF1b3Q7QXV0aGVudGljYXRpb24gUmVzcG9uc2UmcXVvdDsgJmx0Oy0tIGRvbiYjMzk7dCBoYXZl IFRCSUQxPzxicj4NCsKgICsmbHQ7LSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0g LSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtfDxicj4NCsKgIC4gfMKgIMKgKHJlZGlyZWN0IHRv IFRDMSnCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqB8wqAg wqAgwqAgwqAgwqB8PGJyPg0KwqAgLiB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKg IMKgfDxicj4NCsKgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8wqAgwqAg wqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIHwgNWIu IEhUVFBTIEdFVCBvciBQT1NUIHdpdGjCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKg IMKgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIHwgRVRCTVNHW1t7RUtNMX1LczEsVEJJRDEs cHJvdmlkZWRfdG9rZW5fYmluZGluZ11dwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAg fCBjb252ZXlpbmcgQXV0aG4gUmVwb25zZSBjb250YWluaW5nIElEIFRva2VuIHcvVEJJRDEswqAg wqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlzc3VlZCBmb3IgVEMxwqAgwqAgwqAgwqAgwqAgwqAgfDxi cj4NCsKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oHzCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAg wqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKg IMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCB8wqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAg fMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIHzCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8wqAgwqAg wqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgfCA2LiB1c2VyIGlzIHNpZ25l ZC1vbiwgYW55IHNlY3VyaXR5LXJlbGV2YW50IGNvb2tpZShzKcKgIMKgIMKgIMKgIHw8YnI+DQrC oCDCoCB8IHRoYXQgYXJlIHNldCBTSE9VTEQgY29udGFpbiBUQklEMcKgIMKgIMKgIHzCoCDCoCDC oCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCB8Jmx0Oy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLXzCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAg wqAgwqB8PGJyPg0KwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgfMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoHw8 YnI+DQrCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqB8wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgfDxicj4NCjxi cj48L3NwYW4+PGRpdiBjbGFzcz0iSE9FblpiIj48ZGl2IGNsYXNzPSJoNSI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClVuYmVhcmFibGUgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5VbmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZSIgcmVsPSJub3JlZmVycmVy IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91 bmJlYXJhYmxlPC9hPjxicj4NCjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9k aXY+DQo= --001a113d0ad2f48d20052eeb5983-- From nobody Sun Mar 27 10:10:32 2016 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 6230312D1B7 for <unbearable@ietfa.amsl.com>; Sun, 27 Mar 2016 10:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 2eQdK6g7SBsK for <unbearable@ietfa.amsl.com>; Sun, 27 Mar 2016 10:10:29 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id C939212D1AE for <unbearable@ietf.org>; Sun, 27 Mar 2016 10:10:29 -0700 (PDT) Received: (qmail 25137 invoked by uid 0); 27 Mar 2016 17:10:27 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 27 Mar 2016 17:10:27 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id bCAK1s00G2UhLwi01CANlP; Sun, 27 Mar 2016 18:10:24 -0600 X-Authority-Analysis: v=2.1 cv=Maz/5fPf c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7OsogOcEt9IA:10 a=ieNpE_y6AAAA:8 a=xonXGGwuOix9TNq2cHcA:9 a=QEXdDO2ut3YA:10 a=8jT8sO8vu7cA:10 a=9qO-vq0wQ1sA:10 a=3Jth8Htmo3MA:10 a=K-YDP-jLr_8A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:To:Subject:From; bh=sCocOxNrIPs0EH5Z4Rysbmv60aH29NJeWWZakRfCNdw=; b=b6nvpNwUPkZT1mmlYmOjmmEbFG kSNTHCndHDmt3syoTIMDUum654tD4slo2ujqsD4T0NO5kAfeGO8oQIzJsEGAj00MAd0c3YWvxvxig vD6/rjvkQhn2S9wIdGRvHscKJ; Received: from [73.202.80.238] (port=48528 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1akECk-00053x-Cb for unbearable@ietf.org; Sun, 27 Mar 2016 11:10:22 -0600 From: =JeffH <Jeff.Hodges@KingsMountain.com> To: IETF Tokbind WG <unbearable@ietf.org> Message-ID: <56F81406.8000207@KingsMountain.com> Date: Sun, 27 Mar 2016 10:10:30 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/vHcntCBGA70W4c15NFgN9N8_Orc> Subject: [Unbearable] diff from -tokbind-protocol-04 to -05.. X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 27 Mar 2016 17:10:31 -0000 ..is available here.. http://kingsmountain.com/doc/diff/Diff--draft-ietf-tokbind-protocol-04--to--draft-ietf-tokbind-protocol-05.html =JeffH From nobody Mon Mar 28 10:31:32 2016 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 1413812DBEC for <unbearable@ietfa.amsl.com>; Mon, 28 Mar 2016 10:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 f0mnxZcEmZyv for <unbearable@ietfa.amsl.com>; Mon, 28 Mar 2016 10:31:26 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0122.outbound.protection.outlook.com [207.46.100.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77BCC12DADA for <unbearable@ietf.org>; Mon, 28 Mar 2016 10:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wqUY5PULKoZSc2mwVLUcSH8dSPy+aEyGt3k8F9konbI=; b=dNvAlvNXDdHp5SgoQ3KTyq+BFxoiXTFg1i0l0xprqranSolUtDMV07V2sFJ+prePIWFECGA6Ig9qvESqOMK2x3u4xqvvYOpLDR9aYQ9dAUAo/xF4FwQ7d6SMVp1FEocfXbMidWKNnHJ6CCwBZQkbT6P1XlzV3jHXPP3+3jXFCto= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.447.15; Mon, 28 Mar 2016 17:31:16 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0434.023; Mon, 28 Mar 2016 17:31:15 +0000 From: Andrei Popov <Andrei.Popov@microsoft.com> To: Nick Harper <nharper@google.com>, =JeffH <Jeff.Hodges@kingsmountain.com> Thread-Topic: [Unbearable] Referred token binding IDs Thread-Index: AQHRhwsHFxaL/1+IUEybAurEP9d0+Z9rEoOAgAQLprA= Date: Mon, 28 Mar 2016 17:31:15 +0000 Message-ID: <BLUPR03MB1396A8439FD3E9412FEF873E8C860@BLUPR03MB1396.namprd03.prod.outlook.com> References: <56F5FA41.4020705@KingsMountain.com> <CACdeXi+NoqixLVO1zCogPoKaZrbDDspV8mZ_W2DQG8RWBQSNtA@mail.gmail.com> In-Reply-To: <CACdeXi+NoqixLVO1zCogPoKaZrbDDspV8mZ_W2DQG8RWBQSNtA@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8::1d2] x-ms-office365-filtering-correlation-id: 4898e033-9e86-41a7-64a9-08d3572ec41b x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:DbjEeM0cHbw0Asdc3KsoUgsGR8s8BAIcbBlDVbRFIQiNmrdru5v9cQhoJ/X9bZyG/h6icYwbxatWy3UI/tp/fqdLxG9cqAiTVsnZWyNvaJhkAkauAVA0gMHW1zreJvhPRAFXei6IbV3tZZHm2j3SFw==; 24:MmlpU2kHt6wy7sytKgqhaGlq8hP+b2YVt7w4eCRRF7iN5Q97NDlkZes+QpSiq4+Z8hhjfqZ20xTnQAw5QS60jNTGXDx5N2ffbzXOyGPMDy8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; x-microsoft-antispam-prvs: <BLUPR03MB13955B10B30369937E54251D8C860@BLUPR03MB1395.namprd03.prod.outlook.com> x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 0895DF8FFD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(74316001)(106116001)(19617315012)(99286002)(16236675004)(86362001)(19625215002)(561944003)(33656002)(76576001)(87936001)(19609705001)(86612001)(5005710100001)(19580395003)(19580405001)(10400500002)(5004730100002)(8990500004)(50986999)(54356999)(189998001)(10090500001)(76176999)(5001770100001)(19300405004)(81166005)(5002640100001)(15975445007)(2950100001)(2900100001)(586003)(92566002)(3280700002)(122556002)(790700001)(6116002)(102836003)(1096002)(1220700001)(2906002)(5008740100001)(77096005)(3660700001)(5003600100002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1396A8439FD3E9412FEF873E8C860BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2016 17:31:15.6791 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/sqSG32-px0eVzFY6LpHjvPiECmw> Cc: IETF Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 28 Mar 2016 17:31:30 -0000 --_000_BLUPR03MB1396A8439FD3E9412FEF873E8C860BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBJ4oCZbSBzaWRpbmcgd2l0aCBEaXJrIG9uIHRoaXM6IGlmIHRoZSBSUCByZWRpcmVj dHMgdG8gSURQMSwgd2hpY2ggcmVkaXJlY3RzIHRvIElEUDIsIHRoZW4gSURQMiBnZW5lcmF0ZXMg YSB0b2tlbiBmb3IgSURQMSB0byBjb25zdW1lLCBhbmQgZmluYWxseSBJRFAxIG1heSBnZW5lcmF0 ZSBhIHRva2VuIGZvciB0aGUgUlAgdG8gY29uc3VtZS4gVGhpcyB3b3JrcyB3aXRoIHRoZSBjbGll bnQgcHJvdmluZyBwb3NzZXNzaW9uIG9mIHR3byBUQiBrZXlzIGF0IGVhY2ggc3RlcCBvZiB0aGUg cmVkaXJlY3QuDQoNCklmIHdlIHdhbnRlZCB0byBzaG9ydC1jaXJjdWl0IHRoZSByZXR1cm4gcGF0 aCwgc28gdGhhdCBJRFAyIGNhbiByZWRpcmVjdCBiYWNrIHRvIHRoZSBSUCwgdGhlbiBpbmRlZWQg d2XigJlkIG5lZWQgdG8gY29udmV5IFRCSURfUlAgdG8gSURQMiwgYnV0IHNvIGZhciBpbiBvdXIg bGltaXRlZCBkZXBsb3ltZW50IGV4cGVyaWVuY2UgaGVyZSBhdCBNUyB3ZSBoYXZlIG5vdCBmb3Vu ZCB0aGUgbmVlZCB0byBkbyB0aGlzLiBJZiBzb21lb25lIGhhcyByZWRpcmVjdCBzY2VuYXJpb3Mg bGlrZSB0aGlzLCBwbGVhc2Ugc3BlYWsgdXAuDQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206 IFVuYmVhcmFibGUgW21haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBOaWNrIEhhcnBlcg0KU2VudDogRnJpZGF5LCBNYXJjaCAyNSwgMjAxNiA4OjM0IFBNDQpU bzogPUplZmZIIDxKZWZmLkhvZGdlc0BraW5nc21vdW50YWluLmNvbT4NCkNjOiBJRVRGIFRva2Jp bmQgV0cgPHVuYmVhcmFibGVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFJl ZmVycmVkIHRva2VuIGJpbmRpbmcgSURzDQoNCklmIHlvdSB3YW50IFRQNCB0byBnZW5lcmF0ZSBh IHRva2VuIGJvdW5kIHRvIFRCSUQxLCB0aGVuIFRQNCBuZWVkcyB0byB2ZXJpZnkgdGhhdCBUQklE NCBhbmQgVEJJRDEgYXJlIGJvdGggb3duZWQgYnkgdGhlIHNhbWUgY2xpZW50LiBJTU8sIHRoZSBl YXNpZXN0IHdheSB0byBkbyB0aGlzIGlzIHRvIGhhdmUgYm90aCBUQklEcyBpbiB0aGUgc2FtZSBU b2tlbkJpbmRpbmdNZXNzYWdlLiBJJ20gY3VyaW91cyBpZiB0aGlzIHNjZW5hcmlvICh3aXRoIFRD MSwgVEMyLCBUUDMsIGFuZCBUUDQpIGlzIGh5cG90aGV0aWNhbCwgb3IgaWYgdGhlcmUgYXJlIHJl YWwtd29ybGQgc2V0dXBzIHRoYXQgd29yayBsaWtlIHRoaXMgd2hlcmUgVEMxIGNhbid0IHJlZGly ZWN0IGRpcmVjdGx5IHRvIFRQNCwgb3IgeW91IGNhbid0IGhhdmUgVFA0IGlzc3VlIGEgdG9rZW4g Zm9yIFRQMywgd2hpY2ggdGhlbiBpc3N1ZXMgYSB0b2tlbiBmb3IgVEMyLCB3aGljaCBpc3N1ZXMg YSB0b2tlbiBmb3IgVEMxIChhcyBEaXJrIHN1Z2dlc3RzKS4NCg0KSSBjYW4gdGhpbmsgb2YgYSBm ZWRlcmF0ZWQgc2NlbmFyaW8gdGhhdCBjdXJyZW50bHkgZXhpc3RzIHdoZXJlIHRoZXJlIGFyZSBt dWx0aXBsZSB0b2tlbiBjb25zdW1lcnMgYW5kIHByb2R1Y2VycywgYnV0IGl0IHdvcmtzIHdpdGgg YSBzaW5nbGUgcmVmZXJyZWQgdG9rZW4gYmluZGluZyBmcm9tIEluY2x1ZGUtUmVmZXJlci1Ub2tl bi1CaW5kaW5nLUlELg0KMSkgU29tZSBhcHAgQSB3aXNoZXMgdG8gbGV0IHVzZXJzIGxvZyBpbiB3 aXRoIHRoZWlyIGdvb2dsZSBhY2NvdW50LiBXaGVuIHRoZSB1c2VyIGNsaWNrcyBBJ3MgbG9naW4g YnV0dG9uLCB0aGV5IGdldCByZWRpcmVjdGVkIHRvIGdvb2dsZSdzIGxvZ2luIHBhZ2UgRyAod2l0 aCBJbmNsdWRlLVJlZmVyZXItVG9rZW4tQmluZGluZy1JRCkuDQoyKSBUaGUgdXNlciB3aXNoZXMg dG8gbG9nIGluIHRvIGdvb2dsZSB3aXRoIHRoZWlyIHVuaXZlcnNpdHkncyBnbWFpbCBhY2NvdW50 LiBUaGV5IHN0YXJ0IHdvcmtpbmcgdGhyb3VnaCB0aGUgbG9naW4gZmxvdyBmb3IgdGhlaXIgdXNl cm5hbWVAdW5pdmVyc2l0eS5lZHU8bWFpbHRvOnVzZXJuYW1lQHVuaXZlcnNpdHkuZWR1PiBhY2Nv dW50LCBhbmQgRyByZWRpcmVjdHMgdGhlbSB0byB0aGUgdW5pdmVyc2l0eSdzIElkUCB0byBsb2cg aW4uDQozKSBUaGUgdXNlciBsb2dzIGluIHRvIHRoZSB1bml2ZXJzaXR5J3MgSWRQLCB3aGljaCBn ZW5lcmF0ZXMgYSBTQU1MIHRva2VuIGJvdW5kIHRvIFRCSURfRy4gVGhlIHVuaXZlcnNpdHkncyBJ ZFAgcGFzc2VzIHRoaXMgU0FNTCB0b2tlbiBiYWNrIHRvIGdvb2dsZS4NCjQpIEdvb2dsZSB2ZXJp ZmllcyB0aGlzIHRva2VuLCBhbmQgbm93IGdlbmVyYXRlcyBhbiBPcGVuSUQgQ29ubmVjdCB0b2tl biB0byBwYXNzIGJhY2sgdG8gQSwgYW5kIGJpbmRzIGl0IHRvIHRoZSByZWZlcnJlZCBUQklEX0Eg dGhhdCB3YXMgcGFzc2VkIHRvIEcgaW4gdGhlIGluaXRpYWwgcmVkaXJlY3QgQS0+Ry4NCjUpIEEg bm93IGhhcyBhIHRva2VuIGZyb20gRyB0aGF0IGlzIGJvdW5kIHRvIFRCSURfQS4NCg0KSWYgdGhl cmUgYXJlIHNpdHVhdGlvbnMgd2hlcmUgdGhlcmUgaXMgYSBuZWVkIGZvciBUUDQgdG8gZ2VuZXJh dGUgYSB0b2tlbiBmb3IgVEMxLCB0aGVuIEkgdGhpbmsgY2hhbmdlcyB3b3VsZCBiZSBuZWVkZWQg dG8gVEJIVFRQUyB0byBzdXBwb3J0IHRoYXQuIE9uZSBzdWNoIGNoYW5nZSBjb3VsZCBiZSBmb3Ig SW5jbHVkZS1SZWZlcmVyLVRva2VuLUJpbmRpbmctSUQgdG8gcGFzcyBhbG9uZyBhbGwgVEJJRHMg ZnJvbSB0aGUgcHJldmlvdXMgcmVxdWVzdCBpbnN0ZWFkIG9mIGp1c3Qgb25lLiBUaGlzIHdvdWxk IG9ubHkgd29yayBpZiB0aGVyZSB3YXMgYSBzaW5nbGUgY2hhaW4gb2YgcmVkaXJlY3RzIGZyb20g VEMxIGFsbCB0aGUgd2F5IHRvIFRQNC4gT25jZSBUUDQgcmVjZWl2ZXMgdGhpcyBUb2tlbkJpbmRp bmdNZXNzYWdlIHdpdGggVEJJRDEsIFRCSUQyLCBUQklEMywgYW5kIFRCSUQ0IChhbmQgdmVyaWZp ZXMgYWxsIG9mIHRoZW0pLCBpdCBjb3VsZCBpc3N1ZSBhIHRva2VuIHRoYXQgaXMgYm91bmQgdG8g YWxsIG9mIHRoZW0sIGFuZCB0aGVuIFRDMSBpdGVyYXRlcyB0aHJvdWdoIHRoZSBib3VuZCBUQklE cyB0byBmaW5kIG9uZSB0aGF0IGl0IHJlY29nbml6ZXMuDQoNCk9uIEZyaSwgTWFyIDI1LCAyMDE2 IGF0IDc6NTYgUE0sID1KZWZmSCA8SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb208bWFpbHRv OkplZmYuSG9kZ2VzQGtpbmdzbW91bnRhaW4uY29tPj4gd3JvdGU6DQpPbiBNb25kYXksIE1hcmNo IDIxLCAyMDE2IGF0IDE6NDAgUE0sIE5pY2sgd3JvdGU6DQo+IE15IHVuZGVyc3RhbmRpbmcgb2Yg dGhlIHByb2JsZW0gaW4gZmlndXJlIDEgaXMgdGhhdA0KPg0KPiAxKSBpbiB0aGUgcmVkaXJlY3Qg ZnJvbSBUQzIgdG8gVFAzIChzdGVwIDJiKSwgdGhlIHJlZmVycmVkIFRCSUQNCj4gaXMgVEJJRDIs IHdoaWxlIHRoZSByZWRpcmVjdCB1cmkgaXMgdG8gVEMxLCBhbmQuLg0KDQp5ZXMsIHRoaXMgaXMg YW4gaXNzdWUgLS0gaW4gdGhpcyBjYXNlIFRCSUQxIG5lZWRzIHRvIGJlIChzb21laG93KSByZWxh eWVkLg0KDQoNCj4gMikgd2hlbiBUUDMgcmVkaXJlY3RzIHRvIFRQNCwgc29tZWhvdyBUQklEMiBu ZWVkcyB0byBiZSByZWxheWVkLg0KDQphY3R1YWxseSwgVEJJRDEgbmVlZHMgdG8gYmUgcmVsYXll ZCAoc29tZWhvdykgcmF0aGVyIHRoZW4gVEJJRDIgYmVjYXVzZSB0aGF0IGlzIHdoYXQgaXMgYmVp bmcgY2FsbGVkIGZvciBpbiB0aGUgImZlZCBsYXllcidzIiBhdXRobiByZXF1ZXN0J3MgcmVkaXJl Y3RfdXJpLg0KDQoNCj4gT25lIHdheSB0byBzb2x2ZSBwcm9ibGVtIDIgaXMgdG8gdHJlYXQgdGhl IFRQMy0+VFA0IHJlZGlyZWN0IGxpa2UgdGhlDQo+ICJpZGVudGl0eS1hcy1hLXNlcnZpY2UiIHNj ZW5hcmlvIHRoYXQgRGlyayBtZW50aW9uZWQuIEluc3RlYWQgb2YgVFA0DQo+IHJlZGlyZWN0aW5n IHRvIFRDMSwgaXQgY2FuIGNyZWF0ZSBhIHRva2VuIHRvIGJlIGNvbnN1bWVkIGJ5IFRQMywgYW5k DQo+IHJlZGlyZWN0IHRvIFRQMywgd2hpY2ggd2lsbCB0aGVuIGNyZWF0ZSBhIHRva2VuIHRvIHNl bmQgYmFjayB0byBUQzEuDQoNCklNViBpdCBpcyBpbmFwcHJvcHJpYXRlIGZvciB1cyB0byBzcGVj aWZ5IGEgc29sdXRpb24gbGlrZSB0aGF0IChpLmUuLCBjaGFpbmluZyBJRFBzKSBpbiAtdG9rYmlu ZC1odHRwcyBha2EgSFRUUFNUQiAtLSBzdWNoIGEgY29uZmlndXJhdGlvbiBpcyB1cCB0byBob3cg dGhlIGZlZCBsYXllciBpcyBjb25maWcnZCBhbmQgZGVwbG95ZWQuIEl0IG1heSBvciBtYXkgbm90 IGJlIGFwcHJvcHJpYXRlIGZvciBhIGdpdmVuIGZlZGVyYXRpb24uDQoNCg0KPiBGb3IgcHJvYmxl bSAxLCBJIGFtIGdvaW5nIHRvIGFzc3VtZSB0aGF0IFRDMSBhbmQgVEMyIGFyZSBjb29wZXJhdGlu Zy4NCj4gVGhlIGVhc2llc3Qgd2F5IHRvIGZpeCB0aGlzIGlzIHRvIGhhdmUgVEMyIHRyYW5zbWl0 IHRvIFRDMQ0KPiBvdXQtb2YtYmFuZCB3aGF0IFRCSUQyIGlzIHNvIHRoYXQgVEMxIGNhbiB2ZXJp ZnkgaXQuDQoNCmRpZCB5b3UgbWVhbiB0byBzYXk6IGhhdmUgVEMxIHRyYW5zbWl0IG91dC1vZi1i YW5kIFRCSUQxIHRvIFRDMiA/IC4uYmVjYXVzZSB0aGUgaXNzdWUgaGVyZSBpbiBuZWVkaW5nIHRv IHJlbGF5IFRCSUQxIHNvbWVob3csIHVubGVzcyBJJ20gbWlzc2luZyBzb21ldGhpbmcuDQoNCg0K PiBIZXJlJ3MgYW5vdGhlciBzb2x1dGlvbiAoZm9yIGJvdGggcHJvYmxlbXMpIHRoYXQgSSB0aGlu ayBjb3VsZCB3b3JrLi4uDQo+IC4uPGVsaWRlZD4uLg0KDQpUaGUgYWJvdmUgb3RoZXIgc29sdXRp b24gZWxpZGVkIGR1ZSB0byB0aGUgYmVsb3cgc3Vic2VxdWVudCBhbmFseXNpcy4NCg0KDQpPbiBU aHVyc2RheSwgTWFyY2ggMjQsIDIwMTYgYXQgMzoxNSBQTSwgTmljayB3cm90ZToNCj4gVEw7RFI6 IFVzZSBJbmNsdWRlLVJlZmVyZXItVG9rZW4tQmluZGluZy1JRC4gQmluZGluZyBhIHRva2VuIHRv IGFuDQo+IElEIHRoYXQgaGFzbid0IGJlZW4gdmVyaWZpZWQgY2FuIHJlc3VsdCBpbiBhIE1pdE0g Z2V0dGluZyBjb250cm9sIG9mDQo+IGEgYm91bmQgdG9rZW4uDQo+DQo+IERpcmsgYW5kIEkgY2hh dHRlZCBhYm91dCBteS9EYXZpZCdzIHByb3Bvc2FsLCBhbmQgaG93IGl0IGFwcGxpZXMgdG8NCj4g SmVmZidzIHNjZW5hcmlvLiBJbiBzdGVwcyAzYSBhbmQgM2IgZnJvbSBmaWd1cmUgMSwgVEJJRDMg bmVlZHMgdG8gYmUNCj4gcmVmZXJyZWQgdG8gVFA0IChpbiBhZGRpdGlvbiB0byBjb252ZXlpbmcg VEJJRDIpLg0KDQphY3R1YWxseSwgY29udmV5aW5nIFRCSUQzIHRvIFRQNCBpcyBvcHRpb25hbCBJ TVYgYW5kIG9uZSB3b3VsZCBvbmx5IG5lZWQgdG8gZG8gaXQgaWYgVFA0IGlzIGFsc28gbWludGlu ZyBvdGhlciBib3VuZCBzZWMgdG9rZW5zIGVnIGNvb2tpZXMgd2l0aCBUQklEMyBpbiAnZW0uDQoN CkFsc28sIGl0IGlzIFRCSUQxIHRoYXQgYWN0dWFsbHkgbmVlZHMgdG8gYmUgcmVmZXJyZWQsIGlu IG9yZGVyIHRvIHByb3Blcmx5IGlzc3VlIHRoZSBJRCBUb2tlbi4gVGhlIHJlbWFyayBpbiAodGhl IG9sZCkgZmlndXJlIDEgd3J0ICJzb21laG93IGNvbnZleXMgVEJJRDIgPyIgaXMgc2ltcGx5IGEg cmVmZXJlbmNlIHRvIERpcmsncyBjb21tZW50cyB3aGVyZSBoZSBzdWdnZXN0ZWQgdGhhdCB0aGF0 IGlzIHdoYXQgd2UnZCBkbyBoZXJlLiBTZWUgdXBkYXRlZCBmaWd1cmUgMWEgYmVsb3cuDQoNCg0K PiBUaGUgcHJvYmxlbSB3aXRoIHRoZSBjdXJyZW50IHNldHVwIG9mIGZpZ3VyZSAxIGlzIHdoZW4g dGhlcmUgaXMgYW4NCj4gYXR0YWNrZXIgTWl0TWluZyBjb25uZWN0aW9ucyB0byBUUDMuIEluIHN0 ZXAgMmIsIHRoZQ0KPiBUb2tlbkJpbmRpbmdNZXNzYWdlIGNvbnRhaW5zIFRCSUQzJyBhbmQgVEJJ RDInLCBib3RoIHVuZGVyIGF0dGFja2VyDQo+IGNvbnRyb2wuIFRoZW4sIGluIHN0ZXAgM2IsIHdo ZW4gdGhlIGNsaWVudCBmb2xsb3dzIHRoZSByZWRpcmVjdCBmcm9tDQo+ICh0aGUgTWl0TSdkKSBU UDMgdG8gVFA0LCBpdCBpbmNsdWRlcyBUQklENCwgYnV0IG5vdCBUQklEMywgaW4gdGhlDQo+IFRv a2VuQmluZGluZ01lc3NhZ2UuIFdoZW4gVFA0IGF1dGhlbnRpY2F0ZXMgdGhlIHVzZXIsIFRCSUQ0 IGlzDQo+IGNvcnJlY3QsIGFuZCB0aGVuIFRQNCBjcmVhdGVzIGEgdG9rZW4gZm9yIHRoZSB1c2Vy J3MgaWRlbnRpdHkgd2l0aCBhbg0KPiBhdHRhY2tlci1jb250cm9sbGVkIFRCSUQuIEV2ZW4gaWYg VFAzIGFuZCBUUDQgYXJlIHNvbWVob3cNCj4gY29vcGVyYXRpbmcsIGFuZCB0aGUgcHJvdmlkZWQg YW5kIHJlZmVycmVkIHRva2VuIGJpbmRpbmdzIGZyb20gdGhlDQo+IHJlcXVlc3QgaW4gc3RlcCAy YiBhcmUgcGFzc2VkIGZyb20gVFAzIHRvIFRQNCBvdXQtb2YtYmFuZCwgdGhlIHRva2VuDQo+IHN0 aWxsIGhhcyBhbiBhdHRhY2tlciBjb250cm9sbGVkIFRCSUQsIHNpbmNlIHRoZSB0b2tlbiBiaW5k aW5ncyBzZW50DQo+IGluIHN0ZXAgMmIgYXJlIGF0dGFja2VyIGNvbnRyb2xsZWQuDQoNCmFncmVl ZCB3aXRoIHRoZSBhYm92ZSBleGNlcHQgdGhhdCBpdCBpcyBUQklEMSB0aGF0IHJlYWxseSBuZWVk cyB0byBiZSBjb252ZXllZCB0byB1bHRpbWF0ZWx5IHRvIFRQNCBpbiBvcmRlciBmb3IgdGhlIGxh dHRlciB0byBjb3JyZWN0bHkgaXNzdWUgdGhlIE9JREMgSUQgVG9rZW4sIG9yIFNBTUwgYXNzZXJ0 aW9uIG9yIHdoYXRldmVyLCBhdCB0aGUgZmVkIGxheWVyLg0KDQoNCk9uIEZyaWRheSwgTWFyY2gg MjUsIDIwMTYgYXQgMTA6NDkgQU0sIERpcmsgd3JvdGU6DQo+IEFncmVlZC4gQm90dG9tIGxpbmUg aXMgdGhhdCBJIHN0aWxsIGJlbGlldmUgdGhhdCBhIHNpbmdsZSByZWZlcnJlZA0KPiB0b2tlbiBi aW5kaW5nIChldmVuIG9uIHJlcGVhdGVkIHJlZGlyZWN0cykgZ2l2ZXMgdXMgYWxsIHdlIG5lZWQu DQoNCkkgYWdyZWUgaXQgaXMgImFsbCB3ZSBuZWVkIiBfaWZfIHdlIGFyZSBzYXlpbmcgdGhhdCBp dCBpcyBvdXQtb2Ytc2NvcGUgZm9yIEhUVFBTVEIgdG8gc3BlY2lmeSBob3csIGluIGEgbXVsdGkt cmVkaXJlY3Qgc2NlbmFyaW8gc3VjaCBhcyBmaWcgMWEsIGZvciB0aGUgY29ycmVjdCByZWZlcnJl ZCBUQklEIHRvIGJlIGNvbnZleWVkIHRvIHRoZSBUQydzIHBvaW50LW9mLWhhbmRvZmYtdG8tVFAs IGFuZCBzaW1pbGFybHkgb3V0LW9mLXNjb3BlIGZvciBhbnkgcmVkaXJlY3RzIGFtb25nIFRQIGVu dGl0aWVzIHBlciBIVFRQU1RCIHNwZWMgKGkuZS4sIHRoZXkgZmlnZ2VyIGl0IG91dCB0aGVtc2Vs dmVzKS4NCg0KSS5lLiwgd2UgX2Nhbl8gc2F5IHRoZSBhYm92ZSBJIHRoaW5rIC0tIHRobyBzb21l IG1heSBwZXJjZWl2ZSBpdCBhcyBzdWItb3B0aW1hbCB0byBqdXN0IGxlYXZlIGl0IHVuc3BlY2lm aWVkIC0tIGJ1dCBpdCBtYXkgbm90IGJlIHRoYXQgYmlnIGEgZGVhbCwgSSBkb24ndCBrbm93LiAo ZmVkZXJhdGlvbiBmb2xrIHBsZWFzZSBzcGVhayB1cCBoZXJlICEpDQoNCldlIGNvdWxkIGRldmlz ZSBzb21lIG1lYW5zIG9mIHNpZ25hbGluZyBpbiB0aGUgSFRUUFNUQiBoZWFkZXIgZmllbGQgbGF5 ZXIgZnJvbSBUQy10by1UQyBhbmQgVFAtdG8tVFAgd2hhdCB0aGUgY29ycmVjdCBUQklEIHRvIHVz ZSBpcyAoaG0sIGl0IHdpbGwgcmVxdWlyZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBmcm9tIHRoZSBw b3N0dWxhdGVkIE1JVE1zKSBhbmQgdGhhdCBtaWdodCBzYXZlIHRoZSBmZWQgbGF5ZXIgZm9sa3Mg ZnJvbSBpbnZlbnRpbmcgZGlzam9pbnQgd2F5cyB0byBkbyBpdCAoYW5kIGhtLCBob3dldmVyIHRo ZXkgZG8gaXQgd2lsbCBuZWVkIGludGVncml0eSBwcm90ZWN0aW9uKS4uLg0KDQpCdXQgd2UgbWF5 IG5vdCB3YW50IHRvIGdvIHRoZXJlLCBJJ20gbm90IHN1cmUgbXlzZWxmLg0KDQpIVEgsDQoNCj1K ZWZmSA0KLS0tLS0tDQoNCg0KRmlndXJlIDFhOiAgICggTm90ZTogaWYgdGhpcyBmaWcgZ2V0cyBp bnNlcnRlZCBpbnRvIHRoZSBzcGVjIGl0IHdpbGwNCiAgICAgICAgICAgICAgICAgICAgIGxpa2Vs eSBfbm90XyBiZSBsYWJlbGVkICJmaWcgMSIgdGhlcmUgKQ0KV2hhdDogQW5hbHlzaXMgb2YgcmVk aXJlY3QgaG9wcyBhdCBSUCBha2EgVEMgYW5kIGF0IElEUCBha2EgVFANCg0KTGVnZW5kOiAoc2Vl IGZpZ3VyZSAxIGluIGEgcHJpb3IgZW1haWwgbXNnKQ0KDQoNCkNsaWVudCwgICAgICAgICAgICAg ICAgICAgICAgVG9rZW4gQ29uc3VtZXIsICAgICAgICAgVG9rZW4gUHJvdmlkZXIsDQpha2E6ICAg ICAgICAgICAgICAgICAgICAgICAgIGFrYTogICAgICAgICAgICAgICAgICAgIGFrYToNClVzZXIg QWdlbnQgICAgICAgICAgICAgICAgICAgT3BlbklEIENsaWVudCwgICAgICAgICAgT3BlbklEIFBy b3ZpZGVyLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPSURDIFJlbHlpbmcgUGFydHks ICAgICBPSURDIFByb3ZpZGVyLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTQU1MIFJl bHlpbmcgUGFydHkgICAgICBTQU1MIElkZW50aXR5IFByb3ZpZGVyDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFsgc2VydmVycyAiMSIsICIyIiBdICAgIFsgc2VydmVycyAiMyIsICI0IiBd DQorLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0rICArLS0tLS0rICAgICAr LS0tLS0rICAgKy0tLS0tKw0KfCBDbGllbnQgfCAgICAgICAgICAgICAgICAgICAgICAgfCBUQzEg fCAgfCBUQzIgfCAgICAgfCBUUDMgfCAgIHwgVFA0IHwNCistLS0tLS0tLSsgICAgICAgICAgICAg ICAgICAgICAgICstLS0tLSsgICstLS0tLSsgICAgICstLS0tLSsgICArLS0tLS0rDQogICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICB8ICAgICAg ICAgfA0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgfCAgICAg ICAgICAgfCAgICAgICAgIHwNCiAgICB8IDAuIENsaWVudCBpbnRlcmFjdHMgdy9UQzEgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICB8DQogICAgfCBvdmVyIEhUVFBTLCBlc3RhYmxp c2hlcyBLczEgJiBLcDEsIFRCSUQxICAgICAgICAgICB8ICAgICAgICAgfA0KICAgIHwgRVRCTVNH W1t7RUtNMX1LczEsVEJJRDEscHJvdmlkZWRfdG9rZW5fYmluZGluZ11dICAgfCAgICAgICAgIHwN CiAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgICAgICAgIHwgICAgICAgICAg IHwgICAgICAgICB8DQogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICB8ICAgICAgICAgICB8ICAgICAgICAgfA0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgIHwNCiAgICB8IDFhLiByZWRpcmVj dCB0byBUQzIgZm9yIFRDLXNwZWNpZmljIHJlYXNvbnMgICAgICAgIHwgICAgICAgICB8DQogICAg fCBhbnkgc2VjdXJpdHktcmVsZXZhbnQgY29va2llcyBzaG91bGQgY29udGFpbiBUQklEMSB8ICAg ICAgICAgfA0KICArPC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gfCAgICAgICAgfCAg ICAgICAgICAgfCAgICAgICAgIHwNCiAgLiB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICB8DQogICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAgICAgICB8ICAgICAgICAgfA0KICAgIHwgMWIu IGVzdGFibGlzaGVzIEtzMiAmIEtwMiwgVEJJRDIgICAgICAgfCAgICAgICAgICAgfCAgICAgICAg IHwNCiAgICB8IEVUQk1TR1tbe0VLTTJ9S3MyLFRCSUQyLHByb3ZpZGVkX3Rva2VuX2JpbmRpbmdd XSAgIHwgICAgICAgICB8DQogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICB8ICAgICAgICAgICB8ICAgICAgICAgfA0KICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgIHwNCiAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICB8DQog ICAgfCAyYS4gT0lEQyBJRCBUb2tlbiByZXF1ZXN0LCAgICB8ICAgICAgICB8ICAgICAgICAgICB8 ICAgICAgICAgfA0KICAgIHwgYWthICJBdXRoZW50aWNhdGlvbiBSZXF1ZXN0IiB3LyByZWRpcmVj dF91cmk9VEMxOyAgPC0tIG5vdGUgd2VsbA0KICAgIHwgY29udmV5ZWQgdy8gSFRUUCByZXNwb25z ZSBoZWFkZXIgZmllbGQgb2Y6ICAgICAgICAgfCAgICAgICAgIHwNCiAgICB8ICAgSW5jbHVkZS1S ZWZlcmVyLVRva2VuLUJpbmRpbmctSUQ6dHJ1ZSAgICAgICAgICAgIHwgICAgICAgICB8DQogICAg fCBhbnkgc2VjdXJpdHktcmVsZXZhbnQgY29va2llcyBzaG91bGQgY29udGFpbiBUQklEMiB8ICAg ICAgICAgfA0KICArPC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtfCAg ICAgICAgICAgfCAgICAgICAgIHwNCiAgLiB8IChyZWRpcmVjdCB0byBUUCB2aWEgMzAxLCAzMDIs IHwgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICB8DQogIC4gfCAgMzAzLCAzMDcsIG9yIDMw OCkgICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgfA0KICAuIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAg IHwNCiAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPnwgICAgICAgICB8DQogICAgfCAyYi4gY2xpZW50IG9wZW5zIEhUVFBTIHcvIFRQMywgICAg ICAgICB8ICAgICAgICAgICB8ICAgICAgICAgfA0KICAgIHwgZXN0YWJsaXNoZXMgS3MzLCBLcDMs IFRCSUQzOyAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgIHwNCiAgICB8IHNlbmRzIEdF VCBvciBQT1NUIHdpdGggICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICB8DQog ICAgfCBJRCBUb2tlbiByZXF1ZXN0IHcvIHJlZGlyZWN0X3VyaT1UQzEsICB8ICAgICAgICAgICB8 ICAgICAgICAgfA0KICAgIHwgRVRCTVNHW1t7RUtNM31LczMsVEJJRDMscHJvdmlkZWRfdG9rZW5f YmluZGluZ10sICAgICAgICAgICAgIHwNCiAgICB8ICAgICAgIFt7RUtNM31LczIsVEJJRDIscmVm ZXJyZWRfdG9rZW5fYmluZGluZ11dIDwtLSBidXQgSUQgVG9rIHJlcXVlc3QNCiAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgIDwtLSBpcyBmb3IgVEMx DQogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAg ICB8ICAgICAgICAgfA0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgfCAgICAgICAgICAgfCAgICAgICAgIHwNCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICB8DQogICAgfCAzYS4gcmVkaXJl Y3QgdG8gVFA0IGZvciBUUC1zcGVjaWZpYyByZWFzb25zICAgICAgICB8ICAgICAgICAgfA0KICAg IHwgYW55IHNlY3VyaXR5LXJlbGV2YW50IGNvb2tpZXMgc2hvdWxkIGNvbnRhaW4gVEJJRDMgfCAg ICAgICAgIHwNCiAgKzwtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAt IC0gLSAtIC0gLXwgICAgICAgICB8DQogIC4gfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwNCiAgICB8IDNi LiBjbGllbnQgb3BlbnMgSFRUUFMgdy8gVFA0LCAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAg ICB8DQogICAgfCBlc3RhYmxpc2hlcyBLczQgJiBLcDQsIFRCSUQ0ICAgICAgICAgICB8ICAgICAg ICAgICB8ICAgICAgICAgfA0KICAgIHwgRVRCTVNHW1t7RUtNNH1LczQsVEJJRDQscHJvdmlkZWRf dG9rZW5fYmluZGluZ11dICAgfCAgICAgICAgIHwNCiAgICB8ICAgICAgICAgKioqIGFzIHdlbGwg YXMgdGhlIElEIFRva2VuIHJlcXVlc3Qgdy8gcmVkaXJlY3RfdXJpPVRDMTsNCiAgICB8ICAgICAg ICAgKioqIGFsc28sIHNvbWVob3cgY29udmV5cyBUQklEMSB0byBUUDQgPC0tIE5lZWQgdGhpcyB0 bw0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICA8 LS0gaXNzdWUgYm91bmQNCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgIHwgICAgICAgPC0tIElEIFRva2VuDQogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgfA0KICAgIHwgNC4gdXNlciBhdXRo ZW50aWNhdGlvbiAoaWYgYXBwbGljYWJsZSwgICAgICAgICAgICAgfCAgICAgICAgIHwNCiAgICB8 ICAgIG1ldGhvZHMgdmFyeSwgcGFydGljdWxhcnMgYXJlIG91dCBvZiBzY29wZSkgICAgIHwgICAg ICAgICB8DQogICAgfDw9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0+fA0KICAgIHwgKFRQIGdlbmVyYXRlcyBJRCBUb2tlbiBmb3IgVEMx IGNvbnRhaW5pbmcgVEJJRDEgICA8LS0gTmVlZCB0byBnZXQNCiAgICB8ICBhbHNvIHNldCBjb29r aWUocykgY29udGFpbmluZyBUQklENCBhbmQvb3IgVEJJRDMgPC0tIFRCSUQxIGhlcmUNCiAgICB8 ICBkZXRhaWxzIHZhcnkpICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgICAgIHwgICAg ICAgICB8DQogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAg ICAgICAgICB8ICAgICAgICAgfA0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgIHwNCiAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICB8DQogICAgfCA1YS4g SUQgVG9rZW4gaXNzdWVkIGZvciBUQzEsIGNvbnRhaW5pbmcgVEJJRDEsIDwtLSBob3cgZG8gdGhp cyBpZg0KICAgIHwgICAgY29udmV5ZWQgdmlhIE9JREMgIkF1dGhlbnRpY2F0aW9uIFJlc3BvbnNl IiA8LS0gZG9uJ3QgaGF2ZSBUQklEMT8NCiAgKzwtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0g LSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC18DQogIC4gfCAgIChyZWRpcmVjdCB0 byBUQzEpICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgfA0KICAuIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAgfCAgICAg ICAgIHwNCiAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgICAgICAgIHwgICAg ICAgICAgIHwgICAgICAgICB8DQogICAgfCA1Yi4gSFRUUFMgR0VUIG9yIFBPU1Qgd2l0aCAgICB8 ICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgfA0KICAgIHwgRVRCTVNHW1t7RUtNMX1LczEs VEJJRDEscHJvdmlkZWRfdG9rZW5fYmluZGluZ11dICAgfCAgICAgICAgIHwNCiAgICB8IGNvbnZl eWluZyBBdXRobiBSZXBvbnNlIGNvbnRhaW5pbmcgSUQgVG9rZW4gdy9UQklEMSwgICAgICAgICB8 DQogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzc3VlZCBmb3IgVEMx ICAgICAgICAgICAgfA0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgfCAgICAgICAgICAgfCAgICAgICAgIHwNCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICB8DQogICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgfA0KICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAgfCAg ICAgICAgIHwNCiAgICB8IDYuIHVzZXIgaXMgc2lnbmVkLW9uLCBhbnkgc2VjdXJpdHktcmVsZXZh bnQgY29va2llKHMpICAgICAgICB8DQogICAgfCB0aGF0IGFyZSBzZXQgU0hPVUxEIGNvbnRhaW4g VEJJRDEgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgfA0KICAgIHw8LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tfCAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgIHwNCiAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgICAgIHwgICAgICAg ICB8DQogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAgICAg ICAgICB8ICAgICAgICAgfA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0DQpVbmJlYXJhYmxlQGlldGYub3JnPG1h aWx0bzpVbmJlYXJhYmxlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby91bmJlYXJhYmxlPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3Rp bmZvJTJmdW5iZWFyYWJsZSZkYXRhPTAxJTdjMDElN2NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQu Y29tJTdjNTY5MjVjYTcyNjkxNDhiZmVkNTYwOGQzNTUyNzdmYWYlN2M3MmY5ODhiZjg2ZjE0MWFm OTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9NXJucmsycFhpT2ZkYWlLc1dpRXNLQXRLYUw2R252 S0RsUGNzS1VSMGJDQSUzZD4NCg0K --_000_BLUPR03MB1396A8439FD3E9412FEF873E8C860BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaW0NCgl7bXNvLXN0 eWxlLW5hbWU6aW07fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JIHRoaW5rIEnigJltIHNpZGluZyB3aXRoIERpcmsgb24gdGhpczogaWYgdGhlIFJQ IHJlZGlyZWN0cyB0byBJRFAxLCB3aGljaCByZWRpcmVjdHMgdG8gSURQMiwgdGhlbiBJRFAyIGdl bmVyYXRlcyBhIHRva2VuIGZvciBJRFAxIHRvIGNvbnN1bWUsIGFuZCBmaW5hbGx5IElEUDENCiBt YXkgZ2VuZXJhdGUgYSB0b2tlbiBmb3IgdGhlIFJQIHRvIGNvbnN1bWUuIFRoaXMgd29ya3Mgd2l0 aCB0aGUgY2xpZW50IHByb3ZpbmcgcG9zc2Vzc2lvbiBvZiB0d28gVEIga2V5cyBhdCBlYWNoIHN0 ZXAgb2YgdGhlIHJlZGlyZWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SWYgd2Ugd2FudGVkIHRvIHNob3J0LWNpcmN1aXQgdGhlIHJldHVybiBwYXRoLCBzbyB0 aGF0IElEUDIgY2FuIHJlZGlyZWN0IGJhY2sgdG8gdGhlIFJQLCB0aGVuIGluZGVlZCB3ZeKAmWQg bmVlZCB0byBjb252ZXkgVEJJRF9SUCB0byBJRFAyLCBidXQgc28gZmFyIGluIG91ciBsaW1pdGVk DQogZGVwbG95bWVudCBleHBlcmllbmNlIGhlcmUgYXQgTVMgd2UgaGF2ZSBub3QgZm91bmQgdGhl IG5lZWQgdG8gZG8gdGhpcy4gSWYgc29tZW9uZSBoYXMgcmVkaXJlY3Qgc2NlbmFyaW9zIGxpa2Ug dGhpcywgcGxlYXNlIHNwZWFrIHVwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+QW5kcmVpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IFVuYmVhcmFibGUgW21haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk5pY2sgSGFycGVyPGJyPg0KPGI+U2VudDo8 L2I+IEZyaWRheSwgTWFyY2ggMjUsIDIwMTYgODozNCBQTTxicj4NCjxiPlRvOjwvYj4gPUplZmZI ICZsdDtKZWZmLkhvZGdlc0BraW5nc21vdW50YWluLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IElF VEYgVG9rYmluZCBXRyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBSZWZlcnJlZCB0b2tlbiBiaW5kaW5nIElEczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSB3YW50IFRQNCB0byBnZW5lcmF0 ZSBhIHRva2VuIGJvdW5kIHRvIFRCSUQxLCB0aGVuIFRQNCBuZWVkcyB0byB2ZXJpZnkgdGhhdCBU QklENCBhbmQgVEJJRDEgYXJlIGJvdGggb3duZWQgYnkgdGhlIHNhbWUgY2xpZW50LiBJTU8sIHRo ZSBlYXNpZXN0IHdheSB0byBkbyB0aGlzIGlzIHRvIGhhdmUgYm90aCBUQklEcyBpbiB0aGUgc2Ft ZSBUb2tlbkJpbmRpbmdNZXNzYWdlLiBJJ20gY3VyaW91cyBpZiB0aGlzDQogc2NlbmFyaW8gKHdp dGggVEMxLCBUQzIsIFRQMywgYW5kIFRQNCkgaXMgaHlwb3RoZXRpY2FsLCBvciBpZiB0aGVyZSBh cmUgcmVhbC13b3JsZCBzZXR1cHMgdGhhdCB3b3JrIGxpa2UgdGhpcyB3aGVyZSBUQzEgY2FuJ3Qg cmVkaXJlY3QgZGlyZWN0bHkgdG8gVFA0LCBvciB5b3UgY2FuJ3QgaGF2ZSBUUDQgaXNzdWUgYSB0 b2tlbiBmb3IgVFAzLCB3aGljaCB0aGVuIGlzc3VlcyBhIHRva2VuIGZvciBUQzIsIHdoaWNoIGlz c3VlcyBhIHRva2VuIGZvcg0KIFRDMSAoYXMgRGlyayBzdWdnZXN0cykuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGNhbiB0aGluayBvZiBhIGZlZGVyYXRl ZCBzY2VuYXJpbyB0aGF0IGN1cnJlbnRseSBleGlzdHMgd2hlcmUgdGhlcmUgYXJlIG11bHRpcGxl IHRva2VuIGNvbnN1bWVycyBhbmQgcHJvZHVjZXJzLCBidXQgaXQgd29ya3Mgd2l0aCBhIHNpbmds ZSByZWZlcnJlZCB0b2tlbiBiaW5kaW5nIGZyb20gSW5jbHVkZS1SZWZlcmVyLVRva2VuLUJpbmRp bmctSUQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4xKSBTb21lIGFwcCBBIHdpc2hlcyB0byBsZXQgdXNlcnMgbG9nIGluIHdpdGggdGhlaXIgZ29v Z2xlIGFjY291bnQuIFdoZW4gdGhlIHVzZXIgY2xpY2tzIEEncyBsb2dpbiBidXR0b24sIHRoZXkg Z2V0IHJlZGlyZWN0ZWQgdG8gZ29vZ2xlJ3MgbG9naW4gcGFnZSBHICh3aXRoIEluY2x1ZGUtUmVm ZXJlci1Ub2tlbi1CaW5kaW5nLUlEKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjIpIFRoZSB1c2VyIHdpc2hlcyB0byBsb2cgaW4gdG8gZ29vZ2xl IHdpdGggdGhlaXIgdW5pdmVyc2l0eSdzIGdtYWlsIGFjY291bnQuIFRoZXkgc3RhcnQgd29ya2lu ZyB0aHJvdWdoIHRoZSBsb2dpbiBmbG93IGZvciB0aGVpcg0KPGEgaHJlZj0ibWFpbHRvOnVzZXJu YW1lQHVuaXZlcnNpdHkuZWR1Ij51c2VybmFtZUB1bml2ZXJzaXR5LmVkdTwvYT4gYWNjb3VudCwg YW5kIEcgcmVkaXJlY3RzIHRoZW0gdG8gdGhlIHVuaXZlcnNpdHkncyBJZFAgdG8gbG9nIGluLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MykgVGhl IHVzZXIgbG9ncyBpbiB0byB0aGUgdW5pdmVyc2l0eSdzIElkUCwgd2hpY2ggZ2VuZXJhdGVzIGEg U0FNTCB0b2tlbiBib3VuZCB0byBUQklEX0cuIFRoZSB1bml2ZXJzaXR5J3MgSWRQIHBhc3NlcyB0 aGlzIFNBTUwgdG9rZW4gYmFjayB0byBnb29nbGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40KSBHb29nbGUgdmVyaWZpZXMgdGhpcyB0b2tlbiwg YW5kIG5vdyBnZW5lcmF0ZXMgYW4gT3BlbklEIENvbm5lY3QgdG9rZW4gdG8gcGFzcyBiYWNrIHRv IEEsIGFuZCBiaW5kcyBpdCB0byB0aGUgcmVmZXJyZWQgVEJJRF9BIHRoYXQgd2FzIHBhc3NlZCB0 byBHIGluIHRoZSBpbml0aWFsIHJlZGlyZWN0IEEtJmd0O0cuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj41KSBBIG5vdyBoYXMgYSB0b2tlbiBmcm9t IEcgdGhhdCBpcyBib3VuZCB0byBUQklEX0EuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZXJlIGFyZSBzaXR1YXRpb25zIHdoZXJlIHRo ZXJlIGlzIGEgbmVlZCBmb3IgVFA0IHRvIGdlbmVyYXRlIGEgdG9rZW4gZm9yIFRDMSwgdGhlbiBJ IHRoaW5rIGNoYW5nZXMgd291bGQgYmUgbmVlZGVkIHRvIFRCSFRUUFMgdG8gc3VwcG9ydCB0aGF0 LiBPbmUgc3VjaCBjaGFuZ2UgY291bGQgYmUgZm9yIEluY2x1ZGUtUmVmZXJlci1Ub2tlbi1CaW5k aW5nLUlEIHRvIHBhc3MgYWxvbmcgYWxsIFRCSURzIGZyb20NCiB0aGUgcHJldmlvdXMgcmVxdWVz dCBpbnN0ZWFkIG9mIGp1c3Qgb25lLiBUaGlzIHdvdWxkIG9ubHkgd29yayBpZiB0aGVyZSB3YXMg YSBzaW5nbGUgY2hhaW4gb2YgcmVkaXJlY3RzIGZyb20gVEMxIGFsbCB0aGUgd2F5IHRvIFRQNC4g T25jZSBUUDQgcmVjZWl2ZXMgdGhpcyBUb2tlbkJpbmRpbmdNZXNzYWdlIHdpdGggVEJJRDEsIFRC SUQyLCBUQklEMywgYW5kIFRCSUQ0IChhbmQgdmVyaWZpZXMgYWxsIG9mIHRoZW0pLCBpdCBjb3Vs ZCBpc3N1ZSBhDQogdG9rZW4gdGhhdCBpcyBib3VuZCB0byBhbGwgb2YgdGhlbSwgYW5kIHRoZW4g VEMxIGl0ZXJhdGVzIHRocm91Z2ggdGhlIGJvdW5kIFRCSURzIHRvIGZpbmQgb25lIHRoYXQgaXQg cmVjb2duaXplcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gRnJpLCBNYXIgMjUsIDIwMTYgYXQgNzo1NiBQTSwgPUplZmZIICZsdDs8YSBo cmVmPSJtYWlsdG86SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20iIHRhcmdldD0iX2JsYW5r Ij5KZWZmLkhvZGdlc0BraW5nc21vdW50YWluLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbmRheSwgTWFyY2gg MjEsIDIwMTYgYXQgMTo0MCBQTSwgTmljayB3cm90ZTo8YnI+DQomZ3Q7IE15IHVuZGVyc3RhbmRp bmcgb2YgdGhlIHByb2JsZW0gaW4gZmlndXJlIDEgaXMgdGhhdDxicj4NCiZndDs8YnI+DQomZ3Q7 IDEpIGluIHRoZSByZWRpcmVjdCBmcm9tIFRDMiB0byBUUDMgKHN0ZXAgMmIpLCB0aGUgcmVmZXJy ZWQgVEJJRDxicj4NCiZndDsgaXMgVEJJRDIsIHdoaWxlIHRoZSByZWRpcmVjdCB1cmkgaXMgdG8g VEMxLCBhbmQuLjxicj4NCjxicj4NCnllcywgdGhpcyBpcyBhbiBpc3N1ZSAtLSBpbiB0aGlzIGNh c2UgVEJJRDEgbmVlZHMgdG8gYmUgKHNvbWVob3cpIHJlbGF5ZWQuPGJyPg0KPGJyPg0KPGJyPg0K Jmd0OyAyKSB3aGVuIFRQMyByZWRpcmVjdHMgdG8gVFA0LCBzb21laG93IFRCSUQyIG5lZWRzIHRv IGJlIHJlbGF5ZWQuPGJyPg0KPGJyPg0KYWN0dWFsbHksIFRCSUQxIG5lZWRzIHRvIGJlIHJlbGF5 ZWQgKHNvbWVob3cpIHJhdGhlciB0aGVuIFRCSUQyIGJlY2F1c2UgdGhhdCBpcyB3aGF0IGlzIGJl aW5nIGNhbGxlZCBmb3IgaW4gdGhlICZxdW90O2ZlZCBsYXllcidzJnF1b3Q7IGF1dGhuIHJlcXVl c3QncyByZWRpcmVjdF91cmkuPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBPbmUgd2F5IHRvIHNvbHZl IHByb2JsZW0gMiBpcyB0byB0cmVhdCB0aGUgVFAzLSZndDtUUDQgcmVkaXJlY3QgbGlrZSB0aGU8 YnI+DQomZ3Q7ICZxdW90O2lkZW50aXR5LWFzLWEtc2VydmljZSZxdW90OyBzY2VuYXJpbyB0aGF0 IERpcmsgbWVudGlvbmVkLiBJbnN0ZWFkIG9mIFRQNDxicj4NCiZndDsgcmVkaXJlY3RpbmcgdG8g VEMxLCBpdCBjYW4gY3JlYXRlIGEgdG9rZW4gdG8gYmUgY29uc3VtZWQgYnkgVFAzLCBhbmQ8YnI+ DQomZ3Q7IHJlZGlyZWN0IHRvIFRQMywgd2hpY2ggd2lsbCB0aGVuIGNyZWF0ZSBhIHRva2VuIHRv IHNlbmQgYmFjayB0byBUQzEuPGJyPg0KPGJyPg0KSU1WIGl0IGlzIGluYXBwcm9wcmlhdGUgZm9y IHVzIHRvIHNwZWNpZnkgYSBzb2x1dGlvbiBsaWtlIHRoYXQgKGkuZS4sIGNoYWluaW5nIElEUHMp IGluIC10b2tiaW5kLWh0dHBzIGFrYSBIVFRQU1RCIC0tIHN1Y2ggYSBjb25maWd1cmF0aW9uIGlz IHVwIHRvIGhvdyB0aGUgZmVkIGxheWVyIGlzIGNvbmZpZydkIGFuZCBkZXBsb3llZC4gSXQgbWF5 IG9yIG1heSBub3QgYmUgYXBwcm9wcmlhdGUgZm9yIGEgZ2l2ZW4gZmVkZXJhdGlvbi48YnI+DQo8 YnI+DQo8YnI+DQomZ3Q7IEZvciBwcm9ibGVtIDEsIEkgYW0gZ29pbmcgdG8gYXNzdW1lIHRoYXQg VEMxIGFuZCBUQzIgYXJlIGNvb3BlcmF0aW5nLjxicj4NCiZndDsgVGhlIGVhc2llc3Qgd2F5IHRv IGZpeCB0aGlzIGlzIHRvIGhhdmUgVEMyIHRyYW5zbWl0IHRvIFRDMTxicj4NCiZndDsgb3V0LW9m LWJhbmQgd2hhdCBUQklEMiBpcyBzbyB0aGF0IFRDMSBjYW4gdmVyaWZ5IGl0Ljxicj4NCjxicj4N CmRpZCB5b3UgbWVhbiB0byBzYXk6IGhhdmUgVEMxIHRyYW5zbWl0IG91dC1vZi1iYW5kIFRCSUQx IHRvIFRDMiA/IC4uYmVjYXVzZSB0aGUgaXNzdWUgaGVyZSBpbiBuZWVkaW5nIHRvIHJlbGF5IFRC SUQxIHNvbWVob3csIHVubGVzcyBJJ20gbWlzc2luZyBzb21ldGhpbmcuPGJyPg0KPGJyPg0KPGJy Pg0KJmd0OyBIZXJlJ3MgYW5vdGhlciBzb2x1dGlvbiAoZm9yIGJvdGggcHJvYmxlbXMpIHRoYXQg SSB0aGluayBjb3VsZCB3b3JrLi4uPGJyPg0KJmd0OyAuLiZsdDtlbGlkZWQmZ3Q7Li48YnI+DQo8 YnI+DQpUaGUgYWJvdmUgb3RoZXIgc29sdXRpb24gZWxpZGVkIGR1ZSB0byB0aGUgYmVsb3cgc3Vi c2VxdWVudCBhbmFseXNpcy48YnI+DQo8YnI+DQo8YnI+DQpPbiBUaHVyc2RheSwgTWFyY2ggMjQs IDIwMTYgYXQgMzoxNSBQTSwgTmljayB3cm90ZTo8YnI+DQomZ3Q7IFRMO0RSOiBVc2UgSW5jbHVk ZS1SZWZlcmVyLVRva2VuLUJpbmRpbmctSUQuIEJpbmRpbmcgYSB0b2tlbiB0byBhbjxicj4NCiZn dDsgSUQgdGhhdCBoYXNuJ3QgYmVlbiB2ZXJpZmllZCBjYW4gcmVzdWx0IGluIGEgTWl0TSBnZXR0 aW5nIGNvbnRyb2wgb2Y8YnI+DQomZ3Q7IGEgYm91bmQgdG9rZW4uPGJyPg0KJmd0Ozxicj4NCiZn dDsgRGlyayBhbmQgSSBjaGF0dGVkIGFib3V0IG15L0RhdmlkJ3MgcHJvcG9zYWwsIGFuZCBob3cg aXQgYXBwbGllcyB0bzxicj4NCiZndDsgSmVmZidzIHNjZW5hcmlvLiBJbiBzdGVwcyAzYSBhbmQg M2IgZnJvbSBmaWd1cmUgMSwgVEJJRDMgbmVlZHMgdG8gYmU8YnI+DQomZ3Q7IHJlZmVycmVkIHRv IFRQNCAoaW4gYWRkaXRpb24gdG8gY29udmV5aW5nIFRCSUQyKS48YnI+DQo8YnI+DQphY3R1YWxs eSwgY29udmV5aW5nIFRCSUQzIHRvIFRQNCBpcyBvcHRpb25hbCBJTVYgYW5kIG9uZSB3b3VsZCBv bmx5IG5lZWQgdG8gZG8gaXQgaWYgVFA0IGlzIGFsc28gbWludGluZyBvdGhlciBib3VuZCBzZWMg dG9rZW5zIGVnIGNvb2tpZXMgd2l0aCBUQklEMyBpbiAnZW0uPGJyPg0KPGJyPg0KQWxzbywgaXQg aXMgVEJJRDEgdGhhdCBhY3R1YWxseSBuZWVkcyB0byBiZSByZWZlcnJlZCwgaW4gb3JkZXIgdG8g cHJvcGVybHkgaXNzdWUgdGhlIElEIFRva2VuLiBUaGUgcmVtYXJrIGluICh0aGUgb2xkKSBmaWd1 cmUgMSB3cnQgJnF1b3Q7c29tZWhvdyBjb252ZXlzIFRCSUQyID8mcXVvdDsgaXMgc2ltcGx5IGEg cmVmZXJlbmNlIHRvIERpcmsncyBjb21tZW50cyB3aGVyZSBoZSBzdWdnZXN0ZWQgdGhhdCB0aGF0 IGlzIHdoYXQgd2UnZCBkbyBoZXJlLiBTZWUgdXBkYXRlZA0KIGZpZ3VyZSAxYSBiZWxvdy48YnI+ DQo8YnI+DQo8YnI+DQomZ3Q7IFRoZSBwcm9ibGVtIHdpdGggdGhlIGN1cnJlbnQgc2V0dXAgb2Yg ZmlndXJlIDEgaXMgd2hlbiB0aGVyZSBpcyBhbjxicj4NCiZndDsgYXR0YWNrZXIgTWl0TWluZyBj b25uZWN0aW9ucyB0byBUUDMuIEluIHN0ZXAgMmIsIHRoZTxicj4NCiZndDsgVG9rZW5CaW5kaW5n TWVzc2FnZSBjb250YWlucyBUQklEMycgYW5kIFRCSUQyJywgYm90aCB1bmRlciBhdHRhY2tlcjxi cj4NCiZndDsgY29udHJvbC4gVGhlbiwgaW4gc3RlcCAzYiwgd2hlbiB0aGUgY2xpZW50IGZvbGxv d3MgdGhlIHJlZGlyZWN0IGZyb208YnI+DQomZ3Q7ICh0aGUgTWl0TSdkKSBUUDMgdG8gVFA0LCBp dCBpbmNsdWRlcyBUQklENCwgYnV0IG5vdCBUQklEMywgaW4gdGhlPGJyPg0KJmd0OyBUb2tlbkJp bmRpbmdNZXNzYWdlLiBXaGVuIFRQNCBhdXRoZW50aWNhdGVzIHRoZSB1c2VyLCBUQklENCBpczxi cj4NCiZndDsgY29ycmVjdCwgYW5kIHRoZW4gVFA0IGNyZWF0ZXMgYSB0b2tlbiBmb3IgdGhlIHVz ZXIncyBpZGVudGl0eSB3aXRoIGFuPGJyPg0KJmd0OyBhdHRhY2tlci1jb250cm9sbGVkIFRCSUQu IEV2ZW4gaWYgVFAzIGFuZCBUUDQgYXJlIHNvbWVob3c8YnI+DQomZ3Q7IGNvb3BlcmF0aW5nLCBh bmQgdGhlIHByb3ZpZGVkIGFuZCByZWZlcnJlZCB0b2tlbiBiaW5kaW5ncyBmcm9tIHRoZTxicj4N CiZndDsgcmVxdWVzdCBpbiBzdGVwIDJiIGFyZSBwYXNzZWQgZnJvbSBUUDMgdG8gVFA0IG91dC1v Zi1iYW5kLCB0aGUgdG9rZW48YnI+DQomZ3Q7IHN0aWxsIGhhcyBhbiBhdHRhY2tlciBjb250cm9s bGVkIFRCSUQsIHNpbmNlIHRoZSB0b2tlbiBiaW5kaW5ncyBzZW50PGJyPg0KJmd0OyBpbiBzdGVw IDJiIGFyZSBhdHRhY2tlciBjb250cm9sbGVkLjxicj4NCjxicj4NCmFncmVlZCB3aXRoIHRoZSBh Ym92ZSBleGNlcHQgdGhhdCBpdCBpcyBUQklEMSB0aGF0IHJlYWxseSBuZWVkcyB0byBiZSBjb252 ZXllZCB0byB1bHRpbWF0ZWx5IHRvIFRQNCBpbiBvcmRlciBmb3IgdGhlIGxhdHRlciB0byBjb3Jy ZWN0bHkgaXNzdWUgdGhlIE9JREMgSUQgVG9rZW4sIG9yIFNBTUwgYXNzZXJ0aW9uIG9yIHdoYXRl dmVyLCBhdCB0aGUgZmVkIGxheWVyLjxicj4NCjxicj4NCjxicj4NCk9uIEZyaWRheSwgTWFyY2gg MjUsIDIwMTYgYXQgMTA6NDkgQU0sIERpcmsgd3JvdGU6PGJyPg0KJmd0OyBBZ3JlZWQuIEJvdHRv bSBsaW5lIGlzIHRoYXQgSSBzdGlsbCBiZWxpZXZlIHRoYXQgYSBzaW5nbGUgcmVmZXJyZWQ8YnI+ DQomZ3Q7IHRva2VuIGJpbmRpbmcgKGV2ZW4gb24gcmVwZWF0ZWQgcmVkaXJlY3RzKSBnaXZlcyB1 cyBhbGwgd2UgbmVlZC48YnI+DQo8YnI+DQpJIGFncmVlIGl0IGlzICZxdW90O2FsbCB3ZSBuZWVk JnF1b3Q7IF9pZl8gd2UgYXJlIHNheWluZyB0aGF0IGl0IGlzIG91dC1vZi1zY29wZSBmb3IgSFRU UFNUQiB0byBzcGVjaWZ5IGhvdywgaW4gYSBtdWx0aS1yZWRpcmVjdCBzY2VuYXJpbyBzdWNoIGFz IGZpZyAxYSwgZm9yIHRoZSBjb3JyZWN0IHJlZmVycmVkIFRCSUQgdG8gYmUgY29udmV5ZWQgdG8g dGhlIFRDJ3MgcG9pbnQtb2YtaGFuZG9mZi10by1UUCwgYW5kIHNpbWlsYXJseSBvdXQtb2Ytc2Nv cGUgZm9yIGFueQ0KIHJlZGlyZWN0cyBhbW9uZyBUUCBlbnRpdGllcyBwZXIgSFRUUFNUQiBzcGVj IChpLmUuLCB0aGV5IGZpZ2dlciBpdCBvdXQgdGhlbXNlbHZlcykuPGJyPg0KPGJyPg0KSS5lLiwg d2UgX2Nhbl8gc2F5IHRoZSBhYm92ZSBJIHRoaW5rIC0tIHRobyBzb21lIG1heSBwZXJjZWl2ZSBp dCBhcyBzdWItb3B0aW1hbCB0byBqdXN0IGxlYXZlIGl0IHVuc3BlY2lmaWVkIC0tIGJ1dCBpdCBt YXkgbm90IGJlIHRoYXQgYmlnIGEgZGVhbCwgSSBkb24ndCBrbm93LiAoZmVkZXJhdGlvbiBmb2xr IHBsZWFzZSBzcGVhayB1cCBoZXJlICEpPGJyPg0KPGJyPg0KV2UgY291bGQgZGV2aXNlIHNvbWUg bWVhbnMgb2Ygc2lnbmFsaW5nIGluIHRoZSBIVFRQU1RCIGhlYWRlciBmaWVsZCBsYXllciBmcm9t IFRDLXRvLVRDIGFuZCBUUC10by1UUCB3aGF0IHRoZSBjb3JyZWN0IFRCSUQgdG8gdXNlIGlzICho bSwgaXQgd2lsbCByZXF1aXJlIGludGVncml0eSBwcm90ZWN0aW9uIGZyb20gdGhlIHBvc3R1bGF0 ZWQgTUlUTXMpIGFuZCB0aGF0IG1pZ2h0IHNhdmUgdGhlIGZlZCBsYXllciBmb2xrcyBmcm9tIGlu dmVudGluZw0KIGRpc2pvaW50IHdheXMgdG8gZG8gaXQgKGFuZCBobSwgaG93ZXZlciB0aGV5IGRv IGl0IHdpbGwgbmVlZCBpbnRlZ3JpdHkgcHJvdGVjdGlvbikuLi48YnI+DQo8YnI+DQpCdXQgd2Ug bWF5IG5vdCB3YW50IHRvIGdvIHRoZXJlLCBJJ20gbm90IHN1cmUgbXlzZWxmLjxicj4NCjxicj4N CkhUSCw8YnI+DQo8YnI+DQo9SmVmZkg8YnI+DQotLS0tLS08YnI+DQo8YnI+DQo8YnI+DQpGaWd1 cmUgMWE6Jm5ic3A7ICZuYnNwOyggTm90ZTogaWYgdGhpcyBmaWcgZ2V0cyBpbnNlcnRlZCBpbnRv IHRoZSBzcGVjIGl0IHdpbGw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bGlrZWx5IF9ub3RfIGJl IGxhYmVsZWQgJnF1b3Q7ZmlnIDEmcXVvdDsgdGhlcmUgKTxicj4NCldoYXQ6IEFuYWx5c2lzIG9m IHJlZGlyZWN0IGhvcHMgYXQgUlAgYWthIFRDIGFuZCBhdCBJRFAgYWthIFRQPGJyPg0KPGJyPg0K TGVnZW5kOiAoc2VlIGZpZ3VyZSAxIGluIGEgcHJpb3IgZW1haWwgbXNnKTxicj4NCjxicj4NCjxi cj4NCkNsaWVudCwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRva2VuIENvbnN1bWVyLCZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUb2tlbiBQcm92aWRlciw8YnI+DQpha2E6Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWthOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBha2E6PGJyPg0KVXNlciBB Z2VudCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO09wZW5JRCBDbGllbnQsJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBPcGVuSUQgUHJvdmlkZXIsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtPSURDIFJlbHlpbmcgUGFydHksJm5ic3A7ICZuYnNwOyAmbmJz cDtPSURDIFByb3ZpZGVyLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7U0FNTCBSZWx5aW5nIFBhcnR5Jm5ic3A7ICZuYnNwOyAmbmJzcDsgU0FNTCBJ ZGVudGl0eSBQcm92aWRlcjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O1sgc2VydmVycyAmcXVvdDsxJnF1b3Q7LCAmcXVvdDsyJnF1b3Q7IF0mbmJzcDsgJm5ic3A7IFsg c2VydmVycyAmcXVvdDszJnF1b3Q7LCAmcXVvdDs0JnF1b3Q7IF08YnI+DQomIzQzOy0tLS0tLS0t JiM0MzsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS0tLS0mIzQzOyZuYnNwOyAmIzQz Oy0tLS0tJiM0MzsmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS0tLS0mIzQzOyZuYnNwOyAmbmJz cDsmIzQzOy0tLS0tJiM0Mzs8YnI+DQp8IENsaWVudCB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt8IFRDMSB8Jm5ic3A7IHwgVEMyIHwmbmJzcDsgJm5ic3A7ICZuYnNwO3wgVFAzIHwmbmJzcDsg Jm5ic3A7fCBUUDQgfDxicj4NCiYjNDM7LS0tLS0tLS0mIzQzOyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7JiM0MzstLS0tLSYjNDM7Jm5ic3A7ICYjNDM7LS0tLS0mIzQzOyZuYnNwOyAmbmJzcDsg Jm5ic3A7JiM0MzstLS0tLSYjNDM7Jm5ic3A7ICZuYnNwOyYjNDM7LS0tLS0mIzQzOzxicj4NCiZu YnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt8PGJyPg0KJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3w8YnI+DQombmJzcDsgJm5ic3A7IHwgMC4gQ2xpZW50IGludGVyYWN0cyB3 L1RDMSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3w8YnI+DQombmJzcDsgJm5ic3A7IHwgb3ZlciBIVFRQUywgZXN0YWJs aXNoZXMgS3MxICZhbXA7IEtwMSwgVEJJRDEmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiZuYnNw OyAmbmJzcDsgfCBFVEJNU0dbW3tFS00xfUtzMSxUQklEMSxwcm92aWRlZF90b2tlbl9iaW5kaW5n XV0mbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0K Jm5ic3A7ICZuYnNwOyB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5ic3A7ICZu YnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8YnI+ DQombmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fDxicj4NCiZuYnNwOyAmbmJzcDsgfCAxYS4gcmVkaXJlY3QgdG8gVEMyIGZvciBUQy1z cGVjaWZpYyByZWFzb25zJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiZuYnNwOyAmbmJzcDsgfCBhbnkgc2VjdXJpdHkt cmVsZXZhbnQgY29va2llcyBzaG91bGQgY29udGFpbiBUQklEMSB8Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3w8YnI+DQombmJzcDsgJiM0MzsmbHQ7LSAtIC0gLSAtIC0gLSAtIC0g LSAtIC0gLSAtIC0gLSB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fDxicj4NCiZuYnNwOyAuIHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7fDxicj4NCiZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tJmd0O3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiZuYnNwOyAmbmJz cDsgfCAxYi4gZXN0YWJsaXNoZXMgS3MyICZhbXA7IEtwMiwgVEJJRDImbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8YnI+DQombmJzcDsgJm5ic3A7IHwgRVRC TVNHW1t7RUtNMn1LczIsVEJJRDIscHJvdmlkZWRfdG9rZW5fYmluZGluZ11dJm5ic3A7ICZuYnNw O3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiZuYnNwOyAmbmJzcDsg fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5i c3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3w8YnI+DQombmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7fDxicj4NCiZuYnNwOyAmbmJzcDsgfCAyYS4gT0lEQyBJRCBUb2tlbiByZXF1 ZXN0LCZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3w8YnI+DQombmJzcDsgJm5ic3A7IHwgYWthICZxdW90O0F1dGhlbnRpY2F0aW9u IFJlcXVlc3QmcXVvdDsgdy8gcmVkaXJlY3RfdXJpPVRDMTsmbmJzcDsgJmx0Oy0tIG5vdGUgd2Vs bDxicj4NCiZuYnNwOyAmbmJzcDsgfCBjb252ZXllZCB3LyBIVFRQIHJlc3BvbnNlIGhlYWRlciBm aWVsZCBvZjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwO0lu Y2x1ZGUtUmVmZXJlci1Ub2tlbi1CaW5kaW5nLUlEOnRydWUmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8 YnI+DQombmJzcDsgJm5ic3A7IHwgYW55IHNlY3VyaXR5LXJlbGV2YW50IGNvb2tpZXMgc2hvdWxk IGNvbnRhaW4gVEJJRDIgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0K Jm5ic3A7ICYjNDM7Jmx0Oy0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAt fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5ic3A7IC4gfCAocmVkaXJlY3QgdG8gVFAgdmlh IDMwMSwgMzAyLCB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7fDxicj4NCiZuYnNwOyAuIHwmbmJzcDsgMzAzLCAzMDcsIG9yIDMwOCkmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiZuYnNwOyAuIHwmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiZuYnNwOyAmIzQzOy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiZuYnNwOyAmbmJzcDsgfCAyYi4gY2xpZW50 IG9wZW5zIEhUVFBTIHcvIFRQMywmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5ic3A7ICZuYnNwOyB8IGVzdGFibGlzaGVzIEtzMywg S3AzLCBUQklEMzsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7fDxicj4NCiZuYnNwOyAmbmJzcDsgfCBzZW5kcyBHRVQgb3IgUE9TVCB3 aXRoJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8YnI+DQombmJzcDsgJm5ic3A7IHwgSUQgVG9r ZW4gcmVxdWVzdCB3LyByZWRpcmVjdF91cmk9VEMxLCZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3w8YnI+DQombmJzcDsgJm5ic3A7IHwgRVRCTVNHW1t7RUtNM31LczMsVEJJRDMscHJvdmlkZWRf dG9rZW5fYmluZGluZ10sJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fDxicj4NCiZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1t7 RUtNM31LczIsVEJJRDIscmVmZXJyZWRfdG9rZW5fYmluZGluZ11dICZsdDstLSBidXQgSUQgVG9r IHJlcXVlc3Q8YnI+DQombmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy0tIGlzIGZvciBUQzE8YnI+DQombmJzcDsg Jm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxi cj4NCiZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt8PGJyPg0KJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3w8YnI+DQombmJzcDsgJm5ic3A7IHwgM2EuIHJlZGlyZWN0IHRv IFRQNCBmb3IgVFAtc3BlY2lmaWMgcmVhc29ucyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8YnI+DQombmJzcDsgJm5ic3A7IHwg YW55IHNlY3VyaXR5LXJlbGV2YW50IGNvb2tpZXMgc2hvdWxkIGNvbnRhaW4gVEJJRDMgfCZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5ic3A7ICYjNDM7Jmx0Oy0gLSAt IC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtfCZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5ic3A7IC4gfCZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5ic3A7ICYjNDM7LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Jmd0O3w8YnI+DQombmJzcDsgJm5ic3A7IHwgM2IuIGNsaWVudCBvcGVucyBIVFRQUyB3LyBUUDQs Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxi cj4NCiZuYnNwOyAmbmJzcDsgfCBlc3RhYmxpc2hlcyBLczQgJmFtcDsgS3A0LCBUQklENCZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8 PGJyPg0KJm5ic3A7ICZuYnNwOyB8IEVUQk1TR1tbe0VLTTR9S3M0LFRCSUQ0LHByb3ZpZGVkX3Rv a2VuX2JpbmRpbmddXSZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3w8YnI+DQombmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7KioqIGFzIHdlbGwgYXMgdGhlIElEIFRva2VuIHJlcXVlc3Qgdy8gcmVkaXJlY3RfdXJpPVRD MTs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsqKiogYWxzbywgc29tZWhvdyBjb252ZXlzIFRCSUQxIHRvIFRQ NCAmbHQ7LS0gTmVlZCB0aGlzIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy0tIGlzc3VlIGJvdW5k PGJyPg0KJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy0tIElEIFRva2VuPGJyPg0KJm5ic3A7ICZuYnNwOyB8Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8YnI+DQombmJzcDsg Jm5ic3A7IHwgNC4gdXNlciBhdXRoZW50aWNhdGlvbiAoaWYgYXBwbGljYWJsZSwmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3w8YnI+DQombmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7IG1ldGhv ZHMgdmFyeSwgcGFydGljdWxhcnMgYXJlIG91dCBvZiBzY29wZSkmbmJzcDsgJm5ic3A7ICZuYnNw O3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiZuYnNwOyAmbmJzcDsg fCZsdDs9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0mZ3Q7fDxicj4NCiZuYnNwOyAmbmJzcDsgfCAoVFAgZ2VuZXJhdGVzIElEIFRva2Vu IGZvciBUQzEgY29udGFpbmluZyBUQklEMSZuYnNwOyAmbmJzcDsmbHQ7LS0gTmVlZCB0byBnZXQ8 YnI+DQombmJzcDsgJm5ic3A7IHwmbmJzcDsgYWxzbyBzZXQgY29va2llKHMpIGNvbnRhaW5pbmcg VEJJRDQgYW5kL29yIFRCSUQzICZsdDstLSBUQklEMSBoZXJlPGJyPg0KPHNwYW4gY2xhc3M9Imlt Ij4mbmJzcDsgJm5ic3A7IHwmbmJzcDsgZGV0YWlscyB2YXJ5KSZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Imlt Ij4mbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fDwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPiZuYnNwOyAmbmJzcDsgfCZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PC9zcGFuPjxicj4NCjxz cGFuIGNsYXNzPSJpbSI+Jm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3w8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj4mbmJzcDsg Jm5ic3A7IHwgNWEuIElEIFRva2VuIGlzc3VlZCBmb3IgVEMxLCBjb250YWluaW5nIFRCSUQxLCAm bHQ7LS0gaG93IGRvIHRoaXMgaWY8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj4mbmJzcDsg Jm5ic3A7IHwmbmJzcDsgJm5ic3A7IGNvbnZleWVkIHZpYSBPSURDICZxdW90O0F1dGhlbnRpY2F0 aW9uIFJlc3BvbnNlJnF1b3Q7ICZsdDstLSBkb24ndCBoYXZlIFRCSUQxPzwvc3Bhbj48YnI+DQo8 c3BhbiBjbGFzcz0iaW0iPiZuYnNwOyAmIzQzOyZsdDstIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAt IC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC18PC9zcGFuPjxicj4NCjxzcGFu IGNsYXNzPSJpbSI+Jm5ic3A7IC4gfCZuYnNwOyAmbmJzcDsocmVkaXJlY3QgdG8gVEMxKSZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Imlt Ij4mbmJzcDsgLiB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3w8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj4mbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7fDwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPiZuYnNwOyAmbmJz cDsgfCA1Yi4gSFRUUFMgR0VUIG9yIFBPU1Qgd2l0aCZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8L3NwYW4+PGJyPg0KPHNwYW4g Y2xhc3M9ImltIj4mbmJzcDsgJm5ic3A7IHwgRVRCTVNHW1t7RUtNMX1LczEsVEJJRDEscHJvdmlk ZWRfdG9rZW5fYmluZGluZ11dJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7fDwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPiZuYnNwOyAmbmJzcDsgfCBj b252ZXlpbmcgQXV0aG4gUmVwb25zZSBjb250YWluaW5nIElEIFRva2VuIHcvVEJJRDEsJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Imlt Ij4mbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpc3N1ZWQgZm9yIFRDMSZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Imlt Ij4mbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fDwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPiZuYnNwOyAmbmJzcDsgfCZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PC9zcGFuPjxicj4NCjxz cGFuIGNsYXNzPSJpbSI+Jm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3w8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj4mbmJzcDsg Jm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDwv c3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPiZuYnNwOyAmbmJzcDsgfCA2LiB1c2VyIGlzIHNp Z25lZC1vbiwgYW55IHNlY3VyaXR5LXJlbGV2YW50IGNvb2tpZShzKSZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB8PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jm5ic3A7ICZuYnNwOyB8 IHRoYXQgYXJlIHNldCBTSE9VTEQgY29udGFpbiBUQklEMSZuYnNwOyAmbmJzcDsgJm5ic3A7IHwm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7fDwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPiZuYnNwOyAm bmJzcDsgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDwvc3Bhbj48YnI+DQo8c3BhbiBjbGFz cz0iaW0iPiZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt8PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jm5ic3A7ICZuYnNwOyB8 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVW5iZWFyYWJsZSBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPlVuYmVhcmFibGVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYl MmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZ1bmJlYXJhYmxlJmFtcDtkYXRh PTAxJTdjMDElN2NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdjNTY5MjVjYTcyNjkxNDhi ZmVkNTYwOGQzNTUyNzdmYWYlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEm YW1wO3NkYXRhPTVybnJrMnBYaU9mZGFpS3NXaUVzS0F0S2FMNkdudktEbFBjc0tVUjBiQ0ElM2Qi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Vu YmVhcmFibGU8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BLUPR03MB1396A8439FD3E9412FEF873E8C860BLUPR03MB1396namp_-- From nobody Mon Mar 28 16:15:07 2016 Return-Path: <martin.thomson@gmail.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 6219512D160 for <unbearable@ietfa.amsl.com>; Mon, 28 Mar 2016 16:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CxxTrg1R_ceb for <unbearable@ietfa.amsl.com>; Mon, 28 Mar 2016 16:15:03 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B54AE12D0E5 for <unbearable@ietf.org>; Mon, 28 Mar 2016 16:15:03 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id e3so2212399ioa.1 for <unbearable@ietf.org>; Mon, 28 Mar 2016 16:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=yoTpw3Q63HqBLrCwRovzyrqfoH5CkCdaxEhFAKmp4nE=; b=B6WgwvXobb56VTCCuAN1mx5q7wWGGfred8OAU/rmiQO2pd/6ImyAvDWLVDCldiNcKb X660TVPUZn8hz4SNIX6uQMWu8AjwTUtX9VgEfdtCsn2FUksPksN/eKnxJF6lwUs8ewjx WJbfGigeEBSenuJooIzmg4Wt9tmkmoQYR9tAB75if3DN8BHkCFYXRrCq1NVfG55fkJ5z 0eLvQOaeV2ATA0AWcxoeB/IIEnHdBOrk5vt8Imbv6qK5G6EvevzYzfBPeq+lF5qdM0KP NDlwo+3be90amzcogVGeYfQQzOpP/C/MxT65HuBfwchw7W5dnzfeDIRfake6T/cI9ZUG u/HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=yoTpw3Q63HqBLrCwRovzyrqfoH5CkCdaxEhFAKmp4nE=; b=dQNLJidSUrMVs2V4b9djRUSZ6aEp+6Di93NwJ9BlnYTNSY6j0HyMkzukdBdSYRCg4E WlMr5vWdl4sjPp9U90mYtQZN8ekStgE1w3d3FTSKWEqfkFkCiqedyn1Bda1dRXdO5SEH vRCOO27clkx6/zuA44lBHsKTMTmDcISySguetvzAqLZU0aDU053EWsWu8yPFuooYCdKr sfbGJszDckAUGsCfgyWfU8v8mwUUX8jOgfAVNxBRzURUi5I8K9dYK5k8XbX4PbhOJmnN ++ofVOCF8DkeyLa0r+dONckQA31aSGIjgjt9MDWlVy7I4/sz3xswGiBgIFQ+SRokG95e MKbQ== X-Gm-Message-State: AD7BkJL6bWMCGGsZml1YhKFUw3NX9djeFycABxLzXMZGbVkDeXZtvKdoDI0vYqwEQOfPMb0+0BWOaNYnaijecQ== MIME-Version: 1.0 X-Received: by 10.107.161.140 with SMTP id k134mr12103537ioe.190.1459206903029; Mon, 28 Mar 2016 16:15:03 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Mon, 28 Mar 2016 16:15:02 -0700 (PDT) In-Reply-To: <BLUPR03MB1396745AEBAA9911312ABD488C830@BLUPR03MB1396.namprd03.prod.outlook.com> References: <CAH9QtQFLWGLgKGkD8BeuEsGAaumuqzheBgaiuOHKuUvZucuRWw@mail.gmail.com> <BLUPR03MB139616608F68A44A25D7A6758C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CAH9QtQFFppvqu42B_TuKDfO_6pMkTCBtzhDWbTh+PVfyPVGGyw@mail.gmail.com> <BLUPR03MB13961CA8EF0DE7D342ADDDC78C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CABkgnnW2v2cK-FRm59c5x3b3pWq6Lbbfvv65oSo2VjY9xdPYiQ@mail.gmail.com> <CAH9QtQFOWqXaon4xNHxRdxOb-EvDGoZXo=EdPbvi-nNTFKZA0g@mail.gmail.com> <BLUPR03MB1396D4C18D5D082283D481DA8C820@BLUPR03MB1396.namprd03.prod.outlook.com> <CABkgnnW-L9WHFFPHvGATGnC7pV2mANggEYAzZ2aUwfp3uPwHMA@mail.gmail.com> <BLUPR03MB1396745AEBAA9911312ABD488C830@BLUPR03MB1396.namprd03.prod.outlook.com> Date: Tue, 29 Mar 2016 10:15:02 +1100 Message-ID: <CABkgnnVWHy_hOSKdS9FA1KGf59R1mfWnnPQET_6aZDuztxqqyA@mail.gmail.com> From: Martin Thomson <martin.thomson@gmail.com> To: Andrei Popov <Andrei.Popov@microsoft.com> Content-Type: text/plain; charset=UTF-8 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/le40HcbT_IbGgCB-Z9thC1gsrKc> Cc: Tokbind WG <unbearable@ietf.org>, Bill Cox <waywardgeek@google.com> Subject: Re: [Unbearable] Thoughts on TLS 0-RTT 1.3 compatibility X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 28 Mar 2016 23:15:05 -0000 On 26 March 2016 at 04:10, Andrei Popov <Andrei.Popov@microsoft.com> wrote: > Totally agree about the effort, but how about these incentives: > 1. Prevent attackers from exporting TLS session resumption secrets; Cost-benefit. If I could be convinced that it was worth the cost, then maybe. Even a handful of milliseconds is probably too much though. > 2. Enable more 0-RTT resumption in TLS (secure resumption secrets might be longer-lived); 0-RTT is pretty common already. And protection on the secrets isn't the only thing to consider when extending the lifetime of a secret. (The server doesn't know what protections are in place, so it's going to have its own limits, then there's all the other factors...) > 3. Enable TB in 0-RTT mode. That's not an incentive. To me, in any case. TB isn't an ends, it's a means. From nobody Mon Mar 28 22:06:24 2016 Return-Path: <balfanz@google.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 C04AE12D530 for <unbearable@ietfa.amsl.com>; Mon, 28 Mar 2016 22:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Gw2T_k0hGxEB for <unbearable@ietfa.amsl.com>; Mon, 28 Mar 2016 22:06:21 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1B712D52C for <unbearable@ietf.org>; Mon, 28 Mar 2016 22:06:21 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id 191so36357289wmq.0 for <unbearable@ietf.org>; Mon, 28 Mar 2016 22:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=KyuaVyHsHBHipOIf0F4xjHq8V0iuP/VXaLUTvc/f0iM=; b=ZftMKnKQuPM4nMN7ynUlCGZ7D/Gc5ivqoygwwdrOyd4La2RpX3DrdDkOZs6FAIYpzW /v1Q6lRnfsx53SL5UVKdcFppIA6L8ZLrmNrqGsRcc9169Yi4Wzd7d6a4Z2R/J3gVbZXP TVbf12P9shnhUW8KqBlGH9mdyx9WrvvSxog/DZhh3+WUX8DfX1XX1AiUZl5Ju26/6slr qAC/I4xa9HFkLy14dGdlbfbCGf7U1EzvqUXpYShbAAI1HnHYSMa9Dww8fGvG4/S0njPW 1iIkzNd/Rvq1h9WzlS6RLaORd/joY6jo0BTKxdzfWoLFFS0jl8m5Cq36futJoo5WHTZF TaDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=KyuaVyHsHBHipOIf0F4xjHq8V0iuP/VXaLUTvc/f0iM=; b=TA0LlfMA+gGiXQ8RFlU6P4S9wPLtrOycVaLfeyIqMIM6D7gAsEpg8kqYlBRTKx/eyW 7AWVgyj5Xs1Xaqpm9tYquV/cN5IHPT9k7X7HfK2FH6EzMYRq9HqZSGK9thoOImBV7aS3 n59C9QbgzDx0ndZ+k6A3UYQhni02vpW4RU0DOXln0Gqna5z/FOlyIbxQ0fSRf7Es6ljq DGPU4NEUuXm9+0e6A0a3n8he3d+7RSbFhQ1aXM7bUIezj3qLBEkK5w8PJHeOa1o1yQkx 7EPoWlr2rt0lODZG817LP2rmp9NGndxDC8gbnLjZIMN8OsG/YgxXK/Rbiz04TYHw1Z6v 6ZuA== X-Gm-Message-State: AD7BkJLo3z2JgHew0DevTJx1BzJ7Mn6GYzmuyI6Gyyb+xWg9jpdxbOIrdTTxNuI3Cmjt37B6MVJsmQek5jUmJ20o X-Received: by 10.28.49.3 with SMTP id x3mr737640wmx.4.1459227979625; Mon, 28 Mar 2016 22:06:19 -0700 (PDT) MIME-Version: 1.0 References: <56F45DA8.6070303@KingsMountain.com> In-Reply-To: <56F45DA8.6070303@KingsMountain.com> From: Dirk Balfanz <balfanz@google.com> Date: Tue, 29 Mar 2016 05:06:10 +0000 Message-ID: <CADHfa2Ab62dNVGwveyqkhT3LOpd4SCUicoHG=NT=w3KEaeP3dQ@mail.gmail.com> To: "=JeffH" <Jeff.Hodges@kingsmountain.com>, IETF Tokbind WG <unbearable@ietf.org> Content-Type: multipart/alternative; boundary=001a1142b97a5f8d85052f28fd04 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/TzWsqlt0JfEoOIZHg_ZPw39wE_E> Subject: Re: [Unbearable] Potential privacy bug if Include-Referer-Token-Binding-ID is improperly implemented client-side X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 29 Mar 2016 05:06:24 -0000 --001a1142b97a5f8d85052f28fd04 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 24, 2016 at 2:35 PM =JeffH <Jeff.Hodges@kingsmountain.com> wrote: > On 3/22/16, 6:15 PM, "Unbearable on behalf of Nick Harper" > <unbearable-bounces@ietf.org on behalf of nharper@google.com> wrote: > > >On Tue, Mar 22, 2016 at 6:10 PM, =JeffH > ><Jeff.Hodges@kingsmountain.com> wrote: > > > >thx for clarifications, Nick. further questions & thoughts.. > > > >> Here's the problem: Suppose the connection to server A is over http. > >> Now a network attacker B injects into some http page (from server C) > >> code that will cause the client to make an http request to server A. > >> The attacker B intercepts the request and responds with a redirect to > >> server B (with the Include-Referer-Token-Binding-ID header). > > > >the redirect to B will be an HTTP 30x response not over TLS, regardless > >of whether the Location: header field contains a https URI, yes? > > > >Correct. > > > >> The client dutifully follows that request and forwards the > >> TokenBindingID it has for A to the attacker-controlled B. > > > >Should we not explicitly stipulate in -tokbind-https that the client MUST > >NOT honor any Include-Referer-Token-Binding-ID header received over > >insecure transport? This is how we addressed similar situations in the > >HSTS and HPKP specs. > > > >The addition of > > > https://github.com/TokenBinding/Internet-Drafts/commit/2033a64397590a55811 > >cb78af8f5aa739cb8c981 > >< > https://github.com/TokenBinding/Internet-Drafts/commit/2033a64397590a5581 > >1cb78af8f5aa739cb8c981> implicitly states that (since the Token-Binding > >header is not sent over an insecure transport). > > agreed, it does implicitly state that requirement, thx -- I had not > thorougly reviewed Dirk's updates in -03. > > >I don't have strong feelings for whether this needs to be more > > explicit. > > I would make it explicit. > Open an issue on github? Dirk. > > > >> It would certainly be nice for the transport to be established error > >> free, and to use HSTS and HPKP, but I don't think those need to be made > >> as requirements for using Token Binding. > > > >I was not proposing stating any requirements wrt employing HSTS and HPKP > >-- rather, I am thinking that we should have some deployment > >considerations where HSTS and HPKP are dutifully mentioned and how their > >use composes with TB to the benefit of the > > web app provider and their users. > > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a1142b97a5f8d85052f28fd04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu= , Mar 24, 2016 at 2:35 PM =3DJeffH <<a href=3D"mailto:Jeff.Hodges@kingsm= ountain.com">Jeff.Hodges@kingsmountain.com</a>> wrote:<br></div><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex">On 3/22/16, 6:15 PM, "Unbearable on behalf of N= ick Harper"<br> <<a href=3D"mailto:unbearable-bounces@ietf.org" target=3D"_blank">unbear= able-bounces@ietf.org</a> on behalf of <a href=3D"mailto:nharper@google.com= " target=3D"_blank">nharper@google.com</a>> wrote:<br> <br> =C2=A0>On Tue, Mar 22, 2016 at 6:10 PM, =3DJeffH<br> =C2=A0><<a href=3D"mailto:Jeff.Hodges@kingsmountain.com" target=3D"_b= lank">Jeff.Hodges@kingsmountain.com</a>> wrote:<br> =C2=A0><br> =C2=A0>thx for clarifications, Nick. further questions & thoughts..<= br> =C2=A0><br> =C2=A0>> Here's the problem: Suppose the connection to server A i= s over http.<br> =C2=A0>> Now a network attacker B injects into some http page (from s= erver C)<br> =C2=A0>> code that will cause the client to make an http request to s= erver A.<br> =C2=A0>> The attacker B intercepts the request and responds with a re= direct to<br> =C2=A0>> server B (with the Include-Referer-Token-Binding-ID header).= <br> =C2=A0><br> =C2=A0>the redirect to B will be an HTTP 30x response not over TLS, rega= rdless<br> =C2=A0>of whether the Location: header field contains a https URI, yes?<= br> =C2=A0><br> =C2=A0>Correct.<br> =C2=A0><br> =C2=A0>> The client dutifully follows that request and forwards the<b= r> =C2=A0>> TokenBindingID it has for A to the attacker-controlled B.<br= > =C2=A0><br> =C2=A0>Should we not explicitly stipulate in -tokbind-https that the cli= ent MUST<br> =C2=A0>NOT honor any Include-Referer-Token-Binding-ID header received ov= er<br> =C2=A0>insecure transport? This is how we addressed similar situations i= n the<br> =C2=A0>HSTS and HPKP specs.<br> =C2=A0><br> =C2=A0>The addition of<br> =C2=A0><a href=3D"https://github.com/TokenBinding/Internet-Drafts/commit= /2033a64397590a55811" rel=3D"noreferrer" target=3D"_blank">https://github.c= om/TokenBinding/Internet-Drafts/commit/2033a64397590a55811</a><br> =C2=A0>cb78af8f5aa739cb8c981<br> =C2=A0><<a href=3D"https://github.com/TokenBinding/Internet-Drafts/co= mmit/2033a64397590a5581" rel=3D"noreferrer" target=3D"_blank">https://githu= b.com/TokenBinding/Internet-Drafts/commit/2033a64397590a5581</a><br> =C2=A0>1cb78af8f5aa739cb8c981> implicitly states that (since the Toke= n-Binding<br> =C2=A0>header is not sent over an insecure transport).<br> <br> agreed, it does implicitly state that requirement, thx -- I had not<br> thorougly reviewed Dirk's updates in -03.<br> <br> =C2=A0>I don't have strong feelings for whether this needs to be mor= e<br> =C2=A0> explicit.<br> <br> I would make it explicit.<br></blockquote><div><br></div><div>Open an issue= on github?</div><div><br></div><div>Dirk.</div><div>=C2=A0</div><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"> <br> <br> =C2=A0>> It would certainly be nice for the transport to be establish= ed error<br> =C2=A0>> free, and to use HSTS and HPKP, but I don't think those = need to be made<br> =C2=A0>> as requirements for using Token Binding.<br> =C2=A0><br> =C2=A0>I was not proposing stating any requirements wrt employing HSTS a= nd HPKP<br> =C2=A0>-- rather, I am thinking that we should have some deployment<br> =C2=A0>considerations where HSTS and HPKP are dutifully mentioned and ho= w their<br> =C2=A0>use composes with TB to the benefit of the<br> =C2=A0> web app provider and their users.<br> <br> <br> <br> <br> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> </blockquote></div></div> --001a1142b97a5f8d85052f28fd04-- From nobody Tue Mar 29 08:47:41 2016 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 585CC12D966 for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 08:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 orKy-DCfj2nU for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 08:47:31 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id F127D12D975 for <unbearable@ietf.org>; Tue, 29 Mar 2016 08:47:15 -0700 (PDT) Received: (qmail 2448 invoked by uid 0); 29 Mar 2016 15:47:15 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 29 Mar 2016 15:47:15 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id brnA1s00m2UhLwi01rnDvs; Tue, 29 Mar 2016 09:47:15 -0600 X-Authority-Analysis: v=2.1 cv=aJ5j99Nm c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=o2b0UYOfsoIA:10 a=7OsogOcEt9IA:10 a=c9hkn8_tIqYr3TUn1EoA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:Cc:To; bh=7d8aJ/izHmZ8pb8BhUOCu3zycd0v3aBNBceuB9bdha8=; b=8bywUT554Z85WUoGU2sdVNF1MN +NA79djwyLXJKyASCupf5ZwlnYlbh28MvfSCmymUFxDuRC4kxogG9ua9oEXacceLS3ItN9z9ZmhvG nNQyBXIwyUYOhMApko7izwjV3; Received: from [70.197.5.62] (port=2411 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1akvrK-0006vG-Do; Tue, 29 Mar 2016 09:47:10 -0600 To: Nick Harper <nharper@google.com> From: =JeffH <Jeff.Hodges@KingsMountain.com> Message-ID: <56FAA372.1000400@KingsMountain.com> Date: Tue, 29 Mar 2016 08:46:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.197.5.62 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/TgTCWUWP9jKCuamAFpHZBUi7vgU> Cc: IETF Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 29 Mar 2016 15:47:40 -0000 On Friday, March 25, 2016 at 8:33 PM, Nick wrote: > > If you want TP4 to generate a token bound to TBID1, given the flexibility in typical federation (Fed) frameworks, such as SAML and OIDC and WS-Federation, I am thinking we may need similar flexibility in the tokbind layer _if_ we wish to explicitly support Fed frameworks in a similarly flexible fashion. It would be good to have someone(s) familiar with actual fed deployments weigh in tho, e.g. our erstwhile co-chairs :) > then TP4 needs to > verify that TBID4 and TBID1 are both owned by the same client. agreed. > IMO, the easiest way to do this is to have both TBIDs in the same > TokenBindingMessage. nominally agreed given present tokbind design. > I'm curious if this scenario (with TC1, TC2, > TP3, and TP4) is hypothetical, or if there are real-world setups > that work like this where TC1 can't redirect directly to TP4, SAML, OIDC, and WS-Fed were explicitly designed with the "AssertionConsumerServiceURL", "redirect_uri", "wreply" (respectively) in order to accommodate the latter use case. > or you > can't have TP4 issue a token for TP3, which then issues a token for > TC2, which issues a token for TC1 (as Dirk suggests). that is one possible deployment architecture, but it isn't the only one, and I don't know how Fed deployment folks at large would view it. > I can think of a federated scenario that currently exists where > there are multiple token consumers and producers, but it works with a > single referred token binding from Include-Referer-Token-Binding-ID. > <details elided> yes, it appears that the present TBPROTO + HTTPSTB design accommodates that particular use case. > If there are situations where there is a need for TP4 to generate a > token for TC1, then I think changes would be needed to TBHTTPS to > support that. Agreed w/latter. Wrt former, see above. > One such change could be for Include-Referer-Token-Binding-ID to pass > along all TBIDs from the previous request instead of just one. This > would only work if there was a single chain of redirects from TC1 all > the way to TP4. Once TP4 receives this TokenBindingMessage with > TBID1, TBID2, TBID3, and TBID4 (and verifies all of them), it could > issue a token that is bound to all of them, and then TC1 iterates > through the bound TBIDs to find one that it recognizes. I was toying with a similar idea and it seemed to me that the set of TBIDs conveyed in the TBMSG to whatever server could possibly grow unbounded... HTH =JeffH From nobody Tue Mar 29 09:37:02 2016 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 289F612DAA8 for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 09:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 sJVZe-p-5TPG for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 09:36:54 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 1077912DA15 for <unbearable@ietf.org>; Tue, 29 Mar 2016 09:30:09 -0700 (PDT) Received: (qmail 24224 invoked by uid 0); 29 Mar 2016 16:30:08 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 29 Mar 2016 16:30:08 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id bsW51s00q2UhLwi01sW8pp; Tue, 29 Mar 2016 10:30:08 -0600 X-Authority-Analysis: v=2.1 cv=aJ5j99Nm c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=o2b0UYOfsoIA:10 a=7OsogOcEt9IA:10 a=hOS2hIbhq5fPKGaUmWoA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:Cc:To; bh=V0/UJ61TAjD50lCub0K4BczCnQwq9LH0z/sw3FsQNpM=; b=eqyke0aeO2XCc/GTSLkiAuPpDR o8W7FK/tYQqUC9tFRyz9waf1x7BjmXl75Bcbpl9ZyPwR0G2+6dvluC8qxeuO8hoNQiolK8S1fzb+b 1W2OVWdnPSGtTxkBhnhloZqP/; Received: from [70.197.5.62] (port=2413 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1akwWr-0005Ww-01; Tue, 29 Mar 2016 10:30:05 -0600 To: Andrei Popov <Andrei.Popov@microsoft.com> From: =JeffH <Jeff.Hodges@KingsMountain.com> Message-ID: <56FAAD89.6060005@KingsMountain.com> Date: Tue, 29 Mar 2016 09:30:01 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.197.5.62 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/Hnyv67dtuBR2iF8LkRIL3Fa9CVE> Cc: IETF Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 29 Mar 2016 16:37:00 -0000 Andrei wrote: > If we wanted to short-circuit the return path, so that IDP2 can redire= ct > back to the RP, then indeed we=E2=80=99d need to convey TBID_RP to IDP= 2, given the flexibility extant in federation frameworks, not facilitating t= he=20 above will yield a flexibility mismatch between the latter and tokbind-ht= tps. we /can/ say "that's the way it is, live with it", or we can work to addr= ess it. in any case, I've posted a plea for review & feedback to a federation=20 deployment mailing list, we'll see whether they have any cycles to contri= bute. =3DJeffH From nobody Tue Mar 29 10:45:41 2016 Return-Path: <nharper@google.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 350B212DFDF for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 10:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 FB64JNkJ6FZh for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 10:45:34 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33D912D9EC for <unbearable@ietf.org>; Tue, 29 Mar 2016 10:26:32 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id e6so28296842vkh.2 for <unbearable@ietf.org>; Tue, 29 Mar 2016 10:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ae37MuM3yzCBPjWXk0RTn+ZVanIwHSy6aOBBRb+oMII=; b=hQ0VVPUSMRXWLFkaRxjArxQ2qtRnfNw7+nrDuKGTgdYy3x23LJQ+RSj8SjrmUWRDE3 9pDBx0GSZCJq/l/KyAkVQ085kmhT9ucSsglAlZgGhdL19tKanCGgJ+EYWWVPljwofun6 SXQ5R+aHtjJ5Gj3v1YT0rlJk7QfAAdBsQHOP4tDET9d1IvtHD7BvA60YsZRDd3EoCYPm 1ntCDsj2kePIBwX2LVuYF85IP8hBVSvQjuKJ3sssLvbqGIcRixjbwrQQlLV3YvkI2tKz hdATWLu14IsFtNBxslegMdeQsKcSkQrq5TwKMFA9xkwive1J1s2v1A7La/3Wnk8AQfHG GMjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ae37MuM3yzCBPjWXk0RTn+ZVanIwHSy6aOBBRb+oMII=; b=mEyQH5QczPevFWyhoBS5JRaBFt0fEVJDwIbVzf705ea4ap+gt2dVJXkLblk3wuuOPq mAvi0bCe1bJ+5Nx/5EeZ2edNmGy3P9hRv/61L08v9hqzLL1UzCHyy0PeGJr/LfUpdzEN k0Q3lDDnbHLJ9E/9MXLo91oA7qXHmSyVLzSKK5GOgJKHpfYtAq1uT0ED5aLhqeGOz0PC uCz/LblNf4TdYXaQP7wPLLUcxB68vfdBytod+c8kEZWfUXHfQe/qcEJkA2SvpAC8C/Ik 8kPXKYkzMZVEYNUzU+xSW5voVdSqMhq/EBhAW8UY44xEq/jExb/FGZIwS7Bxucl7fdmS /PrA== X-Gm-Message-State: AD7BkJKXoqd8jzW46T0gjOUhqcZH4wHHAV3Erx/AN4mtUv+Kn/78itMSJ+axp1f9bOoaEoFhHuybx1Gyr6RyAerj X-Received: by 10.31.107.217 with SMTP id k86mr2225025vki.5.1459272391566; Tue, 29 Mar 2016 10:26:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.76.198 with HTTP; Tue, 29 Mar 2016 10:26:12 -0700 (PDT) In-Reply-To: <56FAA372.1000400@KingsMountain.com> References: <56FAA372.1000400@KingsMountain.com> From: Nick Harper <nharper@google.com> Date: Tue, 29 Mar 2016 10:26:12 -0700 Message-ID: <CACdeXi+6c8wZgWRv9Ab=pK3NJqNiUiuT07ttob0fZU7aYnq-Rw@mail.gmail.com> To: "=JeffH" <Jeff.Hodges@kingsmountain.com> Content-Type: multipart/alternative; boundary=001a1147881087f9ab052f335435 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/AcgfS34pAioWMY22UfwBYjsnJEQ> Cc: IETF Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 29 Mar 2016 17:45:40 -0000 --001a1147881087f9ab052f335435 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 29, 2016 at 8:46 AM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote: > On Friday, March 25, 2016 at 8:33 PM, Nick wrote: > > One such change could be for Include-Referer-Token-Binding-ID to pass > > along all TBIDs from the previous request instead of just one. This > > would only work if there was a single chain of redirects from TC1 all > > the way to TP4. Once TP4 receives this TokenBindingMessage with > > TBID1, TBID2, TBID3, and TBID4 (and verifies all of them), it could > > issue a token that is bound to all of them, and then TC1 iterates > > through the bound TBIDs to find one that it recognizes. > > I was toying with a similar idea and it seemed to me that the set of TBIDs > conveyed in the TBMSG to whatever server could possibly grow unbounded... > > This won't grow more than whatever the browser's redirect limit is (in Chrome this is 20), since this would only apply for a single chain of redirects. --001a1147881087f9ab052f335435 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T= ue, Mar 29, 2016 at 8:46 AM, =3DJeffH <span dir=3D"ltr"><<a href=3D"mail= to:Jeff.Hodges@kingsmountain.com" target=3D"_blank">Jeff.Hodges@kingsmounta= in.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class= =3D"">On Friday, March 25, 2016 at 8:33 PM, Nick wrote:</span><span class= =3D""><br> > One such change could be for Include-Referer-Token-Binding-ID to pass<= br> > along all TBIDs from the previous request instead of just one. This<br= > > would only work if there was a single chain of redirects from TC1 all<= br> > the way to TP4. Once TP4 receives this TokenBindingMessage with<br> > TBID1, TBID2, TBID3, and TBID4 (and verifies all of them), it could<br= > > issue a token that is bound to all of them, and then TC1 iterates<br> > through the bound TBIDs to find one that it recognizes.<br> <br></span> I was toying with a similar idea and it seemed to me that the set of TBIDs<= br> conveyed in the TBMSG to whatever server could possibly grow unbounded...<b= r> <br></blockquote><div>This won't grow more than whatever the browser= 9;s redirect limit is (in Chrome this is 20), since this would only apply f= or a single chain of redirects.</div></div></div></div> --001a1147881087f9ab052f335435-- From nobody Tue Mar 29 12:14:41 2016 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 B8DEE12E03D for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 12:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 PqbnB3q7eOap for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 12:14:35 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 1EDFA12E03C for <unbearable@ietf.org>; Tue, 29 Mar 2016 11:41:34 -0700 (PDT) Received: (qmail 29654 invoked by uid 0); 29 Mar 2016 18:41:31 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy10.mail.unifiedlayer.com with SMTP; 29 Mar 2016 18:41:31 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id c1hR1s01K2UhLwi011hUZg; Tue, 29 Mar 2016 19:41:28 -0600 X-Authority-Analysis: v=2.1 cv=Maz/5fPf c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=o2b0UYOfsoIA:10 a=7OsogOcEt9IA:10 a=NEAV23lmAAAA:8 a=4fsyLvQknkEkmXlbpfwA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=I1Uf7mAGSqRgZgHyYXuQkniqmq+23yPX5GWa6R0s4OI=; b=fs06ew65vV6aL7/u9VDXp0NsPf vqGr0YooYt8uHRHe7gqh41fgv47hl5y0lxHvRzAvQhf0KQo6bUckI461D33wjjbCGbKDiRuST7jDi YXEbMCVUfx/35S7xd6ulafEwx; Received: from [70.197.5.62] (port=2407 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1akyZu-0004QY-3l; Tue, 29 Mar 2016 12:41:22 -0600 To: IETF Tokbind WG <unbearable@ietf.org> From: =JeffH <Jeff.Hodges@KingsMountain.com> Message-ID: <56FACC4C.7090607@KingsMountain.com> Date: Tue, 29 Mar 2016 11:41:16 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.197.5.62 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/AS8XerZhlZ9azTFsJywt92tSftY> Subject: Re: [Unbearable] -tokbind-protocol-04: verifying signature(s) in TokenBindingMessage.TokenBinding? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 29 Mar 2016 19:14:40 -0000 on Fri, 4 Mar 2016 16:49:14, Andrei replied.. >> ... TBPROTO is already tiptoe'g into the "multiple communicating >> parties" morass (aka "federation"). > It did, with the goal of defining all the Token Binding types we > currently know of in one document. > >> ... then maybe that TB type ought to be defined and IANA-regisgtered >> in -tokbind-https -- in that way it seems all mention of the "referred" >> TB concept can be excised from TBPROTO. > > My preference is to do this, if I have to, rather than bringing more > federation language into TBROTO. OK, and I note that you added this comment to PR#16.. <https://github.com/TokenBinding/Internet-Drafts/pull/16#issuecomment-201360367> ..which says.. > I feel that the detailed discussion of the various TB types and their > interaction belongs in the HTTPSTB (and potentially, other documents that > describe the use of TB with various application protocols). My thinking > is that multiple federation schemes exist (even within the HTTP protocol > alone), so hard-coding this in TBPROTO may limit future use of the TB > protocol. To which I agree. =JeffH From nobody Tue Mar 29 12:27:53 2016 Return-Path: <leifj@sunet.se> 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 6102E12E1FA for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 12:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sunet.se 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 AC9Pt0G5VRjj for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 12:27:50 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 283E212DCB3 for <unbearable@ietf.org>; Tue, 29 Mar 2016 11:53:57 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id u2TIrtQd000394 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <unbearable@ietf.org>; Tue, 29 Mar 2016 20:53:55 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id u2TIrpqJ005925 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for <unbearable@ietf.org>; Tue, 29 Mar 2016 20:53:54 +0200 (CEST) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1459277634; bh=Y++E0sNqps6eSKrZp/5snx1aJNBM090I3e4zZfFwDbU=; h=Subject:To:References:From:Date:In-Reply-To; b=BGh0v4yVuXX+mcZ8PFSMKrVc1GoaCXK4tRUG1FJ+2Q58i+5Jb6h9YaAW+7wB9zDSZ 6KOtEcT1d94bojV0k+zB98FrmPC/rtDJvSEFxON+x3/gyYWFHsCpfAXxP1Oiz4FFeY 08T3Anvp64e3CUwFYrl4DSeYZBWPT8AX6aXNLLPE= X-Footer: c3VuZXQuc2U= Received: from [10.0.0.109] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 9.0.1) with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)) for unbearable@ietf.org; Tue, 29 Mar 2016 20:53:49 +0200 To: unbearable@ietf.org References: <56FAA372.1000400@KingsMountain.com> From: Leif Johansson <leifj@sunet.se> Message-ID: <56FACF3D.1010501@sunet.se> Date: Tue, 29 Mar 2016 20:53:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56FAA372.1000400@KingsMountain.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09QzSRTal - d96d0eb7ae6b - 20160329 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=<leifj@sunet.se>; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/1dViooVIfYOX86_-uK5JSLQZ6aQ> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 29 Mar 2016 19:27:53 -0000 > It would be good to have someone(s) familiar with actual fed deployments > weigh in tho, e.g. our erstwhile co-chairs :) Jeff just posted to the refeds list (excellent idea Jeff) where there are lots of folks similarly afflicted - lets see what that yields! Cheers Leif From nobody Tue Mar 29 14:00:53 2016 Return-Path: <balfanz@google.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 0DCE112D50C for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 14:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 oa0AznJmGAgl for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 14:00:50 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06A712E04D for <unbearable@ietf.org>; Tue, 29 Mar 2016 13:31:16 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id 191so65584931wmq.0 for <unbearable@ietf.org>; Tue, 29 Mar 2016 13:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ruUb7Uxavl9rezsK/8Nd530DGG4jMb4qojxuB6r+Io0=; b=HZ+91Krmjv2eeQjloeEbhtv1g9AGSIQu3oXSdN+3wFkBkW4zkNpugDxDL+/0ER1eFU XTVX/hQG2B3UEAedNfqipjnrBq9Dt4FhDYRwPxJ7rCnPqg451zavE5yRxAZISnfoS0dz 9ggwGP8oyaPI9qFjPwAYHOlq5jCLGKtNlU5c68jP8DSZ+2qbHsYC0NsxQp1VKLh02N3u cUaQDV9IupxgWnGmx5UNSgsNobCdA2ai1nNQ7xeu+tYQeXEFlbZMX34iAnVbQWnRa+Uo LZIB1nHBtCx+kco3MZrSs1V5FYkL+tOA8MFen4TeYpPbcutUH0pCmt2LR7TKgunfr0Ya vqCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ruUb7Uxavl9rezsK/8Nd530DGG4jMb4qojxuB6r+Io0=; b=S2FqtTlxj4qCmV2s1Zv3TtBOXXe9xtQ4ZITrOxxdtM0mMsUrcweOn1vAJPUSD+J/xE kEJa9W6mAKLsssFbC+nq0CN2hkonM5Ci9w67o2YkjKRb2+ItRbS8SSRZbCA33Ct44PHU UtrXgx7Wvb79QH+XFgiQq1pqMcIhk4HfpUIO6yfFvoFlRCd3E8c5Ez2uUA83zujNO9FI Qft9I2o1FjVs1cdSZO98FDUHI/2IUuY9Oyb/MzJTiuMQs1afIPhxvfEnj6XGS3MZ1wrg Ljr3jJH3npV++8wJp4n/93Rlsl/RfOmpDybz6RxKgrdy5RQBFgDyCiuznBAjPWdY49rE C0vw== X-Gm-Message-State: AD7BkJL4VlT8AwdABFH2CId77TIui4ffL00TrkmzAsNwA2tuVHaiQCU0OSHazg24I+Ch1n9pytH+6HonLQox7c84 X-Received: by 10.28.22.213 with SMTP id 204mr19449049wmw.12.1459283475267; Tue, 29 Mar 2016 13:31:15 -0700 (PDT) MIME-Version: 1.0 References: <56FAA372.1000400@KingsMountain.com> <56FACF3D.1010501@sunet.se> In-Reply-To: <56FACF3D.1010501@sunet.se> From: Dirk Balfanz <balfanz@google.com> Date: Tue, 29 Mar 2016 20:31:03 +0000 Message-ID: <CADHfa2CeC+9D+L-PRE1VHMmKVjv3L41zPJxrhZuT_oc4VuZXCw@mail.gmail.com> To: Leif Johansson <leifj@sunet.se>, unbearable@ietf.org Content-Type: multipart/alternative; boundary=001a114712fc2be238052f35e930 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/nwOQdRklWUEXNDBg-swvE_U_10U> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 29 Mar 2016 21:00:52 -0000 --001a114712fc2be238052f35e930 Content-Type: text/plain; charset=UTF-8 What's refeds, and how do I join that mailing list? Dirk. On Tue, Mar 29, 2016 at 12:27 PM Leif Johansson <leifj@sunet.se> wrote: > > > It would be good to have someone(s) familiar with actual fed deployments > > weigh in tho, e.g. our erstwhile co-chairs :) > > Jeff just posted to the refeds list (excellent idea Jeff) where there > are lots of folks similarly afflicted - lets see what that yields! > > Cheers Leif > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a114712fc2be238052f35e930 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div style=3D"white-space:pre-wrap">What's refeds, and how do I join th= at mailing list?<br><br>Dirk. </div><br><div class=3D"gmail_quote"><div dir= =3D"ltr">On Tue, Mar 29, 2016 at 12:27 PM Leif Johansson <<a href=3D"mai= lto:leifj@sunet.se" target=3D"_blank">leifj@sunet.se</a>> wrote:<br></di= v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 1px #ccc solid;padding-left:1ex"><br> > It would be good to have someone(s) familiar with actual fed deploymen= ts<br> > weigh in tho, e.g. our erstwhile co-chairs :)<br> <br> Jeff just posted to the refeds list (excellent idea Jeff) where there<br> are lots of folks similarly afflicted - lets see what that yields!<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers Leif<br> <br> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> </blockquote></div> --001a114712fc2be238052f35e930-- From nobody Tue Mar 29 14:51:15 2016 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 49EBC12D51D for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 14:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 teL0xmowXevX for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 14:51:08 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 6A24F12D1E4 for <unbearable@ietf.org>; Tue, 29 Mar 2016 14:51:08 -0700 (PDT) Received: (qmail 27375 invoked by uid 0); 29 Mar 2016 21:51:08 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy8.mail.unifiedlayer.com with SMTP; 29 Mar 2016 21:51:08 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id c4r21s0022UhLwi014r5Ln; Tue, 29 Mar 2016 22:51:05 -0600 X-Authority-Analysis: v=2.1 cv=Maz/5fPf c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=o2b0UYOfsoIA:10 a=7OsogOcEt9IA:10 a=vYQutmE6AAAA:8 a=t65BHY51txpMIgfdxiYA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=iMnIKnUSzn4Sy0X8lAvlYPvwdu6yn0XsHZBIMHFIlKg=; b=lwbfL4PBRVtJ56VeEOTpZbFe8H mizEwEkZZp9RfjA45CKG8rM3zkPPir5wPbRtUS02Qm47P2xYmowR8jiQbxAPkPW/Tp7rKHSMx0JTL jF7Cq7eC4u4J9MM1p6Ffkjy+v; Received: from [70.197.5.62] (port=2414 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1al1XU-00027a-SV; Tue, 29 Mar 2016 15:51:05 -0600 To: IETF Tokbind WG <unbearable@ietf.org>, Dirk Balfanz <balfanz@google.com> From: =JeffH <Jeff.Hodges@KingsMountain.com> Message-ID: <56FAF8C4.60206@KingsMountain.com> Date: Tue, 29 Mar 2016 14:51:00 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.197.5.62 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/uFDA7QX0A5IxRuqQr3_FATwmFNw> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 29 Mar 2016 21:51:14 -0000 On 3/29/16, 11:53 AM, <leifj@sunet.se> wrote: > >> It would be good to have someone(s) familiar with actual fed deployments >> weigh in tho, e.g. our erstwhile co-chairs :) > >Jeff just posted to the refeds list (excellent idea Jeff) where there >are lots of folks similarly afflicted - lets see what that yields! Dirk replied.. > > What's refeds, and how do I join that mailing list? List-subscribe: <mailto:sympa@lists.refeds.org?subject=subscribe%20refeds> (a moderator has to approve it) archives: https://lists.refeds.org/sympa From nobody Tue Mar 29 14:58:27 2016 Return-Path: <leifj@sunet.se> 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 F0B2412D834 for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 14:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sunet.se 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 Bdsq4x2O-Afz for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 14:58:24 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 2D6CC12D519 for <unbearable@ietf.org>; Tue, 29 Mar 2016 14:58:23 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id u2TLwKBP019683 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Mar 2016 23:58:21 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.7) with ESMTP id u2TLwHHC021429 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Mar 2016 23:58:20 +0200 (CEST) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1459288700; bh=Ig3snjckwJpC2rVP1VUdOS20J7JtUoTMk7GLgED2wR0=; h=Subject:To:References:From:Date:In-Reply-To; b=7SuCyVm2kqeYUSRVIWzWNcAu0+tiOaH0b+ee5RYAyWUqoFQt127vQ1H/A+qlJ6jK8 WnpqlmHWbEyqeDZkkmrEMla2y6mqnsfp1NSJjOqTJeHPQlbF6/H2GFRj9MZCvth1qU tL0SbNYvj68KRVzz1TVSt2GkOAbh8mbnwAQ98xq8= X-Footer: c3VuZXQuc2U= Received: from [10.0.0.109] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 9.0.1) with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)); Tue, 29 Mar 2016 23:58:15 +0200 To: Dirk Balfanz <balfanz@google.com>, unbearable@ietf.org References: <56FAA372.1000400@KingsMountain.com> <56FACF3D.1010501@sunet.se> <CADHfa2CeC+9D+L-PRE1VHMmKVjv3L41zPJxrhZuT_oc4VuZXCw@mail.gmail.com> From: Leif Johansson <leifj@sunet.se> Message-ID: <56FAFA77.9010700@sunet.se> Date: Tue, 29 Mar 2016 23:58:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <CADHfa2CeC+9D+L-PRE1VHMmKVjv3L41zPJxrhZuT_oc4VuZXCw@mail.gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09QzVWlqr - 81757ca67ac9 - 20160329 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=<leifj@sunet.se>; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/fwhx-itlV_WXY_dcx2SUCdTZuIs> Subject: Re: [Unbearable] Referred token binding IDs X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 29 Mar 2016 21:58:27 -0000 On 2016-03-29 22:31, Dirk Balfanz wrote: > What's refeds, and how do I join that mailing list? > https://refeds.org/ - is a community of (mainly) R&E federation operators and global research infrastructure operators (think CERN, ESS etc) mostly talking about global deployment and policy issues list info page: https://lists.refeds.org/sympa/info/refeds > Dirk. > > On Tue, Mar 29, 2016 at 12:27 PM Leif Johansson <leifj@sunet.se > <mailto:leifj@sunet.se>> wrote: > > > > It would be good to have someone(s) familiar with actual fed > deployments > > weigh in tho, e.g. our erstwhile co-chairs :) > > Jeff just posted to the refeds list (excellent idea Jeff) where there > are lots of folks similarly afflicted - lets see what that yields! > > Cheers Leif > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org <mailto:Unbearable@ietf.org> > https://www.ietf.org/mailman/listinfo/unbearable > From nobody Tue Mar 29 16:18:33 2016 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 4B96512DB34 for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 16:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 kyvt26ooJxw4 for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 16:18:28 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 006EF12DB20 for <unbearable@ietf.org>; Tue, 29 Mar 2016 16:18:11 -0700 (PDT) Received: (qmail 23125 invoked by uid 0); 29 Mar 2016 23:18:06 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 29 Mar 2016 23:18:06 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id bzJ11s00d2UhLwi01zJ4RB; Tue, 29 Mar 2016 17:18:05 -0600 X-Authority-Analysis: v=2.1 cv=G/WPTbU5 c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=o2b0UYOfsoIA:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=W5g5cZ0s97Z1i8mcFz0A:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=yJFBW7fOQhEgLC1TRNCSwiDulze8S44ipEHt4bWlWvE=; b=uR7QDPT7diLeXko16mCVs5NMxA 4H+Dl2fyHlbdHkQR4Ef2RLdtMnJdIb//XvWOL1Ry6PNNqM7aLviAn/iJDikQkRcTxofjB3DvR1ggw uAb6ezxkcf4gp65xzfsJiBDqv; Received: from [70.197.5.62] (port=3886 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1al2te-0006r7-EH for unbearable@ietf.org; Tue, 29 Mar 2016 17:18:02 -0600 To: IETF Tokbind WG <unbearable@ietf.org> From: =JeffH <Jeff.Hodges@KingsMountain.com> Message-ID: <56FB0D23.1060802@KingsMountain.com> Date: Tue, 29 Mar 2016 16:17:55 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.197.5.62 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/51UxbuFQhaQy7y8QpgEHQoIOdpY> Subject: [Unbearable] PR #19 HTTPSTB: IANA Considerations and updated HTTP/1.1 reference X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 29 Mar 2016 23:18:31 -0000 One needs to register new HTTP header fields with IANA per https://tools.ietf.org/html/rfc3864, so IANA considerations section duly created. Also, HTTP/1.1 is now spec'd by RFC7230 et al, thus duly updated appropriate refs. Also, RFC7230 revised the style for defining header fields -- that style is applied here. In any case, the prior style was somewhat incorrect in that it was using ABNF conventions from the email world rather than HTTP conventions -- e.g., [CFWS] is not used in specifying HTTP header fields. HTH, =JeffH From nobody Tue Mar 29 16:29:43 2016 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 2575812D575 for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 16:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 R_Fzw-gfEQvt for <unbearable@ietfa.amsl.com>; Tue, 29 Mar 2016 16:29:38 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 54D1712D53F for <unbearable@ietf.org>; Tue, 29 Mar 2016 16:29:38 -0700 (PDT) Received: (qmail 22094 invoked by uid 0); 29 Mar 2016 23:29:37 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy7.mail.unifiedlayer.com with SMTP; 29 Mar 2016 23:29:37 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id bzVX1s00W2UhLwi01zVai5; Tue, 29 Mar 2016 17:29:37 -0600 X-Authority-Analysis: v=2.1 cv=aJ5j99Nm c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=o2b0UYOfsoIA:10 a=7OsogOcEt9IA:10 a=NEAV23lmAAAA:8 a=48vgC7mUAAAA:8 a=W5g5cZ0s97Z1i8mcFz0A:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:To:Subject:From; bh=Vg4bYw8whwcJ8DYenBEjfsAJy5d6DDCdORiuDYK5sHc=; b=R/rK9QPEF5a3z+sVKZ8om+9LI2 clggWwY0JxXhjC9T9bEqTgrb+D4oRvkTworbmsNQ15Pnz80YLWpXirlLI39UxpQu58rDQlkaVSZP0 jLEqx+6uqEb+tRyCAzoWtZj8T; Received: from [70.197.5.62] (port=2403 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1al34l-0007oa-34 for unbearable@ietf.org; Tue, 29 Mar 2016 17:29:31 -0600 From: =JeffH <Jeff.Hodges@KingsMountain.com> To: IETF Tokbind WG <unbearable@ietf.org> Message-ID: <56FB0FD3.4040307@KingsMountain.com> Date: Tue, 29 Mar 2016 16:29:23 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.197.5.62 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/evXtRLbX96-c4LOMlm3MSGy6nFA> Subject: Re: [Unbearable] PR #19 HTTPSTB: IANA Considerations and updated HTTP/1.1 reference X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 29 Mar 2016 23:29:40 -0000 this time with the link: https://github.com/TokenBinding/Internet-Drafts/pull/19 One needs to register new HTTP header fields with IANA per https://tools.ietf.org/html/rfc3864, so IANA considerations section duly created. Also, HTTP/1.1 is now spec'd by RFC7230 et al, thus duly updated appropriate refs. Also, RFC7230 revised the style for defining header fields -- that style is applied here. In any case, the prior style was somewhat incorrect in that it was using ABNF conventions from the email world rather than HTTP conventions -- e.g., [CFWS] is not used in specifying HTTP header fields. HTH, =JeffH From nobody Wed Mar 30 16:56:51 2016 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 6B27012D19E for <unbearable@ietfa.amsl.com>; Wed, 30 Mar 2016 16:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 Ub3d-MK3Mgzg for <unbearable@ietfa.amsl.com>; Wed, 30 Mar 2016 16:56:47 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 7F54E12D13F for <unbearable@ietf.org>; Wed, 30 Mar 2016 16:56:47 -0700 (PDT) Received: (qmail 21342 invoked by uid 0); 30 Mar 2016 23:56:39 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy7.mail.unifiedlayer.com with SMTP; 30 Mar 2016 23:56:39 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id cPwS1s00l2UhLwi01PwV21; Wed, 30 Mar 2016 17:56:39 -0600 X-Authority-Analysis: v=2.1 cv=aJ5j99Nm c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=NVXU01xkMoJQG6FTBRwA:9 a=3mnUp16EWE8PfAA7:21 a=bbxxBN8KpAaIueyr:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:To:Subject:From:Cc; bh=RulZDKaMnuR2CVS8EBPCKCXSD87CqjNOCKrAI/Oj0b8=; b=hIvi/lyZ84Aajz2mb/23pfoVnL W8AvMfnSzWi0t66UcCVxsfJ/j2oW9CnCjvqSimVXdaGooIAhrcf3exVz9QLrfsw0krGscMShCweBr e2X5ugFwifgpHMBv+tVwuAAba; Received: from [73.202.80.238] (port=44558 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1alPyM-0002Zs-Pf; Wed, 30 Mar 2016 17:56:26 -0600 From: =JeffH <Jeff.Hodges@KingsMountain.com> To: Amos Jeffries <squid3@treenet.co.nz> Message-ID: <56FC67A4.5020000@KingsMountain.com> Date: Wed, 30 Mar 2016 16:56:20 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/HVvhfV8bxSBFAzpXIfGASdh3DRE> Cc: IETF Tokbind WG <unbearable@ietf.org> Subject: Re: [Unbearable] draft-ietf-tokbind-https-03 BCP90 compliance (was Sec- prefix for Token-Binding headers) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 30 Mar 2016 23:56:50 -0000 Hi Amos, thanks for your review.. On 3/21/16, 11:08 PM, "Unbearable on behalf of Amos Jeffries" <unbearable-bounces@ietf.org on behalf of squid3@treenet.co.nz> wrote: >On 22/03/2016 4:43 p.m., Dirk Balfanz wrote: >> Hi Jeff, >> >> I was told that in Yokohama it was decided to add the Sec- prefix >>again. (I >> wasn't at that meeting.) >> > >Note that HTTP (RFC 7231 section 8.2.1) header naming requirements state: >"Authors of specifications defining new fields are advised to keep the >name as short as practical" > >HTTP also does not define anything like namespaces within header names. >So "Sec-" has no meaning according to HTTP. If there is a document >defining such a namespace that means "Sec-" needs to be added in >violation of the "short as practical" consideration, then it should be >referenced for context in section 2. agreed overall. PR#19 <https://github.com/TokenBinding/Internet-Drafts/pull/19> has fixes (more or less) for most all of the above comments, corrects various superseded references, and adds a couple new ones. >This has prompted me to take a look at this draft in regards to the HTTP >requirements. I'm afraid to report that its in rather bad state in >respect to BCP 90 compliance. <http://tools.ietf.org/html/bcp90> thanks for again for reviewing. >* Sec-Token-Binding does have section 2 to itself, but is still lacking >mention of many of the semantic details required by BCP 90 section 4. > >I did see some details spread out elswhere around the draft, so its >likely they are mostly there somewhere. But they should be a far more >coherent set of semantic statements for HTTP implementers just wanting >to ensure the header is handled correctly by the HTTP layer without >caring about any Token Binding or TLS layer logics. > > >* Include-Referer-Token-Binding-ID semantics are buried in section 3.3 > >This may also be an overly-long header name in respect to the above >mentioned RFC7231 requirement about header naming. > >IMO the header should have a section 2.x to itself outlining explicitly >and clearly the details required by BCP 90 section 4. > >The document structure something along the lines of: > Section 2 HTTP Headers > Section 2.1 The Sec-Token-Binding Header > Section 2.2 The Include-Referer-Token-Binding-ID Header > Section 3 First Party Use Cases > ... > Section 4 Federation Use Cases > ... I tend to agree that the spec's overall structure could be re-crafted more along those lines, for example as is done in <https://tools.ietf.org/html/rfc6797>. What do others think? >* complete lack of "IANA considerations" section for header registry >templates. this is (nominally) addressed in PR#19. >Editorial Issues: > >* section 1 states that the draft covers both first-party and federated >use cases. But there is only section 3 outlining federated cases. No >clearly visible section for the first-party use case. > > >* in section 3.1 it says "the Sec-Token-Binding HTTP header defined >above". > >Should that not be an explicit "section 2" (2.1?) reference instead of >the word "above" ? > > >* in section 4.2 "manterial" -> material > >* in section 4.3 paragraph 4 it says "A client shouldn't be tricked into >sending a Sec-Token-Binding header to a server that" > >That specific wording is just telling malicious actors "dont be bad". >Which is useless. Surely it should be saying to clients not to let >themselves be tricked. > > >* I spy several lower-case "must", "must not", "should", "should not" >and "may" dotted around the document. Are those normative requirements >or just confusing wording? > > >* please pick a consistent formula for the Security Considerations and >Privacy Consuderations entries before this goes to LC. > >Right now there is a mix of conceptual orderings: > - problem, solution requirements > - requirements, problem, solution requirements > - problem, detailed examples, requirements > - problem, detailed examples, some requirements, detailed examples, >more requirements > >If one wants to skip the rather dense explanatinos and details of >attacks and just check that the requirements are met its quite hard to >see what those actually are. > I suggest sticking with problem and requirements in quick prefix >paragraphs, _then_ details and examples (if necessary). I tend to agree that the above items are things the co-authors should consider addressing in order to editorially improve the spec. thanks, =JeffH From nobody Wed Mar 30 20:59:35 2016 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 313DA12D936 for <unbearable@ietfa.amsl.com>; Wed, 30 Mar 2016 20:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 UTw6mI0PDN6c for <unbearable@ietfa.amsl.com>; Wed, 30 Mar 2016 20:59:30 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id A842A12D1D8 for <unbearable@ietf.org>; Wed, 30 Mar 2016 20:59:30 -0700 (PDT) Received: (qmail 24147 invoked by uid 0); 31 Mar 2016 03:59:19 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy10.mail.unifiedlayer.com with SMTP; 31 Mar 2016 03:59:19 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id cazC1s00U2UhLwi01azFji; Thu, 31 Mar 2016 04:59:16 -0600 X-Authority-Analysis: v=2.1 cv=Maz/5fPf c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=kgoENrvEAAAA:8 a=wAuzTQcncn8kZzWXbDsA:9 a=wVdvdK45c-QwJhTr:21 a=XHyipm4t_Wdf4Etj:21 a=QEXdDO2ut3YA:10 a=NHPXY76ssuoA:10 a=d1oxt6aRJawA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=kP2NrKrKg1EDn0qRpb6L/IlZbvDI78Px/NavRJlCTy8=; b=JOGCX6j7s7wNT1f27LEV2DL/xc LYO8m48N9JEZPg/z9Eme//QCMuGvPYsWbEPV+My7YYDDaTiJAyvmF6mXZ6PK1QPX+rVcNWcQwF9xi yvpxxRL8htqxU5nahwwMGZXvy; Received: from [73.202.80.238] (port=47257 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1alTlL-0006b5-FV for unbearable@ietf.org; Wed, 30 Mar 2016 21:59:15 -0600 To: IETF Tokbind WG <unbearable@ietf.org> From: =JeffH <Jeff.Hodges@KingsMountain.com> Message-ID: <56FCA08D.3010407@KingsMountain.com> Date: Wed, 30 Mar 2016 20:59:09 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/xyqW5vOAfiiWmzNPKTH0uTZiT_E> Subject: [Unbearable] comments on -tokbind-protocol-05 aka TBPROTO X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 03:59:34 -0000 review comments on -tokbind-protocol-05 aka TBPROTO: Substantive comments: S1. need to migrate the referred_token_binding type and its IANA registration over to -tokbind-https aka HTTPSTB. see.. Re: [Unbearable] -tokbind-protocol-04: verifying signature(s) in TokenBindingMessage.TokenBinding? <https://www.ietf.org/mail-archive/web/unbearable/current/msg00470.html> As part of this, we may want to explicitly state that defining the semantics of TokenBindingMessages containing more than one provided TokenBinding, as well as allocating new TokenBindingType value(s), is left to applications. S2. TBPROTO focuses on the server side binding TBIDs to "security tokens". However, there are occasions in some protocols/apps where the client side is obliged to bind objects to the TLS layer. See for example <http://w3c.github.io/webauthn/#sec-client-data>. TBPROTO should more clearly explain that either the client or server side may bind TBIDs into objects (tokens, messages, whatever) and either side may be obliged to validate such objects, depending on application use case(s). S3. It seems that TBPROTO intends to be a general purpose app-layer means for generating and agreeing on TBIDs, i.e., it is not just for HTTP; it seems to serve the purpose of mitigating the need for different app-layers to re-invent such a mechanism on their own. In doing so, it arguably is acting as general-purpose packaging of the TLS keying material exporter, and insulating other app-layer designers from the vagaries described in the last parag of the sec cons in RFC5705.. Designing a secure mechanism that uses exporters is not necessarily straightforward. This document only provides the exporter mechanism, but the problem of agreeing on the surrounding context and the meaning of the information passed to and from the exporter remains. Any new uses of the exporter mechanism should be subject to careful review. If so, this should be stated more explicitly in TBPROTO. S5. Should TBPROTO have a "Required Application Programming Interfaces" section similar to that in RFC5929 [1] ? S6a. How TBIDs are "reset" is not described. Presumably, this is accomplished by the client allocating a new key pair for a server, resigning EKM, and including the new values in the "next" TokenBindingMessage sent to the server, and servers need to be vigilant about noticing new TBIDs and re-binding application security tokens/messages as appropriate, yes? S6b. Our Security AD verbally expressed to some of us (at IETF-94?) that simply saying "TBIDs can be reset by the user at any time" is insufficient guidance to app-layer designers regarding a privacy-preserving utilization of TBPROTO. What else might be added? Perhaps suggestion(s) that the app-layer periodically auto-reset TBIDs? S7. Section 6 Security Token Validation specifies conditions (eg incorrect TBID) upon which the server "MUST discard the token". Are there not a range of application behaviors that might occur, e.g., terminating the application session? Or, is this particular behavior defined in order to accommodate resetting of TBIDs by the client-side whereupon there may be a race condition before all the server-issued bound app sec tokens contain the updated TBID? Is this behavior appropriate for all apps in all cases? what if an incorrect bound TBID is being caused by a MITM? S8. Section 8.2 Security Token Replay is fairly light on details regarding how an application layer can utilize TBPROTO to detect MITM attacks, perhaps appropriately generalizing and including the 2nd parag from [2] would help readers better understand how this would work? S9. I would not say "TLS Token Binding IDs are never transmitted in clear text.." -- this could easily occur in an HTTP-based web app that inadvertently leaks cookies, e.g. by retrieving some image over plain http. addressing this implies adding sec cons wrt such risks, eg "apps need to take precautions to ensure bound sec tokens/messages are not 'leaked' over insecure connections such as can occur due to non-https link(s) lurking in a web app, e.g., an image load. HTTP-based applications should employ techniques such as HSTS and HPKP in order to guard against such situations." S10. I would remove the triple-handshake admonition in section 4, and perhaps the one in sec cons, but in any case add to sec cons that there are important sec cons regarding the underlying TLS connection in [I-D.ietf-tokbind-negotiation] that could mitigate the app-layer's TB-based security benefits if they are not heeded. S11. Regarding the design decision: TokenBindingType is not within TokenBindingID -- it is within the enclosing TokenBinding because TokenBindingIDs (TBIDs) may be conveyed in TBMSG as either provided_ or some other app-layer-defined TBType. If the app-layer has defined additional TBType(s), the server-side would want to remember each TBID's type, yes? S12. Perhaps spec should stipulate "server must ignore TBTypes it does not understand" -- or not? [1] https://tools.ietf.org/html/rfc5929#section-7 [2] <https://tools.ietf.org/html/draft-ietf-tokbind-https-02#section-4.4> Overall editorial issues/comments (in no particular order): E1. the mechanics of verifying the signature(s) in a TokenBindingMessage are not spec'd in detail -- experienced crypto folk may know what to do, but others may not. E2. ought to clearly delineate "server processing model" and "client processing model". (e.g. see https://tools.ietf.org/html/rfc6797) E3. section "1. Introduction" and section "2. token binding protocol overview" are quite similar -- perhaps they could be combined? E4. If section 3 and 4 are massaged per E2, section 5 becomes superfluous (it seemed to in my experimenting). E4. the security considerations section contains RFC2119 requirements language -- some downstream reviews may frown on this. E5. TBPROTO in and of itself does not "prevent" export and replay of app security tokens -- rather it facilitates detection of such occurances. E6. Terminology is fairly loose, e.g. terms such as "token", "security token", "bound token", "bound security token" are not used as consistently as they could be. E7. Various spec portions could benefit from further wordsmithing -- suggestions are inline below... <snip> > The Token Binding Protocol Version 1.0 > draft-ietf-tokbind-protocol-05 > <snip> > > 1. Introduction > > Servers generate various security tokens (e.g. HTTP cookies, OAuth > tokens) for applications to access protected resources. Any party in > possession of such token gains access to the protected resource. > Attackers export bearer tokens from the user's machine, present them > to the servers, and impersonate authenticated users. The idea of > Token Binding is to prevent such attacks by cryptographically binding > security tokens to the TLS layer. > > A TLS Token Binding is established by the user agent generating a s/the user agent/a client-side application (e.g., a user agent)/ > private-public key pair (possibly within a secure hardware module, > such as TPM) per target server, and proving possession of the private > key on every TLS connection to the target server. The proof of > possession involves signing the exported keying material [RFC5705] > for the TLS connection with the private key. The corresponding > public key is included in the TLS Token Binding identifier structure > (described in the "TLS Token Binding ID Format" section of this > document). TLS Token Bindings are long-lived, i.e. they encompass > multiple TLS connections and TLS sessions between a given client and > server. To protect privacy, TLS Token Binding IDs are never > transmitted in clear text and can be reset by the user at any time, > e.g. when clearing browser cookies. > > When issuing a security token to a client that supports TLS Token > Binding, a server includes the client's TLS Token Binding ID in the > token. Later on, when a client presents a security token containing > a TLS Token Binding ID, the server makes sure the ID in the token > matches the ID of the TLS Token Binding established with the client. > In the case of a mismatch, the server discards the token. > > In order to successfully export and replay a bound security token, > the attacker needs to also be able to export the client's private > key, which is hard to do in the case of the key generated in a secure > hardware module. > > 1.1. Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > 2. Token Binding Protocol Overview this section largely duplicates the Introduction -- could the intro be trimmed way down and then this section effectively provides the underlying details that are summarized in the Intro? > > The client and server use the Token Binding Negotiation TLS Extension > [I-D.ietf-tokbind-negotiation] to negotiate the Token Binding > protocol version and the parameters (signature algorithm, length) of > the Token Binding key. This negotiation does not require additional > round-trips. wrt "the parameters (signature algorithm, length)" -- this is now effectively referred to as "key parameters" yes? > The Token Binding protocol consists of one message sent by the client > to the server, proving possession of one or more client-generated > asymmetric keys. This message is only sent if the client and server > agree on the use of the Token Binding protocol and the key > parameters. The Token Binding message is sent with the application > protocol data in TLS application_data records. wrt... "The Token Binding message is sent with the application protocol data in TLS application_data records" ...in other words, after Token Binding negotiation during TLS handshake [I-D.ietf-tokbind-negotiation], the Token Binding msg is created by the client and conveyed to the server in the app layer protocol which is running over TLS within whose context the token binding ID was established. Yes? perhaps re-state. > A server receiving the Token Binding message verifies that the key > parameters in the message match the Token Binding parameters > negotiated via [I-D.ietf-tokbind-negotiation], and then validates the > signatures contained in the Token Binding message. If either of > these checks fails, the server terminates the connection, otherwise > the TLS Token Binding is successfully established with the ID > contained in the Token Binding message. > > When a server supporting the Token Binding protocol receives a bound > token, the server compares the TLS Token Binding ID in the security > token with the TLS Token Binding ID established with the client. If > the bound token came from a TLS connection without a Token Binding, > or if the IDs don't match, the token is discarded. > > This document defines the format of the Token Binding protocol > message, the process of establishing a TLS Token Binding, the format > of the Token Binding ID, and the process of validating a security > token. s/security token/bound security token/ > Token Binding Negotiation TLS Extension > [I-D.ietf-tokbind-negotiation] describes the negotiation of the Token > Binding protocol and key parameters. Token Binding over HTTP > [I-D.ietf-tokbind-https] explains how the Token Binding message is > encapsulated within HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] messages. > [I-D.ietf-tokbind-https] also describes Token Binding between > multiple communicating parties: User Agent, Identity Provider and > Relying Party. > > 3. Token Binding Protocol Message > > The Token Binding message is sent by the client and proves possession > of one or more private keys held by the client. This message MUST be > sent if the client and server successfully negotiated the use of the > Token Binding protocol via [I-D.ietf-tokbind-negotiation], and MUST > NOT be sent otherwise. This message MUST be sent in the client's > first application protocol message. This message MAY also be sent in > subsequent application protocol messages, proving possession of other > keys by the same client, to facilitate token binding between more > than two communicating parties. suggest beginning new parag here.. > Token Binding over HTTP > [I-D.ietf-tokbind-https] specifies the encapsulation of the Token > Binding message in the application protocol messages, and the > scenarios involving more than two communicating parties. The Token > Binding message format is defined using TLS specification language: > > enum { > rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2), (255) > } TokenBindingKeyParameters; add comment on above: /* imported from [I-D.ietf-tokbind-negotiation] */ > > struct { > opaque modulus<1..2^16-1>; > opaque publicexponent<1..2^8-1>; > } RSAPublicKey; > > struct { > opaque point <1..2^8-1>; > } ECPoint; > > enum { > provided_token_binding(0), referred_token_binding(1), (255) > } TokenBindingType; > > struct { > TokenBindingKeyParameters key_parameters; > select (key_parameters) { > case rsa2048_pkcs1.5: > case rsa2048_pss: > RSAPublicKey rsapubkey; > case ecdsap256: > ECPoint point; > } missing a semi-colon, should be: }; > } TokenBindingID; > > enum { > (255) // No initial ExtensionType registrations > } ExtensionType; comments in TLS presentation language are: /* . . . */ see https://tools.ietf.org/html/draft-ietf-tls-tls13#section-4.2 > > struct { > ExtensionType extension_type; > opaque extension_data<0..2^16-1>; > } Extension; > > struct { > TokenBindingType tokenbinding_type; > TokenBindingID tokenbindingid; > opaque signature<0..2^16-1>;// Signature over the exported keying >material value > Extension extensions<0..2^16-1>; > } TokenBinding; > > struct { > TokenBinding tokenbindings<0..2^16-1>; > } TokenBindingMessage; is it legit for a TokenBindingMessage to be an empty sequence as implied by the "tokenbindings<0..2^16-1>" declaration? no, it is not, see last paragraph below in this section. [this sort of inconsistency seems to also exist in RFC5246 so I am doubting it is something to worry about.] The below paragraphs appear to be client-side processing rules, yes? I suggest identifying them as such. > The Token Binding message consists of a series of TokenBinding > structures containing the type of the token binding, the > TokenBindingID, a signature over the exported keying material (EKM) > value, optionally followed by Extension structures. > > This document defines two token binding types: provided_token_binding > used to establish a Token Binding when connecting to a server, and > referred_token_binding used when requesting tokens to be presented to > a different server. Token Binding over HTTP [I-D.ietf-tokbind-https] > describes Token Binding between multiple communicating parties: User > Agent, Identity Provider and Relying Party. See also Section 7.1 > > When an rsa2048_pkcs1.5 or rsa2048_pss key is used, > TokenBinding.signature contains the signature generated using, > respectively, the RSASSA-PKCS1-v1_5 or RSASSA-PSS signature scheme > defined in [RFC3447]. RSAPublicKey.modulus and > RSAPublicKey.publicexponent contain the length-prefixed modulus and > exponent of the RSA public key represented in big-endian format. > > When an ecdsap256 key is used, TokenBinding.signature contains a pair > of integers, R followed by S, as defined in [ANSI.X9-62.2005]. R and > S are encoded in big-endian format. ECPoint.point contains the X > coordinate followed by the Y coordinate. The X and Y coordinates are > unsigned integers encoded in big-endian format. Future > specifications may define Token Binding keys using other elliptic > curves with their corresponding signature and point formats. > > The EKM is obtained using the Keying Material Exporters for TLS > defined in [RFC5705], by supplying the following input values: > > o Label: The ASCII string "EXPORTER-Token-Binding" with no > terminating NUL. > > o Context value: NULL (no application context supplied). > > o Length: 32 bytes. the below 2 parags are essentially server-side processing rules -- fold them into the next section and rename it "server processing model"? > An implementation MUST ignore any unknown extensions. Initially, no > extension types are defined (see Section 7.2). One of the possible > uses of extensions envisioned at the time of this writing is > attestation: cryptographic proof that allows the server to verify > that the Token Binding key is hardware-bound. The definitions of > such Token Binding protocol extensions are outside the scope of this > specification. > > At least one TokenBinding MUST be included in the Token Binding > message. The signature algorithm and key length used in the > TokenBinding MUST match the parameters negotiated via > [I-D.ietf-tokbind-negotiation]. The client SHOULD generate and store > Token Binding keys in a secure manner that prevents key export. In > order to prevent cooperating servers from linking user identities, > different keys SHOULD be used by the client for connections to > different servers, s/cooperating servers/colluding servers/ according to the token scoping rules of the > application protocol. > > 4. Establishing a TLS Token Binding s/Token Binding/Token Binding ID/ this section is written from the perspective of the server side upon receipt of an app layer msg containing a TokenBindingMessage, perhaps be more explicit and have an intro sentence like.. Upon receipt by the server of a client's TokenBindingMessage via the application layer protocol, the server performs these checks: > The triple handshake vulnerability in TLS 1.2 and older TLS versions > affects the security of the Token Binding protocol, as described in > the "Security Considerations" section below. Therefore, the server > MUST NOT negotiate the use of the Token Binding protocol with these > TLS versions, unless the server also negotiates Extended Master > Secret [RFC7627] and Renegotiation Indication [RFC5746] TLS > extensions. the above admonition is TLS-specific and is already addressed in [I-D.ietf-tokbind-negotiation] so remove it? > The server MUST terminate the connection if the use of the Token > Binding protocol was not negotiated, but the client sends the Token > Binding message. s/not negotiated/not negotiated at the TLS layer/ > If the Token Binding type is > "provided_token_binding", the server MUST verify that the signature > algorithm (including elliptic curve in the case of ECDSA) and key > length in the Token Binding message match those negotiated via > [I-D.ietf-tokbind-negotiation]. In the case of a mismatch, the > server MUST terminate the connection. suggest.. OLD: the signature algorithm (including elliptic curve in the case of ECDSA) and key length in the Token Binding message match those NEW: the key parameters value in the Token Binding object match that > As described in > [I-D.ietf-tokbind-https], Token Bindings of type > "referred_token_binding" may have different key parameters than those > negotiated via [I-D.ietf-tokbind-negotiation]. rather than "negotiated via [I-D.ietf-tokbind-negotiation]", you mean "negotiated with this server." -- yes ? suggest: Token Bindings of types other than "provided_token_binding" may have different key parameters than those negotiated for the current provided TLS Token Binding ID. > > If the Token Binding message does not contain at least one > TokenBinding structure, or the signature contained in a TokenBinding > structure is invalid, the server MUST terminate the connection. make the next sentence a new parag: > Otherwise, the TLS Token Binding is successfully established and its > ID can be provided to the application for security token validation. suggested enhancement: Otherwise, the Token Binding IDs for the token binding context between this client and server are successfully established. The TokenBindingID structure(s) are noted by the client application, and they are extracted from the TokenBindingMessage and noted by the server side application. The application may then use the Token Binding IDs for bound security token creation and validation (e.g., as in [I-D.ietf-tokbind-https]), or other application uses as appropriate. given the above, it seems section 5 below seems superfluous to me: > > 5. TLS Token Binding ID Format > > The ID of the TLS Token Binding established as a result of Token > Binding message processing is a binary representation of the > following structure: > > > struct { > TokenBindingKeyParameters key_parameters; > select (key_parameters) { > case rsa2048_pkcs1.5: > case rsa2048_pss: > RSAPublicKey rsapubkey; > case ecdsap256: > ECPoint point; > } > } TokenBindingID; > > > TokenBindingID contains the key parameters negotiated via > [I-D.ietf-tokbind-negotiation]. TLS Token Binding ID can be obtained > from the TokenBinding structure described in the "Token Binding > Protocol Message" section of this document by discarding the token > binding type, signature and extensions. TLS Token Binding ID will be > available at the application layer and used by the server to generate > and verify bound tokens. > 6. Security Token Validation Security Token Binding and Validation > Security tokens can be bound to the TLS layer either by embedding the > Token Binding ID in the token, or by maintaining a database mapping > tokens to Token Binding IDs. The specific method of generating bound > security tokens is application-defined and beyond the scope of this > document. suggested rewrite: In general, application layer security tokens are bound to the underlying TLS connection by either embedding the connection's TokenBindingID within the security token, or by the application maintaining a mapping of security tokens to TokenBindingIDs. The specific method of binding application security tokens to underlying TLS connection(s) is application-defined and beyond the scope of this specification. > Upon receipt of a security token, the server attempts to retrieve TLS > Token Binding ID information from the token and from the TLS > connection with the client. Application-provided policy determines > whether to honor non-bound (bearer) tokens. If the token is bound > and a TLS Token Binding has not been established for the client > connection, the server MUST discard the token. If the TLS Token > Binding ID for the token does not match the TLS Token Binding ID > established for the client connection, the server MUST discard the > token. Upon receipt of a bound security token, the server-side application extracts the TokenBindingID(s) from the bound security token and from the TLS connection with the client. Application-specific policy determines whether to honor unbound (i.e., bearer) security tokens. If the security token is bound and a Token Binding has not been established for the client connection, the server MUST discard the security token. If the TokenBindingID within the token does not match the TokenBindingID established for the client connection, the server MUST discard the token. though: what's the rationale for only discarding tokens and not doing anything further? see S7 above. > > 7. IANA Considerations <snip> > > 8. Security Considerations > > 8.1. Security Token Replay > > The goal of the Token Binding protocol is to prevent attackers from > exporting and replaying security tokens, thereby impersonating > legitimate users and gaining access to protected resources. Bound > tokens can still be replayed by the malware present in the User > Agent. In order to export the token to another machine and > successfully replay it, the attacker also needs to export the > corresponding private key. Token Binding private keys are therefore > high-value assets and SHOULD be strongly protected, ideally by > generating them in a hardware security module that prevents key > export. > > The manner in which a token is bound to the TLS layer is application- > defined and beyond the scope of this document. However, the > resulting bound token needs to be integrity-protected, so that an > attacker cannot remove the binding or substitute a Token Binding ID > of their choice without detection. > > 8.2. Downgrade Attacks > > The Token Binding protocol is only used when negotiated via > [I-D.ietf-tokbind-negotiation] within the TLS handshake. TLS > prevents active attackers from modifying the messages of the TLS > handshake, therefore it is not possible for the attacker to remove or > modify the Token Binding Negotiation TLS Extension used to negotiate > the Token Binding protocol and key parameters. The signature > algorithm and key length used in the TokenBinding of type > "provided_token_binding" MUST match the parameters negotiated via > [I-D.ietf-tokbind-negotiation]. suggest: TLS prevents active attackers from modifying the messages of the TLS handshake, therefore it is not possible for the attacker to remove or modify the Token Binding Negotiation TLS Extension used to negotiate the Token Binding protocol version and key parameters. The key parameters used in TokenBindingMessage.TokenBinding structures of type "provided_token_binding" MUST match the key parameters negotiated via [I-D.ietf-tokbind-negotiation]. > > 8.3. Privacy Considerations > > The Token Binding protocol uses persistent, long-lived TLS Token > Binding IDs. To protect privacy, TLS Token Binding IDs are never > transmitted in clear text and can be reset by the user at any time, > e.g. when clearing browser cookies. Some applications offer a > special privacy mode where they don't store or use tokens supplied by > the server, e.g. "in private" browsing. When operating in this > special privacy mode, applications SHOULD use newly generated Token > Binding keys and delete them when exiting this mode, or else SHOULD > NOT negotiate Token Binding at all. > > In order to prevent cooperating servers from linking user identities, > different keys SHOULD be used by the client for connections to > different servers, according to the token scoping rules of the > application protocol. the above admonition (paragraph) should be up above where generation of the token binding key pair is stipulated. > > A server can use tokens and Token Binding IDs to track clients. > Client applications that automatically limit the lifetime of tokens > to maintain user privacy SHOULD apply the same validity time limits > to Token Binding keys. > <snip> From nobody Thu Mar 31 07:29:01 2016 Return-Path: <balfanz@google.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 2CAFD12D16E for <unbearable@ietfa.amsl.com>; Thu, 31 Mar 2016 07:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 JOoz6KRQoKp4 for <unbearable@ietfa.amsl.com>; Thu, 31 Mar 2016 07:28:58 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F9112D17C for <unbearable@ietf.org>; Thu, 31 Mar 2016 07:28:51 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id 127so136409604wmu.1 for <unbearable@ietf.org>; Thu, 31 Mar 2016 07:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=tFwfvSogpQZ/ukgIZzzSK73OV3zgEi6Nk7rmB6liV0s=; b=Sdg7Rkny23R4HfdIpbN1XN7vVJKnMp0N+8K/YANq5d7gIBxbi1fg0LeoxrAETiNoKI xoV//uPGcgbM3ZO7QVgJ5y5/Btald0sMEx8LC2zQJb5UluosD+dwXJUxEfncE1M7Qb1R fNoy1rYkTr/+UIF4liTjbCM+kBNGihDjgWf5q94SkrfYQjQ2TiD2E/KlA50l3L3G3zCA GkQoBMwDAEmaSIZ6UQGtfqOCyrqFK+kZut7rsLHTdS4Ig7LWuVmmS3BkHV36QnpEreDz xE+38944T/K9d2ZtS2ByDlB6bPy1xCzVQexJb6y3zdhzslFhwt1z8kKwkt3v6J8XX8+c o4Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=tFwfvSogpQZ/ukgIZzzSK73OV3zgEi6Nk7rmB6liV0s=; b=ha2JgSh6k60Bi6z/Re9eIMhdRvdJOwNUnerfo7KtWyStlkmjbvPg/ap9c0TAOdYFNU WKlatQjOF2yDU4IWl/T9r3ermLy2yw2jiZe+1yqf2+kccN6r95zNNGx9bKHI366tq7a7 HrBsQBy/8jB34jrra+kZP5NWtNN0H4xNX4WiWZ8axiCT/xTvd4R3cAJzGCxuAhxaJMHX woD4JkRrPk6QNgD9X26id0EzAZ/lLwwGoiB6qrKSlJp+ENAaTWRbi3tyUmaJXpH4X69G Pnkg80KtAwC3FUXPP8GD7TA8161LwOzqRDeVdWCm2ov2XU6DPeASU4EbYrvFWOSB58oX ShaA== X-Gm-Message-State: AD7BkJL/a3x4hVmTNElTvOkO10ttdmFlW8ApOpJDQDNx+FEh2AaccarSdRrC03Z9N65UoEFvOLN8hL7iqUu/mve8 X-Received: by 10.28.144.20 with SMTP id s20mr5498256wmd.12.1459434530515; Thu, 31 Mar 2016 07:28:50 -0700 (PDT) MIME-Version: 1.0 References: <56FB0FD3.4040307@KingsMountain.com> In-Reply-To: <56FB0FD3.4040307@KingsMountain.com> From: Dirk Balfanz <balfanz@google.com> Date: Thu, 31 Mar 2016 14:28:38 +0000 Message-ID: <CADHfa2Drz988TRAZMH1ipvOdEUnp2OfsA=gfM-m7r_NKWUb3kQ@mail.gmail.com> To: "=JeffH" <Jeff.Hodges@kingsmountain.com>, IETF Tokbind WG <unbearable@ietf.org> Content-Type: multipart/alternative; boundary=001a1146a95cc40e76052f5914ff Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/3qiSSv6l1Isi2v-P0Q2PvlEH2V4> Subject: Re: [Unbearable] PR #19 HTTPSTB: IANA Considerations and updated HTTP/1.1 reference X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 14:29:00 -0000 --001a1146a95cc40e76052f5914ff Content-Type: text/plain; charset=UTF-8 Thanks! Merged. Dirk. On Tue, Mar 29, 2016 at 7:29 PM =JeffH <Jeff.Hodges@kingsmountain.com> wrote: > this time with the link: > https://github.com/TokenBinding/Internet-Drafts/pull/19 > > One needs to register new HTTP header fields with IANA per > https://tools.ietf.org/html/rfc3864, so IANA considerations section duly > created. Also, HTTP/1.1 is now spec'd by RFC7230 et al, thus duly updated > appropriate refs. Also, RFC7230 revised the style for defining header > fields > -- that style is applied here. In any case, the prior style was somewhat > incorrect in that it was using ABNF conventions from the email world rather > than HTTP conventions -- e.g., [CFWS] is not used in specifying HTTP header > fields. > > HTH, > > =JeffH > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a1146a95cc40e76052f5914ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Thanks! Merged.<div><br></div><div>Dirk.</div></div><br><d= iv class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Mar 29, 2016 at 7:29 PM = =3DJeffH <<a href=3D"mailto:Jeff.Hodges@kingsmountain.com">Jeff.Hodges@k= ingsmountain.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">thi= s time with the link:<br> =C2=A0 =C2=A0<a href=3D"https://github.com/TokenBinding/Internet-Drafts/pul= l/19" rel=3D"noreferrer" target=3D"_blank">https://github.com/TokenBinding/= Internet-Drafts/pull/19</a><br> <br> One needs to register new HTTP header fields with IANA per<br> <a href=3D"https://tools.ietf.org/html/rfc3864" rel=3D"noreferrer" target= =3D"_blank">https://tools.ietf.org/html/rfc3864</a>, so IANA considerations= section duly<br> created. Also, HTTP/1.1 is now spec'd by RFC7230 et al, thus duly updat= ed<br> appropriate refs. Also, RFC7230 revised the style for defining header field= s<br> -- that style is applied here. In any case, the prior style was somewhat<br= > incorrect in that it was using ABNF conventions from the email world rather= <br> than HTTP conventions -- e.g., [CFWS] is not used in specifying HTTP header= <br> fields.<br> <br> HTH,<br> <br> =3DJeffH<br> <br> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> </blockquote></div> --001a1146a95cc40e76052f5914ff-- From nobody Thu Mar 31 07:57:29 2016 Return-Path: <balfanz@google.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 4105512D1CF for <unbearable@ietfa.amsl.com>; Thu, 31 Mar 2016 07:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 4_cWxQ3Vy1QT for <unbearable@ietfa.amsl.com>; Thu, 31 Mar 2016 07:57:25 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B615812D18E for <unbearable@ietf.org>; Thu, 31 Mar 2016 07:57:24 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id p65so229013411wmp.1 for <unbearable@ietf.org>; Thu, 31 Mar 2016 07:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=LHBNP075os0heN/rbwTrS0iIHrW1cYt58dgo0+WbiNQ=; b=LIMNlUDeaoLMOb/g6iPbX59sj9pnYCntdN5ryOC1FAGV3ydKAHvCHAY9IJXsnWeGcz YX6RTNN6aMuBczyb5ybUW3jWeVjEoJYU6jjv5/RFrropGvfC8FkEY8+yUgJ3UZ7NwHiN Yruge+s3YVKGE/8R44NFaDF4wSJA9S4EgLSVVefhs031htC1V7eRXMbO53Zo/8wCj326 od0Kv9S8DQM2Jwxc96DBxHXWvFv9Fc+Ov3Wjx79PC44HC6Amt0PoIO3i/fNtkPLr7UT9 /goe7XnjNt0L50PsUwjQ9z4Y0u8PWmPSL1fI37wYqJpWFISqRBlp1GOScnjgrXPCeMsW b/Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=LHBNP075os0heN/rbwTrS0iIHrW1cYt58dgo0+WbiNQ=; b=UYZN0Y7tkwZr4jNqNSiHszVU1JwJqJRv12asTKYs3p5Ki6ZZvM5I//24lbN0PIpWdN THzbiJJsjbJmfwjfMfbcYKGetOj/xScIit2fj1+honBJpjMFlYo71m1Q5C73Ok014cxA h2LpxQAHDuV98J0ru06Ow44A6xoyVICy7Wm6R0Kgpw4OD0gjLhGL6x33Kf841wh3Xi0X kWKpTrOSfnXdGtEr83fLoqQKdOc7lh5MxXIQX0J4t3dOqm4eJgkMcHp7lkwpO6a4fQ65 T4COV0PRGMT8n58upIwkQ2mVPGruHjDX/S9aX0G/r/CpgEd+0eUbwUDfiOQwcngAzzNJ iMPw== X-Gm-Message-State: AD7BkJLKWHyz80hrQeDFDjLz+a3AoPmfaUicueUkC5Xa2djjA3g01ij+RNmSjyOHxhDkPDrl+4zRRZlFfZFy9mSi X-Received: by 10.194.203.5 with SMTP id km5mr4208482wjc.172.1459436242889; Thu, 31 Mar 2016 07:57:22 -0700 (PDT) MIME-Version: 1.0 References: <56F07A95.4050904@KingsMountain.com> <CADHfa2DzJ4UAvjtUPfp0QfeBnR4HbuVy9VRqO15=x7raRKSLAA@mail.gmail.com> <56F0E177.8000706@treenet.co.nz> In-Reply-To: <56F0E177.8000706@treenet.co.nz> From: Dirk Balfanz <balfanz@google.com> Date: Thu, 31 Mar 2016 14:57:13 +0000 Message-ID: <CADHfa2CCobe6FYXytOsOHqJ2+NFaw01muJwTy4-qUw=gefPrPA@mail.gmail.com> To: Amos Jeffries <squid3@treenet.co.nz>, unbearable@ietf.org Content-Type: multipart/alternative; boundary=047d7bae4532d4c6fa052f597a1e Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/Xgi5IJjqRUiMkyCKmiQf3De-gho> Subject: Re: [Unbearable] draft-ietf-tokbind-https-03 BCP90 compliance (was Sec- prefix for Token-Binding headers) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 14:57:27 -0000 --047d7bae4532d4c6fa052f597a1e Content-Type: text/plain; charset=UTF-8 Thanks for the comments. One question: The security/privacy considerations sections are not normative. I was under the impression that it's not within the scope of this spec to tell implementors of browsers what they need to do in order to achieve security and privacy. Rather, the goal of the spec is to say enough to ensure interoperability between clients and servers. It just happens to be the case that prefixing the header name with Sec- is an interoperability specification that also addresses the security issues, so that's a requirement we've put into the normative part of the spec. (Ok, now the actual question:) Can you think of other requirements flowing from the security and privacy sections that should make it into the normative parts of the spec? re/ spelling: I was trying to be consistent and spell it 'MUST' (etc.) in normative parts of the spec, and 'must' in non-normative parts. What is best practice here? Dirk. On Tue, Mar 22, 2016 at 2:09 AM Amos Jeffries <squid3@treenet.co.nz> wrote: > On 22/03/2016 4:43 p.m., Dirk Balfanz wrote: > > Hi Jeff, > > > > I was told that in Yokohama it was decided to add the Sec- prefix again. > (I > > wasn't at that meeting.) > > > > Note that HTTP (RFC 7231 section 8.2.1) header naming requirements state: > "Authors of specifications defining new fields are advised to keep the > name as short as practical" > > HTTP also does not define anything like namespaces within header names. > So "Sec-" has no meaning according to HTTP. If there is a document > defining such a namespace that means "Sec-" needs to be added in > violation of the "short as practical" consideration, then it should be > referenced for context in section 2. > > > > This has prompted me to take a look at this draft in regards to the HTTP > requirements. I'm afraid to report that its in rather bad state in > respect to BCP 90 compliance. <http://tools.ietf.org/html/bcp90> > > > * Sec-Token-Binding does have section 2 to itself, but is still lacking > mention of many of the semantic details required by BCP 90 section 4. > > I did see some details spread out elswhere around the draft, so its > likely they are mostly there somewhere. But they should be a far more > coherent set of semantic statements for HTTP implementers just wanting > to ensure the header is handled correctly by the HTTP layer without > caring about any Token Binding or TLS layer logics. > > > * Include-Referer-Token-Binding-ID semantics are buried in section 3.3 > > This may also be an overly-long header name in respect to the above > mentioned RFC7231 requirement about header naming. > > IMO the header should have a section 2.x to itself outlining explicitly > and clearly the details required by BCP 90 section 4. > > The document structure something along the lines of: > Section 2 HTTP Headers > Section 2.1 The Sec-Token-Binding Header > Section 2.2 The Include-Referer-Token-Binding-ID Header > Section 3 First Party Use Cases > ... > Section 4 Federation Use Cases > ... > > * complete lack of "IANA considerations" section for header registry > templates. > > > Editorial Issues: > > * section 1 states that the draft covers both first-party and federated > use cases. But there is only section 3 outlining federated cases. No > clearly visible section for the first-party use case. > > > * in section 3.1 it says "the Sec-Token-Binding HTTP header defined above". > > Should that not be an explicit "section 2" (2.1?) reference instead of > the word "above" ? > > > * in section 4.2 "manterial" -> material > > * in section 4.3 paragraph 4 it says "A client shouldn't be tricked into > sending a Sec-Token-Binding header to a server that" > > That specific wording is just telling malicious actors "dont be bad". > Which is useless. Surely it should be saying to clients not to let > themselves be tricked. > > > * I spy several lower-case "must", "must not", "should", "should not" > and "may" dotted around the document. Are those normative requirements > or just confusing wording? > > > * please pick a consistent formula for the Security Considerations and > Privacy Consuderations entries before this goes to LC. > > Right now there is a mix of conceptual orderings: > - problem, solution requirements > - requirements, problem, solution requirements > - problem, detailed examples, requirements > - problem, detailed examples, some requirements, detailed examples, > more requirements > > If one wants to skip the rather dense explanatinos and details of > attacks and just check that the requirements are met its quite hard to > see what those actually are. > I suggest sticking with problem and requirements in quick prefix > paragraphs, _then_ details and examples (if necessary). > > > Cheers > AYJ > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --047d7bae4532d4c6fa052f597a1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Thanks for the comments. One question:<div><br></div><div>= The security/privacy considerations sections are not normative. I was under= the impression that it's not within the scope of this spec to tell imp= lementors of browsers what they need to do in order to achieve security and= privacy. Rather, the goal of the spec is to say enough to ensure interoper= ability between clients and servers. It just happens to be the case that pr= efixing the header name with Sec- is an interoperability specification that= also addresses the security issues, so that's a requirement we've = put into the normative part of the spec.</div><div><br></div><div>(Ok, now = the actual question:) Can you think of other requirements flowing from the = security and privacy sections that should make it into the normative parts = of the spec?</div><div><br></div><div>re/ spelling: I was trying to be cons= istent and spell it 'MUST' (etc.) in normative parts of the spec, a= nd 'must' in non-normative parts. What is best practice here?</div>= <div><br></div><div>Dirk.</div><div><br></div></div><br><div class=3D"gmail= _quote"><div dir=3D"ltr">On Tue, Mar 22, 2016 at 2:09 AM Amos Jeffries <= <a href=3D"mailto:squid3@treenet.co.nz">squid3@treenet.co.nz</a>> wrote:= <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex">On 22/03/2016 4:43 p.m., Dirk Balf= anz wrote:<br> > Hi Jeff,<br> ><br> > I was told that in Yokohama it was decided to add the Sec- prefix agai= n. (I<br> > wasn't at that meeting.)<br> ><br> <br> Note that HTTP (RFC 7231 section 8.2.1) header naming requirements state:<b= r> "Authors of specifications defining new fields are advised to keep the= <br> name as short as practical"<br> <br> HTTP also does not define anything like namespaces within header names.<br> So "Sec-" has no meaning according to HTTP. If there is a documen= t<br> defining such a namespace that means "Sec-" needs to be added in<= br> violation of the "short as practical" consideration, then it shou= ld be<br> referenced for context in section 2.<br> <br> <br> <br> This has prompted me to take a look at this draft in regards to the HTTP<br= > requirements. I'm afraid to report that its in rather bad state in<br> respect to BCP 90 compliance. <<a href=3D"http://tools.ietf.org/html/bcp= 90" rel=3D"noreferrer" target=3D"_blank">http://tools.ietf.org/html/bcp90</= a>><br> <br> <br> * Sec-Token-Binding does have section 2 to itself, but is still lacking<br> mention of many of the semantic details required by BCP 90 section 4.<br> <br> I did see some details spread out elswhere around the draft, so its<br> likely they are mostly there somewhere. But they should be a far more<br> coherent set of semantic statements for HTTP implementers just wanting<br> to ensure the header is handled correctly by the HTTP layer without<br> caring about any Token Binding or TLS layer logics.<br> <br> <br> * Include-Referer-Token-Binding-ID semantics are buried in section 3.3<br> <br> This may also be an overly-long header name in respect to the above<br> mentioned RFC7231 requirement about header naming.<br> <br> IMO the header should have a section 2.x to itself outlining explicitly<br> and clearly the details required by BCP 90 section 4.<br> <br> The document structure something along the lines of:<br> =C2=A0Section 2 HTTP Headers<br> =C2=A0Section 2.1 The Sec-Token-Binding Header<br> =C2=A0Section 2.2 The Include-Referer-Token-Binding-ID Header<br> =C2=A0Section 3 First Party Use Cases<br> =C2=A0...<br> =C2=A0Section 4 Federation Use Cases<br> =C2=A0...<br> <br> * complete lack of "IANA considerations" section for header regis= try<br> templates.<br> <br> <br> Editorial Issues:<br> <br> * section 1 states that the draft covers both first-party and federated<br> use cases. But there is only section 3 outlining federated cases. No<br> clearly visible section for the first-party use case.<br> <br> <br> * in section 3.1 it says "the Sec-Token-Binding HTTP header defined ab= ove".<br> <br> Should that not be an explicit "section 2" (2.1?) reference inste= ad of<br> the word "above" ?<br> <br> <br> * in section 4.2=C2=A0 "manterial" -> material<br> <br> * in section 4.3 paragraph 4 it says "A client shouldn't be tricke= d into<br> sending a Sec-Token-Binding header to a server that"<br> <br> That specific wording is just telling malicious actors "dont be bad&qu= ot;.<br> Which is useless. Surely it should be saying to clients not to let<br> themselves be tricked.<br> <br> <br> * I spy several lower-case "must", "must not", "sh= ould", "should not"<br> and "may" dotted around the document. Are those normative require= ments<br> or just confusing wording?<br> <br> <br> * please pick a consistent formula for the Security Considerations and<br> Privacy Consuderations entries before this goes to LC.<br> <br> Right now there is a mix of conceptual orderings:<br> =C2=A0- problem, solution requirements<br> =C2=A0- requirements, problem, solution requirements<br> =C2=A0- problem, detailed examples, requirements<br> =C2=A0- problem, detailed examples, some requirements, detailed examples,<b= r> more requirements<br> <br> If one wants to skip the rather dense explanatinos and details of<br> attacks and just check that the requirements are met its quite hard to<br> see what those actually are.<br> =C2=A0I suggest sticking with problem and requirements in quick prefix<br> paragraphs, _then_ details and examples (if necessary).<br> <br> <br> Cheers<br> AYJ<br> <br> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> </blockquote></div> --047d7bae4532d4c6fa052f597a1e-- From nobody Thu Mar 31 08:44:42 2016 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 9BBDC12D50D for <unbearable@ietfa.amsl.com>; Thu, 31 Mar 2016 08:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 1_uQSMCyqNuZ for <unbearable@ietfa.amsl.com>; Thu, 31 Mar 2016 08:44:38 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 0A95412D1EA for <unbearable@ietf.org>; Thu, 31 Mar 2016 08:44:38 -0700 (PDT) Received: (qmail 21373 invoked by uid 0); 31 Mar 2016 15:44:37 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy8.mail.unifiedlayer.com with SMTP; 31 Mar 2016 15:44:37 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id cfkW1s01F2UhLwi01fkZjx; Thu, 31 Mar 2016 09:44:36 -0600 X-Authority-Analysis: v=2.1 cv=G/WPTbU5 c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=RcnLg9jrK0isJ0HTFMsA:9 a=g8aIRJx3lnqs8BL9:21 a=aZz3H8KD10fuKaeI:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=Xow4AZ4oBymHjYIMp5YQ7nsOv7l92Pxxe4257ig2MEo=; b=H8yoC7SNzjhiskNWimifKp4rIM 6ijoOrBj+kkxSqdWKuuHVCjkFnwLsAVCEw633kIElW4jVAJoWdtHnlAwe4N3lcQzNIbTWHgvQUzHU FxgfWfyQ9THN9nJd/zi+F6kz7; Received: from [73.202.80.238] (port=50060 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1alelr-0002Fa-Pw for unbearable@ietf.org; Thu, 31 Mar 2016 09:44:31 -0600 To: IETF Tokbind WG <unbearable@ietf.org> From: =JeffH <Jeff.Hodges@KingsMountain.com> Message-ID: <56FD45D8.3010609@KingsMountain.com> Date: Thu, 31 Mar 2016 08:44:24 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/TZz_w6Ak3NvFqs1Kc0Nlvqh_5Ug> Subject: [Unbearable] comments on draft-ietf-tokbind-negotiation-02 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 15:44:40 -0000 I basically have only editorial comments on -tokbind-negotiation-02 aka TBNEGO. Though, one possible bug is that step 1 in section 4 refers to 'client' when it should be referring to 'server', yes? see detailed inline comments on this and other stuff below. An overall editorial comment is: RFC5246 defines extensions generically as "Hello Extensions" <https://tools.ietf.org/html/rfc5246#section-7.4.1.4>, rather than as "client hello extension" or "server hello extension".. 7.4.1.4. Hello Extensions The extension format is: struct { ExtensionType extension_type; opaque extension_data<0..2^16-1>; } Extension; enum { signature_algorithms(13), (65535) } ExtensionType; Here: - "extension_type" identifies the particular extension type. - "extension_data" contains information specific to the particular extension type. The initial set of extensions is defined in a companion document [...]. An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello. If a client receives an extension type in ServerHello that it did not request in the associated ClientHello, it MUST abort the handshake with an unsupported_extension fatal alert. Nonetheless, "server-oriented" extensions may be provided in the future within this framework. [...] ..thus I suggest re-working the TBNEGO sections to define a "TB Nego hello extension" with subsequent sections defining the client-side and server-side processing of the extension. further editorial comments inline below: ><snip> > Transport Layer Security (TLS) Extension for Token Binding Protocol > Negotiation > draft-ietf-tokbind-negotiation-02 > >Abstract > > This document specifies a Transport Layer Security (TLS) [RFC5246] > extension for the negotiation of Token Binding protocol > [I-D.ietf-tokbind-protocol] version and key parameters. > >Status of This Memo > > <snip/> > >Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 > 2. Token Binding Negotiation Client Hello Extension . . . . . . 2 > 3. Token Binding Negotiation Server Hello Extension . . . . . . 3 > 4. Negotiating Token Binding Protocol Version and Key Parameters 4 > 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 > 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 > 6.1. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 6 > 6.2. Triple Handshake Vulnerability in TLS 1.2 and Older TLS > Versions . . . . . . . . . . . . . . . . . . . . . . . . 6 > 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 > 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 > 8.2. Informative References . . . . . . . . . . . . . . . . . 7 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 > >1. Introduction > > In order to use the Token Binding protocol > [I-D.ietf-tokbind-protocol], the client and server need to agree on > the Token Binding protocol version and the parameters (signature > algorithm, length) of the Token Binding key. This document specifies > a new TLS extension to accomplish this negotiation without > introducing additional network round-trips. > >1.1. Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > >2. Token Binding Negotiation Client Hello Extension recast as "Token Binding Negotiation Hello Extension" move client-side processing rules to > > The client uses the "token_binding" TLS extension to indicate the > highest supported Token Binding protocol version and key parameters. > > enum { > token_binding(TBD), (65535) > } ExtensionType; > > The "extension_data" field of this extension contains a > "TokenBindingParameters" value. OLD: The "extension_data" field of this extension contains a "TokenBindingParameters" value. NEW: The token_binding extention's "extension_data" field, which is a component of the Extension struct as defined in Section 7.4.1.4 of [RFC5246], contains a "TokenBindingParameters" value, as defined below. > > struct { > uint8 major; > uint8 minor; > } ProtocolVersion; nit: rename this TBProtocolVersion ? > > enum { > rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2), (255) > } TokenBindingKeyParameters; > > struct { > ProtocolVersion token_binding_version; > TokenBindingKeyParameters key_parameters_list<1..2^8-1> > } TokenBindingParameters; > > "token_binding_version" indicates the version of the Token Binding > protocol the client wishes to use during this connection. This > SHOULD be the latest (highest valued) version supported by the > client. [I-D.ietf-tokbind-protocol] describes version {1, 0} of the > protocol. add: "RFC Editor - please remove for RFC publication: Note to implementers - " > Prototype implementations of Token Binding drafts can > indicate support of a specific draft version, e.g. {0, 1} or {0, 2}. new parag.. > "key_parameters_list" contains the list of identifiers of the Token > Binding key parameters supported by the client, in descending order > of preference. > >3. Token Binding Negotiation Server Hello Extension > > The server uses the "token_binding" TLS extension to indicate support > for the Token Binding protocol and to select the protocol version and > key parameters. > > The server that supports Token Binding and receives a client hello > message containing the "token_binding" extension, will include the > "token_binding" extension in the server hello if all of the following > conditions are satisfied: > > 1. The server supports the Token Binding protocol version offered by > the client or a lower version. > > 2. The server finds acceptable Token Binding key parameters on the > client's list. > > 3. The server is also negotiating Extended Master Secret [RFC7627] > and Renegotiation Indication [RFC5746] TLS extensions. This > requirement only applies when TLS 1.2 or an older TLS version is > used (see security considerations section below for more > details). > > > The server will ignore any key parameters that it does not recognize. > The "extension_data" field of the "token_binding" extension is > structured the same as described above for the client > "extension_data". > > "token_binding_version" contains the lower of the Token Binding > protocol version offered by the client in the "token_binding" > extension and the highest version supported by the server. > > "key_parameters_list" contains exactly one Token Binding key > parameters identifier selected by the server from the client's list. > >4. Negotiating Token Binding Protocol Version and Key Parameters > > It is expected that a server will have a list of Token Binding key > parameters identifiers that it supports, in preference order. The > server MUST only select an identifier that the client offered. The > server SHOULD select the most highly preferred key parameters > identifier it supports which is also advertised by the client. In > the event that the server supports none of the key parameters that > the client advertises, then the server MUST NOT include > "token_binding" extension in the server hello. > > The client receiving the "token_binding" extension MUST terminate the > handshake with a fatal "unsupported_extension" alert if any of the > following conditions are true: > > 1. The client did not include the "token_binding" extension in the > client hello. s/client/server/ and s/client hello/ServerHello/ ? plus some other cleanups, e.g.: 1. The server did not include the "token_binding" extension in its ServerHello message. > 2. "token_binding_version" is higher than the Token Binding protocol > version advertised by the client. append: ..in its ClientHello message. > > 3. "key_parameters_list" includes more than one Token Binding key > parameters identifier. > > 4. "key_parameters_list" includes an identifier that was not > advertised by the client. > > 5. TLS 1.2 or an older TLS version is used, but Extended Master > Secret [RFC7627] and Renegotiation Indication [RFC5746] TLS > extensions are not negotiated (see security considerations > section below for more details). > > If the "token_binding" extension is included in the server hello and > the client supports the Token Binding protocol version selected by > the server, it means that the version and key parameters have been > negotiated between the client and the server and SHALL be definitive > for the TLS connection. move 3d chunk below up to here as a "NOTE:" > In this case, the client MUST use the > negotiated key parameters in the "provided_token_binding" as > described in [I-D.ietf-tokbind-protocol]. Does this stipulation really belong in this spec? ISTM more appropriate to stipulate this in -tokbind-protocol. > If the client does not support the Token Binding protocol version > selected by the server, then the connection proceeds without Token > Binding. there are security considerations here, yes? how does the app layer know that TB was not negotiated? > Please note that the Token Binding protocol version and key > parameters are negotiated for each TLS connection, which means that > the client and server include their "token_binding" extensions both > in the full TLS handshake that establishes a new TLS session and in > the subsequent abbreviated TLS handshakes that resume the TLS > session. Move this parag up above as a "NOTE:" > >5. IANA Considerations > > This document defines a new TLS extension "token_binding", which > needs to be added to the IANA "Transport Layer Security (TLS) > Extensions" registry. > > This document establishes a registry for identifiers of Token Binding > key parameters entitled "Token Binding Key Parameters" under the > "Token Binding Protocol" heading. > > Entries in this registry require the following fields: > > o Value: The octet value that identifies a set of Token Binding key > parameters (0-255). > > o Description: The description of the Token Binding key parameters. > > o Specification: A reference to a specification that defines the > Token Binding key parameters. > > This registry operates under the "Expert Review" policy as defined in > [RFC5226]. The designated expert is advised to encourage the > inclusion of a reference to a permanent and readily available > specification that enables the creation of interoperable > implementations using the identified set of Token Binding key > parameters. > > An initial set of registrations for this registry follows: > > Value: 0 > > Description: rsa2048_pkcs1.5 > > Specification: this document > > Value: 1 > > Description: rsa2048_pss > > Specification: this document > > Value: 2 > > Description: ecdsap256 > > Specification: this document > >6. Security Considerations > >6.1. Downgrade Attacks > > The Token Binding protocol version and key parameters are negotiated > via "token_binding" extension within the TLS handshake. TLS prevents > active attackers from modifying the messages of the TLS handshake, > therefore it is not possible for the attacker to remove or modify the > "token_binding" extension. The signature algorithm and key length > used in the TokenBinding of type "provided_token_binding" MUST match > the parameters negotiated via "token_binding" extension. suggestion for 2nd sentence: TLS prevents active attackers from modifying the messages of the TLS handshake, therefore it is not possible for the attacker to remove or modify the "token_binding" extension without detection by the TLS layer, as long as the following stipulation regarding the Triple Handshake Vulnerability is adhered to. the last sentence.. The signature algorithm and key length used in the TokenBinding of type "provided_token_binding" MUST match the parameters negotiated via "token_binding" extension. ..seems unnecessary in this spec -- it is more properly addressed in -tokbind-protocol and -tokbind-https. in any case, rather than saying "signature algorithm and key length", it should say "key parameters" > >6.2. Triple Handshake Vulnerability in TLS 1.2 and Older TLS Versions > > The Token Binding protocol relies on the TLS Exporters [RFC5705] to > associate a TLS connection with a Token Binding. The triple > handshake attack [TRIPLE-HS] is a known TLS protocol vulnerability > allowing the attacker to synchronize exported keying material between > TLS connections. The attacker can then successfully replay bound > tokens. For this reason, the Token Binding protocol MUST NOT be > negotiated with these TLS versions, unless the Extended Master Secret > [RFC7627] and Renegotiation Indication [RFC5746] TLS extensions have > also been negotiated. > >7. Acknowledgements > > This document incorporates comments and suggestions offered by Eric > Rescorla, Gabriel Montenegro, Martin Thomson, Vinod Anupam, Bill Cox, > Nick Harper and others. > >8. References <snip> From nobody Thu Mar 31 10:32:45 2016 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 870AC12D5D2 for <unbearable@ietfa.amsl.com>; Thu, 31 Mar 2016 10:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 GBxG3-CldqeK for <unbearable@ietfa.amsl.com>; Thu, 31 Mar 2016 10:32:41 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id C359112D192 for <unbearable@ietf.org>; Thu, 31 Mar 2016 10:32:41 -0700 (PDT) Received: (qmail 4750 invoked by uid 0); 31 Mar 2016 17:32:40 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 31 Mar 2016 17:32:40 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id chYc1s00F2UhLwi01hYfv4; Thu, 31 Mar 2016 11:32:40 -0600 X-Authority-Analysis: v=2.1 cv=aJ5j99Nm c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=IW0norMAVNDEYp8w2MgA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:To:From:Subject:Date:Message-ID; bh=QdWJGinalohvBTNDu4RSt/XGqA8XXlbmcieJQn6fRtw=; b=WmZuQd+EPgLyuK6zLGSlk7G1De Ro7Md03b5uKyT08ClZA+xFtXpQESOV5tgjRFszt3WlXmYOeRVXa0JxLWNsk50tUxTIbF/qsMf3sXU sjsOePwzHd1OYrgFmQMyrmhu1; Received: from [127.0.0.1] (port=56742 helo=box514.bluehost.com) by box514.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from <jeff.hodges@kingsmountain.com>) id 1algSS-0005xC-1G for unbearable@ietf.org; Thu, 31 Mar 2016 11:32:36 -0600 Received: from 73.202.80.238 ([73.202.80.238]) (SquirrelMail authenticated user jeff.hodges@kingsmountain.com) by box514.bluehost.com with HTTP; Thu, 31 Mar 2016 11:32:36 -0600 Message-ID: <27646f04123990c53e3d27cafc2e6509.squirrel@box514.bluehost.com> Date: Thu, 31 Mar 2016 11:32:36 -0600 From: jeff.hodges@kingsmountain.com To: "IETF Tokbind WG" <unbearable@ietf.org> User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Identified-User: {:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:program running on server} Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/KZLcc80gfUkbOzOxXjTDe3WD7P8> Subject: [Unbearable] tokenbinding/internet-drafts repo conventions X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 17:32:43 -0000 i suggest establishing some further conventions wrt how we manage the tokenbinding/internet-drafts repo. Essentially, the specs that we are "publishing" via the repo (i.e., via the spec links in README.md) are "editors' drafts" -- i.e., the specs pub'd via the repo do not necessarily match that published in the rfc-editors' internet-drafts repository. For example, Dirk merged PR#19 into -tokbind-https-03, so now the repo's copy has diverged from <https://tools.ietf.org/html/draft-ietf-tokbind-https-03>. this is not a big deal, we should just be explicit about it and update the README appropriately. Additionally, ISTM that upon making any changes to any of the spec files in master branch post official draft publication, eg as what has occured with -https-03, we should increment the spec's version in the repo. for example, since -https-03 is officially published, and we have made changes to the editors' source file in the repo, we should go ahead and increment the version to be -https-04 because it is effectively the current "editors' draft" for the to-be-published -04 rev. This is similar to how "editors' drafts" are often made available in the W3C context. thoughts? =JeffH From nobody Thu Mar 31 11:36:17 2016 Return-Path: <balfanz@google.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 A8F9712D72E for <unbearable@ietfa.amsl.com>; Thu, 31 Mar 2016 11:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 nzqHV9BUbKZg for <unbearable@ietfa.amsl.com>; Thu, 31 Mar 2016 11:36:14 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D4112D73C for <unbearable@ietf.org>; Thu, 31 Mar 2016 11:36:14 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id 20so124833408wmh.1 for <unbearable@ietf.org>; Thu, 31 Mar 2016 11:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=MqUam+J2z07wiosSnRzDhBO6Amw+SIy4P7a3PumWQao=; b=ao/FXBeSX/FotUf+yyeRbEHzVSZudCAQ1+KdmfwnJPnzNUocb0vvk1NdgYf7AqZQCA QhbVztFxbm7oP7FTG8I1ciwrSjNf1keIGp+uN16OYpQv27VuT0sKxkt7MwyJHMPTS8I2 npvinZXoCsTISB/nklxyz5LFD8LCWwB8tl6kr15PALBaUUxAvnhPP3YgYSSiThlUcvvy qrVQDnyGkVVQfx5RzrHDLGTJ3Svl0RZU15mS/tLpKZZnOsVOMohHU3G7tahlmXSQpQG5 lC1cl4dGOTTm9eTI7JgI0bPYRMvjJvNFnuuWimnb/YAgYUK9/d9Hz8uPYsuLG8joddJY paiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=MqUam+J2z07wiosSnRzDhBO6Amw+SIy4P7a3PumWQao=; b=MXS12X7GBI20rth2l9EHkKXD2A05E+TBtsbkZE+2QmR8qQvuiC0iTukjqBlNWL0Lui FSAmxGs7gs5wGMiuqCfXEoJXcvjao9xGPNsiF5R16mtv4pgmKoZA6in1ZmvOHDPqVLrR 8iSPUMI1AU3wYOoCRH+aeqixQ/onqfQhM/OMW45ky6SFEdhON93QyEUeZmV4Bj9iVSrk /srM1cheDWP0sxcteyh3w6bq24rIISJoUGlxIIZAkKsfrFcgu6Q9RqhO6MElS94VEvOc YqZWy4ej3VxBWjcK3LZccTOaC0QzsnLzNowvjahv4bFxaYabE0awzIiAmB+o635eA9eK bg0A== X-Gm-Message-State: AD7BkJI4/er53nn8YFTKoLu2N1iNqOXxbbg3mSwbUEkvlLau+PRy/F2pwSVZfgSoLMZCPkYeto0nO2GYb4rGcQZi X-Received: by 10.194.203.5 with SMTP id km5mr5336089wjc.172.1459449372680; Thu, 31 Mar 2016 11:36:12 -0700 (PDT) MIME-Version: 1.0 References: <27646f04123990c53e3d27cafc2e6509.squirrel@box514.bluehost.com> In-Reply-To: <27646f04123990c53e3d27cafc2e6509.squirrel@box514.bluehost.com> From: Dirk Balfanz <balfanz@google.com> Date: Thu, 31 Mar 2016 18:36:02 +0000 Message-ID: <CADHfa2DA501bQSh9XveOcxcHu7d4EHDjdDUcgyUk2t4RXVVkNA@mail.gmail.com> To: jeff.hodges@kingsmountain.com, IETF Tokbind WG <unbearable@ietf.org> Content-Type: multipart/alternative; boundary=047d7bae45326d7e12052f5c895f Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/IzqRWgzCbeb4nPItkIJiIdPWq-Y> Subject: Re: [Unbearable] tokenbinding/internet-drafts repo conventions X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 18:36:16 -0000 --047d7bae45326d7e12052f5c895f Content-Type: text/plain; charset=UTF-8 Agreed about the version numbers. I was wondering why your PR didn't change the version number. :-) Dirk. On Thu, Mar 31, 2016 at 1:32 PM <jeff.hodges@kingsmountain.com> wrote: > i suggest establishing some further conventions wrt how we manage the > tokenbinding/internet-drafts repo. > > Essentially, the specs that we are "publishing" via the repo (i.e., via the > spec links in README.md) are "editors' drafts" -- i.e., the specs pub'd via > the repo do not necessarily match that published in the rfc-editors' > internet-drafts repository. > > For example, Dirk merged PR#19 into -tokbind-https-03, so now the repo's > copy > has diverged from <https://tools.ietf.org/html/draft-ietf-tokbind-https-03 > >. > > this is not a big deal, we should just be explicit about it and update the > README appropriately. > > Additionally, ISTM that upon making any changes to any of the spec files in > master branch post official draft publication, eg as what has occured with > -https-03, we should increment the spec's version in the repo. > > for example, since -https-03 is officially published, and we have made > changes > to the editors' source file in the repo, we should go ahead and increment > the > version to be -https-04 because it is effectively the current "editors' > draft" > for the to-be-published -04 rev. > > This is similar to how "editors' drafts" are often made available in the > W3C > context. > > thoughts? > > =JeffH > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --047d7bae45326d7e12052f5c895f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed about the version numbers. I was wondering why your PR didn't ch= ange the version number. :-)<br><br>Dirk.<br><br><div class=3D"gmail_quote"= ><div dir=3D"ltr">On Thu, Mar 31, 2016 at 1:32 PM <<a href=3D"mailto:jef= f.hodges@kingsmountain.com">jeff.hodges@kingsmountain.com</a>> wrote:<br= ></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-= left:1px #ccc solid;padding-left:1ex">i suggest establishing some further c= onventions wrt how we manage the<br> tokenbinding/internet-drafts repo.<br> <br> Essentially, the specs that we are "publishing" via the repo (i.e= ., via the<br> spec links in README.md) are "editors' drafts" -- i.e., the s= pecs pub'd via<br> the repo do not necessarily match that published in the rfc-editors'<br= > internet-drafts repository.<br> <br> For example, Dirk merged PR#19 into -tokbind-https-03, so now the repo'= s copy<br> has diverged from <<a href=3D"https://tools.ietf.org/html/draft-ietf-tok= bind-https-03" rel=3D"noreferrer" target=3D"_blank">https://tools.ietf.org/= html/draft-ietf-tokbind-https-03</a>>.<br> <br> this is not a big deal, we should just be explicit about it and update the<= br> README appropriately.<br> <br> Additionally, ISTM that upon making any changes to any of the spec files in= <br> master branch post official draft publication, eg as what has occured with<= br> -https-03, we should increment the spec's version in the repo.<br> <br> for example, since -https-03 is officially published, and we have made chan= ges<br> to the editors' source file in the repo, we should go ahead and increme= nt the<br> version to be -https-04 because it is effectively the current "editors= ' draft"<br> for the to-be-published -04 rev.<br> <br> This is similar to how "editors' drafts" are often made avail= able in the W3C<br> context.<br> <br> thoughts?<br> <br> =3DJeffH<br> <br> <br> _______________________________________________<br> Unbearable mailing list<br> <a href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbearable@ietf.or= g</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/unbearable" rel=3D"norefer= rer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/unbearable</a>= <br> </blockquote></div> --047d7bae45326d7e12052f5c895f-- From nobody Thu Mar 31 17:16:57 2016 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 64D7C12D0EB for <unbearable@ietfa.amsl.com>; Thu, 31 Mar 2016 17:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 lugTcHIwtK0S for <unbearable@ietfa.amsl.com>; Thu, 31 Mar 2016 17:16:51 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0117.outbound.protection.outlook.com [207.46.100.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9389512D1CC for <unbearable@ietf.org>; Thu, 31 Mar 2016 17:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ix5lAbSVKw2FlA51IzRAs6wSlSYj4UBRs704YxbUfVM=; b=VGGVXWQZy1MeBW+pV242otj5Ktv20ah3TJUnGirQOab31FksYXPRdfm1o1qaKYXthY8OQ9c+SvuJxk9il/wnV4dQQMy/q77amQHKLhtq5QEU6g9CjbXy6vgk2XBygDu+ShmlFO68sB+bqDj0YJ0YdXFrvw4HPk7KD1heOFOBmMc= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1394.namprd03.prod.outlook.com (10.163.81.140) with Microsoft SMTP Server (TLS) id 15.1.447.15; Fri, 1 Apr 2016 00:16:49 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0447.024; Fri, 1 Apr 2016 00:16:49 +0000 From: Andrei Popov <Andrei.Popov@microsoft.com> To: =JeffH <Jeff.Hodges@KingsMountain.com>, IETF Tokbind WG <unbearable@ietf.org>, "Dirk Balfanz (balfanz@google.com)" <balfanz@google.com> Thread-Topic: [Unbearable] comments on -tokbind-protocol-05 aka TBPROTO Thread-Index: AQHRiwG/0qnm/66FSUSVMVlortc1959z56dA Date: Fri, 1 Apr 2016 00:16:49 +0000 Message-ID: <BLUPR03MB1396F3A551D2992653B753938C9A0@BLUPR03MB1396.namprd03.prod.outlook.com> References: <56FCA08D.3010407@KingsMountain.com> In-Reply-To: <56FCA08D.3010407@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: KingsMountain.com; dkim=none (message not signed) header.d=none;KingsMountain.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:7::1d2] x-ms-office365-filtering-correlation-id: 3a33603f-ddcd-4f2c-a02d-08d359c2eb4d x-microsoft-exchange-diagnostics: 1; BLUPR03MB1394; 5:Azq2QXoC9SNmeMbbBwmMnbaJgKkrHFHNb/r321UuHaSuGuhk9z8AtjhLdzJg2fxPY57EcuL2S8YjK5gAWMTmhfkflt8mTWILyMsco5nQ1C1GHeDfzVFC2Y0dB1wOMqYO9aEVq/B8dV7eTmyu9Unayw==; 24:M/zMfElbAqAd03h0/9AXoC0PACE6xRX7ul6NCnLH0XbaVa75FVTXgPkVe31bTm8GhM/rKAQbaHQ2V3Xzmvku4v1/JDpIRBBELpKB8lC2GfU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1394; x-microsoft-antispam-prvs: <BLUPR03MB1394DC1FE1B60AD59CFA8FA48C9A0@BLUPR03MB1394.namprd03.prod.outlook.com> x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BLUPR03MB1394; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1394; x-forefront-prvs: 0899B47777 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(51914003)(164054003)(5004730100002)(50986999)(5003600100002)(1220700001)(1096002)(122556002)(11100500001)(230783001)(102836003)(99286002)(586003)(575784001)(6116002)(15975445007)(74316001)(2900100001)(86362001)(5002640100001)(77096005)(2950100001)(76176999)(92566002)(10400500002)(5008740100001)(54356999)(189998001)(3280700002)(3660700001)(31430400001)(19580405001)(10090500001)(19580395003)(2906002)(106116001)(107886002)(5001770100001)(76576001)(10290500002)(5005710100001)(81166005)(33656002)(87936001)(3826002)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1394; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2016 00:16:49.3444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1394 Archived-At: <http://mailarchive.ietf.org/arch/msg/unbearable/IYktnlCYLsaD8Yd_vEIdS9DPheg> Subject: Re: [Unbearable] comments on -tokbind-protocol-05 aka TBPROTO X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 01 Apr 2016 00:16:55 -0000 Hi Jeff, Thanks for the review. S1. If Dirk is OK with adding referred_token_binding type and its IANA regi= stration to HTTPSTB, then when it's done, I will remove from TBPROTO. Altho= ugh the need for referred_token_binding is general enough that I would be f= ine keeping it in TBPROTO. S2. What is the use case? A client generating its own token and binding it = to the client's TB key? S3. TBPROTO already describes the specific parameters of the TLS exporter, = including the context, per RFC5705, see TBPROTO section 3. S5. Token Binding is a protocol; I don't see a need to describe APIs. S6a. "Reset" means "deleted" in this case, perhaps it will be more clear if= I use the latter term. Servers simply need to validate the binding: either= the token is acceptable, or not. If not, client auth is re-done and a new = bound token is generated. This is a flow that today's Web apps support. S6b. TBPROTO has a new privacy consideration for this:=20 " A server can use tokens and Token Binding IDs to track clients. Client applications that automatically limit the lifetime of tokens to maintain user privacy SHOULD apply the same validity time limits to Token Binding keys." S7. Servers handle invalid tokens today; TBPROTO describes new cases where = a bound token must be considered invalid. At least in our deployment experi= ence so far, TB validation failures are auto-handled by the existing applic= ation logic with no change. S8. Pull request will be appreciated:). S9. How about "Token Binding IDs MUST never be transmitted in clear text"? S10. We've discussed this before and I would prefer to keep the EMS mantra:= ). If more folks push for this, I'll make the change. S11. TB type was removed from TB ID because it's contextual: the same TB is= "provided" to the RP and "referred" to the IDP. Now if the IDP includes th= is "referred" TB ID in the token, the RP will see that the first byte does = not match. At least in our implementation, this change reduces the number o= f SW components that need to understand the structure of TB IDs. S12. I think so, at least I don't see a reason why we would not do this. I = did not make this change in -05, because I'd like to give folks time to thi= nk about this and speak up if they see a problem. Regarding the editorial comments, but I'd appreciate pull requests:). Thanks, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of =3DJeffH Sent: Wednesday, March 30, 2016 8:59 PM To: IETF Tokbind WG <unbearable@ietf.org> Subject: [Unbearable] comments on -tokbind-protocol-05 aka TBPROTO review comments on -tokbind-protocol-05 aka TBPROTO: Substantive comments: S1. need to migrate the referred_token_binding type and its IANA registrati= on over to -tokbind-https aka HTTPSTB. see.. Re: [Unbearable] -tokbind-protocol-04: verifying signature(s) in TokenBindingMessage.TokenBinding? <https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.iet= f.org%2fmail-archive%2fweb%2funbearable%2fcurrent%2fmsg00470.html&data=3D01= %7c01%7cAndrei.Popov%40microsoft.com%7ceb9106880c0f43c8f1fd08d35918e032%7c7= 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DQO3CyTKGt%2f%2f%2bvTudCFpoVlIAW= rCvBVo0WNqCPuhqiBE%3d> As part of this, we may want to explicitly state that defining the semantic= s of TokenBindingMessages containing more than one provided TokenBinding, a= s well as allocating new TokenBindingType value(s), is left to applications= . S2. TBPROTO focuses on the server side binding TBIDs to "security tokens". However, there are occasions in some protocols/apps where the client side i= s obliged to bind objects to the TLS layer. See for example <https://na01.s= afelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2fw3c.github.io%2fwebauth= n%2f%23sec-client-data&data=3D01%7c01%7cAndrei.Popov%40microsoft.com%7ceb91= 06880c0f43c8f1fd08d35918e032%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata= =3DtKSoFC0O3WzmmLdTFN2NoMETyeaNFGibJSL9Vv8%2fXSM%3d>. TBPROTO should more c= learly explain that either the client or server side may bind TBIDs into ob= jects (tokens, messages, whatever) and either side may be obliged to valida= te such objects, depending on application use case(s). S3. It seems that TBPROTO intends to be a general purpose app-layer means f= or generating and agreeing on TBIDs, i.e., it is not just for HTTP; it seem= s to serve the purpose of mitigating the need for different app-layers to r= e-invent such a mechanism on their own. In doing so, it arguably is acting = as general-purpose packaging of the TLS keying material exporter, and insul= ating other app-layer designers from the vagaries described in the last par= ag of the sec cons in RFC5705.. Designing a secure mechanism that uses exporters is not necessarily straightforward. This document only provides the exporter mechanism, but the problem of agreeing on the surrounding context and the meaning of the information passed to and from the exporter remains. Any new uses of the exporter mechanism should be subject to careful review. If so, this should be stated more explicitly in TBPROTO. S5. Should TBPROTO have a "Required Application Programming Interfaces" section similar to that in RFC5929 [1] ? S6a. How TBIDs are "reset" is not described. Presumably, this is accomplish= ed by the client allocating a new key pair for a server, resigning EKM, and= including the new values in the "next" TokenBindingMessage sent to the server, and servers need to be vigilant abo= ut noticing new TBIDs and re-binding application security tokens/messages a= s appropriate, yes? S6b. Our Security AD verbally expressed to some of us (at IETF-94?) that si= mply saying "TBIDs can be reset by the user at any time" is insufficient gu= idance to app-layer designers regarding a privacy-preserving utilization of= TBPROTO. What else might be added? Perhaps suggestion(s) that the app-laye= r periodically auto-reset TBIDs? S7. Section 6 Security Token Validation specifies conditions (eg incorrect TBID) upon which the server "MUST discard the token". Are there not a range= of application behaviors that might occur, e.g., terminating the applicati= on session? Or, is this particular behavior defined in order to accommodate= resetting of TBIDs by the client-side whereupon there may be a race condit= ion before all the server-issued bound app sec tokens contain the updated T= BID? Is this behavior appropriate for all apps in all cases? what if an incorrect bound TBID is being caused by a MITM? S8. Section 8.2 Security Token Replay is fairly light on details regarding = how an application layer can utilize TBPROTO to detect MITM attacks, perhap= s appropriately generalizing and including the 2nd parag from [2] would hel= p readers better understand how this would work? S9. I would not say "TLS Token Binding IDs are never transmitted in clear t= ext.." -- this could easily occur in an HTTP-based web app that inadvertent= ly leaks cookies, e.g. by retrieving some image over plain http. addressing= this implies adding sec cons wrt such risks, eg "apps need to take precaut= ions to ensure bound sec tokens/messages are not 'leaked' over insecure con= nections such as can occur due to non-https link(s) lurking in a web app, e.g., an image load. HTTP-based applications = should employ techniques such as HSTS and HPKP in order to guard against su= ch situations." S10. I would remove the triple-handshake admonition in section 4, and perha= ps the one in sec cons, but in any case add to sec cons that there are impo= rtant sec cons regarding the underlying TLS connection in [I-D.ietf-tokbind= -negotiation] that could mitigate the app-layer's TB-based security benefit= s if they are not heeded. S11. Regarding the design decision: TokenBindingType is not within TokenBin= dingID -- it is within the enclosing TokenBinding because TokenBindingIDs (= TBIDs) may be conveyed in TBMSG as either provided_ or some other app-layer= -defined TBType. If the app-layer has defined additional TBType(s), the ser= ver-side would want to remember each TBID's type, yes? S12. Perhaps spec should stipulate "server must ignore TBTypes it does not = understand" -- or not? [1] https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2ftool= s.ietf.org%2fhtml%2frfc5929%23section-7&data=3D01%7c01%7cAndrei.Popov%40mic= rosoft.com%7ceb9106880c0f43c8f1fd08d35918e032%7c72f988bf86f141af91ab2d7cd01= 1db47%7c1&sdata=3D7Rtq3b6tY8SDfgJzEXov52ed1TlmhIsiokvWFhPuu7s%3d [2] <https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2ftoo= ls.ietf.org%2fhtml%2fdraft-ietf-tokbind-https-02%23section-4.4&data=3D01%7c= 01%7cAndrei.Popov%40microsoft.com%7ceb9106880c0f43c8f1fd08d35918e032%7c72f9= 88bf86f141af91ab2d7cd011db47%7c1&sdata=3Dyl4SXEzdjflkb26Y7vdiAjGqlsOm8eELhM= 5C6gjvcFo%3d> Overall editorial issues/comments (in no particular order): E1. the mechanics of verifying the signature(s) in a TokenBindingMessage ar= e not spec'd in detail -- experienced crypto folk may know what to do, but = others may not. E2. ought to clearly delineate "server processing model" and "client proces= sing model". (e.g. see https://na01.safelinks.protection.outlook.com/?url= =3Dhttps%3a%2f%2ftools.ietf.org%2fhtml%2frfc6797&data=3D01%7c01%7cAndrei.Po= pov%40microsoft.com%7ceb9106880c0f43c8f1fd08d35918e032%7c72f988bf86f141af91= ab2d7cd011db47%7c1&sdata=3Do549jo6lq%2fNiA0CM20JVit7j0YfXaiLt7Rh28IKbM1Q%3d= ) E3. section "1. Introduction" and section "2. token binding protocol overvi= ew" are quite similar -- perhaps they could be combined? E4. If section 3 and 4 are massaged per E2, section 5 becomes superfluous (= it seemed to in my experimenting). E4. the security considerations section contains RFC2119 requirements langu= age -- some downstream reviews may frown on this. E5. TBPROTO in and of itself does not "prevent" export and replay of app se= curity tokens -- rather it facilitates detection of such occurances. E6. Terminology is fairly loose, e.g. terms such as "token", "security toke= n", "bound token", "bound security token" are not used as consistently as t= hey could be. E7. Various spec portions could benefit from further wordsmithing -- sugges= tions are inline below... <snip> > The Token Binding Protocol Version 1.0 > draft-ietf-tokbind-protocol-05 > <snip> > > 1. Introduction > > Servers generate various security tokens (e.g. HTTP cookies, OAuth > tokens) for applications to access protected resources. Any party in > possession of such token gains access to the protected resource. > Attackers export bearer tokens from the user's machine, present them > to the servers, and impersonate authenticated users. The idea of > Token Binding is to prevent such attacks by cryptographically binding > security tokens to the TLS layer. > > A TLS Token Binding is established by the user agent generating a s/the user agent/a client-side application (e.g., a user agent)/ > private-public key pair (possibly within a secure hardware module, > such as TPM) per target server, and proving possession of the private > key on every TLS connection to the target server. The proof of > possession involves signing the exported keying material [RFC5705] > for the TLS connection with the private key. The corresponding > public key is included in the TLS Token Binding identifier structure > (described in the "TLS Token Binding ID Format" section of this > document). TLS Token Bindings are long-lived, i.e. they encompass > multiple TLS connections and TLS sessions between a given client and > server. To protect privacy, TLS Token Binding IDs are never > transmitted in clear text and can be reset by the user at any time, > e.g. when clearing browser cookies. > > When issuing a security token to a client that supports TLS Token > Binding, a server includes the client's TLS Token Binding ID in the > token. Later on, when a client presents a security token containing > a TLS Token Binding ID, the server makes sure the ID in the token > matches the ID of the TLS Token Binding established with the client. > In the case of a mismatch, the server discards the token. > > In order to successfully export and replay a bound security token, > the attacker needs to also be able to export the client's private > key, which is hard to do in the case of the key generated in a secure > hardware module. > > 1.1. Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > 2. Token Binding Protocol Overview this section largely duplicates the Introduction -- could the intro be trim= med way down and then this section effectively provides the underlying deta= ils that are summarized in the Intro? > > The client and server use the Token Binding Negotiation TLS Extension > [I-D.ietf-tokbind-negotiation] to negotiate the Token Binding > protocol version and the parameters (signature algorithm, length) of > the Token Binding key. This negotiation does not require additional > round-trips. wrt "the parameters (signature algorithm, length)" -- this is now effective= ly referred to as "key parameters" yes? > The Token Binding protocol consists of one message sent by the client > to the server, proving possession of one or more client-generated > asymmetric keys. This message is only sent if the client and server > agree on the use of the Token Binding protocol and the key > parameters. The Token Binding message is sent with the application > protocol data in TLS application_data records. wrt... "The Token Binding message is sent with the application protocol dat= a in TLS application_data records" ...in other words, after Token Binding negotiation during TLS handshake [I-= D.ietf-tokbind-negotiation], the Token Binding msg is created by the client= and conveyed to the server in the app layer protocol which is running over= TLS within whose context the token binding ID was established. Yes? perhaps re-state. > A server receiving the Token Binding message verifies that the key > parameters in the message match the Token Binding parameters > negotiated via [I-D.ietf-tokbind-negotiation], and then validates the > signatures contained in the Token Binding message. If either of > these checks fails, the server terminates the connection, otherwise > the TLS Token Binding is successfully established with the ID > contained in the Token Binding message. > > When a server supporting the Token Binding protocol receives a bound > token, the server compares the TLS Token Binding ID in the security > token with the TLS Token Binding ID established with the client. If > the bound token came from a TLS connection without a Token Binding, > or if the IDs don't match, the token is discarded. > > This document defines the format of the Token Binding protocol > message, the process of establishing a TLS Token Binding, the format > of the Token Binding ID, and the process of validating a security > token. s/security token/bound security token/ > Token Binding Negotiation TLS Extension > [I-D.ietf-tokbind-negotiation] describes the negotiation of the Token > Binding protocol and key parameters. Token Binding over HTTP > [I-D.ietf-tokbind-https] explains how the Token Binding message is > encapsulated within HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] messages. > [I-D.ietf-tokbind-https] also describes Token Binding between > multiple communicating parties: User Agent, Identity Provider and > Relying Party. > > 3. Token Binding Protocol Message > > The Token Binding message is sent by the client and proves possession > of one or more private keys held by the client. This message MUST be > sent if the client and server successfully negotiated the use of the > Token Binding protocol via [I-D.ietf-tokbind-negotiation], and MUST > NOT be sent otherwise. This message MUST be sent in the client's > first application protocol message. This message MAY also be sent in > subsequent application protocol messages, proving possession of other > keys by the same client, to facilitate token binding between more > than two communicating parties. suggest beginning new parag here.. > Token Binding over HTTP > [I-D.ietf-tokbind-https] specifies the encapsulation of the Token > Binding message in the application protocol messages, and the > scenarios involving more than two communicating parties. The Token > Binding message format is defined using TLS specification language: > > enum { > rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2), (255) > } TokenBindingKeyParameters; add comment on above: /* imported from [I-D.ietf-tokbind-negotiation] */ > > struct { > opaque modulus<1..2^16-1>; > opaque publicexponent<1..2^8-1>; > } RSAPublicKey; > > struct { > opaque point <1..2^8-1>; > } ECPoint; > > enum { > provided_token_binding(0), referred_token_binding(1), (255) > } TokenBindingType; > > struct { > TokenBindingKeyParameters key_parameters; > select (key_parameters) { > case rsa2048_pkcs1.5: > case rsa2048_pss: > RSAPublicKey rsapubkey; > case ecdsap256: > ECPoint point; > } missing a semi-colon, should be: }; > } TokenBindingID; > > enum { > (255) // No initial ExtensionType registration= s > } ExtensionType; comments in TLS presentation language are: /* . . . */ see https://na01.saf= elinks.protection.outlook.com/?url=3Dhttps%3a%2f%2ftools.ietf.org%2fhtml%2f= draft-ietf-tls-tls13%23section-4.2&data=3D01%7c01%7cAndrei.Popov%40microsof= t.com%7ceb9106880c0f43c8f1fd08d35918e032%7c72f988bf86f141af91ab2d7cd011db47= %7c1&sdata=3DsyRBZbc35znWJx2yjbbHPcrAbOS%2fD4drLMvaPSP6DtE%3d > > struct { > ExtensionType extension_type; > opaque extension_data<0..2^16-1>; > } Extension; > > struct { > TokenBindingType tokenbinding_type; > TokenBindingID tokenbindingid; > opaque signature<0..2^16-1>;// Signature over the exported keying >material value > Extension extensions<0..2^16-1>; > } TokenBinding; > > struct { > TokenBinding tokenbindings<0..2^16-1>; > } TokenBindingMessage; is it legit for a TokenBindingMessage to be an empty sequence as implied by= the "tokenbindings<0..2^16-1>" declaration? no, it is not, see last paragr= aph below in this section. [this sort of inconsistency seems to also exist in RFC5246 so I am doubting= it is something to worry about.] The below paragraphs appear to be client-side processing rules, yes? I sugg= est identifying them as such. > The Token Binding message consists of a series of TokenBinding > structures containing the type of the token binding, the > TokenBindingID, a signature over the exported keying material (EKM) > value, optionally followed by Extension structures. > > This document defines two token binding types: provided_token_binding > used to establish a Token Binding when connecting to a server, and > referred_token_binding used when requesting tokens to be presented to > a different server. Token Binding over HTTP [I-D.ietf-tokbind-https] > describes Token Binding between multiple communicating parties: User > Agent, Identity Provider and Relying Party. See also Section 7.1 > > When an rsa2048_pkcs1.5 or rsa2048_pss key is used, > TokenBinding.signature contains the signature generated using, > respectively, the RSASSA-PKCS1-v1_5 or RSASSA-PSS signature scheme > defined in [RFC3447]. RSAPublicKey.modulus and > RSAPublicKey.publicexponent contain the length-prefixed modulus and > exponent of the RSA public key represented in big-endian format. > > When an ecdsap256 key is used, TokenBinding.signature contains a pair > of integers, R followed by S, as defined in [ANSI.X9-62.2005]. R and > S are encoded in big-endian format. ECPoint.point contains the X > coordinate followed by the Y coordinate. The X and Y coordinates are > unsigned integers encoded in big-endian format. Future > specifications may define Token Binding keys using other elliptic > curves with their corresponding signature and point formats. > > The EKM is obtained using the Keying Material Exporters for TLS > defined in [RFC5705], by supplying the following input values: > > o Label: The ASCII string "EXPORTER-Token-Binding" with no > terminating NUL. > > o Context value: NULL (no application context supplied). > > o Length: 32 bytes. the below 2 parags are essentially server-side processing rules -- fold the= m into the next section and rename it "server processing model"? > An implementation MUST ignore any unknown extensions. Initially, no > extension types are defined (see Section 7.2). One of the possible > uses of extensions envisioned at the time of this writing is > attestation: cryptographic proof that allows the server to verify > that the Token Binding key is hardware-bound. The definitions of > such Token Binding protocol extensions are outside the scope of this > specification. > > At least one TokenBinding MUST be included in the Token Binding > message. The signature algorithm and key length used in the > TokenBinding MUST match the parameters negotiated via > [I-D.ietf-tokbind-negotiation]. The client SHOULD generate and store > Token Binding keys in a secure manner that prevents key export. In > order to prevent cooperating servers from linking user identities, > different keys SHOULD be used by the client for connections to > different servers, s/cooperating servers/colluding servers/ according to the token scoping rules of the > application protocol. > > 4. Establishing a TLS Token Binding s/Token Binding/Token Binding ID/ this section is written from the perspective of the server side upon receip= t of an app layer msg containing a TokenBindingMessage, perhaps be more exp= licit and have an intro sentence like.. Upon receipt by the server of a client's TokenBindingMessage via the applic= ation layer protocol, the server performs these checks: > The triple handshake vulnerability in TLS 1.2 and older TLS versions > affects the security of the Token Binding protocol, as described in > the "Security Considerations" section below. Therefore, the server > MUST NOT negotiate the use of the Token Binding protocol with these > TLS versions, unless the server also negotiates Extended Master > Secret [RFC7627] and Renegotiation Indication [RFC5746] TLS > extensions. the above admonition is TLS-specific and is already addressed in [I-D.ietf-= tokbind-negotiation] so remove it? > The server MUST terminate the connection if the use of the Token > Binding protocol was not negotiated, but the client sends the Token > Binding message. s/not negotiated/not negotiated at the TLS layer/ > If the Token Binding type is > "provided_token_binding", the server MUST verify that the signature > algorithm (including elliptic curve in the case of ECDSA) and key > length in the Token Binding message match those negotiated via > [I-D.ietf-tokbind-negotiation]. In the case of a mismatch, the > server MUST terminate the connection. suggest.. OLD: the signature algorithm (including elliptic curve in the case of ECDSA) and= key length in the Token Binding message match those NEW: the key parameters value in the Token Binding object match that > As described in > [I-D.ietf-tokbind-https], Token Bindings of type > "referred_token_binding" may have different key parameters than those > negotiated via [I-D.ietf-tokbind-negotiation]. rather than "negotiated via [I-D.ietf-tokbind-negotiation]", you mean "nego= tiated with this server." -- yes ? suggest: Token Bindings of types other than "provided_token_binding" may have differ= ent key parameters than those negotiated for the current provided TLS Token= Binding ID. > > If the Token Binding message does not contain at least one > TokenBinding structure, or the signature contained in a TokenBinding > structure is invalid, the server MUST terminate the connection. make the next sentence a new parag: > Otherwise, the TLS Token Binding is successfully established and its > ID can be provided to the application for security token validation. suggested enhancement: Otherwise, the Token Binding IDs for the token binding context between this= client and server are successfully established. The TokenBindingID structu= re(s) are noted by the client application, and they are extracted from the = TokenBindingMessage and noted by the server side application. The applicati= on may then use the Token Binding IDs for bound security token creation and= validation (e.g., as in [I-D.ietf-tokbind-https]), or other application us= es as appropriate. given the above, it seems section 5 below seems superfluous to me: > > 5. TLS Token Binding ID Format > > The ID of the TLS Token Binding established as a result of Token > Binding message processing is a binary representation of the > following structure: > > > struct { > TokenBindingKeyParameters key_parameters; > select (key_parameters) { > case rsa2048_pkcs1.5: > case rsa2048_pss: > RSAPublicKey rsapubkey; > case ecdsap256: > ECPoint point; > } > } TokenBindingID; > > > TokenBindingID contains the key parameters negotiated via > [I-D.ietf-tokbind-negotiation]. TLS Token Binding ID can be obtained > from the TokenBinding structure described in the "Token Binding > Protocol Message" section of this document by discarding the token > binding type, signature and extensions. TLS Token Binding ID will be > available at the application layer and used by the server to generate > and verify bound tokens. > 6. Security Token Validation Security Token Binding and Validation > Security tokens can be bound to the TLS layer either by embedding the > Token Binding ID in the token, or by maintaining a database mapping > tokens to Token Binding IDs. The specific method of generating bound > security tokens is application-defined and beyond the scope of this > document. suggested rewrite: In general, application layer security tokens are bound to the underlying T= LS connection by either embedding the connection's TokenBindingID within th= e security token, or by the application maintaining a mapping of security t= okens to TokenBindingIDs. The specific method of binding application securi= ty tokens to underlying TLS connection(s) is application-defined and beyond= the scope of this specification. > Upon receipt of a security token, the server attempts to retrieve TLS > Token Binding ID information from the token and from the TLS > connection with the client. Application-provided policy determines > whether to honor non-bound (bearer) tokens. If the token is bound > and a TLS Token Binding has not been established for the client > connection, the server MUST discard the token. If the TLS Token > Binding ID for the token does not match the TLS Token Binding ID > established for the client connection, the server MUST discard the > token. Upon receipt of a bound security token, the server-side application extract= s the TokenBindingID(s) from the bound security token and from the TLS conn= ection with the client. Application-specific policy determines whether to h= onor unbound (i.e., bearer) security tokens. If the security token is bound and a Token Binding has not been established= for the client connection, the server MUST discard the security token. If = the TokenBindingID within the token does not match the TokenBindingID estab= lished for the client connection, the server MUST discard the token. though: what's the rationale for only discarding tokens and not doing anyth= ing further? see S7 above. > > 7. IANA Considerations <snip> > > 8. Security Considerations > > 8.1. Security Token Replay > > The goal of the Token Binding protocol is to prevent attackers from > exporting and replaying security tokens, thereby impersonating > legitimate users and gaining access to protected resources. Bound > tokens can still be replayed by the malware present in the User > Agent. In order to export the token to another machine and > successfully replay it, the attacker also needs to export the > corresponding private key. Token Binding private keys are therefore > high-value assets and SHOULD be strongly protected, ideally by > generating them in a hardware security module that prevents key > export. > > The manner in which a token is bound to the TLS layer is application- > defined and beyond the scope of this document. However, the > resulting bound token needs to be integrity-protected, so that an > attacker cannot remove the binding or substitute a Token Binding ID > of their choice without detection. > > 8.2. Downgrade Attacks > > The Token Binding protocol is only used when negotiated via > [I-D.ietf-tokbind-negotiation] within the TLS handshake. TLS > prevents active attackers from modifying the messages of the TLS > handshake, therefore it is not possible for the attacker to remove or > modify the Token Binding Negotiation TLS Extension used to negotiate > the Token Binding protocol and key parameters. The signature > algorithm and key length used in the TokenBinding of type > "provided_token_binding" MUST match the parameters negotiated via > [I-D.ietf-tokbind-negotiation]. suggest: TLS prevents active attackers from modifying the messages of the TLS handsh= ake, therefore it is not possible for the attacker to remove or modify the = Token Binding Negotiation TLS Extension used to negotiate the Token Binding= protocol version and key parameters. The key parameters used in TokenBindi= ngMessage.TokenBinding structures of type "provided_token_binding" MUST mat= ch the key parameters negotiated via [I-D.ietf-tokbind-negotiation]. > > 8.3. Privacy Considerations > > The Token Binding protocol uses persistent, long-lived TLS Token > Binding IDs. To protect privacy, TLS Token Binding IDs are never > transmitted in clear text and can be reset by the user at any time, > e.g. when clearing browser cookies. Some applications offer a > special privacy mode where they don't store or use tokens supplied by > the server, e.g. "in private" browsing. When operating in this > special privacy mode, applications SHOULD use newly generated Token > Binding keys and delete them when exiting this mode, or else SHOULD > NOT negotiate Token Binding at all. > > In order to prevent cooperating servers from linking user identities, > different keys SHOULD be used by the client for connections to > different servers, according to the token scoping rules of the > application protocol. the above admonition (paragraph) should be up above where generation of the= token binding key pair is stipulated. > > A server can use tokens and Token Binding IDs to track clients. > Client applications that automatically limit the lifetime of tokens > to maintain user privacy SHOULD apply the same validity time limits > to Token Binding keys. > <snip> _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7cAndrei.Popov%40micr= osoft.com%7ceb9106880c0f43c8f1fd08d35918e032%7c72f988bf86f141af91ab2d7cd011= db47%7c1&sdata=3DhmtJxiRucUApCw9TYg9cC42LHEvmkWxv0AmHinFnpJc%3d