From nobody Thu Feb 2 17:15:20 2017 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 70C42129579 for ; Thu, 2 Feb 2017 17:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=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 u7yJcukQck4h for ; Thu, 2 Feb 2017 17:15:17 -0800 (PST) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id 2F99C127735 for ; Thu, 2 Feb 2017 17:15:17 -0800 (PST) Received: (qmail 23939 invoked by uid 0); 3 Feb 2017 01:15:14 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy3.mail.unifiedlayer.com with SMTP; 3 Feb 2017 01:15:14 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id g1FA1u00C2UhLwi011FDkk; Thu, 02 Feb 2017 18:15:14 -0700 X-Authority-Analysis: v=2.1 cv=H5NInYoi 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=n2v9WMKugxEA:10 a=NEAV23lmAAAA:8 a=8TEvEHZbQ6QEmvt1cB4A:9 a=QEXdDO2ut3YA:10 a=Jvbhi6MioLIA:10 a=Bn2pgwyD2vrAyMmN8A2t:22 Received: from [173.224.162.69] (port=39130 helo=[10.225.80.62]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cZST0-0004Zi-0I for unbearable@ietf.org; Thu, 02 Feb 2017 18:15:10 -0700 To: IETF TokBind WG From: =JeffH Message-ID: <4760c488-ac72-2f1d-0956-5774309314f8@KingsMountain.com> Date: Thu, 2 Feb 2017 17:15:08 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 173.224.162.69 X-Exim-ID: 1cZST0-0004Zi-0I X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.225.80.62]) [173.224.162.69]:39130 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 1 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Unbearable] HTTPSTB updates and respin WGLC 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: Fri, 03 Feb 2017 01:15:18 -0000 Please review PR #92: HTTPSTB: 'TB key' terminology cleanup, see #87 https://github.com/TokenBinding/Internet-Drafts/pull/92 In the meantime, am working on issue #88 and reviewing draft-campbell-tokbind-tls-term. =JeffH From nobody Thu Feb 2 17:51:29 2017 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 F32DE129A84 for ; Thu, 2 Feb 2017 17:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 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=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1S6uX8-XOvx for ; Thu, 2 Feb 2017 17:51:25 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0105.outbound.protection.outlook.com [104.47.42.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF92129A78 for ; Thu, 2 Feb 2017 17:51:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+wK15vo+nhAtGAr0gLqVnOcb/jdLluHOOO9OT8oHydw=; b=YNeRNL5wbLQRL8R0Fd2gaqXH5IQtigoMFYjATIN+Er6Bra5Q3J2f+u0BMu+aSdjw+nr1h4vI2pphxVPVsdf8GKCwDcpeKnUv2/tckhud//D4oqq9n+QYaesmbZlnubCV8UaSg2bvNTjYzy2eJRW3mvt19K96vNgbaUSCmNzzViw= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Fri, 3 Feb 2017 01:51:24 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0860.027; Fri, 3 Feb 2017 01:51:24 +0000 From: Andrei Popov To: =JeffH , IETF TokBind WG Thread-Topic: [Unbearable] HTTPSTB updates and respin WGLC Thread-Index: AQHSfbsAGHpXbpxUPkurN0G1jEFRUKFWe+2w Date: Fri, 3 Feb 2017 01:51:23 +0000 Message-ID: References: <4760c488-ac72-2f1d-0956-5774309314f8@KingsMountain.com> In-Reply-To: <4760c488-ac72-2f1d-0956-5774309314f8@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:a::1d2] x-ms-office365-filtering-correlation-id: 3487d357-2492-4744-3f9c-08d44bd728cc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0842; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 7:vDUyL22Xqq0yOJEuuEm/yN7CK+zysPf5lk4xg7lZKGDD8WwbPMJN9JRM39xEH4hxyHBD66enDXZ0aDnXseAxNWyYbzx+qQbkrL72Cmuw+CCviT3rcTWJl8DIefLivJ7gAdpOAPnhdpOaLr0q2ehIDui1XnzmmKcIMWY7Ny7YFEFA907aNOQBi9aOblPiL3h8sH/Q5kGwisOpFLSrOlyNd6C9it5oOQH8aSQEwkw0KZ+5yIjmVacQXzR9vAT4/KvxPkGTFhoU2R18EYasMy4msZhP5xZVLynqtfRt22cwwWZ+5/4WC2ZTVf3uTx4XPbJNm8rtNTqasZSKM6NKM8eHIUVcZ/Zzv9rSBr/OuY8iTfsJveCD5YHg3AabAAgIQcbWr8IxWE8op/mulRMXdx8ScP+du4WIZE8yOHKTJDFd9Pyz3OoWAa546cCiKzbhosP7OOiWUIfKCTCEEzyb0Y6F+L5M9q+XbUl7JLg7x8HvfFCPxzZ994zBvPmhiT6sHnchHmGWGJlu5T2AZStATNBEVMNbw9DVtTbCao5xsanX82Q= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(6042181)(6072148); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 02070414A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(55674003)(189002)(199003)(377454003)(2900100001)(3660700001)(9686003)(15650500001)(122556002)(68736007)(5005710100001)(8990500004)(10290500002)(6116002)(102836003)(86362001)(86612001)(76176999)(92566002)(54356999)(50986999)(2950100002)(107886002)(189998001)(5001770100001)(97736004)(7696004)(38730400001)(229853002)(6506006)(5660300001)(74316002)(106116001)(106356001)(105586002)(3280700002)(6306002)(99286003)(2906002)(55016002)(25786008)(77096006)(33656002)(7736002)(53936002)(10090500001)(6436002)(81166006)(81156014)(8676002)(101416001)(8936002)(305945005)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 03 Feb 2017 01:51:23.8889 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Subject: Re: [Unbearable] HTTPSTB updates and respin WGLC 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: Fri, 03 Feb 2017 01:51:28 -0000 Thanks, Jeff, for correcting TB key vs. TB ID. A few editorial suggestions = below. I think this needs to be rephrased: > The Token Binding ID of a TLS connection is constructed using =20 > the public key OF a private-public key pair, OF which =20 > the client proves possession OF the private key to =20 > the server. Perhaps better to just split this into two sentences:=20 The Token Binding ID of a TLS connection is constructed using the public ke= y of a private-public key pair. The client proves possession of the corresponding private key. > (clients use different Token Binding key pairs for different... > The scoping for those Token Binding key pairs generated by Web browsers i= n... > browsers MAY use different key pair scoping rules. > For privacy reasons, clients use different Token Binding key pairs > of the Token Binding key pair. It is possible that the Token >
Token Binding key pair across such subdomains. > permissible to use different Token Binding key pair scoping rules, such a= s... > using the same Token Binding key pair for both the Relying Party and the = Identity... >
> Token Binding key pairs do not have an expiration time. > Token Binding key pairs (similar to the affordances provided to delete co= okies). > Binding key pairs from such modes after the session is over. Generally sp= eaking, > Binding key pairs as they have over cookies or other potential tracking While not wrong, all these key pairs seem unnecessary. The Token Binding ke= y is asymmetric, so clearly it has a private and public component. Aesthetically, I'd prefer Token Binding keys, key scoping, etc., to avoid a= tautology. > contains both: a proof of possession of the provided Token Binding =20 > ID, as well as a proof of possession of the referred Token Binding =20 > ID It's a proof of possession of a Token Binding key, I think. Cheers, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of =3DJeffH Sent: Thursday, February 2, 2017 5:15 PM To: IETF TokBind WG Subject: Re: [Unbearable] HTTPSTB updates and respin WGLC Please review PR #92: HTTPSTB: 'TB key' terminology cleanup, see #87 https://github.com/TokenBinding/Internet-Drafts/pull/92 In the meantime, am working on issue #88 and reviewing draft-campbell-tokbi= nd-tls-term. =3DJeffH _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable From nobody Sun Feb 5 12:54:53 2017 Return-Path: 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 3D05D1293E1; Sun, 5 Feb 2017 12:54:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148632809221.31496.5928180225376398174.idtracker@ietfa.amsl.com> Date: Sun, 05 Feb 2017 12:54:52 -0800 Archived-At: Cc: unbearable@ietf.org, stephen.farrell@cs.tcd.ie, leifj@sunet.se, tokbind-chairs@ietf.org Subject: [Unbearable] tokbind - New Meeting Session Request for IETF 98 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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 20:54:52 -0000 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): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: ace tls oauth People who must be present: Stephen Farrell Leif Johansson Dirk Balfanz John Bradley Andrey Popov Mike Jones Resources Requested: Meetecho support in room Special Requests: Key contributors are unable to attend on Friday. Please if possible avoid Friday scheduling. --------------------------------------------------------- From nobody Mon Feb 6 03:02:12 2017 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 D2027129537; Mon, 6 Feb 2017 03:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 TyqnBoP-f1FU; Mon, 6 Feb 2017 03:02:04 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 3B18D12950D; Mon, 6 Feb 2017 03:02:04 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 6C92A78048B; Mon, 6 Feb 2017 12:02:00 +0100 (CET) To: Justin Richer , oauth@ietf.org, IETF Tokbind WG References: <318C729C-3374-47B9-BF7E-F5F2F81EAC33@oracle.com> <39f411e1-da84-b25c-a894-9e0a629d6d95@mit.edu> <71435970-7138-f739-bb92-1208d44817e1@free.fr> <9a2da0db-fa67-3216-c520-0d746d10cfc8@mit.edu> From: Denis Message-ID: Date: Mon, 6 Feb 2017 12:02:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <9a2da0db-fa67-3216-c520-0d746d10cfc8@mit.edu> Content-Type: multipart/alternative; boundary="------------310C5A4D40FAE297B2BB215D" Archived-At: Subject: [Unbearable] Is it possible to stop sharing bearer tokens ? (was OAuth for institutional users) 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: Mon, 06 Feb 2017 11:02:07 -0000 This is a multi-part message in MIME format. --------------310C5A4D40FAE297B2BB215D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Justin, You said : "Sharing bearer tokens is a well known attack surface and *there's really no way to stop that*. Even PoP-style tokens can be shared since nothing stops Bob and Alice from sharing their secrets with each other". You also said: "There's literally *nothing in the world that can prevent that level of collusion* -- PoP, token binding, DRM... nothing". Whatever kind of cryptography is being used, there is indeed are no way to stop sharing bearer tokens using implementations that rely on/_software-only implementations_/. Since the current documents being progressed in the Tokbind WG are based on the use of software only (i.e. TLS binding), none of them is able to prevent that level of collusion. _Note_: I also send a copy of the email to the Tokbind WG (unbearable@ietf.org) so that it can be aware of that discussion. However, when/_using secure hardware_ in a right way, *it is possible to stop sharing bearer tokens*/. Idemix from IBM has been extended to take advantage of the use of smart cards. See the IRMA project (I Reveal My Attributes) at: https://www.irmacard.org/irma/ It is mentioned in particular that "/The security of IRMA depends on the protection of each Users private key/". Bob cannot indeed transmit any private key to Alice, however he is able to *use* private keys present in his smart card. If Bob accepts to collaborate with Alice, a smart card simply protecting private keys does not possess sufficient properties to counter the ABC attack (Alice and Bob Collusion attack). Bob can perform all the computations that Alice needs, even if Bob and Alice are located in different continents. Hence the IRMA project, based on Idemix, is vulnerable to the ABC attack. Another solution from Microsoft (U-Prove) has the same problem, even when smart cards (or secure elements) are being used: U-prove is also vulnerable to the ABC attack. draft-ietf-oauth-pop-architecture-08 (OAuth 2.0 Proof-of-Possession (PoP) Security Architecture), has expired on January 9, 2017. Since it was only relying on software, it was unable to counter the ABC attack. The *only way* to stop sharing bearer tokens is to use implementations that rely on//some piece of hardware that has /_additional properties_/ beyond the protection of private keys. A secure solution certainly needs to rely on the use of software, but also on the use of secure elements that have specific /_functional and security properties_/. Stopping the sharing of bearer tokens, is not a concern in the case of a delegation protocol, since the use of *Authorization Servers should be deprecated in this context for privacy reasons (as explained in my previous email sent to the OAuth mailing list).* However, stopping the sharing of bearer tokens is mandatory in a "different protocol where the client and resource negotiate attributes for the client to present to the resource to fulfill its requirements". A protocol able to stop sharing bearer tokens needs to transmit data generated by the secure elements (called APDUs - Application Protocol Data Units) so that some APDUscan be directly verified by Authorization Servers and some other APDUscan be directly verified by Resource Servers. In order to stop the sharing of bearer tokens, it is also necessary to specify the format of the access tokens. I noticed that OAuth does not specify the access token itself, since the format is opaque to the protocol flow. As long as this postulate will remain, OAuth and its derivatives won't be able to stop the sharing of bearer tokens. As a conclusion, keeping all the postulates of OAuth 2.0 /unchanged//, /I do agree with you that//"*there's really no way to stop that"*. However, *there's a way to stop that*, but some of the postulates of OAuth 2.0 would need to be changed and some /_functional and security requirements_/ that apply to the use of secure elements would need to be added. This might not be called "OAuth 2.0" anymore ... but this would be a secure solution. Denis > Hi Denis, > > The book is being published very shortly and the text is completed, so > there aren't any more updates to be made to it. Additionally, this > isn't really the forum for comments on the book (there's an online > form for discussion if you're interested: > https://forums.manning.com/forums/oauth-2-in-action), this is a list > for discussing and developing OAuth itself. Still, most of your > comments are general enough misconceptions of OAuth that they may be > of interest to others so I'll answer them on the list here, inline below. > > > On 2/2/2017 5:47 PM, Denis wrote: >> >> Justin, >> >> Your are making the promotion of your book (OAuth 2 In Action), soon >> to be published. >> >> I browsed through the 23 pages of Chapter 1 that are provided as a >> free download. >> >> I saw the footnote from Manning Publications Co. which states: >> >> "/We welcome reader comments about anything in the manuscript/" >> >> Since Manning Publications Co. asked for it, I hope that you will be >> able to take into consideration some of my comments before this book >> is published. >> >> I will only comment on a few sentences. >> >> 1. Page 1: "The application requests authorization from the owner of >> the resource and receivestokens that it can use to access the resource". >> >> Such a model is rather restrictive and does not cover the general >> case where an application is willing to perform an operation on a >> resource >> and where the resource tells to the application which kind of >> attributes need to be presented by the application for that specific >> operation. >> In such a case, the resource owner is not involved in anyway at the >> time of the request. If this restriction remains, this should be >> clearly stated. >> > > This is the model of OAuth: it's a delegation protocol, delegating > from a resource owner to a client. What you're describing is a > different protocol where the client and resource negotiate attributes > for the client to present to the resource to fulfill its requirements. > OAuth specifically abstracts that process using the authorization > server, and to great success. > >> 2. Page 10:" To acquire a token, the client first sends the resource >> owner to the authorization server in order to request that the >> resource owner authorize this client". >> >> This sentence is not English. You cannot "send the resource owner to >> the authorization server". This sentence should be rephrased. >> > > Yes you can send the resource owner to the authorization server -- > generally by redirecting their web browser to a page on the > authorization server (the authorization endpoint) for the resource > owner to interact with the authorization server. > >> 3. Page 16: "Even worse, some of the available options in OAuth can >> be taken in the wrong context or not enforced properly, leading to >> insecure implementations. >> These kinds of vulnerabilities are discussed at length in the OAuth >> Threat Model Document and the vulnerabilities section of this book >> (chapters 7, 8, 9, and 10)." >> >> Bear in mind that RFC 6819 was issued four years ago (in January >> 2013). Collusions between servers was considered, but collusions >> between clients was omitted, >> typically the ABC attack (Alice and Bob Collusion attack). See: >> https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html >> >> You should add some text in section 7.6 to deal with the ABC attack. >> > > Sharing bearer tokens is a well known attack surface and there's > really no way to stop that. Even PoP-style tokens can be shared since > nothing stops Bob and Alice from sharing their secrets with each > other. I've read everything you've written about the so-called ABC > attack and don't think there's more to say about it, especially in an > introductory book. > >> 4. Page 16: " Ultimately, OAuth 2.0 is a good protocol, but its far >> from perfect. We will see its replacement at some point in the >> future, as with all things >> in technology, but no real contender has yet emerged as of the >> writing of this book. >> >> I can agree with you that "OAuth 2.0is far from perfect". Can a >> protocol with so many options be a "good protocol" ? Can >> interoperability be achieved ? >> I don't think so. You then say: " but no real contender has yet >> emerged as of the writing of this book". I would rather suggest that >> you delete >> " but no real contender has yet emerged as of the writing of this book". >> > > I address the optionality and interoperability issues in that chapter, > more in chapter 2, and even more in chapter 6. Yes, it's a good > protocol, and I'm sorry you don't like it. When there's a delegation > protocol that's similarly used across millions of sites and APIs all > over the internet, then we can talk about a real contender for > replacement. I look forward to that day, but we're not there yet (and > I don't think we're anywhere near there). > >> 5. Page 17: "OAuth assumes that the resource owner is the one thats >> controlling the client". >> >> I do hope that it is not the case. The client should only be >> controlled by an end-user or by a local application and no one else. >> > > The resource owner *is* the end user. Your "should" is the same as the > assumption I'm stating. > >> >> 6. Page 17: " OAuth isnt defined outside of the HTTP protocol. Since >> OAuth 2.0 with bearer tokens provides no message signatures, >> is it not meant to be used outside of HTTPS (HTTP over TLS). >> Sensitive secrets and information are passed over the wire, and >> OAuth requires a transport layer mechanism such as TLS to protect >> these secrets". >> >> The HTTPS protocol indeed needs to be used for resource data origin >> authentication and confidentiality protection of the data being >> exchanged. >> However, protecting sensitive secrets and information passed over the >> wire using TLS does not prevent in anyway an ABC attack. TLS binding >> does not provide either any extra protection in case of an ABC >> attack. This should be stated since this is an important issue. I >> really wonder >> if you can still say: " OAuth 2.0 is a good protocol". In any case, >> OAuth 2.0 is not a protocol but a framework. >> > > It doesn't prevent people from sharing secrets with each other out of > band, as we've just talked about, but it does prevent a whole raft of > other non-collusive attacks which are significantly more malicious and > problematic. > >> 7. Page 18: "OAuth doesnt define a token format". >> >> How do you want to interoperate if no token format is being defined ? >> IETF RFCs on the standards track are primarily intended to be used to >> address interoperability. >> > > It all is based on *what* OAuth defines interoperability between. > OAuth says how a client talks to an AS and how a client talks to an > RS. It says nothing about how an RS and AS get along. Since the token > format is opaque to the client, OAuth defines no token format because > it didn't need to define one to be interoperable in the way it was > intended to be. > >> 8. Page 18 "In fact, the OAuth protocol explicitly states that the >> content of the token is completely opaque to the client application. >> >> This is even worse. In such a case, the client will be unable to make >> sure that what he got in the token is really what he was asking for: >> nothing more and nothing less. >> > > This is one of OAuth's best features, as it make things simpler. > >> 9. Page 18: " OAuth 2.0 is also not a single protocol. As discussed >> previously, the specification is split into multiple definitions and >> flows, each of which has >> its own set of use cases. The core OAuth 2.0 specification has >> somewhat accurately been described as a security protocol generator, >> because it can be used >> to design the security architecture for many different use cases. As >> discussed in the previous section, these systems arent necessarily >> compatible with each other." >> >> This is indeed a very good description of the current mess. >> > > Yes, and I hope you read the rest of the paragraph that explains the > nature of that "mess" and why it's set up the way that it is. There's > a reason for it, which is why that section is there in the book. > >> 10. Section 15.2 is not provided. Its title is : *Proof of possession >> (PoP) tokens*. I am really curious to read how you can achieve PoP in >> the case of an ABC attack. >> > > That's in chapter 15, which you don't have because you haven't bought > the book. :) Same with all of the other forward references throughout > that section. > > And you can still share secrets if they're given to you in the PoP > case. Or you can just skip the security layer and share the results of > the API calls. There's literally nothing in the world that can prevent > that level of collusion -- PoP, token binding, DRM... nothing. > >> 11. I also observed that there is no chapter dealing with *privacy >> issues.* Nowadays, it is an important topic. In particular on how to >> prevent an authorization server >> to act as *Big Brother*. A section should be added to deal with >> privacy issues. >> > > This is a topic that has been covered in great depth on the web, and > since this is a technical book we didn't feel the need to get into it. > I encourage you to write a treatise yourself, please let us know when > you do. > >> 12. Finally a typo on page 18:"Since OAuth 2.0 with bearer tokens >> provides no message signatures, *is it*not meant to be used outside >> of HTTPS (HTTP over TLS)". >> > The preview chapters are not the latest copy of the manuscript text as > it's being prepared for final publication, so a lot of typos and > format errors have been fixed already. > > Thanks for the feedback, but as I said above, in the future please > don't bring up issues you have with the book on this mailing list. > > -- Justin > >> >> Denis >> >> >>> +1 to Phil's reference to SCIM, and since it looks like you're >>> looking to do end user authentication you should look at OpenID Connect: >>> >>> http://openid.net/connect/ >>> >>> There are a lot of ways to get an authentication protocol based on >>> OAuth very, very wrong, and I've covered some of the big ones in an >>> article I wrote (with the community's help) a few years ago: >>> >>> http://oauth.net/articles/authentication/ >>> >>> Furthermore, I've covered the topic in my upcoming book, OAuth 2 In >>> Action, which you might find useful: >>> >>> https://www.manning.com/books/oauth-2-in-action >>> >>> All said, the space is not as easy as you may think it is at first >>> and there are a lot of pitfalls. But the good news is that you're >>> not the first to dive in here and there are a lot of really good >>> solutions already available. >>> >>> -- Justin >>> >>> >>> On 2/2/2017 10:52 AM, Phil Hunt (IDM) wrote: >>>> You are headed down the road to a very big domain called identity >>>> management and provisioning. >>>> >>>> You might want to look at SCIM (RFC7643, 7644) for a restful api >>>> pattern. >>>> >>>> SCIM is usually OAuth enabled but the scopes/rights have not yet >>>> been standardized. There is however some obvious access control >>>> patterns that apply from the old ldap directory world. >>>> >>>> Phil >>>> >>>> On Feb 1, 2017, at 6:36 PM, Yunqi Zhang >>> > wrote: >>>> >>>>> Hi all, >>>>> >>>>> I'm working on a set of API endpoints to allow institutions to >>>>> manage their users and records, and their users to read their own >>>>> records. >>>>> >>>>> Specifically, each institution will get a {client_id} and a >>>>> {secret} after registering with us, which allows them to create >>>>> users under its institution using [POST https://hostname/users/]. >>>>> Then the institution can also insert records for each user using >>>>> [POST https://hostname/users/:user_id/]. Once a user has been >>>>> created, he/she can read his/her own records using [GET >>>>> https://hostname/users/:user_id/]. >>>>> >>>>> In this process, there are two types of authentications I would >>>>> like to achieve, which I'm thinking about using oauth. However, I >>>>> am super new on oauth and have four questions. >>>>> >>>>> Institution authentication (e.g., company FOO will have READ and >>>>> WRITE access to https://hostname/ to create users under its own >>>>> institution, insert records for specific users): (1) Since this >>>>> part of the system will be created and run by the institution, >>>>> this should be a "client credential grant" using {client_id} and >>>>> {secret} of the institution, correct? >>>>> >>>>> End-user authentication (e.g., user John Doe of company FOO will >>>>> have READ access to https://hostname/users/:john_doe_user_id/ to >>>>> read his own personal records): (2) Because this part of the >>>>> system will probably run on the web/mobile app created by company >>>>> FOO, this should be a "resource owner credential grant" using >>>>> {username}, {password} of the specific user, correct? >>>>> >>>>> (3) Because I am allow two types of different authentications, >>>>> which will use two types of different {access_token}s I assume, >>>>> would that be something weird (or hard to build) under the oauth >>>>> model? >>>>> >>>>> (4) What if the web/mobile app created by a subset of the >>>>> companies already has its own authentication and does not want to >>>>> create another password for each of its users, what should I do? >>>>> For example, company FOO has its own authentication for its >>>>> web/mobile app and does not want to bother creating another >>>>> password for each of its user (i.e., requires only {username}), >>>>> whereas company BAR would like to create another password for each >>>>> user (i.e., requires {username} and {password}). What kind of >>>>> authentication model should I use for a scenario like this? >>>>> >>>>> Thank you very much for your help! >>>>> >>>>> Yunqi >>>> --------------310C5A4D40FAE297B2BB215D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Justin,

You said :

"Sharing bearer tokens is a well known attack surface and there's really no way to stop that.
Even PoP-style tokens can be shared since nothing stops Bob and Alice from sharing their secrets with each other".

You also said:

"There's literally nothing in the world that can prevent that level of collusion -- PoP, token binding, DRM... nothing".


Whatever kind of cryptography is being used, there is indeed are no way to stop sharing bearer tokens using implementations
that rely on software-only implementations.

Since the current documents being progressed in the Tokbind WG are based on the use of software only (i.e. TLS binding),
none of them is able to prevent that level of collusion.

Note: I also send a copy of the email to the Tokbind WG (unbearable@ietf.org) so that it can be aware of that discussion.

However, when using secure hardware in a right way, it is possible to stop sharing bearer tokens.

Idemix from IBM has been extended to take advantage of the use of smart cards. See the IRMA project (I Reveal My Attributes)
at: https://www.irmacard.org/irma/

It is mentioned in particular that "The security of IRMA depends on the protection of each Users private key".

Bob cannot indeed transmit any private key to Alice, however he is able to use private keys present in his smart card.
If Bob accepts to collaborate with Alice, a smart card simply protecting private keys does not possess sufficient properties
to counter the ABC attack (Alice and Bob Collusion attack). Bob can perform all the computations that Alice needs, even if Bob
and Alice are located in different continents.

Hence the IRMA project, based on Idemix, is vulnerable to the ABC attack.

Another solution from Microsoft (U-Prove) has the same problem, even when smart cards (or secure elements) are being used:
U-prove is also vulnerable to the ABC attack.

draft-ietf-oauth-pop-architecture-08 (OAuth 2.0 Proof-of-Possession (PoP) Security Architecture), has expired on January 9, 2017.
Since it was only relying on software, it was unable to counter the ABC attack.

The only way to stop sharing bearer tokens is to use implementations that rely on some piece of hardware that has additional properties
beyond the protection of private keys.

A secure solution certainly needs to rely on the use of software, but also on the use of secure elements that have specific functional and security properties.

Stopping the sharing of bearer tokens, is not a concern in the case of a delegation protocol, since the use of Authorization Servers should be deprecated
in this context for privacy reasons (as explained in my previous email sent to the OAuth mailing list).

However, stopping the sharing of bearer tokens is mandatory in a "different protocol where the client and resource negotiate attributes for the client
to present to the resource to fulfill its requirements".

A protocol able to stop sharing bearer tokens needs to transmit data generated by the secure elements (called APDUs - Application Protocol Data Units)
so that some APDUs can be directly verified by Authorization Servers and some other APDUs can be directly verified by Resource Servers.

In order to stop the sharing of bearer tokens, it is also necessary to specify the format of the access tokens.

I noticed that OAuth does not specify the access token itself, since the format is opaque to the protocol flow. As long as this postulate will remain,
OAuth and its derivatives won't be able to stop the sharing of bearer tokens.

As a conclusion, keeping all the postulates of OAuth 2.0 unchanged, I do agree with you that "there's really no way to stop that".

However, there's a way to stop that, but some of the postulates of OAuth 2.0 would need to be changed and some functional and security requirements
that apply to the use of secure elements would need to be added.

This might not be called "OAuth 2.0" anymore ... but this would be a secure solution.

Denis


Hi Denis,

The book is being published very shortly and the text is completed, so there aren't any more updates to be made to it. Additionally, this isn't really the forum for comments on the book (there's an online form for discussion if you're interested: https://forums.manning.com/forums/oauth-2-in-action), this is a list for discussing and developing OAuth itself. Still, most of your comments are general enough misconceptions of OAuth that they may be of interest to others so I'll answer them on the list here, inline below.


On 2/2/2017 5:47 PM, Denis wrote:

Justin,

Your are making the promotion of your book (OAuth 2 In Action), soon to be published.

I browsed through the 23 pages of Chapter 1 that are provided as a free download.

I saw the footnote from Manning Publications Co. which states:

"We welcome reader comments about anything in the manuscript"

Since Manning Publications Co. asked for it, I hope that you will be able to take into consideration some of my comments before this book is published.

I will only comment on a few sentences.

1. Page 1: "The application requests authorization from the owner of the resource and receives tokens that it can use to access the resource".

Such a model is rather restrictive and does not cover the general case where an application is willing to perform an operation on a resource
and where the resource tells to the application which kind of attributes need to be presented by the application for that specific operation.
In such a case, the resource owner is not involved in anyway at the time of the request. If this restriction remains, this should be clearly stated.


This is the model of OAuth: it's a delegation protocol, delegating from a resource owner to a client. What you're describing is a different protocol where the client and resource negotiate attributes for the client to present to the resource to fulfill its requirements. OAuth specifically abstracts that process using the authorization server, and to great success.

2. Page 10:" To acquire a token, the client first sends the resource owner to the authorization server in order to request that the resource owner authorize this client".

This sentence is not English. You cannot "send the resource owner to the authorization server". This sentence should be rephrased.


Yes you can send the resource owner to the authorization server -- generally by redirecting their web browser to a page on the authorization server (the authorization endpoint) for the resource owner to interact with the authorization server.

3. Page 16: "Even worse, some of the available options in OAuth can be taken in the wrong context or not enforced properly, leading to insecure implementations.
These kinds of vulnerabilities are discussed at length in the OAuth Threat Model Document and the vulnerabilities section of this book (chapters 7, 8, 9, and 10)."

Bear in mind that RFC 6819 was issued four years ago (in January 2013). Collusions between servers was considered, but collusions between clients was omitted,
typically the ABC attack (Alice and Bob Collusion attack). See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html

You should add some text in section 7.6 to deal with the ABC attack.


Sharing bearer tokens is a well known attack surface and there's really no way to stop that. Even PoP-style tokens can be shared since nothing stops Bob and Alice from sharing their secrets with each other. I've read everything you've written about the so-called ABC attack and don't think there's more to say about it, especially in an introductory book.

4. Page 16: " Ultimately, OAuth 2.0 is a good protocol, but its far from perfect. We will see its replacement at some point in the future, as with all things
in technology, but no real contender has yet emerged as of the writing of this book.

I can agree with you that "OAuth 2.0 is far from perfect". Can a protocol with so many options be a "good protocol" ? Can interoperability be achieved ?
I don't think so. You then say: " but no real contender has yet emerged as of the writing of this book". I would rather suggest that you delete
" but no real contender has yet emerged as of the writing of this book".


I address the optionality and interoperability issues in that chapter, more in chapter 2, and even more in chapter 6. Yes, it's a good protocol, and I'm sorry you don't like it. When there's a delegation protocol that's similarly used across millions of sites and APIs all over the internet, then we can talk about a real contender for replacement. I look forward to that day, but we're not there yet (and I don't think we're anywhere near there).

5. Page 17: "OAuth assumes that the resource owner is the one thats controlling the client".

I do hope that it is not the case. The client should only be controlled by an end-user or by a local application and no one else.


The resource owner *is* the end user. Your "should" is the same as the assumption I'm stating.


6. Page 17: " OAuth isnt defined outside of the HTTP protocol. Since OAuth 2.0 with bearer tokens provides no message signatures,
is it not meant to be used outside of HTTPS (HTTP over TLS). Sensitive secrets and information are passed over the wire, and
OAuth requires a transport layer mechanism such as TLS to protect these secrets".

The HTTPS protocol indeed needs to be used for resource data origin authentication and confidentiality protection of the data being exchanged.
However, protecting sensitive secrets and information passed over the wire using TLS does not prevent in anyway an ABC attack. TLS binding
does not provide either any extra protection in case of an ABC attack. This should be stated since this is an important issue. I really wonder
if you can still say: " OAuth 2.0 is a good protocol". In any case, OAuth 2.0 is not a protocol but a framework.


It doesn't prevent people from sharing secrets with each other out of band, as we've just talked about, but it does prevent a whole raft of other non-collusive attacks which are significantly more malicious and problematic.

7. Page 18: "OAuth doesnt define a token format".

How do you want to interoperate if no token format is being defined ? IETF RFCs on the standards track are primarily intended to be used to address interoperability.


It all is based on *what* OAuth defines interoperability between. OAuth says how a client talks to an AS and how a client talks to an RS. It says nothing about how an RS and AS get along. Since the token format is opaque to the client, OAuth defines no token format because it didn't need to define one to be interoperable in the way it was intended to be.

8. Page 18 "In fact, the OAuth protocol explicitly states that the content of the token is completely opaque to the client application.

This is even worse. In such a case, the client will be unable to make sure that what he got in the token is really what he was asking for: nothing more and nothing less.


This is one of OAuth's best features, as it make things simpler.

9. Page 18: " OAuth 2.0 is also not a single protocol. As discussed previously, the specification is split into multiple definitions and flows, each of which has
its own set of use cases. The core OAuth 2.0 specification has somewhat accurately been described as a security protocol generator, because it can be used
to design the security architecture for many different use cases. As discussed in the previous section, these systems arent necessarily compatible with each other."

This is indeed a very good description of the current mess.


Yes, and I hope you read the rest of the paragraph that explains the nature of that "mess" and why it's set up the way that it is. There's a reason for it, which is why that section is there in the book.

10. Section 15.2 is not provided. Its title is : Proof of possession (PoP) tokens. I am really curious to read how you can achieve PoP in the case of an ABC attack.


That's in chapter 15, which you don't have because you haven't bought the book. :) Same with all of the other forward references throughout that section.

And you can still share secrets if they're given to you in the PoP case. Or you can just skip the security layer and share the results of the API calls. There's literally nothing in the world that can prevent that level of collusion -- PoP, token binding, DRM... nothing.

11. I also observed that there is no chapter dealing with privacy issues. Nowadays, it is an important topic. In particular on how to prevent an authorization server
to act as Big Brother. A section should be added to deal with privacy issues.


This is a topic that has been covered in great depth on the web, and since this is a technical book we didn't feel the need to get into it. I encourage you to write a treatise yourself, please let us know when you do.

12. Finally a typo on page 18: "Since OAuth 2.0 with bearer tokens provides no message signatures, is it not meant to be used outside of HTTPS (HTTP over TLS)".

The preview chapters are not the latest copy of the manuscript text as it's being prepared for final publication, so a lot of typos and format errors have been fixed already.

Thanks for the feedback, but as I said above, in the future please don't bring up issues you have with the book on this mailing list.

-- Justin


Denis


+1 to Phil's reference to SCIM, and since it looks like you're looking to do end user authentication you should look at OpenID Connect:

http://openid.net/connect/

There are a lot of ways to get an authentication protocol based on OAuth very, very wrong, and I've covered some of the big ones in an article I wrote (with the community's help) a few years ago:

http://oauth.net/articles/authentication/

Furthermore, I've covered the topic in my upcoming book, OAuth 2 In Action, which you might find useful:

https://www.manning.com/books/oauth-2-in-action

All said, the space is not as easy as you may think it is at first and there are a lot of pitfalls. But the good news is that you're not the first to dive in here and there are a lot of really good solutions already available.

-- Justin


On 2/2/2017 10:52 AM, Phil Hunt (IDM) wrote:
You are headed down the road to a very big domain called identity management and provisioning.

You might want to look at SCIM (RFC7643, 7644) for a restful api pattern.

SCIM is usually OAuth enabled but the scopes/rights have not yet been standardized. There is however some obvious access control patterns that apply from the old ldap directory world.

Phil

On Feb 1, 2017, at 6:36 PM, Yunqi Zhang <zhangyunqi.cs@gmail.com> wrote:

Hi all,

I'm working on a set of API endpoints to allow institutions to manage their users and records, and their users to read their own records.

Specifically, each institution will get a {client_id} and a {secret} after registering with us, which allows them to create users under its institution using [POST https://hostname/users/]. Then the institution can also insert records for each user using [POST https://hostname/users/:user_id/]. Once a user has been created, he/she can read his/her own records using [GET https://hostname/users/:user_id/].

In this process, there are two types of authentications I would like to achieve, which I'm thinking about using oauth. However, I am super new on oauth and have four questions.

Institution authentication (e.g., company FOO will have READ and WRITE access to https://hostname/ to create users under its own institution, insert records for specific users): (1) Since this part of the system will be created and run by the institution, this should be a "client credential grant" using {client_id} and {secret} of the institution, correct?

End-user authentication (e.g., user John Doe of company FOO will have READ access to https://hostname/users/:john_doe_user_id/ to read his own personal records): (2) Because this part of the system will probably run on the web/mobile app created by company FOO, this should be a "resource owner credential grant" using {username}, {password} of the specific user, correct?

(3) Because I am allow two types of different authentications, which will use two types of different {access_token}s I assume, would that be something weird (or hard to build) under the oauth model?

(4) What if the web/mobile app created by a subset of the companies already has its own authentication and does not want to create another password for each of its users, what should I do? For example, company FOO has its own authentication for its web/mobile app and does not want to bother creating another password for each of its user (i.e., requires only {username}), whereas company BAR would like to create another password for each user (i.e., requires {username} and {password}). What kind of authentication model should I use for a scenario like this?

Thank you very much for your help!

Yunqi


--------------310C5A4D40FAE297B2BB215D-- From nobody Mon Feb 6 09:17:13 2017 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 A6C6A12941E for ; Sun, 5 Feb 2017 23:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com; domainkeys=pass (1024-bit key) header.sender=dirk=balfanz.net@github.com header.d=github.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 Jgw1uHGb4Q87 for ; Sun, 5 Feb 2017 23:10:57 -0800 (PST) Received: from m69-169.mailgun.net (m69-169.mailgun.net [166.78.69.169]) (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 589A5129CA9 for ; Sun, 5 Feb 2017 23:10:57 -0800 (PST) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1486365056; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=Q2VcInRbuA4whzSRXEpfkspkVM7OTGMejaK1LzA4hgY=; b=IdndI8KnFISopODriPhesh53BLYXBhy6lv55j52PELvZiwOrBniuSXKRbVWsRbAik7uK5l4b sZCsxgv89fbQed9P/R1FiDSw+2YaGFM+00AeKfp0/JQoRfP4zRW1z4j0DsGPlc5GSBhAXJne F8JWov2UqOWqR1KnBVFECIY+CIg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=EuuO1Hx6WW6//f35PWLcGRK410jVSl/0jfhl0vYubkm+ANSQ/2+SO+Tw4fHc0/a12c8CPj PKYWsLLgxgn5B+EAYcihsU9FjOzCfnXk74bWNxTZ51vXon7KiNYfUbRxAzl5lShspJ1HSuwd yNgGg0UHYp6K5qP86hO1YSl33oaFs= Sender: dirk=balfanz.net@github.com X-Mailgun-Sending-Ip: 166.78.69.169 X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Received: from github.com (Unknown [192.30.252.42]) by mxa.mailgun.org with ESMTP id 58982180.7fc991e1c6f0-smtp-out-n01; Mon, 06 Feb 2017 07:10:56 -0000 (UTC) Date: Sun, 05 Feb 2017 23:10:55 -0800 From: balfanz To: unbearable@ietf.org Message-ID: <5898217f534e7_142e53fc5bfb9dc2c5144b@hookshot-fe-6dbb0c4.cp1-iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_5898217f531f2_142e53fc5bfb9dc2c51349"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Mon, 06 Feb 2017 09:17:11 -0800 Subject: [Unbearable] [TokenBinding/Internet-Drafts] df3a15: 'TB key' terminology cleanup, see #87 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: balfanz 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: Mon, 06 Feb 2017 07:10:59 -0000 ----==_mimepart_5898217f531f2_142e53fc5bfb9dc2c51349 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: df3a1597df4fee0c170787a34d3585e50e934798 https://github.com/TokenBinding/Internet-Drafts/commit/df3a1597df4fee0c170787a34d3585e50e934798 Author: JeffH Date: 2017-01-31 (Tue, 31 Jan 2017) Changed paths: M draft-ietf-tokbind-https-08.xml Log Message: ----------- 'TB key' terminology cleanup, see #87 Commit: 5c1159f0f6215caa7c25153d90a5cabbc6b230a2 https://github.com/TokenBinding/Internet-Drafts/commit/5c1159f0f6215caa7c25153d90a5cabbc6b230a2 Author: JeffH Date: 2017-02-02 (Thu, 02 Feb 2017) Changed paths: M draft-ietf-tokbind-https-08.xml Log Message: ----------- back to 'key pair' in one place Commit: 50ca5ade28ed789facaf96a2d592ee2cea325f58 https://github.com/TokenBinding/Internet-Drafts/commit/50ca5ade28ed789facaf96a2d592ee2cea325f58 Author: balfanz Date: 2017-02-05 (Sun, 05 Feb 2017) Changed paths: M draft-ietf-tokbind-https-08.xml Log Message: ----------- Merge pull request #92 from equalsJeffH/HTTPSTB-cleanup2 HTTPSTB: 'TB key' terminology cleanup, see #87 Compare: https://github.com/TokenBinding/Internet-Drafts/compare/59de987dc1ef...50ca5ade28ed ----==_mimepart_5898217f531f2_142e53fc5bfb9dc2c51349-- From nobody Mon Feb 6 09:17:39 2017 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 3066612945D for ; Sun, 5 Feb 2017 23:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.341 X-Spam-Level: X-Spam-Status: No, score=-7.341 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 4bd4g2hT_JiL for ; Sun, 5 Feb 2017 23:10:50 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F2A12941E for ; Sun, 5 Feb 2017 23:10:50 -0800 (PST) Date: Sun, 05 Feb 2017 23:10:49 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1486365049; bh=55i/dMufxpE+P4k6Edq+WVhi7vtObeVprSKEsNObyXQ=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=GUTM7/FJQtKdhm0B9YtgvkIH371K52nEFSKiq7MdbhkNTxo1I0+LIGb/iHHnZc3Yp WjRNhsFwanulclsP26szuShyWJ8Au+be7J7Yygrwlk+ZpFBhmrBHTTaYLR+bio8OAu TpUnGPYIblddHV0scm/7G8ss/p3dK6KynmAzOa2c= From: balfanz To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58982179340ab_678c3fb570ae51402250f0"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: balfanz X-GitHub-Recipient: unbearable-ML X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Mon, 06 Feb 2017 09:17:36 -0800 Cc: Subscribed Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: 'TB key' terminology cleanup, see #87 (#92) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Reply-To: TokenBinding/Internet-Drafts 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: Mon, 06 Feb 2017 07:10:52 -0000 ----==_mimepart_58982179340ab_678c3fb570ae51402250f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit balfanz approved this pull request. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/TokenBinding/Internet-Drafts/pull/92#pullrequestreview-20205118 ----==_mimepart_58982179340ab_678c3fb570ae51402250f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@balfanz approved this pull request.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58982179340ab_678c3fb570ae51402250f0-- From nobody Mon Feb 6 09:17:41 2017 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 9CBD612945D for ; Sun, 5 Feb 2017 23:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, 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=github.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 mGUn65bL_vf3 for ; Sun, 5 Feb 2017 23:10:56 -0800 (PST) Received: from o9.sgmail.github.com (o9.sgmail.github.com [167.89.101.2]) (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 94429129C90 for ; Sun, 5 Feb 2017 23:10:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=EPE2ucESHunw3ZXW2h2TUCsBN7U=; b=FC0ySapLrTUD4PGk J5QrZFVawNvS31WoqROW8KY9HIIi3fvK7vG+mCRuxZoVcFwPQ6CfmtSaP9KKu7np yly9MTkPtfEYa2ab+yan2oMkP9MizQKv/1xkSfb+jKcr/bFUCP+XK78KRE9hi18H dlidjbQJ/X8KrUkhxbc8W3VXFzo= Received: by filter0896p1mdw1.sendgrid.net with SMTP id filter0896p1mdw1-30660-5898217E-2E 2017-02-06 07:10:55.005835636 +0000 UTC Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2a-ext-cp1-prd.iad.github.net [192.30.253.16]) by ismtpd0005p1iad1.sendgrid.net (SG) with ESMTP id deZ4Tff0SbGyqdJVbvGCLQ for ; Mon, 06 Feb 2017 07:10:54.974 +0000 (UTC) Date: Sun, 05 Feb 2017 23:10:54 -0800 From: balfanz To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5898217ed820d_72e73f92c9da113c29653c"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: balfanz X-GitHub-Recipient: unbearable-ML X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org X-SG-EID: 9Yqp9dCIIwZxB0MVAPExrXlt7a4/46ALD9aG/N3UOYogJ18zkv8oVUDA1G9z3utumz8S/Im9QIkna8 CxgWW6oU+dAFDJThcIX37GbFlZ+MzdrV9Hp2rAXBVdow0ej1yo5SQ8kP+bosUtIqQ0eHz2nk980Dgq +PPfQKLqGfR08Z6bgsjQS98zWt+yKFLRUg1/86WquiXJtjJmAMgeLL+NKF+RfxL1ffVW8ZKAD7Sxh5 U= Archived-At: X-Mailman-Approved-At: Mon, 06 Feb 2017 09:17:36 -0800 Cc: Subscribed Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: 'TB key' terminology cleanup, see #87 (#92) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Reply-To: TokenBinding/Internet-Drafts 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: Mon, 06 Feb 2017 07:10:58 -0000 ----==_mimepart_5898217ed820d_72e73f92c9da113c29653c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Merged #92. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/TokenBinding/Internet-Drafts/pull/92#event-949819172 ----==_mimepart_5898217ed820d_72e73f92c9da113c29653c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Merged #92.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_5898217ed820d_72e73f92c9da113c29653c-- From nobody Mon Feb 6 09:17:44 2017 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 C3637129C90 for ; Sun, 5 Feb 2017 23:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 OQ6ZPIRXqg7X for ; Sun, 5 Feb 2017 23:12:36 -0800 (PST) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext7.iad.github.net [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24041129CA8 for ; Sun, 5 Feb 2017 23:12:36 -0800 (PST) Date: Sun, 05 Feb 2017 23:12:34 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1486365154; bh=lYODNGmwpbREHHDhZeQMrX8s0eey4KkwUIFbXUg24u4=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=11r8yRud1eXPs8IuMMvnzf6wVHVU+nKej2dokQOKQlsN785Hi2P7bsdC02zW/b4bj BGFLhSffko3UzlHvMz5fwi5WnfFqS33cC7+HxHBAokPzdxWCXVFPpKK6fb1b9INSQj R3vsC07B0brA4oDA5mw3mslzjSrt5l7ALV4EuR/U= From: balfanz To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_589821e2e7765_76f93ff18cbbf130544248"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: balfanz X-GitHub-Recipient: unbearable-ML X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Mon, 06 Feb 2017 09:17:36 -0800 Cc: Subscribed Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: TBPROTO: "token binding key" terminology ambiguity.. (#87) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Reply-To: TokenBinding/Internet-Drafts 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: Mon, 06 Feb 2017 07:12:39 -0000 ----==_mimepart_589821e2e7765_76f93ff18cbbf130544248 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #87. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/TokenBinding/Internet-Drafts/issues/87#event-949820576 ----==_mimepart_589821e2e7765_76f93ff18cbbf130544248 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #87.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_589821e2e7765_76f93ff18cbbf130544248-- From nobody Mon Feb 6 09:17:47 2017 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 2AE57129C90 for ; Sun, 5 Feb 2017 23:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.57 X-Spam-Level: X-Spam-Status: No, score=-4.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.887, 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=github.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 dHNFW_IjIjq9 for ; Sun, 5 Feb 2017 23:12:38 -0800 (PST) Received: from o5.sgmail.github.com (o5.sgmail.github.com [192.254.113.10]) (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 EE90D12945D for ; Sun, 5 Feb 2017 23:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=q6dym9CksgTdRgYxJ+hjjw/fvQw=; b=lkmXoY7dIoBuwLC9 7eCSuv8a13cvrKMXa7uz5hoZjjfxz2oYuhGbkiMjxygF6Kb9Qb8e5sDd4bymdQBQ sz2dkFHyPPVx9mLud8bA/vXsMRLwHyf2fzvcXniX3yCKuuyxmFzNClVnkGgM7yiU nQ2BsU8yASA8/h52wesWGLkZ3Cg= Received: by filter0590p1mdw1.sendgrid.net with SMTP id filter0590p1mdw1-8967-589821E2-31 2017-02-06 07:12:34.96997356 +0000 UTC Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [192.30.253.17]) by ismtpd0002p1iad1.sendgrid.net (SG) with ESMTP id wJqGoe0zQjqrYO6isnr7-Q for ; Mon, 06 Feb 2017 07:12:35.067 +0000 (UTC) Date: Sun, 05 Feb 2017 23:12:34 -0800 From: balfanz To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_589821e2f2c8c_30353fa6681c113438544b"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: balfanz X-GitHub-Recipient: unbearable-ML X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org X-SG-EID: 9Yqp9dCIIwZxB0MVAPExrXlt7a4/46ALD9aG/N3UOYrcz92bCCqZ2mch/+BB3XBdMePbZgKyn+nk7h QHfkLGJZRFMx3DOILxMx9PHQZNbBfGD9ObeqnScp1nhE8pzIMZP7W6dQSLJhlDt98MILdFDWjx1+gA 6kM1/5HBIYcfiZ7L+Wbn/lXySnI+IBFkpazaaSVQ5deAvimatB9ExezaUA== Archived-At: X-Mailman-Approved-At: Mon, 06 Feb 2017 09:17:36 -0800 Cc: Subscribed Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: TBPROTO: "token binding key" terminology ambiguity.. (#87) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Reply-To: TokenBinding/Internet-Drafts 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: Mon, 06 Feb 2017 07:12:40 -0000 ----==_mimepart_589821e2f2c8c_30353fa6681c113438544b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Addressed in https://github.com/TokenBinding/Internet-Drafts/pull/92. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/TokenBinding/Internet-Drafts/issues/87#issuecomment-277601864 ----==_mimepart_589821e2f2c8c_30353fa6681c113438544b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Addressed in #92.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_589821e2f2c8c_30353fa6681c113438544b-- From nobody Mon Feb 6 09:17:49 2017 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 C701B129418 for ; Mon, 6 Feb 2017 09:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.403 X-Spam-Level: X-Spam-Status: No, score=-0.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 FRRryuaUvjR1 for ; Mon, 6 Feb 2017 09:16:05 -0800 (PST) Received: from o7.sgmail.github.com (o7.sgmail.github.com [167.89.101.198]) (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 3ACE7129408 for ; Mon, 6 Feb 2017 09:16:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=MsF9GPY6hjbIqCWvpFny8cSVtck=; b=JerGhVgT4d+0H8pG qz5LSML5rmH6d8mQP2XuJJktQZXj7BUs1npGd5kqWnaYs+4BRxSjdovKoSq5bAoa NKydGS+eQpoA5SEUDkhMmBpVAjXGgAIy5cEqkt8bO0mb55AHnsEas1xjDt3N7HG3 RnMG4ZpfapZ34oI/YciA4zXUfD4= Received: by filter1121p1mdw1.sendgrid.net with SMTP id filter1121p1mdw1-26814-5898AF53-5A 2017-02-06 17:16:03.876037979 +0000 UTC Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2a-ext-cp1-prd.iad.github.net [192.30.253.16]) by ismtpd0002p1iad1.sendgrid.net (SG) with ESMTP id eYv2PkdvTAmdCdJtoSPzdA for ; Mon, 06 Feb 2017 17:16:03.761 +0000 (UTC) Date: Mon, 06 Feb 2017 09:16:03 -0800 From: =JeffH To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5898af53a536b_6763fe121089138276919"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: equalsJeffH X-GitHub-Recipient: unbearable-ML X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org X-SG-EID: 9Yqp9dCIIwZxB0MVAPExrXlt7a4/46ALD9aG/N3UOYrqy61MUdyZhRIUP3WzG4D7w6TojJhMDnchmK 5BBajl/tuz9mu7o8EvPJYYHDcmcMuCnk3N7P+xiJHbN/f3z8e6DpJ0OsILbxIedA7ekim5/lEvBzNO 1z3X7ffZO3dM4UJyyVHpggXEE26TgQ/o0TaATbV7gAexHKLzRoMJbAJ3Ww== Archived-At: X-Mailman-Approved-At: Mon, 06 Feb 2017 09:17:36 -0800 Cc: Subscribed Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: TBPROTO: "token binding key" terminology ambiguity.. (#87) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Reply-To: TokenBinding/Internet-Drafts 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: Mon, 06 Feb 2017 17:16:07 -0000 ----==_mimepart_5898af53a536b_6763fe121089138276919 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Just for completeness sake, PR #92 addressed this for HTTPSTB, but not TBPROTO -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/TokenBinding/Internet-Drafts/issues/87#issuecomment-277748831 ----==_mimepart_5898af53a536b_6763fe121089138276919 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Just for completeness sake, PR #92 addressed this for HTTPSTB, but not TBPROTO

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_5898af53a536b_6763fe121089138276919-- From nobody Mon Feb 6 10:16:51 2017 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 B16791295AE for ; Mon, 6 Feb 2017 10:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlWqsWsCpHZT for ; Mon, 6 Feb 2017 10:16:49 -0800 (PST) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id 3548B1295A9 for ; Mon, 6 Feb 2017 10:16:49 -0800 (PST) Received: (qmail 24649 invoked by uid 0); 6 Feb 2017 18:16:44 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy3.mail.unifiedlayer.com with SMTP; 6 Feb 2017 18:16:44 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id hWGg1u0102UhLwi01WGjou; Mon, 06 Feb 2017 11:16:44 -0700 X-Authority-Analysis: v=2.1 cv=Pets2ERd 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=n2v9WMKugxEA:10 a=48vgC7mUAAAA:8 a=5YsoP0Yi3H3MacMIDrYA:9 a=QEXdDO2ut3YA:10 a=0OUrREWNrsQA:10 a=987wj2eQoPoA:10 a=w1C3t2QeGrPiZgrLijVG:22 Received: from [173.224.162.69] (port=15692 helo=[10.225.80.59]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1canqC-00080h-Ho; Mon, 06 Feb 2017 11:16:40 -0700 To: Andrei Popov , Dirk Balfanz From: =JeffH Message-ID: <4ab4ab60-3798-d227-8f91-d310b5b3e9c7@KingsMountain.com> Date: Mon, 6 Feb 2017 10:16:39 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 173.224.162.69 X-Exim-ID: 1canqC-00080h-Ho X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.225.80.59]) [173.224.162.69]:15692 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 3 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Cc: IETF TokBind WG Subject: Re: [Unbearable] HTTPSTB updates and respin WGLC 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: Mon, 06 Feb 2017 18:16:50 -0000 cf: [ i suspect Dirk had not seen Andrei's email prior to merging PR #92 ] Andrei wrote on Fri, 3 Feb 2017 01:51:23 +0000: > > A few editorial suggestions below. > >> I think this needs to be rephrased: >> The Token Binding ID of a TLS connection is constructed using >> the public key OF a private-public key pair, OF which >> the client proves possession OF the private key to >> the server. > Perhaps better to just split this into two sentences: > > The Token Binding ID of a TLS connection is constructed using the > public key of a private-public key pair. > The client proves possession of the corresponding private key. thx, queued. >> (clients use different Token Binding key pairs for different... >> The scoping for those Token Binding key pairs generated by Web >> browsers in... >> browsers MAY use different key pair scoping rules. >> For privacy reasons, clients use different Token Binding key pairs >> of the Token Binding key pair. It is possible that the Token >>
> [...] > > While not wrong, all these key pairs seem unnecessary. The Token > Binding key is asymmetric, so clearly it has a private and public > component. It seems inaccurate and potentially confusing to speak of a singular "token binding key" when we have explicitly termed it a "private-public key pair", and it is indeed two separate (although related) artifacts. Though, in the plural case, would using "keys" rather than "key pairs" work for you? >> contains both: a proof of possession of the provided Token Binding >> ID, as well as a proof of possession of the referred Token Binding >> ID > It's a proof of possession of a Token Binding key, I think. ok, queued, thx again. =JeffH From nobody Mon Feb 6 10:30:07 2017 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 F3B3A1295BF for ; Mon, 6 Feb 2017 10:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.889 X-Spam-Level: X-Spam-Status: No, score=-3.889 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=-1.887, 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 q0pirCKxCdTx for ; Mon, 6 Feb 2017 10:30:04 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0099.outbound.protection.outlook.com [104.47.40.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11C7612706D for ; Mon, 6 Feb 2017 10:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KD9lmfyjFsMubtKYxql86Z+zU+PlpjtpFbeCbIVa+Qg=; b=o1UrlXal1wPUbA2iDqc/UwYbGaX2Dm6Wuk2+D4z7NdO2LC+Ys4yymHvDZp/SbmEC+VvhxNIXkwSyErJN6cUUfWfpe6po8+g6vr5Avy/4vx/OYfgZfWdcF3J6Yvx5H/Vb3H+vbIN6t8XyWxY/maNlThRxzK7ZC+KzXzoeVGUBkM4= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Mon, 6 Feb 2017 18:30:00 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.025; Mon, 6 Feb 2017 18:30:00 +0000 From: Andrei Popov To: =JeffH , Dirk Balfanz Thread-Topic: [Unbearable] HTTPSTB updates and respin WGLC Thread-Index: AQHSgKU2H782DYLSAEOPK8wfkxaST6FcTAuw Date: Mon, 6 Feb 2017 18:30:00 +0000 Message-ID: References: <4ab4ab60-3798-d227-8f91-d310b5b3e9c7@KingsMountain.com> In-Reply-To: <4ab4ab60-3798-d227-8f91-d310b5b3e9c7@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: bcbb0d66-7e91-4944-a4fe-08d44ebe2925 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0842; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 7:sTqYQcVS2W9BeE/LJ8zbYHAnKXdzomnw1xdm8zyhlL6X1aHu7Ol8SDOZc2TINiW3Nz0dfjMySxbZfFQANu9PM0XeB+xbN4DokbZCpfsiAbaUEHXk/wW1ieEj6IB6jmbTv5U7dkHO2eW6SAwAYd7Gif28sYaL+Nw4gofKdbgFcl81IWtLMu2Ot4K59M6lLWSIxHsn22QHIFmN/NEnZRf+rl2iXqMl4+kV+UV7ZqqUfkTx6mGFw0JKsvXn+4zqINAWrtvlFv3pEIaP93jT/nZZLU8BXNyt2mLMgfQ9Uj0R2E5mHD7ZJ1kKeZB7lRIXAPPaZZyWcc5pM629+6SmL46X+RXh3WeRec6Ck6CMaVf8Xaklb4tJM1w9IGvCGl3nc1qzVSgMHAJe4WHkaSOFaaXOER9pa66Fo46O9vJ/6f2wx+tWRFbWmdTGHxNC9Al6OYNwqEwbdS82R/18vMiPmR6BcjgrbfuHcm1SLRrzM/Sl1WydFUktR/Pe1aIni+420P63LNZOWAfnEMaN4IuFApxFwEA5ikULtp9/YFZjoJcubLU= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(20170203043)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 0210479ED8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39410400002)(39850400002)(39860400002)(377454003)(13464003)(199003)(189002)(25786008)(105586002)(8936002)(106116001)(106356001)(8676002)(5660300001)(81156014)(81166006)(68736007)(55016002)(2900100001)(38730400001)(99286003)(6436002)(5005710100001)(10290500002)(77096006)(10090500001)(229853002)(6506006)(6306002)(2906002)(8990500004)(9686003)(86362001)(15650500001)(4326007)(189998001)(97736004)(53936002)(5001770100001)(33656002)(86612001)(3280700002)(3660700001)(6116002)(2950100002)(7736002)(305945005)(74316002)(7696004)(102836003)(50986999)(92566002)(122556002)(6246003)(54356999)(101416001)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 06 Feb 2017 18:30:00.4306 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Cc: IETF TokBind WG Subject: Re: [Unbearable] HTTPSTB updates and respin WGLC 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: Mon, 06 Feb 2017 18:30:06 -0000 > Though, in the plural case, would using "keys" rather than "key pairs"=20 work for you? This is just aesthetic preference; I can live with either phrasing... -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of =3DJeffH Sent: Monday, February 6, 2017 10:17 AM To: Andrei Popov ; Dirk Balfanz Cc: IETF TokBind WG Subject: Re: [Unbearable] HTTPSTB updates and respin WGLC cf: [ i suspect Dirk had not seen Andrei's email prior to merging PR #92 ] Andrei wrote on Fri, 3 Feb 2017 01:51:23 +0000: > > A few editorial suggestions below. > >> I think this needs to be rephrased: >> The Token Binding ID of a TLS connection is constructed using >> the p= ublic key OF a private-public key pair, OF which >> the client proves poss= ession OF the private key to >> the server. > Perhaps better to just split this into two sentences: > > The Token Binding ID of a TLS connection is constructed using the > pub= lic key of a private-public key pair. > The client proves possession of the corresponding private key. thx, queued. >> (clients use different Token Binding key pairs for different... >> The scoping for those Token Binding key pairs generated by Web >> brow= sers in... >> browsers MAY use different key pair scoping rules. >> For privacy reasons, clients use different Token Binding key pairs >> = of the Token Binding key pair. It is possible that the Token >>
> [...] > > While not wrong, all these key pairs seem unnecessary. The Token > Bind= ing key is asymmetric, so clearly it has a private and public > component. It seems inaccurate and potentially confusing to speak of a singular "token= binding key" when we have explicitly termed it a "private-public key pair"= , and it is indeed two separate (although related) artifacts. Though, in the plural case, would using "keys" rather than "key pairs"=20 work for you? >> contains both: a proof of possession of the provided Token Binding >> = ID, as well as a proof of possession of the referred Token Binding >> ID = > It's a proof of possession of a Token Binding key, I think. ok, queued, thx again. =3DJeffH _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable From nobody Mon Feb 6 15:51:44 2017 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 D70691294E6 for ; Mon, 6 Feb 2017 15:51:42 -0800 (PST) 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 WXCo6UqfFo88 for ; Mon, 6 Feb 2017 15:51:41 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d: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 CF86F1293F5 for ; Mon, 6 Feb 2017 15:51:40 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id s186so72292684qkb.1 for ; Mon, 06 Feb 2017 15:51:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4xYW9gc1EWrpp1H98R0vDtpQH+xVnxFcIuVNfJba3R8=; b=P73CFKAluZyEgqxg5L2W0TEzR1JVwqrYbspxWUCLceMlgxjCdGpLHrL1/RB4K5ADGO 0FMdZ2jkNr/dQEWp98qHKWh6YltdJ/7Dlh24PuW4zuZsyxdwsAfvkwRha2EYxQL1tF/f NLOMUPW04auGUgmrwuZo4DC5nTYx5Fd7D8yR7F1/5llPT81jqV43ZYMiqsf4Afi8qcjL g+Fs7CG+/kkzQ3RHkenYUKg1PKfhOdbEnqWbZUr1dLkdysBvzMOveuIMFZKnmtUABPje PyIyUkK+LB+Euwy3lXcIGCOSfGtFgwxqyPpoXCYmEQJAs180gUSzEDiGTnJWSh4fTJ2w mb2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4xYW9gc1EWrpp1H98R0vDtpQH+xVnxFcIuVNfJba3R8=; b=jRz8GEbdTJTv3yAH1mnaarP16WE1hLOfsljRg8RzkrPzoViMb36LonZaV9tlsfz6bP Fqy30X7M6OIgTJmMpOkBn7rxmwq+36BhmmE48CIFOJxCztItRx0n13Ilx4m57XpET2Tx F4tDR7iEoH2RaX7EiX8MqcRTHV1rWWlOxSSwIzZpf8p2Dux3H3Dbo/SarZNsOxu8WMh0 761dxYtyu5EUd2T2oPipo8kSI4nsTQBFe57YC4gu+UdfLWGvWpevVkH2cKHuwSGISbz+ LXA1Lvq5CSzYHodqpKR1UbPiSdJAuEDhpZ68jReEMSm4bodnVjbeRgrzIpRLl7cFYCAz YLwQ== X-Gm-Message-State: AMke39lwzAnM5ilGA7JrQp/Sar0Z+GAPBT8eGqXBrYp1A7F3+GFGhulb/RxmImA6LPNFDac3 X-Received: by 10.55.210.70 with SMTP id f67mr11445228qkj.304.1486425099833; Mon, 06 Feb 2017 15:51:39 -0800 (PST) Received: from [192.168.8.100] ([181.201.111.117]) by smtp.gmail.com with ESMTPSA id w44sm1871861qta.4.2017.02.06.15.51.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 15:51:38 -0800 (PST) From: John Bradley Message-Id: <6801C875-65FA-4C4F-B45B-59AD7D734845@ve7jtb.com> Content-Type: multipart/signed; boundary="Apple-Mail=_FA3B6F07-717C-4EC9-9338-0F7BC1F71912"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 6 Feb 2017 20:51:35 -0300 In-Reply-To: To: Andrei Popov References: <4ab4ab60-3798-d227-8f91-d310b5b3e9c7@KingsMountain.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF TokBind WG , Dirk Balfanz , =JeffH Hodges Subject: Re: [Unbearable] HTTPSTB updates and respin WGLC 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: Mon, 06 Feb 2017 23:51:43 -0000 --Apple-Mail=_FA3B6F07-717C-4EC9-9338-0F7BC1F71912 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 When do you think you guys can push =E2=80=9Cfinal" versions for the WG? I am hoping we can have these specs wrapped up by Chicago. John B. > On Feb 6, 2017, at 3:30 PM, Andrei Popov = wrote: >=20 >> Though, in the plural case, would using "keys" rather than "key = pairs"=20 > work for you? >=20 > This is just aesthetic preference; I can live with either phrasing... >=20 > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of = =3DJeffH > Sent: Monday, February 6, 2017 10:17 AM > To: Andrei Popov ; Dirk Balfanz = > Cc: IETF TokBind WG > Subject: Re: [Unbearable] HTTPSTB updates and respin WGLC >=20 > cf: = > [ i suspect Dirk had not seen Andrei's email prior to merging PR #92 ] >=20 > Andrei wrote on Fri, 3 Feb 2017 01:51:23 +0000: >>=20 >> A few editorial suggestions below. >>=20 >>> I think this needs to be rephrased: >>> The Token Binding ID of a TLS connection is constructed using >> = the public key OF a private-public key pair, OF which >> the client = proves possession OF the private key to >> the server. >> Perhaps better to just split this into two sentences: >>=20 >> The Token Binding ID of a TLS connection is constructed using the > = public key of a private-public key pair. >> The client proves possession of the corresponding private key. >=20 > thx, queued. >=20 >=20 >>> (clients use different Token Binding key pairs for different... >>> The scoping for those Token Binding key pairs generated by Web >> = browsers in... >>> browsers MAY use different key pair scoping rules. >>> For privacy reasons, clients use different Token Binding key pairs = >> of the Token Binding key pair. It is possible that the Token >> =
>> [...] >>=20 >> While not wrong, all these key pairs seem unnecessary. The Token > = Binding key is asymmetric, so clearly it has a private and public > = component. >=20 > It seems inaccurate and potentially confusing to speak of a singular = "token binding key" when we have explicitly termed it a "private-public = key pair", and it is indeed two separate (although related) artifacts. >=20 > Though, in the plural case, would using "keys" rather than "key pairs"=20= > work for you? >=20 >>> contains both: a proof of possession of the provided Token Binding = >> ID, as well as a proof of possession of the referred Token Binding = >> ID > It's a proof of possession of a Token Binding key, I think. >=20 > ok, queued, thx again. >=20 > =3DJeffH >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_FA3B6F07-717C-4EC9-9338-0F7BC1F71912 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILMTCCBUcw ggQvoAMCAQICEEAfBHP+tuqufC4R+F+Tu54wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAyIENsaWVudCBDQTAeFw0xNjA4MTIy MTE5NDFaFw0xODA4MTIyMTE5NDFaMIGCMQswCQYDVQQGEwJDTDEiMCAGA1UECAwZTWV0cm9wb2xp dGFuYSBkZSBTYW50aWFnbzEWMBQGA1UEBwwNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAwwMSm9obiBC cmFkbGV5MSAwHgYJKoZIhvcNAQkBFhF2ZTdqdGJAdmU3anRiLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALhTcSiDGvVrm4hlJA8WyFcWWe0dqnuJzstQYTaF281JFOEPA/13kQYI JMXAEUcS7NvW7KdUI0tHU0N6RTo0Ilf1E1nm8No++eqHO8pFUZ/cidpv0r+1Qcl9EgrpbZ00Y7Xg pq06EZELzJAmds4QQcsTKdpLNFbVcFnM11i2Gj5VNsYgO+qPO2AS8rLHkgDWnNkc9/lA+ZK5wGiU zxPU9KnIrERoTif3Zk7KjLvFpBWYD60M/lNoHZ5zxYgmYLmvoM1TSLn4Ms57wwT5MieV2l0aqlGC 7CKNa6XyeL1B0y0wSxL3PJQS4vSLDnttZC7od2A6yjeUMyM3rQ41vqUIMc8CAwEAAaOCAcMwggG/ MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUmA9bUmBmTYkCcZ3yYv8IRRP2nN4wHwYDVR0jBBgwFoAUmZerGDU6i1lFQ5iy cnHI9PsJzxYwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNz bC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGll bnQyLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xp ZW50Mi5jcmwwHAYDVR0RBBUwE4ERdmU3anRiQHZlN2p0Yi5jb20wIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMFUGA1UdIAROMEwwDAYKKwYBBAGBtTcGATA8BgsrBgEEAYG1NwEC BTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4IBAQBqcYJfFA/ITkX4L6JihqW168Wog1BOfkbPXO+wPn5G9P1NwruGfu41b70EPPwV vol+/j+qhSSrDjFyfNBsq4G45GRR6hwx0ei/bH0UW15Y63ASYPkNlj3ydCcvhw5ItWD5aYPphBx9 C7tLnQ7ow09cqt2CIgPd3W/IGri7p4hWPbdcX0oFIhJcDxmCwTcWyoVoIo4aas5gP44LPGneCoqI lXQMJinwneEnKd7rWXlzVWv7geaH3t79zARSw9ev9F4E61cDuHi+vgTFEpio7oxybqfj99yLibhX uZjReYnYbDMRiWDXduVIrIGYwmnUuD8a0b20kJgHm+FEgB6UMa9JMIIF4jCCA8qgAwIBAgIQXLZI bkcMmMZ/9oDbZErijTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1 WhcNMzAxMjE2MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDIgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7g9Q jJUJI4Ss9VBqj9Y3ok4h/TIJZUc+rzj61Rv3hNB/yeEEC1fz3i/EU+MXOOGxM7KCbtCIcJxHIW/k 8RP6sPPMO4cTg7sNzfBWsYsemtY6fN/kVr2R2X+/PjvtxmAaXpGX0znvQPxaE123IMGXy0zEKHZ/ nJDZ199TP9TNn9v+1QO0AZb4oaJ7ch0DpSJa8kF5xiNFDAg9taKKSrVuPHJL9MFFYPIqwShjHg+u YEzjfxbMP2QWwamnaA9Y7fORSDNapduFlARAcDtXdMpAijiG4HKnrN323I0Ka7lDTAWyLtTDCETK sI8fzOyL0inEu1WEVpdPytm8s1rwQB4f9QIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQr MCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRa MFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBSZl6sYNTqLWUVDmLJy ccj0+wnPFjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUd IAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4ICAQCZQUEEzvYk9U4wNHhDu1f9QGwbzAH4m4wIKH8ZidNYwZhyoNKW041iJ002KMW9 ywYM95n4770tT45yH29vTMlZtBvz0h44KuxMLNXRCTDwvV07sT39nPjFi5MpwZaLVueNiaa1vok1 n2Wn8lLcyCltYZNGAEifM0ko/A/vvckftFIZG75RAiZHYtfnrdBGiOxyF+nHI9a33BRX5Vl/3z0+ uHZ/Y6YPbNJ7iboOFrFZBCtt+lp3WaDB62ZoBewiMmd09JrqmMJAEgw3EbfQNtaPzHPg/EOhlZik Rgd4BCrzrbIqB2RKib+gnQJt2uoJaKOaV90S9Xgs3PC837OE9CEmY6/MTTG0xpbLh2hR/rLQ3sCr H56aODeuDrQBq85lXxRbDCERDUR7FZUhHv+i1aQaY59NPu26hDd6nqksSDq2mCddpidPBuGJz9lN X2nRyGkudDuWV6gIr6AZfaYv+ggTXOcCDJZFzMhWdLC7CPvRKxQ7vTiYV+4lgqOvV9MnZc149PPt itTysq/oOv70zx7q+tyaLTa4cqFhCclhIwSwOEJiV3xqQebvmwsDX7BaXGAJZIhbdUbNr3poEgct 6uAxw2zyr69WCJmTUUhz/k1/TT/eCUZJqnMg/6mje7tiVdaUQJcBtJ6cq5+mUDNUB1fohW8EOFai zFpP/0FaP62ctTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMiBDbGllbnQgQ0ECEEAfBHP+tuqufC4R+F+Tu54wCQYFKw4DAhoF AKCCAZkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjA2MjM1 MTM2WjAjBgkqhkiG9w0BCQQxFgQU9beabvfqf9x2P2Oy0rz+S2/yRVowgZoGCSsGAQQBgjcQBDGB jDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIg Q2xpZW50IENBAhBAHwRz/rbqrnwuEfhfk7ueMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIgQ2xpZW50IENBAhBA HwRz/rbqrnwuEfhfk7ueMA0GCSqGSIb3DQEBAQUABIIBADDHC27ujxrIoAs06t+huumEZhuAUpWi Kb3YuD1RKrqFtxPAiWOYmY6avFNuQgS0ipc4AW4EIq+TBQqCqOm4EtF7SoCwEEU3QPn/sGDRCf2a CsRKeMjFAICZLyHkdMkDqZ4vGJCPrNxsPVjYXvdcv2sUMgvQvNg+emDv7cbc1as0xhujxzs7WXZo aJW9x2TT1gxU1DLaiPK70/hY45dsnRAunl+Tk/b360AN2e9RgXXI03390CR6tv7ipQLE1b52u5ck SBfFkdNuP06hXj4RZWKsrF2avQ0nUrlxiT1YN2R9iJZEC/voWsEhXAD/FPl47iRwgato1JOo4wfo NodLzfsAAAAAAAA= --Apple-Mail=_FA3B6F07-717C-4EC9-9338-0F7BC1F71912-- From nobody Mon Feb 6 16:01:15 2017 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 194D21297BF for ; Mon, 6 Feb 2017 16:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 INmgi302BUTB for ; Mon, 6 Feb 2017 16:01:13 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0113.outbound.protection.outlook.com [104.47.32.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 364E6129513 for ; Mon, 6 Feb 2017 16:01:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pHJStSsdQmw6g65O98cBPO5W3dC8HYcZD37nquAgZT4=; b=bD7c68Pq0jLC/JPSVJragXlh6j71RuHXlCLzxHTKyFddMwXOvouZjtolQJ9cZIJ28j37RAKzs4Hu/mg7EqlwM709GLtuJ+oobHJz5irpCKocVDhsJAflGV+dBB29cRWRTDidOwI22T9pJjriSq6KWbRzdknadVMyVBb+Y4MLKUM= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0841.namprd03.prod.outlook.com (10.160.163.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 7 Feb 2017 00:01:09 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.025; Tue, 7 Feb 2017 00:01:09 +0000 From: Andrei Popov To: John Bradley Thread-Topic: [Unbearable] HTTPSTB updates and respin WGLC Thread-Index: AQHSgKU2H782DYLSAEOPK8wfkxaST6FcTAuwgABakICAAAHYMA== Date: Tue, 7 Feb 2017 00:01:09 +0000 Message-ID: References: <4ab4ab60-3798-d227-8f91-d310b5b3e9c7@KingsMountain.com> <6801C875-65FA-4C4F-B45B-59AD7D734845@ve7jtb.com> In-Reply-To: <6801C875-65FA-4C4F-B45B-59AD7D734845@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: 2713c4ab-f62f-4e0b-64ce-08d44eec6c1f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0841; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0841; 7:P4gv3O31lMFBy6VSWHfHEULTYxhO25dLmUpBtb5V1zvFjWHtAleco+ucGQL7OcQoh0M7qS0qtaJmVzjcZleP7ttMGb9J8n6B1DyxSLicSykoKfBVeXkGnxHFsXxVy+dcjzspQ3sh5dfgHEI9rGyFnXQo83lr/dsNtwQ0vtC7hUcvLxq+THaIe4SmBwuI4TrHJmuhUoHot7vHrfnj/LV1g0yD7JZxwTM3yXb8k3VI54o4fhm8zSTqeMe1CUdmcWXM4L625SsFCI9Tc0MBro2GtwsldewNMwQVEioInqIbkPhpBhUp5ktWO8/cCAtDoCsK1rHoWV+hLIuJ0nnJRDQkvH1qLCyayAqsGV9AVr22mH5Zp6W9/9ooXhQitnC+5Rr5iN5HJ2H8K8J68UqjL7DByCS0+Aq+cMazypOmWggevwCJu0KfsD0/a0Ws94Bsad2OhWUfXy2M8scX0JxcV9CRIGmUS/CyG4CoKE8s9Uye8xM2I9zFd6MYEfWp3htnU3Qz9YItFNyZV4XZGxN/b4aRp9AC0dC3LhlmiztxIJT1fOw= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(20170203043)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:CY1PR0301MB0841; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0841; x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39450400003)(39850400002)(39860400002)(39840400002)(13464003)(189002)(24454002)(199003)(377454003)(6306002)(54356999)(76176999)(3280700002)(105586002)(25786008)(3660700001)(5660300001)(106116001)(53936002)(106356001)(9686003)(6116002)(99286003)(102836003)(6506006)(54906002)(55016002)(50986999)(305945005)(229853002)(77096006)(2950100002)(6916009)(92566002)(7696004)(6436002)(2906002)(33656002)(2900100001)(74316002)(8990500004)(189998001)(10090500001)(86362001)(7736002)(10290500002)(4326007)(6246003)(5005710100001)(38730400002)(8676002)(68736007)(122556002)(101416001)(97736004)(81166006)(81156014)(8936002)(86612001)(15650500001)(110136004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0841; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 07 Feb 2017 00:01:09.7416 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0841 Archived-At: Cc: IETF TokBind WG , Dirk Balfanz , =JeffH Hodges Subject: Re: [Unbearable] HTTPSTB updates and respin WGLC 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, 07 Feb 2017 00:01:15 -0000 SGkgSm9obiwNCg0KSSBiZWxpZXZlIEplZmYgaXMgd29ya2luZyBvbiBhbm90aGVyIFBSLCB0aGVu IG9uY2UgdGhhdCdzIG1lcmdlZCB3ZSBzaG91bGQgYmUgYWJsZSB0byBwdWJsaXNoIHRoZSAzIHVw ZGF0ZWQgSS1Ecy4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEpvaG4gQnJhZGxleSBbbWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tXSANClNl bnQ6IE1vbmRheSwgRmVicnVhcnkgNiwgMjAxNyAzOjUyIFBNDQpUbzogQW5kcmVpIFBvcG92IDxB bmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4NCkNjOiA9SmVmZkggSG9kZ2VzIDxKZWZmLkhvZGdl c0BLaW5nc01vdW50YWluLmNvbT47IERpcmsgQmFsZmFueiA8YmFsZmFuekBnb29nbGUuY29tPjsg SUVURiBUb2tCaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtVbmJl YXJhYmxlXSBIVFRQU1RCIHVwZGF0ZXMgYW5kIHJlc3BpbiBXR0xDDQoNCldoZW4gZG8geW91IHRo aW5rIHlvdSBndXlzIGNhbiBwdXNoIOKAnGZpbmFsIiB2ZXJzaW9ucyBmb3IgdGhlIFdHPw0KDQpJ IGFtIGhvcGluZyB3ZSBjYW4gaGF2ZSB0aGVzZSBzcGVjcyB3cmFwcGVkIHVwIGJ5IENoaWNhZ28u DQoNCkpvaG4gQi4NCj4gT24gRmViIDYsIDIwMTcsIGF0IDM6MzAgUE0sIEFuZHJlaSBQb3BvdiA8 QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPiANCj4+IFRob3VnaCwgaW4gdGhl IHBsdXJhbCBjYXNlLCB3b3VsZCB1c2luZyAia2V5cyIgcmF0aGVyIHRoYW4gImtleSBwYWlycyIg DQo+IHdvcmsgZm9yIHlvdT8NCj4gDQo+IFRoaXMgaXMganVzdCBhZXN0aGV0aWMgcHJlZmVyZW5j ZTsgSSBjYW4gbGl2ZSB3aXRoIGVpdGhlciBwaHJhc2luZy4uLg0KPiANCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mID1KZWZmSA0KPiBTZW50OiBNb25kYXksIEZlYnJ1 YXJ5IDYsIDIwMTcgMTA6MTcgQU0NCj4gVG86IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1p Y3Jvc29mdC5jb20+OyBEaXJrIEJhbGZhbnogPGJhbGZhbnpAZ29vZ2xlLmNvbT4NCj4gQ2M6IElF VEYgVG9rQmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtVbmJl YXJhYmxlXSBIVFRQU1RCIHVwZGF0ZXMgYW5kIHJlc3BpbiBXR0xDDQo+IA0KPiBjZjogPGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdW5iZWFyYWJsZS9jdXJyZW50L21zZzAx MTQ3Lmh0bWw+DQo+IFsgaSBzdXNwZWN0IERpcmsgaGFkIG5vdCBzZWVuIEFuZHJlaSdzIGVtYWls IHByaW9yIHRvIG1lcmdpbmcgUFIgIzkyIF0NCj4gDQo+IEFuZHJlaSB3cm90ZSBvbiBGcmksIDMg RmViIDIwMTcgMDE6NTE6MjMgKzAwMDA6DQo+PiANCj4+IEEgZmV3IGVkaXRvcmlhbCBzdWdnZXN0 aW9ucyBiZWxvdy4NCj4+IA0KPj4+IEkgdGhpbmsgdGhpcyBuZWVkcyB0byBiZSByZXBocmFzZWQ6 DQo+Pj4gVGhlIFRva2VuIEJpbmRpbmcgSUQgb2YgYSBUTFMgY29ubmVjdGlvbiBpcyBjb25zdHJ1 Y3RlZCB1c2luZyAgPj4gdGhlIHB1YmxpYyBrZXkgT0YgYSBwcml2YXRlLXB1YmxpYyBrZXkgcGFp ciwgT0Ygd2hpY2ggID4+IHRoZSBjbGllbnQgcHJvdmVzIHBvc3Nlc3Npb24gT0YgdGhlIHByaXZh dGUga2V5IHRvICA+PiB0aGUgc2VydmVyLg0KPj4gUGVyaGFwcyBiZXR0ZXIgdG8ganVzdCBzcGxp dCB0aGlzIGludG8gdHdvIHNlbnRlbmNlczoNCj4+IA0KPj4gVGhlIFRva2VuIEJpbmRpbmcgSUQg b2YgYSBUTFMgY29ubmVjdGlvbiBpcyBjb25zdHJ1Y3RlZCB1c2luZyB0aGUgID4gcHVibGljIGtl eSBvZiBhIHByaXZhdGUtcHVibGljIGtleSBwYWlyLg0KPj4gVGhlIGNsaWVudCBwcm92ZXMgcG9z c2Vzc2lvbiBvZiB0aGUgY29ycmVzcG9uZGluZyBwcml2YXRlIGtleS4NCj4gDQo+IHRoeCwgcXVl dWVkLg0KPiANCj4gDQo+Pj4gKGNsaWVudHMgdXNlIGRpZmZlcmVudCBUb2tlbiBCaW5kaW5nIGtl eSBwYWlycyBmb3IgZGlmZmVyZW50Li4uDQo+Pj4gVGhlIHNjb3BpbmcgZm9yIHRob3NlIFRva2Vu IEJpbmRpbmcga2V5IHBhaXJzIGdlbmVyYXRlZCBieSBXZWIgID4+IGJyb3dzZXJzIGluLi4uDQo+ Pj4gYnJvd3NlcnMgTUFZIHVzZSBkaWZmZXJlbnQga2V5IHBhaXIgc2NvcGluZyBydWxlcy4NCj4+ PiBGb3IgcHJpdmFjeSByZWFzb25zLCBjbGllbnRzIHVzZSBkaWZmZXJlbnQgVG9rZW4gQmluZGlu ZyBrZXkgcGFpcnMgID4+IG9mIHRoZSBUb2tlbiBCaW5kaW5nIGtleSBwYWlyLiBJdCBpcyBwb3Nz aWJsZSB0aGF0IHRoZSBUb2tlbiAgPj4gPHNlY3Rpb24gdGl0bGU9IlNjb3Bpbmcgb2YgVG9rZW4g QmluZGluZyBLZXkgUGFpcnMiLi4uDQo+Pj4gWy4uLl0NCj4+IA0KPj4gV2hpbGUgbm90IHdyb25n LCBhbGwgdGhlc2Uga2V5IHBhaXJzIHNlZW0gdW5uZWNlc3NhcnkuIFRoZSBUb2tlbiAgPiBCaW5k aW5nIGtleSBpcyBhc3ltbWV0cmljLCBzbyBjbGVhcmx5IGl0IGhhcyBhIHByaXZhdGUgYW5kIHB1 YmxpYyAgPiBjb21wb25lbnQuDQo+IA0KPiBJdCBzZWVtcyBpbmFjY3VyYXRlIGFuZCBwb3RlbnRp YWxseSBjb25mdXNpbmcgdG8gc3BlYWsgb2YgYSBzaW5ndWxhciAidG9rZW4gYmluZGluZyBrZXki IHdoZW4gd2UgaGF2ZSBleHBsaWNpdGx5IHRlcm1lZCBpdCBhICJwcml2YXRlLXB1YmxpYyBrZXkg cGFpciIsIGFuZCBpdCBpcyBpbmRlZWQgdHdvIHNlcGFyYXRlIChhbHRob3VnaCByZWxhdGVkKSBh cnRpZmFjdHMuDQo+IA0KPiBUaG91Z2gsIGluIHRoZSBwbHVyYWwgY2FzZSwgd291bGQgdXNpbmcg ImtleXMiIHJhdGhlciB0aGFuICJrZXkgcGFpcnMiIA0KPiB3b3JrIGZvciB5b3U/DQo+IA0KPj4+ IGNvbnRhaW5zIGJvdGg6IGEgcHJvb2Ygb2YgcG9zc2Vzc2lvbiBvZiB0aGUgcHJvdmlkZWQgVG9r ZW4gQmluZGluZyAgPj4gSUQsIGFzIHdlbGwgYXMgYSBwcm9vZiBvZiBwb3NzZXNzaW9uIG9mIHRo ZSByZWZlcnJlZCBUb2tlbiBCaW5kaW5nICA+PiBJRCAgPiBJdCdzIGEgcHJvb2Ygb2YgcG9zc2Vz c2lvbiBvZiBhIFRva2VuIEJpbmRpbmcga2V5LCBJIHRoaW5rLg0KPiANCj4gb2ssIHF1ZXVlZCwg dGh4IGFnYWluLg0KPiANCj4gPUplZmZIDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBVbmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KPiBVbmJl YXJhYmxlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dW5iZWFyYWJsZQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3QNCj4gVW5iZWFyYWJsZUBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUNCg0K From nobody Mon Feb 6 16:07:39 2017 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 9304E1297C2 for ; Mon, 6 Feb 2017 16:07:38 -0800 (PST) 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 Vs6fxxaN7T_U for ; Mon, 6 Feb 2017 16:07:37 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d: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 D38211297BF for ; Mon, 6 Feb 2017 16:07:36 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id s140so72635537qke.0 for ; Mon, 06 Feb 2017 16:07:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ActFqmkuuvH9+Rswe5e1KnRPils0rlLnS4dwS1ydZrQ=; b=Iwzh05ZLA5zA1up8P6fw+ElMsCj203EHuB1CeJNP9T/j3JJNULaw0Z3LDLHxuYByxg v1aRbpnG7OOr8CXTGPNV2MWgUtDziJXwNm8KISps6kQJiYxVQJzz2wSOJr2zgeyTzAOO hRMaRcT3C/ybwkQJPzFJXOlSbdZJmixzbR6hSwIun6aavuk2DBG+WgcONrMWhBdVsvhj 7h0/j1CIEwur7Dytw/9cYaDKpxDGWVvKV2HB5BBjQYE0B7XStzHorKe9dr/h+2/yXoW2 56JLtI0C/qIaqGr9uatmRMEgiOuROLi0w+tvFK0GnVR7WPRMte3uVREkEYkfaTJczQHS Qj5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ActFqmkuuvH9+Rswe5e1KnRPils0rlLnS4dwS1ydZrQ=; b=WsqZstQstjQmYA0S85PDjdC5KEL8vHsfya9rUp96POtOtauckUGkVauWUEMyMM0Ec6 gBy/oZyydJf3hJnQ22NjJAYNUYY+sXY5rc/odJmvNfb4GhRLn4UXZ9G4P0Xt2wxLnEP8 E843KOfAOJi51BOvXV6MkEANauhm643eoxFUqHWSeTKMRY0D0Ep18cQf7Mqr5QBlanq+ /kCD0NSM2LD3yvTeFub9PZFEVzqQMRuZPp+YEDXV8lbnq8sP+4NylRqSXHNYGeBCnOW1 p8bAhDXJdsyMRA1hFtAvaxUZNISYVEM/gd0gf857TylMbxvFPTEWURUEkw3piPBVsIqt x9ig== X-Gm-Message-State: AMke39m7bHDfemxBQNgGex8vobx0Khu2wm/HDTnDSB3LBq25KZLTLPtF2C7Jhn8R3AgOAymw X-Received: by 10.55.154.204 with SMTP id c195mr11605210qke.293.1486426055810; Mon, 06 Feb 2017 16:07:35 -0800 (PST) Received: from [192.168.8.100] ([181.201.111.117]) by smtp.gmail.com with ESMTPSA id 12sm1872928qtv.31.2017.02.06.16.07.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 16:07:35 -0800 (PST) From: John Bradley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_59DD084F-2C2C-4544-9FA7-FC5B1F40AE78"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 6 Feb 2017 21:07:32 -0300 In-Reply-To: To: Andrei Popov References: <4ab4ab60-3798-d227-8f91-d310b5b3e9c7@KingsMountain.com> <6801C875-65FA-4C4F-B45B-59AD7D734845@ve7jtb.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF TokBind WG , Dirk Balfanz , =JeffH Hodges Subject: Re: [Unbearable] HTTPSTB updates and respin WGLC 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, 07 Feb 2017 00:07:38 -0000 --Apple-Mail=_59DD084F-2C2C-4544-9FA7-FC5B1F40AE78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the update. Lets get this done before you ship Creators update:). John B. > On Feb 6, 2017, at 9:01 PM, Andrei Popov = wrote: >=20 > Hi John, >=20 > I believe Jeff is working on another PR, then once that's merged we = should be able to publish the 3 updated I-Ds. >=20 > Cheers, >=20 > Andrei >=20 > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Monday, February 6, 2017 3:52 PM > To: Andrei Popov > Cc: =3DJeffH Hodges ; Dirk Balfanz = ; IETF TokBind WG > Subject: Re: [Unbearable] HTTPSTB updates and respin WGLC >=20 > When do you think you guys can push =E2=80=9Cfinal" versions for the = WG? >=20 > I am hoping we can have these specs wrapped up by Chicago. >=20 > John B. >> On Feb 6, 2017, at 3:30 PM, Andrei Popov = wrote: >>=20 >>> Though, in the plural case, would using "keys" rather than "key = pairs"=20 >> work for you? >>=20 >> This is just aesthetic preference; I can live with either phrasing... >>=20 >> -----Original Message----- >> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of = =3DJeffH >> Sent: Monday, February 6, 2017 10:17 AM >> To: Andrei Popov ; Dirk Balfanz = >> Cc: IETF TokBind WG >> Subject: Re: [Unbearable] HTTPSTB updates and respin WGLC >>=20 >> cf: = >> [ i suspect Dirk had not seen Andrei's email prior to merging PR #92 = ] >>=20 >> Andrei wrote on Fri, 3 Feb 2017 01:51:23 +0000: >>>=20 >>> A few editorial suggestions below. >>>=20 >>>> I think this needs to be rephrased: >>>> The Token Binding ID of a TLS connection is constructed using >> = the public key OF a private-public key pair, OF which >> the client = proves possession OF the private key to >> the server. >>> Perhaps better to just split this into two sentences: >>>=20 >>> The Token Binding ID of a TLS connection is constructed using the > = public key of a private-public key pair. >>> The client proves possession of the corresponding private key. >>=20 >> thx, queued. >>=20 >>=20 >>>> (clients use different Token Binding key pairs for different... >>>> The scoping for those Token Binding key pairs generated by Web >> = browsers in... >>>> browsers MAY use different key pair scoping rules. >>>> For privacy reasons, clients use different Token Binding key pairs = >> of the Token Binding key pair. It is possible that the Token >> =
>>> [...] >>>=20 >>> While not wrong, all these key pairs seem unnecessary. The Token > = Binding key is asymmetric, so clearly it has a private and public > = component. >>=20 >> It seems inaccurate and potentially confusing to speak of a singular = "token binding key" when we have explicitly termed it a "private-public = key pair", and it is indeed two separate (although related) artifacts. >>=20 >> Though, in the plural case, would using "keys" rather than "key = pairs"=20 >> work for you? >>=20 >>>> contains both: a proof of possession of the provided Token Binding = >> ID, as well as a proof of possession of the referred Token Binding = >> ID > It's a proof of possession of a Token Binding key, I think. >>=20 >> ok, queued, thx again. >>=20 >> =3DJeffH >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >=20 --Apple-Mail=_59DD084F-2C2C-4544-9FA7-FC5B1F40AE78 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILMTCCBUcw ggQvoAMCAQICEEAfBHP+tuqufC4R+F+Tu54wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAyIENsaWVudCBDQTAeFw0xNjA4MTIy MTE5NDFaFw0xODA4MTIyMTE5NDFaMIGCMQswCQYDVQQGEwJDTDEiMCAGA1UECAwZTWV0cm9wb2xp dGFuYSBkZSBTYW50aWFnbzEWMBQGA1UEBwwNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAwwMSm9obiBC cmFkbGV5MSAwHgYJKoZIhvcNAQkBFhF2ZTdqdGJAdmU3anRiLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALhTcSiDGvVrm4hlJA8WyFcWWe0dqnuJzstQYTaF281JFOEPA/13kQYI JMXAEUcS7NvW7KdUI0tHU0N6RTo0Ilf1E1nm8No++eqHO8pFUZ/cidpv0r+1Qcl9EgrpbZ00Y7Xg pq06EZELzJAmds4QQcsTKdpLNFbVcFnM11i2Gj5VNsYgO+qPO2AS8rLHkgDWnNkc9/lA+ZK5wGiU zxPU9KnIrERoTif3Zk7KjLvFpBWYD60M/lNoHZ5zxYgmYLmvoM1TSLn4Ms57wwT5MieV2l0aqlGC 7CKNa6XyeL1B0y0wSxL3PJQS4vSLDnttZC7od2A6yjeUMyM3rQ41vqUIMc8CAwEAAaOCAcMwggG/ MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUmA9bUmBmTYkCcZ3yYv8IRRP2nN4wHwYDVR0jBBgwFoAUmZerGDU6i1lFQ5iy cnHI9PsJzxYwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNz bC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGll bnQyLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xp ZW50Mi5jcmwwHAYDVR0RBBUwE4ERdmU3anRiQHZlN2p0Yi5jb20wIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMFUGA1UdIAROMEwwDAYKKwYBBAGBtTcGATA8BgsrBgEEAYG1NwEC BTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4IBAQBqcYJfFA/ITkX4L6JihqW168Wog1BOfkbPXO+wPn5G9P1NwruGfu41b70EPPwV vol+/j+qhSSrDjFyfNBsq4G45GRR6hwx0ei/bH0UW15Y63ASYPkNlj3ydCcvhw5ItWD5aYPphBx9 C7tLnQ7ow09cqt2CIgPd3W/IGri7p4hWPbdcX0oFIhJcDxmCwTcWyoVoIo4aas5gP44LPGneCoqI lXQMJinwneEnKd7rWXlzVWv7geaH3t79zARSw9ev9F4E61cDuHi+vgTFEpio7oxybqfj99yLibhX uZjReYnYbDMRiWDXduVIrIGYwmnUuD8a0b20kJgHm+FEgB6UMa9JMIIF4jCCA8qgAwIBAgIQXLZI bkcMmMZ/9oDbZErijTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1 WhcNMzAxMjE2MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDIgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7g9Q jJUJI4Ss9VBqj9Y3ok4h/TIJZUc+rzj61Rv3hNB/yeEEC1fz3i/EU+MXOOGxM7KCbtCIcJxHIW/k 8RP6sPPMO4cTg7sNzfBWsYsemtY6fN/kVr2R2X+/PjvtxmAaXpGX0znvQPxaE123IMGXy0zEKHZ/ nJDZ199TP9TNn9v+1QO0AZb4oaJ7ch0DpSJa8kF5xiNFDAg9taKKSrVuPHJL9MFFYPIqwShjHg+u YEzjfxbMP2QWwamnaA9Y7fORSDNapduFlARAcDtXdMpAijiG4HKnrN323I0Ka7lDTAWyLtTDCETK sI8fzOyL0inEu1WEVpdPytm8s1rwQB4f9QIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQr MCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRa MFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBSZl6sYNTqLWUVDmLJy ccj0+wnPFjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUd IAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4ICAQCZQUEEzvYk9U4wNHhDu1f9QGwbzAH4m4wIKH8ZidNYwZhyoNKW041iJ002KMW9 ywYM95n4770tT45yH29vTMlZtBvz0h44KuxMLNXRCTDwvV07sT39nPjFi5MpwZaLVueNiaa1vok1 n2Wn8lLcyCltYZNGAEifM0ko/A/vvckftFIZG75RAiZHYtfnrdBGiOxyF+nHI9a33BRX5Vl/3z0+ uHZ/Y6YPbNJ7iboOFrFZBCtt+lp3WaDB62ZoBewiMmd09JrqmMJAEgw3EbfQNtaPzHPg/EOhlZik Rgd4BCrzrbIqB2RKib+gnQJt2uoJaKOaV90S9Xgs3PC837OE9CEmY6/MTTG0xpbLh2hR/rLQ3sCr H56aODeuDrQBq85lXxRbDCERDUR7FZUhHv+i1aQaY59NPu26hDd6nqksSDq2mCddpidPBuGJz9lN X2nRyGkudDuWV6gIr6AZfaYv+ggTXOcCDJZFzMhWdLC7CPvRKxQ7vTiYV+4lgqOvV9MnZc149PPt itTysq/oOv70zx7q+tyaLTa4cqFhCclhIwSwOEJiV3xqQebvmwsDX7BaXGAJZIhbdUbNr3poEgct 6uAxw2zyr69WCJmTUUhz/k1/TT/eCUZJqnMg/6mje7tiVdaUQJcBtJ6cq5+mUDNUB1fohW8EOFai zFpP/0FaP62ctTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMiBDbGllbnQgQ0ECEEAfBHP+tuqufC4R+F+Tu54wCQYFKw4DAhoF AKCCAZkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjA3MDAw NzMyWjAjBgkqhkiG9w0BCQQxFgQUUxv1rUp2wUNqenfmUALjR7/JPngwgZoGCSsGAQQBgjcQBDGB jDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIg Q2xpZW50IENBAhBAHwRz/rbqrnwuEfhfk7ueMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIgQ2xpZW50IENBAhBA HwRz/rbqrnwuEfhfk7ueMA0GCSqGSIb3DQEBAQUABIIBABcstSo1ekRL8JU7JsQGpT6tjnRyzdKg 2NSsjbUR46R7JvTsYGhLVigwdwaW4SFjXKql5iTGCC/m9IaZArUnlg+Qvv3THi4U2jwRcC2vMsNO Lp/1YLvW8cHnkm5poIXGlc6HNCKb9l8EKD9Yxg8As3lSzbzqtdzaH/4VIyBqBNUctKlWltYv9MJz mveEI8cNgcNJbW/jcv86Ooyz+ZXtggnsEAFd/CSspgSQieJbi0nxXCBPDsEbl4vhyd9a3wjT/BCL taeHBTc52Ur1q1p2UAv4jcpiOziKaN6dyaNN8BEf/6fuZ3pc3jv7OzCT9oOyBb/feiy40bxNLxhs 8L+yzqcAAAAAAAA= --Apple-Mail=_59DD084F-2C2C-4544-9FA7-FC5B1F40AE78-- From nobody Mon Feb 6 16:15:30 2017 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 17195128AC9 for ; Mon, 6 Feb 2017 16:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Y_glUdkmYLLJ for ; Mon, 6 Feb 2017 16:15:27 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0129.outbound.protection.outlook.com [104.47.32.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF6F127078 for ; Mon, 6 Feb 2017 16:15:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PRwNXGg+YtGOqFSmRLm4mqbZlHG1HBEDUrrpp4jo0DU=; b=b0u2l/AAb2lykanE3CSR8HnatdG9F5wRUyuKOgCvpxuySLLWPTP3sCN+6s6gDQN86lZvMl8id3fJhsZHtegaeCdcIBMlGmL6GFcrJDzkRJsLn09huawOGlORLw/s/aUStN7CtoLLw6TkGr5bszIsXjm2lt7sRdIhPIvfWCq1Hn4= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 7 Feb 2017 00:15:25 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.025; Tue, 7 Feb 2017 00:15:25 +0000 From: Andrei Popov To: John Bradley Thread-Topic: [Unbearable] HTTPSTB updates and respin WGLC Thread-Index: AQHSgKU2H782DYLSAEOPK8wfkxaST6FcTAuwgABakICAAAHYMIAAAp0AgAABgkA= Date: Tue, 7 Feb 2017 00:15:24 +0000 Message-ID: References: <4ab4ab60-3798-d227-8f91-d310b5b3e9c7@KingsMountain.com> <6801C875-65FA-4C4F-B45B-59AD7D734845@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: fa0e7ece-6cdf-4818-efef-08d44eee69e2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0842; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 7:b+twI89hNzjBI98BGvIbofh88JsJzYqdg0UkE7iHbehvxpaCt57RJa/ssIntrgtDTkHYgiu3dwn0bNOSitIberGZnM1ciq4hYtb2O6KB7EuNYzfM1CxigeSm1RCYdCiGz1bP6nkMbSu2vR+N1ZJf1DULqu2/9ZM43IN+eu7SkFnF4V5QjPLInfdRBMhAhNRQIaBIfKGngH4hk34kWx3lnCuPkmHKEWn2EdWczHAu/kD/as2MIzPIppToTfzYD6XcGnYulqNyNyg4IXEa1+JDDXQsb27rJHwp9DnSmZ0WIRUG3aBr588JyQBH4KFxZxgUBWMLn0xz9Nxl7xkq9X4S14qmL5tYuW+Kb7c8PulEoPXUDkNIBz3qljFIJ/O9lc+1DgsSKC4/QDjEapLqmf+SxQMDk3K9HugKSsdK/QjriovEWaKUcsODKSHMDOSL1zicnbdkAKkwI9VM29lSVOmZK+9fiOWyudp7FuL8teHg3ZUXLmzRUrEoSspY3TG2858e7EAi9kTYRrtb/F4NkL5T0Dr+yaH1v1pkjpHzp0WpR1k= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(20170203043)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123558025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39840400002)(39410400002)(39850400002)(39450400003)(189002)(24454002)(199003)(51914003)(377454003)(13464003)(76176999)(3280700002)(86612001)(3660700001)(53936002)(97736004)(189998001)(33656002)(93886004)(92566002)(50986999)(122556002)(54356999)(101416001)(110136004)(305945005)(74316002)(7736002)(6916009)(2950100002)(6116002)(102836003)(7696004)(6246003)(106116001)(81156014)(68736007)(81166006)(8676002)(5660300001)(105586002)(38730400002)(25786008)(8936002)(106356001)(8990500004)(9686003)(2906002)(6506006)(4326007)(5005710100001)(54906002)(15650500001)(86362001)(10090500001)(6436002)(10290500002)(77096006)(99286003)(2900100001)(55016002)(229853002)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 07 Feb 2017 00:15:24.9193 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Cc: IETF TokBind WG , Dirk Balfanz , =JeffH Hodges Subject: Re: [Unbearable] HTTPSTB updates and respin WGLC 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, 07 Feb 2017 00:15:29 -0000 SSdsbCBkbyBhbnl0aGluZyBhIG1lcmUgY28tZWRpdG9yIGNhbiBkbywgdG8gaGVscCBtb3ZlIHRo aXMgYWxvbmc6KQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm9obiBCcmFk bGV5IFttYWlsdG86dmU3anRiQHZlN2p0Yi5jb21dIA0KU2VudDogTW9uZGF5LCBGZWJydWFyeSA2 LCAyMDE3IDQ6MDggUE0NClRvOiBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQu Y29tPg0KQ2M6ID1KZWZmSCBIb2RnZXMgPEplZmYuSG9kZ2VzQEtpbmdzTW91bnRhaW4uY29tPjsg RGlyayBCYWxmYW56IDxiYWxmYW56QGdvb2dsZS5jb20+OyBJRVRGIFRva0JpbmQgV0cgPHVuYmVh cmFibGVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIEhUVFBTVEIgdXBkYXRl cyBhbmQgcmVzcGluIFdHTEMNCg0KVGhhbmtzIGZvciB0aGUgdXBkYXRlLg0KDQpMZXRzIGdldCB0 aGlzIGRvbmUgYmVmb3JlIHlvdSBzaGlwIENyZWF0b3JzIHVwZGF0ZTopLg0KDQpKb2huIEIuDQoN Cj4gT24gRmViIDYsIDIwMTcsIGF0IDk6MDEgUE0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92 QG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPiANCj4gSGkgSm9obiwNCj4gDQo+IEkgYmVsaWV2ZSBK ZWZmIGlzIHdvcmtpbmcgb24gYW5vdGhlciBQUiwgdGhlbiBvbmNlIHRoYXQncyBtZXJnZWQgd2Ug c2hvdWxkIGJlIGFibGUgdG8gcHVibGlzaCB0aGUgMyB1cGRhdGVkIEktRHMuDQo+IA0KPiBDaGVl cnMsDQo+IA0KPiBBbmRyZWkNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IEpvaG4gQnJhZGxleSBbbWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tXSANCj4gU2VudDogTW9u ZGF5LCBGZWJydWFyeSA2LCAyMDE3IDM6NTIgUE0NCj4gVG86IEFuZHJlaSBQb3BvdiA8QW5kcmVp LlBvcG92QG1pY3Jvc29mdC5jb20+DQo+IENjOiA9SmVmZkggSG9kZ2VzIDxKZWZmLkhvZGdlc0BL aW5nc01vdW50YWluLmNvbT47IERpcmsgQmFsZmFueiA8YmFsZmFuekBnb29nbGUuY29tPjsgSUVU RiBUb2tCaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW1VuYmVh cmFibGVdIEhUVFBTVEIgdXBkYXRlcyBhbmQgcmVzcGluIFdHTEMNCj4gDQo+IFdoZW4gZG8geW91 IHRoaW5rIHlvdSBndXlzIGNhbiBwdXNoIOKAnGZpbmFsIiB2ZXJzaW9ucyBmb3IgdGhlIFdHPw0K PiANCj4gSSBhbSBob3Bpbmcgd2UgY2FuIGhhdmUgdGhlc2Ugc3BlY3Mgd3JhcHBlZCB1cCBieSBD aGljYWdvLg0KPiANCj4gSm9obiBCLg0KPj4gT24gRmViIDYsIDIwMTcsIGF0IDM6MzAgUE0sIEFu ZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPj4gDQo+Pj4g VGhvdWdoLCBpbiB0aGUgcGx1cmFsIGNhc2UsIHdvdWxkIHVzaW5nICJrZXlzIiByYXRoZXIgdGhh biAia2V5IHBhaXJzIiANCj4+IHdvcmsgZm9yIHlvdT8NCj4+IA0KPj4gVGhpcyBpcyBqdXN0IGFl c3RoZXRpYyBwcmVmZXJlbmNlOyBJIGNhbiBsaXZlIHdpdGggZWl0aGVyIHBocmFzaW5nLi4uDQo+ PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBVbmJlYXJhYmxlIFtt YWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgPUplZmZIDQo+ PiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDYsIDIwMTcgMTA6MTcgQU0NCj4+IFRvOiBBbmRyZWkg UG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPjsgRGlyayBCYWxmYW56IDxiYWxmYW56 QGdvb2dsZS5jb20+DQo+PiBDYzogSUVURiBUb2tCaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3Jn Pg0KPj4gU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBIVFRQU1RCIHVwZGF0ZXMgYW5kIHJlc3Bp biBXR0xDDQo+PiANCj4+IGNmOiA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi91bmJlYXJhYmxlL2N1cnJlbnQvbXNnMDExNDcuaHRtbD4NCj4+IFsgaSBzdXNwZWN0IERpcmsg aGFkIG5vdCBzZWVuIEFuZHJlaSdzIGVtYWlsIHByaW9yIHRvIG1lcmdpbmcgUFIgIzkyIF0NCj4+ IA0KPj4gQW5kcmVpIHdyb3RlIG9uIEZyaSwgMyBGZWIgMjAxNyAwMTo1MToyMyArMDAwMDoNCj4+ PiANCj4+PiBBIGZldyBlZGl0b3JpYWwgc3VnZ2VzdGlvbnMgYmVsb3cuDQo+Pj4gDQo+Pj4+IEkg dGhpbmsgdGhpcyBuZWVkcyB0byBiZSByZXBocmFzZWQ6DQo+Pj4+IFRoZSBUb2tlbiBCaW5kaW5n IElEIG9mIGEgVExTIGNvbm5lY3Rpb24gaXMgY29uc3RydWN0ZWQgdXNpbmcgID4+IHRoZSBwdWJs aWMga2V5IE9GIGEgcHJpdmF0ZS1wdWJsaWMga2V5IHBhaXIsIE9GIHdoaWNoICA+PiB0aGUgY2xp ZW50IHByb3ZlcyBwb3NzZXNzaW9uIE9GIHRoZSBwcml2YXRlIGtleSB0byAgPj4gdGhlIHNlcnZl ci4NCj4+PiBQZXJoYXBzIGJldHRlciB0byBqdXN0IHNwbGl0IHRoaXMgaW50byB0d28gc2VudGVu Y2VzOg0KPj4+IA0KPj4+IFRoZSBUb2tlbiBCaW5kaW5nIElEIG9mIGEgVExTIGNvbm5lY3Rpb24g aXMgY29uc3RydWN0ZWQgdXNpbmcgdGhlICA+IHB1YmxpYyBrZXkgb2YgYSBwcml2YXRlLXB1Ymxp YyBrZXkgcGFpci4NCj4+PiBUaGUgY2xpZW50IHByb3ZlcyBwb3NzZXNzaW9uIG9mIHRoZSBjb3Jy ZXNwb25kaW5nIHByaXZhdGUga2V5Lg0KPj4gDQo+PiB0aHgsIHF1ZXVlZC4NCj4+IA0KPj4gDQo+ Pj4+IChjbGllbnRzIHVzZSBkaWZmZXJlbnQgVG9rZW4gQmluZGluZyBrZXkgcGFpcnMgZm9yIGRp ZmZlcmVudC4uLg0KPj4+PiBUaGUgc2NvcGluZyBmb3IgdGhvc2UgVG9rZW4gQmluZGluZyBrZXkg cGFpcnMgZ2VuZXJhdGVkIGJ5IFdlYiAgPj4gYnJvd3NlcnMgaW4uLi4NCj4+Pj4gYnJvd3NlcnMg TUFZIHVzZSBkaWZmZXJlbnQga2V5IHBhaXIgc2NvcGluZyBydWxlcy4NCj4+Pj4gRm9yIHByaXZh Y3kgcmVhc29ucywgY2xpZW50cyB1c2UgZGlmZmVyZW50IFRva2VuIEJpbmRpbmcga2V5IHBhaXJz ICA+PiBvZiB0aGUgVG9rZW4gQmluZGluZyBrZXkgcGFpci4gSXQgaXMgcG9zc2libGUgdGhhdCB0 aGUgVG9rZW4gID4+IDxzZWN0aW9uIHRpdGxlPSJTY29waW5nIG9mIFRva2VuIEJpbmRpbmcgS2V5 IFBhaXJzIi4uLg0KPj4+PiBbLi4uXQ0KPj4+IA0KPj4+IFdoaWxlIG5vdCB3cm9uZywgYWxsIHRo ZXNlIGtleSBwYWlycyBzZWVtIHVubmVjZXNzYXJ5LiBUaGUgVG9rZW4gID4gQmluZGluZyBrZXkg aXMgYXN5bW1ldHJpYywgc28gY2xlYXJseSBpdCBoYXMgYSBwcml2YXRlIGFuZCBwdWJsaWMgID4g Y29tcG9uZW50Lg0KPj4gDQo+PiBJdCBzZWVtcyBpbmFjY3VyYXRlIGFuZCBwb3RlbnRpYWxseSBj b25mdXNpbmcgdG8gc3BlYWsgb2YgYSBzaW5ndWxhciAidG9rZW4gYmluZGluZyBrZXkiIHdoZW4g d2UgaGF2ZSBleHBsaWNpdGx5IHRlcm1lZCBpdCBhICJwcml2YXRlLXB1YmxpYyBrZXkgcGFpciIs IGFuZCBpdCBpcyBpbmRlZWQgdHdvIHNlcGFyYXRlIChhbHRob3VnaCByZWxhdGVkKSBhcnRpZmFj dHMuDQo+PiANCj4+IFRob3VnaCwgaW4gdGhlIHBsdXJhbCBjYXNlLCB3b3VsZCB1c2luZyAia2V5 cyIgcmF0aGVyIHRoYW4gImtleSBwYWlycyIgDQo+PiB3b3JrIGZvciB5b3U/DQo+PiANCj4+Pj4g Y29udGFpbnMgYm90aDogYSBwcm9vZiBvZiBwb3NzZXNzaW9uIG9mIHRoZSBwcm92aWRlZCBUb2tl biBCaW5kaW5nICA+PiBJRCwgYXMgd2VsbCBhcyBhIHByb29mIG9mIHBvc3Nlc3Npb24gb2YgdGhl IHJlZmVycmVkIFRva2VuIEJpbmRpbmcgID4+IElEICA+IEl0J3MgYSBwcm9vZiBvZiBwb3NzZXNz aW9uIG9mIGEgVG9rZW4gQmluZGluZyBrZXksIEkgdGhpbmsuDQo+PiANCj4+IG9rLCBxdWV1ZWQs IHRoeCBhZ2Fpbi4NCj4+IA0KPj4gPUplZmZIDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBVbmJlYXJhYmxlIG1haWxpbmcgbGlzdA0K Pj4gVW5iZWFyYWJsZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby91bmJlYXJhYmxlDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiBVbmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KPj4gVW5iZWFy YWJsZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91 bmJlYXJhYmxlDQo+IA0KDQo= From nobody Mon Feb 6 23:30:16 2017 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 17AFB129488 for ; Mon, 6 Feb 2017 23:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 xpP-JB8T--Xt for ; Mon, 6 Feb 2017 23:30:13 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 B795012009C for ; Mon, 6 Feb 2017 23:30:12 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id z134so57798711lff.3 for ; Mon, 06 Feb 2017 23:30:12 -0800 (PST) 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=aggNhPDcU4w5YpAeZDbEQYvQq+QT9ryK0UjjYUTl+sU=; b=fu3w8JI5G/6yi/pJVhOSD6YPljd5jsIqWY1z1a6/dvrZjKiQ55jnyXGO2xZR0fsA0n r+JZ5I9GoUuZsa1ErB2ojG54C/efWE2OT0ied9tgd7RVSam5e6hXwV4vefA61fpRIi39 0reOqCy/0YZoFUGfNBOIbBb5MuYpmD8OG/Al+Kd0mfPDPCz5iKgF8dRRaRyYsb2DkslE +KDkiOChUi2G7j6bnAXIfFqGE9pNMn0ISATNHA6cVdrHQi4RxA/qnlJ0Ya/Pw7GPWUOE 4BsMfZgKRIXi6VAomq+5eTtyH8gvSy3SLR+mPeyh0376XBmgenCQjnEm+edTb+i3nl4g qT6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=aggNhPDcU4w5YpAeZDbEQYvQq+QT9ryK0UjjYUTl+sU=; b=d4p8G97RaYfU//er1O7ZeArJRrXAzfwQriPz5pKUSK04JptMRdOSUaPFLYwt/Q4mvB jgx8xzvby66wVGX/744M9Qywjiw3zonQy6xwL1BgStLWkG9dvztIBg9tFCI+O4NZiwQi CGN0IAChND4q9nRR8i9mmeeRwjTV2zpFLmcFvZHYO5ayVENf64soynFBTFPHoXFB1AhR EAI0zEfF957IYdRYjqizLy+a7Lv3UvMd0XwiHCYUzmihUgtc1TJd1c/9tDvKjUOsRA/6 2Sk5rOkTe4ELze3MtTyGK4Q9WAimMiK6c3/LqUIP78wVEQIDoNlyTSnDMlksGRtwA0VW rXeg== X-Gm-Message-State: AIkVDXIIl4IapyzxzF1Brw+E2AZwyTV2At7ED/tItXbuobeh7oM20DLIG047t2onMTCrYA== X-Received: by 10.46.9.20 with SMTP id 20mr5648998ljj.0.1486452610646; Mon, 06 Feb 2017 23:30:10 -0800 (PST) Received: from ?IPv6:2001:6b0:7:1:783c:5cbd:5329:5386? ([2001:6b0:7:1:783c:5cbd:5329:5386]) by smtp.gmail.com with ESMTPSA id d77sm989332lfd.26.2017.02.06.23.30.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 23:30:09 -0800 (PST) To: unbearable@ietf.org References: <4ab4ab60-3798-d227-8f91-d310b5b3e9c7@KingsMountain.com> <6801C875-65FA-4C4F-B45B-59AD7D734845@ve7jtb.com> From: Leif Johansson Message-ID: <543f7a94-7cc8-7225-95f5-a77d685f0817@mnt.se> Date: Tue, 7 Feb 2017 08:30:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Unbearable] HTTPSTB updates and respin WGLC 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, 07 Feb 2017 07:30:15 -0000 On 2017-02-07 01:07, John Bradley wrote: > Thanks for the update. > > Lets get this done before you ship Creators update:). > good news and good work! > John B. > >> On Feb 6, 2017, at 9:01 PM, Andrei Popov wrote: >> >> Hi John, >> >> I believe Jeff is working on another PR, then once that's merged we should be able to publish the 3 updated I-Ds. >> >> Cheers, >> >> Andrei >> >> -----Original Message----- >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >> Sent: Monday, February 6, 2017 3:52 PM >> To: Andrei Popov >> Cc: =JeffH Hodges ; Dirk Balfanz ; IETF TokBind WG >> Subject: Re: [Unbearable] HTTPSTB updates and respin WGLC >> >> When do you think you guys can push final" versions for the WG? >> >> I am hoping we can have these specs wrapped up by Chicago. >> >> John B. >>> On Feb 6, 2017, at 3:30 PM, Andrei Popov wrote: >>> >>>> Though, in the plural case, would using "keys" rather than "key pairs" >>> work for you? >>> >>> This is just aesthetic preference; I can live with either phrasing... >>> >>> -----Original Message----- >>> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of =JeffH >>> Sent: Monday, February 6, 2017 10:17 AM >>> To: Andrei Popov ; Dirk Balfanz >>> Cc: IETF TokBind WG >>> Subject: Re: [Unbearable] HTTPSTB updates and respin WGLC >>> >>> cf: >>> [ i suspect Dirk had not seen Andrei's email prior to merging PR #92 ] >>> >>> Andrei wrote on Fri, 3 Feb 2017 01:51:23 +0000: >>>> >>>> A few editorial suggestions below. >>>> >>>>> I think this needs to be rephrased: >>>>> The Token Binding ID of a TLS connection is constructed using >> the public key OF a private-public key pair, OF which >> the client proves possession OF the private key to >> the server. >>>> Perhaps better to just split this into two sentences: >>>> >>>> The Token Binding ID of a TLS connection is constructed using the > public key of a private-public key pair. >>>> The client proves possession of the corresponding private key. >>> >>> thx, queued. >>> >>> >>>>> (clients use different Token Binding key pairs for different... >>>>> The scoping for those Token Binding key pairs generated by Web >> browsers in... >>>>> browsers MAY use different key pair scoping rules. >>>>> For privacy reasons, clients use different Token Binding key pairs >> of the Token Binding key pair. It is possible that the Token >>
>>>> [...] >>>> >>>> While not wrong, all these key pairs seem unnecessary. The Token > Binding key is asymmetric, so clearly it has a private and public > component. >>> >>> It seems inaccurate and potentially confusing to speak of a singular "token binding key" when we have explicitly termed it a "private-public key pair", and it is indeed two separate (although related) artifacts. >>> >>> Though, in the plural case, would using "keys" rather than "key pairs" >>> work for you? >>> >>>>> contains both: a proof of possession of the provided Token Binding >> ID, as well as a proof of possession of the referred Token Binding >> ID > It's a proof of possession of a Token Binding key, I think. >>> >>> ok, queued, thx again. >>> >>> =JeffH >>> >>> _______________________________________________ >>> 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 >> > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > From nobody Tue Feb 7 14:17:02 2017 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 6569112950A for ; Tue, 7 Feb 2017 14:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=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 p_7zeUD9sNmo for ; Tue, 7 Feb 2017 14:16:59 -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 8A7021294E5 for ; Tue, 7 Feb 2017 14:16:59 -0800 (PST) Received: (qmail 25757 invoked by uid 0); 7 Feb 2017 22:15:12 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 7 Feb 2017 22:15:12 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id hyF91u0052UhLwi01yFCgY; Tue, 07 Feb 2017 15:15:12 -0700 X-Authority-Analysis: v=2.1 cv=H5NInYoi 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=n2v9WMKugxEA:10 a=48vgC7mUAAAA:8 a=QZB_nyJot4CiqQdncX0A:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 Received: from [173.224.162.88] (port=34921 helo=[10.244.66.209]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cbE2W-0000un-T6 for unbearable@ietf.org; Tue, 07 Feb 2017 15:15:08 -0700 From: =JeffH To: IETF TokBind WG Message-ID: Date: Tue, 7 Feb 2017 14:15:06 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 173.224.162.88 X-Exim-ID: 1cbE2W-0000un-T6 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.244.66.209]) [173.224.162.88]:34921 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 1 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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, 07 Feb 2017 22:17:01 -0000 the below is kind of long (read it anyway :) The summary is we need to make a conscious decision regarding the Connection HTTP request header field and whether we provide guidance regarding it and the Sec-Token-Binding header (and what guidance if so), or not. This seems to have ramifications for the nascent draft-campbell-tokbind-tls-term draft, unless I'm misunderstanding things. =JeffH In working through the list of "Considerations for New Header Fields" at the end of rfc7231 section 8.3.1 [1], there are these two items.. o Whether it is appropriate to list the field-name in the Connection header field (i.e., if the header field is to be hop-by-hop; see Section 6.1 of [RFC7230]). o Under what conditions intermediaries are allowed to insert, delete, or modify the field's value. Given the specifics in [RFC7230] Section 6.1 [2].. 6.1. Connection The "Connection" header field allows the sender to indicate desired control options for the current connection. In order to avoid confusing downstream recipients, a proxy or gateway MUST remove or replace any received connection options before forwarding the message. When a header field aside from Connection is used to supply control information for or about the current connection, the sender MUST list the corresponding field-name within the Connection header field. A proxy or gateway MUST parse a received Connection header field before a message is forwarded and, for each connection-option in this field, remove any header field(s) from the message with the same name as the connection-option, and then remove the Connection header field itself (or replace it with the intermediary's own connection options for the forwarded message). Hence, the Connection header field provides a declarative way of distinguishing header fields that are only intended for the immediate recipient ("hop-by-hop") from those fields that are intended for all recipients on the chain ("end-to-end"), enabling the message to be self-descriptive and allowing future connection-specific extensions to be deployed without fear that they will be blindly forwarded by older intermediaries. ..it offhand seems that one would want to list "Sec-Token-Binding" in the Connection header field because Sec-Token-Binding is ostensibly about the connection and is hop-by-hop because TLS is hop-by-hop. However, given our current thinking wrt TB and TLS Terminating Reverse Proxies [3], where we are contemplating one approach where such "TTRPs" pass-through the Sec-Token-Binding header field and add a corresponding Token-Binding-Context header, one would not want to list Sec-Token-Binding in the Connection header (because a TTRP would then strip it off). However there are implementation and security considerations with this. As one proposal, we could say in HTTPSTB something along the lines of.. [...] Clients SHOULD NOT list the Sec-Token-Binding header field as a connection option in the Connection header field (Section 6.1 of [RFC7230]) in order to generally enable Sec-Token-Binding header field pass-through by intermediaries, e.g., by TLS terminating reverse proxies (TTRP). Intermediaries MUST NOT modify the Sec-Token-Binding header field's value. See also the security considerations section. [...] Security Considerations [...] Not listing Sec-Token-Binding in the Connection header: this enables TTRPs to transparently convey the Sec-Token-Binding header field, containing a Token Binding Message, to the next tier ("backend servers"), e.g., where security tokens containing Token Binding IDs may be minted and validated. The communication between a TTRP and backend servers needs to be secured against eavesdropping and modification by unintended parties. The Token Binding Message itself may be validated by the TTRP or by a backend server. Though, in the latter case, the data necessary to perform such validation (i.e., the EKM, etc.) needs to be conveyed to the entity performing it. Such conveyance is out of scope for this specification. Listing Sec-Token-Binding in the Connection header: if done, this may help in ensuring that Token Binding IDs are not inadvertently revealed to unintended parties, though may cause difficulties with web sites employing TTRPs. [...] Or, we could just say "clients SHOULD list the Sec-Token-Binding header field as a connection option in the Connection header field", but that will create problems for TTRPs [3]. Or, we can just not mention the Connection header and see if anyone raises questions about it during further WG and IETF-wide review. thoughts? [1] [2] [3] From nobody Tue Feb 7 14:39:00 2017 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 B3A6F129432 for ; Tue, 7 Feb 2017 14:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBr-VoNlKKYI for ; Tue, 7 Feb 2017 14:38:56 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0137.outbound.protection.outlook.com [104.47.40.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6194C1294BB for ; Tue, 7 Feb 2017 14:38:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uvQugibEr8z1T0ZNR446oXn2qzISGCQwoZIBwU0n+kk=; b=LTqE7VO+ZuWh0r5vYoqvM4siuvbT2D7Fh42TUSmac48Y/TgTXxIhfC/3T6J6F9YQttmRZapABZHxtE2eOtv4ApK6PYZAHqfSbwoa/EGnzpSGv71XWTM6TCYjeuKELeSS/dFw1fBfR6nvBfnyh8uQUe3EoXuAMUnEBfY4jcFx9IA= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0841.namprd03.prod.outlook.com (10.160.163.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 7 Feb 2017 22:38:54 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.026; Tue, 7 Feb 2017 22:38:54 +0000 From: Andrei Popov To: =JeffH , IETF TokBind WG Thread-Topic: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? Thread-Index: AQHSgY/umVnjYtjx7keEPN17kRprnKFeIDFQ Date: Tue, 7 Feb 2017 22:38:54 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: b996e95c-6d54-43bf-dcf7-08d44faa18f1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0841; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0841; 7:DVg0cyVCzM+M7L4ISTCBtf5Q7924PicB9jKmfpNV7MBPSklJgrS5qVz0Y0yC/2OQVB/i6zrFd1yDsi1oVQ+b76hSkgJXZ7eUteUogxw4NvZWACdbmO5BaEmOAGW1sWkrS2d26vMOuyDPwBK9kPRF5Iy+hlPAo9AkxgyOSKZ7jbsnSDxsEH3x4MCLo1hTKKlUA51O8Hi09w2ikCbtnnXCL1Hpnxdi9RDEAioSUtQV20X+BCuvrq4EmG6OVSckOOY2IKlfqrmylMd5NcWlyhvCRtIispmHjcDx1oN7cU4zpJvhl5TauIrbHRjUWcX37+kmk/3529WwzzZgBmgSG6lPcov44fbafbmqd5HRgH+vyvGmzLdKucigc6JTiyfomSWVGELwATlvmFLrMHxt39h1bIrbQSc8z3ZVTECAXAznQlkonszB7U4M9WlvXKTosXs0QQlHs1BdaJHVuxZ2DpV1vc/3lirrB6d3jwL7VLIk8LJN9Bw/Km2dcKoXsjbQjXED9Y/eOePmCBat9LEuOgwx6GOgdlqdOAtCTh1gFrpz6UA= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(20170203043)(2017020603029)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:CY1PR0301MB0841; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0841; x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39840400002)(39450400003)(39860400002)(189002)(199003)(377454003)(13464003)(5660300001)(6116002)(102836003)(92566002)(7696004)(74316002)(229853002)(2950100002)(25786008)(6506006)(6436002)(10090500001)(6306002)(9686003)(189998001)(77096006)(99286003)(55016002)(86612001)(81156014)(38730400002)(8936002)(68736007)(86362001)(81166006)(122556002)(105586002)(106356001)(101416001)(3660700001)(8990500004)(561944003)(33656002)(2906002)(10290500002)(5005710100001)(50986999)(54356999)(76176999)(106116001)(53936002)(305945005)(97736004)(2900100001)(3280700002)(7736002)(230783001)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0841; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 07 Feb 2017 22:38:54.4959 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0841 Archived-At: Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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, 07 Feb 2017 22:38:58 -0000 When we discussed this early on, there was a strong distaste for connection= headers in the HTTP community, so we've defined TB headers as per-request. " clients MUST include the Sec-Token- Binding header field in their HTTP requests." We could also explicitly prohibit listing TB headers in the Connection head= er, if folks would like to see this clarification.=20 There are many reasons to keep TB headers per-request; it's not just about = the proxies and terminators. Cheers, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of =3DJeffH Sent: Tuesday, February 7, 2017 2:15 PM To: IETF TokBind WG Subject: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection = header field? the below is kind of long (read it anyway :) The summary is we need to mak= e a conscious decision regarding the Connection HTTP request header field a= nd whether we provide guidance regarding it and the Sec-Token-Binding heade= r (and what guidance if so), or not. This seems to have ramifications for t= he nascent draft-campbell-tokbind-tls-term draft, unless I'm misunderstandi= ng things. =3DJeffH In working through the list of "Considerations for New Header Fields" at th= e end of rfc7231 section 8.3.1 [1], there are these two items.. o Whether it is appropriate to list the field-name in the Connection header field (i.e., if the header field is to be hop-by-hop; see Section 6.1 of [RFC7230]). o Under what conditions intermediaries are allowed to insert, delete, or modify the field's value. Given the specifics in [RFC7230] Section 6.1 [2].. 6.1. Connection The "Connection" header field allows the sender to indicate desired control options for the current connection. In order to avoid confusing downstream recipients, a proxy or gateway MUST remove or replace any received connection options before forwarding the message. When a header field aside from Connection is used to supply control information for or about the current connection, the sender MUST list the corresponding field-name within the Connection header field. A proxy or gateway MUST parse a received Connection header field before a message is forwarded and, for each connection-option in this field, remove any header field(s) from the message with the same name as the connection-option, and then remove the Connection header field itself (or replace it with the intermediary's own connection options for the forwarded message). Hence, the Connection header field provides a declarative way of distinguishing header fields that are only intended for the immediate recipient ("hop-by-hop") from those fields that are intended for all recipients on the chain ("end-to-end"), enabling the message to be self-descriptive and allowing future connection-specific extensions to be deployed without fear that they will be blindly forwarded by older intermediaries. ..it offhand seems that one would want to list "Sec-Token-Binding" in the C= onnection header field because Sec-Token-Binding is ostensibly about the co= nnection and is hop-by-hop because TLS is hop-by-hop. However, given our current thinking wrt TB and TLS Terminating Reverse Prox= ies [3], where we are contemplating one approach where such "TTRPs"=20 pass-through the Sec-Token-Binding header field and add a corresponding Tok= en-Binding-Context header, one would not want to list Sec-Token-Binding in = the Connection header (because a TTRP would then strip it off). However the= re are implementation and security considerations with this. As one proposal, we could say in HTTPSTB something along the lines of.. [...] Clients SHOULD NOT list the Sec-Token-Binding header field as a connection option in the Connection header field (Section 6.1 of [RFC7230]) in order to generally enable Sec-Token-Binding header field pass-through by intermediaries, e.g., by TLS terminating reverse proxies (TTRP). Intermediaries MUST NOT modify the Sec-Token-Binding header field's value. See also the security considerations section. [...] Security Considerations [...] Not listing Sec-Token-Binding in the Connection header: this enables TTRPs to transparently convey the Sec-Token-Binding header field, containing a Token Binding Message, to the next tier ("backend servers"), e.g., where security tokens containing Token Binding IDs may be minted and validated. The communication between a TTRP and backend servers needs to be secured against eavesdropping and modification by unintended parties. The Token Binding Message itself may be validated by the TTRP or by a backend server. Though, in the latter case, the data necessary to perform such validation (i.e., the EKM, etc.) needs to be conveyed to the entity performing it. Such conveyance is out of scope for this specification. Listing Sec-Token-Binding in the Connection header: if done, this may help in ensuring that Token Binding IDs are not inadvertently revealed to unintended parties, though may cause difficulties with web sites employing TTRPs. [...] Or, we could just say "clients SHOULD list the Sec-Token-Binding header fie= ld as a connection option in the Connection header field", but that will cr= eate problems for TTRPs [3]. Or, we can just not mention the Connection header and see if anyone raises = questions about it during further WG and IETF-wide review. thoughts? [1] [2] [3] _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable From nobody Tue Feb 7 14:39:18 2017 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 99B5F1294EE for ; Tue, 7 Feb 2017 14:39:16 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 LPpfZkC9y4kR for ; Tue, 7 Feb 2017 14:39:14 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 3BBE5129432 for ; Tue, 7 Feb 2017 14:39:14 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id x49so149075166qtc.2 for ; Tue, 07 Feb 2017 14:39:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8nFAHA9AFGg75hQGkiRGvedZ1P+8tuy3iTc08xP3Kgk=; b=Ds1qQu18MJ5UO6gtL9ED46GmHEcVuqclKxnwiNpQNvZ0g5ecspIFm0x2EpB4NGWnQn RqA31jZPp0RAyU0nI/tIaa5BYv3P2QXQyK/Xq0mWnOwRof6q0PDJ4teCFsZI/cD+TvDC zgsGeX/BeudwWVkcUyks2P4Vz/vHS1fBeSFgjxpJTh/xa+YbZz7krfyiht5H9Dv/AukA kMpLQrwSLQ4WwsLcan5fVIolxUNHBD0QmZdS83yo3bAPv/HROejsdhNTlCbjbIosACZj oeArygFpruiNm17vPMO08d/PSmi3x4xRMerBN+1bOZm2YCVpMLf3Csl6+zZshcoYMKWn mjdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8nFAHA9AFGg75hQGkiRGvedZ1P+8tuy3iTc08xP3Kgk=; b=WbzH130loYhkcqwrAoUDl472JlfwlBWHF3ojij+4nHwVAsxvdBm6c7khFnEBeT94c7 I+jSd01Z5lweiFK1S0pjz/bgOFElxt/O6RB0zrhuIM2qCUrpOQC+ASbNBC0GckHxz19j hXa2d4eEjIBoD4lDI61+eeWxKLdzpqxXx444kVrbuSlC7dCTKdCaaPsSSQzM7WJRJvLm 9MqDzX5XKn34a9WjYtoxtElCPGKFS+xbN/v2TILvEU/OrEIuQe+HRmW1T72MkdEmfTK0 4FZ9y65p/juTPCk/23IqxYw80zPUTsxS2uxUIM1696NBVEGzRSm81pwkzjHyCP53LVGz Ztdg== X-Gm-Message-State: AMke39lz12J+suVrxWtm/ZNXFOXdW+3JLUuzSbHWzHZRAsphrAfoxSzjg1CHdrukmWGyTyyJ X-Received: by 10.200.34.81 with SMTP id p17mr15935760qtp.264.1486507153215; Tue, 07 Feb 2017 14:39:13 -0800 (PST) Received: from [192.168.86.150] ([191.115.72.210]) by smtp.gmail.com with ESMTPSA id i132sm4560133qke.44.2017.02.07.14.39.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 14:39:12 -0800 (PST) From: John Bradley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_279C62AC-F029-46C3-9F7F-B0B7DEF30C21"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 7 Feb 2017 19:38:29 -0300 In-Reply-To: To: =JeffH Hodges References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF TokBind WG Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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, 07 Feb 2017 22:39:16 -0000 --Apple-Mail=_279C62AC-F029-46C3-9F7F-B0B7DEF30C21 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The other option might be to go back to having the reverse proxy = validate the token binding and allow the client to list the = Sec-Token-Binding header. That would be hop by hop semantic. =20 We should at-least document why we think that is a bad idea so we have = something to point to if the issue comes up. John B. > On Feb 7, 2017, at 7:15 PM, =3DJeffH = wrote: >=20 > the below is kind of long (read it anyway :) The summary is we need = to make a conscious decision regarding the Connection HTTP request = header field and whether we provide guidance regarding it and the = Sec-Token-Binding header (and what guidance if so), or not. This seems = to have ramifications for the nascent draft-campbell-tokbind-tls-term = draft, unless I'm misunderstanding things. >=20 > =3DJeffH >=20 > In working through the list of "Considerations for New Header Fields" = at the end of rfc7231 section 8.3.1 [1], there are these two items.. >=20 > o Whether it is appropriate to list the field-name in the = Connection > header field (i.e., if the header field is to be hop-by-hop; see > Section 6.1 of [RFC7230]). >=20 > o Under what conditions intermediaries are allowed to insert, > delete, or modify the field's value. >=20 > Given the specifics in [RFC7230] Section 6.1 [2].. >=20 > 6.1. Connection >=20 > The "Connection" header field allows the sender to indicate desired > control options for the current connection. In order to avoid > confusing downstream recipients, a proxy or gateway MUST remove or > replace any received connection options before forwarding the > message. >=20 > When a header field aside from Connection is used to supply control > information for or about the current connection, the sender MUST = list > the corresponding field-name within the Connection header field. A > proxy or gateway MUST parse a received Connection header field = before > a message is forwarded and, for each connection-option in this = field, > remove any header field(s) from the message with the same name as = the > connection-option, and then remove the Connection header field = itself > (or replace it with the intermediary's own connection options for = the > forwarded message). >=20 > Hence, the Connection header field provides a declarative way of > distinguishing header fields that are only intended for the = immediate > recipient ("hop-by-hop") from those fields that are intended for all > recipients on the chain ("end-to-end"), enabling the message to be > self-descriptive and allowing future connection-specific extensions > to be deployed without fear that they will be blindly forwarded by > older intermediaries. >=20 > ..it offhand seems that one would want to list "Sec-Token-Binding" in = the Connection header field because Sec-Token-Binding is ostensibly = about the connection and is hop-by-hop because TLS is hop-by-hop. >=20 > However, given our current thinking wrt TB and TLS Terminating Reverse = Proxies [3], where we are contemplating one approach where such "TTRPs" = pass-through the Sec-Token-Binding header field and add a corresponding = Token-Binding-Context header, one would not want to list = Sec-Token-Binding in the Connection header (because a TTRP would then = strip it off). However there are implementation and security = considerations with this. >=20 > As one proposal, we could say in HTTPSTB something along the lines = of.. >=20 > [...] > Clients SHOULD NOT list the Sec-Token-Binding header field as > a connection option in the Connection header field (Section 6.1 > of [RFC7230]) in order to generally enable Sec-Token-Binding > header field pass-through by intermediaries, e.g., by TLS > terminating reverse proxies (TTRP). Intermediaries MUST NOT > modify the Sec-Token-Binding header field's value. See also the > security considerations section. > [...] > Security Considerations > [...] > Not listing Sec-Token-Binding in the Connection header: this > enables TTRPs to transparently convey the Sec-Token-Binding header > field, containing a Token Binding Message, to the next tier ("backend > servers"), e.g., where security tokens containing Token Binding IDs > may be minted and validated. The communication between a TTRP and > backend servers needs to be secured against eavesdropping and > modification by unintended parties. The Token Binding Message itself > may be validated by the TTRP or by a backend server. Though, in the > latter case, the data necessary to perform such validation (i.e., the > EKM, etc.) needs to be conveyed to the entity performing it. Such > conveyance is out of scope for this specification. >=20 > Listing Sec-Token-Binding in the Connection header: if done, this > may help in ensuring that Token Binding IDs are not inadvertently > revealed to unintended parties, though may cause difficulties with > web sites employing TTRPs. > [...] >=20 > Or, we could just say "clients SHOULD list the Sec-Token-Binding = header field as a connection option in the Connection header field", but = that will create problems for TTRPs [3]. >=20 > Or, we can just not mention the Connection header and see if anyone = raises questions about it during further WG and IETF-wide review. >=20 > thoughts? >=20 > [1] >=20 > [2] >=20 > [3] >=20 >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_279C62AC-F029-46C3-9F7F-B0B7DEF30C21 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILMTCCBUcw ggQvoAMCAQICEEAfBHP+tuqufC4R+F+Tu54wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAyIENsaWVudCBDQTAeFw0xNjA4MTIy MTE5NDFaFw0xODA4MTIyMTE5NDFaMIGCMQswCQYDVQQGEwJDTDEiMCAGA1UECAwZTWV0cm9wb2xp dGFuYSBkZSBTYW50aWFnbzEWMBQGA1UEBwwNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAwwMSm9obiBC cmFkbGV5MSAwHgYJKoZIhvcNAQkBFhF2ZTdqdGJAdmU3anRiLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALhTcSiDGvVrm4hlJA8WyFcWWe0dqnuJzstQYTaF281JFOEPA/13kQYI JMXAEUcS7NvW7KdUI0tHU0N6RTo0Ilf1E1nm8No++eqHO8pFUZ/cidpv0r+1Qcl9EgrpbZ00Y7Xg pq06EZELzJAmds4QQcsTKdpLNFbVcFnM11i2Gj5VNsYgO+qPO2AS8rLHkgDWnNkc9/lA+ZK5wGiU zxPU9KnIrERoTif3Zk7KjLvFpBWYD60M/lNoHZ5zxYgmYLmvoM1TSLn4Ms57wwT5MieV2l0aqlGC 7CKNa6XyeL1B0y0wSxL3PJQS4vSLDnttZC7od2A6yjeUMyM3rQ41vqUIMc8CAwEAAaOCAcMwggG/ MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUmA9bUmBmTYkCcZ3yYv8IRRP2nN4wHwYDVR0jBBgwFoAUmZerGDU6i1lFQ5iy cnHI9PsJzxYwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNz bC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGll bnQyLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xp ZW50Mi5jcmwwHAYDVR0RBBUwE4ERdmU3anRiQHZlN2p0Yi5jb20wIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMFUGA1UdIAROMEwwDAYKKwYBBAGBtTcGATA8BgsrBgEEAYG1NwEC BTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4IBAQBqcYJfFA/ITkX4L6JihqW168Wog1BOfkbPXO+wPn5G9P1NwruGfu41b70EPPwV vol+/j+qhSSrDjFyfNBsq4G45GRR6hwx0ei/bH0UW15Y63ASYPkNlj3ydCcvhw5ItWD5aYPphBx9 C7tLnQ7ow09cqt2CIgPd3W/IGri7p4hWPbdcX0oFIhJcDxmCwTcWyoVoIo4aas5gP44LPGneCoqI lXQMJinwneEnKd7rWXlzVWv7geaH3t79zARSw9ev9F4E61cDuHi+vgTFEpio7oxybqfj99yLibhX uZjReYnYbDMRiWDXduVIrIGYwmnUuD8a0b20kJgHm+FEgB6UMa9JMIIF4jCCA8qgAwIBAgIQXLZI bkcMmMZ/9oDbZErijTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1 WhcNMzAxMjE2MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDIgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7g9Q jJUJI4Ss9VBqj9Y3ok4h/TIJZUc+rzj61Rv3hNB/yeEEC1fz3i/EU+MXOOGxM7KCbtCIcJxHIW/k 8RP6sPPMO4cTg7sNzfBWsYsemtY6fN/kVr2R2X+/PjvtxmAaXpGX0znvQPxaE123IMGXy0zEKHZ/ nJDZ199TP9TNn9v+1QO0AZb4oaJ7ch0DpSJa8kF5xiNFDAg9taKKSrVuPHJL9MFFYPIqwShjHg+u YEzjfxbMP2QWwamnaA9Y7fORSDNapduFlARAcDtXdMpAijiG4HKnrN323I0Ka7lDTAWyLtTDCETK sI8fzOyL0inEu1WEVpdPytm8s1rwQB4f9QIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQr MCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRa MFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBSZl6sYNTqLWUVDmLJy ccj0+wnPFjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUd IAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4ICAQCZQUEEzvYk9U4wNHhDu1f9QGwbzAH4m4wIKH8ZidNYwZhyoNKW041iJ002KMW9 ywYM95n4770tT45yH29vTMlZtBvz0h44KuxMLNXRCTDwvV07sT39nPjFi5MpwZaLVueNiaa1vok1 n2Wn8lLcyCltYZNGAEifM0ko/A/vvckftFIZG75RAiZHYtfnrdBGiOxyF+nHI9a33BRX5Vl/3z0+ uHZ/Y6YPbNJ7iboOFrFZBCtt+lp3WaDB62ZoBewiMmd09JrqmMJAEgw3EbfQNtaPzHPg/EOhlZik Rgd4BCrzrbIqB2RKib+gnQJt2uoJaKOaV90S9Xgs3PC837OE9CEmY6/MTTG0xpbLh2hR/rLQ3sCr H56aODeuDrQBq85lXxRbDCERDUR7FZUhHv+i1aQaY59NPu26hDd6nqksSDq2mCddpidPBuGJz9lN X2nRyGkudDuWV6gIr6AZfaYv+ggTXOcCDJZFzMhWdLC7CPvRKxQ7vTiYV+4lgqOvV9MnZc149PPt itTysq/oOv70zx7q+tyaLTa4cqFhCclhIwSwOEJiV3xqQebvmwsDX7BaXGAJZIhbdUbNr3poEgct 6uAxw2zyr69WCJmTUUhz/k1/TT/eCUZJqnMg/6mje7tiVdaUQJcBtJ6cq5+mUDNUB1fohW8EOFai zFpP/0FaP62ctTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMiBDbGllbnQgQ0ECEEAfBHP+tuqufC4R+F+Tu54wCQYFKw4DAhoF AKCCAZkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjA3MjIz ODI5WjAjBgkqhkiG9w0BCQQxFgQUxa/lN/lqUTlon/5NnRovRaZeJSQwgZoGCSsGAQQBgjcQBDGB jDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIg Q2xpZW50IENBAhBAHwRz/rbqrnwuEfhfk7ueMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIgQ2xpZW50IENBAhBA HwRz/rbqrnwuEfhfk7ueMA0GCSqGSIb3DQEBAQUABIIBAHMuUK8reS0R/Q68txujMcuVXHMN6BVn zDbHk6M4A6Un+ut73lchNDOFjN4fdgI1rPf/dub/T0vVRkxkLXebVgoZpyu4UMlmTXdd09aZLC8D qRwcfEvOo31dKGn/c2C0a7D0LJ/xt9GgMV6M+fCiYJdzX/rLxhAwq7grJF7dj7xGCTygxrnleZ4i wZM1g3G1dI9XBmrLgmvK3r0wCMdChts207ZK52J114MMhBn7Dsvrw8Zu1ecGGlQy+83I+NXyBQBr bcPQnMtFPJLW/aQlIuCR6y4ojDsOYNKOHy09W9FQSdN6M0Y0rncJBLJt4s3x+PphT7c5HQM2nSqI xkDyyuoAAAAAAAA= --Apple-Mail=_279C62AC-F029-46C3-9F7F-B0B7DEF30C21-- From nobody Tue Feb 7 14:56:15 2017 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 4C52212948D for ; Tue, 7 Feb 2017 14:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 jc9Y4-DpcZ0U for ; Tue, 7 Feb 2017 14:56:12 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 D51C312947E for ; Tue, 7 Feb 2017 14:56:11 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id k15so149860202qtg.3 for ; Tue, 07 Feb 2017 14:56:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=cxZGZ9fwwh8p9OqpkUxr3nNenr70KMPcLrFiKFgho8Q=; b=fQCYhKgs6SJFkA9Tf+G/jF2yyPlqudjIGaK2Sww9OcOCtNFxbQGF8Zjsq8SWFKqhOF VcvCswq8sHx/8Xgq2nuY/IseFLVoRRtqe8Y2CKENgyfyyu8J3ljJWoQDo9Tmq+5rKPOM r53/dfgMRHYmyEJdGn1TKACjFofEyPjTXIy2rjyO/navai8uB9kqyVk8wVO0/OPHUivc BuQNm532FvEPRqGyfJvgQmtuDQX0FKpz8vYqXrHdibKlkBWARAnXT4YntJq7RHPDh/zV ajWpoW7UZ4q7hnwKIDO8qWKuXG1ZgWn8OFVQIA8SgoBZJrFGar6WtSDgIlPBHOY4Z3P9 WQAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=cxZGZ9fwwh8p9OqpkUxr3nNenr70KMPcLrFiKFgho8Q=; b=LijmM9o23wBM8VmjcNKOdmOF8Xu+Hq5AzhL3EOGNc4asVU8Q+jljkQ0fUqw1gzt9Gp Q/2wgIGWP2kJhYWbD328ohzSJo61nfaUObWvJA94J9uW3iYxp3WzbBRUC4C+kvCND6GS fp716BehiYb/9r4Z0rawoCB2ImCB+F5iiP69FjXMRyZXtD0gEbQo+Gics9xgFb5e5+76 3D3WpVk9S8Kpt2tCJxwqCVACM7pnLzrGfP771+QVATR4kvoEEOUn1f4PgXwtDZzUEAO1 GiybaNtpa5l7vcHk6HEy/F95UG7xcw6l3+KehkZF+Nd5pDzSLqldN5o3NM9wjP9kUOrW q6Gg== X-Gm-Message-State: AMke39mlGPdxRwBruwJLUyuKTUlvWKTbw0VfM2+LAP1OYvTSRnAyKDUWk585UBmtrBOjGBBr X-Received: by 10.200.44.243 with SMTP id 48mr15964872qtx.262.1486508170831; Tue, 07 Feb 2017 14:56:10 -0800 (PST) Received: from [192.168.86.150] ([191.115.72.210]) by smtp.gmail.com with ESMTPSA id h40sm4604965qtb.6.2017.02.07.14.56.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 14:56:10 -0800 (PST) From: John Bradley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C617AC19-606D-4CAB-9C91-ACBF4B8B9A0B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 7 Feb 2017 19:56:03 -0300 In-Reply-To: To: Andrei Popov References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF TokBind WG , =JeffH Hodges Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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, 07 Feb 2017 22:56:14 -0000 --Apple-Mail=_C617AC19-606D-4CAB-9C91-ACBF4B8B9A0B Content-Type: multipart/alternative; boundary="Apple-Mail=_F81A449D-799A-4C3A-B5D8-962AEFF419D8" --Apple-Mail=_F81A449D-799A-4C3A-B5D8-962AEFF419D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Are connection headers normally used in the reverse proxy use case? = Generally the user agent wouldn't know that it was talking to a proxy. I thought that they were more for the forward proxy use case where the = browser is configured to talk to a specific proxy or is transparently = intercepted (man/enterprise in the middle)=20 I could hypothetically see a enterprise proxy creating token binding = Id=E2=80=99s for the connections to servers and mapping those to token = binding ID from the browser.=20 I think the NGNX token binding module = (https://github.com/google/ngx_token_binding = ) is doing that sort of = transparent mapping on the server side for session cookies.=20 We probably don't want the same behaviour for both forward and reverse = proxies. John B. > On Feb 7, 2017, at 7:38 PM, Andrei Popov = wrote: >=20 > When we discussed this early on, there was a strong distaste for = connection headers in the HTTP community, so we've defined TB headers as = per-request. > " clients MUST include the Sec-Token- > Binding header field in their HTTP requests." > We could also explicitly prohibit listing TB headers in the Connection = header, if folks would like to see this clarification.=20 > There are many reasons to keep TB headers per-request; it's not just = about the proxies and terminators. >=20 > Cheers, >=20 > Andrei >=20 > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of = =3DJeffH > Sent: Tuesday, February 7, 2017 2:15 PM > To: IETF TokBind WG > Subject: [Unbearable] on not listing 'Sec-Token-Binding' in the = Connection header field? >=20 > the below is kind of long (read it anyway :) The summary is we need = to make a conscious decision regarding the Connection HTTP request = header field and whether we provide guidance regarding it and the = Sec-Token-Binding header (and what guidance if so), or not. This seems = to have ramifications for the nascent draft-campbell-tokbind-tls-term = draft, unless I'm misunderstanding things. >=20 > =3DJeffH >=20 > In working through the list of "Considerations for New Header Fields" = at the end of rfc7231 section 8.3.1 [1], there are these two items.. >=20 > o Whether it is appropriate to list the field-name in the = Connection > header field (i.e., if the header field is to be hop-by-hop; see > Section 6.1 of [RFC7230]). >=20 > o Under what conditions intermediaries are allowed to insert, > delete, or modify the field's value. >=20 > Given the specifics in [RFC7230] Section 6.1 [2].. >=20 > 6.1. Connection >=20 > The "Connection" header field allows the sender to indicate desired > control options for the current connection. In order to avoid > confusing downstream recipients, a proxy or gateway MUST remove or > replace any received connection options before forwarding the > message. >=20 > When a header field aside from Connection is used to supply control > information for or about the current connection, the sender MUST = list > the corresponding field-name within the Connection header field. A > proxy or gateway MUST parse a received Connection header field = before > a message is forwarded and, for each connection-option in this = field, > remove any header field(s) from the message with the same name as = the > connection-option, and then remove the Connection header field = itself > (or replace it with the intermediary's own connection options for = the > forwarded message). >=20 > Hence, the Connection header field provides a declarative way of > distinguishing header fields that are only intended for the = immediate > recipient ("hop-by-hop") from those fields that are intended for = all > recipients on the chain ("end-to-end"), enabling the message to be > self-descriptive and allowing future connection-specific extensions > to be deployed without fear that they will be blindly forwarded by > older intermediaries. >=20 > ..it offhand seems that one would want to list "Sec-Token-Binding" in = the Connection header field because Sec-Token-Binding is ostensibly = about the connection and is hop-by-hop because TLS is hop-by-hop. >=20 > However, given our current thinking wrt TB and TLS Terminating Reverse = Proxies [3], where we are contemplating one approach where such "TTRPs"=20= > pass-through the Sec-Token-Binding header field and add a = corresponding Token-Binding-Context header, one would not want to list = Sec-Token-Binding in the Connection header (because a TTRP would then = strip it off). However there are implementation and security = considerations with this. >=20 > As one proposal, we could say in HTTPSTB something along the lines = of.. >=20 > [...] > Clients SHOULD NOT list the Sec-Token-Binding header field as > a connection option in the Connection header field (Section 6.1 > of [RFC7230]) in order to generally enable Sec-Token-Binding > header field pass-through by intermediaries, e.g., by TLS > terminating reverse proxies (TTRP). Intermediaries MUST NOT > modify the Sec-Token-Binding header field's value. See also the > security considerations section. > [...] > Security Considerations > [...] > Not listing Sec-Token-Binding in the Connection header: this > enables TTRPs to transparently convey the Sec-Token-Binding header > field, containing a Token Binding Message, to the next tier = ("backend > servers"), e.g., where security tokens containing Token Binding IDs > may be minted and validated. The communication between a TTRP and > backend servers needs to be secured against eavesdropping and > modification by unintended parties. The Token Binding Message itself > may be validated by the TTRP or by a backend server. Though, in the > latter case, the data necessary to perform such validation (i.e., = the > EKM, etc.) needs to be conveyed to the entity performing it. Such > conveyance is out of scope for this specification. >=20 > Listing Sec-Token-Binding in the Connection header: if done, this > may help in ensuring that Token Binding IDs are not inadvertently > revealed to unintended parties, though may cause difficulties with > web sites employing TTRPs. > [...] >=20 > Or, we could just say "clients SHOULD list the Sec-Token-Binding = header field as a connection option in the Connection header field", but = that will create problems for TTRPs [3]. >=20 > Or, we can just not mention the Connection header and see if anyone = raises questions about it during further WG and IETF-wide review. >=20 > thoughts? >=20 > [1] >=20 > [2] >=20 > [3] >=20 >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_F81A449D-799A-4C3A-B5D8-962AEFF419D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Are connection headers normally used in the reverse proxy use = case?   Generally the user agent wouldn't know that it was talking = to a proxy.

I = thought that they were more for the forward proxy use case where the = browser is configured to talk to a specific proxy or is transparently = intercepted (man/enterprise in the middle) 

I could hypothetically see a enterprise = proxy creating token binding Id=E2=80=99s for the connections to servers = and mapping those to token binding ID from the browser. 

I think the NGNX token = binding module (https://github.com/google/ngx_token_binding) is = doing that sort of transparent mapping on the server side for session = cookies. 

We probably don't want the same behaviour for both forward = and reverse proxies.

John B.


On Feb 7, 2017, at 7:38 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

When = we discussed this early on, there was a strong distaste for connection = headers in the HTTP community, so we've defined TB headers as = per-request.
" clients MUST include the Sec-Token-
  Binding header field in their HTTP requests."
We could also explicitly prohibit listing TB headers in the = Connection header, if folks would like to see this clarification.
There are many reasons to keep TB headers per-request; it's = not just about the proxies and terminators.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of = =3DJeffH
Sent: Tuesday, February 7, 2017 2:15 PM
To: IETF TokBind WG <unbearable@ietf.org>
Subject: = [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header = field?

the below is kind of long (read it = anyway :)  The summary is we need to make a conscious decision = regarding the Connection HTTP request header field and whether we = provide guidance regarding it and the Sec-Token-Binding header (and what = guidance if so), or not. This seems to have ramifications for the = nascent draft-campbell-tokbind-tls-term draft, unless I'm = misunderstanding things.

=3DJeffH

In working through the list of "Considerations = for New Header Fields" at the end of rfc7231 section 8.3.1 [1], there = are these two items..

   o =  Whether it is appropriate to list the field-name in the = Connection
      header = field (i.e., if the header field is to be hop-by-hop; see
=       Section 6.1 of [RFC7230]).

   o  Under what = conditions intermediaries are allowed to insert,
=       delete, or modify the field's = value.

Given the specifics in [RFC7230] = Section 6.1 [2]..

  6.1. =  Connection

   The = "Connection" header field allows the sender to indicate desired
   control options for the current = connection.  In order to avoid
=    confusing downstream recipients, a proxy or gateway = MUST remove or
   replace any received = connection options before forwarding the
=    message.

=    When a header field aside from Connection is used to = supply control
   information for or about = the current connection, the sender MUST list
=    the corresponding field-name within the Connection = header field.  A
   proxy or gateway = MUST parse a received Connection header field before
=    a message is forwarded and, for each connection-option = in this field,
   remove any header = field(s) from the message with the same name as the
=    connection-option, and then remove the Connection = header field itself
   (or replace it with = the intermediary's own connection options for the
=    forwarded message).

=    Hence, the Connection header field provides a = declarative way of
   distinguishing = header fields that are only intended for the immediate
=    recipient ("hop-by-hop") from those fields that are = intended for all
   recipients on the = chain ("end-to-end"), enabling the message to be
=    self-descriptive and allowing future = connection-specific extensions
   to be = deployed without fear that they will be blindly forwarded by
   older intermediaries.

..it offhand seems that one would want to list = "Sec-Token-Binding" in the Connection header field because = Sec-Token-Binding is ostensibly about the connection and is hop-by-hop = because TLS is hop-by-hop.

However, given = our current thinking wrt TB and TLS Terminating Reverse Proxies [3], = where we are contemplating one approach where such "TTRPs"
pass-through the Sec-Token-Binding header field and add a = corresponding Token-Binding-Context header, one would not want to list = Sec-Token-Binding in the Connection header (because a TTRP would then = strip it off). However there are implementation and security = considerations with this.

As one proposal, = we could say in HTTPSTB something along the lines of..

  [...]
  Clients SHOULD = NOT list the Sec-Token-Binding header field as
=   a connection option in the Connection header field (Section = 6.1
  of [RFC7230]) in order to generally = enable Sec-Token-Binding
  header field = pass-through by intermediaries, e.g., by TLS
=   terminating reverse proxies (TTRP). Intermediaries MUST = NOT
  modify the Sec-Token-Binding header = field's value. See also the
  security = considerations section.
  [...]
=   Security Considerations
  [...]
  Not listing Sec-Token-Binding in the Connection = header: this
  enables TTRPs to transparently = convey the Sec-Token-Binding header
  field, = containing a Token Binding Message, to the next tier ("backend
  servers"), e.g., where security tokens = containing Token Binding IDs
  may be minted = and validated. The communication between a TTRP and
=   backend servers needs to be secured against eavesdropping = and
  modification by unintended parties. The = Token Binding Message itself
  may be validated = by the TTRP or by a backend server. Though, in the
=   latter case, the data necessary to perform such validation = (i.e., the
  EKM, etc.) needs to be conveyed to = the entity performing it. Such
  conveyance is = out of scope for this specification.

=   Listing Sec-Token-Binding in the Connection header: if done, = this
  may help in ensuring that Token Binding = IDs are not inadvertently
  revealed to = unintended parties, though may cause difficulties with
=   web sites employing TTRPs.
=   [...]

Or, we could just say = "clients SHOULD list the Sec-Token-Binding header field as a connection = option in the Connection header field", but that will create problems = for TTRPs [3].

Or, we can just not mention = the Connection header and see if anyone raises questions about it during = further WG and IETF-wide review.

thoughts?
[1] <https://tools.ietf.org/html/rfc7231#section-8.3.1>

[2] <https://tools.ietf.org/html/rfc7230#section-6.1>

[3] <https://tools.ietf.org/html/draft-campbell-tokbind-tls-term= >


_______________________________________________
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

= --Apple-Mail=_F81A449D-799A-4C3A-B5D8-962AEFF419D8-- --Apple-Mail=_C617AC19-606D-4CAB-9C91-ACBF4B8B9A0B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILMTCCBUcw ggQvoAMCAQICEEAfBHP+tuqufC4R+F+Tu54wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAyIENsaWVudCBDQTAeFw0xNjA4MTIy MTE5NDFaFw0xODA4MTIyMTE5NDFaMIGCMQswCQYDVQQGEwJDTDEiMCAGA1UECAwZTWV0cm9wb2xp dGFuYSBkZSBTYW50aWFnbzEWMBQGA1UEBwwNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAwwMSm9obiBC cmFkbGV5MSAwHgYJKoZIhvcNAQkBFhF2ZTdqdGJAdmU3anRiLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALhTcSiDGvVrm4hlJA8WyFcWWe0dqnuJzstQYTaF281JFOEPA/13kQYI JMXAEUcS7NvW7KdUI0tHU0N6RTo0Ilf1E1nm8No++eqHO8pFUZ/cidpv0r+1Qcl9EgrpbZ00Y7Xg pq06EZELzJAmds4QQcsTKdpLNFbVcFnM11i2Gj5VNsYgO+qPO2AS8rLHkgDWnNkc9/lA+ZK5wGiU zxPU9KnIrERoTif3Zk7KjLvFpBWYD60M/lNoHZ5zxYgmYLmvoM1TSLn4Ms57wwT5MieV2l0aqlGC 7CKNa6XyeL1B0y0wSxL3PJQS4vSLDnttZC7od2A6yjeUMyM3rQ41vqUIMc8CAwEAAaOCAcMwggG/ MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUmA9bUmBmTYkCcZ3yYv8IRRP2nN4wHwYDVR0jBBgwFoAUmZerGDU6i1lFQ5iy cnHI9PsJzxYwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNz bC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGll bnQyLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xp ZW50Mi5jcmwwHAYDVR0RBBUwE4ERdmU3anRiQHZlN2p0Yi5jb20wIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMFUGA1UdIAROMEwwDAYKKwYBBAGBtTcGATA8BgsrBgEEAYG1NwEC BTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4IBAQBqcYJfFA/ITkX4L6JihqW168Wog1BOfkbPXO+wPn5G9P1NwruGfu41b70EPPwV vol+/j+qhSSrDjFyfNBsq4G45GRR6hwx0ei/bH0UW15Y63ASYPkNlj3ydCcvhw5ItWD5aYPphBx9 C7tLnQ7ow09cqt2CIgPd3W/IGri7p4hWPbdcX0oFIhJcDxmCwTcWyoVoIo4aas5gP44LPGneCoqI lXQMJinwneEnKd7rWXlzVWv7geaH3t79zARSw9ev9F4E61cDuHi+vgTFEpio7oxybqfj99yLibhX uZjReYnYbDMRiWDXduVIrIGYwmnUuD8a0b20kJgHm+FEgB6UMa9JMIIF4jCCA8qgAwIBAgIQXLZI bkcMmMZ/9oDbZErijTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1 WhcNMzAxMjE2MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDIgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7g9Q jJUJI4Ss9VBqj9Y3ok4h/TIJZUc+rzj61Rv3hNB/yeEEC1fz3i/EU+MXOOGxM7KCbtCIcJxHIW/k 8RP6sPPMO4cTg7sNzfBWsYsemtY6fN/kVr2R2X+/PjvtxmAaXpGX0znvQPxaE123IMGXy0zEKHZ/ nJDZ199TP9TNn9v+1QO0AZb4oaJ7ch0DpSJa8kF5xiNFDAg9taKKSrVuPHJL9MFFYPIqwShjHg+u YEzjfxbMP2QWwamnaA9Y7fORSDNapduFlARAcDtXdMpAijiG4HKnrN323I0Ka7lDTAWyLtTDCETK sI8fzOyL0inEu1WEVpdPytm8s1rwQB4f9QIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQr MCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRa MFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBSZl6sYNTqLWUVDmLJy ccj0+wnPFjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUd IAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4ICAQCZQUEEzvYk9U4wNHhDu1f9QGwbzAH4m4wIKH8ZidNYwZhyoNKW041iJ002KMW9 ywYM95n4770tT45yH29vTMlZtBvz0h44KuxMLNXRCTDwvV07sT39nPjFi5MpwZaLVueNiaa1vok1 n2Wn8lLcyCltYZNGAEifM0ko/A/vvckftFIZG75RAiZHYtfnrdBGiOxyF+nHI9a33BRX5Vl/3z0+ uHZ/Y6YPbNJ7iboOFrFZBCtt+lp3WaDB62ZoBewiMmd09JrqmMJAEgw3EbfQNtaPzHPg/EOhlZik Rgd4BCrzrbIqB2RKib+gnQJt2uoJaKOaV90S9Xgs3PC837OE9CEmY6/MTTG0xpbLh2hR/rLQ3sCr H56aODeuDrQBq85lXxRbDCERDUR7FZUhHv+i1aQaY59NPu26hDd6nqksSDq2mCddpidPBuGJz9lN X2nRyGkudDuWV6gIr6AZfaYv+ggTXOcCDJZFzMhWdLC7CPvRKxQ7vTiYV+4lgqOvV9MnZc149PPt itTysq/oOv70zx7q+tyaLTa4cqFhCclhIwSwOEJiV3xqQebvmwsDX7BaXGAJZIhbdUbNr3poEgct 6uAxw2zyr69WCJmTUUhz/k1/TT/eCUZJqnMg/6mje7tiVdaUQJcBtJ6cq5+mUDNUB1fohW8EOFai zFpP/0FaP62ctTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMiBDbGllbnQgQ0ECEEAfBHP+tuqufC4R+F+Tu54wCQYFKw4DAhoF AKCCAZkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjA3MjI1 NjAzWjAjBgkqhkiG9w0BCQQxFgQUtJCOohPQjMZMtcc16VYpx7mcmccwgZoGCSsGAQQBgjcQBDGB jDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIg Q2xpZW50IENBAhBAHwRz/rbqrnwuEfhfk7ueMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIgQ2xpZW50IENBAhBA HwRz/rbqrnwuEfhfk7ueMA0GCSqGSIb3DQEBAQUABIIBALYiufgW9kquh3QUS8lNunmqFSpGssXr mTA2dKDBkZI4MNJXDCFnNRyPotDPC4Zo/wtNMvrLIgCaHgZfzM17/f/PYMptt3VtyJq3c5BtRUSy /uAJsnMYcm35UTQSEbSGTkdbvPbWnHpax7xfJVkwAC67hb9c3jgtLudknfsExOSSGLxLUMbJfu52 uVxg75iWVva+kyD2D+7v1AjS9wj0zNn8HWRIbIIJ+zsjodtFx2JfKyP4xaVWA+DYCxwEok7Qcz6F GkeB/E90V2DUDrUCC0dpBXoJBSF9DIEI3U4/NnFMZv36QwtWHGHh1k6A/y2MhdQdOIDHKysKngov T2/AW+MAAAAAAAA= --Apple-Mail=_C617AC19-606D-4CAB-9C91-ACBF4B8B9A0B-- From nobody Tue Feb 7 16:36:22 2017 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 F14FD12956B for ; Tue, 7 Feb 2017 16:36:20 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 I3oXaPzT4JrD for ; Tue, 7 Feb 2017 16:36:18 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002: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 EA75A1293F5 for ; Tue, 7 Feb 2017 16:36:17 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id w75so77289679ywg.1 for ; Tue, 07 Feb 2017 16:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ROnTCNZxRSsu8QcZAzohnH7mgPohG6oU3P0TdgD40C4=; b=eLAmPyUMufaFB8Fd5GaAiT/zaFPckLN9lSG0zY7gqNtVaTIUU2QNL2GYuquMQ5F6hp 6074vFnLeFz8M6E4DiVtX0MbNXwvvCNWJq5Bj+lDuC8Ryu0kPWqOGEqk/ez0JJH1KKTc kIsmcRq1LEdtEcoEFb+ZOvLNSWasY+AhgTHaJ7pYgm2B8m2qdHEeZKhFozihm79+9FHl ckEbY6sW34o3zEVXAFxEhBTF8gusT0C64XAvL3b93AgL7cAk/ll7ndZyyLY1914808Z0 Q9GpXOx7pRU0GQ4FG5E+xcd2bsUA3EdrrZ3EAi+UcldJc8oQILCk2pzM45NiPpINFuch YQJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ROnTCNZxRSsu8QcZAzohnH7mgPohG6oU3P0TdgD40C4=; b=PZHVKlpgCdtYm4CKngbYWn7y3AbwMPge8WDw/Qe3VB5QsjU6k6tQH/RCDJcMfs63LF 4iGklYvf9aL/Mu+e7Cvy/JklkeoNgArRMOu79OfTfk+ImDpnshmTu913VcrKaxSaH9kX r7ZbqQ27AHT2o9pBqqgZL+ApY55q5awo6GKZ3XwNT1z8mIh7Y0Wngt8QkNSw0O0nwwQT 9BVt7rBubNinqoi5aTfV1C/g5pezo/sIx+4KBK4KZIaTp9k7dfYiF6FzpPQ1ZpObHEs3 mFmgT82mYtJvNyfEAbUW4AtoaCXlsrun3jli2HlCmGvPCE8HhEz/O09hjkCGSsW/t3/O QxYw== X-Gm-Message-State: AMke39maBjzi/QeN5mOzllzAKpFSm01e/csW2Gej9qFYb90+tN39NO1/gwmVNau1TRk3WNBHbAA4U3ifGzltq6XE X-Received: by 10.129.130.3 with SMTP id s3mr12970048ywf.179.1486514177067; Tue, 07 Feb 2017 16:36:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.161.87 with HTTP; Tue, 7 Feb 2017 16:35:56 -0800 (PST) In-Reply-To: References: From: Nick Harper Date: Tue, 7 Feb 2017 16:35:56 -0800 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=94eb2c07a5ba7aad0e0547fa0d82 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] 0-RTT Token Binding: When to switch exporters? 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, 08 Feb 2017 00:36:21 -0000 --94eb2c07a5ba7aad0e0547fa0d82 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've been thinking about this approach for a while (and what it would take to implement it), and I've come to the conclusion that requiring switching exporters to match the switch of encryption keys is infeasible enough that it won't get implemented. Instead, I propose that if a server accepts the client's 0-RTT data, then the client uses the 0-RTT exporter for the entirety of the connection, and otherwise the client uses the exporter as already specified in TBPROTO. This still has decent security properties. First, consider a server that is uncomfortable enough with the early exporter that it does not want to accept any token bindings that use that exporter. This server rejects all early data on connections where the client tries to negotiate token binding, and falls back on using the existing exporter in TBPROTO with no early data. Next, consider a server that does accept some requests sent in early data with a token binding that used the early exporter (the only choice in a request in early data). For this request, since the server accepted it, it has decided that the early exporter provides enough security to verify the binding (otherwise this server would be in the above category). If the early exporter was good enough for this server on a request sent in early data, then surely that server would accept the same request (with the same token binding) when sent under the forward-secure encryption keys. A server accepting early data should accept any request sent in early data. The server can't sniff the early data to reject it if it contains a request it doesn't like (e.g. a POST request), because the early data could contain multiple requests (e.g. in the case of HTTP/2), and the server MUST process the ClientHello and immediately send the ServerHello - it cannot wait to process all of the client's early data. It follows that if a server will accept a token-bound request in early data, then it will accept any token-bound request in early data, meaning that the server finds the early exporter used for the token binding acceptable no matter the request. If the server is fine with the early exporter for every request, then it should accept the early exporter when it is used for requests not sent in early data as well. In other words, if the server does not want to allow the early exporter to be used for token bindings on some requests, then the only logical thing for that server to do is always reject early data if token binding is negotiated. On Fri, Jan 13, 2017 at 2:18 PM, Andrei Popov wrote: > =C3=98 Another way to move the change in exporters out of the client's > control would be to do it at a time that is implicit in the protocol. An > obvious choice would be switch exporters when the client switches from > sending early data to sending data post-handshake. > > I think this type of approach is better. > > > > Cheers, > > > > Andrei > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Ni= ck > Harper > *Sent:* Friday, January 13, 2017 12:30 PM > *To:* IETF Tokbind WG > *Subject:* [Unbearable] 0-RTT Token Binding: When to switch exporters? > > > > The current tokbind 0-RTT draft has the TLS 1.3 early exporter value used > in the TokenBinding.signature for the entirety of the connection. One poi= nt > of discussion that came up in Seoul was that we shouldn't use the 0-RTT > exporter for too long. I agree that we shouldn't use it for too long, but= I > can't remember (or figure out from the meeting notes) if the reason is ju= st > because we prefer the crypto properties of the normal exporter, or are we > also trying to prevent an attacker from being able to use the 0-RTT > exporter indefinitely? > > > > For the first case, the switch from the 0-RTT exporter to the normal > exporter can be client-initiated. One possible design would be to have th= e > client send an extension in the TokenBinding indicating that all future > TokenBindings will use the normal exporter. This would function similar t= o > the ratcheting idea (from section 4.1 of the I-D), but the ratchet doesn'= t > take effect until this indicator extension is sent (before it's sent the > server would accept both exporters). This would likely be done in > combination with the idea of defining new key types to indicate that the > 0-RTT exporter is in use so the server doesn't do trial verification. > > > > If we want to move the switch from 0-RTT exporter to normal exporter out > of the client's control (so that an attacker can't keep using the 0-RTT > exporter indefinitely), a different solution is needed. One possible idea > is to have the server send a message that conceptually means "all future > TokenBindings must not use the 0-RTT exporter". Right now, Token Binding > doesn't have any server-to-client messages, so this would require definin= g > application-specific messages. Another way to move the change in exporter= s > out of the client's control would be to do it at a time that is implicit = in > the protocol. An obvious choice would be switch exporters when the client > switches from sending early data to sending data post-handshake. > --94eb2c07a5ba7aad0e0547fa0d82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've been thinking about this approach for a while (an= d what it would take to implement it), and I've come to the conclusion = that requiring switching exporters to match the switch of encryption keys i= s infeasible enough that it won't get implemented.

I= nstead, I propose that if a server accepts the client's 0-RTT data, the= n the client uses the 0-RTT exporter for the entirety of the connection, an= d otherwise the client uses the exporter as already specified in TBPROTO. T= his still has decent security properties.

First, c= onsider a server that is uncomfortable enough with the early exporter that = it does not want to accept any token bindings that use that exporter. This = server rejects all early data on connections where the client tries to nego= tiate token binding, and falls back on using the existing exporter in TBPRO= TO with no early data.

Next, consider a server tha= t does accept some requests sent in early data with a token binding that us= ed the early exporter (the only choice in a request in early data). For thi= s request, since the server accepted it, it has decided that the early expo= rter provides enough security to verify the binding (otherwise this server = would be in the above category). If the early exporter was good enough for = this server on a request sent in early data, then surely that server would = accept the same request (with the same token binding) when sent under the f= orward-secure encryption keys.

A server accepting = early data should accept any request sent in early data. The server can'= ;t sniff the early data to reject it if it contains a request it doesn'= t like (e.g. a POST request), because the early data could contain multiple= requests (e.g. in the case of HTTP/2), and the server MUST process the Cli= entHello and immediately send the ServerHello - it cannot wait to process a= ll of the client's early data. It follows that if a server will accept = a token-bound request in early data, then it will accept any token-bound re= quest in early data, meaning that the server finds the early exporter used = for the token binding acceptable no matter the request. If the server is fi= ne with the early exporter for every request, then it should accept the ear= ly exporter when it is used for requests not sent in early data as well. In= other words, if the server does not want to allow the early exporter to be= used for token bindings on some requests, then the only logical thing for = that server to do is always reject early data if token binding is negotiate= d.

On = Fri, Jan 13, 2017 at 2:18 PM, Andrei Popov <Andrei.Popov@microsof= t.com> wrote:

=C3=98=C2=A0 Another way to move the change in exporters out= of the client's control would be to do it at a time that is implicit i= n the protocol. An obvious choice would be switch exporters when the client= switches from sending early data to sending data post-handshake.

I think this type of approach is better.<= /u>

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Nick Harper
Sent: Friday, January 13, 2017 12:30 PM
To: IETF Tokbind WG <unbearable@ietf.org>
Subject: [Unbearable] 0-RTT Token Binding: When to switch exporters?=

=C2=A0

The current tokbind 0-RTT draft has the TLS 1.3 earl= y exporter value used in the TokenBinding.signature for the entirety of the= connection. One point of discussion that came up in Seoul was that we shou= ldn't use the 0-RTT exporter for too long. I agree that we shouldn't use it for too long, but I can't r= emember (or figure out from the meeting notes) if the reason is just becaus= e we prefer the crypto properties of the normal exporter, or are we also tr= ying to prevent an attacker from being able to use the 0-RTT exporter indefinitely?

=C2=A0

For the first case, the switch from the 0-RTT export= er to the normal exporter can be client-initiated. One possible design woul= d be to have the client send an extension in the TokenBinding indicating th= at all future TokenBindings will use the normal exporter. This would function similar to the ratcheting idea (f= rom section 4.1 of the I-D), but the ratchet doesn't take effect until = this indicator extension is sent (before it's sent the server would acc= ept both exporters). This would likely be done in combination with the idea of defining new key types to indicate th= at the 0-RTT exporter is in use so the server doesn't do trial verifica= tion.

=C2=A0

If we want to move the switch from 0-RTT exporter to= normal exporter out of the client's control (so that an attacker can&#= 39;t keep using the 0-RTT exporter indefinitely), a different solution is n= eeded. One possible idea is to have the server send a message that conceptually means "all future TokenBindings must= not use the 0-RTT exporter". Right now, Token Binding doesn't hav= e any server-to-client messages, so this would require defining application= -specific messages. Another way to move the change in exporters out of the client's control would be to do it at a time t= hat is implicit in the protocol. An obvious choice would be switch exporter= s when the client switches from sending early data to sending data post-han= dshake.


--94eb2c07a5ba7aad0e0547fa0d82-- From nobody Tue Feb 7 19:53:13 2017 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 42B1812984F for ; Tue, 7 Feb 2017 19:53:12 -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 b7e1Lo7W85g7 for ; Tue, 7 Feb 2017 19:53:09 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 6496A129847 for ; Tue, 7 Feb 2017 19:53:09 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id d9so31269052itc.0 for ; Tue, 07 Feb 2017 19:53:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=64vWWsXudZJJCxcCQW8RkvWZOlLP33bZUWLUY2WDkB0=; b=KaEvEKheVSH534JWl0fM4eED3fcb8rfEVrL72JY0rFkNWZC3jU4hYpDXdGwdKpealv Kn23ot1YMXvjUKtFukoCVzJeeZ7uojjQehD/lUK93G7VR5uAgcAmkojUb+7dRhdnU/5N udU+jZcAD0rwFX20kR6XHuTr8YiFcNP+CxFt14Ysyolg34xiuHbCXfjRHOz0HNrDMt/1 xwCsLU/j/n7+T49xQXCsxNn0N5Rx8bKPvZLril1UxbKR64CWZrXVbvyEQxpTOcPsW8kA VW2y9DmLslP82XbK/kKe4hAOUKpbsMl0PDMz1gZiTVfk4GS9sJK/uTcAiHJlhkkNAt70 Gklw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=64vWWsXudZJJCxcCQW8RkvWZOlLP33bZUWLUY2WDkB0=; b=sU0VIZsd4sXFdpqleb2mr6rc/QpOICfBtlYRIfnXv07T/CcYEsTkJaDXEBZvSjUNj3 Yf1whTq5RXK+xCPCP2uTC9oArHA3iBasC7Ki7Yh+AyWyjxBpILi30wZWdgTA33uViFTd oEz790LhfOTiSR8KlfE1hR/3cQ/PSdrS5QGCWoF5uuJRRF7nu/kZvhUqNyOK+xCNaWal npoT1owNVV2d+n9xCQjN5f1THJx3emAwcxhcsQlkJMaQKQmSX8fQq+aERqVRRomwjJ8g IKs7rLqNrjULKZIwGzxbSRq+I2o2J6kh1xqGiRAOMlfR4/+eQtGgRYpH/WPd6ABkv3ZA zCsw== X-Gm-Message-State: AIkVDXLmCT/ZWmjm2XLOpkLhRh4D5uHfaoveYTxhsg5BION5VbXXI0n503zVs6MD0uqTySKgp3+eAUuDWvi5YPZC X-Received: by 10.36.214.86 with SMTP id o83mr15605839itg.97.1486525988531; Tue, 07 Feb 2017 19:53:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dirk Balfanz Date: Wed, 08 Feb 2017 03:52:56 +0000 Message-ID: To: John Bradley , Andrei Popov Content-Type: multipart/alternative; boundary=001a11470b387f59fb0547fccdd9 Archived-At: Cc: IETF TokBind WG , =JeffH Hodges Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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, 08 Feb 2017 03:53:12 -0000 --001a11470b387f59fb0547fccdd9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't feel strongly about this - I'm fine either way, but would suggest the following: - The Connect header is for the client to tell a proxy "this header really doesn't make sense to forward, please drop it on the next hop". - Clients usually aren't aware that they're talking to a TTRP, so I agree with John that that's probably not a use case that the Connect header was meant for. - If the client *is* aware that it's talking to a proxy, listing Sec-Token-Binding in the Connect header (thus indicating that it shouldn't be forwarded) makes sense to me. - If the proxy has some sort of arrangement with the downstream server that it's supposed to communicate the Token Binding information (like a TTRP would), it has a two options: * verify the Token Binding information and forward just the Token Binding ID to the downstream server (using some mechanism proprietary to the proxy and downstream server). * forward the Sec-Token-Binding header, and (using some mechanism proprietary to the proxy and downstream server) the EKM information, to the downstream server. If the proxy has qualms about violating the spec by forwarding the Sec-Token-Binding header despite its being listed in the Connect header, it can always just use a different header name, like "Private-Forwarded-Token-Binding", or whatever - some mechanism proprietary to the proxy and downstream server. - Either way, the proxy will have to know what the Sec-Token-Binding header means and use some sort of proprietary mechanism between itself and the downstream server to pass on the information that the downstream server needs. - For a proxy that *doesn't* know what the Sec-Token-Binding header means, it's probably best to just drop it, thus saving the downstream server some work verifying a header that we know won't verify. So to me it seems that listing it in the Connect header is the right answer, but like I said I don't feel strongly about it. Dirk. On Tue, Feb 7, 2017 at 2:56 PM John Bradley wrote: > Are connection headers normally used in the reverse proxy use case? > Generally the user agent wouldn't know that it was talking to a proxy. > > I thought that they were more for the forward proxy use case where the > browser is configured to talk to a specific proxy or is transparently > intercepted (man/enterprise in the middle) > > I could hypothetically see a enterprise proxy creating token binding Id= =E2=80=99s > for the connections to servers and mapping those to token binding ID from > the browser. > > I think the NGNX token binding module ( > https://github.com/google/ngx_token_binding) is doing that sort of > transparent mapping on the server side for session cookies. > > We probably don't want the same behaviour for both forward and reverse > proxies. > > John B. > > > On Feb 7, 2017, at 7:38 PM, Andrei Popov > wrote: > > When we discussed this early on, there was a strong distaste for > connection headers in the HTTP community, so we've defined TB headers as > per-request. > " clients MUST include the Sec-Token- > Binding header field in their HTTP requests." > We could also explicitly prohibit listing TB headers in the Connection > header, if folks would like to see this clarification. > There are many reasons to keep TB headers per-request; it's not just abou= t > the proxies and terminators. > > Cheers, > > Andrei > > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org > ] On Behalf Of =3DJeffH > Sent: Tuesday, February 7, 2017 2:15 PM > To: IETF TokBind WG > Subject: [Unbearable] on not listing 'Sec-Token-Binding' in the Connectio= n > header field? > > the below is kind of long (read it anyway :) The summary is we need to > make a conscious decision regarding the Connection HTTP request header > field and whether we provide guidance regarding it and the > Sec-Token-Binding header (and what guidance if so), or not. This seems to > have ramifications for the nascent draft-campbell-tokbind-tls-term draft, > unless I'm misunderstanding things. > > =3DJeffH > > In working through the list of "Considerations for New Header Fields" at > the end of rfc7231 section 8.3.1 [1], there are these two items.. > > o Whether it is appropriate to list the field-name in the Connection > header field (i.e., if the header field is to be hop-by-hop; see > Section 6.1 of [RFC7230]). > > o Under what conditions intermediaries are allowed to insert, > delete, or modify the field's value. > > Given the specifics in [RFC7230] Section 6.1 [2].. > > 6.1. Connection > > The "Connection" header field allows the sender to indicate desired > control options for the current connection. In order to avoid > confusing downstream recipients, a proxy or gateway MUST remove or > replace any received connection options before forwarding the > message. > > When a header field aside from Connection is used to supply control > information for or about the current connection, the sender MUST list > the corresponding field-name within the Connection header field. A > proxy or gateway MUST parse a received Connection header field before > a message is forwarded and, for each connection-option in this field, > remove any header field(s) from the message with the same name as the > connection-option, and then remove the Connection header field itself > (or replace it with the intermediary's own connection options for the > forwarded message). > > Hence, the Connection header field provides a declarative way of > distinguishing header fields that are only intended for the immediate > recipient ("hop-by-hop") from those fields that are intended for all > recipients on the chain ("end-to-end"), enabling the message to be > self-descriptive and allowing future connection-specific extensions > to be deployed without fear that they will be blindly forwarded by > older intermediaries. > > ..it offhand seems that one would want to list "Sec-Token-Binding" in the > Connection header field because Sec-Token-Binding is ostensibly about the > connection and is hop-by-hop because TLS is hop-by-hop. > > However, given our current thinking wrt TB and TLS Terminating Reverse > Proxies [3], where we are contemplating one approach where such "TTRPs" > pass-through the Sec-Token-Binding header field and add a corresponding > Token-Binding-Context header, one would not want to list Sec-Token-Bindin= g > in the Connection header (because a TTRP would then strip it off). Howeve= r > there are implementation and security considerations with this. > > As one proposal, we could say in HTTPSTB something along the lines of.. > > [...] > Clients SHOULD NOT list the Sec-Token-Binding header field as > a connection option in the Connection header field (Section 6.1 > of [RFC7230]) in order to generally enable Sec-Token-Binding > header field pass-through by intermediaries, e.g., by TLS > terminating reverse proxies (TTRP). Intermediaries MUST NOT > modify the Sec-Token-Binding header field's value. See also the > security considerations section. > [...] > Security Considerations > [...] > Not listing Sec-Token-Binding in the Connection header: this > enables TTRPs to transparently convey the Sec-Token-Binding header > field, containing a Token Binding Message, to the next tier ("backend > servers"), e.g., where security tokens containing Token Binding IDs > may be minted and validated. The communication between a TTRP and > backend servers needs to be secured against eavesdropping and > modification by unintended parties. The Token Binding Message itself > may be validated by the TTRP or by a backend server. Though, in the > latter case, the data necessary to perform such validation (i.e., the > EKM, etc.) needs to be conveyed to the entity performing it. Such > conveyance is out of scope for this specification. > > Listing Sec-Token-Binding in the Connection header: if done, this > may help in ensuring that Token Binding IDs are not inadvertently > revealed to unintended parties, though may cause difficulties with > web sites employing TTRPs. > [...] > > Or, we could just say "clients SHOULD list the Sec-Token-Binding header > field as a connection option in the Connection header field", but that wi= ll > create problems for TTRPs [3]. > > Or, we can just not mention the Connection header and see if anyone raise= s > questions about it during further WG and IETF-wide review. > > thoughts? > > [1] > > [2] > > [3] > > > _______________________________________________ > 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 > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a11470b387f59fb0547fccdd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't feel strongly about this - I'm fine either= way, but would suggest the following:

- The Connect hea= der is for the client to tell a proxy "this header really doesn't = make sense to forward, please drop it on the next hop".
- Cl= ients usually aren't aware that they're talking to a TTRP, so I agr= ee with John that that's probably not a use case that the Connect heade= r was meant for.
- If the client *is* aware that it's talking= to a proxy, listing Sec-Token-Binding in the Connect header (thus indicati= ng that it shouldn't be forwarded) makes sense to me.
- If th= e proxy has some sort of arrangement with the downstream server that it'= ;s supposed to communicate the Token Binding information (like a TTRP would= ), it has a two options:
=C2=A0 * verify the Token Binding inform= ation and forward just the Token Binding ID to the downstream server (using= some mechanism proprietary to the proxy and downstream server).
= =C2=A0 * forward the Sec-Token-Binding header, and (using some mechanism pr= oprietary to the proxy and downstream server) the EKM information, to the d= ownstream server.
If the proxy has qualms about violating the spe= c by forwarding the Sec-Token-Binding header despite its being listed in th= e Connect header, it can always just use a different header name, like &quo= t;Private-Forwarded-Token-Binding", or whatever - some =C2=A0mechanism= proprietary to the proxy and downstream server.
- Either way, th= e proxy will have to know what the Sec-Token-Binding header means and use s= ome sort of proprietary mechanism between itself and the downstream server = to pass on the information that the downstream server needs.
- Fo= r a proxy that *doesn't* know what the Sec-Token-Binding header means, = it's probably best to just drop it, thus saving the downstream server s= ome work verifying a header that we know won't verify.

So to me it seems that listing it in the Connect header is the rig= ht answer, but like I said I don't feel strongly about it.
Dirk.


On Tue, Feb 7, 2017 at 2:56 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
Are connection headers normally used in the reverse proxy use case= ? =C2=A0 Generally the user agent wouldn't know that it was talking to = a proxy.

I thought that they were more for the forward proxy use case= where the browser is configured to talk to a specific proxy or is transpar= ently intercepted (man/enterprise in the middle)=C2=A0

I could hy= pothetically see a enterprise proxy creating token binding Id=E2=80=99s for= the connections to servers and mapping those to token binding ID from the = browser.=C2=A0

=
I think the NGNX token binding module (https://github.com/google/ngx_token_binding)=C2=A0is doing that= sort of transparent mapping on the server side for session cookies.=C2=A0<= /div>

We probably don't want the same behaviour for both forward an= d reverse proxies.

John B.


On Feb 7, 2017, at 7:38 PM, Andrei Popov <Andrei.Popov@micr= osoft.com> wrote:

When we discussed this early on, there was a strong distaste for connectio= n headers in the HTTP community, so we've defined TB headers as per-req= uest.
" clients MUST include the Sec-Token-
=C2=A0=C2=A0Binding header field in their HTTP request= s."
We could also explicitly prohibit listing T= B headers in the Connection header, if folks would like to see this clarifi= cation.
There are many reasons to keep TB headers p= er-request; it's not just about the proxies and terminators.

Cheers,

Andrei

--= ---Original Message-----
From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of =3DJeffH
Sent: Tuesday, February 7, 2017 2:15 PM
To: IETF TokBind WG <unbearable@ietf.org>
Subject: [Unbearable] on not listing 'Sec-Token-Binding' in th= e Connection header field?

t= he below is kind of long (read it anyway :) =C2=A0The summary is we need to= make a conscious decision regarding the Connection HTTP request header fie= ld and whether we provide guidance regarding it and the Sec-Token-Binding h= eader (and what guidance if so), or not. This seems to have ramifications f= or the nascent draft-campbell-tokbind-tls-term draft, unless I'm misund= erstanding things.

=3DJeffH<= br class=3D"gmail_msg">
In working through the list = of "Considerations for New Header Fields" at the end of rfc7231 s= ection 8.3.1 [1], there are these two items..

=C2=A0=C2=A0=C2=A0o =C2=A0Whether it is appropriate to l= ist the field-name in the Connection
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0header field (i.e., if the header field is to be ho= p-by-hop; see
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0S= ection 6.1 of [RFC7230]).

= =C2=A0=C2=A0=C2=A0o =C2=A0Under what conditions intermediaries are allowed = to insert,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dele= te, or modify the field's value.

Given the specifics in [RFC7230] Section 6.1 [2]..

=C2=A0=C2=A06.1.=C2=A0 Connection

=C2=A0=C2=A0=C2=A0The "Connect= ion" header field allows the sender to indicate desired
=C2=A0=C2=A0=C2=A0control options for the current connection.=C2= =A0 In order to avoid
=C2=A0=C2=A0=C2=A0confusing d= ownstream recipients, a proxy or gateway MUST remove or
=C2=A0=C2=A0=C2=A0replace any received connection options before forwa= rding the
=C2=A0=C2=A0=C2=A0message.

=C2=A0=C2=A0=C2=A0When a header field asi= de from Connection is used to supply control
=C2=A0= =C2=A0=C2=A0information for or about the current connection, the sender MUS= T list
=C2=A0=C2=A0=C2=A0the corresponding field-na= me within the Connection header field. =C2=A0A
=C2= =A0=C2=A0=C2=A0proxy or gateway MUST parse a received Connection header fie= ld before
=C2=A0=C2=A0=C2=A0a message is forwarded = and, for each connection-option in this field,
=C2= =A0=C2=A0=C2=A0remove any header field(s) from the message with the same na= me as the
=C2=A0=C2=A0=C2=A0connection-option, and = then remove the Connection header field itself
=C2= =A0=C2=A0=C2=A0(or replace it with the intermediary's own connection op= tions for the
=C2=A0=C2=A0=C2=A0forwarded message).=

=C2=A0=C2=A0=C2=A0Hence, t= he Connection header field provides a declarative way of
=C2=A0=C2=A0=C2=A0distinguishing header fields that are only intended= for the immediate
=C2=A0=C2=A0=C2=A0recipient (&qu= ot;hop-by-hop") from those fields that are intended for all
=C2=A0=C2=A0=C2=A0recipients on the chain ("end-to-end= "), enabling the message to be
=C2=A0=C2=A0=C2= =A0self-descriptive and allowing future connection-specific extensions
=C2=A0=C2=A0=C2=A0to be deployed without fear that they= will be blindly forwarded by
=C2=A0=C2=A0=C2=A0old= er intermediaries.

..it offh= and seems that one would want to list "Sec-Token-Binding" in the = Connection header field because Sec-Token-Binding is ostensibly about the c= onnection and is hop-by-hop because TLS is hop-by-hop.

However, given our current thinking wrt TB and T= LS Terminating Reverse Proxies [3], where we are contemplating one approach= where such "TTRPs"
pass-through the Sec-= Token-Binding header field and add a corresponding Token-Binding-Context he= ader, one would not want to list Sec-Token-Binding in the Connection header= (because a TTRP would then strip it off). However there are implementation= and security considerations with this.

As one proposal, we could say in HTTPSTB something along the li= nes of..

=C2=A0=C2=A0[...]<= br class=3D"gmail_msg"> =C2=A0=C2=A0Clients SHOULD NOT list the Sec-Token-B= inding header field as
=C2=A0=C2=A0a connection opt= ion in the Connection header field (Section 6.1
=C2= =A0=C2=A0of [RFC7230]) in order to generally enable Sec-Token-Binding
=C2=A0=C2=A0header field pass-through by intermediaries,= e.g., by TLS
=C2=A0=C2=A0terminating reverse proxi= es (TTRP). Intermediaries MUST NOT
=C2=A0=C2=A0modi= fy the Sec-Token-Binding header field's value. See also the
=C2=A0=C2=A0security considerations section.
=C2=A0=C2=A0[...]
=C2=A0=C2=A0Security Consi= derations
=C2=A0=C2=A0[...]
= =C2=A0=C2=A0Not listing Sec-Token-Binding in the Connection header: this =C2=A0=C2=A0enables TTRPs to transparently convey th= e Sec-Token-Binding header
=C2=A0=C2=A0field, conta= ining a Token Binding Message, to the next tier ("backend
=C2=A0=C2=A0servers"), e.g., where security tokens contain= ing Token Binding IDs
=C2=A0=C2=A0may be minted and= validated. The communication between a TTRP and
= =C2=A0=C2=A0backend servers needs to be secured against eavesdropping and =C2=A0=C2=A0modification by unintended parties. The = Token Binding Message itself
=C2=A0=C2=A0may be val= idated by the TTRP or by a backend server. Though, in the
=C2=A0=C2=A0latter case, the data necessary to perform such validati= on (i.e., the
=C2=A0=C2=A0EKM, etc.) needs to be co= nveyed to the entity performing it. Such
=C2=A0=C2= =A0conveyance is out of scope for this specification.

=C2=A0=C2=A0Listing Sec-Token-Binding in the Con= nection header: if done, this
=C2=A0=C2=A0may help = in ensuring that Token Binding IDs are not inadvertently
=C2=A0=C2=A0revealed to unintended parties, though may cause difficul= ties with
=C2=A0=C2=A0web sites employing TTRPs. =C2=A0=C2=A0[...]

Or, we could just say "clients SHOULD list the Sec-Token-B= inding header field as a connection option in the Connection header field&q= uot;, but that will create problems for TTRPs [3].
<= br class=3D"gmail_msg">Or, we can just not mention the Connection header an= d see if anyone raises questions about it during further WG and IETF-wide r= eview.

thoughts?

[1] <https:= //tools.ietf.org/html/rfc7231#section-8.3.1>
=
[2] <https://tools.ietf.o= rg/html/rfc7230#section-6.1>

[3] <https://tools.ietf.org/h= tml/draft-campbell-tokbind-tls-term>


___________________________________= ____________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable

__________________________________________= _____
Unbearable mailing list
Unbearable@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/unbearable
=

________= _______________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/lis= tinfo/unbearable
--001a11470b387f59fb0547fccdd9-- From nobody Wed Feb 8 06:44:11 2017 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 CD431129B6B for ; Wed, 8 Feb 2017 06:44:09 -0800 (PST) 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, HTML_MESSAGE=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=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 x9ylxnUExTdl for ; Wed, 8 Feb 2017 06:44:07 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 AE726129B7A for ; Wed, 8 Feb 2017 06:44:06 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id x49so166669546qtc.2 for ; Wed, 08 Feb 2017 06:44:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=C9L9mAKMbq+yNualnhmNLPgSio8o+j3CuyZ+HwqlZmI=; b=dtgN+G/lkHmXsWPxfAWl83osW8Y8zFFLQT4BoUd+S9Fyqbhul2HDe+eormLRz+6QpD puD8RA7lACu+kCSkkJjOKfjXakd/IZQ+S4WaXC2aontByaujymtGL2oFza5IWnW/JHuo iU+WZmLCcmLEaErxLLmoKYXxTudSK6+rYaSSm6VSQpWyZ+8NZtT/3yUFqjCzrQFfNfzP YnZghrSlYWJ65ELt69H1pmeAKxNwJHBIZGRmP6FRKxo1fTw72KiFvTQMO3wis7Hkvjlj yad/oGl5vLTq99/MkFyhycCP+9FpA6YQW8fGY9iHdDqporcGoqWb+16ilr4HHFK8EFIh 4wHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=C9L9mAKMbq+yNualnhmNLPgSio8o+j3CuyZ+HwqlZmI=; b=REQruOq6/efe6Os1xK4wg43YjxbAwIga3vqaW9aJqY6Gl0LesjISNoBMIeym9f/gcG unv8HokTZsfuP5ykSszLGaCYGOzW2DmW6M912wCzXQ5Q4Bm7LQzZUMvjE8JChup+y8lP nrCFtzEFYj7TLRnY361A2de3ZWrTzP7Ok0/tEYsRkGXMgd74OwK9I7bKyN76Qq7jFww+ cZTJupYzjZjYDZhbqe5EkZJ3DscQesvwyXrF0H0YNxhtU6tkvaj4XqFUGRrc8EaJdgF8 RuPTYwxjE5dDeDzdS+bDM2w6Te4MjI+ffyY/YIh2Bc8h+SMW3rswsDY8quTgAkzJp0hC jcZw== X-Gm-Message-State: AMke39nWEr1Z9Ns6Alhcw2dqcd8X8HNFbRJh/N//F9emF9E3yfJEUHVsPBPaEooJ3Fh6RJXR X-Received: by 10.237.61.20 with SMTP id g20mr21775245qtf.272.1486565045494; Wed, 08 Feb 2017 06:44:05 -0800 (PST) Received: from [192.168.8.100] ([181.201.86.53]) by smtp.gmail.com with ESMTPSA id d52sm6361175qtc.2.2017.02.08.06.44.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 06:44:04 -0800 (PST) From: John Bradley Message-Id: <43DD0CF0-4043-448D-BE38-FAFFDE779B57@ve7jtb.com> Content-Type: multipart/signed; boundary="Apple-Mail=_4744FFE4-2DC7-4809-8682-E0DE72E43CF8"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 8 Feb 2017 11:44:00 -0300 In-Reply-To: To: Dirk Balfanz References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Andrei Popov , IETF TokBind WG , =JeffH Hodges Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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, 08 Feb 2017 14:44:10 -0000 --Apple-Mail=_4744FFE4-2DC7-4809-8682-E0DE72E43CF8 Content-Type: multipart/alternative; boundary="Apple-Mail=_9DCF0215-2DA2-42A6-B2A3-D469165B583F" --Apple-Mail=_9DCF0215-2DA2-42A6-B2A3-D469165B583F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I suspect the only place we really run into a conflict is in Brian's = draft by re using/maintaining the Sec-Token-Binding header. As Dirk points out that draft could move the info in the = Sec-Token-Binding header to a different header if it is listed in the = Connect header, or always just use a different header name. That can be debated as part of the reverse proxy spec. I am not really getting the sense that we need to mention the connect = header if we are happy with the default behaviour and can account for it = in specs using token binding. What do people think we should do to close this? John B. > On Feb 8, 2017, at 12:52 AM, Dirk Balfanz wrote: >=20 > I don't feel strongly about this - I'm fine either way, but would = suggest the following: >=20 > - The Connect header is for the client to tell a proxy "this header = really doesn't make sense to forward, please drop it on the next hop". > - Clients usually aren't aware that they're talking to a TTRP, so I = agree with John that that's probably not a use case that the Connect = header was meant for. > - If the client *is* aware that it's talking to a proxy, listing = Sec-Token-Binding in the Connect header (thus indicating that it = shouldn't be forwarded) makes sense to me. > - If the proxy has some sort of arrangement with the downstream server = that it's supposed to communicate the Token Binding information (like a = TTRP would), it has a two options: > * verify the Token Binding information and forward just the Token = Binding ID to the downstream server (using some mechanism proprietary to = the proxy and downstream server). > * forward the Sec-Token-Binding header, and (using some mechanism = proprietary to the proxy and downstream server) the EKM information, to = the downstream server. > If the proxy has qualms about violating the spec by forwarding the = Sec-Token-Binding header despite its being listed in the Connect header, = it can always just use a different header name, like = "Private-Forwarded-Token-Binding", or whatever - some mechanism = proprietary to the proxy and downstream server. > - Either way, the proxy will have to know what the Sec-Token-Binding = header means and use some sort of proprietary mechanism between itself = and the downstream server to pass on the information that the downstream = server needs. > - For a proxy that *doesn't* know what the Sec-Token-Binding header = means, it's probably best to just drop it, thus saving the downstream = server some work verifying a header that we know won't verify. >=20 > So to me it seems that listing it in the Connect header is the right = answer, but like I said I don't feel strongly about it. >=20 > Dirk. >=20 >=20 > On Tue, Feb 7, 2017 at 2:56 PM John Bradley > wrote: > Are connection headers normally used in the reverse proxy use case? = Generally the user agent wouldn't know that it was talking to a proxy. >=20 > I thought that they were more for the forward proxy use case where the = browser is configured to talk to a specific proxy or is transparently = intercepted (man/enterprise in the middle)=20 >=20 > I could hypothetically see a enterprise proxy creating token binding = Id=E2=80=99s for the connections to servers and mapping those to token = binding ID from the browser.=20 >=20 > I think the NGNX token binding module = (https://github.com/google/ngx_token_binding = ) is doing that sort of = transparent mapping on the server side for session cookies.=20 >=20 > We probably don't want the same behaviour for both forward and reverse = proxies. >=20 > John B. >=20 >=20 >> On Feb 7, 2017, at 7:38 PM, Andrei Popov > wrote: >>=20 >> When we discussed this early on, there was a strong distaste for = connection headers in the HTTP community, so we've defined TB headers as = per-request. >> " clients MUST include the Sec-Token- >> Binding header field in their HTTP requests." >> We could also explicitly prohibit listing TB headers in the = Connection header, if folks would like to see this clarification.=20 >> There are many reasons to keep TB headers per-request; it's not just = about the proxies and terminators. >>=20 >> Cheers, >>=20 >> Andrei >>=20 >> -----Original Message----- >> From: Unbearable [mailto:unbearable-bounces@ietf.org = ] On Behalf Of =3DJeffH >> Sent: Tuesday, February 7, 2017 2:15 PM >> To: IETF TokBind WG > >> Subject: [Unbearable] on not listing 'Sec-Token-Binding' in the = Connection header field? >>=20 >> the below is kind of long (read it anyway :) The summary is we need = to make a conscious decision regarding the Connection HTTP request = header field and whether we provide guidance regarding it and the = Sec-Token-Binding header (and what guidance if so), or not. This seems = to have ramifications for the nascent draft-campbell-tokbind-tls-term = draft, unless I'm misunderstanding things. >>=20 >> =3DJeffH >>=20 >> In working through the list of "Considerations for New Header Fields" = at the end of rfc7231 section 8.3.1 [1], there are these two items.. >>=20 >> o Whether it is appropriate to list the field-name in the = Connection >> header field (i.e., if the header field is to be hop-by-hop; = see >> Section 6.1 of [RFC7230]). >>=20 >> o Under what conditions intermediaries are allowed to insert, >> delete, or modify the field's value. >>=20 >> Given the specifics in [RFC7230] Section 6.1 [2].. >>=20 >> 6.1. Connection >>=20 >> The "Connection" header field allows the sender to indicate = desired >> control options for the current connection. In order to avoid >> confusing downstream recipients, a proxy or gateway MUST remove or >> replace any received connection options before forwarding the >> message. >>=20 >> When a header field aside from Connection is used to supply = control >> information for or about the current connection, the sender MUST = list >> the corresponding field-name within the Connection header field. = A >> proxy or gateway MUST parse a received Connection header field = before >> a message is forwarded and, for each connection-option in this = field, >> remove any header field(s) from the message with the same name as = the >> connection-option, and then remove the Connection header field = itself >> (or replace it with the intermediary's own connection options for = the >> forwarded message). >>=20 >> Hence, the Connection header field provides a declarative way of >> distinguishing header fields that are only intended for the = immediate >> recipient ("hop-by-hop") from those fields that are intended for = all >> recipients on the chain ("end-to-end"), enabling the message to be >> self-descriptive and allowing future connection-specific = extensions >> to be deployed without fear that they will be blindly forwarded by >> older intermediaries. >>=20 >> ..it offhand seems that one would want to list "Sec-Token-Binding" in = the Connection header field because Sec-Token-Binding is ostensibly = about the connection and is hop-by-hop because TLS is hop-by-hop. >>=20 >> However, given our current thinking wrt TB and TLS Terminating = Reverse Proxies [3], where we are contemplating one approach where such = "TTRPs"=20 >> pass-through the Sec-Token-Binding header field and add a = corresponding Token-Binding-Context header, one would not want to list = Sec-Token-Binding in the Connection header (because a TTRP would then = strip it off). However there are implementation and security = considerations with this. >>=20 >> As one proposal, we could say in HTTPSTB something along the lines = of.. >>=20 >> [...] >> Clients SHOULD NOT list the Sec-Token-Binding header field as >> a connection option in the Connection header field (Section 6.1 >> of [RFC7230]) in order to generally enable Sec-Token-Binding >> header field pass-through by intermediaries, e.g., by TLS >> terminating reverse proxies (TTRP). Intermediaries MUST NOT >> modify the Sec-Token-Binding header field's value. See also the >> security considerations section. >> [...] >> Security Considerations >> [...] >> Not listing Sec-Token-Binding in the Connection header: this >> enables TTRPs to transparently convey the Sec-Token-Binding header >> field, containing a Token Binding Message, to the next tier = ("backend >> servers"), e.g., where security tokens containing Token Binding IDs >> may be minted and validated. The communication between a TTRP and >> backend servers needs to be secured against eavesdropping and >> modification by unintended parties. The Token Binding Message = itself >> may be validated by the TTRP or by a backend server. Though, in the >> latter case, the data necessary to perform such validation (i.e., = the >> EKM, etc.) needs to be conveyed to the entity performing it. Such >> conveyance is out of scope for this specification. >>=20 >> Listing Sec-Token-Binding in the Connection header: if done, this >> may help in ensuring that Token Binding IDs are not inadvertently >> revealed to unintended parties, though may cause difficulties with >> web sites employing TTRPs. >> [...] >>=20 >> Or, we could just say "clients SHOULD list the Sec-Token-Binding = header field as a connection option in the Connection header field", but = that will create problems for TTRPs [3]. >>=20 >> Or, we can just not mention the Connection header and see if anyone = raises questions about it during further WG and IETF-wide review. >>=20 >> thoughts? >>=20 >> [1] > >>=20 >> [2] > >>=20 >> [3] > >>=20 >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable = >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable = >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable = --Apple-Mail=_9DCF0215-2DA2-42A6-B2A3-D469165B583F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I suspect the only place we really run into a conflict is in = Brian's draft by re using/maintaining the Sec-Token-Binding header.

As Dirk points out that = draft could move the info in the Sec-Token-Binding header to a different = header if it is listed in the Connect header, or always just use a = different header name.

That can be debated as part of the reverse proxy = spec.

I am not = really getting the sense that we need to mention the connect header if = we are happy with the default behaviour and can account for it in specs = using token binding.

What do people think we should do to close this?

John B.


On = Feb 8, 2017, at 12:52 AM, Dirk Balfanz <balfanz@google.com> = wrote:

I don't feel strongly about this - I'm fine = either way, but would suggest the following:

- The Connect header is for the client = to tell a proxy "this header really doesn't make sense to forward, = please drop it on the next hop".
- Clients usually = aren't aware that they're talking to a TTRP, so I agree with John that = that's probably not a use case that the Connect header was meant = for.
- If the client *is* aware that it's talking = to a proxy, listing Sec-Token-Binding in the Connect header (thus = indicating that it shouldn't be forwarded) makes sense to me.
- If the proxy has some sort of arrangement with the = downstream server that it's supposed to communicate the Token Binding = information (like a TTRP would), it has a two options:
  * verify the Token Binding information and forward = just the Token Binding ID to the downstream server (using some mechanism = proprietary to the proxy and downstream server).
  * forward the Sec-Token-Binding header, and (using = some mechanism proprietary to the proxy and downstream server) the EKM = information, to the downstream server.
If the proxy = has qualms about violating the spec by forwarding the Sec-Token-Binding = header despite its being listed in the Connect header, it can always = just use a different header name, like = "Private-Forwarded-Token-Binding", or whatever - some  mechanism = proprietary to the proxy and downstream server.
- = Either way, the proxy will have to know what the Sec-Token-Binding = header means and use some sort of proprietary mechanism between itself = and the downstream server to pass on the information that the downstream = server needs.
- For a proxy that *doesn't* know = what the Sec-Token-Binding header means, it's probably best to just drop = it, thus saving the downstream server some work verifying a header that = we know won't verify.

So to me it seems that listing it in the Connect header is = the right answer, but like I said I don't feel strongly about = it.

Dirk.


On = Tue, Feb 7, 2017 at 2:56 PM John Bradley <ve7jtb@ve7jtb.com> = wrote:
Are connection headers normally used in the reverse = proxy use case?   Generally the user agent wouldn't know that it = was talking to a proxy.

I thought that they = were more for the forward proxy use case where the browser is configured = to talk to a specific proxy or is transparently intercepted = (man/enterprise in the middle) 

I could = hypothetically see a enterprise proxy creating token binding Id=E2=80=99s = for the connections to servers and mapping those to token binding ID = from the browser. 

I think the NGNX = token binding module (https://github.com/google/ngx_token_binding) is= doing that sort of transparent mapping on the server side for session = cookies. 

We probably don't = want the same behaviour for both forward and reverse proxies.

John B.


On Feb 7, 2017, at 7:38 PM, = Andrei Popov <Andrei.Popov@microsoft.com> = wrote:

When we = discussed this early on, there was a strong distaste for connection = headers in the HTTP community, so we've defined TB headers as = per-request.
" clients MUST include the = Sec-Token-
  Binding header field in = their HTTP requests."
We could also explicitly = prohibit listing TB headers in the Connection header, if folks would = like to see this clarification.
There are many = reasons to keep TB headers per-request; it's not just about the proxies = and terminators.

Cheers,
Andrei

-----Original = Message-----
From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of = =3DJeffH
Sent: Tuesday, February 7, 2017 2:15 = PM
To: IETF TokBind WG <unbearable@ietf.org>
Subject: [Unbearable] on not listing = 'Sec-Token-Binding' in the Connection header field?

the below is kind of long = (read it anyway :)  The summary is we need to make a conscious = decision regarding the Connection HTTP request header field and whether = we provide guidance regarding it and the Sec-Token-Binding header (and = what guidance if so), or not. This seems to have ramifications for the = nascent draft-campbell-tokbind-tls-term draft, unless I'm = misunderstanding things.

=3DJeffH

In working through the list of "Considerations for = New Header Fields" at the end of rfc7231 section 8.3.1 [1], there are = these two items..

=    o  Whether it is appropriate to list the = field-name in the Connection
=       header field (i.e., if the header = field is to be hop-by-hop; see
=       Section 6.1 of [RFC7230]).

   o =  Under what conditions intermediaries are allowed to insert,
      delete, or = modify the field's value.

Given the specifics in [RFC7230] Section 6.1 = [2]..

=   6.1.  Connection

   The "Connection" header field = allows the sender to indicate desired
=    control options for the current connection.  In = order to avoid
   confusing = downstream recipients, a proxy or gateway MUST remove or
   replace any received connection = options before forwarding the
=    message.

=    When a header field aside from Connection is used to = supply control
   information for = or about the current connection, the sender MUST list
   the corresponding field-name = within the Connection header field.  A
=    proxy or gateway MUST parse a received Connection = header field before
   a message = is forwarded and, for each connection-option in this field,
   remove any header field(s) from = the message with the same name as the
=    connection-option, and then remove the Connection = header field itself
   (or = replace it with the intermediary's own connection options for the
   forwarded message).

   Hence, = the Connection header field provides a declarative way of
   distinguishing header fields that = are only intended for the immediate
=    recipient ("hop-by-hop") from those fields that are = intended for all
   recipients on = the chain ("end-to-end"), enabling the message to be
   self-descriptive and allowing = future connection-specific extensions
=    to be deployed without fear that they will be blindly = forwarded by
   older = intermediaries.

..it = offhand seems that one would want to list "Sec-Token-Binding" in the = Connection header field because Sec-Token-Binding is ostensibly about = the connection and is hop-by-hop because TLS is hop-by-hop.

However, given our current = thinking wrt TB and TLS Terminating Reverse Proxies [3], where we are = contemplating one approach where such "TTRPs"
pass-through the Sec-Token-Binding header field and = add a corresponding Token-Binding-Context header, one would not want to = list Sec-Token-Binding in the Connection header (because a TTRP would = then strip it off). However there are implementation and security = considerations with this.

As one proposal, we could say in HTTPSTB something = along the lines of..

=   [...]
  Clients SHOULD NOT = list the Sec-Token-Binding header field as
=   a connection option in the Connection header field (Section = 6.1
  of [RFC7230]) in order to = generally enable Sec-Token-Binding
=   header field pass-through by intermediaries, e.g., by TLS
  terminating reverse proxies (TTRP). = Intermediaries MUST NOT
  modify the = Sec-Token-Binding header field's value. See also the
  security considerations section.
  [...]
=   Security Considerations
=   [...]
  Not listing = Sec-Token-Binding in the Connection header: this
=   enables TTRPs to transparently convey the Sec-Token-Binding = header
  field, containing a Token = Binding Message, to the next tier ("backend
=   servers"), e.g., where security tokens containing Token = Binding IDs
  may be minted and = validated. The communication between a TTRP and
=   backend servers needs to be secured against eavesdropping = and
  modification by unintended = parties. The Token Binding Message itself
=   may be validated by the TTRP or by a backend server. Though, = in the
  latter case, the data = necessary to perform such validation (i.e., the
=   EKM, etc.) needs to be conveyed to the entity performing it. = Such
  conveyance is out of scope for = this specification.

=   Listing Sec-Token-Binding in the Connection header: if done, = this
  may help in ensuring that Token = Binding IDs are not inadvertently
=   revealed to unintended parties, though may cause = difficulties with
  web sites = employing TTRPs.
  [...]

Or, we could just say = "clients SHOULD list the Sec-Token-Binding header field as a connection = option in the Connection header field", but that will create problems = for TTRPs [3].

Or, we can = just not mention the Connection header and see if anyone raises = questions about it during further WG and IETF-wide review.

thoughts?

[1] <https://tools.ietf.org/html/rfc7231#section-8.3.1>= ;

[2] <https://tools.ietf.org/html/rfc7230#section-6.1><= br class=3D"gmail_msg">
[3] <https://tools.ietf.org/html/draft-campbell-tokbind-tls-t= erm>


_______________________________________________
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

__________________________________________= _____
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable

= --Apple-Mail=_9DCF0215-2DA2-42A6-B2A3-D469165B583F-- --Apple-Mail=_4744FFE4-2DC7-4809-8682-E0DE72E43CF8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILMTCCBUcw ggQvoAMCAQICEEAfBHP+tuqufC4R+F+Tu54wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAyIENsaWVudCBDQTAeFw0xNjA4MTIy MTE5NDFaFw0xODA4MTIyMTE5NDFaMIGCMQswCQYDVQQGEwJDTDEiMCAGA1UECAwZTWV0cm9wb2xp dGFuYSBkZSBTYW50aWFnbzEWMBQGA1UEBwwNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAwwMSm9obiBC cmFkbGV5MSAwHgYJKoZIhvcNAQkBFhF2ZTdqdGJAdmU3anRiLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALhTcSiDGvVrm4hlJA8WyFcWWe0dqnuJzstQYTaF281JFOEPA/13kQYI JMXAEUcS7NvW7KdUI0tHU0N6RTo0Ilf1E1nm8No++eqHO8pFUZ/cidpv0r+1Qcl9EgrpbZ00Y7Xg pq06EZELzJAmds4QQcsTKdpLNFbVcFnM11i2Gj5VNsYgO+qPO2AS8rLHkgDWnNkc9/lA+ZK5wGiU zxPU9KnIrERoTif3Zk7KjLvFpBWYD60M/lNoHZ5zxYgmYLmvoM1TSLn4Ms57wwT5MieV2l0aqlGC 7CKNa6XyeL1B0y0wSxL3PJQS4vSLDnttZC7od2A6yjeUMyM3rQ41vqUIMc8CAwEAAaOCAcMwggG/ MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUmA9bUmBmTYkCcZ3yYv8IRRP2nN4wHwYDVR0jBBgwFoAUmZerGDU6i1lFQ5iy cnHI9PsJzxYwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNz bC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGll bnQyLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xp ZW50Mi5jcmwwHAYDVR0RBBUwE4ERdmU3anRiQHZlN2p0Yi5jb20wIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMFUGA1UdIAROMEwwDAYKKwYBBAGBtTcGATA8BgsrBgEEAYG1NwEC BTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4IBAQBqcYJfFA/ITkX4L6JihqW168Wog1BOfkbPXO+wPn5G9P1NwruGfu41b70EPPwV vol+/j+qhSSrDjFyfNBsq4G45GRR6hwx0ei/bH0UW15Y63ASYPkNlj3ydCcvhw5ItWD5aYPphBx9 C7tLnQ7ow09cqt2CIgPd3W/IGri7p4hWPbdcX0oFIhJcDxmCwTcWyoVoIo4aas5gP44LPGneCoqI lXQMJinwneEnKd7rWXlzVWv7geaH3t79zARSw9ev9F4E61cDuHi+vgTFEpio7oxybqfj99yLibhX uZjReYnYbDMRiWDXduVIrIGYwmnUuD8a0b20kJgHm+FEgB6UMa9JMIIF4jCCA8qgAwIBAgIQXLZI bkcMmMZ/9oDbZErijTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1 WhcNMzAxMjE2MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDIgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7g9Q jJUJI4Ss9VBqj9Y3ok4h/TIJZUc+rzj61Rv3hNB/yeEEC1fz3i/EU+MXOOGxM7KCbtCIcJxHIW/k 8RP6sPPMO4cTg7sNzfBWsYsemtY6fN/kVr2R2X+/PjvtxmAaXpGX0znvQPxaE123IMGXy0zEKHZ/ nJDZ199TP9TNn9v+1QO0AZb4oaJ7ch0DpSJa8kF5xiNFDAg9taKKSrVuPHJL9MFFYPIqwShjHg+u YEzjfxbMP2QWwamnaA9Y7fORSDNapduFlARAcDtXdMpAijiG4HKnrN323I0Ka7lDTAWyLtTDCETK sI8fzOyL0inEu1WEVpdPytm8s1rwQB4f9QIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQr MCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRa MFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBSZl6sYNTqLWUVDmLJy ccj0+wnPFjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUd IAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4ICAQCZQUEEzvYk9U4wNHhDu1f9QGwbzAH4m4wIKH8ZidNYwZhyoNKW041iJ002KMW9 ywYM95n4770tT45yH29vTMlZtBvz0h44KuxMLNXRCTDwvV07sT39nPjFi5MpwZaLVueNiaa1vok1 n2Wn8lLcyCltYZNGAEifM0ko/A/vvckftFIZG75RAiZHYtfnrdBGiOxyF+nHI9a33BRX5Vl/3z0+ uHZ/Y6YPbNJ7iboOFrFZBCtt+lp3WaDB62ZoBewiMmd09JrqmMJAEgw3EbfQNtaPzHPg/EOhlZik Rgd4BCrzrbIqB2RKib+gnQJt2uoJaKOaV90S9Xgs3PC837OE9CEmY6/MTTG0xpbLh2hR/rLQ3sCr H56aODeuDrQBq85lXxRbDCERDUR7FZUhHv+i1aQaY59NPu26hDd6nqksSDq2mCddpidPBuGJz9lN X2nRyGkudDuWV6gIr6AZfaYv+ggTXOcCDJZFzMhWdLC7CPvRKxQ7vTiYV+4lgqOvV9MnZc149PPt itTysq/oOv70zx7q+tyaLTa4cqFhCclhIwSwOEJiV3xqQebvmwsDX7BaXGAJZIhbdUbNr3poEgct 6uAxw2zyr69WCJmTUUhz/k1/TT/eCUZJqnMg/6mje7tiVdaUQJcBtJ6cq5+mUDNUB1fohW8EOFai zFpP/0FaP62ctTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMiBDbGllbnQgQ0ECEEAfBHP+tuqufC4R+F+Tu54wCQYFKw4DAhoF AKCCAZkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjA4MTQ0 NDAxWjAjBgkqhkiG9w0BCQQxFgQUSZ594q9G/34n/kejnRLl7eaxlXcwgZoGCSsGAQQBgjcQBDGB jDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIg Q2xpZW50IENBAhBAHwRz/rbqrnwuEfhfk7ueMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIgQ2xpZW50IENBAhBA HwRz/rbqrnwuEfhfk7ueMA0GCSqGSIb3DQEBAQUABIIBAFVOyCFXzh0mpIf1UemfuQbm8AM1Isd+ UX7WY/Si6Ocm1C/+2vRHQ48AJhOkq7NN+dHXzoo9f9STtzOru+hRFjoQgqZff0608gxKk1JlQhUr jHdXrRaibxNd9Liy59m7BhQ8XvJnM/cfHBycjQp5jx7ludY+CulggW7wW3C2V0AWqPyxJgQ3JQGs IsCeVvHergV3dG2F1OOnnk2igiMsivuLffECkc53wcxRxQkeDbzh4w9gp2NyIgqZSkVIx7u8TmEb es9wmDn4Rry+DSCHOyn1aLcax0Crqw9LDi1dVYOeQKNtjs2TUG7+Nt1HuK5v7pWOtTAJs7T7/uB7 TpTSmpkAAAAAAAA= --Apple-Mail=_4744FFE4-2DC7-4809-8682-E0DE72E43CF8-- From nobody Wed Feb 8 09:20:59 2017 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 4DFBE129C98 for ; Wed, 8 Feb 2017 09:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 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=-1.887, 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 UmLqz8iJ8SZt for ; Wed, 8 Feb 2017 09:20:54 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0099.outbound.protection.outlook.com [104.47.37.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2D7E1293DA for ; Wed, 8 Feb 2017 09:20:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JIj7JtuGzkjyUZhE5k2aRdw6JBoo/iLwBy53LfVWKCU=; b=U07jLDjU+ld+lzDRkKILuRJ6l8dXHldsPqWSX3X5JAER6iRCAUgwD5k67GKiIiG7U2AS01r3PMwFnN87pLdN+kYAom3WKoQZWnCjUoluHRaCJwadbbqjXwwLFfw7oU/H/hC2meMFfH/iGIC7cCCG4gMzQGH0m6SJzY8ceh2n6Ao= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0843.namprd03.prod.outlook.com (10.160.163.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 8 Feb 2017 17:20:51 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.026; Wed, 8 Feb 2017 17:20:51 +0000 From: Andrei Popov To: John Bradley , Dirk Balfanz Thread-Topic: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? Thread-Index: AQHSgZVjoAIXC6BWu0OMPbiyGCJ7xqFeen4AgAC16ACAACoXcA== Date: Wed, 8 Feb 2017 17:20:51 +0000 Message-ID: References: <43DD0CF0-4043-448D-BE38-FAFFDE779B57@ve7jtb.com> In-Reply-To: <43DD0CF0-4043-448D-BE38-FAFFDE779B57@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: 759fb06f-5410-4ea9-3d69-08d45046d50b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0843; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0843; 7:FOh7Mb95hrSbB0bvq9kl34asY1rKoeMU99k+PuK3EH9hxqs8sEiKxcYHRhM5fJLi3NIIRYR5aJEGzJzo9PChI9/ZSv7nuw+wENgAAsty/TtOOxyhItsFa3Uplb3z0fjL63I+hG88Zxc0Slk7qCps+8Rjfo5STPqd8ADcFEEMYWU1bbyDTSgmcZdtLU6KJMQ1Qo8VH3DdXXwxHO3ld71NlXp5RciFSTJwMWUZrDqlvPo7s05b5wVKulioxymkLPrwsOUnfsjdiqAWl9nryUUqabuEfudPdQGjtL6mFY6TOBJdjvMQMVBk7bwPfQLoqgWhKTkk1uPJDRE9qXksLGS2CBXJ72+dGA0r7HuM//jV9CsinmwMFgH1tj1YpnR0T1Sy+VZY0tW1kxd2ZNCLLizsoETldoCL3tricLzEy0erxpZSIyKJanQzjOOVeXW8rEWRbNLb4q89/hr1gvpekH7XHy2huvXSRugqhfOrMZ5m9FDhOzFi6N1FcB6cAVDg1t3vnDreU39GDGb3HQO5SDMvV0QSjDDjARi+8QFu62qZhBA= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(192374486261705)(788757137089)(211936372134217)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(2017020702029)(20170203043)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(20161123560025)(6072148); SRVR:CY1PR0301MB0843; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0843; x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39860400002)(39450400003)(39850400002)(39410400002)(377454003)(24454002)(13464003)(189002)(199003)(33656002)(92566002)(68736007)(54896002)(55016002)(236005)(54906002)(93886004)(561944003)(6306002)(230783001)(9686003)(99286003)(101416001)(5005710100001)(7696004)(5660300001)(122556002)(8990500004)(2950100002)(10290500002)(86362001)(38730400002)(7736002)(7906003)(189998001)(53936002)(6246003)(74316002)(106356001)(50986999)(54356999)(105586002)(790700001)(2906002)(6506006)(606005)(97736004)(6436002)(81156014)(3280700002)(3660700001)(10090500001)(6116002)(8676002)(229853002)(81166006)(25786008)(8936002)(77096006)(102836003)(4326007)(76176999)(2900100001)(106116001)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0843; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB08423324E89771A0EEDD72068C420CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2017 17:20:51.6107 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0843 Archived-At: Cc: IETF TokBind WG , =JeffH Hodges Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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, 08 Feb 2017 17:20:57 -0000 --_000_CY1PR0301MB08423324E89771A0EEDD72068C420CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIFRoZSBDb25uZWN0IGhlYWRlciBpcyBmb3IgdGhlIGNsaWVudCB0byB0ZWxsIGEgcHJveHkg InRoaXMgaGVhZGVyIHJlYWxseSBkb2Vzbid0IG1ha2Ugc2Vuc2UgdG8gZm9yd2FyZCwgcGxlYXNl IGRyb3AgaXQgb24gdGhlIG5leHQgaG9wIi4NCuKApmJ1dCBpbiB0aGUgY2FzZSBvZiB0aGUgU2Vj LVRva2VuLUJpbmRpbmcgaGVhZGVyLCB0aGUgY2xpZW50IGRvZXMgbm90IGtub3cgd2hldGhlciBp dCBtYWtlcyBzZW5zZSB0byBmb3J3YXJkIG9yIG5vdC4NClRoZSBjbGllbnQsIGdlbmVyYWxseSwg ZG9lcyBub3Qga25vdyB3aGV0aGVyIHRoZSBwcm94eSBvciBUTFMgdGVybWluYXRvciB2YWxpZGF0 ZXMgYmluZGluZ3MsIHBhc3NlcyB0aGVtIGFsb25nIGZvciB0aGUgYXBwbGljYXRpb24gc2VydmVy IHRvIHZhbGlkYXRlLCBvciBzdHJpcHMgdGhlbSBhbHRvZ2V0aGVyLg0KDQoNCsOYICBJIGFtIG5v dCByZWFsbHkgZ2V0dGluZyB0aGUgc2Vuc2UgdGhhdCB3ZSBuZWVkIHRvIG1lbnRpb24gdGhlIGNv bm5lY3QgaGVhZGVyIGlmIHdlIGFyZSBoYXBweSB3aXRoIHRoZSBkZWZhdWx0IGJlaGF2aW91ciBh bmQgY2FuIGFjY291bnQgZm9yIGl0IGluIHNwZWNzIHVzaW5nIHRva2VuIGJpbmRpbmcuDQpUaGlz IHNvdW5kcyByZWFzb25hYmxlIHRvIG1lLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBK b2huIEJyYWRsZXkgW21haWx0bzp2ZTdqdGJAdmU3anRiLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwg RmVicnVhcnkgOCwgMjAxNyA2OjQ0IEFNDQpUbzogRGlyayBCYWxmYW56IDxiYWxmYW56QGdvb2ds ZS5jb20+DQpDYzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT47IElF VEYgVG9rQmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz47ID1KZWZmSCBIb2RnZXMgPEplZmYu SG9kZ2VzQGtpbmdzbW91bnRhaW4uY29tPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBvbiBu b3QgbGlzdGluZyAnU2VjLVRva2VuLUJpbmRpbmcnIGluIHRoZSBDb25uZWN0aW9uIGhlYWRlciBm aWVsZD8NCg0KSSBzdXNwZWN0IHRoZSBvbmx5IHBsYWNlIHdlIHJlYWxseSBydW4gaW50byBhIGNv bmZsaWN0IGlzIGluIEJyaWFuJ3MgZHJhZnQgYnkgcmUgdXNpbmcvbWFpbnRhaW5pbmcgdGhlIFNl Yy1Ub2tlbi1CaW5kaW5nIGhlYWRlci4NCg0KQXMgRGlyayBwb2ludHMgb3V0IHRoYXQgZHJhZnQg Y291bGQgbW92ZSB0aGUgaW5mbyBpbiB0aGUgU2VjLVRva2VuLUJpbmRpbmcgaGVhZGVyIHRvIGEg ZGlmZmVyZW50IGhlYWRlciBpZiBpdCBpcyBsaXN0ZWQgaW4gdGhlIENvbm5lY3QgaGVhZGVyLCBv ciBhbHdheXMganVzdCB1c2UgYSBkaWZmZXJlbnQgaGVhZGVyIG5hbWUuDQoNClRoYXQgY2FuIGJl IGRlYmF0ZWQgYXMgcGFydCBvZiB0aGUgcmV2ZXJzZSBwcm94eSBzcGVjLg0KDQpJIGFtIG5vdCBy ZWFsbHkgZ2V0dGluZyB0aGUgc2Vuc2UgdGhhdCB3ZSBuZWVkIHRvIG1lbnRpb24gdGhlIGNvbm5l Y3QgaGVhZGVyIGlmIHdlIGFyZSBoYXBweSB3aXRoIHRoZSBkZWZhdWx0IGJlaGF2aW91ciBhbmQg Y2FuIGFjY291bnQgZm9yIGl0IGluIHNwZWNzIHVzaW5nIHRva2VuIGJpbmRpbmcuDQoNCldoYXQg ZG8gcGVvcGxlIHRoaW5rIHdlIHNob3VsZCBkbyB0byBjbG9zZSB0aGlzPw0KDQpKb2huIEIuDQoN Cg0KT24gRmViIDgsIDIwMTcsIGF0IDEyOjUyIEFNLCBEaXJrIEJhbGZhbnogPGJhbGZhbnpAZ29v Z2xlLmNvbTxtYWlsdG86YmFsZmFuekBnb29nbGUuY29tPj4gd3JvdGU6DQoNCkkgZG9uJ3QgZmVl bCBzdHJvbmdseSBhYm91dCB0aGlzIC0gSSdtIGZpbmUgZWl0aGVyIHdheSwgYnV0IHdvdWxkIHN1 Z2dlc3QgdGhlIGZvbGxvd2luZzoNCg0KLSBUaGUgQ29ubmVjdCBoZWFkZXIgaXMgZm9yIHRoZSBj bGllbnQgdG8gdGVsbCBhIHByb3h5ICJ0aGlzIGhlYWRlciByZWFsbHkgZG9lc24ndCBtYWtlIHNl bnNlIHRvIGZvcndhcmQsIHBsZWFzZSBkcm9wIGl0IG9uIHRoZSBuZXh0IGhvcCIuDQotIENsaWVu dHMgdXN1YWxseSBhcmVuJ3QgYXdhcmUgdGhhdCB0aGV5J3JlIHRhbGtpbmcgdG8gYSBUVFJQLCBz byBJIGFncmVlIHdpdGggSm9obiB0aGF0IHRoYXQncyBwcm9iYWJseSBub3QgYSB1c2UgY2FzZSB0 aGF0IHRoZSBDb25uZWN0IGhlYWRlciB3YXMgbWVhbnQgZm9yLg0KLSBJZiB0aGUgY2xpZW50ICpp cyogYXdhcmUgdGhhdCBpdCdzIHRhbGtpbmcgdG8gYSBwcm94eSwgbGlzdGluZyBTZWMtVG9rZW4t QmluZGluZyBpbiB0aGUgQ29ubmVjdCBoZWFkZXIgKHRodXMgaW5kaWNhdGluZyB0aGF0IGl0IHNo b3VsZG4ndCBiZSBmb3J3YXJkZWQpIG1ha2VzIHNlbnNlIHRvIG1lLg0KLSBJZiB0aGUgcHJveHkg aGFzIHNvbWUgc29ydCBvZiBhcnJhbmdlbWVudCB3aXRoIHRoZSBkb3duc3RyZWFtIHNlcnZlciB0 aGF0IGl0J3Mgc3VwcG9zZWQgdG8gY29tbXVuaWNhdGUgdGhlIFRva2VuIEJpbmRpbmcgaW5mb3Jt YXRpb24gKGxpa2UgYSBUVFJQIHdvdWxkKSwgaXQgaGFzIGEgdHdvIG9wdGlvbnM6DQogICogdmVy aWZ5IHRoZSBUb2tlbiBCaW5kaW5nIGluZm9ybWF0aW9uIGFuZCBmb3J3YXJkIGp1c3QgdGhlIFRv a2VuIEJpbmRpbmcgSUQgdG8gdGhlIGRvd25zdHJlYW0gc2VydmVyICh1c2luZyBzb21lIG1lY2hh bmlzbSBwcm9wcmlldGFyeSB0byB0aGUgcHJveHkgYW5kIGRvd25zdHJlYW0gc2VydmVyKS4NCiAg KiBmb3J3YXJkIHRoZSBTZWMtVG9rZW4tQmluZGluZyBoZWFkZXIsIGFuZCAodXNpbmcgc29tZSBt ZWNoYW5pc20gcHJvcHJpZXRhcnkgdG8gdGhlIHByb3h5IGFuZCBkb3duc3RyZWFtIHNlcnZlcikg dGhlIEVLTSBpbmZvcm1hdGlvbiwgdG8gdGhlIGRvd25zdHJlYW0gc2VydmVyLg0KSWYgdGhlIHBy b3h5IGhhcyBxdWFsbXMgYWJvdXQgdmlvbGF0aW5nIHRoZSBzcGVjIGJ5IGZvcndhcmRpbmcgdGhl IFNlYy1Ub2tlbi1CaW5kaW5nIGhlYWRlciBkZXNwaXRlIGl0cyBiZWluZyBsaXN0ZWQgaW4gdGhl IENvbm5lY3QgaGVhZGVyLCBpdCBjYW4gYWx3YXlzIGp1c3QgdXNlIGEgZGlmZmVyZW50IGhlYWRl ciBuYW1lLCBsaWtlICJQcml2YXRlLUZvcndhcmRlZC1Ub2tlbi1CaW5kaW5nIiwgb3Igd2hhdGV2 ZXIgLSBzb21lICBtZWNoYW5pc20gcHJvcHJpZXRhcnkgdG8gdGhlIHByb3h5IGFuZCBkb3duc3Ry ZWFtIHNlcnZlci4NCi0gRWl0aGVyIHdheSwgdGhlIHByb3h5IHdpbGwgaGF2ZSB0byBrbm93IHdo YXQgdGhlIFNlYy1Ub2tlbi1CaW5kaW5nIGhlYWRlciBtZWFucyBhbmQgdXNlIHNvbWUgc29ydCBv ZiBwcm9wcmlldGFyeSBtZWNoYW5pc20gYmV0d2VlbiBpdHNlbGYgYW5kIHRoZSBkb3duc3RyZWFt IHNlcnZlciB0byBwYXNzIG9uIHRoZSBpbmZvcm1hdGlvbiB0aGF0IHRoZSBkb3duc3RyZWFtIHNl cnZlciBuZWVkcy4NCi0gRm9yIGEgcHJveHkgdGhhdCAqZG9lc24ndCoga25vdyB3aGF0IHRoZSBT ZWMtVG9rZW4tQmluZGluZyBoZWFkZXIgbWVhbnMsIGl0J3MgcHJvYmFibHkgYmVzdCB0byBqdXN0 IGRyb3AgaXQsIHRodXMgc2F2aW5nIHRoZSBkb3duc3RyZWFtIHNlcnZlciBzb21lIHdvcmsgdmVy aWZ5aW5nIGEgaGVhZGVyIHRoYXQgd2Uga25vdyB3b24ndCB2ZXJpZnkuDQoNClNvIHRvIG1lIGl0 IHNlZW1zIHRoYXQgbGlzdGluZyBpdCBpbiB0aGUgQ29ubmVjdCBoZWFkZXIgaXMgdGhlIHJpZ2h0 IGFuc3dlciwgYnV0IGxpa2UgSSBzYWlkIEkgZG9uJ3QgZmVlbCBzdHJvbmdseSBhYm91dCBpdC4N Cg0KRGlyay4NCg0KDQpPbiBUdWUsIEZlYiA3LCAyMDE3IGF0IDI6NTYgUE0gSm9obiBCcmFkbGV5 IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCkFy ZSBjb25uZWN0aW9uIGhlYWRlcnMgbm9ybWFsbHkgdXNlZCBpbiB0aGUgcmV2ZXJzZSBwcm94eSB1 c2UgY2FzZT8gICBHZW5lcmFsbHkgdGhlIHVzZXIgYWdlbnQgd291bGRuJ3Qga25vdyB0aGF0IGl0 IHdhcyB0YWxraW5nIHRvIGEgcHJveHkuDQoNCkkgdGhvdWdodCB0aGF0IHRoZXkgd2VyZSBtb3Jl IGZvciB0aGUgZm9yd2FyZCBwcm94eSB1c2UgY2FzZSB3aGVyZSB0aGUgYnJvd3NlciBpcyBjb25m aWd1cmVkIHRvIHRhbGsgdG8gYSBzcGVjaWZpYyBwcm94eSBvciBpcyB0cmFuc3BhcmVudGx5IGlu dGVyY2VwdGVkIChtYW4vZW50ZXJwcmlzZSBpbiB0aGUgbWlkZGxlKQ0KDQpJIGNvdWxkIGh5cG90 aGV0aWNhbGx5IHNlZSBhIGVudGVycHJpc2UgcHJveHkgY3JlYXRpbmcgdG9rZW4gYmluZGluZyBJ ZOKAmXMgZm9yIHRoZSBjb25uZWN0aW9ucyB0byBzZXJ2ZXJzIGFuZCBtYXBwaW5nIHRob3NlIHRv IHRva2VuIGJpbmRpbmcgSUQgZnJvbSB0aGUgYnJvd3Nlci4NCg0KSSB0aGluayB0aGUgTkdOWCB0 b2tlbiBiaW5kaW5nIG1vZHVsZSAoaHR0cHM6Ly9naXRodWIuY29tL2dvb2dsZS9uZ3hfdG9rZW5f YmluZGluZykgaXMgZG9pbmcgdGhhdCBzb3J0IG9mIHRyYW5zcGFyZW50IG1hcHBpbmcgb24gdGhl IHNlcnZlciBzaWRlIGZvciBzZXNzaW9uIGNvb2tpZXMuDQoNCldlIHByb2JhYmx5IGRvbid0IHdh bnQgdGhlIHNhbWUgYmVoYXZpb3VyIGZvciBib3RoIGZvcndhcmQgYW5kIHJldmVyc2UgcHJveGll cy4NCg0KSm9obiBCLg0KDQoNCk9uIEZlYiA3LCAyMDE3LCBhdCA3OjM4IFBNLCBBbmRyZWkgUG9w b3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9z b2Z0LmNvbT4+IHdyb3RlOg0KDQpXaGVuIHdlIGRpc2N1c3NlZCB0aGlzIGVhcmx5IG9uLCB0aGVy ZSB3YXMgYSBzdHJvbmcgZGlzdGFzdGUgZm9yIGNvbm5lY3Rpb24gaGVhZGVycyBpbiB0aGUgSFRU UCBjb21tdW5pdHksIHNvIHdlJ3ZlIGRlZmluZWQgVEIgaGVhZGVycyBhcyBwZXItcmVxdWVzdC4N CiIgY2xpZW50cyBNVVNUIGluY2x1ZGUgdGhlIFNlYy1Ub2tlbi0NCiAgQmluZGluZyBoZWFkZXIg ZmllbGQgaW4gdGhlaXIgSFRUUCByZXF1ZXN0cy4iDQpXZSBjb3VsZCBhbHNvIGV4cGxpY2l0bHkg cHJvaGliaXQgbGlzdGluZyBUQiBoZWFkZXJzIGluIHRoZSBDb25uZWN0aW9uIGhlYWRlciwgaWYg Zm9sa3Mgd291bGQgbGlrZSB0byBzZWUgdGhpcyBjbGFyaWZpY2F0aW9uLg0KVGhlcmUgYXJlIG1h bnkgcmVhc29ucyB0byBrZWVwIFRCIGhlYWRlcnMgcGVyLXJlcXVlc3Q7IGl0J3Mgbm90IGp1c3Qg YWJvdXQgdGhlIHByb3hpZXMgYW5kIHRlcm1pbmF0b3JzLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOnVu YmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mID1KZWZmSA0KU2VudDogVHVl c2RheSwgRmVicnVhcnkgNywgMjAxNyAyOjE1IFBNDQpUbzogSUVURiBUb2tCaW5kIFdHIDx1bmJl YXJhYmxlQGlldGYub3JnPG1haWx0bzp1bmJlYXJhYmxlQGlldGYub3JnPj4NClN1YmplY3Q6IFtV bmJlYXJhYmxlXSBvbiBub3QgbGlzdGluZyAnU2VjLVRva2VuLUJpbmRpbmcnIGluIHRoZSBDb25u ZWN0aW9uIGhlYWRlciBmaWVsZD8NCg0KdGhlIGJlbG93IGlzIGtpbmQgb2YgbG9uZyAocmVhZCBp dCBhbnl3YXkgOikgIFRoZSBzdW1tYXJ5IGlzIHdlIG5lZWQgdG8gbWFrZSBhIGNvbnNjaW91cyBk ZWNpc2lvbiByZWdhcmRpbmcgdGhlIENvbm5lY3Rpb24gSFRUUCByZXF1ZXN0IGhlYWRlciBmaWVs ZCBhbmQgd2hldGhlciB3ZSBwcm92aWRlIGd1aWRhbmNlIHJlZ2FyZGluZyBpdCBhbmQgdGhlIFNl Yy1Ub2tlbi1CaW5kaW5nIGhlYWRlciAoYW5kIHdoYXQgZ3VpZGFuY2UgaWYgc28pLCBvciBub3Qu IFRoaXMgc2VlbXMgdG8gaGF2ZSByYW1pZmljYXRpb25zIGZvciB0aGUgbmFzY2VudCBkcmFmdC1j YW1wYmVsbC10b2tiaW5kLXRscy10ZXJtIGRyYWZ0LCB1bmxlc3MgSSdtIG1pc3VuZGVyc3RhbmRp bmcgdGhpbmdzLg0KDQo9SmVmZkgNCg0KSW4gd29ya2luZyB0aHJvdWdoIHRoZSBsaXN0IG9mICJD b25zaWRlcmF0aW9ucyBmb3IgTmV3IEhlYWRlciBGaWVsZHMiIGF0IHRoZSBlbmQgb2YgcmZjNzIz MSBzZWN0aW9uIDguMy4xIFsxXSwgdGhlcmUgYXJlIHRoZXNlIHR3byBpdGVtcy4uDQoNCiAgIG8g IFdoZXRoZXIgaXQgaXMgYXBwcm9wcmlhdGUgdG8gbGlzdCB0aGUgZmllbGQtbmFtZSBpbiB0aGUg Q29ubmVjdGlvbg0KICAgICAgaGVhZGVyIGZpZWxkIChpLmUuLCBpZiB0aGUgaGVhZGVyIGZpZWxk IGlzIHRvIGJlIGhvcC1ieS1ob3A7IHNlZQ0KICAgICAgU2VjdGlvbiA2LjEgb2YgW1JGQzcyMzBd KS4NCg0KICAgbyAgVW5kZXIgd2hhdCBjb25kaXRpb25zIGludGVybWVkaWFyaWVzIGFyZSBhbGxv d2VkIHRvIGluc2VydCwNCiAgICAgIGRlbGV0ZSwgb3IgbW9kaWZ5IHRoZSBmaWVsZCdzIHZhbHVl Lg0KDQpHaXZlbiB0aGUgc3BlY2lmaWNzIGluIFtSRkM3MjMwXSBTZWN0aW9uIDYuMSBbMl0uLg0K DQogIDYuMS4gIENvbm5lY3Rpb24NCg0KICAgVGhlICJDb25uZWN0aW9uIiBoZWFkZXIgZmllbGQg YWxsb3dzIHRoZSBzZW5kZXIgdG8gaW5kaWNhdGUgZGVzaXJlZA0KICAgY29udHJvbCBvcHRpb25z IGZvciB0aGUgY3VycmVudCBjb25uZWN0aW9uLiAgSW4gb3JkZXIgdG8gYXZvaWQNCiAgIGNvbmZ1 c2luZyBkb3duc3RyZWFtIHJlY2lwaWVudHMsIGEgcHJveHkgb3IgZ2F0ZXdheSBNVVNUIHJlbW92 ZSBvcg0KICAgcmVwbGFjZSBhbnkgcmVjZWl2ZWQgY29ubmVjdGlvbiBvcHRpb25zIGJlZm9yZSBm b3J3YXJkaW5nIHRoZQ0KICAgbWVzc2FnZS4NCg0KICAgV2hlbiBhIGhlYWRlciBmaWVsZCBhc2lk ZSBmcm9tIENvbm5lY3Rpb24gaXMgdXNlZCB0byBzdXBwbHkgY29udHJvbA0KICAgaW5mb3JtYXRp b24gZm9yIG9yIGFib3V0IHRoZSBjdXJyZW50IGNvbm5lY3Rpb24sIHRoZSBzZW5kZXIgTVVTVCBs aXN0DQogICB0aGUgY29ycmVzcG9uZGluZyBmaWVsZC1uYW1lIHdpdGhpbiB0aGUgQ29ubmVjdGlv biBoZWFkZXIgZmllbGQuICBBDQogICBwcm94eSBvciBnYXRld2F5IE1VU1QgcGFyc2UgYSByZWNl aXZlZCBDb25uZWN0aW9uIGhlYWRlciBmaWVsZCBiZWZvcmUNCiAgIGEgbWVzc2FnZSBpcyBmb3J3 YXJkZWQgYW5kLCBmb3IgZWFjaCBjb25uZWN0aW9uLW9wdGlvbiBpbiB0aGlzIGZpZWxkLA0KICAg cmVtb3ZlIGFueSBoZWFkZXIgZmllbGQocykgZnJvbSB0aGUgbWVzc2FnZSB3aXRoIHRoZSBzYW1l IG5hbWUgYXMgdGhlDQogICBjb25uZWN0aW9uLW9wdGlvbiwgYW5kIHRoZW4gcmVtb3ZlIHRoZSBD b25uZWN0aW9uIGhlYWRlciBmaWVsZCBpdHNlbGYNCiAgIChvciByZXBsYWNlIGl0IHdpdGggdGhl IGludGVybWVkaWFyeSdzIG93biBjb25uZWN0aW9uIG9wdGlvbnMgZm9yIHRoZQ0KICAgZm9yd2Fy ZGVkIG1lc3NhZ2UpLg0KDQogICBIZW5jZSwgdGhlIENvbm5lY3Rpb24gaGVhZGVyIGZpZWxkIHBy b3ZpZGVzIGEgZGVjbGFyYXRpdmUgd2F5IG9mDQogICBkaXN0aW5ndWlzaGluZyBoZWFkZXIgZmll bGRzIHRoYXQgYXJlIG9ubHkgaW50ZW5kZWQgZm9yIHRoZSBpbW1lZGlhdGUNCiAgIHJlY2lwaWVu dCAoImhvcC1ieS1ob3AiKSBmcm9tIHRob3NlIGZpZWxkcyB0aGF0IGFyZSBpbnRlbmRlZCBmb3Ig YWxsDQogICByZWNpcGllbnRzIG9uIHRoZSBjaGFpbiAoImVuZC10by1lbmQiKSwgZW5hYmxpbmcg dGhlIG1lc3NhZ2UgdG8gYmUNCiAgIHNlbGYtZGVzY3JpcHRpdmUgYW5kIGFsbG93aW5nIGZ1dHVy ZSBjb25uZWN0aW9uLXNwZWNpZmljIGV4dGVuc2lvbnMNCiAgIHRvIGJlIGRlcGxveWVkIHdpdGhv dXQgZmVhciB0aGF0IHRoZXkgd2lsbCBiZSBibGluZGx5IGZvcndhcmRlZCBieQ0KICAgb2xkZXIg aW50ZXJtZWRpYXJpZXMuDQoNCi4uaXQgb2ZmaGFuZCBzZWVtcyB0aGF0IG9uZSB3b3VsZCB3YW50 IHRvIGxpc3QgIlNlYy1Ub2tlbi1CaW5kaW5nIiBpbiB0aGUgQ29ubmVjdGlvbiBoZWFkZXIgZmll bGQgYmVjYXVzZSBTZWMtVG9rZW4tQmluZGluZyBpcyBvc3RlbnNpYmx5IGFib3V0IHRoZSBjb25u ZWN0aW9uIGFuZCBpcyBob3AtYnktaG9wIGJlY2F1c2UgVExTIGlzIGhvcC1ieS1ob3AuDQoNCkhv d2V2ZXIsIGdpdmVuIG91ciBjdXJyZW50IHRoaW5raW5nIHdydCBUQiBhbmQgVExTIFRlcm1pbmF0 aW5nIFJldmVyc2UgUHJveGllcyBbM10sIHdoZXJlIHdlIGFyZSBjb250ZW1wbGF0aW5nIG9uZSBh cHByb2FjaCB3aGVyZSBzdWNoICJUVFJQcyINCnBhc3MtdGhyb3VnaCB0aGUgU2VjLVRva2VuLUJp bmRpbmcgaGVhZGVyIGZpZWxkIGFuZCBhZGQgYSBjb3JyZXNwb25kaW5nIFRva2VuLUJpbmRpbmct Q29udGV4dCBoZWFkZXIsIG9uZSB3b3VsZCBub3Qgd2FudCB0byBsaXN0IFNlYy1Ub2tlbi1CaW5k aW5nIGluIHRoZSBDb25uZWN0aW9uIGhlYWRlciAoYmVjYXVzZSBhIFRUUlAgd291bGQgdGhlbiBz dHJpcCBpdCBvZmYpLiBIb3dldmVyIHRoZXJlIGFyZSBpbXBsZW1lbnRhdGlvbiBhbmQgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgd2l0aCB0aGlzLg0KDQpBcyBvbmUgcHJvcG9zYWwsIHdlIGNvdWxk IHNheSBpbiBIVFRQU1RCIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2YuLg0KDQogIFsuLi5d DQogIENsaWVudHMgU0hPVUxEIE5PVCBsaXN0IHRoZSBTZWMtVG9rZW4tQmluZGluZyBoZWFkZXIg ZmllbGQgYXMNCiAgYSBjb25uZWN0aW9uIG9wdGlvbiBpbiB0aGUgQ29ubmVjdGlvbiBoZWFkZXIg ZmllbGQgKFNlY3Rpb24gNi4xDQogIG9mIFtSRkM3MjMwXSkgaW4gb3JkZXIgdG8gZ2VuZXJhbGx5 IGVuYWJsZSBTZWMtVG9rZW4tQmluZGluZw0KICBoZWFkZXIgZmllbGQgcGFzcy10aHJvdWdoIGJ5 IGludGVybWVkaWFyaWVzLCBlLmcuLCBieSBUTFMNCiAgdGVybWluYXRpbmcgcmV2ZXJzZSBwcm94 aWVzIChUVFJQKS4gSW50ZXJtZWRpYXJpZXMgTVVTVCBOT1QNCiAgbW9kaWZ5IHRoZSBTZWMtVG9r ZW4tQmluZGluZyBoZWFkZXIgZmllbGQncyB2YWx1ZS4gU2VlIGFsc28gdGhlDQogIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQogIFsuLi5dDQogIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zDQogIFsuLi5dDQogIE5vdCBsaXN0aW5nIFNlYy1Ub2tlbi1CaW5kaW5nIGluIHRoZSBDb25u ZWN0aW9uIGhlYWRlcjogdGhpcw0KICBlbmFibGVzIFRUUlBzIHRvIHRyYW5zcGFyZW50bHkgY29u dmV5IHRoZSBTZWMtVG9rZW4tQmluZGluZyBoZWFkZXINCiAgZmllbGQsIGNvbnRhaW5pbmcgYSBU b2tlbiBCaW5kaW5nIE1lc3NhZ2UsIHRvIHRoZSBuZXh0IHRpZXIgKCJiYWNrZW5kDQogIHNlcnZl cnMiKSwgZS5nLiwgd2hlcmUgc2VjdXJpdHkgdG9rZW5zIGNvbnRhaW5pbmcgVG9rZW4gQmluZGlu ZyBJRHMNCiAgbWF5IGJlIG1pbnRlZCBhbmQgdmFsaWRhdGVkLiBUaGUgY29tbXVuaWNhdGlvbiBi ZXR3ZWVuIGEgVFRSUCBhbmQNCiAgYmFja2VuZCBzZXJ2ZXJzIG5lZWRzIHRvIGJlIHNlY3VyZWQg YWdhaW5zdCBlYXZlc2Ryb3BwaW5nIGFuZA0KICBtb2RpZmljYXRpb24gYnkgdW5pbnRlbmRlZCBw YXJ0aWVzLiBUaGUgVG9rZW4gQmluZGluZyBNZXNzYWdlIGl0c2VsZg0KICBtYXkgYmUgdmFsaWRh dGVkIGJ5IHRoZSBUVFJQIG9yIGJ5IGEgYmFja2VuZCBzZXJ2ZXIuIFRob3VnaCwgaW4gdGhlDQog IGxhdHRlciBjYXNlLCB0aGUgZGF0YSBuZWNlc3NhcnkgdG8gcGVyZm9ybSBzdWNoIHZhbGlkYXRp b24gKGkuZS4sIHRoZQ0KICBFS00sIGV0Yy4pIG5lZWRzIHRvIGJlIGNvbnZleWVkIHRvIHRoZSBl bnRpdHkgcGVyZm9ybWluZyBpdC4gU3VjaA0KICBjb252ZXlhbmNlIGlzIG91dCBvZiBzY29wZSBm b3IgdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQogIExpc3RpbmcgU2VjLVRva2VuLUJpbmRpbmcgaW4g dGhlIENvbm5lY3Rpb24gaGVhZGVyOiBpZiBkb25lLCB0aGlzDQogIG1heSBoZWxwIGluIGVuc3Vy aW5nIHRoYXQgVG9rZW4gQmluZGluZyBJRHMgYXJlIG5vdCBpbmFkdmVydGVudGx5DQogIHJldmVh bGVkIHRvIHVuaW50ZW5kZWQgcGFydGllcywgdGhvdWdoIG1heSBjYXVzZSBkaWZmaWN1bHRpZXMg d2l0aA0KICB3ZWIgc2l0ZXMgZW1wbG95aW5nIFRUUlBzLg0KICBbLi4uXQ0KDQpPciwgd2UgY291 bGQganVzdCBzYXkgImNsaWVudHMgU0hPVUxEIGxpc3QgdGhlIFNlYy1Ub2tlbi1CaW5kaW5nIGhl YWRlciBmaWVsZCBhcyBhIGNvbm5lY3Rpb24gb3B0aW9uIGluIHRoZSBDb25uZWN0aW9uIGhlYWRl ciBmaWVsZCIsIGJ1dCB0aGF0IHdpbGwgY3JlYXRlIHByb2JsZW1zIGZvciBUVFJQcyBbM10uDQoN Ck9yLCB3ZSBjYW4ganVzdCBub3QgbWVudGlvbiB0aGUgQ29ubmVjdGlvbiBoZWFkZXIgYW5kIHNl ZSBpZiBhbnlvbmUgcmFpc2VzIHF1ZXN0aW9ucyBhYm91dCBpdCBkdXJpbmcgZnVydGhlciBXRyBh bmQgSUVURi13aWRlIHJldmlldy4NCg0KdGhvdWdodHM/DQoNClsxXSA8aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzcyMzEjc2VjdGlvbi04LjMuMT4NCg0KWzJdIDxodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNzIzMCNzZWN0aW9uLTYuMT4NCg0KWzNdIDxodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtdG9rYmluZC10bHMtdGVybT4NCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVW5iZWFyYWJsZSBt YWlsaW5nIGxpc3QNClVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClVuYmVhcmFi bGUgbWFpbGluZyBsaXN0DQpVbmJlYXJhYmxlQGlldGYub3JnPG1haWx0bzpVbmJlYXJhYmxlQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxl DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpVbmJl YXJhYmxlIG1haWxpbmcgbGlzdA0KVW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86VW5iZWFyYWJs ZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFy YWJsZQ0KDQo= --_000_CY1PR0301MB08423324E89771A0EEDD72068C420CY1PR0301MB0842_ 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 bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTQzODEzNjk4MjsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MzUwMTc1MTYgLTExNTgzNjExNzAgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglt c28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZSBDb25uZWN0IGhl YWRlciBpcyBmb3IgdGhlIGNsaWVudCB0byB0ZWxsIGEgcHJveHkgJnF1b3Q7dGhpcyBoZWFkZXIg cmVhbGx5IGRvZXNuJ3QgbWFrZSBzZW5zZSB0byBmb3J3YXJkLCBwbGVhc2UgZHJvcCBpdCBvbiB0 aGUgbmV4dCBob3AmcXVvdDsuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuKApmJ1dCBpbiB0aGUgY2Fz ZSBvZiB0aGUgU2VjLVRva2VuLUJpbmRpbmcgaGVhZGVyLCB0aGUgY2xpZW50IGRvZXMgbm90IGtu b3cgd2hldGhlciBpdCBtYWtlcyBzZW5zZSB0byBmb3J3YXJkIG9yIG5vdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBjbGll bnQsIGdlbmVyYWxseSwgZG9lcyBub3Qga25vdyB3aGV0aGVyIHRoZSBwcm94eSBvciBUTFMgdGVy bWluYXRvciB2YWxpZGF0ZXMgYmluZGluZ3MsIHBhc3NlcyB0aGVtIGFsb25nIGZvciB0aGUgYXBw bGljYXRpb24gc2VydmVyIHRvIHZhbGlkYXRlLCBvciBzdHJpcHMgdGhlbSBhbHRvZ2V0aGVyLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT5JIGFtIG5vdCByZWFsbHkgZ2V0dGluZyB0aGUgc2Vuc2UgdGhhdCB3ZSBuZWVkIHRv IG1lbnRpb24gdGhlIGNvbm5lY3QgaGVhZGVyIGlmIHdlIGFyZSBoYXBweSB3aXRoIHRoZSBkZWZh dWx0IGJlaGF2aW91ciBhbmQgY2FuIGFjY291bnQgZm9yIGl0IGluIHNwZWNzIHVzaW5nIHRva2Vu IGJpbmRpbmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPlRoaXMgc291bmRzIHJlYXNvbmFibGUgdG8gbWUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNoZWVy cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+QW5kcmVpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSm9o biBCcmFkbGV5IFttYWlsdG86dmU3anRiQHZlN2p0Yi5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBGZWJydWFyeSA4LCAyMDE3IDY6NDQgQU08YnI+DQo8Yj5Ubzo8L2I+IERpcmsg QmFsZmFueiAmbHQ7YmFsZmFuekBnb29nbGUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQW5kcmVp IFBvcG92ICZsdDtBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSZndDs7IElFVEYgVG9rQmluZCBX RyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZndDs7ID1KZWZmSCBIb2RnZXMgJmx0O0plZmYuSG9k Z2VzQGtpbmdzbW91bnRhaW4uY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVh cmFibGVdIG9uIG5vdCBsaXN0aW5nICdTZWMtVG9rZW4tQmluZGluZycgaW4gdGhlIENvbm5lY3Rp b24gaGVhZGVyIGZpZWxkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgc3VzcGVjdCB0aGUgb25seSBwbGFjZSB3ZSByZWFsbHkgcnVuIGludG8gYSBjb25m bGljdCBpcyBpbiBCcmlhbidzIGRyYWZ0IGJ5IHJlIHVzaW5nL21haW50YWluaW5nIHRoZSBTZWMt VG9rZW4tQmluZGluZyBoZWFkZXIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BcyBEaXJrIHBvaW50cyBvdXQgdGhhdCBkcmFmdCBjb3VsZCBtb3ZlIHRoZSBp bmZvIGluIHRoZSBTZWMtVG9rZW4tQmluZGluZyBoZWFkZXIgdG8gYSBkaWZmZXJlbnQgaGVhZGVy IGlmIGl0IGlzIGxpc3RlZCBpbiB0aGUgQ29ubmVjdCBoZWFkZXIsIG9yIGFsd2F5cyBqdXN0IHVz ZSBhIGRpZmZlcmVudCBoZWFkZXIgbmFtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBjYW4gYmUgZGViYXRlZCBhcyBwYXJ0IG9mIHRo ZSByZXZlcnNlIHByb3h5IHNwZWMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90IHJlYWxseSBnZXR0aW5nIHRoZSBzZW5zZSB0aGF0 IHdlIG5lZWQgdG8gbWVudGlvbiB0aGUgY29ubmVjdCBoZWFkZXIgaWYgd2UgYXJlIGhhcHB5IHdp dGggdGhlIGRlZmF1bHQgYmVoYXZpb3VyIGFuZCBjYW4gYWNjb3VudCBmb3IgaXQgaW4gc3BlY3Mg dXNpbmcgdG9rZW4gYmluZGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBkbyBwZW9wbGUgdGhpbmsgd2Ugc2hvdWxkIGRvIHRvIGNs b3NlIHRoaXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIEZlYiA4LCAyMDE3LCBhdCAxMjo1MiBBTSwgRGlyayBCYWxmYW56ICZsdDs8YSBo cmVmPSJtYWlsdG86YmFsZmFuekBnb29nbGUuY29tIj5iYWxmYW56QGdvb2dsZS5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg ZG9uJ3QgZmVlbCBzdHJvbmdseSBhYm91dCB0aGlzIC0gSSdtIGZpbmUgZWl0aGVyIHdheSwgYnV0 IHdvdWxkIHN1Z2dlc3QgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0gVGhlIENvbm5lY3QgaGVhZGVyIGlzIGZvciB0aGUgY2xpZW50 IHRvIHRlbGwgYSBwcm94eSAmcXVvdDt0aGlzIGhlYWRlciByZWFsbHkgZG9lc24ndCBtYWtlIHNl bnNlIHRvIGZvcndhcmQsIHBsZWFzZSBkcm9wIGl0IG9uIHRoZSBuZXh0IGhvcCZxdW90Oy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gQ2xpZW50 cyB1c3VhbGx5IGFyZW4ndCBhd2FyZSB0aGF0IHRoZXkncmUgdGFsa2luZyB0byBhIFRUUlAsIHNv IEkgYWdyZWUgd2l0aCBKb2huIHRoYXQgdGhhdCdzIHByb2JhYmx5IG5vdCBhIHVzZSBjYXNlIHRo YXQgdGhlIENvbm5lY3QgaGVhZGVyIHdhcyBtZWFudCBmb3IuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIElmIHRoZSBjbGllbnQgKmlzKiBhd2Fy ZSB0aGF0IGl0J3MgdGFsa2luZyB0byBhIHByb3h5LCBsaXN0aW5nIFNlYy1Ub2tlbi1CaW5kaW5n IGluIHRoZSBDb25uZWN0IGhlYWRlciAodGh1cyBpbmRpY2F0aW5nIHRoYXQgaXQgc2hvdWxkbid0 IGJlIGZvcndhcmRlZCkgbWFrZXMgc2Vuc2UgdG8gbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIElmIHRoZSBwcm94eSBoYXMgc29tZSBzb3J0 IG9mIGFycmFuZ2VtZW50IHdpdGggdGhlIGRvd25zdHJlYW0gc2VydmVyIHRoYXQgaXQncyBzdXBw b3NlZCB0byBjb21tdW5pY2F0ZSB0aGUgVG9rZW4gQmluZGluZyBpbmZvcm1hdGlvbiAobGlrZSBh IFRUUlAgd291bGQpLCBpdCBoYXMgYSB0d28gb3B0aW9uczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAqIHZlcmlmeSB0aGUgVG9rZW4g QmluZGluZyBpbmZvcm1hdGlvbiBhbmQgZm9yd2FyZCBqdXN0IHRoZSBUb2tlbiBCaW5kaW5nIElE IHRvIHRoZSBkb3duc3RyZWFtIHNlcnZlciAodXNpbmcgc29tZSBtZWNoYW5pc20gcHJvcHJpZXRh cnkgdG8gdGhlIHByb3h5IGFuZCBkb3duc3RyZWFtIHNlcnZlcikuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgKiBmb3J3YXJkIHRoZSBT ZWMtVG9rZW4tQmluZGluZyBoZWFkZXIsIGFuZCAodXNpbmcgc29tZSBtZWNoYW5pc20gcHJvcHJp ZXRhcnkgdG8gdGhlIHByb3h5IGFuZCBkb3duc3RyZWFtIHNlcnZlcikgdGhlIEVLTSBpbmZvcm1h dGlvbiwgdG8gdGhlIGRvd25zdHJlYW0gc2VydmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIHByb3h5IGhhcyBxdWFsbXMgYWJvdXQg dmlvbGF0aW5nIHRoZSBzcGVjIGJ5IGZvcndhcmRpbmcgdGhlIFNlYy1Ub2tlbi1CaW5kaW5nIGhl YWRlciBkZXNwaXRlIGl0cyBiZWluZyBsaXN0ZWQgaW4gdGhlIENvbm5lY3QgaGVhZGVyLCBpdCBj YW4gYWx3YXlzIGp1c3QgdXNlIGEgZGlmZmVyZW50IGhlYWRlciBuYW1lLCBsaWtlICZxdW90O1By aXZhdGUtRm9yd2FyZGVkLVRva2VuLUJpbmRpbmcmcXVvdDssIG9yIHdoYXRldmVyDQogLSBzb21l ICZuYnNwO21lY2hhbmlzbSBwcm9wcmlldGFyeSB0byB0aGUgcHJveHkgYW5kIGRvd25zdHJlYW0g c2VydmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LSBFaXRoZXIgd2F5LCB0aGUgcHJveHkgd2lsbCBoYXZlIHRvIGtub3cgd2hhdCB0aGUgU2Vj LVRva2VuLUJpbmRpbmcgaGVhZGVyIG1lYW5zIGFuZCB1c2Ugc29tZSBzb3J0IG9mIHByb3ByaWV0 YXJ5IG1lY2hhbmlzbSBiZXR3ZWVuIGl0c2VsZiBhbmQgdGhlIGRvd25zdHJlYW0gc2VydmVyIHRv IHBhc3Mgb24gdGhlIGluZm9ybWF0aW9uIHRoYXQgdGhlIGRvd25zdHJlYW0gc2VydmVyIG5lZWRz LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBG b3IgYSBwcm94eSB0aGF0ICpkb2Vzbid0KiBrbm93IHdoYXQgdGhlIFNlYy1Ub2tlbi1CaW5kaW5n IGhlYWRlciBtZWFucywgaXQncyBwcm9iYWJseSBiZXN0IHRvIGp1c3QgZHJvcCBpdCwgdGh1cyBz YXZpbmcgdGhlIGRvd25zdHJlYW0gc2VydmVyIHNvbWUgd29yayB2ZXJpZnlpbmcgYSBoZWFkZXIg dGhhdCB3ZSBrbm93IHdvbid0IHZlcmlmeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gdG8gbWUgaXQgc2VlbXMgdGhhdCBsaXN0aW5nIGl0 IGluIHRoZSBDb25uZWN0IGhlYWRlciBpcyB0aGUgcmlnaHQgYW5zd2VyLCBidXQgbGlrZSBJIHNh aWQgSSBkb24ndCBmZWVsIHN0cm9uZ2x5IGFib3V0IGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EaXJrLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRmViIDcsIDIwMTcg YXQgMjo1NiBQTSBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRi LmNvbSI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcmUgY29ubmVj dGlvbiBoZWFkZXJzIG5vcm1hbGx5IHVzZWQgaW4gdGhlIHJldmVyc2UgcHJveHkgdXNlIGNhc2U/ ICZuYnNwOyBHZW5lcmFsbHkgdGhlIHVzZXIgYWdlbnQgd291bGRuJ3Qga25vdyB0aGF0IGl0IHdh cyB0YWxraW5nIHRvIGEgcHJveHkuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIHRob3VnaHQgdGhhdCB0aGV5IHdlcmUgbW9yZSBmb3IgdGhlIGZvcndhcmQg cHJveHkgdXNlIGNhc2Ugd2hlcmUgdGhlIGJyb3dzZXIgaXMgY29uZmlndXJlZCB0byB0YWxrIHRv IGEgc3BlY2lmaWMgcHJveHkgb3IgaXMgdHJhbnNwYXJlbnRseSBpbnRlcmNlcHRlZCAobWFuL2Vu dGVycHJpc2UgaW4gdGhlIG1pZGRsZSkmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBjb3VsZCBoeXBvdGhldGljYWxseSBzZWUgYSBl bnRlcnByaXNlIHByb3h5IGNyZWF0aW5nIHRva2VuIGJpbmRpbmcgSWTigJlzIGZvciB0aGUgY29u bmVjdGlvbnMgdG8gc2VydmVycyBhbmQgbWFwcGluZyB0aG9zZSB0byB0b2tlbiBiaW5kaW5nIElE IGZyb20gdGhlIGJyb3dzZXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlIE5HTlggdG9rZW4gYmluZGluZyBtb2R1 bGUgKDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9nb29nbGUvbmd4X3Rva2VuX2JpbmRpbmci IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vZ29vZ2xlL25neF90b2tlbl9iaW5k aW5nPC9hPikmbmJzcDtpcyBkb2luZyB0aGF0IHNvcnQgb2YgdHJhbnNwYXJlbnQgbWFwcGluZyBv biB0aGUgc2VydmVyIHNpZGUgZm9yIHNlc3Npb24gY29va2llcy4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgcHJvYmFibHkgZG9u J3Qgd2FudCB0aGUgc2FtZSBiZWhhdmlvdXIgZm9yIGJvdGggZm9yd2FyZCBhbmQgcmV2ZXJzZSBw cm94aWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Kb2huIEIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiA3LCAyMDE3LCBhdCA3OjM4IFBNLCBB bmRyZWkgUG9wb3YgJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNv bSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGVuIHdl IGRpc2N1c3NlZCB0aGlzIGVhcmx5IG9uLCB0aGVyZSB3YXMgYSBzdHJvbmcgZGlzdGFzdGUgZm9y IGNvbm5lY3Rpb24gaGVhZGVycyBpbiB0aGUgSFRUUCBjb21tdW5pdHksIHNvIHdlJ3ZlIGRlZmlu ZWQgVEIgaGVhZGVycyBhcyBwZXItcmVxdWVzdC48YnI+DQomcXVvdDsgY2xpZW50cyBNVVNUIGlu Y2x1ZGUgdGhlIFNlYy1Ub2tlbi08YnI+DQombmJzcDsmbmJzcDtCaW5kaW5nIGhlYWRlciBmaWVs ZCBpbiB0aGVpciBIVFRQIHJlcXVlc3RzLiZxdW90Ozxicj4NCldlIGNvdWxkIGFsc28gZXhwbGlj aXRseSBwcm9oaWJpdCBsaXN0aW5nIFRCIGhlYWRlcnMgaW4gdGhlIENvbm5lY3Rpb24gaGVhZGVy LCBpZiBmb2xrcyB3b3VsZCBsaWtlIHRvIHNlZSB0aGlzIGNsYXJpZmljYXRpb24uDQo8YnI+DQpU aGVyZSBhcmUgbWFueSByZWFzb25zIHRvIGtlZXAgVEIgaGVhZGVycyBwZXItcmVxdWVzdDsgaXQn cyBub3QganVzdCBhYm91dCB0aGUgcHJveGllcyBhbmQgdGVybWluYXRvcnMuPGJyPg0KPGJyPg0K Q2hlZXJzLDxicj4NCjxicj4NCkFuZHJlaTxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KRnJvbTogVW5iZWFyYWJsZSBbPGEgaHJlZj0ibWFpbHRvOnVuYmVhcmFibGUt Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzp1bmJlYXJhYmxlLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgPUplZmZIPGJyPg0KU2VudDogVHVlc2RheSwg RmVicnVhcnkgNywgMjAxNyAyOjE1IFBNPGJyPg0KVG86IElFVEYgVG9rQmluZCBXRyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj51bmJlYXJh YmxlQGlldGYub3JnPC9hPiZndDs8YnI+DQpTdWJqZWN0OiBbVW5iZWFyYWJsZV0gb24gbm90IGxp c3RpbmcgJ1NlYy1Ub2tlbi1CaW5kaW5nJyBpbiB0aGUgQ29ubmVjdGlvbiBoZWFkZXIgZmllbGQ/ PGJyPg0KPGJyPg0KdGhlIGJlbG93IGlzIGtpbmQgb2YgbG9uZyAocmVhZCBpdCBhbnl3YXkgOikg Jm5ic3A7VGhlIHN1bW1hcnkgaXMgd2UgbmVlZCB0byBtYWtlIGEgY29uc2Npb3VzIGRlY2lzaW9u IHJlZ2FyZGluZyB0aGUgQ29ubmVjdGlvbiBIVFRQIHJlcXVlc3QgaGVhZGVyIGZpZWxkIGFuZCB3 aGV0aGVyIHdlIHByb3ZpZGUgZ3VpZGFuY2UgcmVnYXJkaW5nIGl0IGFuZCB0aGUgU2VjLVRva2Vu LUJpbmRpbmcgaGVhZGVyIChhbmQgd2hhdCBndWlkYW5jZSBpZiBzbyksIG9yDQogbm90LiBUaGlz IHNlZW1zIHRvIGhhdmUgcmFtaWZpY2F0aW9ucyBmb3IgdGhlIG5hc2NlbnQgZHJhZnQtY2FtcGJl bGwtdG9rYmluZC10bHMtdGVybSBkcmFmdCwgdW5sZXNzIEknbSBtaXN1bmRlcnN0YW5kaW5nIHRo aW5ncy48YnI+DQo8YnI+DQo9SmVmZkg8YnI+DQo8YnI+DQpJbiB3b3JraW5nIHRocm91Z2ggdGhl IGxpc3Qgb2YgJnF1b3Q7Q29uc2lkZXJhdGlvbnMgZm9yIE5ldyBIZWFkZXIgRmllbGRzJnF1b3Q7 IGF0IHRoZSBlbmQgb2YgcmZjNzIzMSBzZWN0aW9uIDguMy4xIFsxXSwgdGhlcmUgYXJlIHRoZXNl IHR3byBpdGVtcy4uPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7byAmbmJzcDtXaGV0aGVy IGl0IGlzIGFwcHJvcHJpYXRlIHRvIGxpc3QgdGhlIGZpZWxkLW5hbWUgaW4gdGhlIENvbm5lY3Rp b248YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtoZWFkZXIgZmllbGQg KGkuZS4sIGlmIHRoZSBoZWFkZXIgZmllbGQgaXMgdG8gYmUgaG9wLWJ5LWhvcDsgc2VlPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7U2VjdGlvbiA2LjEgb2YgW1JGQzcy MzBdKS48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtvICZuYnNwO1VuZGVyIHdoYXQgY29u ZGl0aW9ucyBpbnRlcm1lZGlhcmllcyBhcmUgYWxsb3dlZCB0byBpbnNlcnQsPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZGVsZXRlLCBvciBtb2RpZnkgdGhlIGZpZWxk J3MgdmFsdWUuPGJyPg0KPGJyPg0KR2l2ZW4gdGhlIHNwZWNpZmljcyBpbiBbUkZDNzIzMF0gU2Vj dGlvbiA2LjEgWzJdLi48YnI+DQo8YnI+DQombmJzcDsmbmJzcDs2LjEuJm5ic3A7IENvbm5lY3Rp b248YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtUaGUgJnF1b3Q7Q29ubmVjdGlvbiZxdW90 OyBoZWFkZXIgZmllbGQgYWxsb3dzIHRoZSBzZW5kZXIgdG8gaW5kaWNhdGUgZGVzaXJlZDxicj4N CiZuYnNwOyZuYnNwOyZuYnNwO2NvbnRyb2wgb3B0aW9ucyBmb3IgdGhlIGN1cnJlbnQgY29ubmVj dGlvbi4mbmJzcDsgSW4gb3JkZXIgdG8gYXZvaWQ8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtjb25m dXNpbmcgZG93bnN0cmVhbSByZWNpcGllbnRzLCBhIHByb3h5IG9yIGdhdGV3YXkgTVVTVCByZW1v dmUgb3I8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtyZXBsYWNlIGFueSByZWNlaXZlZCBjb25uZWN0 aW9uIG9wdGlvbnMgYmVmb3JlIGZvcndhcmRpbmcgdGhlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 bWVzc2FnZS48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtXaGVuIGEgaGVhZGVyIGZpZWxk IGFzaWRlIGZyb20gQ29ubmVjdGlvbiBpcyB1c2VkIHRvIHN1cHBseSBjb250cm9sPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7aW5mb3JtYXRpb24gZm9yIG9yIGFib3V0IHRoZSBjdXJyZW50IGNvbm5l Y3Rpb24sIHRoZSBzZW5kZXIgTVVTVCBsaXN0PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7dGhlIGNv cnJlc3BvbmRpbmcgZmllbGQtbmFtZSB3aXRoaW4gdGhlIENvbm5lY3Rpb24gaGVhZGVyIGZpZWxk LiAmbmJzcDtBPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7cHJveHkgb3IgZ2F0ZXdheSBNVVNUIHBh cnNlIGEgcmVjZWl2ZWQgQ29ubmVjdGlvbiBoZWFkZXIgZmllbGQgYmVmb3JlPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7YSBtZXNzYWdlIGlzIGZvcndhcmRlZCBhbmQsIGZvciBlYWNoIGNvbm5lY3Rp b24tb3B0aW9uIGluIHRoaXMgZmllbGQsPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7cmVtb3ZlIGFu eSBoZWFkZXIgZmllbGQocykgZnJvbSB0aGUgbWVzc2FnZSB3aXRoIHRoZSBzYW1lIG5hbWUgYXMg dGhlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Y29ubmVjdGlvbi1vcHRpb24sIGFuZCB0aGVuIHJl bW92ZSB0aGUgQ29ubmVjdGlvbiBoZWFkZXIgZmllbGQgaXRzZWxmPGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7KG9yIHJlcGxhY2UgaXQgd2l0aCB0aGUgaW50ZXJtZWRpYXJ5J3Mgb3duIGNvbm5lY3Rp b24gb3B0aW9ucyBmb3IgdGhlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Zm9yd2FyZGVkIG1lc3Nh Z2UpLjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO0hlbmNlLCB0aGUgQ29ubmVjdGlvbiBo ZWFkZXIgZmllbGQgcHJvdmlkZXMgYSBkZWNsYXJhdGl2ZSB3YXkgb2Y8YnI+DQombmJzcDsmbmJz cDsmbmJzcDtkaXN0aW5ndWlzaGluZyBoZWFkZXIgZmllbGRzIHRoYXQgYXJlIG9ubHkgaW50ZW5k ZWQgZm9yIHRoZSBpbW1lZGlhdGU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtyZWNpcGllbnQgKCZx dW90O2hvcC1ieS1ob3AmcXVvdDspIGZyb20gdGhvc2UgZmllbGRzIHRoYXQgYXJlIGludGVuZGVk IGZvciBhbGw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtyZWNpcGllbnRzIG9uIHRoZSBjaGFpbiAo JnF1b3Q7ZW5kLXRvLWVuZCZxdW90OyksIGVuYWJsaW5nIHRoZSBtZXNzYWdlIHRvIGJlPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7c2VsZi1kZXNjcmlwdGl2ZSBhbmQgYWxsb3dpbmcgZnV0dXJlIGNv bm5lY3Rpb24tc3BlY2lmaWMgZXh0ZW5zaW9uczxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO3RvIGJl IGRlcGxveWVkIHdpdGhvdXQgZmVhciB0aGF0IHRoZXkgd2lsbCBiZSBibGluZGx5IGZvcndhcmRl ZCBieTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO29sZGVyIGludGVybWVkaWFyaWVzLjxicj4NCjxi cj4NCi4uaXQgb2ZmaGFuZCBzZWVtcyB0aGF0IG9uZSB3b3VsZCB3YW50IHRvIGxpc3QgJnF1b3Q7 U2VjLVRva2VuLUJpbmRpbmcmcXVvdDsgaW4gdGhlIENvbm5lY3Rpb24gaGVhZGVyIGZpZWxkIGJl Y2F1c2UgU2VjLVRva2VuLUJpbmRpbmcgaXMgb3N0ZW5zaWJseSBhYm91dCB0aGUgY29ubmVjdGlv biBhbmQgaXMgaG9wLWJ5LWhvcCBiZWNhdXNlIFRMUyBpcyBob3AtYnktaG9wLjxicj4NCjxicj4N Ckhvd2V2ZXIsIGdpdmVuIG91ciBjdXJyZW50IHRoaW5raW5nIHdydCBUQiBhbmQgVExTIFRlcm1p bmF0aW5nIFJldmVyc2UgUHJveGllcyBbM10sIHdoZXJlIHdlIGFyZSBjb250ZW1wbGF0aW5nIG9u ZSBhcHByb2FjaCB3aGVyZSBzdWNoICZxdW90O1RUUlBzJnF1b3Q7DQo8YnI+DQpwYXNzLXRocm91 Z2ggdGhlIFNlYy1Ub2tlbi1CaW5kaW5nIGhlYWRlciBmaWVsZCBhbmQgYWRkIGEgY29ycmVzcG9u ZGluZyBUb2tlbi1CaW5kaW5nLUNvbnRleHQgaGVhZGVyLCBvbmUgd291bGQgbm90IHdhbnQgdG8g bGlzdCBTZWMtVG9rZW4tQmluZGluZyBpbiB0aGUgQ29ubmVjdGlvbiBoZWFkZXIgKGJlY2F1c2Ug YSBUVFJQIHdvdWxkIHRoZW4gc3RyaXAgaXQgb2ZmKS4gSG93ZXZlciB0aGVyZSBhcmUgaW1wbGVt ZW50YXRpb24gYW5kIHNlY3VyaXR5DQogY29uc2lkZXJhdGlvbnMgd2l0aCB0aGlzLjxicj4NCjxi cj4NCkFzIG9uZSBwcm9wb3NhbCwgd2UgY291bGQgc2F5IGluIEhUVFBTVEIgc29tZXRoaW5nIGFs b25nIHRoZSBsaW5lcyBvZi4uPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Wy4uLl08YnI+DQombmJz cDsmbmJzcDtDbGllbnRzIFNIT1VMRCBOT1QgbGlzdCB0aGUgU2VjLVRva2VuLUJpbmRpbmcgaGVh ZGVyIGZpZWxkIGFzPGJyPg0KJm5ic3A7Jm5ic3A7YSBjb25uZWN0aW9uIG9wdGlvbiBpbiB0aGUg Q29ubmVjdGlvbiBoZWFkZXIgZmllbGQgKFNlY3Rpb24gNi4xPGJyPg0KJm5ic3A7Jm5ic3A7b2Yg W1JGQzcyMzBdKSBpbiBvcmRlciB0byBnZW5lcmFsbHkgZW5hYmxlIFNlYy1Ub2tlbi1CaW5kaW5n PGJyPg0KJm5ic3A7Jm5ic3A7aGVhZGVyIGZpZWxkIHBhc3MtdGhyb3VnaCBieSBpbnRlcm1lZGlh cmllcywgZS5nLiwgYnkgVExTPGJyPg0KJm5ic3A7Jm5ic3A7dGVybWluYXRpbmcgcmV2ZXJzZSBw cm94aWVzIChUVFJQKS4gSW50ZXJtZWRpYXJpZXMgTVVTVCBOT1Q8YnI+DQombmJzcDsmbmJzcDtt b2RpZnkgdGhlIFNlYy1Ub2tlbi1CaW5kaW5nIGhlYWRlciBmaWVsZCdzIHZhbHVlLiBTZWUgYWxz byB0aGU8YnI+DQombmJzcDsmbmJzcDtzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLjxi cj4NCiZuYnNwOyZuYnNwO1suLi5dPGJyPg0KJm5ic3A7Jm5ic3A7U2VjdXJpdHkgQ29uc2lkZXJh dGlvbnM8YnI+DQombmJzcDsmbmJzcDtbLi4uXTxicj4NCiZuYnNwOyZuYnNwO05vdCBsaXN0aW5n IFNlYy1Ub2tlbi1CaW5kaW5nIGluIHRoZSBDb25uZWN0aW9uIGhlYWRlcjogdGhpczxicj4NCiZu YnNwOyZuYnNwO2VuYWJsZXMgVFRSUHMgdG8gdHJhbnNwYXJlbnRseSBjb252ZXkgdGhlIFNlYy1U b2tlbi1CaW5kaW5nIGhlYWRlcjxicj4NCiZuYnNwOyZuYnNwO2ZpZWxkLCBjb250YWluaW5nIGEg VG9rZW4gQmluZGluZyBNZXNzYWdlLCB0byB0aGUgbmV4dCB0aWVyICgmcXVvdDtiYWNrZW5kPGJy Pg0KJm5ic3A7Jm5ic3A7c2VydmVycyZxdW90OyksIGUuZy4sIHdoZXJlIHNlY3VyaXR5IHRva2Vu cyBjb250YWluaW5nIFRva2VuIEJpbmRpbmcgSURzPGJyPg0KJm5ic3A7Jm5ic3A7bWF5IGJlIG1p bnRlZCBhbmQgdmFsaWRhdGVkLiBUaGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGEgVFRSUCBhbmQ8 YnI+DQombmJzcDsmbmJzcDtiYWNrZW5kIHNlcnZlcnMgbmVlZHMgdG8gYmUgc2VjdXJlZCBhZ2Fp bnN0IGVhdmVzZHJvcHBpbmcgYW5kPGJyPg0KJm5ic3A7Jm5ic3A7bW9kaWZpY2F0aW9uIGJ5IHVu aW50ZW5kZWQgcGFydGllcy4gVGhlIFRva2VuIEJpbmRpbmcgTWVzc2FnZSBpdHNlbGY8YnI+DQom bmJzcDsmbmJzcDttYXkgYmUgdmFsaWRhdGVkIGJ5IHRoZSBUVFJQIG9yIGJ5IGEgYmFja2VuZCBz ZXJ2ZXIuIFRob3VnaCwgaW4gdGhlPGJyPg0KJm5ic3A7Jm5ic3A7bGF0dGVyIGNhc2UsIHRoZSBk YXRhIG5lY2Vzc2FyeSB0byBwZXJmb3JtIHN1Y2ggdmFsaWRhdGlvbiAoaS5lLiwgdGhlPGJyPg0K Jm5ic3A7Jm5ic3A7RUtNLCBldGMuKSBuZWVkcyB0byBiZSBjb252ZXllZCB0byB0aGUgZW50aXR5 IHBlcmZvcm1pbmcgaXQuIFN1Y2g8YnI+DQombmJzcDsmbmJzcDtjb252ZXlhbmNlIGlzIG91dCBv ZiBzY29wZSBmb3IgdGhpcyBzcGVjaWZpY2F0aW9uLjxicj4NCjxicj4NCiZuYnNwOyZuYnNwO0xp c3RpbmcgU2VjLVRva2VuLUJpbmRpbmcgaW4gdGhlIENvbm5lY3Rpb24gaGVhZGVyOiBpZiBkb25l LCB0aGlzPGJyPg0KJm5ic3A7Jm5ic3A7bWF5IGhlbHAgaW4gZW5zdXJpbmcgdGhhdCBUb2tlbiBC aW5kaW5nIElEcyBhcmUgbm90IGluYWR2ZXJ0ZW50bHk8YnI+DQombmJzcDsmbmJzcDtyZXZlYWxl ZCB0byB1bmludGVuZGVkIHBhcnRpZXMsIHRob3VnaCBtYXkgY2F1c2UgZGlmZmljdWx0aWVzIHdp dGg8YnI+DQombmJzcDsmbmJzcDt3ZWIgc2l0ZXMgZW1wbG95aW5nIFRUUlBzLjxicj4NCiZuYnNw OyZuYnNwO1suLi5dPGJyPg0KPGJyPg0KT3IsIHdlIGNvdWxkIGp1c3Qgc2F5ICZxdW90O2NsaWVu dHMgU0hPVUxEIGxpc3QgdGhlIFNlYy1Ub2tlbi1CaW5kaW5nIGhlYWRlciBmaWVsZCBhcyBhIGNv bm5lY3Rpb24gb3B0aW9uIGluIHRoZSBDb25uZWN0aW9uIGhlYWRlciBmaWVsZCZxdW90OywgYnV0 IHRoYXQgd2lsbCBjcmVhdGUgcHJvYmxlbXMgZm9yIFRUUlBzIFszXS48YnI+DQo8YnI+DQpPciwg d2UgY2FuIGp1c3Qgbm90IG1lbnRpb24gdGhlIENvbm5lY3Rpb24gaGVhZGVyIGFuZCBzZWUgaWYg YW55b25lIHJhaXNlcyBxdWVzdGlvbnMgYWJvdXQgaXQgZHVyaW5nIGZ1cnRoZXIgV0cgYW5kIElF VEYtd2lkZSByZXZpZXcuPGJyPg0KPGJyPg0KdGhvdWdodHM/PGJyPg0KPGJyPg0KWzFdICZsdDs8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzIzMSNzZWN0aW9uLTguMy4x IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyMzEjc2Vj dGlvbi04LjMuMTwvYT4mZ3Q7PGJyPg0KPGJyPg0KWzJdICZsdDs8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNzIzMCNzZWN0aW9uLTYuMSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjMwI3NlY3Rpb24tNi4xPC9hPiZndDs8YnI+ DQo8YnI+DQpbM10gJmx0OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1jYW1wYmVsbC10b2tiaW5kLXRscy10ZXJtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLXRva2JpbmQtdGxzLXRlcm08L2E+Jmd0Ozxi cj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 VW5iZWFyYWJsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlVuYmVhcmFibGVAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91 bmJlYXJhYmxlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby91bmJlYXJhYmxlPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlVu YmVhcmFibGVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpVbmJlYXJhYmxl QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Vu YmVhcmFibGU8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR0301MB08423324E89771A0EEDD72068C420CY1PR0301MB0842_-- From nobody Thu Feb 9 07:55:59 2017 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 C1EF2129AF2 for ; Thu, 9 Feb 2017 07:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=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 eamxf5f1oAKf for ; Thu, 9 Feb 2017 07:55:57 -0800 (PST) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 2FE281296C4 for ; Thu, 9 Feb 2017 07:55:57 -0800 (PST) Received: (qmail 15772 invoked by uid 0); 9 Feb 2017 15:55:56 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy2.mail.unifiedlayer.com with SMTP; 9 Feb 2017 15:55:56 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id ifvs1u00b2UhLwi01fvve5; Thu, 09 Feb 2017 08:55:56 -0700 X-Authority-Analysis: v=2.1 cv=Pets2ERd 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=n2v9WMKugxEA:10 a=NEAV23lmAAAA:8 a=LaE38y510AhqUo1Keb4A:9 a=QEXdDO2ut3YA:10 a=Bn2pgwyD2vrAyMmN8A2t:22 Received: from [173.224.162.69] (port=58448 helo=[10.225.80.61]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cbr4a-0001Gx-BM for unbearable@ietf.org; Thu, 09 Feb 2017 08:55:52 -0700 To: IETF TokBind WG From: =JeffH Message-ID: <074faef6-b425-17f8-ac05-223834a2cc0b@KingsMountain.com> Date: Thu, 9 Feb 2017 07:55:51 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 173.224.162.69 X-Exim-ID: 1cbr4a-0001Gx-BM X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.225.80.61]) [173.224.162.69]:58448 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 1 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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: Thu, 09 Feb 2017 15:55:59 -0000 Dirk wrote: > > [...] > - If the proxy has some sort of arrangement with the downstream > server that it's supposed to communicate the Token Binding > information (like a TTRP would), it has a two options: > > * verify the Token Binding information and forward just the Token > Binding ID to the downstream server (using some mechanism proprietary > to the proxy and downstream server). > > * forward the Sec-Token-Binding header, and (using some mechanism > proprietary to the proxy and downstream server) the EKM information, > to the downstream server. > > If the proxy has qualms about violating the spec by forwarding the > Sec-Token-Binding header despite its being listed in the Connect > header, it can always just use a different header name, like > "Private-Forwarded-Token-Binding", or whatever - some mechanism > proprietary to the proxy and downstream server. > [...] Andrei wrote: > > …but in the case of the Sec-Token-Binding header, the client does not know whether it makes > sense to forward or not. > > The client, generally, does not know whether the proxy or TLS > terminator validates bindings, passes them along for the application > server to validate, or strips them altogether. johnB wrote: > > I suspect the only place we really run into a conflict is in Brian's > draft by re using/maintaining the Sec-Token-Binding header. > > As Dirk points out that draft could move the info in the > Sec-Token-Binding header to a different header if it is listed in the > Connect header, or always just use a different header name. Yep. > That can be debated as part of the reverse proxy spec. Agreed. This cleanly separates things. Dirk also wrote: > > to me it seems that listing it in the Connect header is the > right answer I agree with this for security considerations reasons -- we want the Sec-Token-Binding header to be hop-by-hop in sync with the underlying TLS connection and not be "leaked" downstream unless it is a conscious decision, e.g., in the tls terminating reverse proxy (TTRP) case. I will update PR #94 accordingly there's also another issue with PR #94 that's being discussed in the PR that I'll bring here to the list in a subsequent msg. =JeffH From nobody Thu Feb 9 08:38:14 2017 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 61A67129BD4 for ; Thu, 9 Feb 2017 08:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 MFgIAmVa-GoF for ; Thu, 9 Feb 2017 08:38:11 -0800 (PST) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::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 68B56129BD2 for ; Thu, 9 Feb 2017 08:38:11 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id w194so2957881ybe.0 for ; Thu, 09 Feb 2017 08:38:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zoR6dSADKNSHT2B2Yb2ULJuFdo0vHJH4tpTK5bkwfb0=; b=FGvFP0FSZBSuC/k+nxcgKOcgxZa/zlAmodMK3dAw4Vk9M7v8t9pxl0vKEYYA6Xo+me yw7Y1lSmuqoYxgmufdghGs3uFauy/p3425Nutibvbz9RL95NN61IfQHMjtJ3lY9ycPXm /bWue3htAFIA3xpI6nyhNlBZ7kQmWbKil5vGg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zoR6dSADKNSHT2B2Yb2ULJuFdo0vHJH4tpTK5bkwfb0=; b=MhxkXQwfTtnPvkfETswgL4WXN3b1b3b/IUQZTVVq9/J0VOlJkkLZPMvwhHKvLc3MKz yHeCSZf99ULj3LbqBXfjisQINhKuEZfSjjdkV1ptrG9HaQtTSWrjSotCtACVVCCJ82eR dtAVQELDeC7g7KJ3eMap0nm5ygcZ0vAdBdkJFVMFIJsJADP52otFLWykkCtYVk0+LbBK P4ZuocU+nwUeXqTpeCpOCz9VyOWgsNbBzrFnYabsbWdRsP5Ze45oofL9Qd6991o1qzJW vIbE3+rpOWcokW+G16x337vlYMBgCOw7LR2qRRfT8nqR4WrHmMvxM6jRnZbFb+CqJDgr H57g== X-Gm-Message-State: AMke39msprO45AP+K7CUZzym4nXX3Np0al+Qbp/TsEHaVJsgNRzabJMDD3q6BYphBvGJuMS6o3RP7c4fd1EIJ6aO X-Received: by 10.37.170.137 with SMTP id t9mr2935603ybi.145.1486658290469; Thu, 09 Feb 2017 08:38:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.126.131 with HTTP; Thu, 9 Feb 2017 08:37:40 -0800 (PST) In-Reply-To: <074faef6-b425-17f8-ac05-223834a2cc0b@KingsMountain.com> References: <074faef6-b425-17f8-ac05-223834a2cc0b@KingsMountain.com> From: Brian Campbell Date: Thu, 9 Feb 2017 10:37:40 -0600 Message-ID: To: "=JeffH" Content-Type: multipart/alternative; boundary=94eb2c19afdc4eaed505481b9b71 Archived-At: Cc: IETF TokBind WG Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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: Thu, 09 Feb 2017 16:38:12 -0000 --94eb2c19afdc4eaed505481b9b71 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 9, 2017 at 9:55 AM, =JeffH wrote: > > I agree with this for security considerations reasons -- we want the > Sec-Token-Binding header to be hop-by-hop in sync with the underlying TLS > connection and not be "leaked" downstream unless it is a conscious > decision, e.g., in the tls terminating reverse proxy (TTRP) case. > > But the client is only making a connection to a server and client does not know whether it makes sense for that server to forward or not. And it shouldn't know that. Sec-Token-Binding shouldn't be listed in Connection header field by a client. --94eb2c19afdc4eaed505481b9b71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 9, 2017 at 9:55 AM, =3DJeffH <Jeff.Hodges@kin= gsmountain.com> wrote:

 I agree with this for security considerations reasons -- we want the Sec-To= ken-Binding header to be hop-by-hop in sync with the underlying TLS connect= ion and not be "leaked" downstream unless it is a conscious decis= ion, e.g., in the tls terminating reverse proxy (TTRP) case.


But the client is only making a connection to a s= erver and client does not know whether it makes sense for that server to fo= rward or not. And it shouldn't know that.=C2=A0 Sec-Token-Binding shoul= dn't be listed in Connection header field by a client.
= =C2=A0
--94eb2c19afdc4eaed505481b9b71-- From nobody Thu Feb 9 09:05:51 2017 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 E511B129C01 for ; Thu, 9 Feb 2017 09:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=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 yLf8M6Yiple8 for ; Thu, 9 Feb 2017 09:05:41 -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 975F2129F34 for ; Thu, 9 Feb 2017 09:05:40 -0800 (PST) Received: (qmail 1823 invoked by uid 0); 9 Feb 2017 17:05:40 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 9 Feb 2017 17:05:40 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id ih4a1u0142UhLwi01h4d8V; Thu, 09 Feb 2017 10:04:38 -0700 X-Authority-Analysis: v=2.1 cv=WOnsABcR 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=n2v9WMKugxEA:10 a=48vgC7mUAAAA:8 a=d5h6PwwjwPkCndJaT-EA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 Received: from [173.224.162.69] (port=10931 helo=[10.225.80.61]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cbs94-0005CC-35 for unbearable@ietf.org; Thu, 09 Feb 2017 10:04:34 -0700 To: IETF TokBind WG From: =JeffH Message-ID: <935ac509-1e0f-3fed-0239-04cf390ef2ce@KingsMountain.com> Date: Thu, 9 Feb 2017 09:04:33 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 173.224.162.69 X-Exim-ID: 1cbs94-0005CC-35 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.225.80.61]) [173.224.162.69]:10931 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 1 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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: Thu, 09 Feb 2017 17:05:45 -0000 >> I agree with this for security considerations reasons -- we want >> the Sec-Token-Binding header to be hop-by-hop in sync with the >> underlying TLS connection and not be "leaked" downstream unless it >> is a conscious decision, e.g., in the tls terminating reverse proxy >> (TTRP) case. >> >> > But the client is only making a connection to a server and client > does not know whether it makes sense for that server to forward or > not. And it shouldn't know that. correct, agreed. > Sec-Token-Binding shouldn't be listed in Connection header field by > a client. listing Sec-Token-Binding in the Connection header means ([RFC7230] Section 6.1).. 6.1. Connection The "Connection" header field allows the sender to indicate desired control options for the current connection. In order to avoid confusing downstream recipients, a proxy or gateway MUST remove or replace any received connection options before forwarding the message. ..which is what we want by default for security considerations reasons, I think. As Dirk noted: > > If the proxy has qualms about violating the spec by forwarding the > Sec-Token-Binding header despite its being listed in the Connect > header, it can always just use a different header name, like > "Private-Forwarded-Token-Binding", or whatever - some mechanism > proprietary to the proxy and downstream server. Thus, a comment on (which i'll endeavor to write up more fully anon) is that it should either define another header field for conveyance of the EncodedTokenBindingMessage (along with the header field it already defines) or have the header field it already defines convey both the EncodedTokenBindingMessage and the EKM et al. =JeffH From nobody Thu Feb 9 10:18:23 2017 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 065D8129C46 for ; Thu, 9 Feb 2017 10:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRU_tdBuTPKu for ; Thu, 9 Feb 2017 10:18:19 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0101.outbound.protection.outlook.com [104.47.33.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76417127076 for ; Thu, 9 Feb 2017 10:18:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oqB28gg8kZENSk37kAz35H5XQL8u3ZdgvlMtFKgxrk0=; b=kv3MuPBt68BeGjlbefyJ1D3SIztUPSvemjrroaW9G8ttBTJJCzXa5xDtXv/sYc++h3MZ1OQ24IUGkRg+ik1D6/s7oKGAz8NbOVXNeqmUt3R98x7JiVdeUw7Ons2GD/Q+mBCI0qTTwLwch31LiRHy4SgtTFM2tgMIHaRs33mLZKo= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 9 Feb 2017 18:18:17 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.026; Thu, 9 Feb 2017 18:18:17 +0000 From: Andrei Popov To: =JeffH , IETF TokBind WG Thread-Topic: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? Thread-Index: AQHSgvaVoAIXC6BWu0OMPbiyGCJ7xqFg+h3w Date: Thu, 9 Feb 2017 18:18:17 +0000 Message-ID: References: <935ac509-1e0f-3fed-0239-04cf390ef2ce@KingsMountain.com> In-Reply-To: <935ac509-1e0f-3fed-0239-04cf390ef2ce@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: 09caef47-3629-4634-78d5-08d45118055e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0842; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 7:kvkg8QHWZskgTKNHmiuthTs6W1fncgHDRTQ81UIzPgy4v3e58XoZUeuT4aBth0uyefDAGxuO8bh3hFEFamUsehW07bVacclrUPDpp7l4AX4RGKTfT2Xxejb6YtyFhr9PjUv2D7W60MVBDvRvwIA1x2NJlD2AU5zV2PU4CCXLQXGPmKugJp/ZFv8lCkLqd7P+Vtgo2BisEUuNOjW1g0Kp7d5q+7+P34znDLnHAU1zrmgFf+Sh1gCGA3UzWJx9SxVwvZzHbbkxZ4ljPq/NLQek/cX2cb4zce63UUk619TjUHHgSH/O8q1wy/1Uc+FsylwqMD88VVsQHHmBHgtF4Q/I82+CP1RoFssY25psTUuxFFjlbp5Q1YPr/v1fNIVL0P1zPNBemEdb63An/a0R8NlxRSVgc6XFclNdmxNAOZS3WmrCL/z0rpOsv2Ca+c80c+OQ40F+dI2KHLOoJ/vT+wxwoKtZbFhqK+6oLdwfLIzPYiG6iEFszVlvIppUUK7tP3c/dg+5OLKWYJJ7WRoxKV7v7I2jrb/m9jQTx5w+z5o4eq8= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(788757137089)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123558025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39450400003)(39410400002)(39850400002)(39860400002)(377454003)(199003)(189002)(13464003)(55016002)(6306002)(6506006)(25786008)(33656002)(6436002)(3280700002)(2906002)(81166006)(101416001)(5660300001)(106116001)(53936002)(92566002)(86362001)(99286003)(10090500001)(229853002)(6246003)(77096006)(86612001)(97736004)(5005710100001)(305945005)(9686003)(8936002)(54356999)(76176999)(230783001)(8676002)(50986999)(106356001)(68736007)(122556002)(10290500002)(102836003)(189998001)(6116002)(81156014)(105586002)(7736002)(7696004)(3660700001)(8990500004)(2900100001)(38730400002)(74316002)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 09 Feb 2017 18:18:17.5493 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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: Thu, 09 Feb 2017 18:18:22 -0000 Hi Jeff, If you agree that the client, generally, does not know whether the proxy/TL= S terminator validates TB or passes it on to the back-end server, then why = do you argue that the client should require the proxy to drop TB headers? I= believe the client should not interfere with this and let datacenter infra= structure figure out how/where to handle TB headers. > ..which is what we want by default for security considerations reasons, I= think. Sorry, what security considerations reasons are you referring to? Cheers, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of =3DJeffH Sent: Thursday, February 9, 2017 9:05 AM To: IETF TokBind WG Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connect= ion header field? >> I agree with this for security considerations reasons -- we want >> th= e Sec-Token-Binding header to be hop-by-hop in sync with the >> underlying= TLS connection and not be "leaked" downstream unless it >> is a conscious= decision, e.g., in the tls terminating reverse proxy >> (TTRP) case. >> >> > But the client is only making a connection to a server and client > doe= s not know whether it makes sense for that server to forward or > not. And= it shouldn't know that. correct, agreed. > Sec-Token-Binding shouldn't be listed in Connection header field by > a= client. listing Sec-Token-Binding in the Connection header means ([RFC7230] Section= 6.1).. 6.1. Connection The "Connection" header field allows the sender to indicate desired control options for the current connection. In order to avoid confusing downstream recipients, a proxy or gateway MUST remove or replace any received connection options before forwarding the message. ..which is what we want by default for security considerations reasons, I t= hink. As Dirk noted: > > If the proxy has qualms about violating the spec by forwarding the > Sec-Token-Binding header despite its being listed in the Connect > header, it can always just use a different header name, like > "Private-Forwarded-Token-Binding", or whatever - some mechanism > proprietary to the proxy and downstream server. Thus, a comment on (which i'll e= ndeavor to write up more fully anon) is that it should either define anothe= r header field for conveyance of the EncodedTokenBindingMessage (along with= the header field it already defines) or have the header field it already defines convey both the Encode= dTokenBindingMessage and the EKM et al. =3DJeffH _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable From nobody Thu Feb 9 10:25:48 2017 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 8D8B5129444 for ; Thu, 9 Feb 2017 10:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBD9LM2Uq4es for ; Thu, 9 Feb 2017 10:25:44 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0104.outbound.protection.outlook.com [104.47.38.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 A3107129412 for ; Thu, 9 Feb 2017 10:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Fc8mCdR3MlkHBJOL5VwhXMbaupo1HArcfQR0XjM8G8c=; b=FhHw/CLihnMhar76iMrJwchvnA2b7tJgukhQ1ialU0epSb2vcXAWWd8X6gmJ6svLRpHiczxQfbQ20lsiM6k6F1B8IvAPCXt9Skb1dEwNxZ3KgKxKSvuLj0WZsFFHPqz7jax1v6OEOd17QrkMrfvdqIQ9IDH602X5z3lzQCI96fk= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0844.namprd03.prod.outlook.com (10.160.163.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 9 Feb 2017 18:25:40 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.026; Thu, 9 Feb 2017 18:25:40 +0000 From: Andrei Popov To: Brian Campbell , =JeffH Thread-Topic: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? Thread-Index: AQHSguz8oAIXC6BWu0OMPbiyGCJ7xqFg384AgAAczHA= Date: Thu, 9 Feb 2017 18:25:40 +0000 Message-ID: References: <074faef6-b425-17f8-ac05-223834a2cc0b@KingsMountain.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: b4899b2e-5de9-4e4c-3a4b-08d451190d76 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0844; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 7:D1P2xRvovJQ4gwRMjxiTBnr3zfSktK6CE4t8VwjY6WbG8k3lpY4YPb2cl0sBXQZH6FiTOtcF0hnBGmnP96zH5kBLpABK8vAPST+AO8uD+AHlieDE6ox9PcvktBr0FppnBBBcZb8wjUHUfLjOmHUYcydGfShoqmEPcJsNa00/PrHuuko5SZMRZGTwO1CMrl7lOpHRurLQRkw7W59hExPnEJozV/ipNxAkZtKle6BOux+R7sE4kdZ+mNbjDOvIpOQgYsonIA7xQQyfmNxn1Cp2i3za+S03pENQN//55NVDRT4UCKBOw6GA7sDwXkr9eqhQKIBzGUf394EcU+E6gQsS89gYUpjcOQKCXx+zPzG2IxZdN2Hols3ln15Z9er9nZ8xyrpvcE4NQGCj5gUyjTTocXnOKfzmI9VRrGODDC+XIw9RNV4IHmp3unqG3ry3ounJG92BkzurGvWYwNJhgBEyr5JO1x0Hf/KlzC5wQBN9Lfw8Zwr20se5aILU2/E5Y06GF8MhNsVmr7vQcPzdgfYC76WXyduv6BebV3HdQmNuD/w= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123558025)(20161123560025)(20161123555025)(20161123562025)(6072148)(6042181); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(24454002)(189002)(199003)(106116001)(4326007)(105586002)(3660700001)(77096006)(5005710100001)(7736002)(10290500002)(122556002)(6246003)(102836003)(6116002)(99286003)(229853002)(19609705001)(9686003)(790700001)(55016002)(74316002)(25786008)(6506006)(6436002)(68736007)(86612001)(54896002)(6306002)(86362001)(50986999)(76176999)(54356999)(92566002)(53936002)(81166006)(3280700002)(2900100001)(81156014)(101416001)(7696004)(230783001)(236005)(8676002)(8936002)(106356001)(2950100002)(8990500004)(38730400002)(97736004)(33656002)(2906002)(5660300001)(189998001)(10090500001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0844; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB084223E0274288D9B330D16D8C450CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2017 18:25:40.5184 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0844 Archived-At: Cc: IETF TokBind WG Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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: Thu, 09 Feb 2017 18:25:46 -0000 --_000_CY1PR0301MB084223E0274288D9B330D16D8C450CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXhhY3RseSwgSSBhZ3JlZSB3aXRoIEJyaWFuLiBUaGUgcHJveHkvdGVybWluYXRvciBpcyBiZXR0 ZXIgcG9zaXRpb25lZCB0byBrbm93IGhvdy93aGVyZSBUQiBoZWFkZXJzIGFyZSBoYW5kbGVkIGlu IGEgcGFydGljdWxhciBkYXRhY2VudGVyLiBBbmQgYSBwcm94eS90ZXJtaW5hdG9yIHRoYXQga25v d3Mgbm90aGluZyBhYm91dCBUQiBoZWFkZXJzIHNob3VsZCBmb3J3YXJkIHRoZW0gb24uDQoNCkZy b206IFVuYmVhcmFibGUgW21haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDksIDIwMTcg ODozOCBBTQ0KVG86ID1KZWZmSCA8SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20+DQpDYzog SUVURiBUb2tCaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtVbmJl YXJhYmxlXSBvbiBub3QgbGlzdGluZyAnU2VjLVRva2VuLUJpbmRpbmcnIGluIHRoZSBDb25uZWN0 aW9uIGhlYWRlciBmaWVsZD8NCg0KDQoNCk9uIFRodSwgRmViIDksIDIwMTcgYXQgOTo1NSBBTSwg PUplZmZIIDxKZWZmLkhvZGdlc0BraW5nc21vdW50YWluLmNvbTxtYWlsdG86SmVmZi5Ib2RnZXNA a2luZ3Ntb3VudGFpbi5jb20+PiB3cm90ZToNCg0KSSBhZ3JlZSB3aXRoIHRoaXMgZm9yIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIHJlYXNvbnMgLS0gd2Ugd2FudCB0aGUgU2VjLVRva2VuLUJpbmRp bmcgaGVhZGVyIHRvIGJlIGhvcC1ieS1ob3AgaW4gc3luYyB3aXRoIHRoZSB1bmRlcmx5aW5nIFRM UyBjb25uZWN0aW9uIGFuZCBub3QgYmUgImxlYWtlZCIgZG93bnN0cmVhbSB1bmxlc3MgaXQgaXMg YSBjb25zY2lvdXMgZGVjaXNpb24sIGUuZy4sIGluIHRoZSB0bHMgdGVybWluYXRpbmcgcmV2ZXJz ZSBwcm94eSAoVFRSUCkgY2FzZS4NCg0KQnV0IHRoZSBjbGllbnQgaXMgb25seSBtYWtpbmcgYSBj b25uZWN0aW9uIHRvIGEgc2VydmVyIGFuZCBjbGllbnQgZG9lcyBub3Qga25vdyB3aGV0aGVyIGl0 IG1ha2VzIHNlbnNlIGZvciB0aGF0IHNlcnZlciB0byBmb3J3YXJkIG9yIG5vdC4gQW5kIGl0IHNo b3VsZG4ndCBrbm93IHRoYXQuICBTZWMtVG9rZW4tQmluZGluZyBzaG91bGRuJ3QgYmUgbGlzdGVk IGluIENvbm5lY3Rpb24gaGVhZGVyIGZpZWxkIGJ5IGEgY2xpZW50Lg0KDQo= --_000_CY1PR0301MB084223E0274288D9B330D16D8C450CY1PR0301MB0842_ 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 IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkV4YWN0bHksIEkgYWdyZWUgd2l0aCBCcmlhbi4gVGhlIHBy b3h5L3Rlcm1pbmF0b3IgaXMgYmV0dGVyIHBvc2l0aW9uZWQgdG8ga25vdyBob3cvd2hlcmUgVEIg aGVhZGVycyBhcmUgaGFuZGxlZCBpbiBhIHBhcnRpY3VsYXIgZGF0YWNlbnRlci4gQW5kIGEgcHJv eHkvdGVybWluYXRvciB0aGF0IGtub3dzDQogbm90aGluZyBhYm91dCBUQiBoZWFkZXJzIHNob3Vs ZCBmb3J3YXJkIHRoZW0gb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBVbmJlYXJhYmxlIFttYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBDYW1wYmVsbDxicj4NCjxiPlNlbnQ6PC9i PiBUaHVyc2RheSwgRmVicnVhcnkgOSwgMjAxNyA4OjM4IEFNPGJyPg0KPGI+VG86PC9iPiA9SmVm ZkggJmx0O0plZmYuSG9kZ2VzQGtpbmdzbW91bnRhaW4uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4g SUVURiBUb2tCaW5kIFdHICZsdDt1bmJlYXJhYmxlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW1VuYmVhcmFibGVdIG9uIG5vdCBsaXN0aW5nICdTZWMtVG9rZW4tQmluZGlu ZycgaW4gdGhlIENvbm5lY3Rpb24gaGVhZGVyIGZpZWxkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFRodSwgRmViIDksIDIwMTcgYXQgOTo1NSBBTSwgPUplZmZIICZsdDs8YSBocmVmPSJt YWlsdG86SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20iIHRhcmdldD0iX2JsYW5rIj5KZWZm LkhvZGdlc0BraW5nc21vdW50YWluLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KSSBhZ3JlZSB3aXRoIHRoaXMgZm9yIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IHJlYXNvbnMgLS0gd2Ugd2FudCB0aGUgU2VjLVRva2VuLUJpbmRpbmcgaGVhZGVyIHRvIGJlIGhv cC1ieS1ob3AgaW4gc3luYyB3aXRoIHRoZSB1bmRlcmx5aW5nIFRMUyBjb25uZWN0aW9uIGFuZCBu b3QgYmUgJnF1b3Q7bGVha2VkJnF1b3Q7IGRvd25zdHJlYW0gdW5sZXNzIGl0IGlzIGEgY29uc2Np b3VzIGRlY2lzaW9uLCBlLmcuLCBpbiB0aGUgdGxzIHRlcm1pbmF0aW5nIHJldmVyc2UNCiBwcm94 eSAoVFRSUCkgY2FzZS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCB0aGUgY2xpZW50IGlzIG9ubHkgbWFraW5nIGEgY29ubmVj dGlvbiB0byBhIHNlcnZlciBhbmQgY2xpZW50IGRvZXMgbm90IGtub3cgd2hldGhlciBpdCBtYWtl cyBzZW5zZSBmb3IgdGhhdCBzZXJ2ZXIgdG8gZm9yd2FyZCBvciBub3QuIEFuZCBpdCBzaG91bGRu J3Qga25vdyB0aGF0LiZuYnNwOyBTZWMtVG9rZW4tQmluZGluZyBzaG91bGRuJ3QgYmUgbGlzdGVk IGluIENvbm5lY3Rpb24gaGVhZGVyIGZpZWxkIGJ5IGENCiBjbGllbnQuIDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_CY1PR0301MB084223E0274288D9B330D16D8C450CY1PR0301MB0842_-- From nobody Thu Feb 9 10:40:46 2017 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 6A4C712958C for ; Thu, 9 Feb 2017 10:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 JJVqNGvsYHFv for ; Thu, 9 Feb 2017 10:40:43 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 2EF71129583 for ; Thu, 9 Feb 2017 10:40:43 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id w20so12631605qtb.1 for ; Thu, 09 Feb 2017 10:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=P9aY3icpjdjhnUDD64WJ5+n6seLd1Jrk4r+OkJ+2AhE=; b=XtmUI0LQcC6f8IPsxPzVsy2ZX0EDqvgiUDKe3MoZJQ4xNiBoYRiLtQpYRwMnittbDh GrF3A8AZcdH15JUStDW4sMtBWDKNvxxAnP/74uKb/eyfeG4N8kP06AS5LcxxFUHPW2ux IRi1GFads4PBCd0ZciTZo25Ps3Ds95Jkzhy+Nc4RoWPvWCGMEG2BP+YSqPOR9rFbpUmo 2N9s89Z4bdlbgXjkI3uBZfFgbVCosi5MN0QocNClyyuMz8Ehb7VrQZQ9Zy8mlQ2Pv3T9 kYeKJWNjOqHwTDPtCFxPhzix0EfoGT0ChSUZSHIO8QRkGmvdSkvi+E5I9nHwKmFAbVtm Vazw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=P9aY3icpjdjhnUDD64WJ5+n6seLd1Jrk4r+OkJ+2AhE=; b=Ks4xqH0R817/peEw4F/BMUHd2zlOpa9SzqD6hdteAKUqvNgdjkIxofzG1LVlYuDS87 M4dSrvgSABtPmcSZxba8yQzzdl9j/87zPY3dkkKTCff6hvOl4q47dV0qTEPiRgVJWHss 7O02Z+zGFwaARJEsKZ9WZtSMgitwEIZra7wpwiXPXW8G0tfs2fjoZykgf/h/FH4WpCaw hNsHUAe42WYItpCc6NWzMfER31MWdNjhdoQo3ubceO773NHbb9jXFH16BFK/Lot59EVn xHztKyMwNzBlkdiQgVDV3L2Xxdh1gQnDWqaO7QN6WnLBUnMxDrzkX2p9Vge748PIkWkG VlHw== X-Gm-Message-State: AMke39mEh5EZarDs3xNKbCc2+ioWJa4/O5aWkxEub8AULzRzjAsVPHWXhTqubVLvlq3wIXTq X-Received: by 10.200.37.199 with SMTP id f7mr4443203qtf.186.1486665642039; Thu, 09 Feb 2017 10:40:42 -0800 (PST) Received: from [192.168.8.100] ([181.201.209.140]) by smtp.gmail.com with ESMTPSA id f126sm9837963qkc.47.2017.02.09.10.40.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 10:40:41 -0800 (PST) From: John Bradley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_56366F2F-30DF-4916-A28E-FFB6EC9F62CC"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Feb 2017 15:40:37 -0300 In-Reply-To: To: Andrei Popov References: <074faef6-b425-17f8-ac05-223834a2cc0b@KingsMountain.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF TokBind WG , Brian Campbell , =JeffH Hodges Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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: Thu, 09 Feb 2017 18:40:45 -0000 --Apple-Mail=_56366F2F-30DF-4916-A28E-FFB6EC9F62CC Content-Type: multipart/alternative; boundary="Apple-Mail=_0E847F11-9C89-46AB-8FAC-5A46C8A904B3" --Apple-Mail=_0E847F11-9C89-46AB-8FAC-5A46C8A904B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That may be the rub. =46rom a header perspective we are talking about any proxy forward and = reverse. I dont know that a proxy that doesn=E2=80=99t understand token binding = should forward the header especially in the forward case. What if the forward proxy is negotiating it=E2=80=99s own token binding = to the server? (should a forward proxy proxy do that is perhaps another = question) I understand the desire to pass the header on in the reverse proxy case = as it may make server code easier. However I take Jeff=E2=80=99s point that token binding is by its nature = hop by hop and if we mess with that we may get some unintended side = effects. If Brian had proposed sticking everything in one or two new headers and = removing the existing one then this would be much less controversial. I always thought that we could use the same header on the inside of the = proxy, but can see why that might mess up some other expectations. So is token binding hop by hop? John B. > On Feb 9, 2017, at 3:25 PM, Andrei Popov = wrote: >=20 > Exactly, I agree with Brian. The proxy/terminator is better positioned = to know how/where TB headers are handled in a particular datacenter. And = a proxy/terminator that knows nothing about TB headers should forward = them on. > =20 > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of = Brian Campbell > Sent: Thursday, February 9, 2017 8:38 AM > To: =3DJeffH > Cc: IETF TokBind WG > Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the = Connection header field? > =20 > =20 > =20 > On Thu, Feb 9, 2017 at 9:55 AM, =3DJeffH = > = wrote: >=20 > I agree with this for security considerations reasons -- we want the = Sec-Token-Binding header to be hop-by-hop in sync with the underlying = TLS connection and not be "leaked" downstream unless it is a conscious = decision, e.g., in the tls terminating reverse proxy (TTRP) case. >=20 > =20 > But the client is only making a connection to a server and client does = not know whether it makes sense for that server to forward or not. And = it shouldn't know that. Sec-Token-Binding shouldn't be listed in = Connection header field by a client.=20 > =20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_0E847F11-9C89-46AB-8FAC-5A46C8A904B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That may be the rub.

=46rom a header perspective we are talking about any proxy = forward and reverse.

I dont know that a proxy that doesn=E2=80=99t understand = token binding should forward the header especially in the forward = case.

What if = the forward proxy is negotiating it=E2=80=99s own token binding  to = the server?  (should a forward proxy proxy do that is perhaps = another question)

I understand the desire to pass the header on in the reverse = proxy case as it may make server code easier.

However I take Jeff=E2=80=99s point = that token binding is by its nature hop by hop and if we mess with that = we may get some unintended side effects.

If Brian had proposed sticking = everything in one or two  new headers and removing the existing one = then this would be much less controversial.

I always thought that we could use the = same header on the inside of the proxy, but can see why that might mess = up some other expectations.

So is token binding hop by hop?

John B.

On = Feb 9, 2017, at 3:25 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

Exactly, I agree with Brian. The proxy/terminator is better = positioned to know how/where TB headers are handled in a particular = datacenter. And a proxy/terminator that knows nothing about TB headers = should forward them on.
 
From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf = Of Brian = Campbell
Sent: Thursday, February 9, 2017 = 8:38 AM
To: =3DJeffH <Jeff.Hodges@kingsmountain.com>
Cc: IETF = TokBind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] on not = listing 'Sec-Token-Binding' in the Connection header field?
 
 
 
On Thu, Feb 9, 2017 = at 9:55 AM, =3DJeffH <Jeff.Hodges@kingsmountain.com> wrote:


I = agree with this for security considerations reasons -- we want the = Sec-Token-Binding header to be hop-by-hop in sync with the underlying = TLS connection and not be "leaked" downstream unless it is a conscious = decision, e.g., in the tls terminating reverse proxy (TTRP) case.

 
But the client is = only making a connection to a server and client does not know whether it = makes sense for that server to forward or not. And it shouldn't know = that.  Sec-Token-Binding shouldn't be listed in Connection header = field by a client. 
 
_______________________________________________
Unbearable mailing = list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable

= --Apple-Mail=_0E847F11-9C89-46AB-8FAC-5A46C8A904B3-- --Apple-Mail=_56366F2F-30DF-4916-A28E-FFB6EC9F62CC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILMTCCBUcw ggQvoAMCAQICEEAfBHP+tuqufC4R+F+Tu54wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAyIENsaWVudCBDQTAeFw0xNjA4MTIy MTE5NDFaFw0xODA4MTIyMTE5NDFaMIGCMQswCQYDVQQGEwJDTDEiMCAGA1UECAwZTWV0cm9wb2xp dGFuYSBkZSBTYW50aWFnbzEWMBQGA1UEBwwNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAwwMSm9obiBC cmFkbGV5MSAwHgYJKoZIhvcNAQkBFhF2ZTdqdGJAdmU3anRiLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALhTcSiDGvVrm4hlJA8WyFcWWe0dqnuJzstQYTaF281JFOEPA/13kQYI JMXAEUcS7NvW7KdUI0tHU0N6RTo0Ilf1E1nm8No++eqHO8pFUZ/cidpv0r+1Qcl9EgrpbZ00Y7Xg pq06EZELzJAmds4QQcsTKdpLNFbVcFnM11i2Gj5VNsYgO+qPO2AS8rLHkgDWnNkc9/lA+ZK5wGiU zxPU9KnIrERoTif3Zk7KjLvFpBWYD60M/lNoHZ5zxYgmYLmvoM1TSLn4Ms57wwT5MieV2l0aqlGC 7CKNa6XyeL1B0y0wSxL3PJQS4vSLDnttZC7od2A6yjeUMyM3rQ41vqUIMc8CAwEAAaOCAcMwggG/ MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUmA9bUmBmTYkCcZ3yYv8IRRP2nN4wHwYDVR0jBBgwFoAUmZerGDU6i1lFQ5iy cnHI9PsJzxYwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNz bC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGll bnQyLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xp ZW50Mi5jcmwwHAYDVR0RBBUwE4ERdmU3anRiQHZlN2p0Yi5jb20wIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMFUGA1UdIAROMEwwDAYKKwYBBAGBtTcGATA8BgsrBgEEAYG1NwEC BTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4IBAQBqcYJfFA/ITkX4L6JihqW168Wog1BOfkbPXO+wPn5G9P1NwruGfu41b70EPPwV vol+/j+qhSSrDjFyfNBsq4G45GRR6hwx0ei/bH0UW15Y63ASYPkNlj3ydCcvhw5ItWD5aYPphBx9 C7tLnQ7ow09cqt2CIgPd3W/IGri7p4hWPbdcX0oFIhJcDxmCwTcWyoVoIo4aas5gP44LPGneCoqI lXQMJinwneEnKd7rWXlzVWv7geaH3t79zARSw9ev9F4E61cDuHi+vgTFEpio7oxybqfj99yLibhX uZjReYnYbDMRiWDXduVIrIGYwmnUuD8a0b20kJgHm+FEgB6UMa9JMIIF4jCCA8qgAwIBAgIQXLZI bkcMmMZ/9oDbZErijTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1 WhcNMzAxMjE2MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDIgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7g9Q jJUJI4Ss9VBqj9Y3ok4h/TIJZUc+rzj61Rv3hNB/yeEEC1fz3i/EU+MXOOGxM7KCbtCIcJxHIW/k 8RP6sPPMO4cTg7sNzfBWsYsemtY6fN/kVr2R2X+/PjvtxmAaXpGX0znvQPxaE123IMGXy0zEKHZ/ nJDZ199TP9TNn9v+1QO0AZb4oaJ7ch0DpSJa8kF5xiNFDAg9taKKSrVuPHJL9MFFYPIqwShjHg+u YEzjfxbMP2QWwamnaA9Y7fORSDNapduFlARAcDtXdMpAijiG4HKnrN323I0Ka7lDTAWyLtTDCETK sI8fzOyL0inEu1WEVpdPytm8s1rwQB4f9QIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQr MCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRa MFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBSZl6sYNTqLWUVDmLJy ccj0+wnPFjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUd IAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4ICAQCZQUEEzvYk9U4wNHhDu1f9QGwbzAH4m4wIKH8ZidNYwZhyoNKW041iJ002KMW9 ywYM95n4770tT45yH29vTMlZtBvz0h44KuxMLNXRCTDwvV07sT39nPjFi5MpwZaLVueNiaa1vok1 n2Wn8lLcyCltYZNGAEifM0ko/A/vvckftFIZG75RAiZHYtfnrdBGiOxyF+nHI9a33BRX5Vl/3z0+ uHZ/Y6YPbNJ7iboOFrFZBCtt+lp3WaDB62ZoBewiMmd09JrqmMJAEgw3EbfQNtaPzHPg/EOhlZik Rgd4BCrzrbIqB2RKib+gnQJt2uoJaKOaV90S9Xgs3PC837OE9CEmY6/MTTG0xpbLh2hR/rLQ3sCr H56aODeuDrQBq85lXxRbDCERDUR7FZUhHv+i1aQaY59NPu26hDd6nqksSDq2mCddpidPBuGJz9lN X2nRyGkudDuWV6gIr6AZfaYv+ggTXOcCDJZFzMhWdLC7CPvRKxQ7vTiYV+4lgqOvV9MnZc149PPt itTysq/oOv70zx7q+tyaLTa4cqFhCclhIwSwOEJiV3xqQebvmwsDX7BaXGAJZIhbdUbNr3poEgct 6uAxw2zyr69WCJmTUUhz/k1/TT/eCUZJqnMg/6mje7tiVdaUQJcBtJ6cq5+mUDNUB1fohW8EOFai zFpP/0FaP62ctTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMiBDbGllbnQgQ0ECEEAfBHP+tuqufC4R+F+Tu54wCQYFKw4DAhoF AKCCAZkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjA5MTg0 MDM4WjAjBgkqhkiG9w0BCQQxFgQUAubA3LuxM3SZjEv5dPA+HdT8NpowgZoGCSsGAQQBgjcQBDGB jDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIg Q2xpZW50IENBAhBAHwRz/rbqrnwuEfhfk7ueMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIgQ2xpZW50IENBAhBA HwRz/rbqrnwuEfhfk7ueMA0GCSqGSIb3DQEBAQUABIIBADh507lyQSqpTt5eyH//3aTmXs8+OxfN gXrSP3hqAD6F2Y+MO0Vuuako/s/os33HO1EqnHiO/hkgIlX18L7EE+skEaXOy+lQAY/rAt8dXCKe DUEfGS4qszp2dEnB/hqvXLMf6R5VMGNyDL1tFCVKdiYJqQzBCaRL7/ZgRvXtb0ORLjEYLxSKXYmK z1RqlxuAZHgK7g7Q8TVOP/c5ssZb6r/zgmdDQHmkKxI4YDweQIwRpfTkx0EnbKyKeXyCqSzpJ8bS TeGTF9YiCwHQzcMEm9m6UeiKtaLzuJBCWD4NncWaPlYHfxNHf52awQObRApQ02XoXvQeFy2aX7FI IwDlQx0AAAAAAAA= --Apple-Mail=_56366F2F-30DF-4916-A28E-FFB6EC9F62CC-- From nobody Thu Feb 9 10:49:01 2017 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 A261112957E for ; Thu, 9 Feb 2017 10:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Frvf7pPHG3ht for ; Thu, 9 Feb 2017 10:48:59 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0134.outbound.protection.outlook.com [104.47.33.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CEEC127076 for ; Thu, 9 Feb 2017 10:48:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IugP1kIw0soJCvtWp43/LL7AN16eazzJSv0oIiz9WcE=; b=i9Vywz5JD/kB+3LZrn2VY5YtkP9MGd71iAHzkmZ02NJsIDNKs0PereWHByy9lSlZGyneWr1n5WKhJZl3jAauQVaZ8e0Xd1HoZTHLFZskHFrGIGDl4E5HY/gZUJLltaKfe5ZJsS2QVnFoRjsf+qifOMTVV/dcw9A3nZe8ByrqlK4= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0844.namprd03.prod.outlook.com (10.160.163.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 9 Feb 2017 18:48:54 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.026; Thu, 9 Feb 2017 18:48:54 +0000 From: Andrei Popov To: John Bradley Thread-Topic: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? Thread-Index: AQHSguz8oAIXC6BWu0OMPbiyGCJ7xqFg384AgAAczHCAAAWOgIAAAH5g Date: Thu, 9 Feb 2017 18:48:54 +0000 Message-ID: References: <074faef6-b425-17f8-ac05-223834a2cc0b@KingsMountain.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: 3c50e62f-f473-4083-fdcd-08d4511c4c77 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0844; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 7:7ZUmVjOI3theL1LwXGbkYRR9OuURjF1GB638NfJ93BcLqbbduuaZWOw81Eq/vI3WbmBjXGll9lWePpJAWYIFrsQv+kz6T327/J8aLE+H5M+OpdpykEG8e3Go2QypyHl6yFu/3zBu6J5krusyDEOOE4iDpuSsDtIRurGx/Nd9AkWpV5WAtW8y7vn+pX6AOAv8YyPPtdLCzgSrw0+VAO/3MP4pmnLzzCpk/cssxLh60lWB77MsJF/zcdm17i5dGqZ3Cl7NOmPS9KGxNYGHqCCEmMKyYC2V7uLdiHKkO04M4F6Pp65f/eZMxxDK5r3RLBRlFENvCVXK+t0akor2+KPMQwYFI5Y4WnVDHolLwJ5i161ZecZL3P2opj6XhFk0p4PMKJWv6d55DzeM/9Nf7ckMzMUVEYmooanoqqY/LFvqRn0O4u+9j6j/d7qhC26l8DeEf/ZRsiAyyM7s2B2FI+s+0b+ZNJ6OPHG2mzzBNhMJ8Du20gtfDYW2/aYxOa+Ho6vwM9frLE45IF3cmnCvFwH/ElMXCAlLOUYBIdndXHMSM7Y= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123558025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39850400002)(39410400002)(39860400002)(39450400003)(189002)(199003)(24454002)(377454003)(2950100002)(6916009)(8936002)(106356001)(8990500004)(38730400002)(53936002)(81166006)(2900100001)(3280700002)(54906002)(50986999)(92566002)(76176999)(54356999)(236005)(8676002)(230783001)(81156014)(101416001)(7696004)(189998001)(5660300001)(10090500001)(110136004)(97736004)(33656002)(2906002)(7736002)(10290500002)(5005710100001)(122556002)(6246003)(4326007)(105586002)(106116001)(7906003)(77096006)(3660700001)(606005)(6436002)(86612001)(93886004)(68736007)(55016002)(25786008)(6506006)(74316002)(86362001)(54896002)(6306002)(9686003)(102836003)(229853002)(99286003)(6116002)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0844; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB08423422FB68F197584F31B98C450CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2017 18:48:54.7046 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0844 Archived-At: Cc: IETF TokBind WG , Brian Campbell , =JeffH Hodges Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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: Thu, 09 Feb 2017 18:49:00 -0000 --_000_CY1PR0301MB08423422FB68F197584F31B98C450CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEkgZG9udCBrbm93IHRoYXQgYSBwcm94eSB0aGF0IGRvZXNu4oCZdCB1bmRlcnN0YW5kIHRv a2VuIGJpbmRpbmcgc2hvdWxkIGZvcndhcmQgdGhlIGhlYWRlciBlc3BlY2lhbGx5IGluIHRoZSBm b3J3YXJkIGNhc2UuDQoNCsOYDQoNCsOYICBXaGF0IGlmIHRoZSBmb3J3YXJkIHByb3h5IGlzIG5l Z290aWF0aW5nIGl04oCZcyBvd24gdG9rZW4gYmluZGluZyAgdG8gdGhlIHNlcnZlcj8gIChzaG91 bGQgYSBmb3J3YXJkIHByb3h5IHByb3h5IGRvIHRoYXQgaXMgcGVyaGFwcyBhbm90aGVyIHF1ZXN0 aW9uKQ0KDQpXb3VsZCB5b3UgYWdyZWUgdGhhdCBpZiBhIHByb3h5IGlzIG5lZ290aWF0aW5nIGl0 cyBvd24gVEIgdG8gdGhlIHNlcnZlciwgdGhlbiB0aGlzIHByb3h5IGlzIFRCLWF3YXJlLCBhbmQg a25vd3Mgd2hhdCB0byBkbyBhYm91dCB0aGUgY2xpZW504oCZcyBUQiBoZWFkZXI/DQoNCkZyb206 IEpvaG4gQnJhZGxleSBbbWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tXQ0KU2VudDogVGh1cnNkYXks IEZlYnJ1YXJ5IDksIDIwMTcgMTA6NDEgQU0NClRvOiBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3Bv dkBtaWNyb3NvZnQuY29tPg0KQ2M6IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbT47ID1KZWZmSCBIb2RnZXMgPEplZmYuSG9kZ2VzQGtpbmdzbW91bnRhaW4uY29tPjsg SUVURiBUb2tCaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtVbmJl YXJhYmxlXSBvbiBub3QgbGlzdGluZyAnU2VjLVRva2VuLUJpbmRpbmcnIGluIHRoZSBDb25uZWN0 aW9uIGhlYWRlciBmaWVsZD8NCg0KVGhhdCBtYXkgYmUgdGhlIHJ1Yi4NCg0KRnJvbSBhIGhlYWRl ciBwZXJzcGVjdGl2ZSB3ZSBhcmUgdGFsa2luZyBhYm91dCBhbnkgcHJveHkgZm9yd2FyZCBhbmQg cmV2ZXJzZS4NCg0KSSBkb250IGtub3cgdGhhdCBhIHByb3h5IHRoYXQgZG9lc27igJl0IHVuZGVy c3RhbmQgdG9rZW4gYmluZGluZyBzaG91bGQgZm9yd2FyZCB0aGUgaGVhZGVyIGVzcGVjaWFsbHkg aW4gdGhlIGZvcndhcmQgY2FzZS4NCg0KV2hhdCBpZiB0aGUgZm9yd2FyZCBwcm94eSBpcyBuZWdv dGlhdGluZyBpdOKAmXMgb3duIHRva2VuIGJpbmRpbmcgIHRvIHRoZSBzZXJ2ZXI/ICAoc2hvdWxk IGEgZm9yd2FyZCBwcm94eSBwcm94eSBkbyB0aGF0IGlzIHBlcmhhcHMgYW5vdGhlciBxdWVzdGlv bikNCg0KSSB1bmRlcnN0YW5kIHRoZSBkZXNpcmUgdG8gcGFzcyB0aGUgaGVhZGVyIG9uIGluIHRo ZSByZXZlcnNlIHByb3h5IGNhc2UgYXMgaXQgbWF5IG1ha2Ugc2VydmVyIGNvZGUgZWFzaWVyLg0K DQpIb3dldmVyIEkgdGFrZSBKZWZm4oCZcyBwb2ludCB0aGF0IHRva2VuIGJpbmRpbmcgaXMgYnkg aXRzIG5hdHVyZSBob3AgYnkgaG9wIGFuZCBpZiB3ZSBtZXNzIHdpdGggdGhhdCB3ZSBtYXkgZ2V0 IHNvbWUgdW5pbnRlbmRlZCBzaWRlIGVmZmVjdHMuDQoNCklmIEJyaWFuIGhhZCBwcm9wb3NlZCBz dGlja2luZyBldmVyeXRoaW5nIGluIG9uZSBvciB0d28gIG5ldyBoZWFkZXJzIGFuZCByZW1vdmlu ZyB0aGUgZXhpc3Rpbmcgb25lIHRoZW4gdGhpcyB3b3VsZCBiZSBtdWNoIGxlc3MgY29udHJvdmVy c2lhbC4NCg0KSSBhbHdheXMgdGhvdWdodCB0aGF0IHdlIGNvdWxkIHVzZSB0aGUgc2FtZSBoZWFk ZXIgb24gdGhlIGluc2lkZSBvZiB0aGUgcHJveHksIGJ1dCBjYW4gc2VlIHdoeSB0aGF0IG1pZ2h0 IG1lc3MgdXAgc29tZSBvdGhlciBleHBlY3RhdGlvbnMuDQoNClNvIGlzIHRva2VuIGJpbmRpbmcg aG9wIGJ5IGhvcD8NCg0KSm9obiBCLg0KDQpPbiBGZWIgOSwgMjAxNywgYXQgMzoyNSBQTSwgQW5k cmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92 QG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KRXhhY3RseSwgSSBhZ3JlZSB3aXRoIEJyaWFuLiBU aGUgcHJveHkvdGVybWluYXRvciBpcyBiZXR0ZXIgcG9zaXRpb25lZCB0byBrbm93IGhvdy93aGVy ZSBUQiBoZWFkZXJzIGFyZSBoYW5kbGVkIGluIGEgcGFydGljdWxhciBkYXRhY2VudGVyLiBBbmQg YSBwcm94eS90ZXJtaW5hdG9yIHRoYXQga25vd3Mgbm90aGluZyBhYm91dCBUQiBoZWFkZXJzIHNo b3VsZCBmb3J3YXJkIHRoZW0gb24uDQoNCkZyb206IFVuYmVhcmFibGUgW21haWx0bzp1bmJlYXJh YmxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDog VGh1cnNkYXksIEZlYnJ1YXJ5IDksIDIwMTcgODozOCBBTQ0KVG86ID1KZWZmSCA8SmVmZi5Ib2Rn ZXNAa2luZ3Ntb3VudGFpbi5jb208bWFpbHRvOkplZmYuSG9kZ2VzQGtpbmdzbW91bnRhaW4uY29t Pj4NCkNjOiBJRVRGIFRva0JpbmQgV0cgPHVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOnVuYmVh cmFibGVAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBvbiBub3QgbGlzdGlu ZyAnU2VjLVRva2VuLUJpbmRpbmcnIGluIHRoZSBDb25uZWN0aW9uIGhlYWRlciBmaWVsZD8NCg0K DQoNCk9uIFRodSwgRmViIDksIDIwMTcgYXQgOTo1NSBBTSwgPUplZmZIIDxKZWZmLkhvZGdlc0Br aW5nc21vdW50YWluLmNvbTxtYWlsdG86SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20+PiB3 cm90ZToNCg0KSSBhZ3JlZSB3aXRoIHRoaXMgZm9yIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHJl YXNvbnMgLS0gd2Ugd2FudCB0aGUgU2VjLVRva2VuLUJpbmRpbmcgaGVhZGVyIHRvIGJlIGhvcC1i eS1ob3AgaW4gc3luYyB3aXRoIHRoZSB1bmRlcmx5aW5nIFRMUyBjb25uZWN0aW9uIGFuZCBub3Qg YmUgImxlYWtlZCIgZG93bnN0cmVhbSB1bmxlc3MgaXQgaXMgYSBjb25zY2lvdXMgZGVjaXNpb24s IGUuZy4sIGluIHRoZSB0bHMgdGVybWluYXRpbmcgcmV2ZXJzZSBwcm94eSAoVFRSUCkgY2FzZS4N Cg0KQnV0IHRoZSBjbGllbnQgaXMgb25seSBtYWtpbmcgYSBjb25uZWN0aW9uIHRvIGEgc2VydmVy IGFuZCBjbGllbnQgZG9lcyBub3Qga25vdyB3aGV0aGVyIGl0IG1ha2VzIHNlbnNlIGZvciB0aGF0 IHNlcnZlciB0byBmb3J3YXJkIG9yIG5vdC4gQW5kIGl0IHNob3VsZG4ndCBrbm93IHRoYXQuICBT ZWMtVG9rZW4tQmluZGluZyBzaG91bGRuJ3QgYmUgbGlzdGVkIGluIENvbm5lY3Rpb24gaGVhZGVy IGZpZWxkIGJ5IGEgY2xpZW50Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3QNClVuYmVhcmFibGVAaWV0Zi5v cmc8bWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3VuYmVhcmFibGUNCg0K --_000_CY1PR0301MB08423422FB68F197584F31B98C450CY1PR0301MB0842_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVk LXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjExMTU1 NzY3OTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE5 OTAzMDU0NzIgMzAyMTQ0ODg0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SSBk b250IGtub3cgdGhhdCBhIHByb3h5IHRoYXQgZG9lc27igJl0IHVuZGVyc3RhbmQgdG9rZW4gYmlu ZGluZyBzaG91bGQgZm9yd2FyZCB0aGUgaGVhZGVyIGVzcGVjaWFsbHkgaW4gdGhlIGZvcndhcmQg Y2FzZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPldoYXQg aWYgdGhlIGZvcndhcmQgcHJveHkgaXMgbmVnb3RpYXRpbmcgaXTigJlzIG93biB0b2tlbiBiaW5k aW5nICZuYnNwO3RvIHRoZSBzZXJ2ZXI/ICZuYnNwOyhzaG91bGQgYSBmb3J3YXJkIHByb3h5IHBy b3h5IGRvIHRoYXQgaXMgcGVyaGFwcyBhbm90aGVyIHF1ZXN0aW9uKTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldvdWxkIHlvdSBhZ3JlZSB0aGF0IGlmIGEgcHJveHkg aXMgbmVnb3RpYXRpbmcgaXRzIG93biBUQiB0byB0aGUgc2VydmVyLCB0aGVuIHRoaXMgcHJveHkg aXMgVEItYXdhcmUsIGFuZCBrbm93cyB3aGF0IHRvIGRvIGFib3V0IHRoZSBjbGllbnTigJlzIFRC IGhlYWRlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKb2huIEJyYWRsZXkgW21haWx0 bzp2ZTdqdGJAdmU3anRiLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVh cnkgOSwgMjAxNyAxMDo0MSBBTTxicj4NCjxiPlRvOjwvYj4gQW5kcmVpIFBvcG92ICZsdDtBbmRy ZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEJyaWFuIENhbXBiZWxs ICZsdDtiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSZndDs7ID1KZWZmSCBIb2RnZXMgJmx0O0pl ZmYuSG9kZ2VzQGtpbmdzbW91bnRhaW4uY29tJmd0OzsgSUVURiBUb2tCaW5kIFdHICZsdDt1bmJl YXJhYmxlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFibGVd IG9uIG5vdCBsaXN0aW5nICdTZWMtVG9rZW4tQmluZGluZycgaW4gdGhlIENvbm5lY3Rpb24gaGVh ZGVyIGZpZWxkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYXQgbWF5IGJlIHRoZSBydWIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Gcm9tIGEgaGVhZGVyIHBlcnNwZWN0aXZlIHdlIGFyZSB0YWxraW5nIGFib3V0 IGFueSBwcm94eSBmb3J3YXJkIGFuZCByZXZlcnNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbnQga25vdyB0aGF0IGEgcHJveHkgdGhh dCBkb2VzbuKAmXQgdW5kZXJzdGFuZCB0b2tlbiBiaW5kaW5nIHNob3VsZCBmb3J3YXJkIHRoZSBo ZWFkZXIgZXNwZWNpYWxseSBpbiB0aGUgZm9yd2FyZCBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGlmIHRoZSBmb3J3YXJkIHBy b3h5IGlzIG5lZ290aWF0aW5nIGl04oCZcyBvd24gdG9rZW4gYmluZGluZyAmbmJzcDt0byB0aGUg c2VydmVyPyAmbmJzcDsoc2hvdWxkIGEgZm9yd2FyZCBwcm94eSBwcm94eSBkbyB0aGF0IGlzIHBl cmhhcHMgYW5vdGhlciBxdWVzdGlvbik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB1bmRlcnN0YW5kIHRoZSBkZXNpcmUgdG8gcGFzcyB0aGUg aGVhZGVyIG9uIGluIHRoZSByZXZlcnNlIHByb3h5IGNhc2UgYXMgaXQgbWF5IG1ha2Ugc2VydmVy IGNvZGUgZWFzaWVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Ib3dldmVyIEkgdGFrZSBKZWZm4oCZcyBwb2ludCB0aGF0IHRva2VuIGJpbmRp bmcgaXMgYnkgaXRzIG5hdHVyZSBob3AgYnkgaG9wIGFuZCBpZiB3ZSBtZXNzIHdpdGggdGhhdCB3 ZSBtYXkgZ2V0IHNvbWUgdW5pbnRlbmRlZCBzaWRlIGVmZmVjdHMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIEJyaWFuIGhhZCBwcm9wb3Nl ZCBzdGlja2luZyBldmVyeXRoaW5nIGluIG9uZSBvciB0d28gJm5ic3A7bmV3IGhlYWRlcnMgYW5k IHJlbW92aW5nIHRoZSBleGlzdGluZyBvbmUgdGhlbiB0aGlzIHdvdWxkIGJlIG11Y2ggbGVzcyBj b250cm92ZXJzaWFsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGFsd2F5cyB0aG91Z2h0IHRoYXQgd2UgY291bGQgdXNlIHRoZSBzYW1lIGhl YWRlciBvbiB0aGUgaW5zaWRlIG9mIHRoZSBwcm94eSwgYnV0IGNhbiBzZWUgd2h5IHRoYXQgbWln aHQgbWVzcyB1cCBzb21lIG90aGVyIGV4cGVjdGF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gaXMgdG9rZW4gYmluZGluZyBob3Ag YnkgaG9wPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Kb2huIEIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBGZWIgOSwgMjAxNywgYXQgMzoyNSBQTSwgQW5kcmVpIFBvcG92ICZsdDs8 YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20iPkFuZHJlaS5Qb3BvdkBt aWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkV4YWN0bHksIEkgYWdyZWUgd2l0aCBC cmlhbi4gVGhlIHByb3h5L3Rlcm1pbmF0b3IgaXMgYmV0dGVyIHBvc2l0aW9uZWQgdG8ga25vdyBo b3cvd2hlcmUgVEIgaGVhZGVycyBhcmUgaGFuZGxlZCBpbiBhIHBhcnRpY3VsYXIgZGF0YWNlbnRl ci4gQW5kIGEgcHJveHkvdGVybWluYXRvciB0aGF0IGtub3dzDQogbm90aGluZyBhYm91dCBUQiBo ZWFkZXJzIHNob3VsZCBmb3J3YXJkIHRoZW0gb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5VbmJlYXJhYmxlDQogWzxhIGhyZWY9Im1haWx0bzp1bmJlYXJhYmxlLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XTxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhh bGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9i PkJyaWFuIENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBGZWJydWFyeSA5LCAyMDE3IDg6Mzgg QU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPj1KZWZmSCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkplZmYuSG9kZ2VzQGtpbmdzbW91 bnRhaW4uY29tIj5KZWZmLkhvZGdlc0BraW5nc21vdW50YWluLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+ Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5J RVRGIFRva0JpbmQgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzp1bmJlYXJhYmxlQGlldGYub3JnIj51 bmJlYXJhYmxlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtVbmJlYXJhYmxlXSBv biBub3QgbGlzdGluZyAnU2VjLVRva2VuLUJpbmRpbmcnIGluIHRoZSBDb25uZWN0aW9uIGhlYWRl ciBmaWVsZD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEZlYiA5LCAyMDE3 IGF0IDk6NTUgQU0sID1KZWZmSCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkplZmYuSG9kZ2VzQGtpbmdz bW91bnRhaW4uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48YnI+DQpJIGFncmVlIHdpdGggdGhpcyBmb3Igc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg cmVhc29ucyAtLSB3ZSB3YW50IHRoZSBTZWMtVG9rZW4tQmluZGluZyBoZWFkZXIgdG8gYmUgaG9w LWJ5LWhvcCBpbiBzeW5jIHdpdGggdGhlIHVuZGVybHlpbmcgVExTIGNvbm5lY3Rpb24gYW5kIG5v dCBiZSAmcXVvdDtsZWFrZWQmcXVvdDsgZG93bnN0cmVhbSB1bmxlc3MgaXQgaXMgYSBjb25zY2lv dXMgZGVjaXNpb24sIGUuZy4sIGluIHRoZSB0bHMgdGVybWluYXRpbmcgcmV2ZXJzZQ0KIHByb3h5 IChUVFJQKSBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCB0aGUgY2xpZW50IGlz IG9ubHkgbWFraW5nIGEgY29ubmVjdGlvbiB0byBhIHNlcnZlciBhbmQgY2xpZW50IGRvZXMgbm90 IGtub3cgd2hldGhlciBpdCBtYWtlcyBzZW5zZSBmb3IgdGhhdCBzZXJ2ZXIgdG8gZm9yd2FyZCBv ciBub3QuIEFuZCBpdCBzaG91bGRuJ3Qga25vdyB0aGF0LiZuYnNwOyBTZWMtVG9rZW4tQmluZGlu ZyBzaG91bGRuJ3QgYmUgbGlzdGVkIGluIENvbm5lY3Rpb24gaGVhZGVyIGZpZWxkIGJ5IGENCiBj bGllbnQuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpVbmJlYXJh YmxlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpVbmJlYXJhYmxlQGlldGYub3Jn Ij5VbmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby91bmJlYXJhYmxlPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR0301MB08423422FB68F197584F31B98C450CY1PR0301MB0842_-- From nobody Thu Feb 9 10:52:05 2017 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 0977A1293EE for ; Thu, 9 Feb 2017 10:52:04 -0800 (PST) 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 HlF6N_Cq7pLF for ; Thu, 9 Feb 2017 10:52:02 -0800 (PST) Received: from treenet.co.nz (unknown [121.99.228.82]) by ietfa.amsl.com (Postfix) with ESMTP id C5F3F127076 for ; Thu, 9 Feb 2017 10:52:00 -0800 (PST) Received: from [192.168.20.251] (unknown [121.98.40.15]) by treenet.co.nz (Postfix) with ESMTP id ED095E6EBA for ; Fri, 10 Feb 2017 07:51:58 +1300 (NZDT) To: unbearable@ietf.org References: <935ac509-1e0f-3fed-0239-04cf390ef2ce@KingsMountain.com> From: Amos Jeffries Message-ID: Date: Fri, 10 Feb 2017 07:51:32 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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: Thu, 09 Feb 2017 18:52:04 -0000 On 10/02/2017 7:18 a.m., Andrei Popov wrote: > Hi Jeff, > > If you agree that the client, generally, does not know whether the proxy/TLS terminator validates TB or passes it on to the back-end server, then why do you argue that the client should require the proxy to drop TB headers? I believe the client should not interfere with this and let datacenter infrastructure figure out how/where to handle TB headers. > >> ..which is what we want by default for security considerations reasons, I think. > Sorry, what security considerations reasons are you referring to? > * Leaking the TB values from TLS terminating proxies. *unless* they are intentionally non-validating reverse-proxies. * to be sure the Sec-Token-Binding actually belongs to the TLS connection the HTTP message was transmitted over. Not being injected by an attacker. * to pevent multiple Sec-Token-Binding being delivered on a message if there happened to be multiple different TLS hops along the way. To ensure attackers can't just send multiple TBH and hope one gets accepted. Amos From nobody Thu Feb 9 10:57:47 2017 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 5636E129C3F for ; Thu, 9 Feb 2017 10:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 krw5V7HiNqjw for ; Thu, 9 Feb 2017 10:57:44 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 23CD0129540 for ; Thu, 9 Feb 2017 10:57:44 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id s140so14851393qke.0 for ; Thu, 09 Feb 2017 10:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mCERIagkteeiDvMUu5mZPZFBU140nkfF8kfGiQ14KcE=; b=VuNLTeanye7kT/673+I9ZLBzCmzAWusbjwjk4dCaW6bNWJAhyVjYKjzlyAWqzor7Md jwRPLVzsR+62uQyGR3lrEDDXHm82j1TZJnFZwmzlmw113w1kXUmqLyjEYXPjvDo3re2c e828a+ImfKQ34oqzCwRKwisY/XtRev23dlO+NPMnzC9zfQIaQ7TKTQ29LcBrMCV2adUf dFaJQraCNf8WcdKqxJSal8agogZOvWogpDRmlhoGzqh75SBYXxxjUorDe48S7LXWaaMT DgbUmrkEv81m4GS+FgUJD5LHptg1iEA8PcSeYsgnqUWZyuBrwefIPnwDZ1eiMFoRLrRb hOww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mCERIagkteeiDvMUu5mZPZFBU140nkfF8kfGiQ14KcE=; b=CCjZyZQFm2tPc2l4+1b1AknfaoGLQh5RfxwiT8g94L+quXIbeEUYWbA/hVA4yMvE9y Lr5bBIEXPFxBNaBCvzMfJVpHvsY0NcMfSH/dz6qdPER2uie8n1Z2HhBjKaKdkLLOm1Oc CtHXSS9lNF5M6inDB2tHTWrjulIlHyH8CEx+haFJpfzhd80FSLThgSoMc8kfmvt9M/FN zzHT2+7B7ZgjuyCus9n2TL46Z3qA0q3mtPb4m68bpkLALABcVBZKYEAg/YIh+2xhYrU4 gB3+7TswU1RRh4Sided3hpdPo58gFxlOQ2gUFTBl7AH9Vt6ILN8uOn7ezeA1SS9leeEQ /V4g== X-Gm-Message-State: AMke39kua6pQ4zhzuhfa/Ep3tOm4yL9J+Y7YnsEhLWi+wW9VcfzX8TsR4SB7LiVBZkhJFvD+ X-Received: by 10.233.216.68 with SMTP id u65mr4429388qkf.68.1486666663079; Thu, 09 Feb 2017 10:57:43 -0800 (PST) Received: from [192.168.8.100] ([181.201.209.140]) by smtp.gmail.com with ESMTPSA id u29sm9932152qki.4.2017.02.09.10.57.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 10:57:42 -0800 (PST) From: John Bradley Message-Id: <3248A381-14C7-48CC-A78B-B9649191A4BA@ve7jtb.com> Content-Type: multipart/signed; boundary="Apple-Mail=_AF4CB47E-F11E-4793-AC24-149282CDC3B1"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Feb 2017 15:57:38 -0300 In-Reply-To: To: Andrei Popov References: <074faef6-b425-17f8-ac05-223834a2cc0b@KingsMountain.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF TokBind WG , Brian Campbell , =JeffH Hodges Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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: Thu, 09 Feb 2017 18:57:46 -0000 --Apple-Mail=_AF4CB47E-F11E-4793-AC24-149282CDC3B1 Content-Type: multipart/alternative; boundary="Apple-Mail=_DE9DA017-5CAE-41DB-BBCB-35817FD6B628" --Apple-Mail=_DE9DA017-5CAE-41DB-BBCB-35817FD6B628 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If it is negotiating token binding with the server then it can=E2=80=99t = pass along the original token binding in the same header without = significant confusion I suspect. The bigger short term question is what should a proxy that doesn=E2=80=99t= understand token binding do. If token binding is signalled from the = user agent as hop by hop then it should drop the header. I think it is better for the server to get no token binding header than = one from a client that thinks it has negotiated token binding but it = cant validate. The Include-Referred-Token-Binding-ID header should be end to end and = not removed by proxies. John B. > On Feb 9, 2017, at 3:48 PM, Andrei Popov = wrote: >=20 > =C3=98 I dont know that a proxy that doesn=E2=80=99t understand token = binding should forward the header especially in the forward case. > =C3=98 =20 > =C3=98 What if the forward proxy is negotiating it=E2=80=99s own = token binding to the server? (should a forward proxy proxy do that is = perhaps another question) > =20 > Would you agree that if a proxy is negotiating its own TB to the = server, then this proxy is TB-aware, and knows what to do about the = client=E2=80=99s TB header? > =20 > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Thursday, February 9, 2017 10:41 AM > To: Andrei Popov > Cc: Brian Campbell ; =3DJeffH Hodges = ; IETF TokBind WG > Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the = Connection header field? > =20 > That may be the rub. > =20 > =46rom a header perspective we are talking about any proxy forward and = reverse. > =20 > I dont know that a proxy that doesn=E2=80=99t understand token binding = should forward the header especially in the forward case. > =20 > What if the forward proxy is negotiating it=E2=80=99s own token = binding to the server? (should a forward proxy proxy do that is = perhaps another question) > =20 > I understand the desire to pass the header on in the reverse proxy = case as it may make server code easier. > =20 > However I take Jeff=E2=80=99s point that token binding is by its = nature hop by hop and if we mess with that we may get some unintended = side effects. > =20 > If Brian had proposed sticking everything in one or two new headers = and removing the existing one then this would be much less = controversial. > =20 > I always thought that we could use the same header on the inside of = the proxy, but can see why that might mess up some other expectations. > =20 > So is token binding hop by hop? > =20 > John B. > =20 > On Feb 9, 2017, at 3:25 PM, Andrei Popov > wrote: > =20 > Exactly, I agree with Brian. The proxy/terminator is better positioned = to know how/where TB headers are handled in a particular datacenter. And = a proxy/terminator that knows nothing about TB headers should forward = them on. > =20 > From: Unbearable [mailto:unbearable-bounces@ietf.org = ] On Behalf Of Brian Campbell > Sent: Thursday, February 9, 2017 8:38 AM > To: =3DJeffH > > Cc: IETF TokBind WG > > Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the = Connection header field? > =20 > =20 > =20 > On Thu, Feb 9, 2017 at 9:55 AM, =3DJeffH = > = wrote: >=20 > I agree with this for security considerations reasons -- we want the = Sec-Token-Binding header to be hop-by-hop in sync with the underlying = TLS connection and not be "leaked" downstream unless it is a conscious = decision, e.g., in the tls terminating reverse proxy (TTRP) case. >=20 > =20 > But the client is only making a connection to a server and client does = not know whether it makes sense for that server to forward or not. And = it shouldn't know that. Sec-Token-Binding shouldn't be listed in = Connection header field by a client.=20 > =20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable = --Apple-Mail=_DE9DA017-5CAE-41DB-BBCB-35817FD6B628 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If it is negotiating token binding with the server then it = can=E2=80=99t pass along the original token binding in the same header = without significant confusion I suspect.

The bigger short term question is what = should a proxy that doesn=E2=80=99t understand token binding do. =  If token binding is signalled from the user agent as hop by hop = then it should drop the header.

I think it is better for the server to = get no token binding header than one from a client that thinks it has = negotiated token binding but it cant validate.

The Include-Referred-Token-Binding-ID header should be end to end = and not removed by proxies.

John B.

On Feb 9, 2017, at 3:48 PM, Andrei Popov = <Andrei.Popov@microsoft.com> wrote:

=C3=98  I dont = know that a proxy that doesn=E2=80=99t understand token binding should = forward the header especially in the forward case.
=C3=98   
=C3=98  What = if the forward proxy is negotiating it=E2=80=99s own token binding =  to the server?  (should a forward proxy proxy do that is = perhaps another question)
 
Would you agree that if a proxy is negotiating = its own TB to the server, then this proxy is TB-aware, and knows what to = do about the client=E2=80=99s TB header?
 
From: John = Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Thursday, February 9, 2017 = 10:41 AM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Brian= Campbell <bcampbell@pingidentity.com>; =3DJeffH Hodges <Jeff.Hodges@kingsmountain.com>; IETF TokBind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] on not = listing 'Sec-Token-Binding' in the Connection header field?
 
That may be the rub.
 
=46rom a header perspective we are talking about any = proxy forward and reverse.
 
I dont know that a proxy that doesn=E2=80=99t = understand token binding should forward the header especially in the = forward case.
 
What if the forward proxy is negotiating it=E2=80=99s = own token binding  to the server?  (should a forward proxy = proxy do that is perhaps another question)
 
I understand the desire to pass the = header on in the reverse proxy case as it may make server code = easier.
 
However I take Jeff=E2=80=99s point that token = binding is by its nature hop by hop and if we mess with that we may get = some unintended side effects.
 
If Brian had proposed sticking everything in one or = two  new headers and removing the existing one then this would be = much less controversial.
 
I always thought that we could use the same header on = the inside of the proxy, but can see why that might mess up some other = expectations.
 
So is token binding hop by hop?
 
John B.
 
On Feb 9, 2017, at = 3:25 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
 
Exactly, I agree with = Brian. The proxy/terminator is better positioned to know how/where TB = headers are handled in a particular datacenter. And a proxy/terminator = that knows nothing about TB headers should forward them on.
 
From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf = Of Brian = Campbell
Sent: Thursday, February 9, 2017 = 8:38 AM
To: =3DJeffH <Jeff.Hodges@kingsmountain.com>
Cc: IETF = TokBind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] on not = listing 'Sec-Token-Binding' in the Connection header field?
 
 
 
On Thu, Feb 9, 2017 at 9:55 AM, =3DJeffH = <Jeff.Hodges@kingsmountain.com> wrote:


I = agree with this for security considerations reasons -- we want the = Sec-Token-Binding header to be hop-by-hop in sync with the underlying = TLS connection and not be "leaked" downstream unless it is a conscious = decision, e.g., in the tls terminating reverse proxy (TTRP) case.

 
But the client is only making a = connection to a server and client does not know whether it makes sense = for that server to forward or not. And it shouldn't know that.  = Sec-Token-Binding shouldn't be listed in Connection header field by a = client. 
 
_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable

= --Apple-Mail=_DE9DA017-5CAE-41DB-BBCB-35817FD6B628-- --Apple-Mail=_AF4CB47E-F11E-4793-AC24-149282CDC3B1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILMTCCBUcw ggQvoAMCAQICEEAfBHP+tuqufC4R+F+Tu54wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAyIENsaWVudCBDQTAeFw0xNjA4MTIy MTE5NDFaFw0xODA4MTIyMTE5NDFaMIGCMQswCQYDVQQGEwJDTDEiMCAGA1UECAwZTWV0cm9wb2xp dGFuYSBkZSBTYW50aWFnbzEWMBQGA1UEBwwNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAwwMSm9obiBC cmFkbGV5MSAwHgYJKoZIhvcNAQkBFhF2ZTdqdGJAdmU3anRiLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALhTcSiDGvVrm4hlJA8WyFcWWe0dqnuJzstQYTaF281JFOEPA/13kQYI JMXAEUcS7NvW7KdUI0tHU0N6RTo0Ilf1E1nm8No++eqHO8pFUZ/cidpv0r+1Qcl9EgrpbZ00Y7Xg pq06EZELzJAmds4QQcsTKdpLNFbVcFnM11i2Gj5VNsYgO+qPO2AS8rLHkgDWnNkc9/lA+ZK5wGiU zxPU9KnIrERoTif3Zk7KjLvFpBWYD60M/lNoHZ5zxYgmYLmvoM1TSLn4Ms57wwT5MieV2l0aqlGC 7CKNa6XyeL1B0y0wSxL3PJQS4vSLDnttZC7od2A6yjeUMyM3rQ41vqUIMc8CAwEAAaOCAcMwggG/ MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUmA9bUmBmTYkCcZ3yYv8IRRP2nN4wHwYDVR0jBBgwFoAUmZerGDU6i1lFQ5iy cnHI9PsJzxYwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNz bC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGll bnQyLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xp ZW50Mi5jcmwwHAYDVR0RBBUwE4ERdmU3anRiQHZlN2p0Yi5jb20wIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMFUGA1UdIAROMEwwDAYKKwYBBAGBtTcGATA8BgsrBgEEAYG1NwEC BTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4IBAQBqcYJfFA/ITkX4L6JihqW168Wog1BOfkbPXO+wPn5G9P1NwruGfu41b70EPPwV vol+/j+qhSSrDjFyfNBsq4G45GRR6hwx0ei/bH0UW15Y63ASYPkNlj3ydCcvhw5ItWD5aYPphBx9 C7tLnQ7ow09cqt2CIgPd3W/IGri7p4hWPbdcX0oFIhJcDxmCwTcWyoVoIo4aas5gP44LPGneCoqI lXQMJinwneEnKd7rWXlzVWv7geaH3t79zARSw9ev9F4E61cDuHi+vgTFEpio7oxybqfj99yLibhX uZjReYnYbDMRiWDXduVIrIGYwmnUuD8a0b20kJgHm+FEgB6UMa9JMIIF4jCCA8qgAwIBAgIQXLZI bkcMmMZ/9oDbZErijTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1 WhcNMzAxMjE2MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDIgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7g9Q jJUJI4Ss9VBqj9Y3ok4h/TIJZUc+rzj61Rv3hNB/yeEEC1fz3i/EU+MXOOGxM7KCbtCIcJxHIW/k 8RP6sPPMO4cTg7sNzfBWsYsemtY6fN/kVr2R2X+/PjvtxmAaXpGX0znvQPxaE123IMGXy0zEKHZ/ nJDZ199TP9TNn9v+1QO0AZb4oaJ7ch0DpSJa8kF5xiNFDAg9taKKSrVuPHJL9MFFYPIqwShjHg+u YEzjfxbMP2QWwamnaA9Y7fORSDNapduFlARAcDtXdMpAijiG4HKnrN323I0Ka7lDTAWyLtTDCETK sI8fzOyL0inEu1WEVpdPytm8s1rwQB4f9QIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQr MCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRa MFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBSZl6sYNTqLWUVDmLJy ccj0+wnPFjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUd IAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4ICAQCZQUEEzvYk9U4wNHhDu1f9QGwbzAH4m4wIKH8ZidNYwZhyoNKW041iJ002KMW9 ywYM95n4770tT45yH29vTMlZtBvz0h44KuxMLNXRCTDwvV07sT39nPjFi5MpwZaLVueNiaa1vok1 n2Wn8lLcyCltYZNGAEifM0ko/A/vvckftFIZG75RAiZHYtfnrdBGiOxyF+nHI9a33BRX5Vl/3z0+ uHZ/Y6YPbNJ7iboOFrFZBCtt+lp3WaDB62ZoBewiMmd09JrqmMJAEgw3EbfQNtaPzHPg/EOhlZik Rgd4BCrzrbIqB2RKib+gnQJt2uoJaKOaV90S9Xgs3PC837OE9CEmY6/MTTG0xpbLh2hR/rLQ3sCr H56aODeuDrQBq85lXxRbDCERDUR7FZUhHv+i1aQaY59NPu26hDd6nqksSDq2mCddpidPBuGJz9lN X2nRyGkudDuWV6gIr6AZfaYv+ggTXOcCDJZFzMhWdLC7CPvRKxQ7vTiYV+4lgqOvV9MnZc149PPt itTysq/oOv70zx7q+tyaLTa4cqFhCclhIwSwOEJiV3xqQebvmwsDX7BaXGAJZIhbdUbNr3poEgct 6uAxw2zyr69WCJmTUUhz/k1/TT/eCUZJqnMg/6mje7tiVdaUQJcBtJ6cq5+mUDNUB1fohW8EOFai zFpP/0FaP62ctTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMiBDbGllbnQgQ0ECEEAfBHP+tuqufC4R+F+Tu54wCQYFKw4DAhoF AKCCAZkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjA5MTg1 NzM5WjAjBgkqhkiG9w0BCQQxFgQUmZYPElTPZ4VFJ97HVuG70X+mbJ0wgZoGCSsGAQQBgjcQBDGB jDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIg Q2xpZW50IENBAhBAHwRz/rbqrnwuEfhfk7ueMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIgQ2xpZW50IENBAhBA HwRz/rbqrnwuEfhfk7ueMA0GCSqGSIb3DQEBAQUABIIBAC8YZnch+Kbf2Bwu0Er1Ws7s1SKFRyNK Yskv5gUEQemYrlRMT8SnG0ys/B1HVm1pvcrlKZdsRjiN8PLszlhQUYDUR0vuTM+BXs4d5l3ieFVq lhOgxGo4RP/Rh2lxd7xBSXdHuHyqBkS+7pv03PPXBpnsrhBfqhdqQx5TFnD9HefAA8xbcZZJ6kEY +so44EW+n01u0sxOiONE8tc9VJUkWEBlUni07/g/pGKbnoI9NvMY2bjfVTJNOLiF1PJTMy37zf2i zJa1V1Vy4+Dk5oYpyNhfGg72UgW1NtjiESlW1u3TadTIyNwJHtKbaT9w25MqZ7Gv3D9wlED+Rm3d +Pt0qHgAAAAAAAA= --Apple-Mail=_AF4CB47E-F11E-4793-AC24-149282CDC3B1-- From nobody Thu Feb 9 11:10:19 2017 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 319B2129C57 for ; Thu, 9 Feb 2017 11:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 SxPiMBaKpbRS for ; Thu, 9 Feb 2017 11:10:15 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0100.outbound.protection.outlook.com [104.47.32.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403F612943C for ; Thu, 9 Feb 2017 11:10:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AspeqM3bP/jclTOxeQYk78Yzrc1TfQvQorRzXq6I2Z0=; b=mmGymcMH8za+sSfWhxXPs6Lc6GLymWIHQ7rnhOckC/QCEJ+BS3xxo8W314Sl3r8EX1Wc2Xlr90U0bUak39AUhUeATuIw0lL7oSERGbBSaoPxCg1/NidB2LSXRv4qMvjM+tHEOpv9west1/AlqcQZVqOkcomn2iIhCsCg6ShfFn8= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0844.namprd03.prod.outlook.com (10.160.163.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 9 Feb 2017 19:10:10 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.026; Thu, 9 Feb 2017 19:10:10 +0000 From: Andrei Popov To: John Bradley Thread-Topic: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? Thread-Index: AQHSguz8oAIXC6BWu0OMPbiyGCJ7xqFg384AgAAczHCAAAWOgIAAAH5ggAAEQwCAAAA/gA== Date: Thu, 9 Feb 2017 19:10:10 +0000 Message-ID: References: <074faef6-b425-17f8-ac05-223834a2cc0b@KingsMountain.com> <3248A381-14C7-48CC-A78B-B9649191A4BA@ve7jtb.com> In-Reply-To: <3248A381-14C7-48CC-A78B-B9649191A4BA@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: 03ff973f-6cf6-4ac2-0a8b-08d4511f44c6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0844; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 7:LqqGx8p1/eFWOYTkHIfjyaR7YFtuUhbWsslS0hwqjhEwv/GAUcP+d9coIAZHf2KVcrSrKP4qQRvNi1WQRWA5UhK5X+VI3h2xvIMqf1Q8Tc12v6WlvEWjTTKQYklaKjO6xFlDqlMHU0IiGlC48Pn9pJnmwk7GHvajnD7RPNRSzi6gZe5olFiJveJJSFJIREuzL02PLU88TpCw8ArEwe4zpVnwxCb493aNGHebeh3iC6eTo9WGH1jOwb+NdqDPvAkHE8Xi5/Jf4gMgZbLB9A+KQFS6WVxTG9x4/OkSjzpUY6ctTCduWdQq+yn9t6Ai+PRVbbc+AaOz3dTYgO98jLG33Ba4SGh5yztaW5xF+qPi3JgYIJSNIdvLIwW4OW+Lf4G6rJVpZPJ/mb60xT4NoZZH3mUIh5oLIdl1UfDHYa1NQcun2Frd4sETBkyrV+X/QT7G1g+WnCR74jJ0bu+lHeZyd2zFClEhSEMAZkc9GXvTvS08tkVQSKz4bsC8QeA/mDUCeZKAaRimfh+HnS1pVO1/dl9EkQSQpvF3hz4eNhqbe9M= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39840400002)(39860400002)(39450400003)(189002)(199003)(2950100002)(6916009)(8936002)(106356001)(8990500004)(38730400002)(53936002)(81166006)(2900100001)(3280700002)(54906002)(50986999)(92566002)(76176999)(54356999)(8676002)(230783001)(81156014)(101416001)(7696004)(189998001)(5660300001)(10090500001)(110136004)(97736004)(33656002)(2906002)(10290500002)(7736002)(5005710100001)(122556002)(6246003)(4326007)(105586002)(106116001)(77096006)(3660700001)(6436002)(86612001)(93886004)(68736007)(55016002)(25786008)(6506006)(74316002)(86362001)(6306002)(54896002)(9686003)(102836003)(229853002)(99286003)(6116002)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0844; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842BA623E540E885D2AD8D28C450CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2017 19:10:10.3186 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0844 Archived-At: Cc: IETF TokBind WG , Brian Campbell , =JeffH Hodges Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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: Thu, 09 Feb 2017 19:10:18 -0000 --_000_CY1PR0301MB0842BA623E540E885D2AD8D28C450CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIElmIGl0IGlzIG5lZ290aWF0aW5nIHRva2VuIGJpbmRpbmcgd2l0aCB0aGUgc2VydmVyIHRo ZW4gaXQgY2Fu4oCZdCBwYXNzIGFsb25nIHRoZSBvcmlnaW5hbCB0b2tlbiBiaW5kaW5nIGluIHRo ZSBzYW1lIGhlYWRlciB3aXRob3V0IHNpZ25pZmljYW50IGNvbmZ1c2lvbiBJIHN1c3BlY3QuDQpN eSBhcmd1bWVudCBpcyB0aGF0IGEgVEItYXdhcmUgcHJveHkgdW5kZXJzdGFuZHMgdGhpcyBhbmQg ZG9lcyB0aGUgcmlnaHQgdGhpbmcsIHdoaWNoIG1heSBiZSB2YWxpZGF0aW5nIHRoZSBjbGllbnTi gJlzIFRCIGFuZCBnZW5lcmF0aW5nIGEgbmV3IFRCIGZvciB0aGUgYmFjay1lbmQgc2VydmVyLCBv ciBzb21ldGhpbmcgZWxzZS4NCg0KDQrDmCAgVGhlIGJpZ2dlciBzaG9ydCB0ZXJtIHF1ZXN0aW9u IGlzIHdoYXQgc2hvdWxkIGEgcHJveHkgdGhhdCBkb2VzbuKAmXQgdW5kZXJzdGFuZCB0b2tlbiBi aW5kaW5nIGRvLiAgSWYgdG9rZW4gYmluZGluZyBpcyBzaWduYWxsZWQgZnJvbSB0aGUgdXNlciBh Z2VudCBhcyBob3AgYnkgaG9wIHRoZW4gaXQgc2hvdWxkIGRyb3AgdGhlIGhlYWRlci4NCkEgcHJv eHkgdGhhdCBkb2VzIG5vdCB1bmRlcnN0YW5kIFRCLCBidXQgdGVybWluYXRlcyBUTFMsIGRvZXMg bm90IG5lZ290aWF0ZSBUQiB3aXRoIHRoZSBjbGllbnQgYW5kIGRvZXMgbm90IHJlY2VpdmUgdGhl IFRCIGhlYWRlci4NCg0KDQrDmCAgSSB0aGluayBpdCBpcyBiZXR0ZXIgZm9yIHRoZSBzZXJ2ZXIg dG8gZ2V0IG5vIHRva2VuIGJpbmRpbmcgaGVhZGVyIHRoYW4gb25lIGZyb20gYSBjbGllbnQgdGhh dCB0aGlua3MgaXQgaGFzIG5lZ290aWF0ZWQgdG9rZW4gYmluZGluZyBidXQgaXQgY2FudCB2YWxp ZGF0ZS4NClRoZSBjbGllbnQgb25seSBzZW5kcyB0aGUgVEIgaGVhZGVyIGlmIFRCIHdhcyBuZWdv dGlhdGVkLiBUaGlzIG1lYW5zIHRoZSBwcm94eSBhbmQvb3IgYmFjay1lbmQgc2VydmVyIGFyZSBj b25maWd1cmVkIGJ5IHRoZSBhZG1pbiB0byBoYW5kbGUgVEIuDQpUaGUgY2xpZW50IGRvZXMgbm90 IGtub3cgd2hldGhlciB0aGUgcHJveHkgb3IgdGhlIGJhY2stZW5kIHNlcnZlciBoYW5kbGUgVEIs IHNvIGNhbuKAmXQgbWFrZSBhIGhlYWRlciBmb3J3YXJkaW5nIGRlY2lzaW9uIGZvciB0aGVtLg0K --_000_CY1PR0301MB0842BA623E540E885D2AD8D28C450CY1PR0301MB0842_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1z dHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE0Mzc0MzA2MTsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTIzODYyMzEyMiAtMjA0MzUw NDc3MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206 MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPklmIGl0IGlzIG5lZ290aWF0 aW5nIHRva2VuIGJpbmRpbmcgd2l0aCB0aGUgc2VydmVyIHRoZW4gaXQgY2Fu4oCZdCBwYXNzIGFs b25nIHRoZSBvcmlnaW5hbCB0b2tlbiBiaW5kaW5nIGluIHRoZSBzYW1lIGhlYWRlciB3aXRob3V0 IHNpZ25pZmljYW50IGNvbmZ1c2lvbiBJIHN1c3BlY3QuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk15IGFyZ3VtZW50IGlzIHRoYXQgYSBUQi1h d2FyZSBwcm94eSB1bmRlcnN0YW5kcyB0aGlzIGFuZCBkb2VzIHRoZSByaWdodCB0aGluZywgd2hp Y2ggbWF5IGJlIHZhbGlkYXRpbmcgdGhlIGNsaWVudOKAmXMgVEIgYW5kIGdlbmVyYXRpbmcgYSBu ZXcgVEIgZm9yIHRoZSBiYWNrLWVuZCBzZXJ2ZXIsIG9yDQogc29tZXRoaW5nIGVsc2UuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPlRoZSBiaWdnZXIgc2hvcnQgdGVybSBxdWVzdGlvbiBpcyB3aGF0IHNob3VsZCBhIHByb3h5 IHRoYXQgZG9lc27igJl0IHVuZGVyc3RhbmQgdG9rZW4gYmluZGluZyBkby4gJm5ic3A7SWYgdG9r ZW4gYmluZGluZyBpcyBzaWduYWxsZWQgZnJvbSB0aGUgdXNlciBhZ2VudCBhcyBob3AgYnkgaG9w IHRoZW4gaXQgc2hvdWxkIGRyb3AgdGhlIGhlYWRlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QSBwcm94eSB0aGF0IGRvZXMgbm90IHVuZGVy c3RhbmQgVEIsIGJ1dCB0ZXJtaW5hdGVzIFRMUywgZG9lcyBub3QgbmVnb3RpYXRlIFRCIHdpdGgg dGhlIGNsaWVudCBhbmQgZG9lcyBub3QgcmVjZWl2ZSB0aGUgVEIgaGVhZGVyLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5J IHRoaW5rIGl0IGlzIGJldHRlciBmb3IgdGhlIHNlcnZlciB0byBnZXQgbm8gdG9rZW4gYmluZGlu ZyBoZWFkZXIgdGhhbiBvbmUgZnJvbSBhIGNsaWVudCB0aGF0IHRoaW5rcyBpdCBoYXMgbmVnb3Rp YXRlZCB0b2tlbiBiaW5kaW5nIGJ1dCBpdCBjYW50IHZhbGlkYXRlLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgY2xpZW50IG9ubHkgc2Vu ZHMgdGhlIFRCIGhlYWRlciBpZiBUQiB3YXMgbmVnb3RpYXRlZC4gVGhpcyBtZWFucyB0aGUgcHJv eHkgYW5kL29yIGJhY2stZW5kIHNlcnZlciBhcmUgY29uZmlndXJlZCBieSB0aGUgYWRtaW4gdG8g aGFuZGxlIFRCLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5UaGUgY2xpZW50IGRvZXMgbm90IGtub3cgd2hldGhlciB0aGUgcHJv eHkgb3IgdGhlIGJhY2stZW5kIHNlcnZlciBoYW5kbGUgVEIsIHNvIGNhbuKAmXQgbWFrZSBhIGhl YWRlciBmb3J3YXJkaW5nIGRlY2lzaW9uIGZvciB0aGVtLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR0301MB0842BA623E540E885D2AD8D28C450CY1PR0301MB0842_-- From nobody Thu Feb 9 11:14:31 2017 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 DE772129C5A for ; Thu, 9 Feb 2017 11:14:27 -0800 (PST) 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 taW-9DjSnbit for ; Thu, 9 Feb 2017 11:14:26 -0800 (PST) Received: from treenet.co.nz (unknown [121.99.228.82]) by ietfa.amsl.com (Postfix) with ESMTP id A96671299EF for ; Thu, 9 Feb 2017 11:14:26 -0800 (PST) Received: from [192.168.20.251] (unknown [121.98.40.15]) by treenet.co.nz (Postfix) with ESMTP id 1D6CAE6EBA for ; Fri, 10 Feb 2017 08:14:24 +1300 (NZDT) To: unbearable@ietf.org References: <43DD0CF0-4043-448D-BE38-FAFFDE779B57@ve7jtb.com> From: Amos Jeffries Message-ID: Date: Fri, 10 Feb 2017 08:14:01 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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: Thu, 09 Feb 2017 19:14:30 -0000 On 9/02/2017 6:20 a.m., Andrei Popov wrote: > The Connect header is for the client to tell a proxy "this header > really doesn't make sense to forward, please drop it on the next > hop". but in the case of the Sec-Token-Binding header, the client > does not know whether it makes sense to forward or not. The client, > generally, does not know whether the proxy or TLS terminator > validates bindings, passes them along for the application server to > validate, or strips them altogether. > The Connection header is not particularly about proxies. It is simply about distinguishing hop-by-hop things from end-to-end so any naive/old HTTP recipient can keep the relevant data secure in a fail-closed way. Since the TLS is hop-by-hop the preferred behaviour ought to be a MUST/SHOULD for listing in Connection header to meet the RFC 7230 conditions. If the recipient happens to be TB-aware and non-validating (for any reason, not just TTRPs). Then RFC 7230 grants the ability to forward on both the Sec-Token-Binding and Connection:Sec-Token-Binding headers as being relevant to the next-hop it is using. ie. the "(or replace it with the intermediary's own connection options for the forwarded message)" clause is what applies to non-validating recipients. However the non-validating case should be an exception rather than the norm. Specifically called out as such for TTRPs etc. HTH Amos From nobody Thu Feb 9 11:25:42 2017 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 047A6129C59 for ; Thu, 9 Feb 2017 11:25:29 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 ERpyzq7zP8rA for ; Thu, 9 Feb 2017 11:25:27 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 57598129C5A for ; Thu, 9 Feb 2017 11:25:27 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id v23so13976688qtb.0 for ; Thu, 09 Feb 2017 11:25:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KziFjXTsuhJDs+uxYuPnLNZXkBW5ZtlG4S5vU/s4cds=; b=sxnc+lWj+lbsRa/RMc7X0mQG/mRPUzfIauAAE4mjDMzAjqVSOdW8diaV0FQS7yzmWD onqUnx5t2KSyxpdnHTff7cHGmVfen6ZDMLi+3Xk7iJN55Jqf6DsTFVD37dbzxGy3hg/O sAKERH+iTdHDAU2wrfvHeEUbQHGcnENGe4G3UjHHYH3YlRgdmNWD+Pt3+uO7L9Rmf6fA /uuByN1bj+F5cAgBpsDPviiW55e9yscKCSuE0hMCsHpZ4fJ6RfDkuXM5kwutilAU4z0R dq/rB4AD4O+n8/x73TxqLjJpAgFTJFCKWp+asakVbtNSIlQAGxcZi7POaU8bjrRnh/tw MZ7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KziFjXTsuhJDs+uxYuPnLNZXkBW5ZtlG4S5vU/s4cds=; b=FWe9DUQhDjKeWgbx2yBO2pEFn6GB95j1/1r0/d542FOQld/xXwxPtLsI0V8sKPI3zp 5zW9qgX1NnpRnJueGjt6Vgm9kM1pd85nyhDZgEdWX9Kiqtiwv53N6hmrK3GBPKVnjwsN ScRF4SMO/P625n+PU4as3F8iwjSZrHRq4B8DaTyIeTC2+q08x3qR0T3mWfcBMGvZFfX7 Cn0ee+zhk8u/LFSn7rS/hfKZ4bgDMYxetUPayRuHSPrhYrDuZm5bi9Tpfps73I2mcZmv hzKnuPcLET8PUHh/2NnQ+EzZyy9zjwopAGdMv2S6hiVdAv6KClivhn9Y68gz2u8w02+G VvoA== X-Gm-Message-State: AMke39nKMM8UD0Gshn7LiRJBBSGaMmYtoV2rQU+u8KwMvwcvfCmS/4ZSFLXk5sMySsPYC4vi X-Received: by 10.237.34.250 with SMTP id q55mr4851784qtc.127.1486668326246; Thu, 09 Feb 2017 11:25:26 -0800 (PST) Received: from [192.168.86.130] ([191.115.108.51]) by smtp.gmail.com with ESMTPSA id t2sm9981614qte.14.2017.02.09.11.25.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 11:25:25 -0800 (PST) From: John Bradley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_0E06F584-1AC6-417E-BA71-A5993185B08D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Feb 2017 16:24:42 -0300 In-Reply-To: To: Amos Jeffries References: <43DD0CF0-4043-448D-BE38-FAFFDE779B57@ve7jtb.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: unbearable@ietf.org Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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: Thu, 09 Feb 2017 19:25:29 -0000 X-List-Received-Date: Thu, 09 Feb 2017 19:25:29 -0000 --Apple-Mail=_0E06F584-1AC6-417E-BA71-A5993185B08D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 So it is valid in hop by hop for the proxy to pass on the original = header information as its own for the next hop if that is the correct = thing to do? I suppose that is largely what happens with keep-alive. To Andre=E2=80=99s point I understand that existing proxies wouldn't = negotiate token binding but we need to cover creative future = development. =20 If we lever it open for a proxy to negotiate token binding on one side = and pall along the header someone will do it and blame the spec as being = unclear. We would clearly never recommend that but won=E2=80=99t have direct = control over developers. John B. > On Feb 9, 2017, at 4:14 PM, Amos Jeffries = wrote: >=20 > On 9/02/2017 6:20 a.m., Andrei Popov wrote: >> =C3=98 The Connect header is for the client to tell a proxy "this = header >> really doesn't make sense to forward, please drop it on the next >> hop". =E2=80=A6but in the case of the Sec-Token-Binding header, the = client >> does not know whether it makes sense to forward or not. The client, >> generally, does not know whether the proxy or TLS terminator >> validates bindings, passes them along for the application server to >> validate, or strips them altogether. >>=20 >=20 > The Connection header is not particularly about proxies. It is simply > about distinguishing hop-by-hop things from end-to-end so any = naive/old > HTTP recipient can keep the relevant data secure in a fail-closed way. >=20 > Since the TLS is hop-by-hop the preferred behaviour ought to be a > MUST/SHOULD for listing in Connection header to meet the RFC 7230 > conditions. >=20 > If the recipient happens to be TB-aware and non-validating (for any > reason, not just TTRPs). Then RFC 7230 grants the ability to forward = on > both the Sec-Token-Binding and Connection:Sec-Token-Binding headers as > being relevant to the next-hop it is using. >=20 > ie. the "(or replace it with the intermediary's own connection options > for the forwarded message)" clause is what applies to non-validating > recipients. >=20 > However the non-validating case should be an exception rather than the > norm. Specifically called out as such for TTRPs etc. >=20 >=20 > HTH > Amos >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_0E06F584-1AC6-417E-BA71-A5993185B08D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILMTCCBUcw ggQvoAMCAQICEEAfBHP+tuqufC4R+F+Tu54wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAyIENsaWVudCBDQTAeFw0xNjA4MTIy MTE5NDFaFw0xODA4MTIyMTE5NDFaMIGCMQswCQYDVQQGEwJDTDEiMCAGA1UECAwZTWV0cm9wb2xp dGFuYSBkZSBTYW50aWFnbzEWMBQGA1UEBwwNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAwwMSm9obiBC cmFkbGV5MSAwHgYJKoZIhvcNAQkBFhF2ZTdqdGJAdmU3anRiLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALhTcSiDGvVrm4hlJA8WyFcWWe0dqnuJzstQYTaF281JFOEPA/13kQYI JMXAEUcS7NvW7KdUI0tHU0N6RTo0Ilf1E1nm8No++eqHO8pFUZ/cidpv0r+1Qcl9EgrpbZ00Y7Xg pq06EZELzJAmds4QQcsTKdpLNFbVcFnM11i2Gj5VNsYgO+qPO2AS8rLHkgDWnNkc9/lA+ZK5wGiU zxPU9KnIrERoTif3Zk7KjLvFpBWYD60M/lNoHZ5zxYgmYLmvoM1TSLn4Ms57wwT5MieV2l0aqlGC 7CKNa6XyeL1B0y0wSxL3PJQS4vSLDnttZC7od2A6yjeUMyM3rQ41vqUIMc8CAwEAAaOCAcMwggG/ MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUmA9bUmBmTYkCcZ3yYv8IRRP2nN4wHwYDVR0jBBgwFoAUmZerGDU6i1lFQ5iy cnHI9PsJzxYwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNz bC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGll bnQyLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xp ZW50Mi5jcmwwHAYDVR0RBBUwE4ERdmU3anRiQHZlN2p0Yi5jb20wIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMFUGA1UdIAROMEwwDAYKKwYBBAGBtTcGATA8BgsrBgEEAYG1NwEC BTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4IBAQBqcYJfFA/ITkX4L6JihqW168Wog1BOfkbPXO+wPn5G9P1NwruGfu41b70EPPwV vol+/j+qhSSrDjFyfNBsq4G45GRR6hwx0ei/bH0UW15Y63ASYPkNlj3ydCcvhw5ItWD5aYPphBx9 C7tLnQ7ow09cqt2CIgPd3W/IGri7p4hWPbdcX0oFIhJcDxmCwTcWyoVoIo4aas5gP44LPGneCoqI lXQMJinwneEnKd7rWXlzVWv7geaH3t79zARSw9ev9F4E61cDuHi+vgTFEpio7oxybqfj99yLibhX uZjReYnYbDMRiWDXduVIrIGYwmnUuD8a0b20kJgHm+FEgB6UMa9JMIIF4jCCA8qgAwIBAgIQXLZI bkcMmMZ/9oDbZErijTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1 WhcNMzAxMjE2MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDIgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7g9Q jJUJI4Ss9VBqj9Y3ok4h/TIJZUc+rzj61Rv3hNB/yeEEC1fz3i/EU+MXOOGxM7KCbtCIcJxHIW/k 8RP6sPPMO4cTg7sNzfBWsYsemtY6fN/kVr2R2X+/PjvtxmAaXpGX0znvQPxaE123IMGXy0zEKHZ/ nJDZ199TP9TNn9v+1QO0AZb4oaJ7ch0DpSJa8kF5xiNFDAg9taKKSrVuPHJL9MFFYPIqwShjHg+u YEzjfxbMP2QWwamnaA9Y7fORSDNapduFlARAcDtXdMpAijiG4HKnrN323I0Ka7lDTAWyLtTDCETK sI8fzOyL0inEu1WEVpdPytm8s1rwQB4f9QIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQr MCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRa MFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBSZl6sYNTqLWUVDmLJy ccj0+wnPFjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUd IAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4ICAQCZQUEEzvYk9U4wNHhDu1f9QGwbzAH4m4wIKH8ZidNYwZhyoNKW041iJ002KMW9 ywYM95n4770tT45yH29vTMlZtBvz0h44KuxMLNXRCTDwvV07sT39nPjFi5MpwZaLVueNiaa1vok1 n2Wn8lLcyCltYZNGAEifM0ko/A/vvckftFIZG75RAiZHYtfnrdBGiOxyF+nHI9a33BRX5Vl/3z0+ uHZ/Y6YPbNJ7iboOFrFZBCtt+lp3WaDB62ZoBewiMmd09JrqmMJAEgw3EbfQNtaPzHPg/EOhlZik Rgd4BCrzrbIqB2RKib+gnQJt2uoJaKOaV90S9Xgs3PC837OE9CEmY6/MTTG0xpbLh2hR/rLQ3sCr H56aODeuDrQBq85lXxRbDCERDUR7FZUhHv+i1aQaY59NPu26hDd6nqksSDq2mCddpidPBuGJz9lN X2nRyGkudDuWV6gIr6AZfaYv+ggTXOcCDJZFzMhWdLC7CPvRKxQ7vTiYV+4lgqOvV9MnZc149PPt itTysq/oOv70zx7q+tyaLTa4cqFhCclhIwSwOEJiV3xqQebvmwsDX7BaXGAJZIhbdUbNr3poEgct 6uAxw2zyr69WCJmTUUhz/k1/TT/eCUZJqnMg/6mje7tiVdaUQJcBtJ6cq5+mUDNUB1fohW8EOFai zFpP/0FaP62ctTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMiBDbGllbnQgQ0ECEEAfBHP+tuqufC4R+F+Tu54wCQYFKw4DAhoF AKCCAZkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjA5MTky NDQyWjAjBgkqhkiG9w0BCQQxFgQUGycZ/bmtZlFJPChpI3KIBdBhLYEwgZoGCSsGAQQBgjcQBDGB jDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIg Q2xpZW50IENBAhBAHwRz/rbqrnwuEfhfk7ueMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIgQ2xpZW50IENBAhBA HwRz/rbqrnwuEfhfk7ueMA0GCSqGSIb3DQEBAQUABIIBAC0OJkjikP0p8beBNCCwhF6yWTpCmVoi CT9yljYxd/qYBrwuKRuceBobCc5nHIh2fLKMT0oYiKl5F2sMYBxZGZF6S1nKWL85PcfGREkdH8F2 pLA74Qgkbxme5obZvG6/3GE9PV+rNftcNswMviQ+tyYKJG5sVKTPKn/qpBgNcPEOzcHA1okHxvH9 ExZ9A1hVbmIJuSm2aRf9Az6aaTIO8njSt465VVrrv4gjwhPRiS40ubhDvYHvMCk7MuxeRqEhLprp ux3RBU4jwxiRWYXg3U+ZQuVEqtiY18xIxtq2cZ5ktBDvIjRFzt+7rSFTLz69ulU8HsKd8ZVPDObZ da50oK8AAAAAAAA= --Apple-Mail=_0E06F584-1AC6-417E-BA71-A5993185B08D-- From nobody Thu Feb 9 11:49:45 2017 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 5E05D1294F4 for ; Thu, 9 Feb 2017 11:49:43 -0800 (PST) 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 cyDMS4PXV5Ca for ; Thu, 9 Feb 2017 11:49:42 -0800 (PST) Received: from treenet.co.nz (unknown [121.99.228.82]) by ietfa.amsl.com (Postfix) with ESMTP id ECB3612943A for ; Thu, 9 Feb 2017 11:49:41 -0800 (PST) Received: from [192.168.20.251] (unknown [121.98.40.15]) by treenet.co.nz (Postfix) with ESMTP id 7C200E6EBA for ; Fri, 10 Feb 2017 08:49:38 +1300 (NZDT) To: unbearable@ietf.org References: <43DD0CF0-4043-448D-BE38-FAFFDE779B57@ve7jtb.com> From: Amos Jeffries Message-ID: Date: Fri, 10 Feb 2017 08:48:55 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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: Thu, 09 Feb 2017 19:49:43 -0000 On 10/02/2017 8:24 a.m., John Bradley wrote: > So it is valid in hop by hop for the proxy to pass on the original > header information as its own for the next hop if that is the correct > thing to do? > > I suppose that is largely what happens with keep-alive. > Yes. The other parallel is the various Proxy-Auth* headers from RFC 7235. Which are defined explicitly as point-to-point (not quite hop-by-hop, so Connection entry is optional) then section 4.4 explicitly calls out the exception case: " ... When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first inbound proxy that was expecting to receive credentials. A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request. " This is almost exactly the same as the intended behaviour for the non-validating TTRP use case with Sec-Token-Binding. Amos From nobody Thu Feb 9 14:02:40 2017 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 E1935129CAC for ; Thu, 9 Feb 2017 14:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.889 X-Spam-Level: X-Spam-Status: No, score=-3.889 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=-1.887, 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 rSbSn-n2hO3A for ; Thu, 9 Feb 2017 14:02:38 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0106.outbound.protection.outlook.com [104.47.42.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ADAB1295DB for ; Thu, 9 Feb 2017 14:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rHCJ1Rp1Fbniy2fmJSg/Pc1Y935pVt5IV3nsy6L71ZI=; b=lGo411TRfK25frt6B7zqS9qh9p7Kd/FHimWoN5oaIgV7lLst/8ofGz2midsrl76Ef/tUghFwkew3VOFBjMZ/t5tD7FI024EOpxZ2nC5s6hv3p5q0I0kbS8EkLPF1+A4Yda+TEE/ZU9mIpUnnauYzyEPYba4eAsRucDxZrc+FPHw= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 9 Feb 2017 22:02:36 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.026; Thu, 9 Feb 2017 22:02:36 +0000 From: Andrei Popov To: Amos Jeffries , "unbearable@ietf.org" Thread-Topic: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? Thread-Index: AQHSgZVjoAIXC6BWu0OMPbiyGCJ7xqFeen4AgAC16ACAACoXcIABs6+AgAABzNA= Date: Thu, 9 Feb 2017 22:02:36 +0000 Message-ID: References: <43DD0CF0-4043-448D-BE38-FAFFDE779B57@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: 467ca159-bf41-4c66-18bb-08d451375bb5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0842; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 7:Ih6ZNwt42T+CLPj6C7OM/Y+THvOIkhKaOye/gvbCFuj26qg/XR/qju5M1N5tiJw3hwHSwMiX3BXeJQc8c+8Etaa01gDlTj5W8a6jOxzRJzYmIrUI4883OY9pwekfP3vJdBnimxoxGM9z7CDOYpe7p1X2hKg9z7TwmVoKIvQot5xCKFjFiSA+E2WIlGURKLZOW4tBJ9xCpdEjBIs3mKbqoOWJIZJ1A7SkZGwf9bJ0uF0mR/MU+R+FxCLWjWl/zcrR/A1PRB7Ptl2t1Z7ExHr1LDhgWxBN4vxNG/NhuKl6OKJWyuGAFin0MuNgz+smahoh5ogp3Lq6llUgvbXvVQ2NoJciV8zZtDIgUs8bv08PRtx65/bik3ZAdCUfuTClhuMXVyvELOkaNVZPwPoQMxRbHFGfOQrsJlL8p2o7KpTNCuzXSoXF19ZTVntxyQwv+MQ0bS5F+ieRmIqw8wROjiEb4G0euQRZExgG9lfBQh8BN1Im6cATOAb/Lv8GGADqXDBLdJx1a+6vDTbCEaJBuNKazjUJfk9fLk95VVo+GdyOYWw= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(20161123558025)(6072148); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39450400003)(39860400002)(39840400002)(199003)(189002)(230783001)(50986999)(54356999)(8676002)(76176999)(122556002)(106356001)(68736007)(9686003)(5005710100001)(8936002)(305945005)(97736004)(93886004)(8990500004)(74316002)(2900100001)(2950100002)(38730400002)(10290500002)(102836003)(7736002)(7696004)(3660700001)(6116002)(81156014)(189998001)(105586002)(101416001)(106116001)(81166006)(2906002)(53936002)(5660300001)(6506006)(55016002)(25786008)(3280700002)(33656002)(6436002)(77096006)(86612001)(2501003)(86362001)(10090500001)(92566002)(6246003)(229853002)(99286003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 09 Feb 2017 22:02:36.8157 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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: Thu, 09 Feb 2017 22:02:40 -0000 Hi Amos, > The Connection header is not particularly about proxies. It is simply abo= ut distinguishing hop-by-hop things from end-to-end so any naive/old HTTP r= ecipient can keep the relevant data secure in a fail-closed way. ...and TB can be handled hop-by-hop or passed on for subsequent validation;= both are valid use-cases. It would be a concern if the backend servers were to assume that any TB hea= der (and the contained TB message) floating around is always valid. Instead= what the specs currently say is that if you receive a TB message, you've g= ot to validate it before accepting a bound token. If validation fails, the = bound token is rejected.=20 It seems therefore that stripping TB headers does not "fail closed", but si= mply eliminates the possibility that the contained TB message may get verif= ied further down the line. It is true that a proxy could forward Sec-Token-Binding's contents as a cus= tom header, possibly specified in another document. This is a valid design;= I'm just not convinced that this should be the only possible design. Cheers, Andrei From nobody Fri Feb 10 15:36:49 2017 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 0F30912945F for ; Fri, 10 Feb 2017 15:36:47 -0800 (PST) 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 U1TsC12CV0S4 for ; Fri, 10 Feb 2017 15:36:45 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 1F6E1129409 for ; Fri, 10 Feb 2017 15:36:44 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id x49so49598182qtc.2 for ; Fri, 10 Feb 2017 15:36:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=vY7otFJzG+KWTu2JkNPJ3FJOFPn8tlhigziQgLG5IG0=; b=kMCzQD106hZimQ+UUJ57sTp7aMKWXqaqxwhpOD9raqHuuy/8onzMDoGWjat5ib+yVY tI5A9F3YizbKAXYHzNK6anhTbPlKc/txaM8IWz1Mp8UdBhG9YlbTBw5g9KyZWg0MwU+I xezGPz58jt8TObP8ejOSt5ekNyrBn/56m1IdN67v0T164XEz9lWtrPDasg6kpuTNVz74 YJMdmC39py8aPiNv6Mod30Vf5SOEVtgzl83Aer4pC8xbDfZOyyssR2JIqhxLS+ZeKJ9R nWuvxEX2KPNWfVj0w0STjzUKc35zwtDQsoo3AG6X5Ta+7FsXvifd+HlwvIVhGXtsJtro Qd4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=vY7otFJzG+KWTu2JkNPJ3FJOFPn8tlhigziQgLG5IG0=; b=LV8IH6HfO+h0wkYsmHVeEiXyoiWUO7Uhtc/vsxHzmnPurbjkn/E7w6yY97u/v42Qqi sbAzzoETJcmIcq+I0xTMsIfZIzhoNpQmsQZK2TYlX+r72iJ2JtUCgShByNN1vhq8QyA0 gdV8mIHOdtrvHH4ABawltSBaOg7+La/OWwqLAi3DJFa0mksfdX/3+VRUVNSoTGQ3lhHl T4rHqbfZBx8xG0VqTZl0jeqkxZkRqMJfP72Kp7+PhohKY71Wcd4wzDd+FTh90Whcd1m3 N92PBY2+RniWC5KRZIN3geubpiTqMPJ79f9DoRTKgjYbMmam5EPpObhVvf9jveP/lSYP pXrg== X-Gm-Message-State: AMke39kGMdQiLYpGucBkOW8AWmYKWBLg3aAmsQ+0AJfvNnumGlL7/WuIqVCs3W6em/O7ck7x X-Received: by 10.237.60.218 with SMTP id e26mr10768143qtf.208.1486769803847; Fri, 10 Feb 2017 15:36:43 -0800 (PST) Received: from [192.168.8.102] ([181.201.125.104]) by smtp.gmail.com with ESMTPSA id b1sm2624723qkc.33.2017.02.10.15.36.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 15:36:43 -0800 (PST) From: John Bradley Content-Type: multipart/signed; boundary="Apple-Mail=_002DEC7B-61EA-4045-A210-97A06466FC39"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <3187DE55-6ECD-4FBC-993B-46F9815A07B0@ve7jtb.com> Date: Fri, 10 Feb 2017 20:36:40 -0300 To: IETF TokBind WG X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Unbearable] forward proxies. 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: Fri, 10 Feb 2017 23:36:47 -0000 --Apple-Mail=_002DEC7B-61EA-4045-A210-97A06466FC39 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On a related proxy question. If a user agent connects to a forward proxy, all the connections may be = multiplexed over a single TLS connection. If the proxy negotiates token binding, should the user agent still use = different keys for each etld+1 or one for the proxy because there is = only one TLS connection or just refuse to negotiate token binding. The correct thing to do may depend on the sort of forward proxy it = is(Transparent SOCKS etc). We can leave it but someone may ask and having browsers be consistent = probably a good thing, John B. --Apple-Mail=_002DEC7B-61EA-4045-A210-97A06466FC39 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILMTCCBUcw ggQvoAMCAQICEEAfBHP+tuqufC4R+F+Tu54wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAyIENsaWVudCBDQTAeFw0xNjA4MTIy MTE5NDFaFw0xODA4MTIyMTE5NDFaMIGCMQswCQYDVQQGEwJDTDEiMCAGA1UECAwZTWV0cm9wb2xp dGFuYSBkZSBTYW50aWFnbzEWMBQGA1UEBwwNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAwwMSm9obiBC cmFkbGV5MSAwHgYJKoZIhvcNAQkBFhF2ZTdqdGJAdmU3anRiLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALhTcSiDGvVrm4hlJA8WyFcWWe0dqnuJzstQYTaF281JFOEPA/13kQYI JMXAEUcS7NvW7KdUI0tHU0N6RTo0Ilf1E1nm8No++eqHO8pFUZ/cidpv0r+1Qcl9EgrpbZ00Y7Xg pq06EZELzJAmds4QQcsTKdpLNFbVcFnM11i2Gj5VNsYgO+qPO2AS8rLHkgDWnNkc9/lA+ZK5wGiU zxPU9KnIrERoTif3Zk7KjLvFpBWYD60M/lNoHZ5zxYgmYLmvoM1TSLn4Ms57wwT5MieV2l0aqlGC 7CKNa6XyeL1B0y0wSxL3PJQS4vSLDnttZC7od2A6yjeUMyM3rQ41vqUIMc8CAwEAAaOCAcMwggG/ MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUmA9bUmBmTYkCcZ3yYv8IRRP2nN4wHwYDVR0jBBgwFoAUmZerGDU6i1lFQ5iy cnHI9PsJzxYwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNz bC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGll bnQyLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xp ZW50Mi5jcmwwHAYDVR0RBBUwE4ERdmU3anRiQHZlN2p0Yi5jb20wIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMFUGA1UdIAROMEwwDAYKKwYBBAGBtTcGATA8BgsrBgEEAYG1NwEC BTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4IBAQBqcYJfFA/ITkX4L6JihqW168Wog1BOfkbPXO+wPn5G9P1NwruGfu41b70EPPwV vol+/j+qhSSrDjFyfNBsq4G45GRR6hwx0ei/bH0UW15Y63ASYPkNlj3ydCcvhw5ItWD5aYPphBx9 C7tLnQ7ow09cqt2CIgPd3W/IGri7p4hWPbdcX0oFIhJcDxmCwTcWyoVoIo4aas5gP44LPGneCoqI lXQMJinwneEnKd7rWXlzVWv7geaH3t79zARSw9ev9F4E61cDuHi+vgTFEpio7oxybqfj99yLibhX uZjReYnYbDMRiWDXduVIrIGYwmnUuD8a0b20kJgHm+FEgB6UMa9JMIIF4jCCA8qgAwIBAgIQXLZI bkcMmMZ/9oDbZErijTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1 WhcNMzAxMjE2MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDIgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7g9Q jJUJI4Ss9VBqj9Y3ok4h/TIJZUc+rzj61Rv3hNB/yeEEC1fz3i/EU+MXOOGxM7KCbtCIcJxHIW/k 8RP6sPPMO4cTg7sNzfBWsYsemtY6fN/kVr2R2X+/PjvtxmAaXpGX0znvQPxaE123IMGXy0zEKHZ/ nJDZ199TP9TNn9v+1QO0AZb4oaJ7ch0DpSJa8kF5xiNFDAg9taKKSrVuPHJL9MFFYPIqwShjHg+u YEzjfxbMP2QWwamnaA9Y7fORSDNapduFlARAcDtXdMpAijiG4HKnrN323I0Ka7lDTAWyLtTDCETK sI8fzOyL0inEu1WEVpdPytm8s1rwQB4f9QIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQr MCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRa MFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBSZl6sYNTqLWUVDmLJy ccj0+wnPFjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUd IAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4ICAQCZQUEEzvYk9U4wNHhDu1f9QGwbzAH4m4wIKH8ZidNYwZhyoNKW041iJ002KMW9 ywYM95n4770tT45yH29vTMlZtBvz0h44KuxMLNXRCTDwvV07sT39nPjFi5MpwZaLVueNiaa1vok1 n2Wn8lLcyCltYZNGAEifM0ko/A/vvckftFIZG75RAiZHYtfnrdBGiOxyF+nHI9a33BRX5Vl/3z0+ uHZ/Y6YPbNJ7iboOFrFZBCtt+lp3WaDB62ZoBewiMmd09JrqmMJAEgw3EbfQNtaPzHPg/EOhlZik Rgd4BCrzrbIqB2RKib+gnQJt2uoJaKOaV90S9Xgs3PC837OE9CEmY6/MTTG0xpbLh2hR/rLQ3sCr H56aODeuDrQBq85lXxRbDCERDUR7FZUhHv+i1aQaY59NPu26hDd6nqksSDq2mCddpidPBuGJz9lN X2nRyGkudDuWV6gIr6AZfaYv+ggTXOcCDJZFzMhWdLC7CPvRKxQ7vTiYV+4lgqOvV9MnZc149PPt itTysq/oOv70zx7q+tyaLTa4cqFhCclhIwSwOEJiV3xqQebvmwsDX7BaXGAJZIhbdUbNr3poEgct 6uAxw2zyr69WCJmTUUhz/k1/TT/eCUZJqnMg/6mje7tiVdaUQJcBtJ6cq5+mUDNUB1fohW8EOFai zFpP/0FaP62ctTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMiBDbGllbnQgQ0ECEEAfBHP+tuqufC4R+F+Tu54wCQYFKw4DAhoF AKCCAZkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjEwMjMz NjQwWjAjBgkqhkiG9w0BCQQxFgQU+4oyxOiV5SFKwYE/VSz/STLaNHUwgZoGCSsGAQQBgjcQBDGB jDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIg Q2xpZW50IENBAhBAHwRz/rbqrnwuEfhfk7ueMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIgQ2xpZW50IENBAhBA HwRz/rbqrnwuEfhfk7ueMA0GCSqGSIb3DQEBAQUABIIBAFJjBkAnFLreOfq3zsb+5aE/zX/gcXUG UeLnSfW2QwutCxlEFUmjK3wzDFfFM7r38m632ty6WuXqRJT4nfj396iAItPhkxxARpfPzbx665oW CVL/DfPo7CTekkn1S4+jNSdLQDarQMIPFmnPi1elFcgZlA1XJmFRz5GSR9fH8Hg8hBWvTcwtVOZo zCSjgrOLvtJxEoL2HFA1rZOKIKdylKB99fJPaAGONW0iN8/UsRD/6RUDLQFdTzRRiTkmk9rKwuWo HnoXa87ObpDUUd8QQX9mVM6amHavgI0fhurW8jvvPpx9X0HDW5QRv/2XrzTNVAyFiH9nT3JC5F7v 8c2AJ48AAAAAAAA= --Apple-Mail=_002DEC7B-61EA-4045-A210-97A06466FC39-- From nobody Fri Feb 10 17:29:24 2017 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 86719129539 for ; Fri, 10 Feb 2017 17:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIKESa3bF9Vp for ; Fri, 10 Feb 2017 17:29:22 -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 9CEFE129533 for ; Fri, 10 Feb 2017 17:29:22 -0800 (PST) Received: (qmail 20962 invoked by uid 0); 11 Feb 2017 01:29:16 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 11 Feb 2017 01:29:16 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id jDVD1u0062UhLwi01DVGi1; Fri, 10 Feb 2017 18:29:16 -0700 X-Authority-Analysis: v=2.1 cv=H5NInYoi 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=n2v9WMKugxEA:10 a=9g655wywuj3CFPDTDVEA:9 a=QEXdDO2ut3YA:10 Received: from [173.224.162.69] (port=2218 helo=[10.225.80.49]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1ccMUz-00058L-5M for unbearable@ietf.org; Fri, 10 Feb 2017 18:29:13 -0700 To: IETF TokBind WG From: =JeffH Message-ID: Date: Fri, 10 Feb 2017 17:29:11 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 173.224.162.69 X-Exim-ID: 1ccMUz-00058L-5M X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.225.80.49]) [173.224.162.69]:2218 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 1 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: [Unbearable] TTRPs supporting TB on both upstream and downstream sides? 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: Sat, 11 Feb 2017 01:29:23 -0000 Do TLS Terminating Reverse Proxies (TTRPs) have any need to negotiate Token Binding (TB) between themselves and backend origin servers (this scenario assumes TLS comms between a TTRP and origin servers)? I.E.: TB-wielding TB-wielding TB-wielding client <---------------> TTRP <---------------> Origin Server [TLS W/TB] [TLS W/TB] ..where the client negotiates TB with the TTRP, and the TTRP in turn negotiates TB with the Origin server. This implies that there may be security tokens that the TTRP itself uses with the origin server. Should we be anticipating this scenario as a use case? Note: this question is orthogonal to whether the TTRP is also forwarding the client's Sec-Token-Binding header to the origin server or not. Thanks, =JeffH From nobody Sat Feb 11 05:54:34 2017 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 1965C1297C9 for ; Sat, 11 Feb 2017 05:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 FLFDE5RzTQQf for ; Sat, 11 Feb 2017 05:54:31 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 85C86129488 for ; Sat, 11 Feb 2017 05:54:31 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id w75so34253342ywg.1 for ; Sat, 11 Feb 2017 05:54:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VCNhXIQPfkMmls7nHWoiNQCpfhWTYsNrPQRRp1oBMwg=; b=PI+wZkSqHv5BfZ1MFYc/4pweCEbqtiWHx5M2jhgOlRUjQtrL6KasgaFYpBE+Qyt4gy V8ORI5TP1+xtmJnrEHbOlUJ3u7H/cc4usK8oyjcupVDkCwGPLucU8VoGUtkI2uACwEnj wsB4HBoH4uvUCL/5NIdoyGI7Tr8uxFZ/ka+ps= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VCNhXIQPfkMmls7nHWoiNQCpfhWTYsNrPQRRp1oBMwg=; b=At3z5MG/Kbs9p3zmc/23ARSM/I20TFs2Yh2ANEtfEV2eOcUrPqw+EJNIlliwzNTPfR aFjvC/PEeVuJHzUqaSF2mmmnezY67HkAGuzCKGRvXtzZ05OUfzlr0+fdSECsJID0zmfK h/+0QHsCpnUIgVw27wg8leDRNyc9iqCakLbNsYeOO3da50SnO72GWnZQawDUhjJJW27X Rno5waLBIawpsY//hqdTYyREw9Q97jV+/ZPDMX+QRIDJJNEsyJOGZ6nRXUd5hIzXAmjd dUv/RGAM2tyz8I9mU+u8eVf4iE6oVZasF8chhISJUbJFwCpQzXVEt1UAB2ilJmihLQBA H73A== X-Gm-Message-State: AMke39kNkfeDzqGX7t1Tsv4QP/N8fC6WJM9wWB+gEwh5FHddMSkcMao4gCB+9sxNs6tWAOOcuHwTCVZeaKAZlfsY X-Received: by 10.129.174.90 with SMTP id g26mr11431675ywk.25.1486821270568; Sat, 11 Feb 2017 05:54:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.126.131 with HTTP; Sat, 11 Feb 2017 05:54:00 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Sat, 11 Feb 2017 06:54:00 -0700 Message-ID: To: "=JeffH" Content-Type: multipart/alternative; boundary=f403045f719aad7cba0548418d62 Archived-At: Cc: IETF TokBind WG Subject: Re: [Unbearable] TTRPs supporting TB on both upstream and downstream sides? 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: Sat, 11 Feb 2017 13:54:33 -0000 --f403045f719aad7cba0548418d62 Content-Type: text/plain; charset=UTF-8 In short, I don't think it's a use case with sufficient validity that we should complicate things trying to support. The primary value of Token Binding is preventing replay of exported/stolen security tokens that are dynamically issued to end user applications (potentially huge numbers of such applications). Web browsers and binding of cookies being the canonical example. Things certainly need to be secured between a TTRP and origin server and TLS may well be used between the two. But the dynamic nature of Token Binding seems ill-suited for use between pieces of infrastructure where existing authentication mechanisms, like TLS client auth for example, would be more appropriate. On Fri, Feb 10, 2017 at 6:29 PM, =JeffH wrote: > Do TLS Terminating Reverse Proxies (TTRPs) have any need to negotiate > Token Binding (TB) between themselves and backend origin servers (this > scenario assumes TLS comms between a TTRP and origin servers)? > > I.E.: > > TB-wielding TB-wielding TB-wielding > client <---------------> TTRP <---------------> Origin Server > [TLS W/TB] [TLS W/TB] > > ..where the client negotiates TB with the TTRP, and the TTRP in turn > negotiates TB with the Origin server. This implies that there may be > security tokens that the TTRP itself uses with the origin server. > > Should we be anticipating this scenario as a use case? > > Note: this question is orthogonal to whether the TTRP is also forwarding > the client's Sec-Token-Binding header to the origin server or not. > > Thanks, > > =JeffH > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --f403045f719aad7cba0548418d62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In short, I don't think it's a use case with suffi= cient validity that we should complicate things trying to support.
=
The primary value of Token Binding is preventing replay of exported/sto= len security tokens that are dynamically issued to end user applications (p= otentially huge numbers of such applications). Web browsers and binding of = cookies being the canonical example. Things certainly need to be secured be= tween a TTRP and origin server and TLS may well be used between the two. Bu= t the dynamic nature of Token Binding seems ill-suited for use between piec= es of infrastructure where existing authentication mechanisms, like TLS cli= ent auth for example, would be more appropriate.

On Fri, Feb 10, 2017 at 6:2= 9 PM, =3DJeffH <Jeff.Hodges@kingsmountain.com> w= rote:
Do TLS Terminating Reverse Proxies = (TTRPs) have any need to negotiate Token Binding (TB) between themselves an= d backend origin servers (this scenario assumes TLS comms between a TTRP an= d origin servers)?

I.E.:

TB-wielding=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TB= -wielding=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0TB-wielding
client=C2=A0 =C2=A0<--------------->=C2=A0 TTRP=C2=A0 =C2=A0 =C2=A0&l= t;--------------->=C2=A0 Origin Server
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [TLS W/TB]=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[TLS W/TB]

..where the client negotiates TB with the TTRP, and the TTRP in turn negoti= ates TB with the Origin server.=C2=A0 This implies that there may be securi= ty tokens that the TTRP itself uses with the origin server.

Should we be anticipating this scenario as a use case?

Note: this question is orthogonal to whether the TTRP is also forwarding th= e client's Sec-Token-Binding header to the origin server or not.

Thanks,

=3DJeffH

_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearabl= e

--f403045f719aad7cba0548418d62-- From nobody Sat Feb 11 06:57:23 2017 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 7147E1297F1 for ; Sat, 11 Feb 2017 06:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 3_0n1F39j8fI for ; Sat, 11 Feb 2017 06:57:20 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d: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 551A5129614 for ; Sat, 11 Feb 2017 06:57:20 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id 11so64116275qkl.3 for ; Sat, 11 Feb 2017 06:57:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4HDU0XlgoMu+07ID0UOtwsjBMTdfQFI9MU6pJm4sKvk=; b=FtrzA4T1IAm2JvuPVwitCBxOiKrHzWOeYSafmbOatqT0XRqDlC5Kbk9J/eXriwbxUu ZAk/+Gohhva5VPX1ElFErrZhYxmIzVXVWpUoI6RymW82ubZQHuzj4lK1fL3FjAXjznkU DROpq3DSKwnNehdc1E5O9IWrOaLYwFn2PspGixPGE4FhoamMbSpEAal4qPmOMEbEMXuQ XVsbC+omOhEVDUuQBP1nHWsrfKX6ZHcIMvopgVEa+/fLyIWbWNND7fI+iQGbNwhhkAnI PgUKxmc31FXWyTLuNPz3+y+tp2PEL26uSrbLvfoG7bgCLLZ344hfTWr5dS0PhpumSpM4 EnrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4HDU0XlgoMu+07ID0UOtwsjBMTdfQFI9MU6pJm4sKvk=; b=frQ0DNfrWredgjmuLfbnhehbLvpMU3CZMztEjwSHojg0s/3Ldn7A90gUkR2lsXbUO9 LX7Cwu5xG4jygv04P/KvngyHMLKqORiYmpaYMUfZ8wqv2B8zauzXXp+gM8m6ZZI3R5Qg wAopajeSYsZ5OKP3BbfmFVlBfG8i+GwporJLrFrBalm5rTx2F5TAB/DAUPmmIr5KRjlg befSoOj5hcIQop3yqDJigNGtLqGAtbfBkoV38v7pTrQ0j0vTtRXWQYSkI+qQvpPM7jlw vJZ9G6vWOAlF9g3ve41gOSxgwE1C7jSilI2QV1LxBQoInGtEAZ/iBt+9QS10mOpDqUPZ vo+A== X-Gm-Message-State: AMke39m7sLGWtCqZX04DJjJDMOH2R6S2tUzicpirAuAkqUhC8iuJgwwR8LKENrhOJeGhYKAk X-Received: by 10.55.114.132 with SMTP id n126mr13450311qkc.112.1486825039331; Sat, 11 Feb 2017 06:57:19 -0800 (PST) Received: from jbradley-r.lan ([191.115.249.3]) by smtp.gmail.com with ESMTPSA id o99sm2134958qkh.51.2017.02.11.06.57.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Feb 2017 06:57:18 -0800 (PST) From: John Bradley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1A245517-9C3B-498D-92E1-6FC9732D7CC6"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sat, 11 Feb 2017 11:56:50 -0300 In-Reply-To: To: Brian Campbell References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF TokBind WG , =JeffH Hodges Subject: Re: [Unbearable] TTRPs supporting TB on both upstream and downstream sides? 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: Sat, 11 Feb 2017 14:57:22 -0000 --Apple-Mail=_1A245517-9C3B-498D-92E1-6FC9732D7CC6 Content-Type: multipart/alternative; boundary="Apple-Mail=_6B4B077D-5F21-4655-8799-B0F6E89FD06F" --Apple-Mail=_6B4B077D-5F21-4655-8799-B0F6E89FD06F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In general for the reverse proxy case I agree with Brian. I suspect it = is more likely for the proxy to be at a network boundary and not do tls = inside, or to be in the =E2=80=9Ccloud=E2=80=9D and do mutual TLS back = to the servers. John B. > On Feb 11, 2017, at 10:54 AM, Brian Campbell = wrote: >=20 > In short, I don't think it's a use case with sufficient validity that = we should complicate things trying to support. >=20 > The primary value of Token Binding is preventing replay of = exported/stolen security tokens that are dynamically issued to end user = applications (potentially huge numbers of such applications). Web = browsers and binding of cookies being the canonical example. Things = certainly need to be secured between a TTRP and origin server and TLS = may well be used between the two. But the dynamic nature of Token = Binding seems ill-suited for use between pieces of infrastructure where = existing authentication mechanisms, like TLS client auth for example, = would be more appropriate.=20 >=20 > On Fri, Feb 10, 2017 at 6:29 PM, =3DJeffH = > = wrote: > Do TLS Terminating Reverse Proxies (TTRPs) have any need to negotiate = Token Binding (TB) between themselves and backend origin servers (this = scenario assumes TLS comms between a TTRP and origin servers)? >=20 > I.E.: >=20 > TB-wielding TB-wielding TB-wielding > client <---------------> TTRP <---------------> Origin Server > [TLS W/TB] [TLS W/TB] >=20 > ..where the client negotiates TB with the TTRP, and the TTRP in turn = negotiates TB with the Origin server. This implies that there may be = security tokens that the TTRP itself uses with the origin server. >=20 > Should we be anticipating this scenario as a use case? >=20 > Note: this question is orthogonal to whether the TTRP is also = forwarding the client's Sec-Token-Binding header to the origin server or = not. >=20 > Thanks, >=20 > =3DJeffH >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable = >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_6B4B077D-5F21-4655-8799-B0F6E89FD06F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In general for the reverse proxy case I agree with Brian. =   I suspect it is more likely for the proxy to be at a network = boundary and not do tls inside, or to be in the =E2=80=9Ccloud=E2=80=9D = and do mutual TLS back to the servers.

John B.

On = Feb 11, 2017, at 10:54 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

In short, I don't think it's a use case with sufficient = validity that we should complicate things trying to support.

The primary value of Token = Binding is preventing replay of exported/stolen security tokens that are = dynamically issued to end user applications (potentially huge numbers of = such applications). Web browsers and binding of cookies being the = canonical example. Things certainly need to be secured between a TTRP = and origin server and TLS may well be used between the two. But the = dynamic nature of Token Binding seems ill-suited for use between pieces = of infrastructure where existing authentication mechanisms, like TLS = client auth for example, would be more appropriate.

On Fri, Feb 10, 2017 at 6:29 PM, =3DJeffH <Jeff.Hodges@kingsmountain.com> wrote:
Do TLS Terminating = Reverse Proxies (TTRPs) have any need to negotiate Token Binding (TB) = between themselves and backend origin servers (this scenario assumes TLS = comms between a TTRP and origin servers)?

I.E.:

TB-wielding                =  TB-wielding                =    TB-wielding
client   <--------------->  TTRP    =  <--------------->  Origin Server
            [TLS W/TB]      =              [TLS W/TB]

..where the client negotiates TB with the TTRP, and the TTRP in turn = negotiates TB with the Origin server.  This implies that there may = be security tokens that the TTRP itself uses with the origin server.

Should we be anticipating this scenario as a use case?

Note: this question is orthogonal to whether the TTRP is also forwarding = the client's Sec-Token-Binding header to the origin server or not.

Thanks,

=3DJeffH

_______________________________________________
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

= --Apple-Mail=_6B4B077D-5F21-4655-8799-B0F6E89FD06F-- --Apple-Mail=_1A245517-9C3B-498D-92E1-6FC9732D7CC6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILMTCCBUcw ggQvoAMCAQICEEAfBHP+tuqufC4R+F+Tu54wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAyIENsaWVudCBDQTAeFw0xNjA4MTIy MTE5NDFaFw0xODA4MTIyMTE5NDFaMIGCMQswCQYDVQQGEwJDTDEiMCAGA1UECAwZTWV0cm9wb2xp dGFuYSBkZSBTYW50aWFnbzEWMBQGA1UEBwwNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAwwMSm9obiBC cmFkbGV5MSAwHgYJKoZIhvcNAQkBFhF2ZTdqdGJAdmU3anRiLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALhTcSiDGvVrm4hlJA8WyFcWWe0dqnuJzstQYTaF281JFOEPA/13kQYI JMXAEUcS7NvW7KdUI0tHU0N6RTo0Ilf1E1nm8No++eqHO8pFUZ/cidpv0r+1Qcl9EgrpbZ00Y7Xg pq06EZELzJAmds4QQcsTKdpLNFbVcFnM11i2Gj5VNsYgO+qPO2AS8rLHkgDWnNkc9/lA+ZK5wGiU zxPU9KnIrERoTif3Zk7KjLvFpBWYD60M/lNoHZ5zxYgmYLmvoM1TSLn4Ms57wwT5MieV2l0aqlGC 7CKNa6XyeL1B0y0wSxL3PJQS4vSLDnttZC7od2A6yjeUMyM3rQ41vqUIMc8CAwEAAaOCAcMwggG/ MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUmA9bUmBmTYkCcZ3yYv8IRRP2nN4wHwYDVR0jBBgwFoAUmZerGDU6i1lFQ5iy cnHI9PsJzxYwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNz bC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGll bnQyLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xp ZW50Mi5jcmwwHAYDVR0RBBUwE4ERdmU3anRiQHZlN2p0Yi5jb20wIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMFUGA1UdIAROMEwwDAYKKwYBBAGBtTcGATA8BgsrBgEEAYG1NwEC BTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4IBAQBqcYJfFA/ITkX4L6JihqW168Wog1BOfkbPXO+wPn5G9P1NwruGfu41b70EPPwV vol+/j+qhSSrDjFyfNBsq4G45GRR6hwx0ei/bH0UW15Y63ASYPkNlj3ydCcvhw5ItWD5aYPphBx9 C7tLnQ7ow09cqt2CIgPd3W/IGri7p4hWPbdcX0oFIhJcDxmCwTcWyoVoIo4aas5gP44LPGneCoqI lXQMJinwneEnKd7rWXlzVWv7geaH3t79zARSw9ev9F4E61cDuHi+vgTFEpio7oxybqfj99yLibhX uZjReYnYbDMRiWDXduVIrIGYwmnUuD8a0b20kJgHm+FEgB6UMa9JMIIF4jCCA8qgAwIBAgIQXLZI bkcMmMZ/9oDbZErijTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1 WhcNMzAxMjE2MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDIgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7g9Q jJUJI4Ss9VBqj9Y3ok4h/TIJZUc+rzj61Rv3hNB/yeEEC1fz3i/EU+MXOOGxM7KCbtCIcJxHIW/k 8RP6sPPMO4cTg7sNzfBWsYsemtY6fN/kVr2R2X+/PjvtxmAaXpGX0znvQPxaE123IMGXy0zEKHZ/ nJDZ199TP9TNn9v+1QO0AZb4oaJ7ch0DpSJa8kF5xiNFDAg9taKKSrVuPHJL9MFFYPIqwShjHg+u YEzjfxbMP2QWwamnaA9Y7fORSDNapduFlARAcDtXdMpAijiG4HKnrN323I0Ka7lDTAWyLtTDCETK sI8fzOyL0inEu1WEVpdPytm8s1rwQB4f9QIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQr MCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRa MFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBSZl6sYNTqLWUVDmLJy ccj0+wnPFjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUd IAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4ICAQCZQUEEzvYk9U4wNHhDu1f9QGwbzAH4m4wIKH8ZidNYwZhyoNKW041iJ002KMW9 ywYM95n4770tT45yH29vTMlZtBvz0h44KuxMLNXRCTDwvV07sT39nPjFi5MpwZaLVueNiaa1vok1 n2Wn8lLcyCltYZNGAEifM0ko/A/vvckftFIZG75RAiZHYtfnrdBGiOxyF+nHI9a33BRX5Vl/3z0+ uHZ/Y6YPbNJ7iboOFrFZBCtt+lp3WaDB62ZoBewiMmd09JrqmMJAEgw3EbfQNtaPzHPg/EOhlZik Rgd4BCrzrbIqB2RKib+gnQJt2uoJaKOaV90S9Xgs3PC837OE9CEmY6/MTTG0xpbLh2hR/rLQ3sCr H56aODeuDrQBq85lXxRbDCERDUR7FZUhHv+i1aQaY59NPu26hDd6nqksSDq2mCddpidPBuGJz9lN X2nRyGkudDuWV6gIr6AZfaYv+ggTXOcCDJZFzMhWdLC7CPvRKxQ7vTiYV+4lgqOvV9MnZc149PPt itTysq/oOv70zx7q+tyaLTa4cqFhCclhIwSwOEJiV3xqQebvmwsDX7BaXGAJZIhbdUbNr3poEgct 6uAxw2zyr69WCJmTUUhz/k1/TT/eCUZJqnMg/6mje7tiVdaUQJcBtJ6cq5+mUDNUB1fohW8EOFai zFpP/0FaP62ctTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMiBDbGllbnQgQ0ECEEAfBHP+tuqufC4R+F+Tu54wCQYFKw4DAhoF AKCCAZkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjExMTQ1 NjUxWjAjBgkqhkiG9w0BCQQxFgQU6I4H3WbzzFcanyAnRoWOfgfrT9UwgZoGCSsGAQQBgjcQBDGB jDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIg Q2xpZW50IENBAhBAHwRz/rbqrnwuEfhfk7ueMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIgQ2xpZW50IENBAhBA HwRz/rbqrnwuEfhfk7ueMA0GCSqGSIb3DQEBAQUABIIBAGwCWVZy7bQsS3E71NvsbEzyrDHvaS90 h+n9Bpt1s0zOm/N+TYVYtQnWkSeWax+zI4gUGsARNZ5l4ZE5MpCpE1SQLM7vsvRYJ1UKRTdn5kUb +ESjrN7dfGmEnACA4cHX5wJFDWPwD0Ics7RHpcYv7+FqTD/xSVTMD+t2PqmGbiuYOkeZRY1MdADH yddB/lS3drDRhjM8i93r9BgiWxDwd/l/LxZT5gGDFShzPbDs6K79BNWUyalwLLQzz+GGzYZOYXKl djvqnG4pRIffRZUet9elckhD/kLargVmoSqSIGpQyZH0L/gbuohrzX99pUTrvZ6dJ2QkZ9aFVUXG jbanF/oAAAAAAAA= --Apple-Mail=_1A245517-9C3B-498D-92E1-6FC9732D7CC6-- From nobody Sat Feb 11 10:56:23 2017 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 33F5D12941A for ; Sat, 11 Feb 2017 10:56:22 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 D7b17JwhMmMu for ; Sat, 11 Feb 2017 10:56:20 -0800 (PST) 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 2F672129485 for ; Sat, 11 Feb 2017 10:56:20 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id j13so70594047iod.3 for ; Sat, 11 Feb 2017 10:56:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=xldjdFb8n6MBjErnz8kQTJ1AoajkiBy0oAEgJvM5+X8=; b=a63FSdAh51LvRzRS1v3xTo8pWNbLDBa7JvOEMynWbzEuk2R/lVprC6DO8k1LgeQJql +wyMFGKwpk9/FQCx2cDzD14zWZqz+O/2nJGN3E5irnBU25lvcq9yge5XfLOF8mIYIUFl h2DasazL8szbiX0cQXmZvLZl4aCvFCmB+1Gd/wcMKSqCcQmGUuhj8UFnlFXT0io+7gop x5eInTgyPqVgZCFkIgoigCf0rN+t2a9W5jUmEhQULNsfz1FHmcKDc+YVkskikbd0s395 YHTlUqSCFuADzBQcmjjV+0F59KbaMU+WL5So1RnxJ99IA2EPnYeXeKORcEOUFEGaAWOk XBjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=xldjdFb8n6MBjErnz8kQTJ1AoajkiBy0oAEgJvM5+X8=; b=d77qe4keYb/WtsjP8bNZdCgvmvaebFyril2FAz6a7YlfPJPdF/y4o4PTYi47PrOpSZ j6QtRckQ3o+0Fa7W4Fw+tf0AXW5wXMurXdodLJri1Ay8I+MC/gwZRLSQe0num9ynTPiR ZypnC2bYU2fUWjhusFfOXxstg2jbrbSe3vDcgZnxsP3xZ4TgMaHc8h9k/QMec6MxHwyY Xj4pdTh2tVwJn6LOtitC09DDf+VUw5zyK8/7ygIPvT9HwgCuCjW8kaCixrMtW30pO6Ta 9uV8NvUoo9O6h/d8g6vnIEuhLZ78JwE9lTXasiODJyvpxK11JQywDWruQYJO0nl/E2r4 euxw== X-Gm-Message-State: AMke39l/yXIq/n7A0twX3WsdGxbEk8+7zkEgC8Otz5Tjf/t4Ak41ny7JS2NDHoVvYXRTBcslBAMSihIvVkggxRs9 X-Received: by 10.107.7.78 with SMTP id 75mr16862492ioh.165.1486839378890; Sat, 11 Feb 2017 10:56:18 -0800 (PST) MIME-Version: 1.0 References: <3187DE55-6ECD-4FBC-993B-46F9815A07B0@ve7jtb.com> In-Reply-To: <3187DE55-6ECD-4FBC-993B-46F9815A07B0@ve7jtb.com> From: Dirk Balfanz Date: Sat, 11 Feb 2017 18:56:08 +0000 Message-ID: To: John Bradley , IETF TokBind WG Content-Type: multipart/alternative; boundary=001a113f98d2049e1d054845c5f7 Archived-At: Subject: Re: [Unbearable] forward proxies. 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: Sat, 11 Feb 2017 18:56:22 -0000 --001a113f98d2049e1d054845c5f7 Content-Type: text/plain; charset=UTF-8 That's the kind of scenario that makes TokenBinding better than ChannelID. The browser can use different keys on different HTTP requests, including here, where it would be using different keys for different destination servers. Now, a forward proxy may not have the necessary relationships with the downstream servers to communicate the Token Binding IDs securely, so chances are that all the Token Binding is for naught in this case. But you'll never know. Dirk. On Fri, Feb 10, 2017 at 3:36 PM John Bradley wrote: On a related proxy question. If a user agent connects to a forward proxy, all the connections may be multiplexed over a single TLS connection. If the proxy negotiates token binding, should the user agent still use different keys for each etld+1 or one for the proxy because there is only one TLS connection or just refuse to negotiate token binding. The correct thing to do may depend on the sort of forward proxy it is(Transparent SOCKS etc). We can leave it but someone may ask and having browsers be consistent probably a good thing, John B. _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable --001a113f98d2049e1d054845c5f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's the kind o= f scenario that makes TokenBinding better than ChannelID. The browser can u= se different keys on different HTTP requests, including here, where it woul= d be using different keys for different destination servers.

Now, a for= ward proxy may not have the necessary relationships with the downstream ser= vers to communicate the Token Binding IDs securely, so chances are that all= the Token Binding is for naught in this case. But you'll never know.

Dirk.
=

On Fri, Feb 10, 2017 at 3:36 PM John Bradley &= lt;ve7jtb@ve7jtb.com> wrote:
On a related proxy question.

If a user agent connects to a forward proxy, all the connections may be mul= tiplexed over a single TLS connection.

If the proxy negotiates token binding, should the user agent still use diff= erent keys for each etld+1 or one for the proxy because there is only one T= LS connection or just refuse to negotiate token binding.

The correct thing to do may depend on the sort of forward proxy it is(Trans= parent SOCKS etc).

We can leave it but someone may ask and having browsers be consistent proba= bly a good thing,

John B.


_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/lis= tinfo/unbearable
--001a113f98d2049e1d054845c5f7-- From nobody Sat Feb 11 17:43:22 2017 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 49B991294DC for ; Sat, 11 Feb 2017 17:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihwqNds4dlGk for ; Sat, 11 Feb 2017 17:43:20 -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 306901294D4 for ; Sat, 11 Feb 2017 17:43:20 -0800 (PST) Received: (qmail 23520 invoked by uid 0); 12 Feb 2017 01:43:13 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 12 Feb 2017 01:43:13 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id jdjA1u0022UhLwi01djDYG; Sat, 11 Feb 2017 18:43:13 -0700 X-Authority-Analysis: v=2.1 cv=WOnsABcR 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=n2v9WMKugxEA:10 a=hbxNo_WP0yapi5NwgJwA:9 a=QEXdDO2ut3YA:10 Received: from c-73-202-80-238.hsd1.ca.comcast.net ([73.202.80.238]:65162 helo=[192.168.11.53]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1ccjC1-0005LK-WC for unbearable@ietf.org; Sat, 11 Feb 2017 18:43:10 -0700 To: IETF TokBind WG From: =JeffH Message-ID: Date: Sat, 11 Feb 2017 17:43:08 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 73.202.80.238 X-Exim-ID: 1ccjC1-0005LK-WC X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-73-202-80-238.hsd1.ca.comcast.net ([192.168.11.53]) [73.202.80.238]:65162 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 2 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Unbearable] TTRPs supporting TB on both upstream and downstream sides? 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: Sun, 12 Feb 2017 01:43:21 -0000 > In general for the reverse proxy case I agree with Brian. I suspect > it is more likely for the proxy to be at a network boundary and not > do tls inside, or to be in the “cloud” and do mutual TLS back to the > servers. yeah, that's what I am also thinking, tho it would be good to also hear from Amos since he's a proxy dude. =JeffH From nobody Sat Feb 11 18:49:10 2017 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 5A4C61294EA for ; Sat, 11 Feb 2017 18:49:09 -0800 (PST) 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 ZkwNcqmG3IpD for ; Sat, 11 Feb 2017 18:49:08 -0800 (PST) Received: from treenet.co.nz (unknown [121.99.228.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4E017129422 for ; Sat, 11 Feb 2017 18:49:06 -0800 (PST) Received: from [192.168.20.251] (unknown [121.98.40.15]) by treenet.co.nz (Postfix) with ESMTP id 91974E6ED8 for ; Sun, 12 Feb 2017 15:49:03 +1300 (NZDT) To: unbearable@ietf.org References: From: Amos Jeffries Message-ID: Date: Sun, 12 Feb 2017 15:49:01 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Unbearable] TTRPs supporting TB on both upstream and downstream sides? 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: Sun, 12 Feb 2017 02:49:09 -0000 On 12/02/2017 2:43 p.m., =JeffH wrote: >> In general for the reverse proxy case I agree with Brian. I suspect >> it is more likely for the proxy to be at a network boundary and not >> do tls inside, or to be in the “cloud” and do mutual TLS back to the >> servers. > > yeah, that's what I am also thinking, tho it would be good to also hear > from Amos since he's a proxy dude. > I also agree with Brian, client cert is far simpler in the TTRP use case where an admin is able to setup the appropriate certificates. It will also be more backward compatible with non-TB systems. Amos From nobody Sun Feb 12 21:01:00 2017 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 341F712940B for ; Sun, 12 Feb 2017 21:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.787 X-Spam-Level: X-Spam-Status: No, score=-3.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001, URIBL_BLOCKED=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 7ZAmSML6pckq for ; Sun, 12 Feb 2017 21:00:57 -0800 (PST) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id 513691204D9 for ; Sun, 12 Feb 2017 21:00:57 -0800 (PST) Received: (qmail 23926 invoked by uid 0); 13 Feb 2017 05:00:51 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy3.mail.unifiedlayer.com with SMTP; 13 Feb 2017 05:00:51 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id k50l1u0292UhLwi0150oaW; Sun, 12 Feb 2017 22:00:49 -0700 X-Authority-Analysis: v=2.1 cv=U+QBU4bu 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=n2v9WMKugxEA:10 a=ieNpE_y6AAAA:8 a=48vgC7mUAAAA:8 a=mQbAr3Z20UDnIPEh3PQA:9 a=QEXdDO2ut3YA:10 a=n7YKFLV3fQAA:10 a=J-Kc1YM4xMEA:10 a=lOZzU2MLX5qQKtuoMSD9:22 a=w1C3t2QeGrPiZgrLijVG:22 Received: from c-73-202-80-238.hsd1.ca.comcast.net ([73.202.80.238]:61468 helo=[192.168.11.53]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cd8kn-0003z2-KI for unbearable@ietf.org; Sun, 12 Feb 2017 22:00:45 -0700 From: =JeffH To: IETF TokBind WG Message-ID: <65a184a8-b00e-ddca-f1a5-2c9d274e9f8a@KingsMountain.com> Date: Sun, 12 Feb 2017 21:00:44 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 73.202.80.238 X-Exim-ID: 1cd8kn-0003z2-KI X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-73-202-80-238.hsd1.ca.comcast.net ([192.168.11.53]) [73.202.80.238]:61468 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 1 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? 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: Mon, 13 Feb 2017 05:00:59 -0000 Andrei wrote: > Amos had said: >> The Connection header is not particularly about proxies. It is >> simply about distinguishing hop-by-hop things from end-to-end so >> any naive/old HTTP recipient can keep the relevant data secure in a >> fail-closed way. > > ...and TB can be handled hop-by-hop or passed on for subsequent > validation; both are valid use-cases. > > It would be a concern if the backend servers were to assume that any > TB header (and the contained TB message) floating around is always > valid. Instead what the specs currently say is that if you receive a > TB message, you've got to validate it before accepting a bound > token. If validation fails, the bound token is rejected. > > It seems therefore that stripping TB headers does not "fail closed", > but simply eliminates the possibility that the contained TB message > may get verified further down the line. Actually, unless I'm mis-interpreting TBPROTO (aka -tokbind-protocol), it presently does not allow an application-layer proxy/gateway (that terminates the client-side TLS connection) to simply pass a TBMSG on to the next hop because (a) present spec language in TBPROTO S 4.2 precludes processing TBMSG if TB was not negotiated on the connection [1], and (b) S 5 precludes honoring bound tokens rec'd on a connection where their embedded TBIDs do not match the TBID established for the connection they were received over [2]. Apropos to (a), we are presently thinking that HTTP/TLS Terminating Reverse Proxies (TTRPs) likely will not negotiate TB on their towards-origin-server connections (aka backend connections) [3], and so if they simply forward along the Sec-Token-Binding (STB) header containing the TBMSG, the receiver is (presently) obliged to reject any "contained bindings". In the (b) case, since TBPROTO aspires to be app protocol neutral, there may be some app layer gateway that does want the gateway to negotiate TB on the backend connections, and then the present spec language impedes processing of tokens that have been gathered on prior hops. Plus in the case where TB is not nego'd on the backend connection, the receiving backend server is obliged to not honor the bound tokens because their TBIDs do not match a null TBID of the non-TB'd connection they were received over. > It is true that a proxy could forward Sec-Token-Binding's contents as > a custom header, possibly specified in another document. This is a > valid design; I'm just not convinced that this should be the only > possible design. Also, if an STB header is forwarded along "automatically" (eg, because it was not listed in the Connection header), it must be accompanied by the EKM et al necessary to validate it, so it seems a forwarding entity needs to be "TB-aware" to some degree in order to include said material (eg, via the proposed Token-Binding-Context (TBC) header [4]), and if it is so "aware", it ostensibly can then also forward along the STB regardless of whether the STB is listed in the received Connection header (due to the exception Amos cited earlier in RFC7230 S 6.1). So unless I'm mistaken, we have identified some things we ought to alter in TBPROTO in order to facilitate TTRPs. HTTPSTB may also need some associated language. This seems to be regardless of what we say about STB being conveyed in the Connection header. See diagram at [5]. Other scenarios (and a legend etc) also diagrammed at.. http://kingsmountain.com/doc/draft-ietf-tokbind-figures-STB-TTRPs.txt =JeffH [1] in "4.2 Server Processing Rules": https://tools.ietf.org/html/draft-ietf-tokbind-protocol-11#section-4.2 CURRENT: If the use of the Token Binding protocol was not negotiated, but the client sends the Token Binding message, the server MUST reject any contained bindings. [2] in "5. Bound Security Token Creation and Validation": https://tools.ietf.org/html/draft-ietf-tokbind-protocol-11#section-5 CURRENT: If the token is bound and a Token Binding has not been established for the client connection, the server MUST discard the token. If the Token Binding ID for the token does not match the Token Binding ID established for the client connection, the server MUST discard the token. [3] [4] https://tools.ietf.org/html/draft-campbell-tokbind-tls-term [5] Scenario 3: TB-aware TTRP, TB-wielding origin server. [[ISSUES]] Note: this scenario generalizes to more than one TB-aware TTRP in the path. TB-wielding TB-aware TB-wielding client TTRP Origin Server [TB nego, [TB-nego, [!TB-nego, mints STB] !process STB, process STB !process Toks] using TBC, process Toks] GET / HTTP/1.1 Host:... STB:AIkAAg...72REUA {Connection:STB} --------------------------------> [TB-nego] [pass-thru STB due to exception clause in RFC7230 S 6.1 (or automatically if no Connection hdr), add TBC, optionally use Connection header.] GET / HTTP/1.1 Host:... STB:AIkAAg..72REUA TBC:AQAClt..7fFs4i {Connection:STB,TBC} ----------------------------------> [!TB-nego] WANT: using TBC, origin server is able to verify TBMSG in STB and to bind sec tokens to TBID from client-TTRP connection. BUT: No TB on connection to OS. Also, present spec language in [3] S 4.2 precludes processing STB, and S 5 precludes honoring bound tokens rec'd on this connection !!! THUS: HTTP/1.1 200 OK Set-cookie:foo=31d4..aad42 [cookie !bound] <---------------------------------- HTTP/1.1 200 OK Set-cookie:foo=31d4..aad42 [cookie !bound] <------------------------------ ###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++###+++### From nobody Sun Feb 12 21:18:10 2017 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 5FC8D129474 for ; Sun, 12 Feb 2017 21:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.787 X-Spam-Level: X-Spam-Status: No, score=-3.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001, URIBL_BLOCKED=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 HOWxOTCvwQ61 for ; Sun, 12 Feb 2017 21:18:08 -0800 (PST) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id 10DD1129447 for ; Sun, 12 Feb 2017 21:18:08 -0800 (PST) Received: (qmail 15811 invoked by uid 0); 13 Feb 2017 05:18:07 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy3.mail.unifiedlayer.com with SMTP; 13 Feb 2017 05:18:07 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id k5J41u00N2UhLwi015J7k6; Sun, 12 Feb 2017 22:18:07 -0700 X-Authority-Analysis: v=2.1 cv=WOnsABcR 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=n2v9WMKugxEA:10 a=NEAV23lmAAAA:8 a=48vgC7mUAAAA:8 a=ieNpE_y6AAAA:8 a=Y6pSl3wNlSStAhbz23MA:9 a=QEXdDO2ut3YA:10 a=kaenGqFEXXQA:10 a=KJWqy55PgxgA:10 a=wcBAnfsVOm4A:10 a=xZPjJZGZeIgA:10 a=Bn2pgwyD2vrAyMmN8A2t:22 a=w1C3t2QeGrPiZgrLijVG:22 a=lOZzU2MLX5qQKtuoMSD9:22 Received: from c-73-202-80-238.hsd1.ca.comcast.net ([73.202.80.238]:61740 helo=[192.168.11.53]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cd91Y-0003iS-5t for unbearable@ietf.org; Sun, 12 Feb 2017 22:18:04 -0700 To: IETF TokBind WG From: =JeffH Message-ID: <701e26b0-32d0-2e9c-0c9e-85f7aec49a4d@KingsMountain.com> Date: Sun, 12 Feb 2017 21:18:03 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 73.202.80.238 X-Exim-ID: 1cd91Y-0003iS-5t X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-73-202-80-238.hsd1.ca.comcast.net ([192.168.11.53]) [73.202.80.238]:61740 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 2 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: [Unbearable] wrt handling multiple sec-token-binding header occurrences 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: Mon, 13 Feb 2017 05:18:09 -0000 There are some questions/pushback on this proposed text queued-up in the repo for HTTPSTB.. .. > > If the server receives more than one Sec-Token-Binding header > field in an HTTP request, then the server MUST process only the first > such header field. If the processed Sec-Token-Binding header field > contains more than one EncodedTokenBindingMessage (e.g., delimited by > commas, see Section 3.2 of ), the server MUST > ignore the header field. [...] ..where some folks are saying (details below) that the server should/must reject a received message if the message has multiple Sec-Token-Binding header fields. To explain the above-suggested language: we had to address essentially this situation when crafting RFC6797 HSTS [1] and RFC7469 HPKP [2]. The above language largely mirrors the latter specs' language. Unfortunately, we did not state the rationale for this in either spec (mea culpa wrt HSTS). Tho, this topic was discussed on the websec@ietf.org mailing list during HPKP development which explicates the rationale.. Re: [websec] Why are multiple PKP header fields allowed? ..and although Ivan nominally pushed for message rejection.. ..the spec shipped with the "the UA MUST process only the first PKP header field" language [2] (as HSTS did). Given that receiving multiple STBs may end up being possible, due to HTTP intermediaries, see scenario 6 in [3], and also since we do not have reject-message language any longer in TBPROTO, and given the rationale behind the language in [1] & [2], I propose modifying the above-quoted language to be something like... If the server receives more than one Sec-Token-Binding header field in an HTTP request, then the server MAY process the first such header field, e.g., if the server is configured to receive connections from a reverse proxy. If the processed Sec-Token-Binding header field contains more than one EncodedTokenBindingMessage (e.g., delimited by commas, see Section 3.2 of ), the server MAY process the first occurrence of EncodedTokenBindingMessage. Otherwise, the server SHOULD reject the message in some application-appropriate fashion. =JeffH [1] https://tools.ietf.org/html/rfc6797#section-8.1 [2] https://tools.ietf.org/html/rfc7469#section-2.3.1 [3] @Andrei-Popov's comments: > > We're saying above that only one header is allowed, and only one TB > message must be in it. If the client violates these restrictions, > then we have a malformed request, and should simply reject this > request. @balfanz replies: > > Rejecting the request is fine with me. > > So is ignoring subsequent header fields. > > So is saying that it's ok to submit multiple header fields (just > like it's ok to have multiple TokenBindingIDs in a > TokenBindingMessage), and just passing them all on to upper layers - > maybe that's how the client shows that it possesses multiple keys? > > (Maybe I have a slight preference for the latter.) > > Andrei - do you feel strongly about this? I'm willing to merge any of > those options into the main branch. @nharper replies: > My preference would be to reject a request with multiple > Sec-Token-Binding headers. @b---c (brian campbell) notes: > +1 to reject a request with multiple Sec-Token-Binding headers @Andrei-Popov's replies: > I think the spec should be definitive: since we’re saying the client > should only send one TB header per request, and only one TB message > per header, then the server should be at liberty to enforce this. > > If we allow variation, e.g. it’s OK to send multiple TB headers per > request, then we need to define when and how one would use this > mechanism. And at this point in the process I don’t think we should > be adding new mechanisms to TB v 1.0. @balfanz wonders: > Don't we allow multiple TokenBinding structures within a > TokenBindingMessage? Seems to me that the server already has to be > able to deal with multiple proofs-of-possession. Allowing multiple > header fields is just another way that we might end up with multiple > proofs-of-possession - it's not exactly a "new mechanism". > > But like I said, I don't feel strongly about it. I'm happy to have > the spec say that the server should (must?) reject if there are > multiple headers. @Andrei-Popov's replies: > Correct, we do allow multiple bindings within a TB message (and to > me that's an existing mechanism:). > > Supporting the same thing via multiple header fields requires a code > change, and so far I see no reason to maintain two ways (or > mechanisms:) to do the same thing. [ aside: this'd be a whole lot easier if github.com comments/issues/etc in the TokenBinding/Internet-Drafts were sent to this list - which was set up at one time but appears to have quit working... ] From nobody Mon Feb 13 10:49:45 2017 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 846D51296F0 for ; Mon, 13 Feb 2017 10:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 CvmpVtjA1Nsb for ; Mon, 13 Feb 2017 10:49:41 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0126.outbound.protection.outlook.com [104.47.40.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74AEC129781 for ; Mon, 13 Feb 2017 10:42:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=h1uPyyKG0rzd8BK94vDHoal6ygdA6P1TzfjDbkMj+lU=; b=S5kHCJKGXMphoaThA5ForYh/0f8UMKzqlNAENeKZe+2tnKTDyM8EsxD0mUkRrwYgHsHjLJRQlIP03BPuOEJHmi2K1rJFCtz7LUaW9IIfpi5tMcBJjhfR3LPW7znuuQLnbgU7N84wISwFc+wda2CZxpFerW+iJLGawLSEurXrSqQ= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0841.namprd03.prod.outlook.com (10.160.163.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Mon, 13 Feb 2017 18:42:35 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.030; Mon, 13 Feb 2017 18:42:35 +0000 From: Andrei Popov To: =JeffH , IETF TokBind WG Thread-Topic: [Unbearable] wrt handling multiple sec-token-binding header occurrences Thread-Index: AQHShbiY7VLPsN/JNU6e5Ly2NIHI76FnRJXw Date: Mon, 13 Feb 2017 18:42:35 +0000 Message-ID: References: <701e26b0-32d0-2e9c-0c9e-85f7aec49a4d@KingsMountain.com> In-Reply-To: <701e26b0-32d0-2e9c-0c9e-85f7aec49a4d@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:a::1d2] x-ms-office365-filtering-correlation-id: 16a8e35d-66a0-45ff-f201-08d4544013fa x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0841; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0841; 7:gF3CEW7igFcHQGE65GDhraYNWcpAo+ny1EMhPfIV6dOsUY9y2k675RUHyPmX7C9nc3HRUevCh48OVjcLXm/Sg7VXeAyKbr/eXiHOkp97vdoEZ2MO0aZr23WJfm0PqaahtaClukTQKlH1D08IhYSPxGB4NnH0Gx+p9gXZzISs+4I3CEyRfU5vttkupNevrh340bARc7s+0YXcd5zwMfy0N94p8WqGHQVmKhoOLdNWz6uSv++960CfvFzFMHRTack8GIXiNkS7UionesKd7dBdKcHTa4kBcA7t2wFOyrLz28g1fuP109/c2TqbJpyK/MaN3CtN6Q2oZi3imu5LPwUSSTU4QkE+0+afkcVb7XvYAtKcCUWjK7PLojIhcBUJIXPibPYbj9dKTAAjNUcncYfhmv6HmBUGPtbzby53YL2NYz6QEdxOZjQx71AUchKKUAoGooJVyUX2ziqzbU3LDXoOB0huW6ecwXVHmpjm1PxHswZG4Keq+5juGNkoL9A/7SxxuizpuQXtYnhDuA7PxlAr7z7tHiWCzf1inYJABSLABlQ= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123555025)(20161123558025)(20161123560025)(20161123562025)(6072148); SRVR:CY1PR0301MB0841; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0841; x-forefront-prvs: 02176E2458 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39840400002)(39860400002)(39450400003)(13464003)(189002)(377454003)(199003)(52084003)(99286003)(55016002)(229853002)(9686003)(77096006)(25786008)(6436002)(6306002)(6506006)(3280700002)(105586002)(106356001)(106116001)(3660700001)(5005710100001)(101416001)(10090500001)(10290500002)(102836003)(6116002)(53936002)(33656002)(2906002)(8990500004)(97736004)(122556002)(305945005)(189998001)(7736002)(74316002)(92566002)(7696004)(5660300001)(230783001)(6246003)(2950100002)(2900100001)(38730400002)(81156014)(8936002)(50986999)(76176999)(53376002)(54356999)(86362001)(86612001)(68736007)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0841; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 13 Feb 2017 18:42:35.4024 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0841 Archived-At: Subject: Re: [Unbearable] wrt handling multiple sec-token-binding header occurrences 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: Mon, 13 Feb 2017 18:49:43 -0000 UGVyIFBLUCB0aHJlYWQgcmVmZXJlbmNlZCBiZWxvdzoNCiJObyBtYXR0ZXIgd2hlcmUgdGhlIGhl YWRlciBpcyBpbmplY3RlZCAoZmlyc3Qgb3Igc2Vjb25kKSwNCml0J3MgbmV2ZXIgd3JvbmcgcmVq ZWN0IGJvdGguIEl0IGNlcnRhaW5seSBmZWVscyBzYWZlciB0byBtZTsgYWZ0ZXIgYWxsDQp3ZSBr bm93IHRoYXQgdGhhdCByZXNwb25zZSBpcyBjb250YW1pbmF0ZWQuIg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mID1KZWZmSA0KU2VudDogU3VuZGF5LCBGZWJydWFyeSAx MiwgMjAxNyA5OjE4IFBNDQpUbzogSUVURiBUb2tCaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3Jn Pg0KU3ViamVjdDogW1VuYmVhcmFibGVdIHdydCBoYW5kbGluZyBtdWx0aXBsZSBzZWMtdG9rZW4t YmluZGluZyBoZWFkZXIgb2NjdXJyZW5jZXMNCg0KVGhlcmUgYXJlIHNvbWUgcXVlc3Rpb25zL3B1 c2hiYWNrIG9uIHRoaXMgcHJvcG9zZWQgdGV4dCBxdWV1ZWQtdXAgaW4gdGhlIHJlcG8gZm9yIEhU VFBTVEIuLg0KPGh0dHBzOi8vZ2l0aHViLmNvbS9Ub2tlbkJpbmRpbmcvSW50ZXJuZXQtRHJhZnRz L3B1bGwvOTQvZmlsZXMvNjgxODkwNmJiMDk2YTg4MGY1MjQwNGIzMWI5OTllZGZkMmYzODhlMD4u Lg0KID4NCiA+IDx0PklmIHRoZSBzZXJ2ZXIgcmVjZWl2ZXMgbW9yZSB0aGFuIG9uZSBTZWMtVG9r ZW4tQmluZGluZyBoZWFkZXIgID4gZmllbGQgaW4gYW4gSFRUUCByZXF1ZXN0LCB0aGVuIHRoZSBz ZXJ2ZXIgTVVTVCBwcm9jZXNzIG9ubHkgdGhlIGZpcnN0ICA+IHN1Y2ggaGVhZGVyIGZpZWxkLiBJ ZiB0aGUgcHJvY2Vzc2VkIFNlYy1Ub2tlbi1CaW5kaW5nIGhlYWRlciBmaWVsZCAgPiBjb250YWlu cyBtb3JlIHRoYW4gb25lIEVuY29kZWRUb2tlbkJpbmRpbmdNZXNzYWdlIChlLmcuLCBkZWxpbWl0 ZWQgYnkgID4gY29tbWFzLCBzZWUgU2VjdGlvbiAzLjIgb2YgPHhyZWYgdGFyZ2V0PSJSRkM3MjMw Ii8+KSwgdGhlIHNlcnZlciBNVVNUICA+IGlnbm9yZSB0aGUgaGVhZGVyIGZpZWxkLiBbLi4uXQ0K DQouLndoZXJlIHNvbWUgZm9sa3MgYXJlIHNheWluZyAoZGV0YWlscyBiZWxvdykgdGhhdCB0aGUg c2VydmVyIHNob3VsZC9tdXN0IHJlamVjdCBhIHJlY2VpdmVkIG1lc3NhZ2UgaWYgdGhlIG1lc3Nh Z2UgaGFzIG11bHRpcGxlIFNlYy1Ub2tlbi1CaW5kaW5nIGhlYWRlciBmaWVsZHMuDQoNClRvIGV4 cGxhaW4gdGhlIGFib3ZlLXN1Z2dlc3RlZCBsYW5ndWFnZTogd2UgaGFkIHRvIGFkZHJlc3MgZXNz ZW50aWFsbHkgdGhpcyBzaXR1YXRpb24gd2hlbiBjcmFmdGluZyBSRkM2Nzk3IEhTVFMgWzFdIGFu ZCBSRkM3NDY5IEhQS1AgWzJdLiBUaGUgYWJvdmUgbGFuZ3VhZ2UgbGFyZ2VseSBtaXJyb3JzIHRo ZSBsYXR0ZXIgc3BlY3MnIGxhbmd1YWdlLg0KDQpVbmZvcnR1bmF0ZWx5LCB3ZSBkaWQgbm90IHN0 YXRlIHRoZSByYXRpb25hbGUgZm9yIHRoaXMgaW4gZWl0aGVyIHNwZWMgKG1lYSBjdWxwYSB3cnQg SFNUUykuIFRobywgdGhpcyB0b3BpYyB3YXMgZGlzY3Vzc2VkIG9uIHRoZSB3ZWJzZWNAaWV0Zi5v cmcgbWFpbGluZyBsaXN0IGR1cmluZyBIUEtQIGRldmVsb3BtZW50IHdoaWNoIGV4cGxpY2F0ZXMg dGhlIHJhdGlvbmFsZS4uDQoNCiAgIFJlOiBbd2Vic2VjXSBXaHkgYXJlIG11bHRpcGxlIFBLUCBo ZWFkZXIgZmllbGRzIGFsbG93ZWQ/DQogICA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi93ZWJzZWMvY3VycmVudC9tc2cwMjA1OS5odG1sPg0KDQouLmFuZCBhbHRob3VnaCBJ dmFuIG5vbWluYWxseSBwdXNoZWQgZm9yIG1lc3NhZ2UgcmVqZWN0aW9uLi4NCg0KICAgPGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvd2Vic2VjL2N1cnJlbnQvbXNnMDIwNjUu aHRtbD4NCg0KLi50aGUgc3BlYyBzaGlwcGVkIHdpdGggdGhlICJ0aGUgVUEgTVVTVCBwcm9jZXNz IG9ubHkgdGhlIGZpcnN0IFBLUCBoZWFkZXIgZmllbGQiIGxhbmd1YWdlIFsyXSAoYXMgSFNUUyBk aWQpLg0KDQpHaXZlbiB0aGF0IHJlY2VpdmluZyBtdWx0aXBsZSBTVEJzIG1heSBlbmQgdXAgYmVp bmcgcG9zc2libGUsIGR1ZSB0byBIVFRQIGludGVybWVkaWFyaWVzLCBzZWUgc2NlbmFyaW8gNiBp biBbM10sIGFuZCBhbHNvIHNpbmNlIHdlIGRvIG5vdCBoYXZlIHJlamVjdC1tZXNzYWdlIGxhbmd1 YWdlIGFueSBsb25nZXIgaW4gVEJQUk9UTywgYW5kIGdpdmVuIHRoZSByYXRpb25hbGUgYmVoaW5k IHRoZSBsYW5ndWFnZSBpbiBbMV0gJiBbMl0sIEkgcHJvcG9zZSBtb2RpZnlpbmcgdGhlIGFib3Zl LXF1b3RlZCBsYW5ndWFnZSB0byBiZSBzb21ldGhpbmcgbGlrZS4uLg0KDQogICBJZiB0aGUgc2Vy dmVyIHJlY2VpdmVzIG1vcmUgdGhhbiBvbmUgU2VjLVRva2VuLUJpbmRpbmcgaGVhZGVyDQogICBm aWVsZCBpbiBhbiBIVFRQIHJlcXVlc3QsIHRoZW4gdGhlIHNlcnZlciBNQVkgcHJvY2VzcyB0aGUg Zmlyc3QNCiAgIHN1Y2ggaGVhZGVyIGZpZWxkLCBlLmcuLCBpZiB0aGUgc2VydmVyIGlzIGNvbmZp Z3VyZWQgdG8gcmVjZWl2ZQ0KICAgY29ubmVjdGlvbnMgZnJvbSBhIHJldmVyc2UgcHJveHkuIElm IHRoZSBwcm9jZXNzZWQgU2VjLVRva2VuLUJpbmRpbmcNCiAgIGhlYWRlciBmaWVsZCBjb250YWlu cyBtb3JlIHRoYW4gb25lIEVuY29kZWRUb2tlbkJpbmRpbmdNZXNzYWdlIChlLmcuLA0KICAgZGVs aW1pdGVkIGJ5IGNvbW1hcywgc2VlIFNlY3Rpb24gMy4yIG9mIDx4cmVmIHRhcmdldD0iUkZDNzIz MCIvPiksDQogICB0aGUgc2VydmVyIE1BWSBwcm9jZXNzIHRoZSBmaXJzdCBvY2N1cnJlbmNlIG9m DQogICBFbmNvZGVkVG9rZW5CaW5kaW5nTWVzc2FnZS4gT3RoZXJ3aXNlLCB0aGUgc2VydmVyIFNI T1VMRCByZWplY3QgdGhlDQogICBtZXNzYWdlIGluIHNvbWUgYXBwbGljYXRpb24tYXBwcm9wcmlh dGUgZmFzaGlvbi4NCg0KPUplZmZIDQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNjc5NyNzZWN0aW9uLTguMQ0KDQpbMl0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm Yzc0Njkjc2VjdGlvbi0yLjMuMQ0KDQpbM10gPGh0dHA6Ly9raW5nc21vdW50YWluLmNvbS9kb2Mv ZHJhZnQtaWV0Zi10b2tiaW5kLWZpZ3VyZXMtU1RCLVRUUlBzLnR4dD4NCg0KDQpAQW5kcmVpLVBv cG92J3MgY29tbWVudHM6DQo8aHR0cHM6Ly9naXRodWIuY29tL1Rva2VuQmluZGluZy9JbnRlcm5l dC1EcmFmdHMvcHVsbC85NCNkaXNjdXNzaW9uX3I5OTk3MTY4Nz4NCiA+DQogPiBXZSdyZSBzYXlp bmcgYWJvdmUgdGhhdCBvbmx5IG9uZSBoZWFkZXIgaXMgYWxsb3dlZCwgYW5kIG9ubHkgb25lIFRC ICA+IG1lc3NhZ2UgbXVzdCBiZSBpbiBpdC4gSWYgdGhlIGNsaWVudCB2aW9sYXRlcyB0aGVzZSBy ZXN0cmljdGlvbnMsICA+IHRoZW4gd2UgaGF2ZSBhIG1hbGZvcm1lZCByZXF1ZXN0LCBhbmQgc2hv dWxkIHNpbXBseSByZWplY3QgdGhpcyAgPiByZXF1ZXN0Lg0KDQpAYmFsZmFueiByZXBsaWVzOg0K ID4NCiA+IFJlamVjdGluZyB0aGUgcmVxdWVzdCBpcyBmaW5lIHdpdGggbWUuDQogPg0KID4gU28g aXMgaWdub3Jpbmcgc3Vic2VxdWVudCBoZWFkZXIgZmllbGRzLg0KID4NCiA+IFNvIGlzIHNheWlu ZyB0aGF0IGl0J3Mgb2sgdG8gc3VibWl0IG11bHRpcGxlIGhlYWRlciBmaWVsZHMgKGp1c3QgID4g bGlrZSBpdCdzIG9rIHRvIGhhdmUgbXVsdGlwbGUgVG9rZW5CaW5kaW5nSURzIGluIGEgID4gVG9r ZW5CaW5kaW5nTWVzc2FnZSksIGFuZCBqdXN0IHBhc3NpbmcgdGhlbSBhbGwgb24gdG8gdXBwZXIg bGF5ZXJzIC0gID4gbWF5YmUgdGhhdCdzIGhvdyB0aGUgY2xpZW50IHNob3dzIHRoYXQgaXQgcG9z c2Vzc2VzIG11bHRpcGxlIGtleXM/DQogPg0KID4gKE1heWJlIEkgaGF2ZSBhIHNsaWdodCBwcmVm ZXJlbmNlIGZvciB0aGUgbGF0dGVyLikgID4gID4gQW5kcmVpIC0gZG8geW91IGZlZWwgc3Ryb25n bHkgYWJvdXQgdGhpcz8gSSdtIHdpbGxpbmcgdG8gbWVyZ2UgYW55IG9mICA+IHRob3NlIG9wdGlv bnMgaW50byB0aGUgbWFpbiBicmFuY2guDQoNCkBuaGFycGVyIHJlcGxpZXM6DQogPiBNeSBwcmVm ZXJlbmNlIHdvdWxkIGJlIHRvIHJlamVjdCBhIHJlcXVlc3Qgd2l0aCBtdWx0aXBsZSAgPiBTZWMt VG9rZW4tQmluZGluZyBoZWFkZXJzLg0KDQpAYi0tLWMgKGJyaWFuIGNhbXBiZWxsKSBub3RlczoN CiA+ICsxIHRvIHJlamVjdCBhIHJlcXVlc3Qgd2l0aCBtdWx0aXBsZSBTZWMtVG9rZW4tQmluZGlu ZyBoZWFkZXJzDQoNCkBBbmRyZWktUG9wb3YncyByZXBsaWVzOg0KID4gSSB0aGluayB0aGUgc3Bl YyBzaG91bGQgYmUgZGVmaW5pdGl2ZTogc2luY2Ugd2XigJlyZSBzYXlpbmcgdGhlIGNsaWVudCAg PiAgc2hvdWxkIG9ubHkgc2VuZCBvbmUgVEIgaGVhZGVyIHBlciByZXF1ZXN0LCBhbmQgb25seSBv bmUgVEIgbWVzc2FnZSAgPiAgcGVyIGhlYWRlciwgdGhlbiB0aGUgc2VydmVyIHNob3VsZCBiZSBh dCBsaWJlcnR5IHRvIGVuZm9yY2UgdGhpcy4NCiA+DQogPiBJZiB3ZSBhbGxvdyB2YXJpYXRpb24s IGUuZy4gaXTigJlzIE9LIHRvIHNlbmQgbXVsdGlwbGUgVEIgaGVhZGVycyBwZXIgID4gcmVxdWVz dCwgdGhlbiB3ZSBuZWVkIHRvIGRlZmluZSB3aGVuIGFuZCBob3cgb25lIHdvdWxkIHVzZSB0aGlz ICA+IG1lY2hhbmlzbS4gQW5kIGF0IHRoaXMgcG9pbnQgaW4gdGhlIHByb2Nlc3MgSSBkb27igJl0 IHRoaW5rIHdlIHNob3VsZCAgPiBiZSBhZGRpbmcgbmV3IG1lY2hhbmlzbXMgdG8gVEIgdiAxLjAu DQoNCkBiYWxmYW56IHdvbmRlcnM6DQogPiBEb24ndCB3ZSBhbGxvdyBtdWx0aXBsZSBUb2tlbkJp bmRpbmcgc3RydWN0dXJlcyB3aXRoaW4gYSAgPiBUb2tlbkJpbmRpbmdNZXNzYWdlPyBTZWVtcyB0 byBtZSB0aGF0IHRoZSBzZXJ2ZXIgYWxyZWFkeSBoYXMgdG8gYmUgID4gYWJsZSB0byBkZWFsIHdp dGggbXVsdGlwbGUgcHJvb2ZzLW9mLXBvc3Nlc3Npb24uIEFsbG93aW5nIG11bHRpcGxlICA+IGhl YWRlciBmaWVsZHMgaXMganVzdCBhbm90aGVyIHdheSB0aGF0IHdlIG1pZ2h0IGVuZCB1cCB3aXRo IG11bHRpcGxlICA+IHByb29mcy1vZi1wb3NzZXNzaW9uIC0gaXQncyBub3QgZXhhY3RseSBhICJu ZXcgbWVjaGFuaXNtIi4NCiA+DQogPiBCdXQgbGlrZSBJIHNhaWQsIEkgZG9uJ3QgZmVlbCBzdHJv bmdseSBhYm91dCBpdC4gSSdtIGhhcHB5IHRvIGhhdmUgID4gdGhlIHNwZWMgc2F5IHRoYXQgdGhl IHNlcnZlciBzaG91bGQgKG11c3Q/KSByZWplY3QgaWYgdGhlcmUgYXJlICA+IG11bHRpcGxlIGhl YWRlcnMuDQoNCkBBbmRyZWktUG9wb3YncyByZXBsaWVzOg0KID4gQ29ycmVjdCwgd2UgZG8gYWxs b3cgbXVsdGlwbGUgYmluZGluZ3Mgd2l0aGluIGEgVEIgbWVzc2FnZSAoYW5kIHRvICA+IG1lIHRo YXQncyBhbiBleGlzdGluZyBtZWNoYW5pc206KS4NCiA+DQogPiBTdXBwb3J0aW5nIHRoZSBzYW1l IHRoaW5nIHZpYSBtdWx0aXBsZSBoZWFkZXIgZmllbGRzIHJlcXVpcmVzIGEgY29kZSAgPiBjaGFu Z2UsIGFuZCBzbyBmYXIgSSBzZWUgbm8gcmVhc29uIHRvIG1haW50YWluIHR3byB3YXlzIChvciAg PiBtZWNoYW5pc21zOikgdG8gZG8gdGhlIHNhbWUgdGhpbmcuDQoNCg0KWyBhc2lkZTogdGhpcydk IGJlIGEgd2hvbGUgbG90IGVhc2llciBpZiBnaXRodWIuY29tIGNvbW1lbnRzL2lzc3Vlcy9ldGMg aW4gdGhlIFRva2VuQmluZGluZy9JbnRlcm5ldC1EcmFmdHMgd2VyZSBzZW50IHRvIHRoaXMgbGlz dCAtIHdoaWNoIHdhcyBzZXQgdXAgYXQgb25lIHRpbWUgYnV0IGFwcGVhcnMgdG8gaGF2ZSBxdWl0 IHdvcmtpbmcuLi4gXQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0DQpVbmJlYXJhYmxlQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUNCg== From nobody Tue Feb 14 15:15:33 2017 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 B6462129650 for ; Tue, 14 Feb 2017 15:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnfwRlppMl-t for ; Tue, 14 Feb 2017 15:15:30 -0800 (PST) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id 887EE12942F for ; Tue, 14 Feb 2017 15:15:30 -0800 (PST) Received: (qmail 31297 invoked by uid 0); 14 Feb 2017 23:15:29 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy3.mail.unifiedlayer.com with SMTP; 14 Feb 2017 23:15:29 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id knFR1u00l2UhLwi01nFUVH; Tue, 14 Feb 2017 16:15:29 -0700 X-Authority-Analysis: v=2.1 cv=WOnsABcR 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=n2v9WMKugxEA:10 a=LmU6073Z7aXF-iGEecIA:9 a=QEXdDO2ut3YA:10 Received: from [173.224.162.69] (port=61482 helo=[10.225.80.51]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cdmJh-00047g-Q3 for unbearable@ietf.org; Tue, 14 Feb 2017 16:15:25 -0700 To: IETF TokBind WG From: =JeffH Message-ID: Date: Tue, 14 Feb 2017 15:15:23 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 173.224.162.69 X-Exim-ID: 1cdmJh-00047g-Q3 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.225.80.51]) [173.224.162.69]:61482 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 1 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Unbearable] wrt handling multiple sec-token-binding header occurrences 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, 14 Feb 2017 23:15:32 -0000 Andrei replied: > > Per PKP thread referenced below: > "No matter where the header is injected (first or second), it's never > wrong reject both. It certainly feels safer to me; after all we know > that that response is contaminated." yes, that was written by Ivan and was/is his position wrt HPKP. Regardless, the spec shipped with the "UA MUST process only the first PKP header field" language (as did HSTS). There were real-world HTTP vagaries as I recall which caused us to use the language we did in HSTS and HPKP, but maybe things are different now. That said, I personally am ok with stipulating this.. If the server receives more than one Sec-Token-Binding header field in an HTTP request, then the server MUST reject the message with a 400 (Bad Request) HTTP status code. ..and seeing if we get any pushback during IETF-wide Last Call. =JeffH From nobody Tue Feb 14 15:24:10 2017 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 B1B981296D4 for ; Tue, 14 Feb 2017 15:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 uZvGb1mOh_5h for ; Tue, 14 Feb 2017 15:24:07 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0118.outbound.protection.outlook.com [104.47.36.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 D64161296CA for ; Tue, 14 Feb 2017 15:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rcjXdcpdTPszaNgHg8J3cZvwM0goBvkTW3j0lLs3T80=; b=S7yAdaXp6kT6mttacaLfxYU6KKrGThCgkqxIbAyDQ0sgi7u1B5XQa1SgcBeCQL67PAr7PiE3rQDoBZ6y1+ygpIWS38EE5sK/fdHqFHyTcVMT0hCEWuhC5cXo9f6mqE1hsa3ony2fSpcgFQlwMb6L8HRIpBwyDDnTwpfvaHjo+5I= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0841.namprd03.prod.outlook.com (10.160.163.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 14 Feb 2017 23:24:05 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.030; Tue, 14 Feb 2017 23:24:05 +0000 From: Andrei Popov To: =JeffH , IETF TokBind WG Thread-Topic: [Unbearable] wrt handling multiple sec-token-binding header occurrences Thread-Index: AQHShxg37VLPsN/JNU6e5Ly2NIHI76FpJAEA Date: Tue, 14 Feb 2017 23:24:04 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:a::1d2] x-ms-office365-filtering-correlation-id: 2ba60861-4cab-4be9-6bc4-08d455309149 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0841; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0841; 7:cT1zxTrq7PJmiB3FUf5c2WGa/0Pkw/o1SPG43duWzdyAiryN4BfVCjuvwaA1NFXJYnL+3x6V2l7txDwgYH5IYm8QXkmHKoIS32CEKBlTNpFrGPoXTp+F39osMNcL9mVt1fdif2BoBMAqwd9wj2OyXQHEn3J9DtSCW8eeaYGiDc/zTwBnA684nQlIndGYPrZMI6/Bd94Ji05PthwmOJXoxdIiYf0ZbKGwNrriG1MFeBTxctOwMIyLGX/mviN9+KyNTFbZiwa2EfHHhFEo4Qa9Jf8sywi6uURZfzpvuWLiwSNxzpJsXKX8BruHx90XywYHCcnWdoBBfov757flzX0WgjQvD8X7l9NBvsqlxaQDQeYlPtIukDI+eeljgl5WfeTFMM7m/UD/qIOBsakg3eACtEEv732ydC+mJE5HfXwyO3xbL9SGpZjjoDm/lKXL2lL/FuVEZwnExGyx0X0vWoOJ3irMl0zCs9tsOrYo3HiCAhkiPoUZUdz+ZN8mlFvF498HOPWxYylZqGycFrXAaUCz06VTlP2L6+AGzjtas9njqZI= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(20161123558025)(6072148); SRVR:CY1PR0301MB0841; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0841; x-forefront-prvs: 0218A015FA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39410400002)(39850400002)(39450400003)(39860400002)(13464003)(189002)(377454003)(199003)(9686003)(3660700001)(25786008)(229853002)(99286003)(6306002)(55016002)(6506006)(77096006)(106116001)(3280700002)(105586002)(101416001)(106356001)(53936002)(6116002)(10290500002)(2906002)(10090500001)(8990500004)(33656002)(5005710100001)(97736004)(102836003)(389900002)(6436002)(122556002)(305945005)(74316002)(7736002)(189998001)(7696004)(5660300001)(92566002)(8936002)(2950100002)(6246003)(2900100001)(38730400002)(230783001)(81156014)(50986999)(76176999)(54356999)(8676002)(86362001)(86612001)(68736007)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0841; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 14 Feb 2017 23:24:04.7929 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0841 Archived-At: Subject: Re: [Unbearable] wrt handling multiple sec-token-binding header occurrences 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, 14 Feb 2017 23:24:09 -0000 Yes, I think this would be cleanest/simplest, and then we can easily adjust= the language if someone brings up a reason to do so. Cheers, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of =3DJeffH Sent: Tuesday, February 14, 2017 3:15 PM To: IETF TokBind WG Subject: Re: [Unbearable] wrt handling multiple sec-token-binding header oc= currences Andrei replied: > > Per PKP thread referenced below: > "No matter where the header is injected (first or second), it's never >= wrong reject both. It certainly feels safer to me; after all we know > th= at that response is contaminated." yes, that was written by Ivan and was/is his position wrt HPKP.=20 Regardless, the spec shipped with the "UA MUST process only the first PKP h= eader field" language (as did HSTS). There were real-world HTTP vagaries as= I recall which caused us to use the language we did in HSTS and HPKP, but = maybe things are different now. That said, I personally am ok with stipulating this.. If the server receives more than one Sec-Token-Binding header field in an HTTP request, then the server MUST reject the message with a 400 (Bad Request) HTTP status code. ..and seeing if we get any pushback during IETF-wide Last Call. =3DJeffH _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable From nobody Wed Feb 15 13:12:34 2017 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 2E4D0129B82 for ; Wed, 15 Feb 2017 13:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=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 CuLX2TzDDgER for ; Wed, 15 Feb 2017 13:12:30 -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 C87E61297E4 for ; Wed, 15 Feb 2017 13:12:30 -0800 (PST) Received: (qmail 25619 invoked by uid 0); 15 Feb 2017 21:12:27 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy7.mail.unifiedlayer.com with SMTP; 15 Feb 2017 21:12:27 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id l9CP1u0142UhLwi019CSHY; Wed, 15 Feb 2017 14:12:27 -0700 X-Authority-Analysis: v=2.1 cv=Pets2ERd 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=n2v9WMKugxEA:10 a=cm27Pg_UAAAA:8 a=1XWaLZrsAAAA:8 a=w9HSoYAUWnuqW-_ayAcA:9 a=QEXdDO2ut3YA:10 a=xmb-EsYY8bH0VWELuYED:22 a=nJcEw6yWrPvoIXZ49MH8:22 Received: from [173.224.162.69] (port=61215 helo=[10.225.80.64]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1ce6sB-00015P-S9 for unbearable@ietf.org; Wed, 15 Feb 2017 14:12:23 -0700 From: =JeffH To: IETF TokBind WG Message-ID: <0d90fcf0-0ec7-448c-d0ad-0385062400b9@KingsMountain.com> Date: Wed, 15 Feb 2017 13:12:23 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 173.224.162.69 X-Exim-ID: 1ce6sB-00015P-S9 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.225.80.64]) [173.224.162.69]:61215 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 1 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: [Unbearable] sec-token-binding header in the wild 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, 15 Feb 2017 21:12:32 -0000 fyi/fwiw... target: https://www.chromium.org/ sec-token-binding:AIkAAgBBQMaFRvLPy1uUBZer64ZluK8oBJ8kpcnO84kmCX29demwilh57_4gqlqRLBcZ_dh8x9KdN6TQQZWciZlGmhZp3sUAQFWhQBmwYSLGqlQ59KCOsYpn7Ex1dB_L5bAUTdEjd98Y5CY7NY6aczxi2gC7I6xEMAC4tONGdNOjoALTLt72REUAAA I used the built-in chrome developer tools to examine the request headers and obtain the above STB [ innarestingly enuff, if one targets https://www.google.com/, it seems developer tools only displays the below... Provisional headers are shown Referer:https://www.google.com/ User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 ] From nobody Wed Feb 15 15:29:21 2017 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 AD660129BCB for ; Wed, 15 Feb 2017 15:29:19 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 jopkDO9q44p8 for ; Wed, 15 Feb 2017 15:29:18 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 E09B5129BC7 for ; Wed, 15 Feb 2017 15:29:17 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id w20so1256335qtb.1 for ; Wed, 15 Feb 2017 15:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=deUPw2aEMHq9vWyuoRPPoCv4DUY83kzhJAiS/5jjHsk=; b=IJ+wBfa9UwmVYx5NrchTEr0lkIYayKc2XEMGUMz4SYwC6mE+H5rwrFyqKVyfhJe0+b rDinsd5tj+zDgKjpUKGHgqwy1LDJ/AVuyJUUtpHG41bVeaAaY9ZHksbJXbSMrNYvTlsn 6CuYow5byH7XTFQVTtlpYrAO5neZCcMCLqZvWboEx3e7o8vg9RL+AtjHNoXU5lBvGbcG mACD52bkjSoTSPWVykwUEDQOxyULP7FYsesVqOMWBKnhKrCL9Vc6jDJiKOcvfoLXKhNJ s8M0pUsOagj0WLSZoXo0UDquoukCWgantcawFCAem8f6Y7M0+XYrqz7OBBaS4oJR7ow3 USRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=deUPw2aEMHq9vWyuoRPPoCv4DUY83kzhJAiS/5jjHsk=; b=XkqlYKOUMeATWAmBYHveWPnWb8bLNo5EzyvrNyyTsUENXOJUnXF+AutXxnD5+2LJGl xKQPYRU28eXbZtASqrxDBgU4HQQALMzFMa1lpAZYtoxkHMN58vGlgf7/cvOgpFlY3CbA 2qPjxXNiYpTDG6SsaDznTmwSqnwdXOjAbf58dsNO29MF+8sAFCSJY+US4O9wxT83aVog 8kCRfNgHeUnXhKZyXzPaUxUwNzIsaan9/bQSN8rMrS0FYBK3ct1dv2MR7ZV2YcK3xhau sz71lRZNqLteLJtDnRJC++BdQ29C3bA02YPMeuSWYQHWeKhd+vSkJgl+kPMj8b0OdqzH Y97Q== X-Gm-Message-State: AMke39lWVMPap+6NPyD+KH1HBqcVpXm/bwsyJTRHzrcys7kd/qjIL+3cf3IfZ5XvaSt06t2O X-Received: by 10.200.35.124 with SMTP id b57mr37257676qtb.147.1487201356997; Wed, 15 Feb 2017 15:29:16 -0800 (PST) Received: from [192.168.8.100] ([181.201.204.34]) by smtp.gmail.com with ESMTPSA id c144sm233094qkg.3.2017.02.15.15.29.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 15:29:16 -0800 (PST) From: John Bradley Message-Id: <06A6B2F5-9026-4B30-A099-EB3B8F8AEFB4@ve7jtb.com> Content-Type: multipart/signed; boundary="Apple-Mail=_A5704236-D82A-41A4-96E6-D79D6AC1B159"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 15 Feb 2017 20:29:13 -0300 In-Reply-To: <0d90fcf0-0ec7-448c-d0ad-0385062400b9@KingsMountain.com> To: =JeffH Hodges References: <0d90fcf0-0ec7-448c-d0ad-0385062400b9@KingsMountain.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF TokBind WG Subject: Re: [Unbearable] sec-token-binding header in the wild 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, 15 Feb 2017 23:29:20 -0000 --Apple-Mail=_A5704236-D82A-41A4-96E6-D79D6AC1B159 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Strange I see them on both sites with Edge. With chrome on osx and windows I am not seeing them after turning on the = flag and restarting. I don=E2=80=99t know if the header capture is messing with it somehow. Google.cl negotiated TB with Edge. John B. > On Feb 15, 2017, at 6:12 PM, =3DJeffH = wrote: >=20 > fyi/fwiw... >=20 > target: https://www.chromium.org/ >=20 > = sec-token-binding:AIkAAgBBQMaFRvLPy1uUBZer64ZluK8oBJ8kpcnO84kmCX29demwilh5= 7_4gqlqRLBcZ_dh8x9KdN6TQQZWciZlGmhZp3sUAQFWhQBmwYSLGqlQ59KCOsYpn7Ex1dB_L5b= AUTdEjd98Y5CY7NY6aczxi2gC7I6xEMAC4tONGdNOjoALTLt72REUAAA >=20 > I used the built-in chrome developer tools to examine the request = headers and obtain the above STB >=20 >=20 > [ innarestingly enuff, if one targets https://www.google.com/, it = seems developer tools only displays the below... >=20 > Provisional headers are shown > Referer:https://www.google.com/ > User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) = AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 > ] >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_A5704236-D82A-41A4-96E6-D79D6AC1B159 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILMTCCBUcw ggQvoAMCAQICEEAfBHP+tuqufC4R+F+Tu54wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAyIENsaWVudCBDQTAeFw0xNjA4MTIy MTE5NDFaFw0xODA4MTIyMTE5NDFaMIGCMQswCQYDVQQGEwJDTDEiMCAGA1UECAwZTWV0cm9wb2xp dGFuYSBkZSBTYW50aWFnbzEWMBQGA1UEBwwNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAwwMSm9obiBC cmFkbGV5MSAwHgYJKoZIhvcNAQkBFhF2ZTdqdGJAdmU3anRiLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALhTcSiDGvVrm4hlJA8WyFcWWe0dqnuJzstQYTaF281JFOEPA/13kQYI JMXAEUcS7NvW7KdUI0tHU0N6RTo0Ilf1E1nm8No++eqHO8pFUZ/cidpv0r+1Qcl9EgrpbZ00Y7Xg pq06EZELzJAmds4QQcsTKdpLNFbVcFnM11i2Gj5VNsYgO+qPO2AS8rLHkgDWnNkc9/lA+ZK5wGiU zxPU9KnIrERoTif3Zk7KjLvFpBWYD60M/lNoHZ5zxYgmYLmvoM1TSLn4Ms57wwT5MieV2l0aqlGC 7CKNa6XyeL1B0y0wSxL3PJQS4vSLDnttZC7od2A6yjeUMyM3rQ41vqUIMc8CAwEAAaOCAcMwggG/ MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUmA9bUmBmTYkCcZ3yYv8IRRP2nN4wHwYDVR0jBBgwFoAUmZerGDU6i1lFQ5iy cnHI9PsJzxYwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNz bC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGll bnQyLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xp ZW50Mi5jcmwwHAYDVR0RBBUwE4ERdmU3anRiQHZlN2p0Yi5jb20wIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMFUGA1UdIAROMEwwDAYKKwYBBAGBtTcGATA8BgsrBgEEAYG1NwEC BTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4IBAQBqcYJfFA/ITkX4L6JihqW168Wog1BOfkbPXO+wPn5G9P1NwruGfu41b70EPPwV vol+/j+qhSSrDjFyfNBsq4G45GRR6hwx0ei/bH0UW15Y63ASYPkNlj3ydCcvhw5ItWD5aYPphBx9 C7tLnQ7ow09cqt2CIgPd3W/IGri7p4hWPbdcX0oFIhJcDxmCwTcWyoVoIo4aas5gP44LPGneCoqI lXQMJinwneEnKd7rWXlzVWv7geaH3t79zARSw9ev9F4E61cDuHi+vgTFEpio7oxybqfj99yLibhX uZjReYnYbDMRiWDXduVIrIGYwmnUuD8a0b20kJgHm+FEgB6UMa9JMIIF4jCCA8qgAwIBAgIQXLZI bkcMmMZ/9oDbZErijTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1 WhcNMzAxMjE2MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDIgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7g9Q jJUJI4Ss9VBqj9Y3ok4h/TIJZUc+rzj61Rv3hNB/yeEEC1fz3i/EU+MXOOGxM7KCbtCIcJxHIW/k 8RP6sPPMO4cTg7sNzfBWsYsemtY6fN/kVr2R2X+/PjvtxmAaXpGX0znvQPxaE123IMGXy0zEKHZ/ nJDZ199TP9TNn9v+1QO0AZb4oaJ7ch0DpSJa8kF5xiNFDAg9taKKSrVuPHJL9MFFYPIqwShjHg+u YEzjfxbMP2QWwamnaA9Y7fORSDNapduFlARAcDtXdMpAijiG4HKnrN323I0Ka7lDTAWyLtTDCETK sI8fzOyL0inEu1WEVpdPytm8s1rwQB4f9QIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQr MCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRa MFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBSZl6sYNTqLWUVDmLJy ccj0+wnPFjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUd IAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4ICAQCZQUEEzvYk9U4wNHhDu1f9QGwbzAH4m4wIKH8ZidNYwZhyoNKW041iJ002KMW9 ywYM95n4770tT45yH29vTMlZtBvz0h44KuxMLNXRCTDwvV07sT39nPjFi5MpwZaLVueNiaa1vok1 n2Wn8lLcyCltYZNGAEifM0ko/A/vvckftFIZG75RAiZHYtfnrdBGiOxyF+nHI9a33BRX5Vl/3z0+ uHZ/Y6YPbNJ7iboOFrFZBCtt+lp3WaDB62ZoBewiMmd09JrqmMJAEgw3EbfQNtaPzHPg/EOhlZik Rgd4BCrzrbIqB2RKib+gnQJt2uoJaKOaV90S9Xgs3PC837OE9CEmY6/MTTG0xpbLh2hR/rLQ3sCr H56aODeuDrQBq85lXxRbDCERDUR7FZUhHv+i1aQaY59NPu26hDd6nqksSDq2mCddpidPBuGJz9lN X2nRyGkudDuWV6gIr6AZfaYv+ggTXOcCDJZFzMhWdLC7CPvRKxQ7vTiYV+4lgqOvV9MnZc149PPt itTysq/oOv70zx7q+tyaLTa4cqFhCclhIwSwOEJiV3xqQebvmwsDX7BaXGAJZIhbdUbNr3poEgct 6uAxw2zyr69WCJmTUUhz/k1/TT/eCUZJqnMg/6mje7tiVdaUQJcBtJ6cq5+mUDNUB1fohW8EOFai zFpP/0FaP62ctTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMiBDbGllbnQgQ0ECEEAfBHP+tuqufC4R+F+Tu54wCQYFKw4DAhoF AKCCAZkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjE1MjMy OTE0WjAjBgkqhkiG9w0BCQQxFgQUJHmDfaTIDhuscVY88wFSDkStgkAwgZoGCSsGAQQBgjcQBDGB jDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIg Q2xpZW50IENBAhBAHwRz/rbqrnwuEfhfk7ueMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIgQ2xpZW50IENBAhBA HwRz/rbqrnwuEfhfk7ueMA0GCSqGSIb3DQEBAQUABIIBAD7O9cKNQPNVyl7UC5JIv1aGZizQv5wY wkdJBf15g6s42JS74Ha1MeCuQ0xrJUSH5cYWdHZn7iRwijAcHfqcHJIzPygHVqxSFK9Mx9/FwIlz mfGii6mAlWHEKWR5pIRvNWt0OwCx+Zgnob8T0DJs3+/vqP0Mzjl98he2eFR32lDq36OlNwsrcCE/ DehYdlcawvERpBg+fLzr/webxrZs7wekkVTGw2vncQnKbxC46X5k+ujLLUNVGcLsmM+OQIOdqoH3 nhxPVEezyzzsaxdt77f9FQlMJlR7VgeWDJbQRtPyDKnQy0tT+2JoLqfaEO8rKZ9sVDMmA9+ni+YM Uf2JbZwAAAAAAAA= --Apple-Mail=_A5704236-D82A-41A4-96E6-D79D6AC1B159-- From nobody Wed Feb 15 15:37:09 2017 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 A6CD3129959 for ; Wed, 15 Feb 2017 15:37:07 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wu9G68nuAqcB for ; Wed, 15 Feb 2017 15:37:06 -0800 (PST) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002: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 F17F3129860 for ; Wed, 15 Feb 2017 15:37:05 -0800 (PST) Received: by mail-yb0-x22a.google.com with SMTP id w194so437029ybe.0 for ; Wed, 15 Feb 2017 15:37:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rQpkx0t5fG6GzjlWrfZacImcclQUAyExS7C7z8dFjwc=; b=LM5pWSwyRcuIC4VCa2+eTAR8g/59iVcwRXjWpTwE7jArShjYEJbQkK21TkXMomr2nd subL8WLZ1l1WlP+OIqUssoIilJgd3NzlIvZnumCNa/Sxq9nIX/2Ns9+myXxYAnTPol13 4+XEkxxLbB4gwVSrOS5G5PT69q0iek/wUBKs04sS1LqCEYAL6IkX5GLqzof6cziq+73R wEHDFzb9usXLYZOAHhPP4sKBre7ncrXuJ4jb6fgj1VidiBko+q6/RGnwu58Y4n2FsX5J lZy9rhmzplRcna0pktWmi52Pxgx1aa73m4k3XCcWSERqwRfLOsfWD3P3ZfkbBq2y0tmw J2Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rQpkx0t5fG6GzjlWrfZacImcclQUAyExS7C7z8dFjwc=; b=Yv/1+lsMpBFvGNa6DuKIqCB1SHAHCm1UtBLCMAVNrdHSSJrhTw3kUkDWcS7Ed7bf/s fjkMfUyYPzipXczUl+vCdnc5C4/LPxDFRXDR8gYTKIOERC4grw7FbHLvEX0jaLTNZAOz LnMkheAf7mPtcfrvggCSqSuA0v+4L+/9vbIURiOHnOnX8wDr/HdTh9kP4ztML10H4pSq LRoJfVyf3P//0v1BU3NwEys8oM3Uaqzhu/7K5IQlA4iB1X8FLFgR7+YHy6jRWNHla/MB lzuwzOVlVuPVW6erehHn31hW0SQAYeZhSPqbtqLF/72KqxSuPZ7qnKYCC52n4QzlKb4y 0F7g== X-Gm-Message-State: AMke39mZOWCbYQVrg18HeldsCwr+rely9I5GMeb1B39/FZvlsdzqJydgq+iPWRwaXgEXCB2ea3tGQy44T/aabiPW X-Received: by 10.37.51.215 with SMTP id z206mr27628679ybz.88.1487201825010; Wed, 15 Feb 2017 15:37:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.161.87 with HTTP; Wed, 15 Feb 2017 15:36:44 -0800 (PST) In-Reply-To: <06A6B2F5-9026-4B30-A099-EB3B8F8AEFB4@ve7jtb.com> References: <0d90fcf0-0ec7-448c-d0ad-0385062400b9@KingsMountain.com> <06A6B2F5-9026-4B30-A099-EB3B8F8AEFB4@ve7jtb.com> From: Nick Harper Date: Wed, 15 Feb 2017 15:36:44 -0800 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a1148a1187d7b7c05489a28cd Archived-At: Cc: IETF TokBind WG , =JeffH Hodges Subject: Re: [Unbearable] sec-token-binding header in the wild 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, 15 Feb 2017 23:37:07 -0000 --001a1148a1187d7b7c05489a28cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I see the sec-token-binding header for both www.google.com and www.chromium.org from chrome on os x (version 56.0.2924.87). On Wed, Feb 15, 2017 at 3:29 PM, John Bradley wrote: > Strange I see them on both sites with Edge. > > With chrome on osx and windows I am not seeing them after turning on the > flag and restarting. > > I don=E2=80=99t know if the header capture is messing with it somehow. > > Google.cl negotiated TB with Edge. > > John B. > > > On Feb 15, 2017, at 6:12 PM, =3DJeffH > wrote: > > > > fyi/fwiw... > > > > target: https://www.chromium.org/ > > > > sec-token-binding:AIkAAgBBQMaFRvLPy1uUBZer64ZluK > 8oBJ8kpcnO84kmCX29demwilh57_4gqlqRLBcZ_dh8x9KdN6TQQZWciZlGmhZp3sUAQFW > hQBmwYSLGqlQ59KCOsYpn7Ex1dB_L5bAUTdEjd98Y5CY7NY6aczxi2gC7I > 6xEMAC4tONGdNOjoALTLt72REUAAA > > > > I used the built-in chrome developer tools to examine the request > headers and obtain the above STB > > > > > > [ innarestingly enuff, if one targets https://www.google.com/, it seems > developer tools only displays the below... > > > > Provisional headers are shown > > Referer:https://www.google.com/ > > User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 > > ] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > 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 > > --001a1148a1187d7b7c05489a28cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see the sec-token-binding header for both www.google.com and www.chromium.org from chrome on os x (version 56.0.2924.87).
<= div class=3D"gmail_extra">
On Wed, Feb 15, 20= 17 at 3:29 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Strange I see them on both sites with Edge.
With chrome on osx and windows I am not seeing them after turning on the fl= ag and restarting.

I don=E2=80=99t know if the header capture is messing with it somehow.

Google.cl negotiated TB with Edge.

John B.

> On Feb 15, 2017, at 6:12 PM, =3DJeffH <Jeff.Hodges@KingsMountain.co= m> wrote:
>
> fyi/fwiw...
>
> target: https://www.chromium.org/
>
> sec-token-binding:AIkAAgBBQMaFRvLPy1uUBZer64ZluK8oBJ8kpcnO84= kmCX29demwilh57_4gqlqRLBcZ_dh8x9KdN6TQQZWciZlGmhZp3sUAQFWhQB= mwYSLGqlQ59KCOsYpn7Ex1dB_L5bAUTdEjd98Y5CY7NY6aczxi2gC7I6xEMAC4tON= GdNOjoALTLt72REUAAA
>
> I used the built-in chrome developer tools to examine the request head= ers and obtain the above STB
>
>
> [ innarestingly enuff, if one targets https://www.google.com/, it se= ems developer tools only displays the below...
>
> Provisional headers are shown
> Referer:https://www.google.com/
> User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit= /537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
> ]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbe= arable


_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearabl= e


--001a1148a1187d7b7c05489a28cd-- From nobody Wed Feb 15 15:46:52 2017 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 7AFEE129BEE for ; Wed, 15 Feb 2017 15:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 eVxqBDSm7h0d for ; Wed, 15 Feb 2017 15:46:48 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 327B8129BEA for ; Wed, 15 Feb 2017 15:46:48 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id v23so1569257qtb.0 for ; Wed, 15 Feb 2017 15:46:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EfhEBRJLJBGsrF+sFT0tSkQ/qapJObKqPt8stuEQiYk=; b=TtbYcpXb6t5v5tdisj0BsfCtLTH9v3Y3azQezoE9tdRuSfFMj8rNgRwzBs0/WTlu0F IJcNNh0M39McnsPuFTVMGRwop+aNZRpW8voCNQfpfbapdcZb+c5WXYazbeTaqNB79nhC k50GHT8/Ezui/7+WghnJ5/9ElFznVtCfxjWGIQyLn6770WD7gXO1++X7unzzpjic9+k5 qmrCiRRbZXxyNnfQOhWV5tZr9VB0+4bh4coFaXpY1C9hKCR8Noqq+y+jjuJXsDHOLZg4 MBUnajV6Dkpy7zm48UKdbDwcvascMc7Y+wEWlLLN/J9LilSB+Nz9ePGN2VpCvyti6RxO TfUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=EfhEBRJLJBGsrF+sFT0tSkQ/qapJObKqPt8stuEQiYk=; b=WU6H1bBbCg4ZE5BUI/rJoQ3BUZWAkEMDXiDygevG0KFpVnIvoMzbpk9lbJJYBM7Tss ML7lqLU4SMBD5taLqugpCUpUDFecf1dikkkyZw3PTyZZFkic70Gh0C8hiolI2xDwhaUJ VzTbj90F1B1jzkim3mTEdyYXo5jteYVTOwmo3H+J8WhcaAW9vBS7TNQq7rCyblsbnd/G SgEWUiNfihJ8+EAWnpvbyCVUpEUIINnzFb7fA24Qe+8TAxe0maqxjurixzYDhWD7Q2fS FLRQOPlZqy266cmh16vOMNN4omzzM2S38vz9hk+Q8oobcw41aFDUxachiVxtwo5K5zDL J9ew== X-Gm-Message-State: AMke39mQYfBhqkgIbTurDrFIztUkATz0DLjtRH0YmUxo3beiWHVkhn+gsQs7pkOp10nQRO7K X-Received: by 10.200.45.103 with SMTP id o36mr37789278qta.266.1487202407177; Wed, 15 Feb 2017 15:46:47 -0800 (PST) Received: from [192.168.8.100] ([181.201.204.34]) by smtp.gmail.com with ESMTPSA id k19sm3298764qtf.37.2017.02.15.15.46.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 15:46:46 -0800 (PST) From: John Bradley Message-Id: <0A2CF74F-D5FE-48EF-B9AC-0F06BA1DE1D7@ve7jtb.com> Content-Type: multipart/signed; boundary="Apple-Mail=_EDF814DA-4181-4831-803F-AA1B233E00FE"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 15 Feb 2017 20:46:43 -0300 In-Reply-To: To: Nick Harper References: <0d90fcf0-0ec7-448c-d0ad-0385062400b9@KingsMountain.com> <06A6B2F5-9026-4B30-A099-EB3B8F8AEFB4@ve7jtb.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF TokBind WG , =JeffH Hodges Subject: Re: [Unbearable] sec-token-binding header in the wild 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, 15 Feb 2017 23:46:50 -0000 --Apple-Mail=_EDF814DA-4181-4831-803F-AA1B233E00FE Content-Type: multipart/alternative; boundary="Apple-Mail=_CD8D19D8-F55F-4E0D-A14D-0ADE7C715164" --Apple-Mail=_CD8D19D8-F55F-4E0D-A14D-0ADE7C715164 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I tried 56.0.2924.87 and 58.0.3013.0 OSX and 58,0,3007 (ChromeOS) with = no luck. It might be the extension to capture headers that is messing me up. What are you using. I used the HTTP trace extension. John B. > On Feb 15, 2017, at 8:36 PM, Nick Harper wrote: >=20 > I see the sec-token-binding header for both www.google.com = and www.chromium.org = from chrome on os x (version 56.0.2924.87). >=20 > On Wed, Feb 15, 2017 at 3:29 PM, John Bradley > wrote: > Strange I see them on both sites with Edge. >=20 > With chrome on osx and windows I am not seeing them after turning on = the flag and restarting. >=20 > I don=E2=80=99t know if the header capture is messing with it somehow. >=20 > Google.cl negotiated TB with Edge. >=20 > John B. >=20 > > On Feb 15, 2017, at 6:12 PM, =3DJeffH = wrote: > > > > fyi/fwiw... > > > > target: https://www.chromium.org/ > > > > = sec-token-binding:AIkAAgBBQMaFRvLPy1uUBZer64ZluK8oBJ8kpcnO84kmCX29demwilh5= 7_4gqlqRLBcZ_dh8x9KdN6TQQZWciZlGmhZp3sUAQFWhQBmwYSLGqlQ59KCOsYpn7Ex1dB_L5b= AUTdEjd98Y5CY7NY6aczxi2gC7I6xEMAC4tONGdNOjoALTLt72REUAAA > > > > I used the built-in chrome developer tools to examine the request = headers and obtain the above STB > > > > > > [ innarestingly enuff, if one targets https://www.google.com/ = , it seems developer tools only displays the = below... > > > > Provisional headers are shown > > Referer:https://www.google.com/ > > User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) = AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 > > ] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Unbearable mailing list > > Unbearable@ietf.org > > https://www.ietf.org/mailman/listinfo/unbearable = >=20 >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable = >=20 >=20 --Apple-Mail=_CD8D19D8-F55F-4E0D-A14D-0ADE7C715164 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I tried 56.0.2924.87 and 58.0.3013.0 OSX  and 58,0,3007 (ChromeOS) = with no luck.

It might be the = extension to capture headers that is messing me up.

What are you using. =  I used the HTTP trace extension.

John = B.

On Feb 15, 2017, at 8:36 PM, Nick Harper <nharper@google.com> = wrote:

I see the sec-token-binding header for both www.google.com and www.chromium.org from = chrome on os x (version 56.0.2924.87).
On Wed, Feb 15, 2017 at 3:29 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
Strange I see them on = both sites with Edge.

With chrome on osx and windows I am not seeing them after turning on the = flag and restarting.

I don=E2=80=99t know if the header capture is messing with it = somehow.

Google.cl negotiated TB with Edge.

John B.

> On Feb 15, 2017, at 6:12 PM, =3DJeffH <Jeff.Hodges@KingsMountain.com> = wrote:
>
> fyi/fwiw...
>
> target: https://www.chromium.org/
>
> sec-token-binding:AIkAAgBBQMaFRvLPy1uUBZer64ZluK8oBJ8kpcnO84kmCX29demwilh57_4gqlqRLBcZ_dh8x9KdN6TQQZWciZlGmhZp3sUAQFWhQBmwYSLGqlQ59KCOsYpn7Ex1dB_L5bAUTdEjd98Y5CY7NY6aczxi2gC7I6xEMAC4tONGdNOjoALTLt72REUAAA
>
> I used the built-in chrome developer tools to examine the request = headers and obtain the above STB
>
>
> [ innarestingly enuff, if one targets https://www.google.com/, it seems developer tools only = displays the below...
>
> Provisional headers are shown
> Referer:https://www.google.com/
> User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) = AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 = Safari/537.36
> ]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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



= --Apple-Mail=_CD8D19D8-F55F-4E0D-A14D-0ADE7C715164-- --Apple-Mail=_EDF814DA-4181-4831-803F-AA1B233E00FE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILMTCCBUcw ggQvoAMCAQICEEAfBHP+tuqufC4R+F+Tu54wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAyIENsaWVudCBDQTAeFw0xNjA4MTIy MTE5NDFaFw0xODA4MTIyMTE5NDFaMIGCMQswCQYDVQQGEwJDTDEiMCAGA1UECAwZTWV0cm9wb2xp dGFuYSBkZSBTYW50aWFnbzEWMBQGA1UEBwwNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAwwMSm9obiBC cmFkbGV5MSAwHgYJKoZIhvcNAQkBFhF2ZTdqdGJAdmU3anRiLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALhTcSiDGvVrm4hlJA8WyFcWWe0dqnuJzstQYTaF281JFOEPA/13kQYI JMXAEUcS7NvW7KdUI0tHU0N6RTo0Ilf1E1nm8No++eqHO8pFUZ/cidpv0r+1Qcl9EgrpbZ00Y7Xg pq06EZELzJAmds4QQcsTKdpLNFbVcFnM11i2Gj5VNsYgO+qPO2AS8rLHkgDWnNkc9/lA+ZK5wGiU zxPU9KnIrERoTif3Zk7KjLvFpBWYD60M/lNoHZ5zxYgmYLmvoM1TSLn4Ms57wwT5MieV2l0aqlGC 7CKNa6XyeL1B0y0wSxL3PJQS4vSLDnttZC7od2A6yjeUMyM3rQ41vqUIMc8CAwEAAaOCAcMwggG/ MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUmA9bUmBmTYkCcZ3yYv8IRRP2nN4wHwYDVR0jBBgwFoAUmZerGDU6i1lFQ5iy cnHI9PsJzxYwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNz bC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGll bnQyLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xp ZW50Mi5jcmwwHAYDVR0RBBUwE4ERdmU3anRiQHZlN2p0Yi5jb20wIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMFUGA1UdIAROMEwwDAYKKwYBBAGBtTcGATA8BgsrBgEEAYG1NwEC BTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4IBAQBqcYJfFA/ITkX4L6JihqW168Wog1BOfkbPXO+wPn5G9P1NwruGfu41b70EPPwV vol+/j+qhSSrDjFyfNBsq4G45GRR6hwx0ei/bH0UW15Y63ASYPkNlj3ydCcvhw5ItWD5aYPphBx9 C7tLnQ7ow09cqt2CIgPd3W/IGri7p4hWPbdcX0oFIhJcDxmCwTcWyoVoIo4aas5gP44LPGneCoqI lXQMJinwneEnKd7rWXlzVWv7geaH3t79zARSw9ev9F4E61cDuHi+vgTFEpio7oxybqfj99yLibhX uZjReYnYbDMRiWDXduVIrIGYwmnUuD8a0b20kJgHm+FEgB6UMa9JMIIF4jCCA8qgAwIBAgIQXLZI bkcMmMZ/9oDbZErijTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1 WhcNMzAxMjE2MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDIgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7g9Q jJUJI4Ss9VBqj9Y3ok4h/TIJZUc+rzj61Rv3hNB/yeEEC1fz3i/EU+MXOOGxM7KCbtCIcJxHIW/k 8RP6sPPMO4cTg7sNzfBWsYsemtY6fN/kVr2R2X+/PjvtxmAaXpGX0znvQPxaE123IMGXy0zEKHZ/ nJDZ199TP9TNn9v+1QO0AZb4oaJ7ch0DpSJa8kF5xiNFDAg9taKKSrVuPHJL9MFFYPIqwShjHg+u YEzjfxbMP2QWwamnaA9Y7fORSDNapduFlARAcDtXdMpAijiG4HKnrN323I0Ka7lDTAWyLtTDCETK sI8fzOyL0inEu1WEVpdPytm8s1rwQB4f9QIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQr MCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRa MFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBSZl6sYNTqLWUVDmLJy ccj0+wnPFjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUd IAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4ICAQCZQUEEzvYk9U4wNHhDu1f9QGwbzAH4m4wIKH8ZidNYwZhyoNKW041iJ002KMW9 ywYM95n4770tT45yH29vTMlZtBvz0h44KuxMLNXRCTDwvV07sT39nPjFi5MpwZaLVueNiaa1vok1 n2Wn8lLcyCltYZNGAEifM0ko/A/vvckftFIZG75RAiZHYtfnrdBGiOxyF+nHI9a33BRX5Vl/3z0+ uHZ/Y6YPbNJ7iboOFrFZBCtt+lp3WaDB62ZoBewiMmd09JrqmMJAEgw3EbfQNtaPzHPg/EOhlZik Rgd4BCrzrbIqB2RKib+gnQJt2uoJaKOaV90S9Xgs3PC837OE9CEmY6/MTTG0xpbLh2hR/rLQ3sCr H56aODeuDrQBq85lXxRbDCERDUR7FZUhHv+i1aQaY59NPu26hDd6nqksSDq2mCddpidPBuGJz9lN X2nRyGkudDuWV6gIr6AZfaYv+ggTXOcCDJZFzMhWdLC7CPvRKxQ7vTiYV+4lgqOvV9MnZc149PPt itTysq/oOv70zx7q+tyaLTa4cqFhCclhIwSwOEJiV3xqQebvmwsDX7BaXGAJZIhbdUbNr3poEgct 6uAxw2zyr69WCJmTUUhz/k1/TT/eCUZJqnMg/6mje7tiVdaUQJcBtJ6cq5+mUDNUB1fohW8EOFai zFpP/0FaP62ctTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMiBDbGllbnQgQ0ECEEAfBHP+tuqufC4R+F+Tu54wCQYFKw4DAhoF AKCCAZkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjE1MjM0 NjQ0WjAjBgkqhkiG9w0BCQQxFgQUBX21eGf3M4scS5+0FYHAa/EVUEAwgZoGCSsGAQQBgjcQBDGB jDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIg Q2xpZW50IENBAhBAHwRz/rbqrnwuEfhfk7ueMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIgQ2xpZW50IENBAhBA HwRz/rbqrnwuEfhfk7ueMA0GCSqGSIb3DQEBAQUABIIBAHipO74KDsswPdTbWvBwz5bmX4nS0UJg 8nay2LfhP8q8E1LQecTddaD8KnVjYnV30hab40BxYUc51QGd7zfoxj9uM5SYlvJlqyWO4luWCfct Uvb6gG2I2y+ZtXlCATXwXmPdnfjZspXMaVm7Vx1+lrcuDWZ4a58LKDnyEUSUkj8Fx7H2fFdLav2Y L7WcDxSw5wfHC19n2tXn5jrNb5wUIT47xSKJkThZqJObOvlVVhKezM8kMt58f3cJfNHgoZu0VBvp K9zYaisSuIMe9OFztWtYFdYAyaYfcrM7v6yL8zNDa55Lykl8pPy6i8F8NHO4zRe7AXArbdnwrDU6 KScbr1MAAAAAAAA= --Apple-Mail=_EDF814DA-4181-4831-803F-AA1B233E00FE-- From nobody Wed Feb 15 15:50:27 2017 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 81248129C00 for ; Wed, 15 Feb 2017 15:50:25 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 uc1I7p8kNEUd for ; Wed, 15 Feb 2017 15:50:23 -0800 (PST) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::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 90CFC129C02 for ; Wed, 15 Feb 2017 15:50:19 -0800 (PST) Received: by mail-yb0-x234.google.com with SMTP id j82so475084ybg.1 for ; Wed, 15 Feb 2017 15:50:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7WGQof0UAiG9mu56ifO1e1Wq5htBcKYOn8fbpr7M+mA=; b=OQhWgbMWOl9LpON1if6LcjosLrUDx5NL6cx9TwZeKKqUsl4TsbLZeUNin/YxQuebdy 9BzyZkzqV1MVq/wHK/cRxMmDz0hABl2EXStr/BOe1GyvGLagxpr4oihGC0f/Dkx2K63w /9C3vv50sQZOK+t4PtmRtQuGzMbArvA0GlFE5TWXu5pnu8McbygFkZpX0SnmYhRH38W4 p3fSEih7xNhXUHpJ0vIwBFAFFDIm29cv5hVlp8Nm4NFCj9L9qbK8Cgifo3H5154cq6Nv 0kjqaHsvsQzVbjHlVesyKr2mJnmAXfky43jaUsaXAVhcxYzR51oFUvlKbtv4thGYPsKH nCWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7WGQof0UAiG9mu56ifO1e1Wq5htBcKYOn8fbpr7M+mA=; b=pQT0I+dDcoEvANNrWrWMerauyqLUbmzwHn2h2oqvgu9l2fiaAVRrLfqooaL4dCEHq0 HDSmLS7Yts3iMeyBBHYTfYzVKUbzWA3vD3DGl8lWrS81OfsRmt2LKyJCV1KfDkh2qhcQ w34tYj/4BnFsI5dTOtSUytrXIfcjM+I2a58sei+a0iskDqlvYGVHn773sVGaoVPLGdQd Fon8V7nuhz0qZMjGpmpGm6sWojeNIV0LOzzfp+yZUzN0rHzybvhE8bfLXfJLej6JER6l FJgdxS0eg7y5inXIvBZQEnldH3atTPuEK86Nrr18r4e4dn0r63QzvvbgtX80AO6QF4qc 87nA== X-Gm-Message-State: AMke39k6JQetrDT6lGIc4wbFT74jGBObdDjRm4t2kcrx6oWIWcWhPejOSxaeTmOGnZxkFGFjSztvIL+ZIoewnWe4 X-Received: by 10.37.248.13 with SMTP id u13mr27834527ybd.98.1487202618628; Wed, 15 Feb 2017 15:50:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.161.87 with HTTP; Wed, 15 Feb 2017 15:49:58 -0800 (PST) In-Reply-To: <0A2CF74F-D5FE-48EF-B9AC-0F06BA1DE1D7@ve7jtb.com> References: <0d90fcf0-0ec7-448c-d0ad-0385062400b9@KingsMountain.com> <06A6B2F5-9026-4B30-A099-EB3B8F8AEFB4@ve7jtb.com> <0A2CF74F-D5FE-48EF-B9AC-0F06BA1DE1D7@ve7jtb.com> From: Nick Harper Date: Wed, 15 Feb 2017 15:49:58 -0800 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=f403045dc640cb4b8805489a57da Archived-At: Cc: IETF TokBind WG , =JeffH Hodges Subject: Re: [Unbearable] sec-token-binding header in the wild 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, 15 Feb 2017 23:50:25 -0000 --f403045dc640cb4b8805489a57da Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm using the network tab of chrome's built-in dev tools to view the headers (Ctrl+Shift+I, or kebab menu > more tools > developer tools). As long as the flag is flipped in chrome://flags, it should be negotiating token binding, but I don't know how that extension might be interfering. On Wed, Feb 15, 2017 at 3:46 PM, John Bradley wrote: > I tried 56.0.2924.87 and 58.0.3013.0 OSX and 58,0,3007 (ChromeOS) with > no luck. > > It might be the extension to capture headers that is messing me up. > > What are you using. I used the HTTP trace extension. > > John B. > > On Feb 15, 2017, at 8:36 PM, Nick Harper wrote: > > I see the sec-token-binding header for both www.google.com and > www.chromium.org from chrome on os x (version 56.0.2924.87). > > On Wed, Feb 15, 2017 at 3:29 PM, John Bradley wrote: > >> Strange I see them on both sites with Edge. >> >> With chrome on osx and windows I am not seeing them after turning on the >> flag and restarting. >> >> I don=E2=80=99t know if the header capture is messing with it somehow. >> >> Google.cl negotiated TB with Edge. >> >> John B. >> >> > On Feb 15, 2017, at 6:12 PM, =3DJeffH >> wrote: >> > >> > fyi/fwiw... >> > >> > target: https://www.chromium.org/ >> > >> > sec-token-binding:AIkAAgBBQMaFRvLPy1uUBZer64ZluK8oBJ8kpcnO84 >> kmCX29demwilh57_4gqlqRLBcZ_dh8x9KdN6TQQZWciZlGmhZp3sUAQFWhQB >> mwYSLGqlQ59KCOsYpn7Ex1dB_L5bAUTdEjd98Y5CY7NY6aczxi2gC7I6xEMA >> C4tONGdNOjoALTLt72REUAAA >> > >> > I used the built-in chrome developer tools to examine the request >> headers and obtain the above STB >> > >> > >> > [ innarestingly enuff, if one targets https://www.google.com/, it >> seems developer tools only displays the below... >> > >> > Provisional headers are shown >> > Referer:https://www.google.com/ >> > User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) >> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 >> > ] >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > 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 >> >> > > --f403045dc640cb4b8805489a57da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm using the network tab of chrome's built-in dev= tools to view the headers (Ctrl+Shift+I, or kebab menu > more tools >= ; developer tools). As long as the flag is flipped in chrome://flags, it sh= ould be negotiating token binding, but I don't know how that extension = might be interfering.

On Wed, Feb 15, 2017 at 3:46 PM, John Bradley &= lt;ve7jtb@ve7jtb.com= > wrote:
I tried=C2=A056.0.2924.87 and=C2=A058.0.3013.0 OS= X =C2=A0and 58,0,3007 (ChromeOS) with no luck.

It might be the extension = to capture headers that is messing me up.

What are you using.=C2=A0 I use= d the HTTP trace extension.

John B.
=

On Feb 15, 2017, at 8:36 PM, Nick Harper <nharper@google.com> wrote:

= I see the sec-token-binding header for both www.google.com and www.chromium.org from chrome on os x (version = 56.0.2924.87).

On Wed, Feb 15, 2017 at 3:29 PM, John Bradley <ve7jtb@ve7jtb.com>= ; wrote:
Strange I see them on bot= h sites with Edge.

With chrome on osx and windows I am not seeing them after turning on the fl= ag and restarting.

I don=E2=80=99t know if the header capture is messing with it somehow.

Google.cl negotiated TB with Edge.

John B.

> On Feb 15, 2017, at 6:12 PM, =3DJeffH <Jeff.Hodges@KingsMountain.com> wrote:
>
> fyi/fwiw...
>
> target: https://www.chromium.org/
>
> sec-token-binding:AIkAAgBBQMaFRvLPy1uUBZer64ZluK8oBJ8kpcnO84= kmCX29demwilh57_4gqlqRLBcZ_dh8x9KdN6TQQZWciZlGmhZp3sUAQFWhQBmwYSL= GqlQ59KCOsYpn7Ex1dB_L5bAUTdEjd98Y5CY7NY6aczxi2gC7I6xEMAC4tONGdNOj= oALTLt72REUAAA
>
> I used the built-in chrome developer tools to examine the request head= ers and obtain the above STB
>
>
> [ innarestingly enuff, if one targets https://www.google.com/, it se= ems developer tools only displays the below...
>
> Provisional headers are shown
> Referer:https://www.google.com/
> User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit= /537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
> ]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ie= tf.org
> https://www.ietf.org/mailman/listinfo/unbe= arable


_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearabl= e



--f403045dc640cb4b8805489a57da-- From nobody Wed Feb 15 15:55:57 2017 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 D88B112995C for ; Wed, 15 Feb 2017 15:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 CVIhQpiPCCgz for ; Wed, 15 Feb 2017 15:55:55 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d: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 F044F12942F for ; Wed, 15 Feb 2017 15:55:54 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id s186so1842885qkb.1 for ; Wed, 15 Feb 2017 15:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YZkVcSKUIRBPKf9uagRuwcgH+HxjKMKiFgdd+zcRpok=; b=JO0zRhFODZ+7CgPzDTLlxzAwWmXCO9ylcWmpWqlZnTRSbBbfydVniZ7TntH2XiT0pG TexD53yFjDYzrJNZZSxGg/iAAQnXmppoPEATRty7sn6Fpm1QgbJZ3jM73y3vAV+T0xla ERLdxyzM7DXlQ4Jn2ewL+YoMrF2B3Eho1eWcPy+uzI2AEp1+xMLlm71NB5Y2aGJEIc4G HUyTdVcprkJwoQ7UuU4qWC5Fb6lxE0OYXDCdr1rf8jGJ1vi5eHKaB36udXahXuBFwJmS AbmbfF4n8RA/x4xg1XZMRaFOBOew9N0kn0QtcU2BdqapbwiQxeMLQr1JKCUJC7dR1ljq 6phQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YZkVcSKUIRBPKf9uagRuwcgH+HxjKMKiFgdd+zcRpok=; b=V3giw0InH2D+4uzQkhII2DQn9gWG+ItVQLEXKHULx9yvb1gCHjEoKNNN6iryPVcNs0 P/3F+BaH1w1iIViSrSjhO3GuK/DrhwzIh3r64kdb0+X7F6ToYfYgkRMrMBn7nEc3cCEJ W0ifdvyUsH9g+2qaLJ4TN+zhNf/imrKP+jF4cDceVJfzT2d35/jWMrPEauiUO6QkHrro KsUwNzzU9XAzTa85+R2zWtZrK/MMqggBXzsZrsyMhHtkFtOdkxqrE//0AIDJ+yBP53r7 2eR2kTyMQhXfZQh0/dH0O1hJlK36Vh6ZOCiowupiUnBB88gkxG3HfKgtnNa6sd/Ju+hp SKag== X-Gm-Message-State: AMke39mV1DSBH+KOXmMXRLwel4b6g0SeVNn+iMgb3+rOPMpDHrpKrlVoZq+/kkjp/hFKO+pk X-Received: by 10.55.154.204 with SMTP id c195mr34657728qke.293.1487202954052; Wed, 15 Feb 2017 15:55:54 -0800 (PST) Received: from [192.168.8.100] ([181.201.204.34]) by smtp.gmail.com with ESMTPSA id 140sm3312399qkj.19.2017.02.15.15.55.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 15:55:53 -0800 (PST) From: John Bradley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1A1E6725-F0A5-4664-B158-95F1232A5B88"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 15 Feb 2017 20:55:50 -0300 In-Reply-To: To: Nick Harper References: <0d90fcf0-0ec7-448c-d0ad-0385062400b9@KingsMountain.com> <06A6B2F5-9026-4B30-A099-EB3B8F8AEFB4@ve7jtb.com> <0A2CF74F-D5FE-48EF-B9AC-0F06BA1DE1D7@ve7jtb.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF TokBind WG , =JeffH Hodges Subject: Re: [Unbearable] sec-token-binding header in the wild 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, 15 Feb 2017 23:55:57 -0000 --Apple-Mail=_1A1E6725-F0A5-4664-B158-95F1232A5B88 Content-Type: multipart/alternative; boundary="Apple-Mail=_DEE16239-1CE9-4B98-9E77-BC245DA9E1B6" --Apple-Mail=_DEE16239-1CE9-4B98-9E77-BC245DA9E1B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes I see it. The extension must have been filtering out those = headers. =20 I can=E2=80=99t explain what Jeff is seeing. John B. > On Feb 15, 2017, at 8:49 PM, Nick Harper wrote: >=20 > I'm using the network tab of chrome's built-in dev tools to view the = headers (Ctrl+Shift+I, or kebab menu > more tools > developer tools). As = long as the flag is flipped in chrome://flags, it should be negotiating = token binding, but I don't know how that extension might be interfering. >=20 > On Wed, Feb 15, 2017 at 3:46 PM, John Bradley > wrote: > I tried 56.0.2924.87 and 58.0.3013.0 OSX and 58,0,3007 (ChromeOS) = with no luck. >=20 > It might be the extension to capture headers that is messing me up. >=20 > What are you using. I used the HTTP trace extension. >=20 > John B. >=20 >> On Feb 15, 2017, at 8:36 PM, Nick Harper > wrote: >>=20 >> I see the sec-token-binding header for both www.google.com = and www.chromium.org = from chrome on os x (version 56.0.2924.87). >>=20 >> On Wed, Feb 15, 2017 at 3:29 PM, John Bradley > wrote: >> Strange I see them on both sites with Edge. >>=20 >> With chrome on osx and windows I am not seeing them after turning on = the flag and restarting. >>=20 >> I don=E2=80=99t know if the header capture is messing with it = somehow. >>=20 >> Google.cl negotiated TB with Edge. >>=20 >> John B. >>=20 >> > On Feb 15, 2017, at 6:12 PM, =3DJeffH = > = wrote: >> > >> > fyi/fwiw... >> > >> > target: https://www.chromium.org/ >> > >> > = sec-token-binding:AIkAAgBBQMaFRvLPy1uUBZer64ZluK8oBJ8kpcnO84kmCX29demwilh5= 7_4gqlqRLBcZ_dh8x9KdN6TQQZWciZlGmhZp3sUAQFWhQBmwYSLGqlQ59KCOsYpn7Ex1dB_L5b= AUTdEjd98Y5CY7NY6aczxi2gC7I6xEMAC4tONGdNOjoALTLt72REUAAA >> > >> > I used the built-in chrome developer tools to examine the request = headers and obtain the above STB >> > >> > >> > [ innarestingly enuff, if one targets https://www.google.com/ = , it seems developer tools only displays the = below... >> > >> > Provisional headers are shown >> > Referer:https://www.google.com/ >> > User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) = AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 >> > ] >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Unbearable mailing list >> > Unbearable@ietf.org >> > https://www.ietf.org/mailman/listinfo/unbearable = >>=20 >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable = >>=20 >>=20 >=20 >=20 --Apple-Mail=_DEE16239-1CE9-4B98-9E77-BC245DA9E1B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes I see it.   The extension must have been filtering = out those headers.  

I can=E2=80=99t explain what Jeff is seeing.

John B.
On = Feb 15, 2017, at 8:49 PM, Nick Harper <nharper@google.com> = wrote:

I'm using the network tab of chrome's built-in = dev tools to view the headers (Ctrl+Shift+I, or kebab menu > more = tools > developer tools). As long as the flag is flipped in chrome://flags, it should be = negotiating token binding, but I don't know how that extension might be = interfering.

On Wed, Feb 15, 2017 at 3:46 PM, John Bradley = <ve7jtb@ve7jtb.com> wrote:
I tried 56.0.2924.87 = and 58.0.3013.0 OSX  and 58,0,3007 (ChromeOS) with no = luck.

It might be the extension to capture = headers that is messing me up.

What are you = using.  I used the HTTP trace extension.

John B.

On Feb 15, 2017, at 8:36 PM, Nick Harper = <nharper@google.com> wrote:

I see the sec-token-binding = header for both www.google.com and www.chromium.org from chrome on os x = (version 56.0.2924.87).

On Wed, Feb 15, 2017 at 3:29 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
Strange I see them on = both sites with Edge.

With chrome on osx and windows I am not seeing them after turning on the = flag and restarting.

I don=E2=80=99t know if the header capture is messing with it = somehow.

Google.cl negotiated TB with Edge.

John B.

> On Feb 15, 2017, at 6:12 PM, =3DJeffH <Jeff.Hodges@KingsMountain.com> = wrote:
>
> fyi/fwiw...
>
> target: https://www.chromium.org/
>
> sec-token-binding:AIkAAgBBQMaFRvLPy1uUBZer64ZluK8oBJ8kpcnO84kmCX29demwilh57_4gqlqRLBcZ_dh8x9KdN6TQQZWciZlGmhZp3sUAQFWhQBmwYSLGqlQ59KCOsYpn7Ex1dB_L5bAUTdEjd98Y5CY7NY6aczxi2gC7I6xEMAC4tONGdNOjoALTLt72REUAAA
>
> I used the built-in chrome developer tools to examine the request = headers and obtain the above STB
>
>
> [ innarestingly enuff, if one targets https://www.google.com/, it seems developer tools only = displays the below...
>
> Provisional headers are shown
> Referer:https://www.google.com/
> User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) = AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 = Safari/537.36
> ]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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





= --Apple-Mail=_DEE16239-1CE9-4B98-9E77-BC245DA9E1B6-- --Apple-Mail=_1A1E6725-F0A5-4664-B158-95F1232A5B88 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILMTCCBUcw ggQvoAMCAQICEEAfBHP+tuqufC4R+F+Tu54wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAyIENsaWVudCBDQTAeFw0xNjA4MTIy MTE5NDFaFw0xODA4MTIyMTE5NDFaMIGCMQswCQYDVQQGEwJDTDEiMCAGA1UECAwZTWV0cm9wb2xp dGFuYSBkZSBTYW50aWFnbzEWMBQGA1UEBwwNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAwwMSm9obiBC cmFkbGV5MSAwHgYJKoZIhvcNAQkBFhF2ZTdqdGJAdmU3anRiLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALhTcSiDGvVrm4hlJA8WyFcWWe0dqnuJzstQYTaF281JFOEPA/13kQYI JMXAEUcS7NvW7KdUI0tHU0N6RTo0Ilf1E1nm8No++eqHO8pFUZ/cidpv0r+1Qcl9EgrpbZ00Y7Xg pq06EZELzJAmds4QQcsTKdpLNFbVcFnM11i2Gj5VNsYgO+qPO2AS8rLHkgDWnNkc9/lA+ZK5wGiU zxPU9KnIrERoTif3Zk7KjLvFpBWYD60M/lNoHZ5zxYgmYLmvoM1TSLn4Ms57wwT5MieV2l0aqlGC 7CKNa6XyeL1B0y0wSxL3PJQS4vSLDnttZC7od2A6yjeUMyM3rQ41vqUIMc8CAwEAAaOCAcMwggG/ MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUmA9bUmBmTYkCcZ3yYv8IRRP2nN4wHwYDVR0jBBgwFoAUmZerGDU6i1lFQ5iy cnHI9PsJzxYwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNz bC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGll bnQyLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xp ZW50Mi5jcmwwHAYDVR0RBBUwE4ERdmU3anRiQHZlN2p0Yi5jb20wIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMFUGA1UdIAROMEwwDAYKKwYBBAGBtTcGATA8BgsrBgEEAYG1NwEC BTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4IBAQBqcYJfFA/ITkX4L6JihqW168Wog1BOfkbPXO+wPn5G9P1NwruGfu41b70EPPwV vol+/j+qhSSrDjFyfNBsq4G45GRR6hwx0ei/bH0UW15Y63ASYPkNlj3ydCcvhw5ItWD5aYPphBx9 C7tLnQ7ow09cqt2CIgPd3W/IGri7p4hWPbdcX0oFIhJcDxmCwTcWyoVoIo4aas5gP44LPGneCoqI lXQMJinwneEnKd7rWXlzVWv7geaH3t79zARSw9ev9F4E61cDuHi+vgTFEpio7oxybqfj99yLibhX uZjReYnYbDMRiWDXduVIrIGYwmnUuD8a0b20kJgHm+FEgB6UMa9JMIIF4jCCA8qgAwIBAgIQXLZI bkcMmMZ/9oDbZErijTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1 WhcNMzAxMjE2MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDIgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7g9Q jJUJI4Ss9VBqj9Y3ok4h/TIJZUc+rzj61Rv3hNB/yeEEC1fz3i/EU+MXOOGxM7KCbtCIcJxHIW/k 8RP6sPPMO4cTg7sNzfBWsYsemtY6fN/kVr2R2X+/PjvtxmAaXpGX0znvQPxaE123IMGXy0zEKHZ/ nJDZ199TP9TNn9v+1QO0AZb4oaJ7ch0DpSJa8kF5xiNFDAg9taKKSrVuPHJL9MFFYPIqwShjHg+u YEzjfxbMP2QWwamnaA9Y7fORSDNapduFlARAcDtXdMpAijiG4HKnrN323I0Ka7lDTAWyLtTDCETK sI8fzOyL0inEu1WEVpdPytm8s1rwQB4f9QIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQr MCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRa MFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBSZl6sYNTqLWUVDmLJy ccj0+wnPFjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUd IAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4ICAQCZQUEEzvYk9U4wNHhDu1f9QGwbzAH4m4wIKH8ZidNYwZhyoNKW041iJ002KMW9 ywYM95n4770tT45yH29vTMlZtBvz0h44KuxMLNXRCTDwvV07sT39nPjFi5MpwZaLVueNiaa1vok1 n2Wn8lLcyCltYZNGAEifM0ko/A/vvckftFIZG75RAiZHYtfnrdBGiOxyF+nHI9a33BRX5Vl/3z0+ uHZ/Y6YPbNJ7iboOFrFZBCtt+lp3WaDB62ZoBewiMmd09JrqmMJAEgw3EbfQNtaPzHPg/EOhlZik Rgd4BCrzrbIqB2RKib+gnQJt2uoJaKOaV90S9Xgs3PC837OE9CEmY6/MTTG0xpbLh2hR/rLQ3sCr H56aODeuDrQBq85lXxRbDCERDUR7FZUhHv+i1aQaY59NPu26hDd6nqksSDq2mCddpidPBuGJz9lN X2nRyGkudDuWV6gIr6AZfaYv+ggTXOcCDJZFzMhWdLC7CPvRKxQ7vTiYV+4lgqOvV9MnZc149PPt itTysq/oOv70zx7q+tyaLTa4cqFhCclhIwSwOEJiV3xqQebvmwsDX7BaXGAJZIhbdUbNr3poEgct 6uAxw2zyr69WCJmTUUhz/k1/TT/eCUZJqnMg/6mje7tiVdaUQJcBtJ6cq5+mUDNUB1fohW8EOFai zFpP/0FaP62ctTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMiBDbGllbnQgQ0ECEEAfBHP+tuqufC4R+F+Tu54wCQYFKw4DAhoF AKCCAZkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjE1MjM1 NTUwWjAjBgkqhkiG9w0BCQQxFgQUFQhNutzgeWmV2lGAKOIxNUJYnUEwgZoGCSsGAQQBgjcQBDGB jDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIg Q2xpZW50IENBAhBAHwRz/rbqrnwuEfhfk7ueMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIgQ2xpZW50IENBAhBA HwRz/rbqrnwuEfhfk7ueMA0GCSqGSIb3DQEBAQUABIIBAC9Wb/4Sjui+ekzaXEY6F8Ybif2Gonb4 EmgGZg8ba2XkMlJa6q6XYffvXDAjK9hKIF1/Ch0zvZRYDbYuGzw0xGeLHKC+mkOtIWVZLnuzbRfe TdhsCTNB9O9Zu9BFQWj3VBaD+A/WUia3TE/k9i+/eqFzAYBGyY4FXgNtIiuGiK9XNgTuO1ZTKAUG kihx0XDQRGiuZQ+5eKLbxoIbJwNEx4oywZm1JsN5ODNk9zo51HQn4bqqFsv1cXAzGssXJiMo7GDG LCppp47gAcko/qew336HlEK/ldNstSkRPpCMGXuodhDc/bmIdRju+wmMjKp60uFF9dodRgQ8RBU/ d2+ODmwAAAAAAAA= --Apple-Mail=_1A1E6725-F0A5-4664-B158-95F1232A5B88-- From nobody Wed Feb 15 15:58:52 2017 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 CCC1C129BCF for ; Wed, 15 Feb 2017 15:58:50 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2qfh2Tpkb7rJ for ; Wed, 15 Feb 2017 15:58:48 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 83E1812995F for ; Wed, 15 Feb 2017 15:58:48 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id v200so940825ywc.3 for ; Wed, 15 Feb 2017 15:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h7myN5Wv1p3XatpSJaWw2gm75xcspY4ljAmCmijZWVI=; b=j+pcUR2zelIB2xWihhG0B8+YwpX23KOR+4t3lM03WMJxLcNQR4ijhQ1UqF+KuzpfXc FqXfcxuefJb5X2QTWolfZXClRM1U0ZZz8EdANdjxnFs2+4sPxsyA2MDi7kUKvLXtQVTB F8Qjyec2Lk6DjWJFiYPA08hnQ23Jn79D+qEi7LktMC3+MHeDOk91W8FCfJn9fcNWI0Lc c5lGROfh1+IuQvBiSjiefrF2SoULIVpZlVkFnNN3tjWNxLqYLdVpewCmk45b1Hp4eWRf Jp6nY/TCFJw0lMqOdQp449Svwv98nfhtozStws/B/gGUeSg4F6VEYg2tULcOc+UQIUFf XwdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h7myN5Wv1p3XatpSJaWw2gm75xcspY4ljAmCmijZWVI=; b=tqbyEMwCvgFHqUgvpj1fArxc6bO6S5DfCbIJUoZnD0PA1UlxAgQZJ1BDDDW4/sgntb KrmFDT8r4iHh2rV0sBooGuKr1HgNFLgci7tmeipeNIXpKtuJbzQvzNgAO1RrUO2RFJk5 I9CQAQnfiP6y/n6M+q4EftdjBEHYZ6lJXgOwUBKbjlHlTFUL66dkr8/hoIlEVhkhZ+tj k4Rc9Dfy/NrGlzirAjQiUtTa7lcoFedNnxEIQK2Bw/Gwj6iBdsCAJR2H0z5QX2hYDouf puFW0WEb79w1VzGKiM/JkBs/Fxi8rq/u761doSWUW0mJrHLw2ju51UzEG+Emfl5DPIa6 fvfg== X-Gm-Message-State: AMke39mVlUIG02J9tV9LwN1cBZvrfC2Um6Y57kxc8GPBbUd+55JzAHVp9LLtQZPTzGzzixPfE4M2eIFEomGtDRSc X-Received: by 10.129.7.215 with SMTP id 206mr26858072ywh.228.1487203127632; Wed, 15 Feb 2017 15:58:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.161.87 with HTTP; Wed, 15 Feb 2017 15:58:27 -0800 (PST) In-Reply-To: References: <0d90fcf0-0ec7-448c-d0ad-0385062400b9@KingsMountain.com> <06A6B2F5-9026-4B30-A099-EB3B8F8AEFB4@ve7jtb.com> <0A2CF74F-D5FE-48EF-B9AC-0F06BA1DE1D7@ve7jtb.com> From: Nick Harper Date: Wed, 15 Feb 2017 15:58:27 -0800 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a11428b3a22263205489a76f6 Archived-At: Cc: IETF TokBind WG , =JeffH Hodges Subject: Re: [Unbearable] sec-token-binding header in the wild 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, 15 Feb 2017 23:58:51 -0000 --001a11428b3a22263205489a76f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've occasionally seen the "Provisional headers are shown" message - I think that comes up if the request is served from cache, in which case it makes sense that there's no sec-token-binding header since there was no request that went to a server. On Wed, Feb 15, 2017 at 3:55 PM, John Bradley wrote: > Yes I see it. The extension must have been filtering out those headers. > > I can=E2=80=99t explain what Jeff is seeing. > > John B. > > On Feb 15, 2017, at 8:49 PM, Nick Harper wrote: > > I'm using the network tab of chrome's built-in dev tools to view the > headers (Ctrl+Shift+I, or kebab menu > more tools > developer tools). As > long as the flag is flipped in chrome://flags, it should be negotiating > token binding, but I don't know how that extension might be interfering. > > On Wed, Feb 15, 2017 at 3:46 PM, John Bradley wrote: > >> I tried 56.0.2924.87 and 58.0.3013.0 OSX and 58,0,3007 (ChromeOS) with >> no luck. >> >> It might be the extension to capture headers that is messing me up. >> >> What are you using. I used the HTTP trace extension. >> >> John B. >> >> On Feb 15, 2017, at 8:36 PM, Nick Harper wrote: >> >> I see the sec-token-binding header for both www.google.com and >> www.chromium.org from chrome on os x (version 56.0.2924.87). >> >> On Wed, Feb 15, 2017 at 3:29 PM, John Bradley wrote: >> >>> Strange I see them on both sites with Edge. >>> >>> With chrome on osx and windows I am not seeing them after turning on th= e >>> flag and restarting. >>> >>> I don=E2=80=99t know if the header capture is messing with it somehow. >>> >>> Google.cl negotiated TB with Edge. >>> >>> John B. >>> >>> > On Feb 15, 2017, at 6:12 PM, =3DJeffH >>> wrote: >>> > >>> > fyi/fwiw... >>> > >>> > target: https://www.chromium.org/ >>> > >>> > sec-token-binding:AIkAAgBBQMaFRvLPy1uUBZer64ZluK8oBJ8kpcnO84 >>> kmCX29demwilh57_4gqlqRLBcZ_dh8x9KdN6TQQZWciZlGmhZp3sUAQFWhQB >>> mwYSLGqlQ59KCOsYpn7Ex1dB_L5bAUTdEjd98Y5CY7NY6aczxi2gC7I6xEMA >>> C4tONGdNOjoALTLt72REUAAA >>> > >>> > I used the built-in chrome developer tools to examine the request >>> headers and obtain the above STB >>> > >>> > >>> > [ innarestingly enuff, if one targets https://www.google.com/, it >>> seems developer tools only displays the below... >>> > >>> > Provisional headers are shown >>> > Referer:https://www.google.com/ >>> > User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) >>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.3= 6 >>> > ] >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 >>> >>> >> >> > > --001a11428b3a22263205489a76f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've occasionally seen the "Provisional headers a= re shown" message - I think that comes up if the request is served fro= m cache, in which case it makes sense that there's no sec-token-binding= header since there was no request that went to a server.

On Wed, Feb 15, 2017 at 3:5= 5 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Yes I see it. =C2= =A0 The extension must have been filtering out those headers. =C2=A0
I can=E2=80=99t explain what Jeff is seeing.

John B.

On Feb 15, 2017, at 8:49 PM, Nick Harper <nharper@google.com> wrote:

= I'm using the network tab of chrome's built-in dev tools to view th= e headers (Ctrl+Shift+I, or kebab menu > more tools > developer tools= ). As long as the flag is flipped in chrome://flags, it should be ne= gotiating token binding, but I don't know how that extension might be i= nterfering.

= On Wed, Feb 15, 2017 at 3:46 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I tried=C2=A056.0.2924.87 and=C2=A058.0.3013.0 OSX =C2=A0an= d 58,0,3007 (ChromeOS) with no luck.
It might be the extension to capture = headers that is messing me up.

What are you using.=C2=A0 I used the HTTP = trace extension.

= John B.

On Feb 15, 2017, at 8:36 PM, Nick Harper <nharper@google.com> wrote:
<= br class=3D"m_276333169861899505m_8181302232376487962Apple-interchange-newl= ine">
I see the sec-token-binding header for both www.google.com and www.chromium.org fr= om chrome on os x (version 56.0.2924.87).
<= br>
On Wed, Feb 15, 2017 at 3:29 PM, John Bradley= <ve7jtb@ve7jtb.com> wrote:

> On Feb 15, 2017, at 6:12 PM, =3DJeffH <Jeff.Hodges@KingsMountain.com> wrote:
>
> fyi/fwiw...
>
> target: https://www.chromium.org/
>
> sec-token-binding:AIkAAgBBQMaFRvLPy1uUBZer64ZluK8oBJ8kpcnO84= kmCX29demwilh57_4gqlqRLBcZ_dh8x9KdN6TQQZWciZlGmhZp3sUAQFWhQBmwYSL= GqlQ59KCOsYpn7Ex1dB_L5bAUTdEjd98Y5CY7NY6aczxi2gC7I6xEMAC4tONGdNOj= oALTLt72REUAAA
>
> I used the built-in chrome developer tools to examine the request head= ers and obtain the above STB
>
>
> [ innarestingly enuff, if one targets https://www.google.com/, it se= ems developer tools only displays the below...
>
> Provisional headers are shown
> Referer:https://www.google.com/
> User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit= /537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
> ]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ie= tf.org
> https://www.ietf.org/mailman/listinfo/unbe= arable


_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearabl= e




--001a11428b3a22263205489a76f6-- From nobody Wed Feb 15 16:35:28 2017 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 285DE129863 for ; Wed, 15 Feb 2017 16:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=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 GwZ69wr7t5MH for ; Wed, 15 Feb 2017 16:35:25 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 9807712953F for ; Wed, 15 Feb 2017 16:35:25 -0800 (PST) Received: (qmail 22114 invoked by uid 0); 16 Feb 2017 00:35:20 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy8.mail.unifiedlayer.com with SMTP; 16 Feb 2017 00:35:20 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id lCbG1u0142UhLwi01CbKNt; Wed, 15 Feb 2017 17:35:20 -0700 X-Authority-Analysis: v=2.1 cv=Pets2ERd 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=n2v9WMKugxEA:10 a=48vgC7mUAAAA:8 a=OhYhTfOFuhghmRSOqKoA:9 a=QEXdDO2ut3YA:10 a=b1CPlgppWbsA:10 a=lRJ6R7Cb8V8A:10 a=w1C3t2QeGrPiZgrLijVG:22 Received: from [173.224.162.69] (port=12917 helo=[10.225.80.64]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1ceA2W-0006hk-RC for unbearable@ietf.org; Wed, 15 Feb 2017 17:35:16 -0700 From: =JeffH To: IETF TokBind WG Message-ID: <2395df08-a976-7022-822d-7d3356854e33@KingsMountain.com> Date: Wed, 15 Feb 2017 16:35:15 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 173.224.162.69 X-Exim-ID: 1ceA2W-0006hk-RC X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.225.80.64]) [173.224.162.69]:12917 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 1 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: [Unbearable] TBPROTO: TTRP accordance language (was: on not listing 'Sec-Token-Binding' in the Connection header field? 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: Thu, 16 Feb 2017 00:35:27 -0000 As noted in.. on not listing 'Sec-Token-Binding' in the Connection header field? ..it seems TBPROTO (aka -tokbind-protocol) does not allow an application-layer proxy/gateway (that terminates the client-side TLS connection) to simply pass a TBMSG on to the next hop because (a) present spec language in TBPROTO S 4.2 precludes processing TBMSG if TB was not negotiated on the connection [1], and (b) S 5 precludes honoring bound tokens rec'd on a connection where their embedded TBIDs do not match the TBID established for the connection they were received over [2]. Proposed language to rectify this is below at [1] and [2]. HTH, =JeffH [1] in "4.2 Server Processing Rules": https://tools.ietf.org/html/draft-ietf-tokbind-protocol-11#section-4.2 CURRENT: If the use of the Token Binding protocol was not negotiated, but the client sends the Token Binding message, the server MUST reject any contained bindings. PROPOSED: If the server receives a Token Binding message on a connection where the use of the Token Binding protocol was not negotiated, and the server has no additional information regarding the client's role, the server MUST reject any contained bindings. However, if the server is aware (e.g., via policy) that the client's is an application-layer proxy, and the server and client have negotiated a secure connection, the server MAY process the Token Binding message, provided it also has access to the EKM and key parameters necessary to verify the signature(s) contained in the Token Binding message. Conveyance of the latter information is beyond the scope of this specification but may be detailed in other specifications. If the server's role is that of an application-layer proxy, and the Token Binding protocol was negotiated with the client, then the server MAY forward the Token Binding Message to the next hop (e.g., if stipulated by policy). It MUST do so in a secure fashion, e.g., using a secure connection, or using message-level encryption. [2] in "5. Bound Security Token Creation and Validation": https://tools.ietf.org/html/draft-ietf-tokbind-protocol-11#section-5 CURRENT: Upon receipt of a security token, the server attempts to retrieve 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 Token Binding has not been established for the client connection, the server MUST discard the token. If the Token Binding ID for the token does not match the Token Binding ID established for the client connection, the server MUST discard the token. PROPOSED: Upon receipt of a security token, the server attempts to retrieve 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 Token Binding is established for the client connection, then if the Token Binding ID in the token does not match the Token Binding ID established for the client connection, the server MUST discard the token. If the server is acting as an application-layer proxy, it MAY forward the bound token to the next hop (e.g., if stipulated by policy). It MUST do so in a secure fashion, e.g., using a secure connection, or using message-level encryption. Otherwise, if the token is bound, a Token Binding is not established for the client connection, and the server is aware (e.g., via policy) that the client is an application-layer proxy, then the server MAY process the bound token, provided it also received a valid corresponding Token Binding message from the proxy (see ). If the Token Binding ID in the token does not match the Token Binding ID from the corresponding Token Binding message, the server MUST discard the token. end From nobody Wed Feb 15 16:52:52 2017 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 540241299A8 for ; Wed, 15 Feb 2017 16:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 YTAHrlWEvJie for ; Wed, 15 Feb 2017 16:52:51 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0113.outbound.protection.outlook.com [104.47.38.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD7412999E for ; Wed, 15 Feb 2017 16:52:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pACayEmpQm6y9VpupkMKa0+PDLJGTytF0y9vOdV8t1Q=; b=ZdeTNUcgbql5h6YVqT5o78z+44HtuirBUlcM2mbaM+Kgj/KHpDmiD6YHB3Gh0W7Tm+y8vPeJd2ygICBm7V8NhWcB5haacYmW5MR6m5R3EZ2Yi7nGTTUnpqDLnp2brG5lcKuW+PakpHV4Tktx9eBXg/kaFJDH6VZzjmgNtJ6rWJ4= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 16 Feb 2017 00:52:48 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.030; Thu, 16 Feb 2017 00:52:48 +0000 From: Andrei Popov To: =JeffH , IETF TokBind WG Thread-Topic: [Unbearable] TBPROTO: TTRP accordance language (was: on not listing 'Sec-Token-Binding' in the Connection header field? Thread-Index: AQHSh+yXIxNjJj5Ne0WZK6wDfEiJhaFqywzQ Date: Thu, 16 Feb 2017 00:52:48 +0000 Message-ID: References: <2395df08-a976-7022-822d-7d3356854e33@KingsMountain.com> In-Reply-To: <2395df08-a976-7022-822d-7d3356854e33@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:a::1d2] x-ms-office365-filtering-correlation-id: dd7bbf8d-a4e5-43bf-8c06-08d4560620dc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0842; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 7:66n5zyM5hGs/J8Nh1hwv5v9WxLDXNu1uRtykvomAVCoq87+MAfewjjoSLpjkngyL1RHaTPC9AW9H/FAPJ4UsydOBF0ZOIO6vqWoqj9v6k3g3ZhdX8GJihRMYT6+SLUqMwMrejx+faQKhwilsfg4uIRYo17i5QAdvKT2sUfZxeGy1LX+pDManOO6YJZ7kUsgpM6xRazuaOFVk9v0RjctskrrMngzojuwPpd+2hHGKZc9dJNodavc4rAgUP53wMema2JjWJtqjtyEKPgZXNWN+7vOxL3QP1cS8+Pp+YKYZoZah7iXTqlx3GISctn8Op1v2pdN0qxqHa2c1Q1Y6rdNhpah2t3Ozav3uAtpiIjZ/8LU= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123558025)(20161123560025)(6072148); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39840400002)(39410400002)(39450400003)(39860400002)(199003)(189002)(10290500002)(97736004)(5005710100001)(5660300001)(10090500001)(25786008)(3660700001)(99286003)(106116001)(6436002)(55016002)(105586002)(38730400002)(102836003)(77096006)(229853002)(6116002)(6506006)(86362001)(92566002)(106356001)(7696004)(54356999)(8936002)(81156014)(33656002)(122556002)(305945005)(7736002)(8676002)(189998001)(2906002)(86612001)(81166006)(53936002)(68736007)(50986999)(6246003)(76176999)(8990500004)(3280700002)(2900100001)(74316002)(101416001)(230783001)(9686003)(389900002)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 16 Feb 2017 00:52:48.4767 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Subject: Re: [Unbearable] TBPROTO: TTRP accordance language (was: on not listing 'Sec-Token-Binding' in the Connection header field? 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: Thu, 16 Feb 2017 00:52:52 -0000 > ..it seems TBPROTO (aka -tokbind-protocol) does not allow an application-= layer proxy/gateway (that terminates the client-side TLS > connection) to simply pass a TBMSG on to the next hop because (a) present= spec language in TBPROTO S 4.2 precludes processing TBMSG if=20 > TB was not negotiated on the connection [1], and (b) S 5 precludes honori= ng bound > tokens rec'd on a connection where their embedded=20 > TBIDs do not match the TBID established for the connection they were rece= ived over [2]. TBPROTO uses the term "server" to refer to the server-side end of the conne= ction. Such "server" can be a datacenter with load balancers, TLS terminato= rs, multiple back-end application servers, etc. The details of the possible= topologies of the "servers" are out of scope for TBPROTO, and therefore TB= PROTO does not disallow any forwarding of TB messages within the "server". Tokbind-tls-term spec is probably a better place to discuss HTTP proxies an= d header forwarding. Cheers, Andrei From nobody Wed Feb 15 17:00:50 2017 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 1F264129C25 for ; Wed, 15 Feb 2017 17:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUwQXdqWmcO5 for ; Wed, 15 Feb 2017 17:00:47 -0800 (PST) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id B459C129C24 for ; Wed, 15 Feb 2017 17:00:47 -0800 (PST) Received: (qmail 4707 invoked by uid 0); 16 Feb 2017 01:00:46 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 16 Feb 2017 01:00:46 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id lD0i1u00F2UhLwi01D0l1k; Wed, 15 Feb 2017 18:00:46 -0700 X-Authority-Analysis: v=2.1 cv=H5NInYoi 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=n2v9WMKugxEA:10 a=48vgC7mUAAAA:8 a=1XWaLZrsAAAA:8 a=Mhp_Scw7AAAA:8 a=NEAV23lmAAAA:8 a=ogrqaOgoWTVBUAEURycA:9 a=QEXdDO2ut3YA:10 a=D_hx2Y1PayoA:10 a=MMBfrS4CmmgA:10 a=n1vHpN4PvAkA:10 a=y7lamN7SZnoA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=nJcEw6yWrPvoIXZ49MH8:22 a=rCfoGGe4EEIQCwLoKFZE:22 a=Bn2pgwyD2vrAyMmN8A2t:22 Received: from [173.224.162.69] (port=39912 helo=[10.225.80.64]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1ceAR8-0006pv-6i for unbearable@ietf.org; Wed, 15 Feb 2017 18:00:42 -0700 From: =JeffH To: IETF TokBind WG Message-ID: <3ade43b7-5e02-f635-b4ef-e7132387273e@KingsMountain.com> Date: Wed, 15 Feb 2017 17:00:40 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 173.224.162.69 X-Exim-ID: 1ceAR8-0006pv-6i X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.225.80.64]) [173.224.162.69]:39912 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 1 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: [Unbearable] Token Binding test server and test page? 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: Thu, 16 Feb 2017 01:00:49 -0000 In Bill Cox replied: > john bradley asked: >> Do you have any test page that would show if the cookies are >> successfully token bound ? > > I don't think we've built such a page yet. Would it be useful? Yes, please :) ..and have it show the received STB, a decoded and parsed TBMsg, and bound cookies if any. In John Bradley noted: > Currently if you are brave, there is a Python test server > as part of the Chromium project on Github for testing. > https://github.com/chromium/chromium Are there any more detailed pointers to where the said python test server resides? and does one still need to build the entire project? Any more detailed instructions for that specific item? thanks, =JeffH From nobody Wed Feb 15 17:15:39 2017 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 8862B129461 for ; Wed, 15 Feb 2017 17:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nzh27-foK_u for ; Wed, 15 Feb 2017 17:15:36 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 74CFF129444 for ; Wed, 15 Feb 2017 17:15:36 -0800 (PST) Received: (qmail 14912 invoked by uid 0); 16 Feb 2017 01:15:29 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 16 Feb 2017 01:15:29 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id lDFS1u00G2UhLwi01DFVl9; Wed, 15 Feb 2017 18:15:29 -0700 X-Authority-Analysis: v=2.1 cv=H5NInYoi 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=n2v9WMKugxEA:10 a=KXSRst2svff6QrsAAjAA:9 a=QEXdDO2ut3YA:10 Received: from [173.224.162.69] (port=62743 helo=[10.225.80.64]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1ceAfO-0007g2-Av for unbearable@ietf.org; Wed, 15 Feb 2017 18:15:26 -0700 To: IETF TokBind WG From: =JeffH Message-ID: <62a0ad87-aa67-1a78-1a47-fe7624cf7492@KingsMountain.com> Date: Wed, 15 Feb 2017 17:15:25 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 173.224.162.69 X-Exim-ID: 1ceAfO-0007g2-Av X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.225.80.64]) [173.224.162.69]:62743 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 12 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Unbearable] sec-token-binding header in the wild 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: Thu, 16 Feb 2017 01:15:37 -0000 Nick said: > I've occasionally seen the "Provisional headers are shown" message - > I think that comes up if the request is served from cache, yeah > in which case it makes sense that there's no sec-token-binding header > since there was no request that went to a server. ah. tho I'd turned caching off I'd thought... =JeffH From nobody Wed Feb 15 17:56:56 2017 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 398CC129C40 for ; Wed, 15 Feb 2017 17:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, WEIRD_PORT=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 OKtfe1DwoBl4 for ; Wed, 15 Feb 2017 17:56:52 -0800 (PST) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002: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 3B0C61293FE for ; Wed, 15 Feb 2017 17:56:52 -0800 (PST) Received: by mail-yb0-x22a.google.com with SMTP id o65so1017626ybo.2 for ; Wed, 15 Feb 2017 17:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/Uw1jzusyUysxQB9qgen+/rRDW/YcZulZPHuC8vmE3Y=; b=SiIJQn+sbblXp+LdyBQDvILO3b7aQ3sUvISAaAfsMrLxZCZtx4rZvKiAO+1IdICMBE 9ftLW0efJlbVhJKl6X/4EnE6dGdGkB4hTNEr+6aRVMmTAAvUx8piZUMPLN0HHsBUdo1N 0xsHsqacYKJ9BjydJEqLnaC1IEWWyjVMrIh8SHjA9BbnCG+836J9IKrbMD5MWj9SlX4B fHNxcnr2tRRix8jB+nXUJrcsGnk66ZqjmgR9zYqNDxHOEa5pWEeC3SrzkB11ky196+Rg gvgh7+A8VrMshMjxdFhvnw4eQxAm0SIKLZ1Q6C10+/OJM3j19bMpQ7wZtbTliidbEC+y VRFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/Uw1jzusyUysxQB9qgen+/rRDW/YcZulZPHuC8vmE3Y=; b=ThgnICCpu4DGr9tV1lIp4OOO85eNejMY6IX1viNzlJgDs6N22Le4dKv4zBt/ET0KmO FCOKp+hTmQ9VzhgiJpy5l+UuS1wKZwOXYwC39zZhiwLLdN7oxO/IxaZK4gw3nVeViFoJ NL2lXfd3R5sIb5mkuxi4Y/Yp+5Dr/O4Fbdl++TVfWJWXNFYx5KxIgElF5fryN2tmdXJ5 xO4hM63UWudnWS0yLHc7q3Li4ySFUwVB9M5l/WdU43aFIBRShOum3Bh+0byPcJ9wsnYI 8YpgbeEZAxvKLQEfMn5NXMWGwcHIJeSMJS+T61Xh9Af75oQGlOZdbjC+50HQBn0hZfrm w/aA== X-Gm-Message-State: AMke39ly16z8tyaXp7Pbd4ZeSJ/uwz3netgIRE0tD2eKvW8Z+6S81r2+hgRN7TwseO3sy5YxLqOOHbuwnbueNpoP X-Received: by 10.37.221.134 with SMTP id u128mr26691166ybg.195.1487210211268; Wed, 15 Feb 2017 17:56:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.161.87 with HTTP; Wed, 15 Feb 2017 17:56:30 -0800 (PST) In-Reply-To: <3ade43b7-5e02-f635-b4ef-e7132387273e@KingsMountain.com> References: <3ade43b7-5e02-f635-b4ef-e7132387273e@KingsMountain.com> From: Nick Harper Date: Wed, 15 Feb 2017 17:56:30 -0800 Message-ID: To: "=JeffH" Content-Type: multipart/alternative; boundary=001a114bcea459cf2c05489c1ced Archived-At: Cc: IETF TokBind WG Subject: Re: [Unbearable] Token Binding test server and test page? 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: Thu, 16 Feb 2017 01:56:54 -0000 --001a114bcea459cf2c05489c1ced Content-Type: text/plain; charset=UTF-8 On Wed, Feb 15, 2017 at 5:00 PM, =JeffH wrote: > In > Bill Cox replied: > > john bradley asked: > >> Do you have any test page that would show if the cookies are > >> successfully token bound ? > > > > I don't think we've built such a page yet. Would it be useful? > > Yes, please :) > > ..and have it show the received STB, a decoded and parsed TBMsg, and bound > cookies if any. > > > In > John Bradley noted: > > Currently if you are brave, there is a Python test server > > as part of the Chromium project on Github for testing. > > https://github.com/chromium/chromium > > Are there any more detailed pointers to where the said python test server > resides? and does one still need to build the entire project? Any more > detailed instructions for that specific item? > > The python test server is in //net/tools/testserver/testserver.py. If you run it as "python net/tools/testserver/testserver.py --https port=8443 --token-binding-params=2" and connect to https://localhost:8443/tokbind-ekm, it will return a body with content-type application/octet-stream containing the token binding ekm value. You shouldn't need to build the entire project, but you do need more than just the checkout of the chromium git repo. I think that if you follow the instructions on https://chromium. googlesource.com/chromium/src/+/master/docs/get_the_code.md for your platform through the "Get the code" step (but not "Setting up the build"), it should checkout the dependencies needed to run the python server. > > thanks, > > =JeffH > > > > > > > > > > > > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a114bcea459cf2c05489c1ced Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 15, 2017 at 5:00 PM, =3DJeffH <Jeff.Hodges@kin= gsmountain.com> wrote:
In <htt= ps://www.ietf.org/mail-archive/web/unbearable/current/msg01125.ht= ml> Bill Cox <waywardgeek at google.com> replied:
> john bradley <ve7jtb at ve7jtb.com> asked:
>> Do you have any test page that would show if the cookies are
>> successfully token bound ?
>
> I don't think we've built such a page yet.=C2=A0 Would it be u= seful?

Yes, please :)

..and have it show the received STB, a decoded and parsed TBMsg, and bound = cookies if any.


In <https://www.ietf.org/ma= il-archive/web/unbearable/current/msg00560.html> John Brad= ley noted:
> Currently if you are brave, there is a Python test server
> as part of the Chromium project on Github for testing.
> https://github.com/chromium/chromium

Are there any more detailed pointers to where the said python test server r= esides? and does one still need to build the entire project? Any more detai= led instructions for that specific item?

The python test server is in //net/tools/testserver/<= wbr>testserver.py. If you run it as "python net/tools/testserver/= testserver.py --https port=3D8443 --token-binding-params=3D2" and conn= ect to htt= ps://localhost:8443/tokbind-ekm, it will return a body with conten= t-type application/octet-stream containing the token binding ekm value. You= shouldn't need to build the entire project, but you do need more than = just the checkout of the chromium git repo. I think that if you follow the = instructions on=C2=A0https://chromium.= googlesource.com/chromium/src/+/master/docs/get_the_code.md for yo= ur platform through the "Get the code" step (but not "Settin= g up the build"), it should checkout the dependencies needed to run th= e python server.

thanks,

=3DJeffH














_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearabl= e

--001a114bcea459cf2c05489c1ced-- From nobody Thu Feb 16 11:59:55 2017 Return-Path: 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 BE7A812969F; Thu, 16 Feb 2017 11:59:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148727518977.1011.1896199241428749859.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 11:59:49 -0800 Archived-At: Cc: unbearable@ietf.org Subject: [Unbearable] I-D Action: draft-ietf-tokbind-protocol-12.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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 19:59:50 -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 : The Token Binding Protocol Version 1.0 Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Jeff Hodges Filename : draft-ietf-tokbind-protocol-12.txt Pages : 17 Date : 2017-02-16 Abstract: This document specifies Version 1.0 of the Token Binding protocol. The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS [RFC5246] bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, the Token Binding identifiers are only conveyed over TLS and can be reset by the user at any time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tokbind-protocol-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-protocol-12 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 Thu Feb 16 12:01:58 2017 Return-Path: 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 396471295EE; Thu, 16 Feb 2017 12:01:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148727531322.951.13636894466513943178.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 12:01:53 -0800 Archived-At: Cc: unbearable@ietf.org Subject: [Unbearable] I-D Action: draft-ietf-tokbind-negotiation-07.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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 20:01:57 -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 : Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Filename : draft-ietf-tokbind-negotiation-07.txt Pages : 8 Date : 2017-02-16 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-negotiation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-negotiation-07 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 Thu Feb 16 12:03:17 2017 Return-Path: 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 260111296CE; Thu, 16 Feb 2017 12:03:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148727539115.983.17759375342107449751.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 12:03:11 -0800 Archived-At: Cc: unbearable@ietf.org Subject: [Unbearable] I-D Action: draft-ietf-tokbind-https-08.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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 20:03:11 -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-08.txt Pages : 22 Date : 2017-02-16 Abstract: This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS [RFC5246] connections. We describe both _first-party_ and _federated_ scenarios. In a first-party scenario, an HTTP server is able to cryptographically bind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server. Such bound security tokens are protected from misuse since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections. Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS 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 [I-D.ietf-tokbind-protocol] 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-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-https-08 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 Thu Feb 16 12:26:54 2017 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 ACCBE1294A5 for ; Thu, 16 Feb 2017 12:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 YCyZ0BZsmbr0 for ; Thu, 16 Feb 2017 12:26:51 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0121.outbound.protection.outlook.com [104.47.32.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90E512941A for ; Thu, 16 Feb 2017 12:26:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EOCBF2Ub5LLcRQOowrciHrELROqo4c5XDavE6EkBynM=; b=mAFunbt7/wojs6SbDFV9RY9q7e7buRAWJHadUsj+jm6SXGHcLl82iveBI5tiCHmYyFoMjkrg9HnZD8i36WhJMmjtST+7rytTUCNnJ3CqH2zOlNUA0pWHK/SlLTfWv/jNXIB7Kx9Rnb09OEvgJkDtvXKOxX2PQ9iVUJ+/ZxZKjRg= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0843.namprd03.prod.outlook.com (10.160.163.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 16 Feb 2017 20:26:50 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.034; Thu, 16 Feb 2017 20:26:50 +0000 From: Andrei Popov To: IETF TokBind WG Thread-Topic: Updated I-Ds Thread-Index: AdKIki7cdjaoT3T9Qfa4KQrr2Z1KPg== Date: Thu, 16 Feb 2017 20:26:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: 1434f4ec-66c8-4380-eb03-08d456aa2360 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0843; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0843; 7:GY45kPylN5y7yWcrW214MWfyfQAK9Hp927bVuRnu295HI6YTmpeq3MIN9NY4rYydZxXZvvh/S95IoZMoLza6hS/ri299C++w/+mct7wnRkSKz8HltDZXXWzxargvLFruvO8t4FgOUZXa7AxQL2z4d8Lzxl5tagGrH2xzdJuzFUBH/BdfMAjpnd416HZMdLRzLlr5nhompk8IAV0n3PCQZ7Vdg3q/iMAlN7wmWQZXn/EjGvQWPbOz6lcOR6ysGTQzvuC18sZwYn9N6JWkrzs6DFrbDu7bBx/8OVlot9bBYN//5p6hiwnAyO43I2WgEVOZfuQPsFdG1kymnWkrMkH+z3wFo4t0Mi9kz1+nn8zL6Go= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(20161123558025)(6072148); SRVR:CY1PR0301MB0843; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0843; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39860400002)(39840400002)(39450400003)(39850400002)(39410400002)(189002)(199003)(7906003)(6506006)(77096006)(74316002)(3280700002)(2906002)(7736002)(3660700001)(25786008)(6916009)(102836003)(9686003)(54896002)(6306002)(6436002)(236005)(6116002)(7696004)(99286003)(110136004)(606005)(790700001)(55016002)(15650500001)(5005710100001)(10290500002)(2420400007)(92566002)(5660300001)(38730400002)(33656002)(10710500007)(68736007)(106356001)(53936002)(10090500001)(122556002)(450100001)(8990500004)(2900100001)(86612001)(97736004)(54356999)(101416001)(50986999)(86362001)(8676002)(7110500001)(105586002)(389900003)(81156014)(8936002)(189998001)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0843; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB08426E0DA41282E1CD733F958C5A0CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2017 20:26:50.2503 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0843 Archived-At: Subject: [Unbearable] Updated I-Ds 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: Thu, 16 Feb 2017 20:26:53 -0000 --_000_CY1PR0301MB08426E0DA41282E1CD733F958C5A0CY1PR0301MB0842_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The updated versions of TBPROTO, TBNEGO and HTTPSTB have been uploaded: https://tools.ietf.org/html/draft-ietf-tokbind-protocol-12 https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-07 https://tools.ietf.org/html/draft-ietf-tokbind-https-08 The updated documents address the comments from the unbearable mailing list= and GitHub. Cheers, Andrei --_000_CY1PR0301MB08426E0DA41282E1CD733F958C5A0CY1PR0301MB0842_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The updated versions of TBPROTO, TBNEGO and HTTPSTB = have been uploaded:

https://tools.ietf.org/html/draft-ietf-tokbind-protocol-= 12

https://tools.ietf.org/html/draft-ietf-tokbind-negoti= ation-07

https://tools.ietf.org/html/draft-ietf-tokbind-https-08=

 

The updated documents address the comments from the = unbearable mailing list and GitHub.

 

Cheers,

 

Andrei

--_000_CY1PR0301MB08426E0DA41282E1CD733F958C5A0CY1PR0301MB0842_-- From nobody Thu Feb 16 12:41:04 2017 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 E7B25129689 for ; Thu, 16 Feb 2017 12:41:02 -0800 (PST) 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, HTML_MESSAGE=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=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 MxEPi2Xzrwbb for ; Thu, 16 Feb 2017 12:41:01 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 E5905129551 for ; Thu, 16 Feb 2017 12:41:00 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id u25so27157333qki.2 for ; Thu, 16 Feb 2017 12:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gXknU6BSfdCW5tVLzy6J+4v1qxIpJYFMyavELS49odo=; b=ngxiMghZFBF0HKgEVuk89b8Fnc2KqYi4Fd2NWJj5Ipq7tVBryrEKIit758mL8bQnIR lZZF9LRBRdtkasMI3ASscs4C2mANK3Jd10GB0m37KT90w1EvtBPRGmX2qnXW0bB6aaqH MvncK2YxrE/v7HQs+xcA9v5JACFH+HhENrjHyFopnSkPFaYWVGTmpo0VEkCZWRZ18Dj8 XG23WXBl1o9e6fPEZJF22Tkx0LQ1JxEfjJgedMqj7M4FuErj3jrGzdOUga7+skvjyz6i mO4eBvY2Pktlu150MrcmMIwB9qDEH6mMcIC6IWTT5otMrBGC64LrkxRZ/sCMWDYAvkYH aoQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gXknU6BSfdCW5tVLzy6J+4v1qxIpJYFMyavELS49odo=; b=iaAti8nNPUbMVd+yMGRkSOEZgf48nhjrt4kePBjXDvMp1MEDyBNCfW9bEFZOETHDC4 M4oeayQmPPGLQ39i8HXiC3r3iQZuKVknzaGOjNXv2VtzM9ZQSuldFJfOEmx8mEuqU4Nl me0zkYA2Jg3K7KYcXT1m+W/z0OiXaR4s4ACCjfrf37bHscJtIutoRY0gJPf4FI9/55Dl UrUZUt2WZCVX05POuP1Zr8CPx6f31GxVBZAj5gz4WHbammPSWUNEaTPLiM8GK1uAAls4 WuhVOEdGayhCtamvnVm24rRmU103XI/W/XFTNDWr/YqAEbCB3noZbKuQxBiVKyj45s1Z IDPw== X-Gm-Message-State: AMke39kG1ub9wiXczFjwTd7OwJ0aEKDrGnEqDSOTX2qFFVzqRkufY7/ZEPUk3fwF1D1ogQzx X-Received: by 10.55.99.83 with SMTP id x80mr4322325qkb.185.1487277659761; Thu, 16 Feb 2017 12:40:59 -0800 (PST) Received: from [192.168.8.100] ([181.201.178.1]) by smtp.gmail.com with ESMTPSA id c82sm5091595qka.69.2017.02.16.12.40.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 12:40:58 -0800 (PST) From: John Bradley Message-Id: <2A56853E-C785-48CF-A75E-5F61683B1035@ve7jtb.com> Content-Type: multipart/signed; boundary="Apple-Mail=_BBE4594A-109D-4F45-A7F0-6BAE9445807E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 16 Feb 2017 17:40:56 -0300 In-Reply-To: To: Andrei Popov References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF TokBind WG Subject: Re: [Unbearable] Updated I-Ds 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: Thu, 16 Feb 2017 20:41:03 -0000 --Apple-Mail=_BBE4594A-109D-4F45-A7F0-6BAE9445807E Content-Type: multipart/alternative; boundary="Apple-Mail=_151BA8D2-7F6D-4CAE-A0D7-68C7B1FCAC67" --Apple-Mail=_151BA8D2-7F6D-4CAE-A0D7-68C7B1FCAC67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks. > On Feb 16, 2017, at 5:26 PM, Andrei Popov = wrote: >=20 > The updated versions of TBPROTO, TBNEGO and HTTPSTB have been = uploaded: > https://tools.ietf.org/html/draft-ietf-tokbind-protocol-12 = > https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-07 = > https://tools.ietf.org/html/draft-ietf-tokbind-https-08 = > =20 > The updated documents address the comments from the unbearable mailing = list and GitHub. > =20 > Cheers, > =20 > Andrei > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable = --Apple-Mail=_151BA8D2-7F6D-4CAE-A0D7-68C7B1FCAC67 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks.

On = Feb 16, 2017, at 5:26 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

The updated versions of = TBPROTO, TBNEGO and HTTPSTB have been uploaded:
https://tools.ietf.org/html/draft-ietf-tokbind-protocol-12<= o:p class=3D"">
https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-07
https://tools.ietf.org/html/draft-ietf-tokbind-https-08
 
The = updated documents address the comments from the unbearable mailing list = and GitHub.
 
Cheers,
 
Andrei
_______________________________________________
Unbearable mailing = list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable

= --Apple-Mail=_151BA8D2-7F6D-4CAE-A0D7-68C7B1FCAC67-- --Apple-Mail=_BBE4594A-109D-4F45-A7F0-6BAE9445807E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILMTCCBUcw ggQvoAMCAQICEEAfBHP+tuqufC4R+F+Tu54wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAyIENsaWVudCBDQTAeFw0xNjA4MTIy MTE5NDFaFw0xODA4MTIyMTE5NDFaMIGCMQswCQYDVQQGEwJDTDEiMCAGA1UECAwZTWV0cm9wb2xp dGFuYSBkZSBTYW50aWFnbzEWMBQGA1UEBwwNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAwwMSm9obiBC cmFkbGV5MSAwHgYJKoZIhvcNAQkBFhF2ZTdqdGJAdmU3anRiLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALhTcSiDGvVrm4hlJA8WyFcWWe0dqnuJzstQYTaF281JFOEPA/13kQYI JMXAEUcS7NvW7KdUI0tHU0N6RTo0Ilf1E1nm8No++eqHO8pFUZ/cidpv0r+1Qcl9EgrpbZ00Y7Xg pq06EZELzJAmds4QQcsTKdpLNFbVcFnM11i2Gj5VNsYgO+qPO2AS8rLHkgDWnNkc9/lA+ZK5wGiU zxPU9KnIrERoTif3Zk7KjLvFpBWYD60M/lNoHZ5zxYgmYLmvoM1TSLn4Ms57wwT5MieV2l0aqlGC 7CKNa6XyeL1B0y0wSxL3PJQS4vSLDnttZC7od2A6yjeUMyM3rQ41vqUIMc8CAwEAAaOCAcMwggG/ MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUmA9bUmBmTYkCcZ3yYv8IRRP2nN4wHwYDVR0jBBgwFoAUmZerGDU6i1lFQ5iy cnHI9PsJzxYwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNz bC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGll bnQyLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xp ZW50Mi5jcmwwHAYDVR0RBBUwE4ERdmU3anRiQHZlN2p0Yi5jb20wIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMFUGA1UdIAROMEwwDAYKKwYBBAGBtTcGATA8BgsrBgEEAYG1NwEC BTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4IBAQBqcYJfFA/ITkX4L6JihqW168Wog1BOfkbPXO+wPn5G9P1NwruGfu41b70EPPwV vol+/j+qhSSrDjFyfNBsq4G45GRR6hwx0ei/bH0UW15Y63ASYPkNlj3ydCcvhw5ItWD5aYPphBx9 C7tLnQ7ow09cqt2CIgPd3W/IGri7p4hWPbdcX0oFIhJcDxmCwTcWyoVoIo4aas5gP44LPGneCoqI lXQMJinwneEnKd7rWXlzVWv7geaH3t79zARSw9ev9F4E61cDuHi+vgTFEpio7oxybqfj99yLibhX uZjReYnYbDMRiWDXduVIrIGYwmnUuD8a0b20kJgHm+FEgB6UMa9JMIIF4jCCA8qgAwIBAgIQXLZI bkcMmMZ/9oDbZErijTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1 WhcNMzAxMjE2MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDIgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7g9Q jJUJI4Ss9VBqj9Y3ok4h/TIJZUc+rzj61Rv3hNB/yeEEC1fz3i/EU+MXOOGxM7KCbtCIcJxHIW/k 8RP6sPPMO4cTg7sNzfBWsYsemtY6fN/kVr2R2X+/PjvtxmAaXpGX0znvQPxaE123IMGXy0zEKHZ/ nJDZ199TP9TNn9v+1QO0AZb4oaJ7ch0DpSJa8kF5xiNFDAg9taKKSrVuPHJL9MFFYPIqwShjHg+u YEzjfxbMP2QWwamnaA9Y7fORSDNapduFlARAcDtXdMpAijiG4HKnrN323I0Ka7lDTAWyLtTDCETK sI8fzOyL0inEu1WEVpdPytm8s1rwQB4f9QIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQr MCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRa MFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBSZl6sYNTqLWUVDmLJy ccj0+wnPFjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUd IAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4ICAQCZQUEEzvYk9U4wNHhDu1f9QGwbzAH4m4wIKH8ZidNYwZhyoNKW041iJ002KMW9 ywYM95n4770tT45yH29vTMlZtBvz0h44KuxMLNXRCTDwvV07sT39nPjFi5MpwZaLVueNiaa1vok1 n2Wn8lLcyCltYZNGAEifM0ko/A/vvckftFIZG75RAiZHYtfnrdBGiOxyF+nHI9a33BRX5Vl/3z0+ uHZ/Y6YPbNJ7iboOFrFZBCtt+lp3WaDB62ZoBewiMmd09JrqmMJAEgw3EbfQNtaPzHPg/EOhlZik Rgd4BCrzrbIqB2RKib+gnQJt2uoJaKOaV90S9Xgs3PC837OE9CEmY6/MTTG0xpbLh2hR/rLQ3sCr H56aODeuDrQBq85lXxRbDCERDUR7FZUhHv+i1aQaY59NPu26hDd6nqksSDq2mCddpidPBuGJz9lN X2nRyGkudDuWV6gIr6AZfaYv+ggTXOcCDJZFzMhWdLC7CPvRKxQ7vTiYV+4lgqOvV9MnZc149PPt itTysq/oOv70zx7q+tyaLTa4cqFhCclhIwSwOEJiV3xqQebvmwsDX7BaXGAJZIhbdUbNr3poEgct 6uAxw2zyr69WCJmTUUhz/k1/TT/eCUZJqnMg/6mje7tiVdaUQJcBtJ6cq5+mUDNUB1fohW8EOFai zFpP/0FaP62ctTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMiBDbGllbnQgQ0ECEEAfBHP+tuqufC4R+F+Tu54wCQYFKw4DAhoF AKCCAZkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjE2MjA0 MDU2WjAjBgkqhkiG9w0BCQQxFgQUbwGuXTe5RFF4RU8T5A8T+oE0ihswgZoGCSsGAQQBgjcQBDGB jDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIg Q2xpZW50IENBAhBAHwRz/rbqrnwuEfhfk7ueMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIgQ2xpZW50IENBAhBA HwRz/rbqrnwuEfhfk7ueMA0GCSqGSIb3DQEBAQUABIIBAF1dwZKqlhaXnFwo1Wds4ogGWMxhowHo WmuyWVUAQnbDI/9h86dM8G0fURdoo7jxSqNU0WiMLuCVpWtdgP6F2+qN1pHqpQJQqcFEkHpG+5yC JFvKLBH4g+gdtT0dX/C7Q8pWiP14AoSVaDaj/t3eZFtQFv7DNK8/H9+Cp3HqsTpljvIbiwgsp/5O odF3hr6XobCYjn72capaYLi0aOvmRIDd7/2w8+roLQXGCh2jmUAxrG1NQgXcpotlWtfecJanG3sJ wT2JA1FhaXwCyomy/JXoE3x9/JB30dVD3ogDGvRqTgsWi4YDqvD8e6PWm7fpD8JxpX6tImbI6pE8 L9s8I38AAAAAAAA= --Apple-Mail=_BBE4594A-109D-4F45-A7F0-6BAE9445807E-- From nobody Thu Feb 16 12:54:09 2017 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 7A66F12966D for ; Thu, 16 Feb 2017 12:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 zSIem3twXZXV for ; Thu, 16 Feb 2017 12:54:04 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 044EB1296AE for ; Thu, 16 Feb 2017 12:54:04 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id F29F07803AA; Thu, 16 Feb 2017 21:54:00 +0100 (CET) To: John Bradley , Andrei Popov References: <2A56853E-C785-48CF-A75E-5F61683B1035@ve7jtb.com> From: Denis Message-ID: Date: Thu, 16 Feb 2017 21:54:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <2A56853E-C785-48CF-A75E-5F61683B1035@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------78BCA6AF9260EC3A0E3AAD49" Archived-At: Cc: IETF TokBind WG Subject: Re: [Unbearable] Updated I-Ds 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: Thu, 16 Feb 2017 20:54:07 -0000 This is a multi-part message in MIME format. --------------78BCA6AF9260EC3A0E3AAD49 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Andrei, You said: The updated documents address the comments from the unbearable mailing list. I don't believe that this is the case. I copy and paste a message sent on Wed, 21 dec 2016 at 11:16:52 under the topic: "WGLC on draft-ietf-tokbind-https". Denis ========================================================================================= On November 31, 2016, I sent a message saying: This set of documents failed to meet the terms of references of the WG charter. It is not resistant to the ABC attack (Alice and Bob collusion attack). In this attack Bob who is older than 18 colloborates with Alice and transmits a token to Alice who is only 14 so that she can demonstrat to a RS that she is older than 18. This kind of attack is not even mentionned in the security considerations section. This set of documents should not be progressed to IETF last call unless the attack can be countered. ======================================================================== There are two options: *Option A*: drop this series of documents, i.e. : draft-ietf-tokbind-protocol draft-ietf-tokbind-https draft-ietf-tokbind-negotiation or * * *Option B*: clearly mention that the ABC attack cannot be countered using TLS binding. In case, the latter decision would be taken by the WG, I propose a few text replacements. * Current text: *AbstractThis document describes a collection of mechanisms that allow HTTP servers to cryptographically bind authentication tokens (such ascookies and OAuth tokens) to TLS [RFC5246 ] connections.We describe both _first-party_ and _federated_ scenarios.In afirst-party scenario, an HTTP server is able to cryptographicallybind the security tokens it issues to a client, and which the clientsubsequently returns to the server, to the TLS connection between theclient and server.Such bound security tokens are protected frommisuse since the server can generally detect if they are replayedinappropriately, e.g., over other TLS connections.Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that theclient has with a _different_ server than the one issuing the token. This Internet-Draft is a companion document to The Token BindingProtocol [I-D.ietf-tokbind-protocol ]*Proposed additions in blue*Abstract This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind authentication tokens (such ascookies and OAuth tokens) to TLS [RFC5246 ] connections. We describe both _first-party_ and _federated_ scenarios.In afirst-party scenario, an HTTP server is able to cryptographicallybind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server.Such bound security tokens are protected from misuse since the server can generally detect if they are replayedinappropriately, e.g., over other TLS connections.*However, the binding a security token to a TLS connection is **unable to counter collaboration attacks between two clients since **one client can compute the necessary information for the other **client without the need to release his key(s) to the other client. For an effective protection against collaboration attacks, an **appropriate format of the security token, together with an **appropriate validation of some fields of it, must be used.*Federated token bindings, on the other hand, allow servers tocryptographically bind security tokens to a TLS connection that theclient has with a _different_ server than the one issuing the token. This Internet-Draft is a companion document to The Token BindingProtocol [I-D.ietf-tokbind-protocol ] *Current text: * 7.1. Security Token Replay The goal of the Federated Token Binding mechanisms is to preventattackers from exporting and replaying tokens used in protocolsbetween the client and Token Consumer, thereby impersonatinglegitimate users and gaining access to protected resources.Bound tokens can still be replayed by malware present in the client.Inorder to export the token to another machine and successfully replay it, the attacker also needs to export the corresponding private key.The Token Binding private key is therefore a high-value asset andMUST be strongly protected, ideally by generating it in a hardware security module that prevents key export *Proposed replacement* 7.1. Security Token Export andReplayThe goal of the Federated Token Binding mechanisms is to preventattackers from exporting and replaying tokens used in protocols between the client and Token Consumer, thereby impersonatinglegitimate users and gaining access to protected resources.Boundtokens can still be replayed by malware present in the client. *They can also be exported and re-used when a client collaborates **with another client.In order to export the token to another **machine and successfully use it, a client may export the **corresponding private key to the other client or may perform all **the necessary computations for the other client without exporting **the corresponding private**.Protecting the Token Binding private **key, e.g. in a hardware security module that prevents key export is **a good practice, but in such a case, it is inefficient to counter **the clients collaboration attack.* Some other changes might need to be done in the same spirit. Denis > Thanks. > > >> On Feb 16, 2017, at 5:26 PM, Andrei Popov > > wrote: >> >> The updated versions of TBPROTO, TBNEGO and HTTPSTB have been uploaded: >> https://tools.ietf.org/html/draft-ietf-tokbind-protocol-12 >> https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-07 >> https://tools.ietf.org/html/draft-ietf-tokbind-https-08 >> The updated documents address the comments from the unbearable >> mailing list and GitHub. >> Cheers, >> Andrei >> _______________________________________________ >> 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 --------------78BCA6AF9260EC3A0E3AAD49 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: base64 PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD13aW5kb3dzLTEyNTIiDQogICAgICBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiPg0KICA8 L2hlYWQ+DQogIDxib2R5IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPg0KICAg IDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+QW5kcmVpLCA8YnI+DQogICAgICA8YnI+ DQogICAgICBZb3Ugc2FpZDo8YnI+DQogICAgICA8YmxvY2txdW90ZT48Zm9udCBjb2xvcj0i IzMzMzNmZiI+VGhlIHVwZGF0ZWQgZG9jdW1lbnRzIGFkZHJlc3MNCiAgICAgICAgICB0aGUg Y29tbWVudHMgZnJvbSB0aGUgdW5iZWFyYWJsZSBtYWlsaW5nIGxpc3QuPC9mb250Pjxicj4N CiAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgIEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IHRoaXMg aXMgdGhlIGNhc2UuIEkgY29weSBhbmQgcGFzdGUgYSBtZXNzYWdlDQogICAgICBzZW50IG9u IFdlZCwgMjEgZGVjIDIwMTYgYXQgMTE6MTY6NTIgPGJyPg0KICAgICAgdW5kZXIgdGhlIHRv cGljOiAiV0dMQyBvbiBkcmFmdC1pZXRmLXRva2JpbmQtaHR0cHMiLjxicj4NCiAgICAgIDxi cj4NCiAgICAgIERlbmlzPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT08YnI+DQogICAgICA8YnI+DQogICAgICA8Zm9udCBmYWNlPSJBcmlhbCI+T24gTm92ZW1i ZXIgMzEsIDIwMTYsIEkgc2VudCBhIG1lc3NhZ2Ugc2F5aW5nOjwvZm9udD4NCiAgICAgIDxw Pjxmb250IGZhY2U9IkFyaWFsIj5UaGlzIHNldCBvZiBkb2N1bWVudHMgZmFpbGVkIHRvIG1l ZXQgdGhlDQogICAgICAgICAgdGVybXMgb2YgcmVmZXJlbmNlcyBvZiB0aGUgV0cgY2hhcnRl ci48YnI+DQogICAgICAgICAgPGJyPg0KICAgICAgICAgIEl0IGlzIG5vdCByZXNpc3RhbnQg dG8gdGhlIEFCQyBhdHRhY2sgKEFsaWNlIGFuZCBCb2IgY29sbHVzaW9uDQogICAgICAgICAg YXR0YWNrKS48YnI+DQogICAgICAgICAgSW4gdGhpcyBhdHRhY2sgQm9iIHdobyBpcyBvbGRl ciB0aGFuIDE4IGNvbGxvYm9yYXRlcyB3aXRoDQogICAgICAgICAgQWxpY2UgYW5kIHRyYW5z bWl0cyBhIHRva2VuIHRvIEFsaWNlIDxicj4NCiAgICAgICAgICB3aG8gaXMgb25seSAxNCBz byB0aGF0IHNoZSBjYW4gZGVtb25zdHJhdCB0byBhIFJTIHRoYXQgc2hlIGlzDQogICAgICAg ICAgb2xkZXIgdGhhbiAxOC48YnI+DQogICAgICAgICAgPGJyPg0KICAgICAgICAgIFRoaXMg a2luZCBvZiBhdHRhY2sgaXMgbm90IGV2ZW4gbWVudGlvbm5lZCBpbiB0aGUgc2VjdXJpdHkN CiAgICAgICAgICBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLjxicj4NCiAgICAgICAgICA8YnI+ DQogICAgICAgICAgVGhpcyBzZXQgb2YgZG9jdW1lbnRzIHNob3VsZCBub3QgYmUgcHJvZ3Jl c3NlZCB0byBJRVRGIGxhc3QNCiAgICAgICAgICBjYWxsIHVubGVzcyB0aGUgYXR0YWNrIGNh biBiZSBjb3VudGVyZWQuPGJyPg0KICAgICAgICAgIDxicj4NCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PTxicj4NCiAgICAgICAgICA8YnI+DQogICAgICAgICAgVGhlcmUgYXJlIHR3byBvcHRpb25z Ojxicj4NCiAgICAgICAgICCgPGJyPg0KICAgICAgICAgIDxiPk9wdGlvbiBBPC9iPjogZHJv cCB0aGlzIHNlcmllcyBvZiBkb2N1bWVudHMsIGkuZS4gOiA8YnI+DQogICAgICAgICAgPGJy Pg0KICAgICAgICAgIKAgZHJhZnQtaWV0Zi10b2tiaW5kLXByb3RvY29sPGJyPg0KICAgICAg ICAgIKAgZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzPGJyPg0KICAgICAgICAgIKAgZHJhZnQt aWV0Zi10b2tiaW5kLW5lZ290aWF0aW9uPGJyPg0KICAgICAgICAgIDxicj4NCiAgICAgICAg ICBvciA8Yj48YnI+DQogICAgICAgICAgPC9iPjwvZm9udD48L3A+DQogICAgICA8cD48Zm9u dCBmYWNlPSJBcmlhbCI+PGI+T3B0aW9uIEI8L2I+OiBjbGVhcmx5IG1lbnRpb24gdGhhdCB0 aGUNCiAgICAgICAgICBBQkMgYXR0YWNrIGNhbm5vdCBiZSBjb3VudGVyZWQgdXNpbmcgVExT IGJpbmRpbmcuPGJyPg0KICAgICAgICAgIDxicj4NCiAgICAgICAgICBJbiBjYXNlLCB0aGUg bGF0dGVyIGRlY2lzaW9uIHdvdWxkIGJlIHRha2VuIGJ5IHRoZSBXRywgSQ0KICAgICAgICAg IHByb3Bvc2UgYSBmZXcgdGV4dCByZXBsYWNlbWVudHMuPC9mb250PjwvcD4NCiAgICAgIDxw cmUgd3JhcD0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsNCm1zby1iaWRpLWZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNv LWFuc2ktbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLVVTIj48L3NwYW4+PGI+PGZvbnQgZmFj ZT0iQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IiBsYW5nPSJFTi1VUyI+ PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6Ni4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7DQptc28tYW5zaS1sYW5ndWFnZTpFTi1V UyIgbGFuZz0iRU4tVVMiPkN1cnJlbnQgdGV4dDo8L3NwYW4+PC9wPjwvc3Bhbj48L2ZvbnQ+ PC9iPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSItMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsiIGxhbmc9IkVOLVVTIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Ozttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPqA8bzpw PjwvbzpwPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1m b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5B YnN0cmFjdDxvOnA+PC9vOnA+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPqA8bzpwPjwvbzpwPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ow0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLVVTIj48 c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPqCgIDwvc3Bhbj4NCg0KPGZvbnQgZmFj ZT0iQXJpYWwiPiAgICAgICA8L2ZvbnQ+VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBjb2xs ZWN0aW9uIG9mIG1lY2hhbmlzbXMgdGhhdCBhbGxvdyBIVFRQDQo8bzpwPjwvbzpwPjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KbXNvLWFuc2ktbGFu Z3VhZ2U6RU4tVVMiIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5 ZXMiPqCgIDwvc3Bhbj5zZXJ2ZXJzIHRvIGNyeXB0b2dyYXBoaWNhbGx5IGJpbmQgYXV0aGVu dGljYXRpb24gdG9rZW5zIChzdWNoIGFzPG86cD48L286cD48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsNCm1zby1hbnNpLWxhbmd1YWdlOkVOLVVTIiBs YW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4NCqCgIDwvc3Bh bj5jb29raWVzIGFuZCBPQXV0aCB0b2tlbnMpIHRvIFRMUyBbPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM1MjQ2IiB0aXRsZT0iJnF1b3Q7VGhlIFRyYW5zcG9ydCBMYXllciBT ZWN1cml0eSAoVExTKSBQcm90b2NvbCBWZXJzaW9uIDEuMiZxdW90OyI+PHNwYW4gc3R5bGU9 Im1zby1hbnNpLWxhbmd1YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+UkZDNTI0Njwvc3Bhbj48 L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7DQptc28t YW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPl0gY29ubmVjdGlvbnMuPG86cD48 L286cD48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsNCm1z by1hbnNpLWxhbmd1YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+DQo8bzpwPjwvbzpwPjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KbXNvLWFuc2ktbGFu Z3VhZ2U6RU4tVVMiIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5 ZXMiPqCgIDwvc3Bhbj4NCjxmb250IGZhY2U9IkFyaWFsIj4gICAgICA8L2ZvbnQ+V2UgZGVz Y3JpYmUgYm90aCBfZmlyc3QtcGFydHlfIGFuZCBfZmVkZXJhdGVkXyBzY2VuYXJpb3MuPHNw YW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj6gIDwvc3Bhbj5JbiBhPG86cD48L286cD48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsNCm1zby1hbnNp LWxhbmd1YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1 bjogeWVzIj4NCqCgIDwvc3Bhbj5maXJzdC1wYXJ0eSBzY2VuYXJpbywgYW4gSFRUUCBzZXJ2 ZXIgaXMgYWJsZSB0byBjcnlwdG9ncmFwaGljYWxseTxvOnA+PC9vOnA+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7DQptc28tYW5zaS1sYW5ndWFnZTpF Ti1VUyIgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+DQqg oCA8L3NwYW4+YmluZCB0aGUgc2VjdXJpdHkgdG9rZW5zIGl0IGlzc3VlcyB0byBhIGNsaWVu dCwgYW5kIHdoaWNoIHRoZSBjbGllbnQ8bzpwPjwvbzpwPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiIGxh bmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPg0KoKAgPC9zcGFu PnN1YnNlcXVlbnRseSByZXR1cm5zIHRvIHRoZSBzZXJ2ZXIsIHRvIHRoZSBUTFMgY29ubmVj dGlvbiBiZXR3ZWVuIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7DQptc28tYW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4t VVMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+DQqgoCA8L3NwYW4+Y2xpZW50 IGFuZCBzZXJ2ZXIuPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj6gIDwvc3Bhbj5T dWNoIGJvdW5kIHNlY3VyaXR5IHRva2VucyBhcmUgcHJvdGVjdGVkIGZyb208bzpwPjwvbzpw Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KbXNvLWFu c2ktbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXMiPg0KoKAgPC9zcGFuPm1pc3VzZSBzaW5jZSB0aGUgc2VydmVyIGNhbiBnZW5l cmFsbHkgZGV0ZWN0IGlmIHRoZXkgYXJlIHJlcGxheWVkPG86cD48L286cD48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsNCm1zby1hbnNpLWxhbmd1YWdl OkVOLVVTIiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4N CqCgIDwvc3Bhbj5pbmFwcHJvcHJpYXRlbHksIGUuZy4sIG92ZXIgb3RoZXIgVExTIGNvbm5l Y3Rpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7DQptc28tYW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPiANCg0K PG86cD48L286cD48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJp ZGktZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OzsNCm1zby1hbnNpLWxhbmd1YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj6goCA8L3NwYW4+RmVkZXJhdGVkIHRva2VuIGJpbmRpbmdz LCBvbiB0aGUgb3RoZXIgaGFuZCwgYWxsb3cgc2VydmVycyB0bw0KPG86cD48L286cD48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsNCm1zby1hbnNpLWxh bmd1YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjog eWVzIj6goCA8L3NwYW4+Y3J5cHRvZ3JhcGhpY2FsbHkgYmluZCBzZWN1cml0eSB0b2tlbnMg dG8gYSBUTFMgY29ubmVjdGlvbiB0aGF0IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7DQptc28tYW5zaS1sYW5ndWFnZTpFTi1V UyIgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+DQqgoCA8 L3NwYW4+Y2xpZW50IGhhcyB3aXRoIGEgX2RpZmZlcmVudF8gc2VydmVyIHRoYW4gdGhlIG9u ZSBpc3N1aW5nIHRoZSB0b2tlbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7DQptc28tYW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFu Zz0iRU4tVVMiPg0KPG86cD48L286cD48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OzsNCm1zby1hbnNpLWxhbmd1YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+ PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj6goCA8L3NwYW4+VGhpcyBJbnRlcm5l dC1EcmFmdCBpcyBhIGNvbXBhbmlvbiBkb2N1bWVudCB0byBUaGUgVG9rZW4gQmluZGluZzxv OnA+PC9vOnA+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRp LWZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 DQptc28tYW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJt c28tc3BhY2VydW46IHllcyI+DQqgoCA8L3NwYW4+UHJvdG9jb2wgWzwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzLTA3I3JlZi1JLUQuaWV0 Zi10b2tiaW5kLXByb3RvY29sIj48c3BhbiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6RU4t VVMiIGxhbmc9IkVOLVVTIj5JLUQuaWV0Zi10b2tiaW5kLXByb3RvY29sPC9zcGFuPjwvYT48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsNCm1zby1hbnNp LWxhbmd1YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+XTxvOnA+PC9vOnA+PC9zcGFuPg0KDQoN CjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQtc2l6ZTox MC4wcHQ7DQpmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYW5zaS1s YW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPlByb3Bvc2VkIGFkZGl0aW9ucyA8c3BhbiBz dHlsZT0iY29sb3I6Ymx1ZSI+aW4gYmx1ZTxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsNCm1zby1hbnNpLWxhbmd1 YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+oDxvOnA+PC9vOnA+PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KDQpBYnN0cmFjdA0KPG86cD48L286cD48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+oDxvOnA+PC9v OnA+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7DQptc28t YW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tc3Bh Y2VydW46IHllcyI+oKAgPC9zcGFuPg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBj b2xsZWN0aW9uIG9mIG1lY2hhbmlzbXMgdGhhdCBhbGxvdyBIVFRQDQo8bzpwPjwvbzpwPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KbXNvLWFuc2kt bGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPqCgIDwvc3Bhbj5zZXJ2ZXJzIHRvIGNyeXB0b2dyYXBoaWNhbGx5IGJpbmQgYXV0 aGVudGljYXRpb24gdG9rZW5zIChzdWNoIGFzPG86cD48L286cD48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsNCm1zby1hbnNpLWxhbmd1YWdlOkVOLVVT IiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4NCqCgIDwv c3Bhbj5jb29raWVzIGFuZCBPQXV0aCB0b2tlbnMpIHRvIFRMUyBbPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM1MjQ2IiB0aXRsZT0iJnF1b3Q7VGhlIFRyYW5zcG9ydCBMYXll ciBTZWN1cml0eSAoVExTKSBQcm90b2NvbCBWZXJzaW9uIDEuMiZxdW90OyI+PHNwYW4gc3R5 bGU9Im1zby1hbnNpLWxhbmd1YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+UkZDNTI0Njwvc3Bh bj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7DQpt c28tYW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPl0gY29ubmVjdGlvbnMuDQo8 bzpwPjwvbzpwPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlk aS1mb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ow0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLVVTIj4NCiA8bzpwPjwvbzpw Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KbXNvLWFu c2ktbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXMiPqAgPC9zcGFuPldlIGRlc2NyaWJlIGJvdGggX2ZpcnN0LXBhcnR5XyBhbmQg X2ZlZGVyYXRlZF8gc2NlbmFyaW9zLjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+ oCA8L3NwYW4+SW4gYTxvOnA+PC9vOnA+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7DQptc28tYW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMi PjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+DQqgoCA8L3NwYW4+Zmlyc3QtcGFy dHkgc2NlbmFyaW8sIGFuIEhUVFAgc2VydmVyIGlzIGFibGUgdG8gY3J5cHRvZ3JhcGhpY2Fs bHk8bzpwPjwvbzpwPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28t YmlkaS1mb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ow0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLVVTIj48c3BhbiBzdHls ZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPg0KoKAgPC9zcGFuPmJpbmQgdGhlIHNlY3VyaXR5IHRv a2VucyBpdCBpc3N1ZXMgdG8gYSBjbGllbnQsIGFuZCB3aGljaCB0aGUgY2xpZW50DQo8bzpw PjwvbzpwPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1m b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0K bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNv LXNwYWNlcnVuOiB5ZXMiPqCgIDwvc3Bhbj5zdWJzZXF1ZW50bHkgcmV0dXJucyB0byB0aGUg c2VydmVyLCB0byB0aGUgVExTIGNvbm5lY3Rpb24gYmV0d2VlbiB0aGUNCjxvOnA+PC9vOnA+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7DQptc28tYW5z aS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2Vy dW46IHllcyI+oKAgPC9zcGFuPmNsaWVudCBhbmQgc2VydmVyLjxzcGFuIHN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+oCA8L3NwYW4+U3VjaCBib3VuZCBzZWN1cml0eSB0b2tlbnMgYXJl IHByb3RlY3RlZCBmcm9tDQo8bzpwPjwvbzpwPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVO LVVTIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPqCgIDwvc3Bhbj5taXN1c2Ug c2luY2UgdGhlIHNlcnZlciBjYW4gZ2VuZXJhbGx5IGRldGVjdCBpZiB0aGV5IGFyZSByZXBs YXllZDxvOnA+PC9vOnA+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21z by1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7DQptc28tYW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjxzcGFuIHN0 eWxlPSJtc28tc3BhY2VydW46IHllcyI+DQqgoCA8L3NwYW4+aW5hcHByb3ByaWF0ZWx5LCBl LmcuLCBvdmVyIG90aGVyIFRMUyBjb25uZWN0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KbXNvLWFuc2ktbGFuZ3VhZ2U6 RU4tVVMiIGxhbmc9IkVOLVVTIj4gDQo8bzpwPjwvbzpwPjwvc3Bhbj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KY29sb3I6Ymx1ZTttc28tYW5zaS1sYW5n dWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHll cyI+DQqgoCA8L3NwYW4+SG93ZXZlciwgdGhlIGJpbmRpbmcgYSBzZWN1cml0eSB0b2tlbiB0 byBhIFRMUyBjb25uZWN0aW9uIGlzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsNCmNvbG9yOmJsdWU7bXNvLWFuc2kt bGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPqCgoDwvc3Bhbj51bmFibGUgdG8gY291bnRlciBjb2xsYWJvcmF0aW9uIGF0dGFj a3MgYmV0d2VlbiB0d28gY2xpZW50cyBzaW5jZQ0KPG86cD48L286cD48L3NwYW4+PC9iPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7DQpjb2xvcjpibHVlO21z by1hbnNpLWxhbmd1YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1z cGFjZXJ1bjogeWVzIj6goKA8L3NwYW4+b25lIGNsaWVudCBjYW4gY29tcHV0ZSB0aGUgbmVj ZXNzYXJ5IGluZm9ybWF0aW9uIGZvciB0aGUgb3RoZXINCjxvOnA+PC9vOnA+PC9zcGFuPjwv Yj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KY29sb3I6Ymx1 ZTttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJt c28tc3BhY2VydW46IHllcyI+oKCgPC9zcGFuPmNsaWVudCB3aXRob3V0IHRoZSBuZWVkIHRv IHJlbGVhc2UgaGlzIGtleShzKSB0byB0aGUgb3RoZXIgY2xpZW50Lg0KDQo8c3BhbiBzdHls ZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPqCgIDwvc3Bhbj5Gb3IgYW4gZWZmZWN0aXZlIHByb3Rl Y3Rpb24gYWdhaW5zdCBjb2xsYWJvcmF0aW9uIGF0dGFja3MsIGFuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsNCmNv bG9yOmJsdWU7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLVVTIj48c3BhbiBz dHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPqCgoDwvc3Bhbj5hcHByb3ByaWF0ZSBmb3JtYXQg b2YgdGhlIHNlY3VyaXR5IHRva2VuLCB0b2dldGhlciB3aXRoIGFuDQo8Zm9udCBmYWNlPSJB cmlhbCI+ICA8L2ZvbnQ+PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ow0KY29sb3I6Ymx1ZTttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFu Zz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+oCA8L3NwYW4+YXBw cm9wcmlhdGUgdmFsaWRhdGlvbiBvZiBzb21lIGZpZWxkcyBvZiBpdCwgbXVzdCBiZSB1c2Vk LjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtt c28tYmlkaS1mb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ow0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLVVTIj4gDQoNCjxv OnA+PC9vOnA+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRp LWZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 DQptc28tYW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJt c28tc3BhY2VydW46IHllcyI+oKAgPC9zcGFuPkZlZGVyYXRlZCB0b2tlbiBiaW5kaW5ncywg b24gdGhlIG90aGVyIGhhbmQsIGFsbG93IHNlcnZlcnMgdG88bzpwPjwvbzpwPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KbXNvLWFuc2ktbGFuZ3Vh Z2U6RU4tVVMiIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi Pg0KoKAgPC9zcGFuPmNyeXB0b2dyYXBoaWNhbGx5IGJpbmQgc2VjdXJpdHkgdG9rZW5zIHRv IGEgVExTIGNvbm5lY3Rpb24gdGhhdCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMi IGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPg0KoKAgPC9z cGFuPmNsaWVudCBoYXMgd2l0aCBhIF9kaWZmZXJlbnRfIHNlcnZlciB0aGFuIHRoZSBvbmUg aXNzdWluZyB0aGUgdG9rZW4uDQo8bzpwPjwvbzpwPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9 IkVOLVVTIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7DQptc28tYW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjxz cGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+oKAgPC9zcGFuPlRoaXMgSW50ZXJuZXQt RHJhZnQgaXMgYSBjb21wYW5pb24gZG9jdW1lbnQgdG8gVGhlIFRva2VuIEJpbmRpbmc8bzpw PjwvbzpwPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1m b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0K bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNv LXNwYWNlcnVuOiB5ZXMiPiANCjxmb250IGZhY2U9IkFyaWFsIj4gPC9mb250PiCgPC9zcGFu PlByb3RvY29sIFs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJp ZGktZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9r YmluZC1odHRwcy0wNyNyZWYtSS1ELmlldGYtdG9rYmluZC1wcm90b2NvbCI+PHNwYW4gc3R5 bGU9Im1zby1hbnNpLWxhbmd1YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+SS1ELmlldGYtdG9r YmluZC1wcm90b2NvbDwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7DQptc28tYW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMi Pl08bzpwPjwvbzpwPjwvc3Bhbj4NCg0KDQo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkFy aWFsIiBzaXplPSItMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsiIGxhbmc9IkVO LVVTIj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXRvcDo2LjBwdCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsNCm1zby1hbnNpLWxhbmd1 YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+Q3VycmVudCB0ZXh0OiA8L3NwYW4+PC9iPjxmb250 IGZhY2U9IkFyaWFsIiBzaXplPSItMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsi IGxhbmc9IkVOLVVTIj48L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIt MSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsiIGxhbmc9IkVOLVVTIj4NCjwvc3Bh bj48L2ZvbnQ+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tdG9wOjYu MHB0Ij48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iLTEiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IiBsYW5nPSJFTi1VUyI+Ny4xLiBTZWN1cml0eSBUb2tlbiBSZXBsYXk8L3Nw YW4+PC9mb250Pjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSItMSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsiIGxhbmc9IkVOLVVTIj48L3NwYW4+PC9mb250Pg0KPC9wPjwvc3Bh bj48L2ZvbnQ+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9Ii0xIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyIgbGFuZz0iRU4tVVMiPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tdG9wOjYuMHB0Ij48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iLTEiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IiBsYW5nPSJFTi1VUyI+PC9zcGFuPjwvZm9udD48 L3A+PGgzIHN0eWxlPSJ0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQg MjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhw dCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiPjxmb250IGZhY2U9 IkFyaWFsIiBzaXplPSItMSI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9Ii0xIj48Zm9udCBm YWNlPSJBcmlhbCIgc2l6ZT0iLTEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21z by1iaWRpLWZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7DQptc28tYW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjwvc3Bhbj48 Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iLTEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IiBsYW5nPSJFTi1VUyI+PC9zcGFuPjwvZm9udD48L2ZvbnQ+PC9mb250PjwvZm9udD48 L2gzPjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9Ii0xIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyIgbGFuZz0iRU4tVVMiPjwvc3Bhbj48L2ZvbnQ+PHBy ZSB3cmFwPSIiPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSItMSI+PGZvbnQgZmFjZT0iQXJp YWwiIHNpemU9Ii0xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyIgbGFuZz0iRU4t VVMiPjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9Ii0xIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyIgbGFuZz0iRU4tVVMiPjwvc3Bhbj48L2ZvbnQ+PC9m b250PjwvcHJlPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSItMSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsiIGxhbmc9IkVOLVVTIj48L3NwYW4+PC9mb250Pjxmb250IGZhY2U9 IkFyaWFsIiBzaXplPSItMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsiIGxhbmc9 IkVOLVVTIj48L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSItMSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsiIGxhbmc9IkVOLVVTIj48aDMgc3R5bGU9InRh Yi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQg MzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRw dCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9Ii0x Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyIgbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L2gzPjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQXJpYWwi IHNpemU9Ii0xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyIgbGFuZz0iRU4tVVMi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4w cHQ7DQpmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tYW5zaS1sYW5n dWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHll cyI+oKAgPC9zcGFuPlRoZSBnb2FsIG9mIHRoZSBGZWRlcmF0ZWQgVG9rZW4gQmluZGluZyBt ZWNoYW5pc21zIGlzIHRvIHByZXZlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiIGxh bmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPg0KoKAgPC9zcGFu PmF0dGFja2VycyBmcm9tIGV4cG9ydGluZyBhbmQgcmVwbGF5aW5nIHRva2VucyB1c2VkIGlu IHByb3RvY29sczxvOnA+PC9vOnA+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7DQptc28tYW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjxz cGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+IA0KIKAgPC9zcGFuPmJldHdlZW4gdGhl IGNsaWVudCBhbmQgVG9rZW4gQ29uc3VtZXIsIHRoZXJlYnkgaW1wZXJzb25hdGluZzxvOnA+ PC9vOnA+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7DQpt c28tYW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28t c3BhY2VydW46IHllcyI+DQqgoCA8L3NwYW4+bGVnaXRpbWF0ZSB1c2VycyBhbmQgZ2Fpbmlu ZyBhY2Nlc3MgdG8gcHJvdGVjdGVkIHJlc291cmNlcy48c3BhbiBzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXMiPqAgPC9zcGFuPkJvdW5kDQo8bzpwPjwvbzpwPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMi IGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPqCgIDwvc3Bh bj50b2tlbnMgY2FuIHN0aWxsIGJlIHJlcGxheWVkIGJ5IG1hbHdhcmUgcHJlc2VudCBpbiB0 aGUgY2xpZW50LjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+oCA8L3NwYW4+PGZv bnQgY29sb3I9IiM2NjY2NjYiPkluPG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjxmb250IGNv bG9yPSIjNjY2NjY2Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1m b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0K bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNv LXNwYWNlcnVuOiB5ZXMiPg0KoKAgPC9zcGFuPm9yZGVyIHRvIGV4cG9ydCB0aGUgdG9rZW4g dG8gYW5vdGhlciBtYWNoaW5lIGFuZCBzdWNjZXNzZnVsbHkgcmVwbGF5DQo8bzpwPjwvbzpw Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KbXNvLWFu c2ktbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXMiPqCgIDwvc3Bhbj5pdCwgdGhlIGF0dGFja2VyIGFsc28gbmVlZHMgdG8gZXhw b3J0IHRoZSBjb3JyZXNwb25kaW5nIHByaXZhdGUga2V5LjxvOnA+PC9vOnA+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7DQptc28tYW5zaS1sYW5ndWFn ZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+ DQqgoCA8L3NwYW4+VGhlIFRva2VuIEJpbmRpbmcgcHJpdmF0ZSBrZXkgaXMgdGhlcmVmb3Jl IGEgaGlnaC12YWx1ZSBhc3NldCBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiIGxh bmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPg0KoKAgPC9zcGFu Pk1VU1QgYmUgc3Ryb25nbHkgcHJvdGVjdGVkLCBpZGVhbGx5IGJ5IGdlbmVyYXRpbmcgaXQg aW4gYSBoYXJkd2FyZQ0KPC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjxmb250IGZhY2U9 IkFyaWFsIiBjb2xvcj0iIzY2NjY2NiIgc2l6ZT0iLTEiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 bXNvLWJpZGktZm9udC1zaXplOg0KMTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+ICAgc2Vj dXJpdHkgbW9kdWxlIHRoYXQgcHJldmVudHMga2V5IGV4cG9ydDwvc3Bhbj48L3NwYW4+PC9m b250Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij4NCjwvZm9udD48Zm9udCBmYWNlPSJBcmlhbCIg c2l6ZT0iLTEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IiBsYW5nPSJFTi1VUyI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXRvcDo2LjBwdCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsNCm1zby1hbnNpLWxhbmd1YWdl OkVOLVVTIiBsYW5nPSJFTi1VUyI+UHJvcG9zZWQgcmVwbGFjZW1lbnQ8bzpwPjwvbzpwPjwv c3Bhbj48L2I+PC9wPjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9Ii0x Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyIgbGFuZz0iRU4tVVMiPjxmb250IGZh Y2U9IkFyaWFsIiBzaXplPSItMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsiIGxh bmc9IkVOLVVTIj48aDMgc3R5bGU9InRhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQg MTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBw dCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEzLjVwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1odHRwcy0wNyNzZWN0aW9u LTcuMSI+PHNwYW4gc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOkVOLVVTIiBsYW5nPSJFTi1V UyI+PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNv LWJpZGktZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OzsNCm1zby1hbnNpLWxhbmd1YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5 bGU9Im1zby1zcGFjZXJ1bjogeWVzIj48L3NwYW4+Ny4xLiBTZWN1cml0eSBUb2tlbiA8c3Bh biBzdHlsZT0iY29sb3I6Ymx1ZSI+RXhwb3J0IGFuZDwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEzLjVwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsNCm1zby1hbnNpLWxhbmd1YWdlOkVOLVVT IiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0iQXJpYWwiPiA8L2ZvbnQ+UmVwbGF5PC9zcGFu Pjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSItMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsiIGxhbmc9IkVOLVVTIj4NCg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 bXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+PHNwYW4g c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj6goCA8L3NwYW4+VGhlIGdvYWwgb2YgdGhlIEZl ZGVyYXRlZCBUb2tlbiBCaW5kaW5nIG1lY2hhbmlzbXMgaXMgdG8gcHJldmVudDxvOnA+PC9v OnA+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7DQptc28t YW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tc3Bh Y2VydW46IHllcyI+DQqgoCA8L3NwYW4+YXR0YWNrZXJzIGZyb20gZXhwb3J0aW5nIGFuZCBy ZXBsYXlpbmcgdG9rZW5zIHVzZWQgaW4gcHJvdG9jb2xzDQo8bzpwPjwvbzpwPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KbXNvLWFuc2ktbGFuZ3Vh Z2U6RU4tVVMiIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi PqCgIDwvc3Bhbj5iZXR3ZWVuIHRoZSBjbGllbnQgYW5kIFRva2VuIENvbnN1bWVyLCB0aGVy ZWJ5IGltcGVyc29uYXRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVO LVVTIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPg0KoKAgPC9zcGFuPmxlZ2l0 aW1hdGUgdXNlcnMgYW5kIGdhaW5pbmcgYWNjZXNzIHRvIHByb3RlY3RlZCByZXNvdXJjZXMu PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj6gIDwvc3Bhbj5Cb3VuZDxvOnA+PC9v OnA+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7DQptc28t YW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tc3Bh Y2VydW46IHllcyI+DQqgoCA8L3NwYW4+dG9rZW5zIGNhbiBzdGlsbCBiZSByZXBsYXllZCBi eSBtYWx3YXJlIHByZXNlbnQgaW4gdGhlIGNsaWVudC48c3BhbiBzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXMiPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvZm9udD48L2gzPjwvc3Bhbj48L2Zv bnQ+PC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iLTEiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IiBsYW5nPSJFTi1VUyI+PGgzIHN0eWxlPSJ0YWItc3Rv cHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42 cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQx LjJwdCA2ODcuMHB0IDczMi44cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21z by1iaWRpLWZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7DQptc28tYW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvaDM+PC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0i LTEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IiBsYW5nPSJFTi1VUyI+PGZvbnQg ZmFjZT0iQXJpYWwiIHNpemU9Ii0xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyIg bGFuZz0iRU4tVVMiPjxoMyBzdHlsZT0idGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQgMTM3LjRw dCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTgu MHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Ij48 Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iLTEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1zcGFj ZXJ1bjogeWVzIj4gIDwvc3Bhbj48L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgY29sb3I6IGJsdWU7IiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1zcGFj ZXJ1bjogeWVzIj4gPC9zcGFuPlRoZXkgY2FuIGFsc28gYmUgZXhwb3J0ZWQgYW5kIHJlLXVz ZWQgd2hlbiBhIGNsaWVudCBjb2xsYWJvcmF0ZXMNCiA8L3NwYW4+PC9iPjwvZm9udD48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KY29sb3I6Ymx1ZTttc28t YW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IkNvdXJpZXIg TmV3Ij48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPqAgPC9zcGFuPndpdDwvZm9u dD5oIGFub3RoZXIgY2xpZW50LjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+oCA8 L3NwYW4+SW4gb3JkZXIgdG8gZXhwb3J0IHRoZSB0b2tlbiB0byBhbm90aGVyDQogPC9zcGFu PjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KY29sb3I6 Ymx1ZTttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxl PSJtc28tc3BhY2VydW46IHllcyI+oCA8L3NwYW4+bWFjaGluZSBhbmQgc3VjY2Vzc2Z1bGx5 IHVzZSBpdCwgYSBjbGllbnQgbWF5IGV4cG9ydCB0aGUgPG86cD48L286cD48L3NwYW4+PC9i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7DQpjb2xvcjpibHVl O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1z by1zcGFjZXJ1bjogeWVzIj4NCqCgIDwvc3Bhbj5jb3JyZXNwb25kaW5nIHByaXZhdGUga2V5 IHRvIHRoZSBvdGhlciBjbGllbnQgb3IgbWF5IHBlcmZvcm0gYWxsIA0KPG86cD48L286cD48 L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O21zby1iaWRpLWZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7DQpj b2xvcjpibHVlO21zby1hbnNpLWxhbmd1YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+PHNwYW4g c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj6goKA8L3NwYW4+dGhlIG5lY2Vzc2FyeSBjb21w dXRhdGlvbnMgZm9yIHRoZSBvdGhlciBjbGllbnQgd2l0aG91dCBleHBvcnRpbmcgDQo8bzpw PjwvbzpwPjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bXNv LWJpZGktZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OzsNCmNvbG9yOmJsdWU7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLVVT Ij48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPqCgoDwvc3Bhbj50aGUgY29ycmVz cG9uZGluZyBwcml2YXRlPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ow0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLVVTIj4u PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHll cyI+oCA8L3NwYW4+UHJvdGVjdGluZyB0aGUgVG9rZW4gQmluZGluZyBwcml2YXRlIDxvOnA+ PC9vOnA+PC9zcGFuPjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7bXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OzsNCmNvbG9yOmJsdWU7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9 IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPg0KoKAgPC9zcGFuPmtl eSwgZS5nLiBpbiBhIGhhcmR3YXJlIHNlY3VyaXR5IG1vZHVsZSB0aGF0IHByZXZlbnRzIGtl eSBleHBvcnQgaXMgPG86cD48L286cD48L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7DQpjb2xvcjpibHVlO21zby1hbnNpLWxhbmd1YWdlOkVO LVVTIiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4NCqCg IDwvc3Bhbj5hIGdvb2QgcHJhY3RpY2UsIGJ1dCBpbiBzdWNoIGEgY2FzZSwgaXQgaXMgaW5l ZmZpY2llbnQgdG8gY291bnRlciANCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYmlkaS1mb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ow0KY29sb3I6Ymx1ZTttc28tYW5zaS1s YW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46 IHllcyI+oKCgPC9zcGFuPnRoZSBjbGllbnRzIGNvbGxhYm9yYXRpb24gYXR0YWNrLjxvOnA+ PC9vOnA+PC9zcGFuPjwvYj4gPC9zcGFuPjwvZm9udD48L2gzPjwvc3Bhbj48L2ZvbnQ+PC9z cGFuPjwvZm9udD48L3ByZT4NCiAgICAgIDxmb250IGZhY2U9IkFyaWFsIiBzaXplPSItMSI+ IDwvZm9udD4NCiAgICAgIDxwcmUgd3JhcD0iIj48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0i LTEiPlNvbWUgb3RoZXIgY2hhbmdlcyBtaWdodCBuZWVkIHRvIGJlIGRvbmUgaW4gdGhlIHNh bWUgc3Bpcml0Lg0KDQpEZW5pczwvZm9udD4NCjwvcHJlPg0KICAgICAgPGJyPg0KICAgIDwv ZGl2Pg0KICAgIDxibG9ja3F1b3RlDQogICAgICBjaXRlPSJtaWQ6MkE1Njg1M0UtQzc4NS00 OENGLUE3NUUtNUY2MTY4M0IxMDM1QHZlN2p0Yi5jb20iDQogICAgICB0eXBlPSJjaXRlIj4N CiAgICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9o dG1sOw0KICAgICAgICBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+DQogICAgICBUaGFua3MuDQog ICAgICA8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCiAgICAgIDwvZGl2Pg0KICAgICAg PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQogICAgICAgIDxkaXY+DQogICAgICAgICAg PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQogICAgICAgICAgICA8ZGl2IGNs YXNzPSIiPk9uIEZlYiAxNiwgMjAxNywgYXQgNToyNiBQTSwgQW5kcmVpIFBvcG92ICZsdDs8 YQ0KICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAg ICAgICBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20iIGNsYXNzPSIi PkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZndDsNCiAgICAgICAgICAgICAgd3Jv dGU6PC9kaXY+DQogICAgICAgICAgICA8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5l d2xpbmUiPg0KICAgICAgICAgICAgPGRpdiBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOw0KICAg ICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZToNCiAgICAgICAgICAgICAgICBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7DQogICAgICAgICAgICAgICAgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjoNCiAgICAgICAg ICAgICAgICBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 DQogICAgICAgICAgICAgICAgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsNCiAgICAgICAgICAgICAgICAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7Ij4NCiAgICAgICAgICAgICAgICA8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsNCiAgICAgICAgICAgICAgICAgIGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+VGhlDQogICAgICAg ICAgICAgICAgICB1cGRhdGVkIHZlcnNpb25zIG9mIFRCUFJPVE8sIFRCTkVHTyBhbmQgSFRU UFNUQiBoYXZlDQogICAgICAgICAgICAgICAgICBiZWVuIHVwbG9hZGVkOjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQogICAgICAgICAgICAgICAgPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7DQogICAgICAgICAgICAgICAgICBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxhDQogICAgICAg ICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICAg ICAgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmlu ZC1wcm90b2NvbC0xMiINCiAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImNvbG9yOiByZ2Io MTQ5LCA3OSwgMTE0KTsgdGV4dC1kZWNvcmF0aW9uOg0KICAgICAgICAgICAgICAgICAgICB1 bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi10b2tiaW5kLXByb3RvY29sLTEyPC9hPjxvOnANCiAgICAgICAgICAgICAgICAgICAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQogICAgICAgICAgICAgICAgPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7DQogICAgICAgICAgICAg ICAgICBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxhDQog ICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAg ICAgICAgICAgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt dG9rYmluZC1uZWdvdGlhdGlvbi0wNyINCiAgICAgICAgICAgICAgICAgICAgc3R5bGU9ImNv bG9yOiByZ2IoMTQ5LCA3OSwgMTE0KTsgdGV4dC1kZWNvcmF0aW9uOg0KICAgICAgICAgICAg ICAgICAgICB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi10b2tiaW5kLW5lZ290aWF0aW9uLTA3PC9hPjxvOnANCiAgICAgICAg ICAgICAgICAgICAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQogICAgICAgICAgICAgICAgPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7DQog ICAgICAgICAgICAgICAgICBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPjxhDQogICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIN CiAgICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtdG9rYmluZC1odHRwcy0wOCINCiAgICAgICAgICAgICAgICAgICAgc3R5 bGU9ImNvbG9yOiByZ2IoMTQ5LCA3OSwgMTE0KTsgdGV4dC1kZWNvcmF0aW9uOg0KICAgICAg ICAgICAgICAgICAgICB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzLTA4PC9hPjxvOnANCiAgICAgICAg ICAgICAgICAgICAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQogICAgICAgICAgICAgICAgPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7DQog ICAgICAgICAgICAgICAgICBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPjxvOnANCiAgICAgICAgICAgICAgICAgICAgY2xhc3M9IiI+oDwvbzpwPjwvZGl2 Pg0KICAgICAgICAgICAgICAgIDxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMXB0Ow0KICAgICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5UaGUNCiAgICAgICAgICAgICAgICAgIHVw ZGF0ZWQgZG9jdW1lbnRzIGFkZHJlc3MgdGhlIGNvbW1lbnRzIGZyb20gdGhlDQogICAgICAg ICAgICAgICAgICB1bmJlYXJhYmxlIG1haWxpbmcgbGlzdCBhbmQgR2l0SHViLjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQogICAgICAgICAgICAgICAgPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7DQogICAgICAgICAgICAgICAg ICBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxvOnANCiAg ICAgICAgICAgICAgICAgICAgY2xhc3M9IiI+oDwvbzpwPjwvZGl2Pg0KICAgICAgICAgICAg ICAgIDxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MXB0Ow0KICAgICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj5DaGVlcnMsPG86cA0KICAgICAgICAgICAgICAgICAgICBjbGFzcz0i Ij48L286cD48L2Rpdj4NCiAgICAgICAgICAgICAgICA8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsNCiAgICAgICAgICAgICAgICAgIGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PG86cA0KICAgICAg ICAgICAgICAgICAgICBjbGFzcz0iIj6gPC9vOnA+PC9kaXY+DQogICAgICAgICAgICAgICAg PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7 DQogICAgICAgICAgICAgICAgICBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPkFuZHJlaTxvOnANCiAgICAgICAgICAgICAgICAgICAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQogICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICA8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4Ow0KICAgICAg ICAgICAgICAgIGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsNCiAgICAgICAgICAgICAgICBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyBvcnBoYW5zOg0KICAgICAgICAgICAgICAgIGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4Ow0KICAgICAgICAgICAgICAgIHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87DQogICAgICAg ICAgICAgICAgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsNCiAgICAgICAgICAgICAgICBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFp bXBvcnRhbnQ7IiBjbGFzcz0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzwvc3Bhbj48YnINCiAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4Ow0KICAgICAgICAgICAgICAgIGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsNCiAgICAgICAg ICAgICAgICBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOg0KICAgICAgICAgICAgICAgIGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4Ow0KICAgICAgICAgICAgICAgIHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87DQogICAgICAgICAgICAgICAgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiDQogICAg ICAgICAgICAgICAgY2xhc3M9IiI+DQogICAgICAgICAgICAgIDxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7DQogICAgICAgICAgICAgICAg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOw0KICAgICAg ICAgICAgICAgIGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IG9ycGhhbnM6DQogICAgICAgICAgICAgICAgYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7DQogICAgICAgICAgICAgICAgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsNCiAgICAgICAgICAgICAgICB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4Ow0KICAg ICAgICAgICAgICAgIGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsi IGNsYXNzPSIiPlVuYmVhcmFibGUNCiAgICAgICAgICAgICAgICBtYWlsaW5nIGxpc3Q8L3Nw YW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOw0KICAgICAgICAgICAgICAg IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czoNCiAgICAgICAgICAgICAgICBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7DQogICAgICAgICAgICAgICAgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7DQogICAgICAgICAgICAgICAgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsN CiAgICAgICAgICAgICAgICB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyINCiAgICAgICAgICAgICAgICBjbGFzcz0iIj4NCiAgICAgICAgICAg ICAgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAgICAgICAgICAgICAgIGhyZWY9Im1h aWx0bzpVbmJlYXJhYmxlQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHJnYigxNDksDQogICAg ICAgICAgICAgICAgNzksIDExNCk7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBmb250 LWZhbWlseToNCiAgICAgICAgICAgICAgICBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOw0KICAgICAgICAgICAgICAgIGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7DQogICAgICAgICAgICAgICAgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjoNCiAgICAgICAg ICAgICAgICBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 DQogICAgICAgICAgICAgICAgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsNCiAgICAgICAgICAgICAgICAtd2Via2l0LXRleHQtc2l6ZS1h ZGp1c3Q6IGF1dG87DQogICAgICAgICAgICAgICAgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyIgY2xhc3M9IiI+VW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnINCiAgICAgICAg ICAgICAgICBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 Ow0KICAgICAgICAgICAgICAgIGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOg0KICAgICAgICAgICAgICAgIGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4Ow0KICAgICAgICAgICAgICAgIHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 DQogICAgICAgICAgICAgICAgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiDQogICAgICAgICAgICAgICAgY2xhc3M9IiI+DQogICAgICAgICAg ICAgIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSINCiAgICAgICAgICAgICAgICBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUiDQogICAg ICAgICAgICAgICAgc3R5bGU9ImNvbG9yOiByZ2IoMTQ5LCA3OSwgMTE0KTsgdGV4dC1kZWNv cmF0aW9uOg0KICAgICAgICAgICAgICAgIHVuZGVybGluZTsgZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4Ow0KICAgICAgICAgICAgICAgIGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOg0KICAg ICAgICAgICAgICAgIGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 Ow0KICAgICAgICAgICAgICAgIHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87DQogICAgICAgICAgICAgICAgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsNCiAgICAgICAgICAgICAgICAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGU8L2E+PC9kaXY+DQogICAgICAg ICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAgPGJyIGNsYXNzPSIi Pg0KICAgICAgPC9kaXY+DQogICAgICA8YnI+DQogICAgICA8ZmllbGRzZXQgY2xhc3M9Im1p bWVBdHRhY2htZW50SGVhZGVyIj48L2ZpZWxkc2V0Pg0KICAgICAgPGJyPg0KICAgICAgPHBy ZSB3cmFwPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KPGEgY2xhc3M9Im1vei10eHQtbGluay1h YmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmciPlVuYmVhcmFi bGVAaWV0Zi5vcmc8L2E+DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZTwvYT4NCjwv cHJlPg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8cD48YnI+DQogICAgPC9wPg0KICA8L2Jv ZHk+DQo8L2h0bWw+DQo= --------------78BCA6AF9260EC3A0E3AAD49-- From nobody Thu Feb 16 13:29:24 2017 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 7886D1296F7 for ; Thu, 16 Feb 2017 13:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 PH8hZlfKxuIR for ; Thu, 16 Feb 2017 13:29:07 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0091.outbound.protection.outlook.com [104.47.33.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494531296B4 for ; Thu, 16 Feb 2017 13:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DeLv4mlJxO0HwyhYkz93h640+O2BCijhQV99r6LEEDw=; b=Zzhm30QnBRI+4iR9MRSBnBeg4e6cWeIAoc+BCoa8icxGNe/ieQEcvQH+Schg/DjA80Jn9g85+B8wla0X3LKiZ5wtVyFQzfvy7stbJ2QUB4fZ/NzgkxozTSaaKis8BWYGhQCPb2gO1FHikV+qTzKGFZESXTSNx1oaPCxQQByyI78= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0843.namprd03.prod.outlook.com (10.160.163.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 16 Feb 2017 21:29:03 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.034; Thu, 16 Feb 2017 21:29:03 +0000 From: Andrei Popov To: Denis , John Bradley Thread-Topic: [Unbearable] Updated I-Ds Thread-Index: AdKIki7cdjaoT3T9Qfa4KQrr2Z1KPgAAsoQAAAB1bAAAANOA0A== Date: Thu, 16 Feb 2017 21:29:02 +0000 Message-ID: References: <2A56853E-C785-48CF-A75E-5F61683B1035@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: ad844274-4204-4c48-57f4-08d456b2d436 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0843; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0843; 7:WfnMzO2VPFTAVKFV6E9at5XB2P0D8xFDcMeTzYKWJ12601FzJ6wUfIGzD/PwfSg30DhUTsQy0a+Ejj4oGDQLsuAZ4sspyRaJ+P9x9/kUxbKAQ+UUAOo2vu7fE5QUGHHcz1NnAA4ZHkc72By7dPKTTqF7GVNsiUDwY1ZxZxYZJ5Mk7NbpYkt4ngMh9cnP5D7hSO+D3K/N1UEy/Ll/2WUs5buIJHtH1AHOsYTkL9vqMqC1J0sBaMvj4gCMBZqGKYmR0G8XH1INDhI0ZvakUH46jYqUFdAdqMAshKBpBfE2pHv/9wiy4UYr0z+cZ6KZjphWbpdGXlTLvm6F9MZZ/6QBEMuzxeR5hPNVO2BI8zHJR44= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(191636701735510)(158342451672863)(192374486261705)(21748063052155)(231250463719595); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:CY1PR0301MB0843; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0843; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39850400002)(39450400003)(39860400002)(39840400002)(199003)(377454003)(24454002)(189002)(8990500004)(2900100001)(97736004)(86612001)(54356999)(6246003)(68736007)(106356001)(10090500001)(122556002)(53936002)(7110500001)(105586002)(8676002)(189998001)(9326002)(81166006)(8936002)(81156014)(389900003)(76176999)(4000630100001)(50986999)(101416001)(86362001)(4326007)(2950100002)(229853002)(25786008)(3280700002)(6506006)(7906003)(74316002)(77096006)(7736002)(2906002)(3660700001)(606005)(55016002)(790700001)(99286003)(15650500001)(38730400002)(5660300001)(10710500007)(33656002)(10290500002)(5005710100001)(2420400007)(92566002)(9686003)(102836003)(236005)(6116002)(7696004)(6436002)(6306002)(54896002)(53546006)(15866825005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0843; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB084292E37631494FC866DC7C8C5A0CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2017 21:29:02.7829 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0843 Archived-At: Cc: IETF TokBind WG Subject: Re: [Unbearable] Updated I-Ds 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: Thu, 16 Feb 2017 21:29:11 -0000 --_000_CY1PR0301MB084292E37631494FC866DC7C8C5A0CY1PR0301MB0842_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Denis, I don't mind adding language (probably in the security considerations) sayi= ng that the Token Binding protocol does not prevent cooperating clients fro= m sharing a bound token. So far I do not sense much enthusiasm for this in the WG though... Cheers, Andrei From: Denis [mailto:denis.ietf@free.fr] Sent: Thursday, February 16, 2017 12:54 PM To: John Bradley ; Andrei Popov Cc: IETF TokBind WG Subject: Re: [Unbearable] Updated I-Ds Andrei, You said: The updated documents address the comments from the unbearable mailing list= . I don't believe that this is the case. I copy and paste a message sent on W= ed, 21 dec 2016 at 11:16:52 under the topic: "WGLC on draft-ietf-tokbind-https". Denis =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=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 On November 31, 2016, I sent a message saying: This set of documents failed to meet the terms of references of the WG char= ter. It is not resistant to the ABC attack (Alice and Bob collusion attack). In this attack Bob who is older than 18 colloborates with Alice and transmi= ts a token to Alice who is only 14 so that she can demonstrat to a RS that she is older than 18= . This kind of attack is not even mentionned in the security considerations s= ection. This set of documents should not be progressed to IETF last call unless the= attack can be countered. =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There are two options: Option A: drop this series of documents, i.e. : draft-ietf-tokbind-protocol draft-ietf-tokbind-https draft-ietf-tokbind-negotiation or Option B: clearly mention that the ABC attack cannot be countered using TLS= binding. In case, the latter decision would be taken by the WG, I propose a few text= replacements. Current text: Abstract This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind authentication tokens (such as cookies and OAuth tokens) to TLS [RFC5246] connections. We describe both _first-party_ and _federated_ scenarios. In a first-party scenario, an HTTP server is able to cryptographically bind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server. Such bound security tokens are protected from misuse since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections. Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS 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 [I-D.ietf-tokbind-protocol] Proposed additions in blue Abstract This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind authentication tokens (such as cookies and OAuth tokens) to TLS [RFC5246] connections. We describe both _first-party_ and _federated_ scenarios. In a first-party scenario, an HTTP server is able to cryptographically bind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server. Such bound security tokens are protected from misuse since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections. However, the binding a security token to a TLS connection is unable to counter collaboration attacks between two clients since one client can compute the necessary information for the other client without the need to release his key(s) to the other client. For an effective protection against collaboration attacks, an appropriate format of the security token, together with an appropriate validation of some fields of it, must be used. Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS 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 [I-D.ietf-tokbind-protocol] Current text: 7.1. Security Token Replay The goal of the Federated Token Binding mechanisms is to prevent attackers from exporting and replaying tokens used in protocols between the client and Token Consumer, thereby impersonating legitimate users and gaining access to protected resources. Bound tokens can still be replayed by malware present in the client. In order to export the token to another machine and successfully replay it, the attacker also needs to export the corresponding private key. The Token Binding private key is therefore a high-value asset and MUST be strongly protected, ideally by generating it in a hardware security module that prevents key export Proposed replacement 7.1. Security Token Export and Replay The goal of the Federated Token Binding mechanisms is to prevent attackers from exporting and replaying tokens used in protocols between the client and Token Consumer, thereby impersonating legitimate users and gaining access to protected resources. Bound tokens can still be replayed by malware present in the client. They can also be exported and re-used when a client collaborates with another client. In order to export the token to another machine and successfully use it, a client may export the corresponding private key to the other client or may perform all the necessary computations for the other client without exporting the corresponding private. Protecting the Token Binding private key, e.g. in a hardware security module that prevents key export is a good practice, but in such a case, it is inefficient to counter the clients collaboration attack. Some other changes might need to be done in the same spirit. Denis Thanks. On Feb 16, 2017, at 5:26 PM, Andrei Popov > wrote: The updated versions of TBPROTO, TBNEGO and HTTPSTB have been uploaded: https://tools.ietf.org/html/draft-ietf-tokbind-protocol-12 https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-07 https://tools.ietf.org/html/draft-ietf-tokbind-https-08 The updated documents address the comments from the unbearable mailing list= and GitHub. Cheers, Andrei _______________________________________________ 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 --_000_CY1PR0301MB084292E37631494FC866DC7C8C5A0CY1PR0301MB0842_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Denis,

 

I don’t mind adding language= (probably in the security considerations) saying that the Token Binding pr= otocol does not prevent cooperating clients from sharing a bound token.

So far I do not sense much enthusi= asm for this in the WG though…

 

Cheers,

 

Andrei

 

From: Denis [mailto:denis.ietf@free.fr]
Sent: Thursday, February 16, 2017 12:54 PM
To: John Bradley <ve7jtb@ve7jtb.com>; Andrei Popov <Andrei.= Popov@microsoft.com>
Cc: IETF TokBind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] Updated I-Ds

 

Andrei,

You said:

The updated documents = address the comments from the unbearable mailing list.

I don't believe that this is the case. I copy and pa= ste a message sent on Wed, 21 dec 2016 at 11:16:52
under the topic: "WGLC on draft-ietf-tokbind-https".

Denis
=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=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

On November 31, 20= 16, I sent a message saying:

This set of doc= uments failed to meet the terms of references of the WG charter.

It is not resistant to the ABC attack (Alice and Bob collusion attack).
In this attack Bob who is older than 18 colloborates with Alice and transmi= ts a token to Alice
who is only 14 so that she can demonstrat to a RS that she is older than 18= .

This kind of attack is not even mentionned in the security considerations s= ection.

This set of documents should not be progressed to IETF last call unless the= attack can be countered.

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There are two options:
 
Option A: drop this series of documents, i.e. :

  draft-ietf-tokbind-protocol
  draft-ietf-tokbind-https
  draft-ietf-tokbind-negotiation

or

Option B: clearly m= ention that the ABC attack cannot be countered using TLS binding.

In case, the latter decision would be taken by the WG, I propose a few text= replacements.

C= urrent text:

 
 Abstract    
 
       This document describes a collection of mechanisms that allow HTTP
   servers to cryptographic=
ally bind authentication tokens (such as
   cookies and OAuth tokens=
) to TLS [RFC5246] c=
onnections.
   
      We describe both _first-party_ and _federated_ scenarios.  In a
   first-party scenario, an=
 HTTP server is able to cryptographically
   bind the security tokens=
 it issues to a client, and which the client
   subsequently returns to =
the server, to the TLS connection between the
   client and server. =
 Such bound security tokens are protected from
   misuse since the server =
can generally detect if they are replayed
   inappropriately, e.g., o=
ver other TLS connections. 
 
   Federated token bindings=
, on the other hand, allow servers to
   cryptographically bind s=
ecurity tokens to a TLS connection that the
   client has with a _diffe=
rent_ server than the one issuing the token.
 
   This Internet-Draft is a=
 companion document to The Token Binding
   Protocol [I-D.ietf-tokbind-protocol]
 
 
Proposed additions <=
span style=3D"font-size:11.0pt;color:blue">in blue 
 
Abstract
    =

   This document descr=
ibes a collection of mechanisms that allow HTTP
   servers to cryptographic=
ally bind authentication tokens (such as
   cookies and OAuth tokens=
) to TLS [RFC5246] c=
onnections.
 
   We describe both _first-=
party_ and _federated_ scenarios.  In a
   first-party scenario, an=
 HTTP server is able to cryptographically
   bind the security tokens=
 it issues to a client, and which the client
   subsequently returns to =
the server, to the TLS connection between the
   client and server. =
 Such bound security tokens are protected from
   misuse since the server =
can generally detect if they are replayed
   inappropriately, e.g., o=
ver other TLS connections. 
 
   However, t=
he binding a security token to a TLS connection is

   unable to =
counter collaboration attacks between two clients since


   one client=
 can compute the necessary information for the other<=
/pre>

   client wit=
hout the need to release his key(s) to the other client.<=
/b>


 


   For an eff=
ective protection against collaboration attacks, an

   appropriat=
e format of the security token, together with an

    appropriate validation of some fields of it, must be us=
ed. 


 


   Federated token bindings=
, on the other hand, allow servers to


   cryptographically bind s=
ecurity tokens to a TLS connection that the


   client has with a _diffe=
rent_ server than the one issuing the token.


 


   This Internet-Draft is a=
 companion document to The Token Binding 


   Protocol [I-D.ietf-tokbind-protocol]<=
/pre>

 


 


C=
urrent text:



7.1. Security Token Replay


   The goal of the Federate=
d Token Binding mechanisms is to prevent


   attackers from exporting=
 and replaying tokens used in protocols 


   between the client =
and Token Consumer, thereby impersonating


   legitimate users and gai=
ning access to protected resources.  Bound


   tokens can still be repl=
ayed by malware present in the client.  In


   order to e=
xport the token to another machine and successfully replay


   it, the at=
tacker also needs to export the corresponding private key.


   The Token =
Binding private key is therefore a high-value asset and

   MUST be st=
rongly protected, ideally by generating it in a hardware<=
/pre>

   security m=
odule that prevents key export


 


P=
roposed replacement


7.=
1. Security Token 
Export and
Replay


 


&n=
bsp;  The goal of the Federated Token Binding mechanisms is to prevent=



&n=
bsp;  attackers from exporting and replaying tokens used in protocols<=
o:p>


&n=
bsp;  between the client and Token Consumer, thereby impersonating


&n=
bsp;  legitimate users and gaining access to protected resources. =
; Bound


&n=
bsp;  tokens can still be replayed by malware present in the client.


&n=
bsp;  They can also be exported and re-used when a client =
collaborates


  with another client.  In order to exp=
ort the token to another


   machine and successfully use it, a client may export =
the



   corresponding private key to the other client or=
 may perform all



   the necessary computations for the other client =
without exporting



   the corresponding private.  Pr=
otecting the
 Token Binding private 


   key, e.g. in a hardware security module that pre=
vents key export is



   a good practice, but in such a case, it is ineff=
icient to counter



   the clients collaboration attack.
=



Some other ch=
anges might need to be done in the same spirit.


 


Denis<=
o:p>


 

Thanks.

 

 

On Feb 16, 2017, at 5:26 PM, Andrei Popov <Andrei.Popov@microsoft.com> = wrote:

 

The updated versions of TBPROTO, TBNEGO and HTTPSTB= have been uploaded:

 

The updated documents address the comments from the= unbearable mailing list and GitHub.

 

Cheers,

 

Andrei

_______________________________________________ Unbearable mailing list
Unbearable@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/unbearable

 




_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://w=
ww.ietf.org/mailman/listinfo/unbearable

 

--_000_CY1PR0301MB084292E37631494FC866DC7C8C5A0CY1PR0301MB0842_-- From nobody Thu Feb 16 13:40:02 2017 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 27B8D129577 for ; Thu, 16 Feb 2017 13:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 Uno2U1-XjNWa for ; Thu, 16 Feb 2017 13:39:57 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d: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 BABCA129629 for ; Thu, 16 Feb 2017 13:39:56 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id p22so28761923qka.0 for ; Thu, 16 Feb 2017 13:39:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0uJiJKTbMuUfbxYk+Nzya+8CQ95Noe2QEvTnNR5jv84=; b=lAdrZUE3yLve1F2HGDP6DIuZcfnPXTNwUVl5Ce4wObsu5Vg2KEBrMwTzBayh0BdOFa AnwVFUCsLM6Fngg/JqHf/rGxsXZo2jlF87iWnv/EdUPl/FjpoVQLLX0NdKNS+7eAFAcj u+H9AMgIQzj696UPgEk9E+gYGTzPAkdl2beq1ZIk8gaYnfra83162Y9oZXFBhKCZqByJ ML4xBLDPc7yy2YqLgR+skVEVQNrM0D7EmaaiKPkr/4a2p1fqwjTtf1NFe7QmNJvzb7iH ef/OpIG+o3ixeZTz1E2JY88c/IghI1Qr6nyJtBoKcNc5diWkkmO0okMIeHuGT4qxKv+I RxyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0uJiJKTbMuUfbxYk+Nzya+8CQ95Noe2QEvTnNR5jv84=; b=FRBgC6VREE+cX4OZQG6SA3nXoG5LNcuM8JGEnqcooeKqCB+YVhfmRgkLUtx+fm3Iu6 FQgF5G+YzpcDPVdVhVj7cp5tPUg5gd30Ew/IxM/+CCa2xlutoZC0o0o6AdIOjfJQ7Z86 9tBLsmal5I1uU+RAdfMMQrmd7xPypogxji5yJ4NEgtknSkWf2pN1/th097lSK32IFS0p BJ7jgTqEYYdh8CdXhCvR5JJKJu0xQsMuCBoClyarijjsmfrp7WawbHbhZn2rpWu0d9vX nV/iYhRol6HAbtEG8FI8vj7cVHE9ppSTiqXILTfybe2tVd0f9hnwjKD6XWMNzlsWh+cH AJzA== X-Gm-Message-State: AMke39m+eXMjjCdxc42eCJT2kgy/1HP2PW6tT8ifjuH1x4vJEGZ3xlz5hIpT6a3wsSzoH5U1 X-Received: by 10.55.98.12 with SMTP id w12mr4087693qkb.85.1487281195579; Thu, 16 Feb 2017 13:39:55 -0800 (PST) Received: from [192.168.8.100] ([181.201.178.1]) by smtp.gmail.com with ESMTPSA id 23sm5201006qtp.20.2017.02.16.13.39.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 13:39:54 -0800 (PST) From: John Bradley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_94E402AD-095C-4261-B48F-90361167A219"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 16 Feb 2017 18:39:51 -0300 In-Reply-To: To: Andrei Popov References: <2A56853E-C785-48CF-A75E-5F61683B1035@ve7jtb.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF TokBind WG , Denis Subject: Re: [Unbearable] Updated I-Ds 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: Thu, 16 Feb 2017 21:39:59 -0000 --Apple-Mail=_94E402AD-095C-4261-B48F-90361167A219 Content-Type: multipart/alternative; boundary="Apple-Mail=_E633A415-BA32-4051-9224-96EC1B61B17A" --Apple-Mail=_E633A415-BA32-4051-9224-96EC1B61B17A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I suspect it is just one of those things we all think is self evident. I don=E2=80=99t think having a security consideration will hurt = anything. John B. > On Feb 16, 2017, at 6:29 PM, Andrei Popov = wrote: >=20 > Hi Denis, > =20 > I don=E2=80=99t mind adding language (probably in the security = considerations) saying that the Token Binding protocol does not prevent = cooperating clients from sharing a bound token. > So far I do not sense much enthusiasm for this in the WG though=E2=80=A6= > =20 > Cheers, > =20 > Andrei > =20 > From: Denis [mailto:denis.ietf@free.fr]=20 > Sent: Thursday, February 16, 2017 12:54 PM > To: John Bradley ; Andrei Popov = > Cc: IETF TokBind WG > Subject: Re: [Unbearable] Updated I-Ds > =20 > Andrei,=20 >=20 > You said: > The updated documents address the comments from the unbearable mailing = list. > I don't believe that this is the case. I copy and paste a message sent = on Wed, 21 dec 2016 at 11:16:52=20 > under the topic: "WGLC on draft-ietf-tokbind-https". >=20 > Denis > = =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=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 >=20 > On November 31, 2016, I sent a message saying: > This set of documents failed to meet the terms of references of the WG = charter. >=20 > It is not resistant to the ABC attack (Alice and Bob collusion = attack). > In this attack Bob who is older than 18 colloborates with Alice and = transmits a token to Alice=20 > who is only 14 so that she can demonstrat to a RS that she is older = than 18. >=20 > This kind of attack is not even mentionned in the security = considerations section. >=20 > This set of documents should not be progressed to IETF last call = unless the attack can be countered. >=20 > = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > There are two options: > =20 > Option A: drop this series of documents, i.e. :=20 >=20 > draft-ietf-tokbind-protocol > draft-ietf-tokbind-https > draft-ietf-tokbind-negotiation >=20 > or=20 >=20 > Option B: clearly mention that the ABC attack cannot be countered = using TLS binding. >=20 > In case, the latter decision would be taken by the WG, I propose a few = text replacements. >=20 > Current text: > =20 > Abstract =20 > =20 > This document describes a collection of mechanisms that allow = HTTP > servers to cryptographically bind authentication tokens (such as > cookies and OAuth tokens) to TLS [RFC5246 = ] connections. > =20 > We describe both _first-party_ and _federated_ scenarios. In a > first-party scenario, an HTTP server is able to cryptographically > bind the security tokens it issues to a client, and which the = client > subsequently returns to the server, to the TLS connection between = the > client and server. Such bound security tokens are protected from > misuse since the server can generally detect if they are replayed > inappropriately, e.g., over other TLS connections.=20 > =20 > Federated token bindings, on the other hand, allow servers to > cryptographically bind security tokens to a TLS connection that the > client has with a _different_ server than the one issuing the = token. > =20 > This Internet-Draft is a companion document to The Token Binding > Protocol [I-D.ietf-tokbind-protocol = ] > =20 > =20 > Proposed additions in blue=20 > =20 > Abstract > =20 > This document describes a collection of mechanisms that allow HTTP > servers to cryptographically bind authentication tokens (such as > cookies and OAuth tokens) to TLS [RFC5246 = ] connections. > =20 > We describe both _first-party_ and _federated_ scenarios. In a > first-party scenario, an HTTP server is able to cryptographically > bind the security tokens it issues to a client, and which the = client > subsequently returns to the server, to the TLS connection between = the > client and server. Such bound security tokens are protected from > misuse since the server can generally detect if they are replayed > inappropriately, e.g., over other TLS connections.=20 > =20 > However, the binding a security token to a TLS connection is > unable to counter collaboration attacks between two clients since > one client can compute the necessary information for the other > client without the need to release his key(s) to the other client. > =20 > For an effective protection against collaboration attacks, an > appropriate format of the security token, together with an > appropriate validation of some fields of it, must be used.=20 > =20 > Federated token bindings, on the other hand, allow servers to > cryptographically bind security tokens to a TLS connection that the > client has with a _different_ server than the one issuing the = token. > =20 > This Internet-Draft is a companion document to The Token Binding=20 > Protocol [I-D.ietf-tokbind-protocol = ] > =20 > =20 > Current text: > 7.1. Security Token Replay > The goal of the Federated Token Binding mechanisms is to prevent > attackers from exporting and replaying tokens used in protocols=20 > between the client and Token Consumer, thereby impersonating > legitimate users and gaining access to protected resources. Bound > tokens can still be replayed by malware present in the client. In > order to export the token to another machine and successfully = replay > it, the attacker also needs to export the corresponding private = key. > The Token Binding private key is therefore a high-value asset and > MUST be strongly protected, ideally by generating it in a hardware > security module that prevents key export > =20 > Proposed replacement > 7.1. Security Token Export and Replay >=20 > =20 >=20 > The goal of the Federated Token Binding mechanisms is to prevent >=20 > attackers from exporting and replaying tokens used in protocols >=20 > between the client and Token Consumer, thereby impersonating >=20 > legitimate users and gaining access to protected resources. Bound >=20 > tokens can still be replayed by malware present in the client. >=20 > They can also be exported and re-used when a client collaborates >=20 > with another client. In order to export the token to another >=20 > machine and successfully use it, a client may export the >=20 > corresponding private key to the other client or may perform all >=20 > the necessary computations for the other client without exporting >=20 > the corresponding private. Protecting the Token Binding private=20 >=20 > key, e.g. in a hardware security module that prevents key export is >=20 > a good practice, but in such a case, it is inefficient to counter >=20 > the clients collaboration attack. >=20 > Some other changes might need to be done in the same spirit. > =20 > Denis > =20 > Thanks.=20 > =20 > =20 > On Feb 16, 2017, at 5:26 PM, Andrei Popov > wrote: > =20 > The updated versions of TBPROTO, TBNEGO and HTTPSTB have been = uploaded: > https://tools.ietf.org/html/draft-ietf-tokbind-protocol-12 = > https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-07 = > https://tools.ietf.org/html/draft-ietf-tokbind-https-08 = > =20 > The updated documents address the comments from the unbearable mailing = list and GitHub. > =20 > Cheers, > =20 > Andrei > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable = > =20 >=20 >=20 >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable = > =20 >=20 --Apple-Mail=_E633A415-BA32-4051-9224-96EC1B61B17A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I suspect it is just one of those things we all think is self = evident.

I don=E2=80=99= t think having a security consideration will hurt anything.

John B.
On = Feb 16, 2017, at 6:29 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

Hi Denis,
 
I = don=E2=80=99t mind adding language (probably in the security = considerations) saying that the Token Binding protocol does not prevent = cooperating clients from sharing a bound token.
So far I do not sense much enthusiasm for this = in the WG though=E2=80=A6
 
Cheers,
 
Andrei
 
From: Denis [mailto:denis.ietf@free.fr] 
Sent: Thursday, February 16, 2017 = 12:54 PM
To: John Bradley <ve7jtb@ve7jtb.com>; = Andrei Popov <Andrei.Popov@microsoft.com>
Cc: IETF = TokBind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] Updated = I-Ds
 
Andrei, 

You said:
The updated documents address the comments from the = unbearable mailing list.
I don't believe that this is the case. I copy and paste a = message sent on Wed, 21 dec 2016 at 11:16:52 
under the = topic: "WGLC on draft-ietf-tokbind-https".

Denis
=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=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

On = November 31, 2016, I sent a message saying:

This set of = documents failed to meet the terms of references of the WG charter.

It is not resistant to the ABC attack (Alice = and Bob collusion attack).
In this attack Bob who is older = than 18 colloborates with Alice and transmits a token to Alice 
who is only = 14 so that she can demonstrat to a RS that she is older than 18.

This kind of attack is not even mentionned in = the security considerations section.

This = set of documents should not be progressed to IETF last call unless the = attack can be countered.

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

There are two options:
 
Option A: drop this = series of documents, i.e. : 

  draft-ietf-tokbind-protocol
  = draft-ietf-tokbind-https
  = draft-ietf-tokbind-negotiation

or 

Option B: clearly mention that the ABC attack cannot be = countered using TLS binding.

In case, the = latter decision would be taken by the WG, I propose a few text = replacements.

Current text:

 
 Abstract    =

 
       This document describes a =
collection of mechanisms that allow HTTP
   servers to =
cryptographically bind authentication tokens (such as
   cookies and OAuth =
tokens) to TLS [RFC5246] connections.
   
      We describe both _first-party_ and =
_federated_ scenarios.  In a
   first-party scenario, an HTTP server is able to =
cryptographically
   bind =
the security tokens it issues to a client, and which the client
   subsequently returns =
to the server, to the TLS connection between the
   client and =
server.  Such bound security tokens are protected from
   misuse since the =
server can generally detect if they are replayed
   inappropriately, =
e.g., over other TLS connections. 
 
   =
Federated token bindings, on the other hand, allow servers to
   cryptographically =
bind security tokens to a TLS 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 [I-D.ietf-tokbind-protocol]
 
 
Proposed =
additions in blue 
 
Abstract
    
   This document =
describes a collection of mechanisms that allow HTTP
   servers to =
cryptographically bind authentication tokens (such as
   cookies and OAuth =
tokens) to TLS [RFC5246] connections.
 
   We describe both =
_first-party_ and _federated_ scenarios.  In a
   first-party scenario, =
an HTTP server is able to cryptographically
   bind the security =
tokens it issues to a client, and which the client
   subsequently returns =
to the server, to the TLS connection between the
   client and =
server.  Such bound security tokens are protected from
   misuse since the =
server can generally detect if they are replayed
   inappropriately, =
e.g., over other TLS connections. 
 
   However, the binding a security = token to a TLS connection is
   unable to counter collaboration =
attacks between two clients since
   one client can compute the necessary information =
for the other
   client without the need to release his key(s) to =
the other client.
 
   For an effective protection = against collaboration attacks, an
   appropriate format of the security token, =
together with an
  =
  appropriate validation of some fields of it, must =
be used. 
 
   Federated token =
bindings, on the other hand, allow servers to
   cryptographically =
bind security tokens to a TLS 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 [I-D.ietf-tokbind-protocol]
 
 

Current text:

7.1. Security Token Replay

   The goal of the Federated Token Binding = mechanisms is to prevent
   attackers from exporting and replaying tokens =
used in protocols 
   between the client and Token Consumer, =
thereby impersonating
   legitimate users and gaining access to protected =
resources.  Bound
   tokens can still be replayed by malware present =
in the client.  In
   order to export the token =
to another machine and successfully replay
   it, the attacker also needs to export the =
corresponding private key.
   The Token Binding private =
key is therefore a high-value asset and
   MUST be strongly protected, ideally by =
generating it in a hardware
   security module that =
prevents key export
 

Proposed= replacement

7.1. Security Token Export and Replay

 

   The goal of the Federated Token Binding = mechanisms is to prevent

   attackers from exporting and replaying tokens = used in protocols

   between the client and Token Consumer, thereby = impersonating

   legitimate = users and gaining access to protected resources.  Bound

   tokens can still be = replayed by malware present in the client.

   They can also be exported and re-used when a client = collaborates

  with another client.  In order to export the = token to another

   machine and successfully use it, a = client may export the

   corresponding private key to = the other client or may perform all

   the necessary computations = for the other client without exporting

   the= corresponding private.  = Protecting the Token Binding private 

   key, e.g. in a hardware security module = that prevents key export is

   a good practice, but in such = a case, it is inefficient to counter

   the clients collaboration = attack.

Some other changes might need to be done in the =
same spirit.
 
Denis
 
Thanks. 
 
 
On = Feb 16, 2017, at 5:26 PM, Andrei Popov <Andrei.Popov@microsoft.com>= wrote:
 
The updated versions of TBPROTO, TBNEGO and HTTPSTB have been = uploaded:
https://tools.ietf.org/html/draft-ietf-tokbind-protocol-12
https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-07
https://tools.ietf.org/html/draft-ietf-tokbind-https-08<= /a>
 
The updated documents address the comments from = the unbearable mailing list and GitHub.
 
Cheers,
 
Andrei
 



_______________________________________________
Unbearable =
mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable

 


= --Apple-Mail=_E633A415-BA32-4051-9224-96EC1B61B17A-- --Apple-Mail=_94E402AD-095C-4261-B48F-90361167A219 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILMTCCBUcw ggQvoAMCAQICEEAfBHP+tuqufC4R+F+Tu54wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAyIENsaWVudCBDQTAeFw0xNjA4MTIy MTE5NDFaFw0xODA4MTIyMTE5NDFaMIGCMQswCQYDVQQGEwJDTDEiMCAGA1UECAwZTWV0cm9wb2xp dGFuYSBkZSBTYW50aWFnbzEWMBQGA1UEBwwNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAwwMSm9obiBC cmFkbGV5MSAwHgYJKoZIhvcNAQkBFhF2ZTdqdGJAdmU3anRiLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALhTcSiDGvVrm4hlJA8WyFcWWe0dqnuJzstQYTaF281JFOEPA/13kQYI JMXAEUcS7NvW7KdUI0tHU0N6RTo0Ilf1E1nm8No++eqHO8pFUZ/cidpv0r+1Qcl9EgrpbZ00Y7Xg pq06EZELzJAmds4QQcsTKdpLNFbVcFnM11i2Gj5VNsYgO+qPO2AS8rLHkgDWnNkc9/lA+ZK5wGiU zxPU9KnIrERoTif3Zk7KjLvFpBWYD60M/lNoHZ5zxYgmYLmvoM1TSLn4Ms57wwT5MieV2l0aqlGC 7CKNa6XyeL1B0y0wSxL3PJQS4vSLDnttZC7od2A6yjeUMyM3rQ41vqUIMc8CAwEAAaOCAcMwggG/ MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUmA9bUmBmTYkCcZ3yYv8IRRP2nN4wHwYDVR0jBBgwFoAUmZerGDU6i1lFQ5iy cnHI9PsJzxYwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNz bC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGll bnQyLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xp ZW50Mi5jcmwwHAYDVR0RBBUwE4ERdmU3anRiQHZlN2p0Yi5jb20wIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMFUGA1UdIAROMEwwDAYKKwYBBAGBtTcGATA8BgsrBgEEAYG1NwEC BTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4IBAQBqcYJfFA/ITkX4L6JihqW168Wog1BOfkbPXO+wPn5G9P1NwruGfu41b70EPPwV vol+/j+qhSSrDjFyfNBsq4G45GRR6hwx0ei/bH0UW15Y63ASYPkNlj3ydCcvhw5ItWD5aYPphBx9 C7tLnQ7ow09cqt2CIgPd3W/IGri7p4hWPbdcX0oFIhJcDxmCwTcWyoVoIo4aas5gP44LPGneCoqI lXQMJinwneEnKd7rWXlzVWv7geaH3t79zARSw9ev9F4E61cDuHi+vgTFEpio7oxybqfj99yLibhX uZjReYnYbDMRiWDXduVIrIGYwmnUuD8a0b20kJgHm+FEgB6UMa9JMIIF4jCCA8qgAwIBAgIQXLZI bkcMmMZ/9oDbZErijTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1 WhcNMzAxMjE2MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDIgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7g9Q jJUJI4Ss9VBqj9Y3ok4h/TIJZUc+rzj61Rv3hNB/yeEEC1fz3i/EU+MXOOGxM7KCbtCIcJxHIW/k 8RP6sPPMO4cTg7sNzfBWsYsemtY6fN/kVr2R2X+/PjvtxmAaXpGX0znvQPxaE123IMGXy0zEKHZ/ nJDZ199TP9TNn9v+1QO0AZb4oaJ7ch0DpSJa8kF5xiNFDAg9taKKSrVuPHJL9MFFYPIqwShjHg+u YEzjfxbMP2QWwamnaA9Y7fORSDNapduFlARAcDtXdMpAijiG4HKnrN323I0Ka7lDTAWyLtTDCETK sI8fzOyL0inEu1WEVpdPytm8s1rwQB4f9QIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQr MCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRa MFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBSZl6sYNTqLWUVDmLJy ccj0+wnPFjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUd IAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4ICAQCZQUEEzvYk9U4wNHhDu1f9QGwbzAH4m4wIKH8ZidNYwZhyoNKW041iJ002KMW9 ywYM95n4770tT45yH29vTMlZtBvz0h44KuxMLNXRCTDwvV07sT39nPjFi5MpwZaLVueNiaa1vok1 n2Wn8lLcyCltYZNGAEifM0ko/A/vvckftFIZG75RAiZHYtfnrdBGiOxyF+nHI9a33BRX5Vl/3z0+ uHZ/Y6YPbNJ7iboOFrFZBCtt+lp3WaDB62ZoBewiMmd09JrqmMJAEgw3EbfQNtaPzHPg/EOhlZik Rgd4BCrzrbIqB2RKib+gnQJt2uoJaKOaV90S9Xgs3PC837OE9CEmY6/MTTG0xpbLh2hR/rLQ3sCr H56aODeuDrQBq85lXxRbDCERDUR7FZUhHv+i1aQaY59NPu26hDd6nqksSDq2mCddpidPBuGJz9lN X2nRyGkudDuWV6gIr6AZfaYv+ggTXOcCDJZFzMhWdLC7CPvRKxQ7vTiYV+4lgqOvV9MnZc149PPt itTysq/oOv70zx7q+tyaLTa4cqFhCclhIwSwOEJiV3xqQebvmwsDX7BaXGAJZIhbdUbNr3poEgct 6uAxw2zyr69WCJmTUUhz/k1/TT/eCUZJqnMg/6mje7tiVdaUQJcBtJ6cq5+mUDNUB1fohW8EOFai zFpP/0FaP62ctTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMiBDbGllbnQgQ0ECEEAfBHP+tuqufC4R+F+Tu54wCQYFKw4DAhoF AKCCAZkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjE2MjEz OTUyWjAjBgkqhkiG9w0BCQQxFgQUVXc1zNEEiPkl/UB0nJLZ4ZKKFN8wgZoGCSsGAQQBgjcQBDGB jDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIg Q2xpZW50IENBAhBAHwRz/rbqrnwuEfhfk7ueMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIgQ2xpZW50IENBAhBA HwRz/rbqrnwuEfhfk7ueMA0GCSqGSIb3DQEBAQUABIIBAFtCjOzCUEg1hlH5nEg5EhbIEN4pa8AN vSx2bUtRSIc0vzjxvkBP1xJ5BQw90+znXSPAjyDxNua1PCGfmfAsmu626ENyhMF8P8fwvLYzvARU RkWh+NyHqEU1xHy5e0LNdtJXLyf8cvDSm7ka0ttZZhI6rZk4iYAkjoKM+DB0ywHOxaNWRPeMT650 2nlUHSM5f2shtSTKwkfFEpGe4wCXIn3aYC6epBGI/nAxdS1/K8KE6LrK1smTwxdgpOp/zCrdwua5 NZn/ibYPcnMMuTm4T3KZNJHunU6Ezl8NEEFY+mUELWfxJWN/i5xyA1GPSwU5da7ItjeVjdAknakr F1Z1pccAAAAAAAA= --Apple-Mail=_94E402AD-095C-4261-B48F-90361167A219-- From nobody Thu Feb 16 13:50:25 2017 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 91F6A1296CB for ; Thu, 16 Feb 2017 13:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 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, T_KAM_HTML_FONT_INVALID=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 Zgvzi2jt9eoI for ; Thu, 16 Feb 2017 13:50:22 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002: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 139F81296A4 for ; Thu, 16 Feb 2017 13:50:22 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id l19so15023627ywc.2 for ; Thu, 16 Feb 2017 13:50:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C0cxU2izx+wIvL3SfQAPysR3/NzYlTO215DQ6lH0WUY=; b=LcbCxf6eXTu3oEieXwE6SeOycfoImlmYWIusGQehg87eP7UoiBsnIAxr8hf7qFGFoL SIZtjPwsHFwscJd9sVRztV0rOT2qqH70cT2nEw5jtNIebUzFPqsTzw6Yqq5MS0kkslMQ kMR7uPYcn/PhNeDsHLewUQfYBcT6KZmIC1aSpYV4jGwY78dqUb1mq3kSsC51YLEAqU4a +Y+UqnCRU9IUZ4zkYOiyJYGWaEo1sCWLWooWyK8w5rG6GIFl4XAlx5YY1jSwW8+Z/khi SedFlgwh1Iw7RQ3hF+Ojow6mUCpNW7Pkaupbf/9K6BUVTjQip1aGOmt498xRUf7Ydnsz biWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C0cxU2izx+wIvL3SfQAPysR3/NzYlTO215DQ6lH0WUY=; b=qGUfnlu1bvy/pSB/nklGJNgN0E1qvLDA9qxB4uTksOpSjFkWO/V/ikXiA3O4b/nSe7 9bNSpQMPqlgEcgjonYuO87L6khfx2kA0FdAmNSa813XHHYjuxSQvki0XAJvT7brDtPDQ 8QdhFscPkF+6ZoX81S6yQESNbRhzqk4yLLHbEY9uSyd8bGN97Yybl+3e4Ckdun7WecPq kuL72RIkzxFJ8sDEaGF5Zk2esFQSxjR9TxOqSwVVKgU3kyfqS0En4Ub6a6wM/WXppeJK aa9F5t5I51ELRewET3tU0kg3xKqkkMafmh6INqHPSurfngW1L1rPSD7erFR6j9EfaKCr f+DA== X-Gm-Message-State: AMke39kLrXRL2AwnNO0fEvTmrOcwymDnVsIFW24ID6imYwbUOR6ajoUo66rj990py5SXbHRXz229mAAnb30q82Tl X-Received: by 10.129.7.215 with SMTP id 206mr3277125ywh.228.1487281820941; Thu, 16 Feb 2017 13:50:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.161.87 with HTTP; Thu, 16 Feb 2017 13:50:00 -0800 (PST) In-Reply-To: References: <2A56853E-C785-48CF-A75E-5F61683B1035@ve7jtb.com> From: Nick Harper Date: Thu, 16 Feb 2017 13:50:00 -0800 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a11428b3a9eb8e80548acc82f Archived-At: Cc: Andrei Popov , Denis , IETF TokBind WG Subject: Re: [Unbearable] Updated I-Ds 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: Thu, 16 Feb 2017 21:50:24 -0000 --001a11428b3a9eb8e80548acc82f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think that we don't need to do any more than add a sentence to 7.1 of TBPROTO saying something along the lines of "the Token Binding protocol does not prevent cooperating clients from sharing a bound token" (i.e. what Andrei said). I'm also fine if we don't add anything. On Thu, Feb 16, 2017 at 1:39 PM, John Bradley wrote: > I suspect it is just one of those things we all think is self evident. > > I don=E2=80=99t think having a security consideration will hurt anything. > > John B. > > On Feb 16, 2017, at 6:29 PM, Andrei Popov > wrote: > > Hi Denis, > > I don=E2=80=99t mind adding language (probably in the security considerat= ions) > saying that the Token Binding protocol does not prevent cooperating clien= ts > from sharing a bound token. > So far I do not sense much enthusiasm for this in the WG though=E2=80=A6 > > Cheers, > > Andrei > > *From:* Denis [mailto:denis.ietf@free.fr ] > *Sent:* Thursday, February 16, 2017 12:54 PM > *To:* John Bradley ; Andrei Popov < > Andrei.Popov@microsoft.com> > *Cc:* IETF TokBind WG > *Subject:* Re: [Unbearable] Updated I-Ds > > Andrei, > > You said: > > The updated documents address the comments from the unbearable mailing > list. > > I don't believe that this is the case. I copy and paste a message sent on > Wed, 21 dec 2016 at 11:16:52 > under the topic: "WGLC on draft-ietf-tokbind-https". > > Denis > =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 > =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 > > On November 31, 2016, I sent a message saying: > > This set of documents failed to meet the terms of references of the WG > charter. > > It is not resistant to the ABC attack (Alice and Bob collusion attack). > In this attack Bob who is older than 18 colloborates with Alice and > transmits a token to Alice > who is only 14 so that she can demonstrat to a RS that she is older than > 18. > > This kind of attack is not even mentionned in the security considerations > section. > > This set of documents should not be progressed to IETF last call unless > the attack can be countered. > > =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > There are two options: > > *Option A*: drop this series of documents, i.e. : > > draft-ietf-tokbind-protocol > draft-ietf-tokbind-https > draft-ietf-tokbind-negotiation > > or > > *Option B*: clearly mention that the ABC attack cannot be countered using > TLS binding. > > In case, the latter decision would be taken by the WG, I propose a few > text replacements. > > *Current text:* > > > > Abstract > > > > This document describes a collection of mechanisms that allow HTTP > > servers to cryptographically bind authentication tokens (such as > > cookies and OAuth tokens) to TLS [RFC5246 ] connections. > > > > We describe both _first-party_ and _federated_ scenarios. In a > > first-party scenario, an HTTP server is able to cryptographically > > bind the security tokens it issues to a client, and which the client > > subsequently returns to the server, to the TLS connection between the > > client and server. Such bound security tokens are protected from > > misuse since the server can generally detect if they are replayed > > inappropriately, e.g., over other TLS connections. > > > > Federated token bindings, on the other hand, allow servers to > > cryptographically bind security tokens to a TLS 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 [I-D.ietf-tokbind-protocol ] > > > > > > *Proposed additions **in blue* > > > > Abstract > > > > This document describes a collection of mechanisms that allow HTTP > > servers to cryptographically bind authentication tokens (such as > > cookies and OAuth tokens) to TLS [RFC5246 ] connections. > > > > We describe both _first-party_ and _federated_ scenarios. In a > > first-party scenario, an HTTP server is able to cryptographically > > bind the security tokens it issues to a client, and which the client > > subsequently returns to the server, to the TLS connection between the > > client and server. Such bound security tokens are protected from > > misuse since the server can generally detect if they are replayed > > inappropriately, e.g., over other TLS connections. > > > > * However, the binding a security token to a TLS connection is* > > * unable to counter collaboration attacks between two clients since* > > * one client can compute the necessary information for the other* > > * client without the need to release his key(s) to the other client.* > > > > * For an effective protection against collaboration attacks, an* > > * appropriate format of the security token, together with an* > > * appropriate validation of some fields of it, must be used.* > > > > Federated token bindings, on the other hand, allow servers to > > cryptographically bind security tokens to a TLS 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 [I-D.ietf-tokbind-protocol ] > > > > > > *Current text:* > > 7.1. Security Token Replay > > The goal of the Federated Token Binding mechanisms is to prevent > > attackers from exporting and replaying tokens used in protocols > > between the client and Token Consumer, thereby impersonating > > legitimate users and gaining access to protected resources. Bound > > tokens can still be replayed by malware present in the client. In > > order to export the token to another machine and successfully replay > > it, the attacker also needs to export the corresponding private key. > > The Token Binding private key is therefore a high-value asset and > > MUST be strongly protected, ideally by generating it in a hardware > > security module that prevents key export > > > > *Proposed replacement* > 7.1. Security Token Export and Replay The goal of the Federated Token > Binding mechanisms is to prevent attackers from exporting and replaying > tokens used in protocols between the client and Token Consumer, thereby > impersonating legitimate users and gaining access to protected > resources. Bound tokens can still be replayed by malware present in > the client. They can also be exported and re-used when a client > collaborates with another client. In order to export the token to > another machine and successfully use it, a client may export the corr= esponding > private key to the other client or may perform all the necessary > computations for the other client without exporting the corresponding > private. Protecting the Token Binding private key, e.g. in a hardware > security module that prevents key export is a good practice, but in > such a case, it is inefficient to counter the clients collaboration > attack. > > Some other changes might need to be done in the same spirit. > > > > Denis > > > > Thanks. > > > > On Feb 16, 2017, at 5:26 PM, Andrei Popov > wrote: > > The updated versions of TBPROTO, TBNEGO and HTTPSTB have been uploaded: > https://tools.ietf.org/html/draft-ietf-tokbind-protocol-12 > https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-07 > https://tools.ietf.org/html/draft-ietf-tokbind-https-08 > > The updated documents address the comments from the unbearable mailing > list and GitHub. > > Cheers, > > Andrei > _______________________________________________ > 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 > > > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --001a11428b3a9eb8e80548acc82f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think that we don't need to do any more than add a s= entence to 7.1 of TBPROTO saying something along the lines of "the Tok= en Binding protocol does not prevent cooperating clients from sharing a bou= nd token" (i.e. what Andrei said). I'm also fine if we don't a= dd anything.

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearabl= e


--001a11428b3a9eb8e80548acc82f-- From nobody Thu Feb 16 13:54:44 2017 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 E40A91296F5 for ; Thu, 16 Feb 2017 13:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 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=-1.887, 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 FKqo59bEigbq for ; Thu, 16 Feb 2017 13:54:39 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0106.outbound.protection.outlook.com [104.47.42.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0FDD1296D2 for ; Thu, 16 Feb 2017 13:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DMDty7YXJcttAzv9H7uowkM3LVa5lrmZNe5MqGNdf14=; b=kcOedl+KsuWduNIGVD+LO+0e1Tzkmbs5XgrRQrT/ZG5VY0gVkMmJXTz97v7piEsI65smXwDZz/PKQXqB7ScJ35/2DZWw/mp58piM98woMHo1Mmp+KugpvRNHRe5KHgeiN4zR4Bdor9nNpV0nG/EAxKpbehX+zJmwVrl3NmPxtGo= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 16 Feb 2017 21:54:37 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.034; Thu, 16 Feb 2017 21:54:37 +0000 From: Andrei Popov To: John Bradley Thread-Topic: [Unbearable] Updated I-Ds Thread-Index: AdKIki7cdjaoT3T9Qfa4KQrr2Z1KPgAAsoQAAAB1bAAAANOA0AAAxdWAAABaXhA= Date: Thu, 16 Feb 2017 21:54:37 +0000 Message-ID: References: <2A56853E-C785-48CF-A75E-5F61683B1035@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: e509b9fb-cb8f-4e0e-bbff-08d456b666f0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0842; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 7:Ah+oRpNnsiwDvewKM4DbTPYFFXXyUmC4CHx7vtLhV0aeqA9xVu7m6GUJhJlgILcCL4mvBovmebs8RfXXrQ4jqkGt2kjF349efWfKICZd/bQRYTO65m3HHaBh6r6juZ+VfXOhSyK80rfrpnPYLHS8OKan27YbSS6UuMnAZK4prp/IVTTaUpVWzjzCoz/ig50GtEbmpw39U9WdmmVu5GAGkR7pXkn9qM6qslVSawyKXnJwcTXQc1j/E2nruCyZg8OQ+4Flrq/kgbTTLpBRoGdsVQ0HkqjK+HkWSTIks598yda8xfW9lMnTVhiRaMcQTC8x9MdK0iyUjDHzSQ8vEW856MF3puouQozgM+n4rVursvs= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(191636701735510)(158342451672863)(192374486261705)(21748063052155)(231250463719595); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39410400002)(39850400002)(39860400002)(39840400002)(189002)(377454003)(199003)(24454002)(10710500007)(790700001)(6116002)(2906002)(102836003)(2950100002)(86612001)(33656002)(4326007)(54356999)(3660700001)(6916009)(76176999)(2900100001)(50986999)(15650500001)(122556002)(3280700002)(53546006)(236005)(2420400007)(9686003)(93886004)(53936002)(110136004)(55016002)(101416001)(54906002)(6246003)(38730400002)(229853002)(6306002)(54896002)(19609705001)(25786008)(5660300001)(7736002)(8936002)(189998001)(106356001)(7110500001)(97736004)(99286003)(105586002)(92566002)(81156014)(68736007)(81166006)(6506006)(77096006)(86362001)(7696004)(5005710100001)(7906003)(10090500001)(389900003)(6436002)(606005)(10290500002)(74316002)(8990500004)(8676002)(15866825005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842353B2964E7E952B38DF38C5A0CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2017 21:54:37.5296 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Cc: IETF TokBind WG , Denis Subject: Re: [Unbearable] Updated I-Ds 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: Thu, 16 Feb 2017 21:54:42 -0000 --_000_CY1PR0301MB0842353B2964E7E952B38DF38C5A0CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U291bmRzIGdvb2QsIEnigJlsbCBhZGQgbGFuZ3VhZ2UgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIHRvIGFkZHJlc3MgdGhpcyBhbmQgdXBsb2FkIGFub3RoZXIgdmVyc2lvbiB0b2RheS4N Cg0KRnJvbTogSm9obiBCcmFkbGV5IFttYWlsdG86dmU3anRiQHZlN2p0Yi5jb21dDQpTZW50OiBU aHVyc2RheSwgRmVicnVhcnkgMTYsIDIwMTcgMTo0MCBQTQ0KVG86IEFuZHJlaSBQb3BvdiA8QW5k cmVpLlBvcG92QG1pY3Jvc29mdC5jb20+DQpDYzogRGVuaXMgPGRlbmlzLmlldGZAZnJlZS5mcj47 IElFVEYgVG9rQmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVW5i ZWFyYWJsZV0gVXBkYXRlZCBJLURzDQoNCkkgc3VzcGVjdCBpdCBpcyBqdXN0IG9uZSBvZiB0aG9z ZSB0aGluZ3Mgd2UgYWxsIHRoaW5rIGlzIHNlbGYgZXZpZGVudC4NCg0KSSBkb27igJl0IHRoaW5r IGhhdmluZyBhIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gd2lsbCBodXJ0IGFueXRoaW5nLg0KDQpK b2huIEIuDQpPbiBGZWIgMTYsIDIwMTcsIGF0IDY6MjkgUE0sIEFuZHJlaSBQb3BvdiA8QW5kcmVp LlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4g d3JvdGU6DQoNCkhpIERlbmlzLA0KDQpJIGRvbuKAmXQgbWluZCBhZGRpbmcgbGFuZ3VhZ2UgKHBy b2JhYmx5IGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucykgc2F5aW5nIHRoYXQgdGhlIFRv a2VuIEJpbmRpbmcgcHJvdG9jb2wgZG9lcyBub3QgcHJldmVudCBjb29wZXJhdGluZyBjbGllbnRz IGZyb20gc2hhcmluZyBhIGJvdW5kIHRva2VuLg0KU28gZmFyIEkgZG8gbm90IHNlbnNlIG11Y2gg ZW50aHVzaWFzbSBmb3IgdGhpcyBpbiB0aGUgV0cgdGhvdWdo4oCmDQoNCkNoZWVycywNCg0KQW5k cmVpDQoNCkZyb206IERlbmlzIFttYWlsdG86ZGVuaXMuaWV0ZkBmcmVlLmZyXQ0KU2VudDogVGh1 cnNkYXksIEZlYnJ1YXJ5IDE2LCAyMDE3IDEyOjU0IFBNDQpUbzogSm9obiBCcmFkbGV5IDx2ZTdq dGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PjsgQW5kcmVpIFBvcG92IDxB bmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5j b20+Pg0KQ2M6IElFVEYgVG9rQmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86dW5i ZWFyYWJsZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFVwZGF0ZWQgSS1E cw0KDQpBbmRyZWksDQoNCllvdSBzYWlkOg0KVGhlIHVwZGF0ZWQgZG9jdW1lbnRzIGFkZHJlc3Mg dGhlIGNvbW1lbnRzIGZyb20gdGhlIHVuYmVhcmFibGUgbWFpbGluZyBsaXN0Lg0KSSBkb24ndCBi ZWxpZXZlIHRoYXQgdGhpcyBpcyB0aGUgY2FzZS4gSSBjb3B5IGFuZCBwYXN0ZSBhIG1lc3NhZ2Ug c2VudCBvbiBXZWQsIDIxIGRlYyAyMDE2IGF0IDExOjE2OjUyDQp1bmRlciB0aGUgdG9waWM6ICJX R0xDIG9uIGRyYWZ0LWlldGYtdG9rYmluZC1odHRwcyIuDQoNCkRlbmlzDQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KDQpPbiBOb3ZlbWJlciAzMSwgMjAxNiwgSSBzZW50IGEgbWVz c2FnZSBzYXlpbmc6DQpUaGlzIHNldCBvZiBkb2N1bWVudHMgZmFpbGVkIHRvIG1lZXQgdGhlIHRl cm1zIG9mIHJlZmVyZW5jZXMgb2YgdGhlIFdHIGNoYXJ0ZXIuDQoNCkl0IGlzIG5vdCByZXNpc3Rh bnQgdG8gdGhlIEFCQyBhdHRhY2sgKEFsaWNlIGFuZCBCb2IgY29sbHVzaW9uIGF0dGFjaykuDQpJ biB0aGlzIGF0dGFjayBCb2Igd2hvIGlzIG9sZGVyIHRoYW4gMTggY29sbG9ib3JhdGVzIHdpdGgg QWxpY2UgYW5kIHRyYW5zbWl0cyBhIHRva2VuIHRvIEFsaWNlDQp3aG8gaXMgb25seSAxNCBzbyB0 aGF0IHNoZSBjYW4gZGVtb25zdHJhdCB0byBhIFJTIHRoYXQgc2hlIGlzIG9sZGVyIHRoYW4gMTgu DQoNClRoaXMga2luZCBvZiBhdHRhY2sgaXMgbm90IGV2ZW4gbWVudGlvbm5lZCBpbiB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbi4NCg0KVGhpcyBzZXQgb2YgZG9jdW1lbnRzIHNo b3VsZCBub3QgYmUgcHJvZ3Jlc3NlZCB0byBJRVRGIGxhc3QgY2FsbCB1bmxlc3MgdGhlIGF0dGFj ayBjYW4gYmUgY291bnRlcmVkLg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KVGhlcmUgYXJlIHR3byBv cHRpb25zOg0KDQpPcHRpb24gQTogZHJvcCB0aGlzIHNlcmllcyBvZiBkb2N1bWVudHMsIGkuZS4g Og0KDQogIGRyYWZ0LWlldGYtdG9rYmluZC1wcm90b2NvbA0KICBkcmFmdC1pZXRmLXRva2JpbmQt aHR0cHMNCiAgZHJhZnQtaWV0Zi10b2tiaW5kLW5lZ290aWF0aW9uDQoNCm9yDQpPcHRpb24gQjog Y2xlYXJseSBtZW50aW9uIHRoYXQgdGhlIEFCQyBhdHRhY2sgY2Fubm90IGJlIGNvdW50ZXJlZCB1 c2luZyBUTFMgYmluZGluZy4NCg0KSW4gY2FzZSwgdGhlIGxhdHRlciBkZWNpc2lvbiB3b3VsZCBi ZSB0YWtlbiBieSB0aGUgV0csIEkgcHJvcG9zZSBhIGZldyB0ZXh0IHJlcGxhY2VtZW50cy4NCkN1 cnJlbnQgdGV4dDoNCg0KDQoNCiBBYnN0cmFjdA0KDQoNCg0KICAgICAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIGEgY29sbGVjdGlvbiBvZiBtZWNoYW5pc21zIHRoYXQgYWxsb3cgSFRUUA0KDQog ICBzZXJ2ZXJzIHRvIGNyeXB0b2dyYXBoaWNhbGx5IGJpbmQgYXV0aGVudGljYXRpb24gdG9rZW5z IChzdWNoIGFzDQoNCiAgIGNvb2tpZXMgYW5kIE9BdXRoIHRva2VucykgdG8gVExTIFtSRkM1MjQ2 PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ2Pl0gY29ubmVjdGlvbnMuDQoNCg0K DQogICAgICBXZSBkZXNjcmliZSBib3RoIF9maXJzdC1wYXJ0eV8gYW5kIF9mZWRlcmF0ZWRfIHNj ZW5hcmlvcy4gIEluIGENCg0KICAgZmlyc3QtcGFydHkgc2NlbmFyaW8sIGFuIEhUVFAgc2VydmVy IGlzIGFibGUgdG8gY3J5cHRvZ3JhcGhpY2FsbHkNCg0KICAgYmluZCB0aGUgc2VjdXJpdHkgdG9r ZW5zIGl0IGlzc3VlcyB0byBhIGNsaWVudCwgYW5kIHdoaWNoIHRoZSBjbGllbnQNCg0KICAgc3Vi c2VxdWVudGx5IHJldHVybnMgdG8gdGhlIHNlcnZlciwgdG8gdGhlIFRMUyBjb25uZWN0aW9uIGJl dHdlZW4gdGhlDQoNCiAgIGNsaWVudCBhbmQgc2VydmVyLiAgU3VjaCBib3VuZCBzZWN1cml0eSB0 b2tlbnMgYXJlIHByb3RlY3RlZCBmcm9tDQoNCiAgIG1pc3VzZSBzaW5jZSB0aGUgc2VydmVyIGNh biBnZW5lcmFsbHkgZGV0ZWN0IGlmIHRoZXkgYXJlIHJlcGxheWVkDQoNCiAgIGluYXBwcm9wcmlh dGVseSwgZS5nLiwgb3ZlciBvdGhlciBUTFMgY29ubmVjdGlvbnMuDQoNCg0KDQogICBGZWRlcmF0 ZWQgdG9rZW4gYmluZGluZ3MsIG9uIHRoZSBvdGhlciBoYW5kLCBhbGxvdyBzZXJ2ZXJzIHRvDQoN CiAgIGNyeXB0b2dyYXBoaWNhbGx5IGJpbmQgc2VjdXJpdHkgdG9rZW5zIHRvIGEgVExTIGNvbm5l Y3Rpb24gdGhhdCB0aGUNCg0KICAgY2xpZW50IGhhcyB3aXRoIGEgX2RpZmZlcmVudF8gc2VydmVy IHRoYW4gdGhlIG9uZSBpc3N1aW5nIHRoZSB0b2tlbi4NCg0KDQoNCiAgIFRoaXMgSW50ZXJuZXQt RHJhZnQgaXMgYSBjb21wYW5pb24gZG9jdW1lbnQgdG8gVGhlIFRva2VuIEJpbmRpbmcNCg0KICAg UHJvdG9jb2wgW0ktRC5pZXRmLXRva2JpbmQtcHJvdG9jb2w8aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1odHRwcy0wNyNyZWYtSS1ELmlldGYtdG9rYmluZC1w cm90b2NvbD5dDQoNCg0KDQoNCg0KUHJvcG9zZWQgYWRkaXRpb25zIGluIGJsdWUNCg0KDQoNCkFi c3RyYWN0DQoNCg0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIGNvbGxlY3Rpb24gb2Yg bWVjaGFuaXNtcyB0aGF0IGFsbG93IEhUVFANCg0KICAgc2VydmVycyB0byBjcnlwdG9ncmFwaGlj YWxseSBiaW5kIGF1dGhlbnRpY2F0aW9uIHRva2VucyAoc3VjaCBhcw0KDQogICBjb29raWVzIGFu ZCBPQXV0aCB0b2tlbnMpIHRvIFRMUyBbUkZDNTI0NjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNTI0Nj5dIGNvbm5lY3Rpb25zLg0KDQoNCg0KICAgV2UgZGVzY3JpYmUgYm90aCBfZmly c3QtcGFydHlfIGFuZCBfZmVkZXJhdGVkXyBzY2VuYXJpb3MuICBJbiBhDQoNCiAgIGZpcnN0LXBh cnR5IHNjZW5hcmlvLCBhbiBIVFRQIHNlcnZlciBpcyBhYmxlIHRvIGNyeXB0b2dyYXBoaWNhbGx5 DQoNCiAgIGJpbmQgdGhlIHNlY3VyaXR5IHRva2VucyBpdCBpc3N1ZXMgdG8gYSBjbGllbnQsIGFu ZCB3aGljaCB0aGUgY2xpZW50DQoNCiAgIHN1YnNlcXVlbnRseSByZXR1cm5zIHRvIHRoZSBzZXJ2 ZXIsIHRvIHRoZSBUTFMgY29ubmVjdGlvbiBiZXR3ZWVuIHRoZQ0KDQogICBjbGllbnQgYW5kIHNl cnZlci4gIFN1Y2ggYm91bmQgc2VjdXJpdHkgdG9rZW5zIGFyZSBwcm90ZWN0ZWQgZnJvbQ0KDQog ICBtaXN1c2Ugc2luY2UgdGhlIHNlcnZlciBjYW4gZ2VuZXJhbGx5IGRldGVjdCBpZiB0aGV5IGFy ZSByZXBsYXllZA0KDQogICBpbmFwcHJvcHJpYXRlbHksIGUuZy4sIG92ZXIgb3RoZXIgVExTIGNv bm5lY3Rpb25zLg0KDQoNCg0KICAgSG93ZXZlciwgdGhlIGJpbmRpbmcgYSBzZWN1cml0eSB0b2tl biB0byBhIFRMUyBjb25uZWN0aW9uIGlzDQoNCiAgIHVuYWJsZSB0byBjb3VudGVyIGNvbGxhYm9y YXRpb24gYXR0YWNrcyBiZXR3ZWVuIHR3byBjbGllbnRzIHNpbmNlDQoNCiAgIG9uZSBjbGllbnQg Y2FuIGNvbXB1dGUgdGhlIG5lY2Vzc2FyeSBpbmZvcm1hdGlvbiBmb3IgdGhlIG90aGVyDQoNCiAg IGNsaWVudCB3aXRob3V0IHRoZSBuZWVkIHRvIHJlbGVhc2UgaGlzIGtleShzKSB0byB0aGUgb3Ro ZXIgY2xpZW50Lg0KDQoNCg0KICAgRm9yIGFuIGVmZmVjdGl2ZSBwcm90ZWN0aW9uIGFnYWluc3Qg Y29sbGFib3JhdGlvbiBhdHRhY2tzLCBhbg0KDQogICBhcHByb3ByaWF0ZSBmb3JtYXQgb2YgdGhl IHNlY3VyaXR5IHRva2VuLCB0b2dldGhlciB3aXRoIGFuDQoNCiAgICBhcHByb3ByaWF0ZSB2YWxp ZGF0aW9uIG9mIHNvbWUgZmllbGRzIG9mIGl0LCBtdXN0IGJlIHVzZWQuDQoNCg0KDQogICBGZWRl cmF0ZWQgdG9rZW4gYmluZGluZ3MsIG9uIHRoZSBvdGhlciBoYW5kLCBhbGxvdyBzZXJ2ZXJzIHRv DQoNCiAgIGNyeXB0b2dyYXBoaWNhbGx5IGJpbmQgc2VjdXJpdHkgdG9rZW5zIHRvIGEgVExTIGNv bm5lY3Rpb24gdGhhdCB0aGUNCg0KICAgY2xpZW50IGhhcyB3aXRoIGEgX2RpZmZlcmVudF8gc2Vy dmVyIHRoYW4gdGhlIG9uZSBpc3N1aW5nIHRoZSB0b2tlbi4NCg0KDQoNCiAgIFRoaXMgSW50ZXJu ZXQtRHJhZnQgaXMgYSBjb21wYW5pb24gZG9jdW1lbnQgdG8gVGhlIFRva2VuIEJpbmRpbmcNCg0K ICAgUHJvdG9jb2wgW0ktRC5pZXRmLXRva2JpbmQtcHJvdG9jb2w8aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1odHRwcy0wNyNyZWYtSS1ELmlldGYtdG9rYmlu ZC1wcm90b2NvbD5dDQoNCg0KDQoNCkN1cnJlbnQgdGV4dDoNCjcuMS4gU2VjdXJpdHkgVG9rZW4g UmVwbGF5DQoNCiAgIFRoZSBnb2FsIG9mIHRoZSBGZWRlcmF0ZWQgVG9rZW4gQmluZGluZyBtZWNo YW5pc21zIGlzIHRvIHByZXZlbnQNCg0KICAgYXR0YWNrZXJzIGZyb20gZXhwb3J0aW5nIGFuZCBy ZXBsYXlpbmcgdG9rZW5zIHVzZWQgaW4gcHJvdG9jb2xzDQoNCiAgIGJldHdlZW4gdGhlIGNsaWVu dCBhbmQgVG9rZW4gQ29uc3VtZXIsIHRoZXJlYnkgaW1wZXJzb25hdGluZw0KDQogICBsZWdpdGlt YXRlIHVzZXJzIGFuZCBnYWluaW5nIGFjY2VzcyB0byBwcm90ZWN0ZWQgcmVzb3VyY2VzLiAgQm91 bmQNCg0KICAgdG9rZW5zIGNhbiBzdGlsbCBiZSByZXBsYXllZCBieSBtYWx3YXJlIHByZXNlbnQg aW4gdGhlIGNsaWVudC4gIEluDQoNCiAgIG9yZGVyIHRvIGV4cG9ydCB0aGUgdG9rZW4gdG8gYW5v dGhlciBtYWNoaW5lIGFuZCBzdWNjZXNzZnVsbHkgcmVwbGF5DQoNCiAgIGl0LCB0aGUgYXR0YWNr ZXIgYWxzbyBuZWVkcyB0byBleHBvcnQgdGhlIGNvcnJlc3BvbmRpbmcgcHJpdmF0ZSBrZXkuDQoN CiAgIFRoZSBUb2tlbiBCaW5kaW5nIHByaXZhdGUga2V5IGlzIHRoZXJlZm9yZSBhIGhpZ2gtdmFs dWUgYXNzZXQgYW5kDQoNCiAgIE1VU1QgYmUgc3Ryb25nbHkgcHJvdGVjdGVkLCBpZGVhbGx5IGJ5 IGdlbmVyYXRpbmcgaXQgaW4gYSBoYXJkd2FyZQ0KDQogICBzZWN1cml0eSBtb2R1bGUgdGhhdCBw cmV2ZW50cyBrZXkgZXhwb3J0DQoNCg0KUHJvcG9zZWQgcmVwbGFjZW1lbnQNCjcuMS4gU2VjdXJp dHkgVG9rZW4gRXhwb3J0IGFuZCBSZXBsYXkNCg0KICAgVGhlIGdvYWwgb2YgdGhlIEZlZGVyYXRl ZCBUb2tlbiBCaW5kaW5nIG1lY2hhbmlzbXMgaXMgdG8gcHJldmVudA0KICAgYXR0YWNrZXJzIGZy b20gZXhwb3J0aW5nIGFuZCByZXBsYXlpbmcgdG9rZW5zIHVzZWQgaW4gcHJvdG9jb2xzDQogICBi ZXR3ZWVuIHRoZSBjbGllbnQgYW5kIFRva2VuIENvbnN1bWVyLCB0aGVyZWJ5IGltcGVyc29uYXRp bmcNCiAgIGxlZ2l0aW1hdGUgdXNlcnMgYW5kIGdhaW5pbmcgYWNjZXNzIHRvIHByb3RlY3RlZCBy ZXNvdXJjZXMuICBCb3VuZA0KICAgdG9rZW5zIGNhbiBzdGlsbCBiZSByZXBsYXllZCBieSBtYWx3 YXJlIHByZXNlbnQgaW4gdGhlIGNsaWVudC4NCiAgIFRoZXkgY2FuIGFsc28gYmUgZXhwb3J0ZWQg YW5kIHJlLXVzZWQgd2hlbiBhIGNsaWVudCBjb2xsYWJvcmF0ZXMNCiAgd2l0aCBhbm90aGVyIGNs aWVudC4gIEluIG9yZGVyIHRvIGV4cG9ydCB0aGUgdG9rZW4gdG8gYW5vdGhlcg0KICAgbWFjaGlu ZSBhbmQgc3VjY2Vzc2Z1bGx5IHVzZSBpdCwgYSBjbGllbnQgbWF5IGV4cG9ydCB0aGUNCiAgIGNv cnJlc3BvbmRpbmcgcHJpdmF0ZSBrZXkgdG8gdGhlIG90aGVyIGNsaWVudCBvciBtYXkgcGVyZm9y bSBhbGwNCiAgIHRoZSBuZWNlc3NhcnkgY29tcHV0YXRpb25zIGZvciB0aGUgb3RoZXIgY2xpZW50 IHdpdGhvdXQgZXhwb3J0aW5nDQogICB0aGUgY29ycmVzcG9uZGluZyBwcml2YXRlLiAgUHJvdGVj dGluZyB0aGUgVG9rZW4gQmluZGluZyBwcml2YXRlDQogICBrZXksIGUuZy4gaW4gYSBoYXJkd2Fy ZSBzZWN1cml0eSBtb2R1bGUgdGhhdCBwcmV2ZW50cyBrZXkgZXhwb3J0IGlzDQogICBhIGdvb2Qg cHJhY3RpY2UsIGJ1dCBpbiBzdWNoIGEgY2FzZSwgaXQgaXMgaW5lZmZpY2llbnQgdG8gY291bnRl cg0KICAgdGhlIGNsaWVudHMgY29sbGFib3JhdGlvbiBhdHRhY2suDQoNClNvbWUgb3RoZXIgY2hh bmdlcyBtaWdodCBuZWVkIHRvIGJlIGRvbmUgaW4gdGhlIHNhbWUgc3Bpcml0Lg0KDQoNCg0KRGVu aXMNCg0KVGhhbmtzLg0KDQoNCk9uIEZlYiAxNiwgMjAxNywgYXQgNToyNiBQTSwgQW5kcmVpIFBv cG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jv c29mdC5jb20+PiB3cm90ZToNCg0KVGhlIHVwZGF0ZWQgdmVyc2lvbnMgb2YgVEJQUk9UTywgVEJO RUdPIGFuZCBIVFRQU1RCIGhhdmUgYmVlbiB1cGxvYWRlZDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQtcHJvdG9jb2wtMTINCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQtbmVnb3RpYXRpb24tMDcNCmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQtaHR0cHMtMDgNCg0KVGhlIHVwZGF0 ZWQgZG9jdW1lbnRzIGFkZHJlc3MgdGhlIGNvbW1lbnRzIGZyb20gdGhlIHVuYmVhcmFibGUgbWFp bGluZyBsaXN0IGFuZCBHaXRIdWIuDQoNCkNoZWVycywNCg0KQW5kcmVpDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVW5iZWFyYWJsZSBtYWlsaW5nIGxp c3QNClVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUNCg0KDQoNCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClVuYmVh cmFibGUgbWFpbGluZyBsaXN0DQoNClVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOlVuYmVhcmFi bGVAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5i ZWFyYWJsZQ0KDQoNCg== --_000_CY1PR0301MB0842353B2964E7E952B38DF38C5A0CY1PR0301MB0842_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmgzDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDMgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEzLjVwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFu LmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQt c3BhY2U7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bh bi5IZWFkaW5nM0NoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAzIjsNCglmb250LWZh bWlseToiQ2FsaWJyaSBMaWdodCIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0RDc4O30NCnNwYW4u RW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+U291bmRzIGdvb2QsIEnigJlsbCBhZGQgbGFuZ3VhZ2UgaW4gdGhl IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRvIGFkZHJlc3MgdGhpcyBhbmQgdXBsb2FkIGFub3Ro ZXIgdmVyc2lvbiB0b2RheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKb2huIEJyYWRs ZXkgW21haWx0bzp2ZTdqdGJAdmU3anRiLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgRmVicnVhcnkgMTYsIDIwMTcgMTo0MCBQTTxicj4NCjxiPlRvOjwvYj4gQW5kcmVpIFBvcG92 ICZsdDtBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IERlbmlz ICZsdDtkZW5pcy5pZXRmQGZyZWUuZnImZ3Q7OyBJRVRGIFRva0JpbmQgV0cgJmx0O3VuYmVhcmFi bGVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0gVXBk YXRlZCBJLURzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBzdXNwZWN0IGl0IGlzIGp1c3Qgb25lIG9mIHRob3NlIHRoaW5ncyB3ZSBhbGwgdGhpbmsgaXMg c2VsZiBldmlkZW50LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBkb27igJl0IHRoaW5rIGhhdmluZyBhIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gd2lsbCBo dXJ0IGFueXRoaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Kb2huIEIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gRmViIDE2LCAyMDE3LCBhdCA2OjI5IFBNLCBBbmRyZWkgUG9wb3Yg Jmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSI+QW5kcmVpLlBv cG92QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkhpIERlbmlzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkg ZG9u4oCZdCBtaW5kIGFkZGluZyBsYW5ndWFnZSAocHJvYmFibHkgaW4gdGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zKSBzYXlpbmcgdGhhdCB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCBkb2Vz IG5vdCBwcmV2ZW50IGNvb3BlcmF0aW5nIGNsaWVudHMNCiBmcm9tIHNoYXJpbmcgYSBib3VuZCB0 b2tlbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TbyBmYXIg SSBkbyBub3Qgc2Vuc2UgbXVjaCBlbnRodXNpYXNtIGZvciB0aGlzIGluIHRoZSBXRyB0aG91Z2ji gKY8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaGVlcnMsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kcmVpPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EZW5pcw0KIFs8 YSBocmVmPSJtYWlsdG86ZGVuaXMuaWV0ZkBmcmVlLmZyIj5tYWlsdG86ZGVuaXMuaWV0ZkBmcmVl LmZyPC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPlRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxNyAxMjo1NCBQTTxicj4NCjxiPlRv OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Sm9o biBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2 ZTdqdGIuY29tPC9hPiZndDs7IEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJl aS5Qb3BvdkBtaWNyb3NvZnQuY29tIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5JRVRGIFRva0JpbmQgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzp1bmJlYXJhYmxlQGll dGYub3JnIj51bmJlYXJhYmxlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtVbmJl YXJhYmxlXSBVcGRhdGVkIEktRHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5BbmRyZWksPHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxicj4NCllvdSBz YWlkOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzMzMzRkYiPlRo ZSB1cGRhdGVkIGRvY3VtZW50cyBhZGRyZXNzIHRoZSBjb21tZW50cyBmcm9tIHRoZSB1bmJlYXJh YmxlIG1haWxpbmcgbGlzdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+SSBkb24ndCBiZWxpZXZlIHRoYXQgdGhpcyBpcyB0aGUgY2FzZS4gSSBjb3B5IGFuZCBwYXN0 ZSBhIG1lc3NhZ2Ugc2VudCBvbiBXZWQsIDIxIGRlYyAyMDE2IGF0IDExOjE2OjUyPHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCnVuZGVyIHRoZSB0 b3BpYzogJnF1b3Q7V0dMQyBvbiBkcmFmdC1pZXRmLXRva2JpbmQtaHR0cHMmcXVvdDsuPGJyPg0K PGJyPg0KRGVuaXM8YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCjxi cj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5PbiBOb3ZlbWJlciAzMSwgMjAxNiwgSSBzZW50IGEgbWVzc2FnZSBzYXlpbmc6PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3 aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+VGhpcyBzZXQgb2YgZG9jdW1lbnRzIGZhaWxlZCB0byBtZWV0IHRoZSB0ZXJtcyBvZiBy ZWZlcmVuY2VzIG9mIHRoZSBXRyBjaGFydGVyLjxicj4NCjxicj4NCkl0IGlzIG5vdCByZXNpc3Rh bnQgdG8gdGhlIEFCQyBhdHRhY2sgKEFsaWNlIGFuZCBCb2IgY29sbHVzaW9uIGF0dGFjaykuPGJy Pg0KSW4gdGhpcyBhdHRhY2sgQm9iIHdobyBpcyBvbGRlciB0aGFuIDE4IGNvbGxvYm9yYXRlcyB3 aXRoIEFsaWNlIGFuZCB0cmFuc21pdHMgYSB0b2tlbiB0byBBbGljZTxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQp3aG8gaXMgb25seSAxNCBzbyB0 aGF0IHNoZSBjYW4gZGVtb25zdHJhdCB0byBhIFJTIHRoYXQgc2hlIGlzIG9sZGVyIHRoYW4gMTgu PGJyPg0KPGJyPg0KVGhpcyBraW5kIG9mIGF0dGFjayBpcyBub3QgZXZlbiBtZW50aW9ubmVkIGlu IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLjxicj4NCjxicj4NClRoaXMgc2V0 IG9mIGRvY3VtZW50cyBzaG91bGQgbm90IGJlIHByb2dyZXNzZWQgdG8gSUVURiBsYXN0IGNhbGwg dW5sZXNzIHRoZSBhdHRhY2sgY2FuIGJlIGNvdW50ZXJlZC48YnI+DQo8YnI+DQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT08YnI+DQo8YnI+DQpUaGVyZSBhcmUgdHdvIG9wdGlvbnM6PGJyPg0KJm5ic3A7PGJyPg0K PGI+T3B0aW9uIEE8L2I+OiBkcm9wIHRoaXMgc2VyaWVzIG9mIGRvY3VtZW50cywgaS5lLiA6PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxicj4N CiZuYnNwOyBkcmFmdC1pZXRmLXRva2JpbmQtcHJvdG9jb2w8YnI+DQombmJzcDsgZHJhZnQtaWV0 Zi10b2tiaW5kLWh0dHBzPGJyPg0KJm5ic3A7IGRyYWZ0LWlldGYtdG9rYmluZC1uZWdvdGlhdGlv bjxicj4NCjxicj4NCm9yPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNr Z3JvdW5kOndoaXRlIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj5PcHRpb24gQjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjogY2xlYXJseSBtZW50aW9uIHRoYXQg dGhlIEFCQyBhdHRhY2sgY2Fubm90IGJlIGNvdW50ZXJlZCB1c2luZyBUTFMgYmluZGluZy48YnI+ DQo8YnI+DQpJbiBjYXNlLCB0aGUgbGF0dGVyIGRlY2lzaW9uIHdvdWxkIGJlIHRha2VuIGJ5IHRo ZSBXRywgSSBwcm9wb3NlIGEgZmV3IHRleHQgcmVwbGFjZW1lbnRzLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tdG9wOjYuMHB0O2JhY2tn cm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DdXJyZW50IHRleHQ6PC9zcGFuPjwvYj48bzpwPjwv bzpwPjwvcD4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwO0Fic3RyYWN0Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBjb2xsZWN0aW9u IG9mIG1lY2hhbmlzbXMgdGhhdCBhbGxvdyBIVFRQPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Jm5ic3A7Jm5ic3A7IHNlcnZlcnMgdG8gY3J5cHRvZ3JhcGhpY2FsbHkgYmluZCBhdXRoZW50 aWNhdGlvbiB0b2tlbnMgKHN1Y2ggYXM8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz cDsmbmJzcDsgY29va2llcyBhbmQgT0F1dGggdG9rZW5zKSB0byBUTFMgWzxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ2IiB0aXRsZT0iJnF1b3Q7VGhlIFRyYW5zcG9y dCBMYXllciBTZWN1cml0eSAoVExTKSBQcm90b2NvbCBWZXJzaW9uIDEuMiZxdW90OyI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+UkZDNTI0Njwvc3Bhbj48L2E+XSBjb25uZWN0aW9ucy48L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPldlIGRlc2NyaWJlIGJvdGggX2ZpcnN0LXBhcnR5XyBhbmQgX2ZlZGVyYXRl ZF8gc2NlbmFyaW9zLiZuYnNwOyBJbiBhPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7Jm5ic3A7IGZpcnN0LXBhcnR5IHNjZW5hcmlvLCBhbiBIVFRQIHNlcnZlciBpcyBhYmxlIHRv IGNyeXB0b2dyYXBoaWNhbGx5PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5i c3A7IGJpbmQgdGhlIHNlY3VyaXR5IHRva2VucyBpdCBpc3N1ZXMgdG8gYSBjbGllbnQsIGFuZCB3 aGljaCB0aGUgY2xpZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7 IHN1YnNlcXVlbnRseSByZXR1cm5zIHRvIHRoZSBzZXJ2ZXIsIHRvIHRoZSBUTFMgY29ubmVjdGlv biBiZXR3ZWVuIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBj bGllbnQgYW5kIHNlcnZlci4mbmJzcDsgU3VjaCBib3VuZCBzZWN1cml0eSB0b2tlbnMgYXJlIHBy b3RlY3RlZCBmcm9tPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IG1p c3VzZSBzaW5jZSB0aGUgc2VydmVyIGNhbiBnZW5lcmFsbHkgZGV0ZWN0IGlmIHRoZXkgYXJlIHJl cGxheWVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IGluYXBwcm9w cmlhdGVseSwgZS5nLiwgb3ZlciBvdGhlciBUTFMgY29ubmVjdGlvbnMuIDwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw OyZuYnNwOyBGZWRlcmF0ZWQgdG9rZW4gYmluZGluZ3MsIG9uIHRoZSBvdGhlciBoYW5kLCBhbGxv dyBzZXJ2ZXJzIHRvPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IGNy eXB0b2dyYXBoaWNhbGx5IGJpbmQgc2VjdXJpdHkgdG9rZW5zIHRvIGEgVExTIGNvbm5lY3Rpb24g dGhhdCB0aGU8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgY2xpZW50 IGhhcyB3aXRoIGEgX2RpZmZlcmVudF8gc2VydmVyIHRoYW4gdGhlIG9uZSBpc3N1aW5nIHRoZSB0 b2tlbi48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4gJm5ic3A7Jm5ic3A7VGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBhIGNvbXBh bmlvbiBkb2N1bWVudCB0byBUaGUgVG9rZW4gQmluZGluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPiZuYnNwOyZuYnNwOyBQcm90b2NvbCBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1odHRwcy0wNyNyZWYtSS1ELmlldGYtdG9rYmlu ZC1wcm90b2NvbCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SS1ELmlldGYtdG9rYmluZC1w cm90b2NvbDwvc3Bhbj48L2E+XTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Qcm9wb3NlZCBhZGRpdGlvbnMgPHNw YW4gc3R5bGU9ImNvbG9yOmJsdWUiPmluIGJsdWU8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QWJzdHJhY3Q8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4mbmJzcDsgJm5ic3A7Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBjb2xs ZWN0aW9uIG9mIG1lY2hhbmlzbXMgdGhhdCBhbGxvdyBIVFRQPC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Jm5ic3A7Jm5ic3A7IHNlcnZlcnMgdG8gY3J5cHRvZ3JhcGhpY2FsbHkgYmluZCBh dXRoZW50aWNhdGlvbiB0b2tlbnMgKHN1Y2ggYXM8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDsmbmJzcDsgY29va2llcyBhbmQgT0F1dGggdG9rZW5zKSB0byBUTFMgWzxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ2IiB0aXRsZT0iJnF1b3Q7VGhlIFRy YW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSBQcm90b2NvbCBWZXJzaW9uIDEuMiZxdW90OyI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+UkZDNTI0Njwvc3Bhbj48L2E+XSBjb25uZWN0aW9u cy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4gJm5ic3A7Jm5ic3A7V2UgZGVzY3JpYmUgYm90aCBfZmlyc3QtcGFydHlfIGFu ZCBfZmVkZXJhdGVkXyBzY2VuYXJpb3MuJm5ic3A7IEluIGE8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDsmbmJzcDsgZmlyc3QtcGFydHkgc2NlbmFyaW8sIGFuIEhUVFAgc2VydmVy IGlzIGFibGUgdG8gY3J5cHRvZ3JhcGhpY2FsbHk8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDsmbmJzcDsgYmluZCB0aGUgc2VjdXJpdHkgdG9rZW5zIGl0IGlzc3VlcyB0byBhIGNs aWVudCwgYW5kIHdoaWNoIHRoZSBjbGllbnQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDsmbmJzcDsgc3Vic2VxdWVudGx5IHJldHVybnMgdG8gdGhlIHNlcnZlciwgdG8gdGhlIFRM UyBjb25uZWN0aW9uIGJldHdlZW4gdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7Jm5ic3A7IGNsaWVudCBhbmQgc2VydmVyLiZuYnNwOyBTdWNoIGJvdW5kIHNlY3VyaXR5IHRv a2VucyBhcmUgcHJvdGVjdGVkIGZyb208L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz cDsmbmJzcDsgbWlzdXNlIHNpbmNlIHRoZSBzZXJ2ZXIgY2FuIGdlbmVyYWxseSBkZXRlY3QgaWYg dGhleSBhcmUgcmVwbGF5ZWQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJz cDsgaW5hcHByb3ByaWF0ZWx5LCBlLmcuLCBvdmVyIG90aGVyIFRMUyBjb25uZWN0aW9ucy4gPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PC9i PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibHVlIj4mbmJzcDsmbmJzcDsgSG93ZXZl ciwgdGhlIGJpbmRpbmcgYSBzZWN1cml0eSB0b2tlbiB0byBhIFRMUyBjb25uZWN0aW9uIGlzPC9z cGFuPjwvYj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6Ymx1ZSI+Jm5ic3A7Jm5ic3A7 IHVuYWJsZSB0byBjb3VudGVyIGNvbGxhYm9yYXRpb24gYXR0YWNrcyBiZXR3ZWVuIHR3byBjbGll bnRzIHNpbmNlPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6Ymx1ZSI+ Jm5ic3A7Jm5ic3A7IG9uZSBjbGllbnQgY2FuIGNvbXB1dGUgdGhlIG5lY2Vzc2FyeSBpbmZvcm1h dGlvbiBmb3IgdGhlIG90aGVyPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6Ymx1ZSI+Jm5ic3A7Jm5ic3A7IGNsaWVudCB3aXRob3V0IHRoZSBuZWVkIHRvIHJlbGVhc2Ug aGlzIGtleShzKSB0byB0aGUgb3RoZXIgY2xpZW50Ljwvc3Bhbj48L2I+PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48L2I+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOmJsdWUiPiZuYnNwOyZuYnNwOyBGb3IgYW4gZWZmZWN0aXZlIHByb3RlY3Rp b24gYWdhaW5zdCBjb2xsYWJvcmF0aW9uIGF0dGFja3MsIGFuPC9zcGFuPjwvYj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6Ymx1ZSI+Jm5ic3A7Jm5ic3A7IGFwcHJvcHJpYXRlIGZvcm1h dCBvZiB0aGUgc2VjdXJpdHkgdG9rZW4sIHRvZ2V0aGVyIHdpdGggYW48L3NwYW4+PC9iPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsdWUiPiZuYnNwOyA8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOmJsdWUiPiZuYnNwOyZuYnNwO2FwcHJvcHJpYXRlIHZhbGlkYXRpb24g b2Ygc29tZSBmaWVsZHMgb2YgaXQsIG11c3QgYmUgdXNlZC48L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IEZlZGVyYXRlZCB0b2tl biBiaW5kaW5ncywgb24gdGhlIG90aGVyIGhhbmQsIGFsbG93IHNlcnZlcnMgdG88L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgY3J5cHRvZ3JhcGhpY2FsbHkgYmluZCBz ZWN1cml0eSB0b2tlbnMgdG8gYSBUTFMgY29ubmVjdGlvbiB0aGF0IHRoZTwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBjbGllbnQgaGFzIHdpdGggYSBfZGlmZmVyZW50 XyBzZXJ2ZXIgdGhhbiB0aGUgb25lIGlzc3VpbmcgdGhlIHRva2VuLjwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZu YnNwOyBUaGlzIEludGVybmV0LURyYWZ0IGlzIGEgY29tcGFuaW9uIGRvY3VtZW50IHRvIFRoZSBU b2tlbiBCaW5kaW5nIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDtQcm90b2NvbCBbPGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1odHRwcy0wNyNyZWYtSS1ELmlldGYt dG9rYmluZC1wcm90b2NvbCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SS1ELmlldGYtdG9r YmluZC1wcm90b2NvbDwvc3Bhbj48L2E+XTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tdG9wOjYuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DdXJy ZW50IHRleHQ6PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tdG9wOjYuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PjcuMS4gU2VjdXJpdHkgVG9rZW4gUmVwbGF5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZSBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyBUaGUgZ29hbCBvZiB0aGUgRmVkZXJhdGVkIFRva2VuIEJpbmRpbmcgbWVjaGFu aXNtcyBpcyB0byBwcmV2ZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5i c3A7IGF0dGFja2VycyBmcm9tIGV4cG9ydGluZyBhbmQgcmVwbGF5aW5nIHRva2VucyB1c2VkIGlu IHByb3RvY29scyA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz cDtiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIFRva2VuIENvbnN1bWVyLCB0aGVyZWJ5IGltcGVyc29u YXRpbmc8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgbGVnaXRpbWF0 ZSB1c2VycyBhbmQgZ2FpbmluZyBhY2Nlc3MgdG8gcHJvdGVjdGVkIHJlc291cmNlcy4mbmJzcDsg Qm91bmQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgdG9rZW5zIGNh biBzdGlsbCBiZSByZXBsYXllZCBieSBtYWx3YXJlIHByZXNlbnQgaW4gdGhlIGNsaWVudC4mbmJz cDsgPHNwYW4gc3R5bGU9ImNvbG9yOiM2NjY2NjYiPkluPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7Jm5ic3A7IG9yZGVyIHRvIGV4cG9ydCB0 aGUgdG9rZW4gdG8gYW5vdGhlciBtYWNoaW5lIGFuZCBzdWNjZXNzZnVsbHkgcmVwbGF5PC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojNjY2NjY2Ij4mbmJzcDsmbmJzcDsgaXQsIHRo ZSBhdHRhY2tlciBhbHNvIG5lZWRzIHRvIGV4cG9ydCB0aGUgY29ycmVzcG9uZGluZyBwcml2YXRl IGtleS48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiM2NjY2NjYiPiZuYnNwOyZu YnNwOyBUaGUgVG9rZW4gQmluZGluZyBwcml2YXRlIGtleSBpcyB0aGVyZWZvcmUgYSBoaWdoLXZh bHVlIGFzc2V0IGFuZDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzY2NjY2NiI+ Jm5ic3A7Jm5ic3A7IE1VU1QgYmUgc3Ryb25nbHkgcHJvdGVjdGVkLCBpZGVhbGx5IGJ5IGdlbmVy YXRpbmcgaXQgaW4gYSBoYXJkd2FyZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 IzY2NjY2NiI+Jm5ic3A7Jm5ic3A7IHNlY3VyaXR5IG1vZHVsZSB0aGF0IHByZXZlbnRzIGtleSBl eHBvcnQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6Ni4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPlByb3Bvc2VkIHJlcGxhY2VtZW50PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwv cD4NCjxoMyBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjcuMS4gU2VjdXJpdHkg VG9rZW48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsdWUiPkV4cG9ydCBhbmQ8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPlJlcGxheTwvc3Bhbj48bzpwPjwvbzpwPjwvaDM+DQo8aDMgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv aDM+DQo8aDMgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg VGhlIGdvYWwgb2YgdGhlIEZlZGVyYXRlZCBUb2tlbiBCaW5kaW5nIG1lY2hhbmlzbXMgaXMgdG8g cHJldmVudDwvc3Bhbj48bzpwPjwvbzpwPjwvaDM+DQo8aDMgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYXR0YWNrZXJzIGZyb20gZXhwb3J0aW5nIGFuZCBy ZXBsYXlpbmcgdG9rZW5zIHVzZWQgaW4gcHJvdG9jb2xzPC9zcGFuPjxvOnA+PC9vOnA+PC9oMz4N CjxoMyBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBiZXR3 ZWVuIHRoZSBjbGllbnQgYW5kIFRva2VuIENvbnN1bWVyLCB0aGVyZWJ5IGltcGVyc29uYXRpbmc8 L3NwYW4+PG86cD48L286cD48L2gzPg0KPGgzIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IGxlZ2l0aW1hdGUgdXNlcnMgYW5kIGdhaW5pbmcgYWNjZXNzIHRv IHByb3RlY3RlZCByZXNvdXJjZXMuJm5ic3A7IEJvdW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9oMz4N CjxoMyBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0b2tl bnMgY2FuIHN0aWxsIGJlIHJlcGxheWVkIGJ5IG1hbHdhcmUgcHJlc2VudCBpbiB0aGUgY2xpZW50 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvaDM+DQo8aDMgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPiZuYnNwO1RoZXkgY2FuIGFsc28gYmUgZXhw b3J0ZWQgYW5kIHJlLXVzZWQgd2hlbiBhIGNsaWVudCBjb2xsYWJvcmF0ZXM8L3NwYW4+PC9zcGFu PjxvOnA+PC9vOnA+PC9oMz4NCjxoMyBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6Ymx1ZSI+Jm5ic3A7Jm5ic3A7d2l0aCBhbm90aGVyIGNsaWVudC4mbmJzcDsgSW4gb3Jk ZXIgdG8gZXhwb3J0IHRoZSB0b2tlbiB0byBhbm90aGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9oMz4N CjxoMyBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7 Jm5ic3A7IG1hY2hpbmUgYW5kIHN1Y2Nlc3NmdWxseSB1c2UgaXQsIGEgY2xpZW50IG1heSBleHBv cnQgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9oMz4NCjxoMyBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Y29ycmVzcG9uZGluZyBw cml2YXRlIGtleSB0byB0aGUgb3RoZXIgY2xpZW50IG9yIG1heSBwZXJmb3JtIGFsbDwvc3Bhbj48 bzpwPjwvbzpwPjwvaDM+DQo8aDMgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsdWUiPiZuYnNwOyZuYnNwOyZuYnNwO3RoZSBuZWNlc3NhcnkgY29tcHV0YXRpb25zIGZv ciB0aGUgb3RoZXIgY2xpZW50IHdpdGhvdXQgZXhwb3J0aW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9o Mz4NCjxoMyBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5i c3A7Jm5ic3A7Jm5ic3A7dGhlIGNvcnJlc3BvbmRpbmcgcHJpdmF0ZTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ LjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj4mbmJzcDsgUHJvdGVjdGluZyB0aGUgVG9rZW4gQmlu ZGluZyBwcml2YXRlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L2gzPg0KPGgzIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDsmbmJzcDsmbmJzcDtrZXksIGUuZy4g aW4gYSBoYXJkd2FyZSBzZWN1cml0eSBtb2R1bGUgdGhhdCBwcmV2ZW50cyBrZXkgZXhwb3J0IGlz PC9zcGFuPjxvOnA+PC9vOnA+PC9oMz4NCjxoMyBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7YSBnb29kIHByYWN0aWNlLCBidXQg aW4gc3VjaCBhIGNhc2UsIGl0IGlzIGluZWZmaWNpZW50IHRvIGNvdW50ZXI8L3NwYW4+PG86cD48 L286cD48L2gzPg0KPGgzIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bHVlIj4mbmJzcDsmbmJzcDsmbmJzcDt0aGUgY2xpZW50cyBjb2xsYWJvcmF0aW9uIGF0dGFjay48 L3NwYW4+PG86cD48L286cD48L2gzPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlNvbWUg b3RoZXIgY2hhbmdlcyBtaWdodCBuZWVkIHRvIGJlIGRvbmUgaW4gdGhlIHNhbWUgc3Bpcml0Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkRl bmlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj5UaGFua3MuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+T24gRmViIDE2LCAyMDE3LCBhdCA1OjI2IFBNLCBBbmRyZWkgUG9wb3YgJmx0OzxhIGhyZWY9 Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHVwZGF0ZWQgdmVyc2lvbnMgb2YgVEJQUk9U TywgVEJORUdPIGFuZCBIVFRQU1RCIGhhdmUgYmVlbiB1cGxvYWRlZDo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10b2tiaW5kLXByb3RvY29sLTEyIj48 c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtdG9rYmluZC1wcm90b2NvbC0xMjwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1uZWdvdGlhdGlvbi0wNyI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXRva2JpbmQtbmVnb3RpYXRpb24tMDc8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQtaHR0cHMtMDgiPjxz cGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi10b2tiaW5kLWh0dHBzLTA4PC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgdXBkYXRl ZCBkb2N1bWVudHMgYWRkcmVzcyB0aGUgY29tbWVudHMgZnJvbSB0aGUgdW5iZWFyYWJsZSBtYWls aW5nIGxpc3QgYW5kIEdpdEh1Yi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaGVlcnMsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kcmVp PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpVbmJlYXJh YmxlIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86VW5iZWFyYWJsZUBp ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPlVuYmVhcmFibGVAaWV0Zi5v cmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6Izk1NEY3MiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by91bmJlYXJhYmxlPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHByZSBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ VW5iZWFyYWJsZSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PGEgaHJlZj0ibWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmciPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPlVuYmVhcmFibGVAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5i ZWFyYWJsZTwvc3Bhbj48L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR0301MB0842353B2964E7E952B38DF38C5A0CY1PR0301MB0842_-- From nobody Thu Feb 16 15:11:24 2017 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 B4E46129485 for ; Thu, 16 Feb 2017 15:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com; domainkeys=pass (1024-bit key) header.sender=andreipo=microsoft.com@github.com header.d=github.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 c-ibZKSAhaE5 for ; Thu, 16 Feb 2017 15:11:20 -0800 (PST) Received: from m71-131.mailgun.net (m71-131.mailgun.net [166.78.71.131]) (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 5799012944E for ; Thu, 16 Feb 2017 15:11:20 -0800 (PST) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1487286679; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=ch73X5ROMlaE3EbA6bcnO7mYTH1HRs2XI2tKOxVtcqY=; b=RmK2LUOu33G8DAn+w9IcDVRHEW9Fwkv97yoO7VhdLXX22Ys+ZoYqZjqsbMk1DRd2eHFZlnwH qTdIEeeYlK+V08KetfrjkpNaQ/nefaFwuLTFuGWuYVs/XYn0vHZqVqgm1ucU8MYUveTGMO5v MUiUVd5t1vg8WI7XRfRf6mWGEZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=KR/W8/89mghNaZmXBozreL147qdmP0Rg7cRwziz3rAN4j98Rst+t+igt72Uf3hsE2Eq+id B8TtvuP/PhGtOV8awE5pwVx69Mk1/Y8g8+JPYOu0yMDa/CTu+fLyv+rZtQgXojNUNJUP5xYj sl6G5am+SOS2429jAHbydCoaqpDBY= Sender: andreipo=microsoft.com@github.com X-Mailgun-Sending-Ip: 166.78.71.131 X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Received: from github.com (Unknown [192.30.252.34]) by mxa.mailgun.org with ESMTP id 58a63197.7f193373f300-smtp-out-n03; Thu, 16 Feb 2017 23:11:19 -0000 (UTC) Date: Thu, 16 Feb 2017 15:11:19 -0800 From: Andrei Popov To: unbearable@ietf.org Message-ID: <58a631973add5_6853f8def849c2c10863c@hookshot-fe2-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_58a631973aa48_6853f8def849c2c1085e3"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] d50efc: Addressing Denis' comment regarding cooperating cl... X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Andrei Popov List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 23:11:22 -0000 ----==_mimepart_58a631973aa48_6853f8def849c2c1085e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: d50efc5c0eca01f42b7d1999d826eaf91ff8dd3b https://github.com/TokenBinding/Internet-Drafts/commit/d50efc5c0eca01f42b7d1999d826eaf91ff8dd3b Author: Andrei Popov Date: 2017-02-16 (Thu, 16 Feb 2017) Changed paths: M README.md R draft-ietf-tokbind-protocol-12.xml A draft-ietf-tokbind-protocol-13.xml Log Message: ----------- Addressing Denis' comment regarding cooperating clients. ----==_mimepart_58a631973aa48_6853f8def849c2c1085e3-- From nobody Thu Feb 16 15:46:37 2017 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 E1BF912944F for ; Thu, 16 Feb 2017 15:46:36 -0800 (PST) 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=sunet-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 GWytoUuGfyrx for ; Thu, 16 Feb 2017 15:46:35 -0800 (PST) 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 1A0561293EE for ; Thu, 16 Feb 2017 15:46:34 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id x1so15575908lff.0 for ; Thu, 16 Feb 2017 15:46:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-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=IpVktaUU7ETiuJ4PHfsAE240w6Ss6fvfVnaolGow1Mw=; b=ubnRPNEJnDkahpBCkS8rE3zbRaEulaPMAFokZk5R7558OduJ/yy+lroNNnwKy+Sr7O R07zLty3nR2I/pt3+6rTy+gkBMLV6qm1DxTolu8fq9vMsGkhLp/IQsIhucfaKVsl3Ay4 L+kMYjtYsZt+6TcM2BiuqRFcOTojgVGfJQ/WKo4EvV5P6kGbq6Mqnyui8kV3J6z4C51P ZXYIp1UTjhZP8VECok3y9hu2R9kr9KO1kaijqeiM0/biGQIcy9SKR6DOcojox1qSbX2k PGfiH+5OiZjMtkYU3/CsEUfxFLpDh5YCZ/B0LQz/IBn31VwJn/lGamrZRhmP2T6opz2j oxdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=IpVktaUU7ETiuJ4PHfsAE240w6Ss6fvfVnaolGow1Mw=; b=WXG37I2ipAu6qg5+BofZl99sruut98c9VwHOYz2Xvfhd4vqtn/9DIEBvjTVqMNBkJP cZC/7tAG6MR/Eoc8+B1RVjh7Ht9n6OXPdB2EYYGS177ws3VUppBn0De8U9qR09qWE1t8 MQno7EArYEBJYN/RP0V0brB5Mlt9O//UVlBKSFuVsu0pG2El4KYfU2r0CqiAjz3A8tqd 1ZSlubPHrWP1tu6EGT8zNFztDtxKTpYU18fetlFrdR5F/aTby6c7EhQcpKQAoR2uCrTK sHtToWzjVBquTXRjRwtLEGcWksmbifquN54YPMHi61LsJ8+9C3CP6H45p2iQOXs6SPSP MD+w== X-Gm-Message-State: AMke39k6GeL/BKe6MXG0pumrGsRLuHP5RNhd0tM3w+tDc3LLDPvYFPTQ2OKHqMaELwqd4g== X-Received: by 10.25.92.217 with SMTP id u86mr1505057lfi.5.1487288792304; Thu, 16 Feb 2017 15:46:32 -0800 (PST) Received: from [10.0.0.149] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by smtp.gmail.com with ESMTPSA id y29sm2087864ljd.41.2017.02.16.15.46.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 15:46:31 -0800 (PST) To: unbearable@ietf.org References: <2A56853E-C785-48CF-A75E-5F61683B1035@ve7jtb.com> From: Leif Johansson Message-ID: Date: Fri, 17 Feb 2017 00:46:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Unbearable] Updated I-Ds 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: Thu, 16 Feb 2017 23:46:37 -0000 On 2017-02-16 22:50, Nick Harper wrote: > I think that we don't need to do any more than add a sentence to 7.1 of > TBPROTO saying something along the lines of "the Token Binding protocol > does not prevent cooperating clients from sharing a bound token" (i.e. > what Andrei said). I'm also fine if we don't add anything. I sense consensus forming around adding a sentence in the security considerations section. I propose to start another WGLC right now and deal with this issue as part of the WGLC comments. Cheers Leif From nobody Thu Feb 16 15:49:46 2017 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 67C8E129485 for ; Thu, 16 Feb 2017 15:49:45 -0800 (PST) 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=sunet-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 f8m-UIjpVpEK for ; Thu, 16 Feb 2017 15:49:44 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 081A31293DA for ; Thu, 16 Feb 2017 15:49:44 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id o140so1485072lff.1 for ; Thu, 16 Feb 2017 15:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=WNRiwGmRp0ZhQztMW72LC+zabaoPp6fdJ2Cjd6KQy3g=; b=1FDZvfq4zLSxLeXZOsPhYC+dsYJJ2l3KTzeNEhg6ryNA8pyFag0jj9CiUaqIExAdmO XMFk/Umi8Ak6rDdygyhfPr1DxnohcdJ0IzUExmTCRE885Y0BBQawHTxmFlnvl6nof7w6 PABXiyhAukvsw17Fg0JziZTird4fbj2reQWdtDZjV0gjYA8li1S0Sq6gNEyAvTNNeTwo kQOrAFThBtboms7Bbqqxcm34gZg0jtRfgBjSRAB9noQ4zHJnEbMCtRk+zVXODPWegwBa 41hVV+JmMkR+BAL8U2zPiCCyr0sCix7lNpj/TziDJw/6t9FEWQD/FuuVIJUHafpqz5bT qYpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=WNRiwGmRp0ZhQztMW72LC+zabaoPp6fdJ2Cjd6KQy3g=; b=b0LQBYmiPT8QR86NkeSjxdtgUXA5bGd5/GMt2sZ5Y8c/JDy07zp7No4dFLIbvqKWiJ HLINJEdX7njege0iBr0rvARS9IzrUgms2AZTPH/Mmve9xNFoDTYvvLRRS3nQ4XCovdoi 5iCdng8MZ5fdyGKQNpl0GRJu8FTeE3lxzp2pOou//QkuhpaRa4plUouJoiGxmR1eO0/U GsBTwcBOfTk7f2o2tFYTLN4L/HwNKlEZcPJ+5qzakQzX4BXg0GoN9bpI+kEM8eGlMd5H dfkH8fZu8IvabV3DtaV1VNqZ840QhJzgaj+/Gbbe4yQLaV/HM0qHwaYwI2z1LB4V5+dQ hvEQ== X-Gm-Message-State: AMke39lFChy2PyoAiT3MUhkVEI58um6zWogI0Uho541h4PdlQzZAq7/a5huKREnNNRE1/g== X-Received: by 10.25.151.20 with SMTP id z20mr1533552lfd.92.1487288982029; Thu, 16 Feb 2017 15:49:42 -0800 (PST) Received: from [10.0.0.149] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by smtp.gmail.com with ESMTPSA id m18sm2071271ljb.8.2017.02.16.15.49.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 15:49:41 -0800 (PST) To: unbearable@ietf.org From: Leif Johansson Message-ID: <90198679-4549-2893-6d91-f4415df217ad@sunet.se> Date: Fri, 17 Feb 2017 00:49:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] WGLC 3 on core documents 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: Thu, 16 Feb 2017 23:49:45 -0000 This starts a 3 week WGLC on the core documents: https://tools.ietf.org/html/draft-ietf-tokbind-protocol-12 https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-07 https://tools.ietf.org/html/draft-ietf-tokbind-https-08 Any comments should be in hand by the 10th (any TZ). The recently raised security considerations issue will be treated as a WGLC comment. BestR Leif & John From nobody Thu Feb 16 16:59:43 2017 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 9B52812944F for ; Thu, 16 Feb 2017 16:59:42 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 56USTcs5ELit for ; Thu, 16 Feb 2017 16:59:41 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 3CFD7129559 for ; Thu, 16 Feb 2017 16:53:23 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id x49so29370080qtc.2 for ; Thu, 16 Feb 2017 16:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=drFqvMN4ZaLBzlO8ue1xQhtHii7Aa0giHyIaLB3AqQM=; b=R+gnmQGo3HWBgElYt29XVAWa2Ihtn00ZhVffih4hlOA4B25VteBEOeZ8RkNRJLG+Kx +h2ANCbUtiKI3G9DnUZzOrQQevLFZsO6add6BScekYa3ElIy3FkgSgC5uUkIhWvIOlEw 2382n9hLO8498C9ToKoN4meXlkyUHF8pw5ZB/qtbvlRBoj87X00zJvre3V7loDSHsZhD FxZXNqm4g+nWG+5zeedY/J9/OUvMQ/ifAhX0oMsT8q+vlfL15Ef2r5+ZdWllkebLpsre 9Ze0iqb26z0beY3yjn9jCYIVhdRS/GhTL7s1ufjVqm8+gRSGWrgcx9FrBZp+TODk5Lqh n1Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=drFqvMN4ZaLBzlO8ue1xQhtHii7Aa0giHyIaLB3AqQM=; b=mStU6FV07G6PMS6wrAvEyyWl8Few4Ueg094RrNQVV0i73fx+9O6hGsxIrfcSPhcqXv GQH7uRHK5c8CyWYybsAG8iKw6pcYOCwib7vAbES2lsrH+pz5hTbVUdN9CGLEY3jt8m9H djGevdjRjZcDmNAbPVGXDhzdtPvZ16TuanJb/LWp9MLV3PcH3+Of6c+iGMhm4wtqHpck 93EI4reNNK5b+5rdeYWtjZhmJNnsiLpnsJOM0FaaGWBUsPy0hbA6FJ1x2SUBSAbgC6nh 0yRSt3eZcBEa6x/Tk1jkHOYV3Qio0eksrncmXcNdFvFeiGYD0f1szTbKE/y8sejAdFqx 6NSw== X-Gm-Message-State: AMke39nN8Fr+N0ivQmrTZxohu2ojei0nD9RnKrjDoSOkvKc+bsDhxTjGlzeQ41Rn0N6laIdx X-Received: by 10.237.47.230 with SMTP id m93mr4730910qtd.103.1487292802189; Thu, 16 Feb 2017 16:53:22 -0800 (PST) Received: from [192.168.8.100] ([181.201.178.1]) by smtp.gmail.com with ESMTPSA id m143sm5487985qke.18.2017.02.16.16.53.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 16:53:21 -0800 (PST) From: John Bradley Message-Id: <49D963D1-FCF8-4A71-B362-16C8EA6B3F50@ve7jtb.com> Content-Type: multipart/signed; boundary="Apple-Mail=_5AB73A5E-857B-4A5B-8E9B-37290083AF85"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 16 Feb 2017 21:53:18 -0300 In-Reply-To: To: Leif Johansson References: <2A56853E-C785-48CF-A75E-5F61683B1035@ve7jtb.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: unbearable@ietf.org Subject: Re: [Unbearable] Updated I-Ds 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: Fri, 17 Feb 2017 00:59:42 -0000 --Apple-Mail=_5AB73A5E-857B-4A5B-8E9B-37290083AF85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I just looked at diff of Andrei=E2=80=99s proposed addition to security = considerations, and it is fine. Lets rev protocol to 13 and go with that. > On Feb 16, 2017, at 8:46 PM, Leif Johansson wrote: >=20 > On 2017-02-16 22:50, Nick Harper wrote: >> I think that we don't need to do any more than add a sentence to 7.1 = of >> TBPROTO saying something along the lines of "the Token Binding = protocol >> does not prevent cooperating clients from sharing a bound token" = (i.e. >> what Andrei said). I'm also fine if we don't add anything. >=20 > I sense consensus forming around adding a sentence in the security > considerations section. >=20 > I propose to start another WGLC right now and deal with this issue > as part of the WGLC comments. >=20 > Cheers Leif >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_5AB73A5E-857B-4A5B-8E9B-37290083AF85 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILMTCCBUcw ggQvoAMCAQICEEAfBHP+tuqufC4R+F+Tu54wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAyIENsaWVudCBDQTAeFw0xNjA4MTIy MTE5NDFaFw0xODA4MTIyMTE5NDFaMIGCMQswCQYDVQQGEwJDTDEiMCAGA1UECAwZTWV0cm9wb2xp dGFuYSBkZSBTYW50aWFnbzEWMBQGA1UEBwwNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAwwMSm9obiBC cmFkbGV5MSAwHgYJKoZIhvcNAQkBFhF2ZTdqdGJAdmU3anRiLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALhTcSiDGvVrm4hlJA8WyFcWWe0dqnuJzstQYTaF281JFOEPA/13kQYI JMXAEUcS7NvW7KdUI0tHU0N6RTo0Ilf1E1nm8No++eqHO8pFUZ/cidpv0r+1Qcl9EgrpbZ00Y7Xg pq06EZELzJAmds4QQcsTKdpLNFbVcFnM11i2Gj5VNsYgO+qPO2AS8rLHkgDWnNkc9/lA+ZK5wGiU zxPU9KnIrERoTif3Zk7KjLvFpBWYD60M/lNoHZ5zxYgmYLmvoM1TSLn4Ms57wwT5MieV2l0aqlGC 7CKNa6XyeL1B0y0wSxL3PJQS4vSLDnttZC7od2A6yjeUMyM3rQ41vqUIMc8CAwEAAaOCAcMwggG/ MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUmA9bUmBmTYkCcZ3yYv8IRRP2nN4wHwYDVR0jBBgwFoAUmZerGDU6i1lFQ5iy cnHI9PsJzxYwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNz bC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGll bnQyLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xp ZW50Mi5jcmwwHAYDVR0RBBUwE4ERdmU3anRiQHZlN2p0Yi5jb20wIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMFUGA1UdIAROMEwwDAYKKwYBBAGBtTcGATA8BgsrBgEEAYG1NwEC BTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4IBAQBqcYJfFA/ITkX4L6JihqW168Wog1BOfkbPXO+wPn5G9P1NwruGfu41b70EPPwV vol+/j+qhSSrDjFyfNBsq4G45GRR6hwx0ei/bH0UW15Y63ASYPkNlj3ydCcvhw5ItWD5aYPphBx9 C7tLnQ7ow09cqt2CIgPd3W/IGri7p4hWPbdcX0oFIhJcDxmCwTcWyoVoIo4aas5gP44LPGneCoqI lXQMJinwneEnKd7rWXlzVWv7geaH3t79zARSw9ev9F4E61cDuHi+vgTFEpio7oxybqfj99yLibhX uZjReYnYbDMRiWDXduVIrIGYwmnUuD8a0b20kJgHm+FEgB6UMa9JMIIF4jCCA8qgAwIBAgIQXLZI bkcMmMZ/9oDbZErijTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1 WhcNMzAxMjE2MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDIgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7g9Q jJUJI4Ss9VBqj9Y3ok4h/TIJZUc+rzj61Rv3hNB/yeEEC1fz3i/EU+MXOOGxM7KCbtCIcJxHIW/k 8RP6sPPMO4cTg7sNzfBWsYsemtY6fN/kVr2R2X+/PjvtxmAaXpGX0znvQPxaE123IMGXy0zEKHZ/ nJDZ199TP9TNn9v+1QO0AZb4oaJ7ch0DpSJa8kF5xiNFDAg9taKKSrVuPHJL9MFFYPIqwShjHg+u YEzjfxbMP2QWwamnaA9Y7fORSDNapduFlARAcDtXdMpAijiG4HKnrN323I0Ka7lDTAWyLtTDCETK sI8fzOyL0inEu1WEVpdPytm8s1rwQB4f9QIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQr MCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRa MFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBSZl6sYNTqLWUVDmLJy ccj0+wnPFjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUd IAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4ICAQCZQUEEzvYk9U4wNHhDu1f9QGwbzAH4m4wIKH8ZidNYwZhyoNKW041iJ002KMW9 ywYM95n4770tT45yH29vTMlZtBvz0h44KuxMLNXRCTDwvV07sT39nPjFi5MpwZaLVueNiaa1vok1 n2Wn8lLcyCltYZNGAEifM0ko/A/vvckftFIZG75RAiZHYtfnrdBGiOxyF+nHI9a33BRX5Vl/3z0+ uHZ/Y6YPbNJ7iboOFrFZBCtt+lp3WaDB62ZoBewiMmd09JrqmMJAEgw3EbfQNtaPzHPg/EOhlZik Rgd4BCrzrbIqB2RKib+gnQJt2uoJaKOaV90S9Xgs3PC837OE9CEmY6/MTTG0xpbLh2hR/rLQ3sCr H56aODeuDrQBq85lXxRbDCERDUR7FZUhHv+i1aQaY59NPu26hDd6nqksSDq2mCddpidPBuGJz9lN X2nRyGkudDuWV6gIr6AZfaYv+ggTXOcCDJZFzMhWdLC7CPvRKxQ7vTiYV+4lgqOvV9MnZc149PPt itTysq/oOv70zx7q+tyaLTa4cqFhCclhIwSwOEJiV3xqQebvmwsDX7BaXGAJZIhbdUbNr3poEgct 6uAxw2zyr69WCJmTUUhz/k1/TT/eCUZJqnMg/6mje7tiVdaUQJcBtJ6cq5+mUDNUB1fohW8EOFai zFpP/0FaP62ctTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMiBDbGllbnQgQ0ECEEAfBHP+tuqufC4R+F+Tu54wCQYFKw4DAhoF AKCCAZkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjE3MDA1 MzE5WjAjBgkqhkiG9w0BCQQxFgQUo3fXII6bsSdMzF64l2nTFp0/DYswgZoGCSsGAQQBgjcQBDGB jDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIg Q2xpZW50IENBAhBAHwRz/rbqrnwuEfhfk7ueMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIgQ2xpZW50IENBAhBA HwRz/rbqrnwuEfhfk7ueMA0GCSqGSIb3DQEBAQUABIIBAGpraJ+U6ppIJThXCGZ1CENttE77ivR8 hrIiUNTnnqzBYz7krfUkuMekNy9Y/6UO239WydVgi5fJBzzS8YlAgeRrp+j5yfvvn7Se7OhAn2El ZICzMoL8DmKI+LV/u03y0+713sePwvWNSo9rDsX2w5leFewF86MyjOO3+OP2w0wCJfBKjw7iA9QA zJuJv7IpWyYSGQNDUZ6bOWlsR+8vqNwQRaaP7UonUiji15ZdaLMOFA6F6Q8YLrjuqJwy5h74ApGv xfpPgwx4jTcShydwMjQJmrM1T3tGvguS2RutiMu1sAbzB797QI5Rsb7afRF092ponnrG4/8nCICf 2BBojOUAAAAAAAA= --Apple-Mail=_5AB73A5E-857B-4A5B-8E9B-37290083AF85-- From nobody Thu Feb 16 17:14:51 2017 Return-Path: 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 BA5421289B0; Thu, 16 Feb 2017 17:14:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148729408675.21869.1268004913445537905.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 17:14:46 -0800 Archived-At: Cc: unbearable@ietf.org Subject: [Unbearable] I-D Action: draft-ietf-tokbind-protocol-13.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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 01:14:47 -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 : The Token Binding Protocol Version 1.0 Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Jeff Hodges Filename : draft-ietf-tokbind-protocol-13.txt Pages : 17 Date : 2017-02-16 Abstract: This document specifies Version 1.0 of the Token Binding protocol. The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS [RFC5246] bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, the Token Binding identifiers are only conveyed over TLS and can be reset by the user at any time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tokbind-protocol-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-protocol-13 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 Thu Feb 16 17:19:18 2017 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 7282C1296CA for ; Thu, 16 Feb 2017 17:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bmv3AlpISty9 for ; Thu, 16 Feb 2017 17:19:14 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0132.outbound.protection.outlook.com [104.47.40.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D99129550 for ; Thu, 16 Feb 2017 17:19:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uy8vu8Ksds2YG7pR1K+psyt7VmsS6DmiiIvs2YrlAC4=; b=VT1vKXCV2tCK+qFhEpDkZVUkctfZl49/SsfPtcrw1jtFuu0cvrkjJ7KGwGuiu0nJfr6pspkjSoEY1V1C8ikzRf9kxhwKdkBgLYpe1oRuZDiiqucZSIsFhRrt6MTGguVUvg4sMcm3itJDcZczvK3G2uD1S1g5EGB3caE2vw1LTGg= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0843.namprd03.prod.outlook.com (10.160.163.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 17 Feb 2017 01:19:12 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.034; Fri, 17 Feb 2017 01:19:11 +0000 From: Andrei Popov To: John Bradley , Leif Johansson Thread-Topic: [Unbearable] Updated I-Ds Thread-Index: AdKIki7cdjaoT3T9Qfa4KQrr2Z1KPgAAsoQAAAB1bAAAANOA0AAAxdWAAABawAAABBGXAAACVT0AAADM67A= Date: Fri, 17 Feb 2017 01:19:11 +0000 Message-ID: References: <2A56853E-C785-48CF-A75E-5F61683B1035@ve7jtb.com> <49D963D1-FCF8-4A71-B362-16C8EA6B3F50@ve7jtb.com> In-Reply-To: <49D963D1-FCF8-4A71-B362-16C8EA6B3F50@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: aa9f3f0b-e9c6-43df-32ae-08d456d2fab4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0843; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0843; 7:4SeV2LfuZGVqU/+ClPVlUbOtB6U/84hbeRvXcP1bi4XpQs0FEelteCqGzLFvc1RKPiuzQ/qhbUkbl4M5R3sEJv8PTC26E5DkTSDPdOClhdQLFLLCQKTsDLnYE/eYRmSJnZYghc50XtgAPo0oDlPwyJLL6MfIMK3k6+TN0IxwTvWcgZ8p6xDYwG4JdyQjCiWAVc/lTWDwvj3fSFPLf5h1Eqr6KaqwR+XrZ+3b/pywSE5cyU4L2MYSufyZ9DS5pSaO9lLYwAAWCt+c5J62kkfQeyrP0bhZ9JXi6Y+6Rf9s3XFiO9vypjhHpNSfSV9cBml7Wq2DoA/WDMYA6DQwNPCSQZmzgdzOwnL6YzNvQ0BW+zU= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(100405760836317)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(6072148)(6042181); SRVR:CY1PR0301MB0843; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0843; x-forefront-prvs: 02213C82F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377424004)(377454003)(24454002)(189002)(51444003)(199003)(13464003)(77096006)(74316002)(3280700002)(6506006)(3660700001)(2906002)(7736002)(2950100002)(93886004)(4326007)(305945005)(25786008)(229853002)(102836003)(9686003)(53546006)(6306002)(6116002)(6436002)(7696004)(99286003)(15650500001)(55016002)(10290500002)(5005710100001)(92566002)(5660300001)(38730400002)(33656002)(106356001)(53936002)(10090500001)(122556002)(8990500004)(6246003)(97736004)(2900100001)(54356999)(86612001)(101416001)(50986999)(76176999)(86362001)(105586002)(389900003)(8676002)(81156014)(68736007)(8936002)(189998001)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0843; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 17 Feb 2017 01:19:11.4223 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0843 Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] Updated I-Ds 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: Fri, 17 Feb 2017 01:19:16 -0000 VXBsb2FkZWQgVEJQUk9UTy0xMyB3aXRoIGFkZGVkIGxhbmd1YWdlIGNvbmNlcm5pbmcgY29vcGVy YXRpbmcgY2xpZW50cyAoc2VlIHNlY3Rpb24gNy4xKToNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXRva2JpbmQtcHJvdG9jb2wtMTMNCg0KQ2hlZXJzLA0KDQpBbmRyZWkN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFVuYmVhcmFibGUgW21haWx0bzp1 bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2huIEJyYWRsZXkNClNl bnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxNyA0OjUzIFBNDQpUbzogTGVpZiBKb2hhbnNz b24gPGxlaWZqQHN1bmV0LnNlPg0KQ2M6IHVuYmVhcmFibGVAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbVW5iZWFyYWJsZV0gVXBkYXRlZCBJLURzDQoNCkkganVzdCBsb29rZWQgYXQgZGlmZiBvZiBB bmRyZWnigJlzIHByb3Bvc2VkIGFkZGl0aW9uIHRvIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCBh bmQgaXQgaXMgZmluZS4NCg0KTGV0cyByZXYgcHJvdG9jb2wgdG8gMTMgYW5kIGdvIHdpdGggdGhh dC4NCg0KPiBPbiBGZWIgMTYsIDIwMTcsIGF0IDg6NDYgUE0sIExlaWYgSm9oYW5zc29uIDxsZWlm akBzdW5ldC5zZT4gd3JvdGU6DQo+IA0KPiBPbiAyMDE3LTAyLTE2IDIyOjUwLCBOaWNrIEhhcnBl ciB3cm90ZToNCj4+IEkgdGhpbmsgdGhhdCB3ZSBkb24ndCBuZWVkIHRvIGRvIGFueSBtb3JlIHRo YW4gYWRkIGEgc2VudGVuY2UgdG8gNy4xIA0KPj4gb2YgVEJQUk9UTyBzYXlpbmcgc29tZXRoaW5n IGFsb25nIHRoZSBsaW5lcyBvZiAidGhlIFRva2VuIEJpbmRpbmcgDQo+PiBwcm90b2NvbCBkb2Vz IG5vdCBwcmV2ZW50IGNvb3BlcmF0aW5nIGNsaWVudHMgZnJvbSBzaGFyaW5nIGEgYm91bmQgdG9r ZW4iIChpLmUuDQo+PiB3aGF0IEFuZHJlaSBzYWlkKS4gSSdtIGFsc28gZmluZSBpZiB3ZSBkb24n dCBhZGQgYW55dGhpbmcuDQo+IA0KPiBJIHNlbnNlIGNvbnNlbnN1cyBmb3JtaW5nIGFyb3VuZCBh ZGRpbmcgYSBzZW50ZW5jZSBpbiB0aGUgc2VjdXJpdHkgDQo+IGNvbnNpZGVyYXRpb25zIHNlY3Rp b24uDQo+IA0KPiBJIHByb3Bvc2UgdG8gc3RhcnQgYW5vdGhlciBXR0xDIHJpZ2h0IG5vdyBhbmQg ZGVhbCB3aXRoIHRoaXMgaXNzdWUgYXMgDQo+IHBhcnQgb2YgdGhlIFdHTEMgY29tbWVudHMuDQo+ IA0KPiAJQ2hlZXJzIExlaWYNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IFVuYmVhcmFibGUgbWFpbGluZyBsaXN0DQo+IFVuYmVhcmFibGVA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJh YmxlDQoNCg== From nobody Thu Feb 16 21:54:01 2017 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 8F6C6129586 for ; Thu, 16 Feb 2017 21:53:59 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-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 GYJy-xWig6sw for ; Thu, 16 Feb 2017 21:53:57 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 309D11294D2 for ; Thu, 16 Feb 2017 21:53:57 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id z127so17869429lfa.2 for ; Thu, 16 Feb 2017 21:53:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DDXICw7lAYdH4NTHtQBIljoLGrGSqMAOvxu5APuuO/Q=; b=RZIJBMMHOrjODYornis7KuX+67eV4jWHzA8KleDFqdPIRmd3kecRBbjM5XsLsLF9bI GbWsvuAoBVWyXXwhxbhHaJlzv/+mSwJCSjOmjUpBuGYQTtYlhQ9pWbjs2xunDBqhRQjW GaWnTOMF/aLsKw3taab10LOky9/WUMiR+ci4DGDyy7/9c/TDLJ4r41NObC7PAhoewTLh GU5t2l1P3dwxc1O2wQ47hQkkANY8EbZCvFrPIwVviAMPMZ1XRwZ2j0ANUnvblFyQiWDn iGkD5TFPpu9HYOd2MzGyuUKjG/A+Xl0CdEtdinj/g9Vt1Y3foDuv0BSaAeOQQedXk1Gc Ogag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DDXICw7lAYdH4NTHtQBIljoLGrGSqMAOvxu5APuuO/Q=; b=Z+hR8m1wEi6b0xsTdaZodP3dZUHssKdubDw50TJYEqRDnzWoKeLv7x6/w6l69lPNu0 ADwhlLlIufp/Z87+GOVbdAm+kUQKWse5m4EV4eS2wAfAS4DLN09k+cCQ9cNlOpVcrITO qFPgnOe5B64eAO/BnYQFDGyeN3f3iiz9Wr0X9SrbSFPsKe819vP93X0gXZwQJvm6qiLn 0LWbrKKjY4MkVOSHZT/nwRJs9RwCdKpA5Lj6Q9MekiEDZ8B7zbtsp6b8KwLjz0gTV6Da fuDsU4uykhv/43lBTNABCHfaCNovDN3a8l/uqJAWHLVnMnk9P/RPUPsW/TgUx+px02zz u0Jg== X-Gm-Message-State: AMke39lfbzGEr+eU/ZubgdTHivR5W2AcCQ9UgjjNIcxPgDc8Bu2+CowF8NIuXtSknOqtMA== X-Received: by 10.25.22.201 with SMTP id 70mr1800385lfw.97.1487310835304; Thu, 16 Feb 2017 21:53:55 -0800 (PST) Received: from [10.0.0.110] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by smtp.gmail.com with ESMTPSA id 26sm2141791ljo.21.2017.02.16.21.53.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 21:53:54 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Fri, 17 Feb 2017 06:53:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <95C79323-0477-4485-9330-732F02B37B3F@sunet.se> References: <2A56853E-C785-48CF-A75E-5F61683B1035@ve7jtb.com> <49D963D1-FCF8-4A71-B362-16C8EA6B3F50@ve7jtb.com> To: Andrei Popov Archived-At: Cc: John Bradley , "unbearable@ietf.org" Subject: Re: [Unbearable] Updated I-Ds 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: Fri, 17 Feb 2017 05:53:59 -0000 I guess our messaged collided in mid air but the result is the same I guess Skickat fr=C3=A5n min iPhone > 17 feb. 2017 kl. 02:19 skrev Andrei Popov : >=20 > Uploaded TBPROTO-13 with added language concerning cooperating clients (se= e section 7.1): > https://tools.ietf.org/html/draft-ietf-tokbind-protocol-13 >=20 > Cheers, >=20 > Andrei >=20 > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of John Br= adley > Sent: Thursday, February 16, 2017 4:53 PM > To: Leif Johansson > Cc: unbearable@ietf.org > Subject: Re: [Unbearable] Updated I-Ds >=20 > I just looked at diff of Andrei=E2=80=99s proposed addition to security co= nsiderations, and it is fine. >=20 > Lets rev protocol to 13 and go with that. >=20 >> On Feb 16, 2017, at 8:46 PM, Leif Johansson wrote: >>=20 >> On 2017-02-16 22:50, Nick Harper wrote: >>> I think that we don't need to do any more than add a sentence to 7.1=20 >>> of TBPROTO saying something along the lines of "the Token Binding=20 >>> protocol does not prevent cooperating clients from sharing a bound token= " (i.e. >>> what Andrei said). I'm also fine if we don't add anything. >>=20 >> I sense consensus forming around adding a sentence in the security=20 >> considerations section. >>=20 >> I propose to start another WGLC right now and deal with this issue as=20 >> part of the WGLC comments. >>=20 >> Cheers Leif >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >=20 From nobody Fri Feb 17 07:14:11 2017 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 E551F1299D7 for ; Fri, 17 Feb 2017 07:14:09 -0800 (PST) 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=sunet-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 a8bSMIAxyRgG for ; Fri, 17 Feb 2017 07:14:08 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 501E81299CF for ; Fri, 17 Feb 2017 07:14:07 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id z134so23922729lff.3 for ; Fri, 17 Feb 2017 07:14:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=DxBbgUPEoEXYnptXS1kjAI0mCNMEums4Zs603dnLe2c=; b=KfJvkKwGpw1MyH2cKvXG1JCxfTcnHvJO5beVFg5XxkTWpqHfNsc+tjuy7r01397lIj ongjuQwlD0clVdYBx8nzJWM0t2Z3QIlC2/oac2SqvnjwVbUYOrTBDBjW5+kjPU8TU2tG ao5GGxRPdJNTZPdEB52dfkX4Jw1whIk2ADUDAyDidNsFjQ5HOKzWDVHHW9aZ/mGaieBC AOSuuTwbdIu0KIfMtElKnARyGAx0aAYDoXBANKaNYHryU4smSd8w60bSRYpBvfR1rmON mIMf1dWpsg9BugR4HY9MvYKU22HcPaxTAhyZ+Q8L2laX3HyuJuQ7yCk+lOcgDQGsbkUn x2Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=DxBbgUPEoEXYnptXS1kjAI0mCNMEums4Zs603dnLe2c=; b=ZOMvLQtPJwwjXxsoWUBsVai9Y+cFU5Uw29nBWomFgXPAtwBq6M8B8AbLGJgvbap5eA 3PKtoShVmLmE27xuradHhiut0RWdx+l/XJwkM2/PmQuNycBs8lcpBLhd22oEQLotyKGW W3n8oar6sjGJC/lbz/nxvLqqBJ0aV3/JCldLLGbAdiEuG/JRUaVQSA47PxlWc+3ozEHW SmRnaDkbllfBDMSL6DKGObT6sVNRYhQy7V4X13VXx9YD8wF7WsMxx7G2dHP/YkpfCanj q/nvlPcxgxw9UZXYzhgfSi0bjan59SoVzLFwyPCA0NGw9hdUHA8VcPmeYJfBf0uE+NOo KW8Q== X-Gm-Message-State: AMke39laMWnzDezJYFnlWG5flFDFr4Q1nwkETwGKW/ruPZcGkOhK2uNpFH/BxV+Rq3WlKw== X-Received: by 10.46.71.132 with SMTP id u126mr2151264lja.43.1487344445791; Fri, 17 Feb 2017 07:14:05 -0800 (PST) Received: from ?IPv6:2001:6b0:7:1:bc91:1ede:292b:8484? ([2001:6b0:7:1:bc91:1ede:292b:8484]) by smtp.gmail.com with ESMTPSA id m80sm2574328lfi.51.2017.02.17.07.14.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 07:14:05 -0800 (PST) To: unbearable@ietf.org From: Leif Johansson Message-ID: Date: Fri, 17 Feb 2017 16:14:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] WGLC clarification 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: Fri, 17 Feb 2017 15:14:10 -0000 Due to unbridled enthusiasm for getting our work done we got -protocol-13 more or less at the same time I launched the WGLC that included -protocol-12 For the sake of simplicity I suggest we move the WGLC to cover -protocol-13 Please review and don't forget to inform the WG about your review even if (especially if) you are ok with the documents as they now stand. Cheers Leif From nobody Wed Feb 22 13:53:34 2017 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 71DA0129BA0 for ; Wed, 22 Feb 2017 13:53:32 -0800 (PST) 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, HTML_MESSAGE=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 (1024-bit key) header.d=pingidentity.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 1iTqN5VilPdv for ; Wed, 22 Feb 2017 13:53:30 -0800 (PST) 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 69083129B94 for ; Wed, 22 Feb 2017 13:53:30 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id l19so8284469ywc.2 for ; Wed, 22 Feb 2017 13:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=f5pgJG7b4NhLmkvXrb4k+DD89teg3fvcPrLMPu6R87c=; b=H43sBlR2rOVeJzsvnS7xVaC2/6ir4zUC/nwnUGCz/E/ru6PWIHeEQQefMsS7V94JpA uhhUE6feIyF162f3gwrHFkLgoiPi5+jFjwAXGk1A8BVXUd7HPr3Xkmheic2rPhgCkmai 5vRFAqq+mp8ipL/6T2CQ75WJOy6d7npJz3a1o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=f5pgJG7b4NhLmkvXrb4k+DD89teg3fvcPrLMPu6R87c=; b=inRBDcQyJwaTQMZGp26WPZSS4aWULQgi4FFrYpu4NMCqjHNegLDTFVjo+5gKttW9Tm 0MmZwBeDAiBLRgC3+KJXcDAOGeLlBZUkfEIA8NvBSJ1XHFBlyjPiEb7uj5KSjqntoqgp jQRjUrj7ffieEDMShcuaOOvWjs6M5+cqeWurlV+Hh6xlJLEgesHJ577xqIXg6x5Cs3mt 4MUTzCZ6yA60eOPeKzqSEczstneJQAneKQWF+axQwp0E7F6nC9nAM2bDBIgT0OOGed++ JsWvz9w8RQqA7shczQe+mz2UCnuc3WS3lm5kI/2Rxuo3sVo4REThjN+SpMCPLZy4B78S 7ubg== X-Gm-Message-State: AMke39m3xVU7t/oafhCMz5RGeQlmJNzK46EfRWGX3Tb2nKBtYZ0jmLdSORhhE9+eH9dZpUdSxPyS0lD/H9WfqI2j X-Received: by 10.13.214.129 with SMTP id y123mr6705325ywd.25.1487800409269; Wed, 22 Feb 2017 13:53:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.126.131 with HTTP; Wed, 22 Feb 2017 13:52:58 -0800 (PST) From: Brian Campbell Date: Wed, 22 Feb 2017 14:52:58 -0700 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary=94eb2c076d5ae4bfa2054925861f Archived-At: Subject: [Unbearable] ramifications of longer EKMs 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, 22 Feb 2017 21:53:32 -0000 --94eb2c076d5ae4bfa2054925861f Content-Type: text/plain; charset=UTF-8 Shortly after Seoul TBPROTO-11 "Clarified that other signature schemes may require longer exporter output ", which generally seems like a good thing in terms of facilitating cryptographic agility going forward (i.e. a super-duper signature scheme might need to sign over a longer EKM to realize its super-duperness). However, that future TokenBindingKeyParameters type might use a longer EKM has some ramifications when a TokenBindingMessage has more than one TokenBinding that maybe weren't fully considered. A server has to parse the TokenBindingMessage and look at the TokenBindingKeyParameters of each TokenBinding in order to know the length of the EKM to use in validating the signature on each. And possibly have to get two (or more) different EKM values to service a single TokenBindingMessage or request. This situation only occurs when a referred_token_binding is sent but that's a valid case that needs to be handled and the server can't really know if it's there without parsing the message. So rather than getting the EKM based on the negotiated key parameters type, the whole TokenBindingMessage needs to effectively be preprocessed. It's certainly possible to do things that way but it seems potentially error prone (especially given that all the currently defined TokenBindingKeyParameters use 32 byte EKMs so there's likely an ossification effect) and less than ideal. It's even less ideal for the model that's proposed in HTTPS Token Binding and TLS Terminating Reverse Proxies because the TLS Terminating Reverse Proxy (TTRP), which we are trying to keep as "dumb" as possible, has to process the TokenBindingMessage to know the length of the EKM(s) that it will pass along in the Token-Binding-Context header/message. The Token-Binding-Context message also would need to be updated to allow for more than one EKM value. That feels rather ugly and somewhat undermines the effort to keep as much TB related processing out of the TTRP as possible. Thoughts on this? Seems to me like there are a few options, 1) Leave it as it is and suck up the complexity on the server side and in the TTRP spec. 2) Leave it as it is and suck up the complexity on the server side but change the model of the TTRP spec to do token binding validation and processing in the TTRP and pass just validated TokenBindingIDs (or something) to the back-end/origin server 3) Go back to TB only ever using 32 byte EKM values, which isn't as crypto agile but will likely be good enough for a long long time 4) Change things so that the EKM length used for all the TokenBindings in a single TokenBindingMessage is determined by the negotiated key parameters type. This simplifies things considerably while still providing some agility. The downside is not getting the benefits of a longer EKM when a referred would use it but the provided doesn't. Which doesn't seem that bad actually. 5) Something else and/or I'm confused and made a mistake in thinking about this whole issue. --94eb2c076d5ae4bfa2054925861f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Shortly after Seou= l TBPROTO-11 "Clarified that other si= gnature schemes may require longer exporter output", which general= ly seems like a good thing in terms of facilitating cryptographic agility g= oing forward (i.e. a super-duper signature scheme might need to sign over a= longer EKM to realize its super-duperness).

However, that future T= okenBindingKeyParameters type might use a longer EKM has some ramifications= when a TokenBindingMessage has more than one TokenBinding that maybe weren= 't fully considered. A server has to parse the TokenBindingMessage and = look at the TokenBindingKeyParameters of each TokenBinding in order to know= the length of the EKM to use in validating the signature on each. And poss= ibly have to get two (or more) different EKM values to service a single Tok= enBindingMessage or request. This situation only occurs when a referred_tok= en_binding is sent but that's a valid case that needs to be handled and= the server can't really know if it's there without parsing the mes= sage. So rather than getting the EKM based on the negotiated key parameters= type, the whole TokenBindingMessage needs to effectively be preprocessed.= =C2=A0

It's certainly possible to do things that way but = it seems potentially error prone (especially given that all the currently d= efined TokenBindingKeyParameters use 32 byte EKMs so there's likely an = ossification effect) and less than ideal.

It's even less = ideal for the model that's proposed in HTTPS Token Binding and TLS Term= inating Reverse Proxies because the TLS Terminating Reverse Proxy (TTRP= ), which we are trying to keep as "dumb" as possible, has to proc= ess the TokenBindingMessage to know the length of the EKM(s) that it will p= ass along in the Token-Binding-Context header/message. The Token-Binding-Co= ntext message also would need to be updated to allow for more than one EKM = value. That feels rather ugly and somewhat undermines the effort to keep as= much TB related processing out of the TTRP as possible.

Thou= ghts on this?

Seems to me like there are a few options,
1) Leave it as it is and suck up the complexity on the server side = and in the TTRP spec.

2) Leave it as it is and suck up the complexi= ty on the server side but change the model of the TTRP spec to do token bin= ding validation and processing in the TTRP and pass just validated TokenBin= dingIDs (or something) to the back-end/origin server

3) Go bac= k to TB only ever using 32 byte EKM values, which isn't as crypto agile= but will likely be good enough for a long long time

4) Change= things so that the EKM length used for all the TokenBindings in a single T= okenBindingMessage is determined by the negotiated key parameters type. Thi= s simplifies things considerably while still providing some agility. The do= wnside is not getting the benefits of a longer EKM when a referred would us= e it but the provided doesn't. Which doesn't seem that bad actually= .

5) Something else and/or I'm confused and made a mistak= e in thinking about this whole issue.


<= div>







=
--94eb2c076d5ae4bfa2054925861f-- From nobody Wed Feb 22 15:32:35 2017 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 8EC87129D20 for ; Wed, 22 Feb 2017 15:32:34 -0800 (PST) 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 bk99KUuJxpuC for ; Wed, 22 Feb 2017 15:32:32 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0103.outbound.protection.outlook.com [104.47.42.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D33F129D29 for ; Wed, 22 Feb 2017 15:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=knt51/e1NKCS+S5SAvJibC24rTZ8Rlh5hF+lhuDs5Bs=; b=DXKIJIMZfEAPkUDfnnL6n5RuMweCLnk5oPZwpVTUVqIz6fcBBSd4BomTwd8BpKZ3ebPuFZzpdYo38GsBP12JzNweHFzoLx2Laxk8OlWhWYA2r6PGf+v8clIrkfgE0bxRTXjH4ee3okE9IWounoGh0TdMQOkj08LyNt1clQl8bjc= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0841.namprd03.prod.outlook.com (10.160.163.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Wed, 22 Feb 2017 23:32:23 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0919.018; Wed, 22 Feb 2017 23:32:23 +0000 From: Andrei Popov To: Brian Campbell , IETF Tokbind WG Thread-Topic: [Unbearable] ramifications of longer EKMs Thread-Index: AQHSjVYgmQf/q9+NMUG8uI+0qEZ9BqF1ncIg Date: Wed, 22 Feb 2017 23:32:23 +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: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: 8e97bdc5-00e4-49c8-ea37-08d45b7b0dbf x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0841; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0841; 7:tfOHy0MrB7usyThrI90G9/H/BIwnHkYPpBCNDHYZtJ8PIvLRfpui0Tr9OJHjHV9jLDMt3ELiBUFWBjLMIchfUQcQOKbDhzjnjYNElQVLij4cMyzfeqihcJXKOUNyHA0QSMKn3QC0DCXrNyI7K4goP2Lb0wUeIxRk8yDqM8yHzxOdHJ+AVNntjRU8OxMY1g9jVjQMfeL1fXTFVRqlzMSfX7ZONOF9T0uDnyIZyQJXz9JVWidYgZslXm8kFSM0NCiaRXdCVfBbrj9aCIXEVMYwDBzf2YmpjGeKQbl7xy3xritNZo+BQmR8aslaJzFjZ90MvwgzD8/ONa9dVoGsmwvBmDOEs9gAdPRGsqWDp4zj3fw= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123558025)(20161123564025)(20161123555025)(6072148)(6042181); SRVR:CY1PR0301MB0841; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0841; x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(189998001)(106116001)(53546006)(8936002)(81166006)(74316002)(8676002)(38730400002)(6246003)(8990500004)(6116002)(7696004)(6436002)(2950100002)(33656002)(5005710100001)(10090500001)(2900100001)(10290500002)(7736002)(122556002)(5660300001)(790700001)(606005)(3660700001)(77096006)(92566002)(229853002)(50986999)(54356999)(102836003)(3280700002)(25786008)(2906002)(99286003)(55016002)(76176999)(86612001)(6306002)(53936002)(236005)(6506006)(54896002)(86362001)(9686003)(19609705001)(7906003)(148743002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0841; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:nspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842D765811AA4C37AE332938C500CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2017 23:32:23.4306 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0841 Archived-At: Subject: Re: [Unbearable] ramifications of longer EKMs 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, 22 Feb 2017 23:32:34 -0000 --_000_CY1PR0301MB0842D765811AA4C37AE332938C500CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIFdHIGRlY2lkZWQgdGhhdCB0aGUgbmVnb3RpYXRlZCBUQiBrZXkgcGFyYW1ldGVycyAoc3Bl Y2lmaWNhbGx5LCBzaWduYXR1cmUgc2NoZW1lKSwgcmF0aGVyIHRoYW4gVEIgdmVyc2lvbiwgZGV0 ZXJtaW5lIHRoZSBzaXplIG9mIHRoZSBFS00uIFRoaXMgbWVhbnMgdGhhdCBhIOKAnGR1bWLigJ0g KG9yIOKAnHNsaW3igJ0/KSBUVFJQIHN1cHBvcnRpbmcgVEIgdlggZG9lcyBub3QgZ3VhcmFudGVl IGNvbXBhdGliaWxpdHkgd2l0aCBhbGwgVEIga2V5IHR5cGVzIHRoYXQgbWF5IGJlIGRlZmluZWQg KHBlcmhhcHMsIGFmdGVyIHRoZSBUVFJQIHNoaXBzKSBmb3IgVEIgdlguDQoNCg0Kw5ggIEl0J3Mg ZXZlbiBsZXNzIGlkZWFsIGZvciB0aGUgbW9kZWwgdGhhdCdzIHByb3Bvc2VkIGluIEhUVFBTIFRv a2VuIEJpbmRpbmcgYW5kIFRMUyBUZXJtaW5hdGluZyBSZXZlcnNlIFByb3hpZXM8aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLXRva2JpbmQtdGxzLXRlcm0tMDA+IGJl Y2F1c2UgdGhlIFRMUyBUZXJtaW5hdGluZyBSZXZlcnNlIFByb3h5IChUVFJQKSwgd2hpY2ggd2Ug YXJlIHRyeWluZyB0byBrZWVwIGFzICJkdW1iIiBhcyBwb3NzaWJsZSwgaGFzIHRvIHByb2Nlc3Mg dGhlIFRva2VuQmluZGluZ01lc3NhZ2UgdG8ga25vdyB0aGUgbGVuZ3RoIG9mIHRoZSBFS00ocykg dGhhdCBpdCB3aWxsIHBhc3MgYWxvbmcgaW4gdGhlIFRva2VuLUJpbmRpbmctQ29udGV4dCBoZWFk ZXIvbWVzc2FnZS4NClBhcnNpbmcgVEIgbWVzc2FnZXMgYXQgVFRSUCBpcyBub3QgbmVjZXNzYXJ5 OiB0aGUgVFRSUCBjb3VsZCBwYXNzIGFsb25nIGFsbCBFS00gbGVuZ3RocyBpdCBzdXBwb3J0cyAo YXQgdGhlIGNvc3Qgb2YgZXh0cmEgYnl0ZXMgb24gdGhlIHdpcmUpLiBFdmVuIHRoZW4sIGEgbmV3 IHNpZ25hdHVyZSBzY2hlbWUgY2FuIGJlIGRlZmluZWQgcmVxdWlyaW5nIGFuIEVLTSBsZW5ndGgg dGhhdCBpcyBub3Qgc3VwcG9ydGVkIGJ5IHRoZSBUVFJQLg0KDQpNeSBwcmVmZXJyZWQgb3B0aW9u IGlzIDMpLCB3aGVyZSBUQiB2IDEuMCB3aWxsIG9ubHkgZXZlciB1c2UgMzItYnl0ZSBFS00gdmFs dWVzLiBGdXR1cmUgVEIgdmVyc2lvbnMgbWF5IGRlZmluZSBzb21lIG90aGVyIEVLTShzKS4NCkkg Y291bGQgbGl2ZSB3aXRoIG9wdGlvbiAxKSBhcyB3ZWxsLCBidXQgdGhlbiBJIHdvdWxkIGJlIHJl bHVjdGFudCB0byBuZWdvdGlhdGUgdGhvc2UgVEIga2V5IHBhcmFtZXRlcnMgdGhhdCByZXF1aXJl IGEgZGlmZmVyZW50IEVLTSBsZW5ndGggKGZvciBUQiB2IDEuMCkuIFdoaWNoIGVmZmVjdGl2ZWx5 IHR1cm5zIG9wdGlvbiAxKSBpbnRvIG9wdGlvbiAzKSDimLouDQpPcHRpb24gMikgZG9lcyBub3Qg bWFrZSBzZW5zZSB0byBtZSwgYmVjYXVzZSBUVFJQIGNhbuKAmXQgcmVhbGlzdGljYWxseSByZXF1 aXJlIG9uZSBwYXJ0aWN1bGFyIG1vZGVsIG9mIFRCIHByb2Nlc3NpbmcgaW4gYSBkYXRhY2VudGVy IChhcyB0aGVyZSBpcyBsaXR0bGUgcmVhc29uIGZvciBhIGRhdGFjZW50ZXIgb3BlcmF0b3IgdG8g Y29tcGx5KS4NCk9wdGlvbiA0KSBkZWZlYXRzIHRoZSBwdXJwb3NlIG9mIGhhdmluZyBwZXItc2ln bmF0dXJlLXNjaGVtZSBFS00gbGVuZ3Rocy4gSWYgd2UgZG9u4oCZdCBjYXJlIGZvciBwZXItc2ln bmF0dXJlLXNjaGVtZSBFS00gbGVuZ3RocywgdGhlbiB3ZSBzaG91bGQgZ28gd2l0aCAzKS4NCg0K Q2hlZXJzLA0KDQpBbmRyZWkNCg0KDQpGcm9tOiBVbmJlYXJhYmxlIFttYWlsdG86dW5iZWFyYWJs ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6IFdl ZG5lc2RheSwgRmVicnVhcnkgMjIsIDIwMTcgMTo1MyBQTQ0KVG86IElFVEYgVG9rYmluZCBXRyA8 dW5iZWFyYWJsZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtVbmJlYXJhYmxlXSByYW1pZmljYXRpb25z IG9mIGxvbmdlciBFS01zDQoNClNob3J0bHkgYWZ0ZXIgU2VvdWwgVEJQUk9UTy0xMSAiQ2xhcmlm aWVkIHRoYXQgb3RoZXIgc2lnbmF0dXJlIHNjaGVtZXMgbWF5IHJlcXVpcmUgbG9uZ2VyIGV4cG9y dGVyIG91dHB1dDxodHRwczovL2dpdGh1Yi5jb20vVG9rZW5CaW5kaW5nL0ludGVybmV0LURyYWZ0 cy9jb21taXQvY2FjOTlmN2M5MzM3ZjMyYzg1NzNjODc4ODc4ZDRkYTdmOWVlYjE4Nj4iLCB3aGlj aCBnZW5lcmFsbHkgc2VlbXMgbGlrZSBhIGdvb2QgdGhpbmcgaW4gdGVybXMgb2YgZmFjaWxpdGF0 aW5nIGNyeXB0b2dyYXBoaWMgYWdpbGl0eSBnb2luZyBmb3J3YXJkIChpLmUuIGEgc3VwZXItZHVw ZXIgc2lnbmF0dXJlIHNjaGVtZSBtaWdodCBuZWVkIHRvIHNpZ24gb3ZlciBhIGxvbmdlciBFS00g dG8gcmVhbGl6ZSBpdHMgc3VwZXItZHVwZXJuZXNzKS4NCg0KSG93ZXZlciwgdGhhdCBmdXR1cmUg VG9rZW5CaW5kaW5nS2V5UGFyYW1ldGVycyB0eXBlIG1pZ2h0IHVzZSBhIGxvbmdlciBFS00gaGFz IHNvbWUgcmFtaWZpY2F0aW9ucyB3aGVuIGEgVG9rZW5CaW5kaW5nTWVzc2FnZSBoYXMgbW9yZSB0 aGFuIG9uZSBUb2tlbkJpbmRpbmcgdGhhdCBtYXliZSB3ZXJlbid0IGZ1bGx5IGNvbnNpZGVyZWQu IEEgc2VydmVyIGhhcyB0byBwYXJzZSB0aGUgVG9rZW5CaW5kaW5nTWVzc2FnZSBhbmQgbG9vayBh dCB0aGUgVG9rZW5CaW5kaW5nS2V5UGFyYW1ldGVycyBvZiBlYWNoIFRva2VuQmluZGluZyBpbiBv cmRlciB0byBrbm93IHRoZSBsZW5ndGggb2YgdGhlIEVLTSB0byB1c2UgaW4gdmFsaWRhdGluZyB0 aGUgc2lnbmF0dXJlIG9uIGVhY2guIEFuZCBwb3NzaWJseSBoYXZlIHRvIGdldCB0d28gKG9yIG1v cmUpIGRpZmZlcmVudCBFS00gdmFsdWVzIHRvIHNlcnZpY2UgYSBzaW5nbGUgVG9rZW5CaW5kaW5n TWVzc2FnZSBvciByZXF1ZXN0LiBUaGlzIHNpdHVhdGlvbiBvbmx5IG9jY3VycyB3aGVuIGEgcmVm ZXJyZWRfdG9rZW5fYmluZGluZyBpcyBzZW50IGJ1dCB0aGF0J3MgYSB2YWxpZCBjYXNlIHRoYXQg bmVlZHMgdG8gYmUgaGFuZGxlZCBhbmQgdGhlIHNlcnZlciBjYW4ndCByZWFsbHkga25vdyBpZiBp dCdzIHRoZXJlIHdpdGhvdXQgcGFyc2luZyB0aGUgbWVzc2FnZS4gU28gcmF0aGVyIHRoYW4gZ2V0 dGluZyB0aGUgRUtNIGJhc2VkIG9uIHRoZSBuZWdvdGlhdGVkIGtleSBwYXJhbWV0ZXJzIHR5cGUs IHRoZSB3aG9sZSBUb2tlbkJpbmRpbmdNZXNzYWdlIG5lZWRzIHRvIGVmZmVjdGl2ZWx5IGJlIHBy ZXByb2Nlc3NlZC4NCkl0J3MgY2VydGFpbmx5IHBvc3NpYmxlIHRvIGRvIHRoaW5ncyB0aGF0IHdh eSBidXQgaXQgc2VlbXMgcG90ZW50aWFsbHkgZXJyb3IgcHJvbmUgKGVzcGVjaWFsbHkgZ2l2ZW4g dGhhdCBhbGwgdGhlIGN1cnJlbnRseSBkZWZpbmVkIFRva2VuQmluZGluZ0tleVBhcmFtZXRlcnMg dXNlIDMyIGJ5dGUgRUtNcyBzbyB0aGVyZSdzIGxpa2VseSBhbiBvc3NpZmljYXRpb24gZWZmZWN0 KSBhbmQgbGVzcyB0aGFuIGlkZWFsLg0KSXQncyBldmVuIGxlc3MgaWRlYWwgZm9yIHRoZSBtb2Rl bCB0aGF0J3MgcHJvcG9zZWQgaW4gSFRUUFMgVG9rZW4gQmluZGluZyBhbmQgVExTIFRlcm1pbmF0 aW5nIFJldmVyc2UgUHJveGllczxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2Ft cGJlbGwtdG9rYmluZC10bHMtdGVybS0wMD4gYmVjYXVzZSB0aGUgVExTIFRlcm1pbmF0aW5nIFJl dmVyc2UgUHJveHkgKFRUUlApLCB3aGljaCB3ZSBhcmUgdHJ5aW5nIHRvIGtlZXAgYXMgImR1bWIi IGFzIHBvc3NpYmxlLCBoYXMgdG8gcHJvY2VzcyB0aGUgVG9rZW5CaW5kaW5nTWVzc2FnZSB0byBr bm93IHRoZSBsZW5ndGggb2YgdGhlIEVLTShzKSB0aGF0IGl0IHdpbGwgcGFzcyBhbG9uZyBpbiB0 aGUgVG9rZW4tQmluZGluZy1Db250ZXh0IGhlYWRlci9tZXNzYWdlLiBUaGUgVG9rZW4tQmluZGlu Zy1Db250ZXh0IG1lc3NhZ2UgYWxzbyB3b3VsZCBuZWVkIHRvIGJlIHVwZGF0ZWQgdG8gYWxsb3cg Zm9yIG1vcmUgdGhhbiBvbmUgRUtNIHZhbHVlLiBUaGF0IGZlZWxzIHJhdGhlciB1Z2x5IGFuZCBz b21ld2hhdCB1bmRlcm1pbmVzIHRoZSBlZmZvcnQgdG8ga2VlcCBhcyBtdWNoIFRCIHJlbGF0ZWQg cHJvY2Vzc2luZyBvdXQgb2YgdGhlIFRUUlAgYXMgcG9zc2libGUuDQpUaG91Z2h0cyBvbiB0aGlz Pw0KU2VlbXMgdG8gbWUgbGlrZSB0aGVyZSBhcmUgYSBmZXcgb3B0aW9ucywNCjEpIExlYXZlIGl0 IGFzIGl0IGlzIGFuZCBzdWNrIHVwIHRoZSBjb21wbGV4aXR5IG9uIHRoZSBzZXJ2ZXIgc2lkZSBh bmQgaW4gdGhlIFRUUlAgc3BlYy4NCg0KMikgTGVhdmUgaXQgYXMgaXQgaXMgYW5kIHN1Y2sgdXAg dGhlIGNvbXBsZXhpdHkgb24gdGhlIHNlcnZlciBzaWRlIGJ1dCBjaGFuZ2UgdGhlIG1vZGVsIG9m IHRoZSBUVFJQIHNwZWMgdG8gZG8gdG9rZW4gYmluZGluZyB2YWxpZGF0aW9uIGFuZCBwcm9jZXNz aW5nIGluIHRoZSBUVFJQIGFuZCBwYXNzIGp1c3QgdmFsaWRhdGVkIFRva2VuQmluZGluZ0lEcyAo b3Igc29tZXRoaW5nKSB0byB0aGUgYmFjay1lbmQvb3JpZ2luIHNlcnZlcg0KMykgR28gYmFjayB0 byBUQiBvbmx5IGV2ZXIgdXNpbmcgMzIgYnl0ZSBFS00gdmFsdWVzLCB3aGljaCBpc24ndCBhcyBj cnlwdG8gYWdpbGUgYnV0IHdpbGwgbGlrZWx5IGJlIGdvb2QgZW5vdWdoIGZvciBhIGxvbmcgbG9u ZyB0aW1lDQo0KSBDaGFuZ2UgdGhpbmdzIHNvIHRoYXQgdGhlIEVLTSBsZW5ndGggdXNlZCBmb3Ig YWxsIHRoZSBUb2tlbkJpbmRpbmdzIGluIGEgc2luZ2xlIFRva2VuQmluZGluZ01lc3NhZ2UgaXMg ZGV0ZXJtaW5lZCBieSB0aGUgbmVnb3RpYXRlZCBrZXkgcGFyYW1ldGVycyB0eXBlLiBUaGlzIHNp bXBsaWZpZXMgdGhpbmdzIGNvbnNpZGVyYWJseSB3aGlsZSBzdGlsbCBwcm92aWRpbmcgc29tZSBh Z2lsaXR5LiBUaGUgZG93bnNpZGUgaXMgbm90IGdldHRpbmcgdGhlIGJlbmVmaXRzIG9mIGEgbG9u Z2VyIEVLTSB3aGVuIGEgcmVmZXJyZWQgd291bGQgdXNlIGl0IGJ1dCB0aGUgcHJvdmlkZWQgZG9l c24ndC4gV2hpY2ggZG9lc24ndCBzZWVtIHRoYXQgYmFkIGFjdHVhbGx5Lg0KNSkgU29tZXRoaW5n IGVsc2UgYW5kL29yIEknbSBjb25mdXNlZCBhbmQgbWFkZSBhIG1pc3Rha2UgaW4gdGhpbmtpbmcg YWJvdXQgdGhpcyB3aG9sZSBpc3N1ZS4NCg0KDQoNCg0KDQoNCg== --_000_CY1PR0301MB0842D765811AA4C37AE332938C500CY1PR0301MB0842_ 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 OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt Y29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1OTk4NzM1ODA7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xOTIzNzA0NDggLTc4MTU2Mzg2OCA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxp YnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGww OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBXRyBkZWNpZGVkIHRo YXQgdGhlIG5lZ290aWF0ZWQgVEIga2V5IHBhcmFtZXRlcnMgKHNwZWNpZmljYWxseSwgc2lnbmF0 dXJlIHNjaGVtZSksIHJhdGhlciB0aGFuIFRCIHZlcnNpb24sIGRldGVybWluZSB0aGUgc2l6ZSBv ZiB0aGUgRUtNLiBUaGlzIG1lYW5zIHRoYXQgYSDigJxkdW1i4oCdIChvciDigJxzbGlt4oCdPykN CiBUVFJQIHN1cHBvcnRpbmcgVEIgdlggZG9lcyBub3QgZ3VhcmFudGVlIGNvbXBhdGliaWxpdHkg d2l0aCBhbGwgVEIga2V5IHR5cGVzIHRoYXQgbWF5IGJlIGRlZmluZWQgKHBlcmhhcHMsIGFmdGVy IHRoZSBUVFJQIHNoaXBzKSBmb3IgVEIgdlguPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SXQn cyBldmVuIGxlc3MgaWRlYWwgZm9yIHRoZSBtb2RlbCB0aGF0J3MgcHJvcG9zZWQgaW4NCjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC10b2tiaW5kLXRs cy10ZXJtLTAwIj5IVFRQUyBUb2tlbiBCaW5kaW5nIGFuZCBUTFMgVGVybWluYXRpbmcgUmV2ZXJz ZSBQcm94aWVzPC9hPiBiZWNhdXNlIHRoZSBUTFMgVGVybWluYXRpbmcgUmV2ZXJzZSBQcm94eSAo VFRSUCksIHdoaWNoIHdlIGFyZSB0cnlpbmcgdG8ga2VlcCBhcyAmcXVvdDtkdW1iJnF1b3Q7IGFz IHBvc3NpYmxlLCBoYXMgdG8gcHJvY2VzcyB0aGUgVG9rZW5CaW5kaW5nTWVzc2FnZQ0KIHRvIGtu b3cgdGhlIGxlbmd0aCBvZiB0aGUgRUtNKHMpIHRoYXQgaXQgd2lsbCBwYXNzIGFsb25nIGluIHRo ZSBUb2tlbi1CaW5kaW5nLUNvbnRleHQgaGVhZGVyL21lc3NhZ2UuPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPlBhcnNpbmcgVEIgbWVzc2FnZXMgYXQgVFRSUCBpcyBub3QgbmVjZXNzYXJ5OiB0aGUgVFRS UCBjb3VsZCBwYXNzIGFsb25nIGFsbCBFS00gbGVuZ3RocyBpdCBzdXBwb3J0cyAoYXQgdGhlIGNv c3Qgb2YgZXh0cmEgYnl0ZXMgb24gdGhlIHdpcmUpLiBFdmVuIHRoZW4sIGEgbmV3IHNpZ25hdHVy ZSBzY2hlbWUNCiBjYW4gYmUgZGVmaW5lZCByZXF1aXJpbmcgYW4gRUtNIGxlbmd0aCB0aGF0IGlz IG5vdCBzdXBwb3J0ZWQgYnkgdGhlIFRUUlAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk15IHByZWZlcnJlZCBv cHRpb24gaXMgMyksIHdoZXJlIFRCIHYgMS4wIHdpbGwgb25seSBldmVyIHVzZSAzMi1ieXRlIEVL TSB2YWx1ZXMuIEZ1dHVyZSBUQiB2ZXJzaW9ucyBtYXkgZGVmaW5lIHNvbWUgb3RoZXIgRUtNKHMp LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+SSBjb3VsZCBsaXZlIHdpdGggb3B0aW9uIDEpIGFzIHdlbGwsIGJ1dCB0aGVuIEkgd291 bGQgYmUgcmVsdWN0YW50IHRvIG5lZ290aWF0ZSB0aG9zZSBUQiBrZXkgcGFyYW1ldGVycyB0aGF0 IHJlcXVpcmUgYSBkaWZmZXJlbnQgRUtNIGxlbmd0aCAoZm9yIFRCIHYgMS4wKS4gV2hpY2ggZWZm ZWN0aXZlbHkNCiB0dXJucyBvcHRpb24gMSkgaW50byBvcHRpb24gMykgPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+Sjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPk9wdGlvbiAyKSBkb2VzIG5vdCBtYWtlIHNlbnNlIHRvIG1lLCBi ZWNhdXNlIFRUUlAgY2Fu4oCZdCByZWFsaXN0aWNhbGx5IHJlcXVpcmUgb25lIHBhcnRpY3VsYXIg bW9kZWwgb2YgVEIgcHJvY2Vzc2luZyBpbiBhIGRhdGFjZW50ZXIgKGFzIHRoZXJlIGlzIGxpdHRs ZSByZWFzb24gZm9yIGEgZGF0YWNlbnRlcg0KIG9wZXJhdG9yIHRvIGNvbXBseSkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5PcHRp b24gNCkgZGVmZWF0cyB0aGUgcHVycG9zZSBvZiBoYXZpbmcgcGVyLXNpZ25hdHVyZS1zY2hlbWUg RUtNIGxlbmd0aHMuIElmIHdlIGRvbuKAmXQgY2FyZSBmb3IgcGVyLXNpZ25hdHVyZS1zY2hlbWUg RUtNIGxlbmd0aHMsIHRoZW4gd2Ugc2hvdWxkIGdvIHdpdGggMykuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNo ZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kcmVpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFVuYmVhcmFibGUgW21haWx0bzp1bmJl YXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIENhbXBi ZWxsPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMjIsIDIwMTcgMTo1MyBQ TTxicj4NCjxiPlRvOjwvYj4gSUVURiBUb2tiaW5kIFdHICZsdDt1bmJlYXJhYmxlQGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbVW5iZWFyYWJsZV0gcmFtaWZpY2F0aW9ucyBvZiBs b25nZXIgRUtNczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5TaG9ydGx5IGFmdGVyIFNlb3VsIFRCUFJPVE8tMTEgJnF1b3Q7 PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL1Rva2VuQmluZGluZy9JbnRlcm5ldC1EcmFmdHMv Y29tbWl0L2NhYzk5ZjdjOTMzN2YzMmM4NTczYzg3ODg3OGQ0ZGE3ZjllZWIxODYiPkNsYXJpZmll ZCB0aGF0IG90aGVyIHNpZ25hdHVyZSBzY2hlbWVzIG1heSByZXF1aXJlIGxvbmdlciBleHBvcnRl ciBvdXRwdXQ8L2E+JnF1b3Q7LA0KIHdoaWNoIGdlbmVyYWxseSBzZWVtcyBsaWtlIGEgZ29vZCB0 aGluZyBpbiB0ZXJtcyBvZiBmYWNpbGl0YXRpbmcgY3J5cHRvZ3JhcGhpYyBhZ2lsaXR5IGdvaW5n IGZvcndhcmQgKGkuZS4gYSBzdXBlci1kdXBlciBzaWduYXR1cmUgc2NoZW1lIG1pZ2h0IG5lZWQg dG8gc2lnbiBvdmVyIGEgbG9uZ2VyIEVLTSB0byByZWFsaXplIGl0cyBzdXBlci1kdXBlcm5lc3Mp Lg0KPGJyPg0KPGJyPg0KSG93ZXZlciwgdGhhdCBmdXR1cmUgVG9rZW5CaW5kaW5nS2V5UGFyYW1l dGVycyB0eXBlIG1pZ2h0IHVzZSBhIGxvbmdlciBFS00gaGFzIHNvbWUgcmFtaWZpY2F0aW9ucyB3 aGVuIGEgVG9rZW5CaW5kaW5nTWVzc2FnZSBoYXMgbW9yZSB0aGFuIG9uZSBUb2tlbkJpbmRpbmcg dGhhdCBtYXliZSB3ZXJlbid0IGZ1bGx5IGNvbnNpZGVyZWQuIEEgc2VydmVyIGhhcyB0byBwYXJz ZSB0aGUgVG9rZW5CaW5kaW5nTWVzc2FnZSBhbmQgbG9vayBhdCB0aGUgVG9rZW5CaW5kaW5nS2V5 UGFyYW1ldGVycw0KIG9mIGVhY2ggVG9rZW5CaW5kaW5nIGluIG9yZGVyIHRvIGtub3cgdGhlIGxl bmd0aCBvZiB0aGUgRUtNIHRvIHVzZSBpbiB2YWxpZGF0aW5nIHRoZSBzaWduYXR1cmUgb24gZWFj aC4gQW5kIHBvc3NpYmx5IGhhdmUgdG8gZ2V0IHR3byAob3IgbW9yZSkgZGlmZmVyZW50IEVLTSB2 YWx1ZXMgdG8gc2VydmljZSBhIHNpbmdsZSBUb2tlbkJpbmRpbmdNZXNzYWdlIG9yIHJlcXVlc3Qu IFRoaXMgc2l0dWF0aW9uIG9ubHkgb2NjdXJzIHdoZW4gYSByZWZlcnJlZF90b2tlbl9iaW5kaW5n DQogaXMgc2VudCBidXQgdGhhdCdzIGEgdmFsaWQgY2FzZSB0aGF0IG5lZWRzIHRvIGJlIGhhbmRs ZWQgYW5kIHRoZSBzZXJ2ZXIgY2FuJ3QgcmVhbGx5IGtub3cgaWYgaXQncyB0aGVyZSB3aXRob3V0 IHBhcnNpbmcgdGhlIG1lc3NhZ2UuIFNvIHJhdGhlciB0aGFuIGdldHRpbmcgdGhlIEVLTSBiYXNl ZCBvbiB0aGUgbmVnb3RpYXRlZCBrZXkgcGFyYW1ldGVycyB0eXBlLCB0aGUgd2hvbGUgVG9rZW5C aW5kaW5nTWVzc2FnZSBuZWVkcyB0byBlZmZlY3RpdmVseQ0KIGJlIHByZXByb2Nlc3NlZC4mbmJz cDsgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+SXQncyBjZXJ0YWlubHkgcG9zc2libGUgdG8gZG8gdGhpbmdz IHRoYXQgd2F5IGJ1dCBpdCBzZWVtcyBwb3RlbnRpYWxseSBlcnJvciBwcm9uZSAoZXNwZWNpYWxs eSBnaXZlbiB0aGF0IGFsbCB0aGUgY3VycmVudGx5IGRlZmluZWQgVG9rZW5CaW5kaW5nS2V5UGFy YW1ldGVycyB1c2UgMzIgYnl0ZSBFS01zIHNvIHRoZXJlJ3MgbGlrZWx5IGFuIG9zc2lmaWNhdGlv bg0KIGVmZmVjdCkgYW5kIGxlc3MgdGhhbiBpZGVhbC4gPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SXQncyBl dmVuIGxlc3MgaWRlYWwgZm9yIHRoZSBtb2RlbCB0aGF0J3MgcHJvcG9zZWQgaW4NCjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC10b2tiaW5kLXRscy10 ZXJtLTAwIj5IVFRQUyBUb2tlbiBCaW5kaW5nIGFuZCBUTFMgVGVybWluYXRpbmcgUmV2ZXJzZSBQ cm94aWVzPC9hPiBiZWNhdXNlIHRoZSBUTFMgVGVybWluYXRpbmcgUmV2ZXJzZSBQcm94eSAoVFRS UCksIHdoaWNoIHdlIGFyZSB0cnlpbmcgdG8ga2VlcCBhcyAmcXVvdDtkdW1iJnF1b3Q7IGFzIHBv c3NpYmxlLCBoYXMgdG8gcHJvY2VzcyB0aGUgVG9rZW5CaW5kaW5nTWVzc2FnZQ0KIHRvIGtub3cg dGhlIGxlbmd0aCBvZiB0aGUgRUtNKHMpIHRoYXQgaXQgd2lsbCBwYXNzIGFsb25nIGluIHRoZSBU b2tlbi1CaW5kaW5nLUNvbnRleHQgaGVhZGVyL21lc3NhZ2UuIFRoZSBUb2tlbi1CaW5kaW5nLUNv bnRleHQgbWVzc2FnZSBhbHNvIHdvdWxkIG5lZWQgdG8gYmUgdXBkYXRlZCB0byBhbGxvdyBmb3Ig bW9yZSB0aGFuIG9uZSBFS00gdmFsdWUuIFRoYXQgZmVlbHMgcmF0aGVyIHVnbHkgYW5kIHNvbWV3 aGF0IHVuZGVybWluZXMgdGhlIGVmZm9ydA0KIHRvIGtlZXAgYXMgbXVjaCBUQiByZWxhdGVkIHBy b2Nlc3Npbmcgb3V0IG9mIHRoZSBUVFJQIGFzIHBvc3NpYmxlLiA8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5U aG91Z2h0cyBvbiB0aGlzPyA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5TZWVtcyB0byBtZSBsaWtlIHRoZXJl IGFyZSBhIGZldyBvcHRpb25zLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjEpIExlYXZlIGl0IGFzIGl0IGlz IGFuZCBzdWNrIHVwIHRoZSBjb21wbGV4aXR5IG9uIHRoZSBzZXJ2ZXIgc2lkZSBhbmQgaW4gdGhl IFRUUlAgc3BlYy4NCjxicj4NCjxicj4NCjIpIExlYXZlIGl0IGFzIGl0IGlzIGFuZCBzdWNrIHVw IHRoZSBjb21wbGV4aXR5IG9uIHRoZSBzZXJ2ZXIgc2lkZSBidXQgY2hhbmdlIHRoZSBtb2RlbCBv ZiB0aGUgVFRSUCBzcGVjIHRvIGRvIHRva2VuIGJpbmRpbmcgdmFsaWRhdGlvbiBhbmQgcHJvY2Vz c2luZyBpbiB0aGUgVFRSUCBhbmQgcGFzcyBqdXN0IHZhbGlkYXRlZCBUb2tlbkJpbmRpbmdJRHMg KG9yIHNvbWV0aGluZykgdG8gdGhlIGJhY2stZW5kL29yaWdpbiBzZXJ2ZXI8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij4zKSBHbyBiYWNrIHRvIFRCIG9ubHkgZXZlciB1c2luZyAzMiBieXRlIEVLTSB2YWx1ZXMs IHdoaWNoIGlzbid0IGFzIGNyeXB0byBhZ2lsZSBidXQgd2lsbCBsaWtlbHkgYmUgZ29vZCBlbm91 Z2ggZm9yIGEgbG9uZyBsb25nIHRpbWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij40KSBDaGFuZ2UgdGhpbmdz IHNvIHRoYXQgdGhlIEVLTSBsZW5ndGggdXNlZCBmb3IgYWxsIHRoZSBUb2tlbkJpbmRpbmdzIGlu IGEgc2luZ2xlIFRva2VuQmluZGluZ01lc3NhZ2UgaXMgZGV0ZXJtaW5lZCBieSB0aGUgbmVnb3Rp YXRlZCBrZXkgcGFyYW1ldGVycyB0eXBlLiBUaGlzIHNpbXBsaWZpZXMgdGhpbmdzIGNvbnNpZGVy YWJseSB3aGlsZSBzdGlsbCBwcm92aWRpbmcNCiBzb21lIGFnaWxpdHkuIFRoZSBkb3duc2lkZSBp cyBub3QgZ2V0dGluZyB0aGUgYmVuZWZpdHMgb2YgYSBsb25nZXIgRUtNIHdoZW4gYSByZWZlcnJl ZCB3b3VsZCB1c2UgaXQgYnV0IHRoZSBwcm92aWRlZCBkb2Vzbid0LiBXaGljaCBkb2Vzbid0IHNl ZW0gdGhhdCBiYWQgYWN0dWFsbHkuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij41KSBTb21ldGhpbmcgZWxz ZSBhbmQvb3IgSSdtIGNvbmZ1c2VkIGFuZCBtYWRlIGEgbWlzdGFrZSBpbiB0aGlua2luZyBhYm91 dCB0aGlzIHdob2xlIGlzc3VlLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_CY1PR0301MB0842D765811AA4C37AE332938C500CY1PR0301MB0842_-- From nobody Wed Feb 22 16:09:33 2017 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 82FE8129CDA for ; Wed, 22 Feb 2017 16:09:31 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 KThFZHE4JNkg for ; Wed, 22 Feb 2017 16:09:28 -0800 (PST) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002: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 94577129CD1 for ; Wed, 22 Feb 2017 16:09:28 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id a5so5089774ybb.2 for ; Wed, 22 Feb 2017 16:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jirn5KL/Ud3aMB7rEyibM3BykG7splW6zJsWA1Yq/RU=; b=pmYR+fz4jLujeBrg5WX4+80jb1ozKYxrzI5lOJdJ9blaLxtAoYRSLjv01RMmwQssx8 2ZJwmdKoWYN7RM3hZfMWwdZ2ctW6sJ2+qH+KPZECApECjdJDTiPTF7qtE+JCKPmi2P20 Wirvi94pN3dZaIin7+b9KUIYHQfhAlJjHC9b8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Jirn5KL/Ud3aMB7rEyibM3BykG7splW6zJsWA1Yq/RU=; b=hRSYXENa47Zu/istrzdjfh/oJGsrriU1FUuViuxSf82OyMvY6TdCEanR97rr41KBz1 QoV2gq6Bl5huliVOpYHZqI5nY/9e7Ik7TspxYeRD6sYchCEYedqTT5mOexWs57m1DJoO R7qY4aNINf7abrEF3IQBN2QEulDK5Ji3N9fWz7A2PAdArI82upWzPLkwLYeWVwHT9h2D b5e7BB2A3jDtfNL+t3gz+PS9O1E0Hv/8sQ1ekxz/nYtvX1B62DjsMKi8bgKDcjybjlsg /YufRiTAYXlIdLgb4cZkaFDcSK8qIVx0RDjGUWXi2Rkbs3Yfl9da1kjkhxM2tfgUyd4O cUbw== X-Gm-Message-State: AMke39nSphf+G86yGOEofUxphQ/XLe58m67zvw1bLJ20NZvGHkInCjBr+nrdnphuUaK2/b16ytMkRIJRT2CkYRWc X-Received: by 10.37.163.38 with SMTP id d35mr5178828ybi.32.1487808567598; Wed, 22 Feb 2017 16:09:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.126.131 with HTTP; Wed, 22 Feb 2017 16:08:57 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Wed, 22 Feb 2017 17:08:57 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=94eb2c19a52c2a803f0549276d3e Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] ramifications of longer EKMs 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: Thu, 23 Feb 2017 00:09:31 -0000 --94eb2c19a52c2a803f0549276d3e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > The WG decided that the negotiated TB key parameters (specifically, > signature scheme), rather than TB version, determine the size of the EKM. > This means that a =E2=80=9Cdumb=E2=80=9D (or =E2=80=9Cslim=E2=80=9D?) TTR= P supporting TB vX does not > guarantee compatibility with all TB key types that may be defined (perhap= s, > after the TTRP ships) for TB vX. > That's true. And matching up supported TB key parameters will likely be a challenge for the currently proposed TTRP support model regardless. Parsing TB messages at TTRP is not necessary: the TTRP could pass along all > EKM lengths it supports (at the cost of extra bytes on the wire). Even > then, a new signature scheme can be defined requiring an EKM length that = is > not supported by the TTRP. > That's a good point and an approach I hadn't considered. Allows for the TTRP stay similarly "dumb"/"slim". The extra bytes cost is not ideal and it's feels a little ugly. But would probably be better than the parsing approach I was thinking of. > > > My preferred option is 3), where TB v 1.0 will only ever use 32-byte EKM > values. Future TB versions may define some other EKM(s). > > I could live with option 1) as well, but then I would be reluctant to > negotiate those TB key parameters that require a different EKM length (fo= r > TB v 1.0). Which effectively turns option 1) into option 3) J. > I don't know that it would necessarily turn option 1) into option 3) but I can see and concede the point. > Option 2) does not make sense to me, because TTRP can=E2=80=99t realistic= ally > require one particular model of TB processing in a datacenter (as there i= s > little reason for a datacenter operator to comply). > I'm not sure I follow this? I'd think, if this kind of model was used, a TTRP could do all the TB validation work and just expose the TB ID(s) to the backend where they can bind to whatever tokens/cookies they are issuing. The backend apps would only be able to use TB key parameters that the TTRP supports but that's pretty much true of the other model too - the TTRP still is the one negotiating. > Option 4) defeats the purpose of having per-signature-scheme EKM lengths. > If we don=E2=80=99t care for per-signature-scheme EKM lengths, then we sh= ould go > with 3). > It only defeats the purpose of having per-signature-scheme EKM lengths in the case of a refereed TB using a longer EKM than the provided. Which should be a much less common occurrence and something that would dissipate over time as the new TB key parameters type gets adopted/deployed. On Wed, Feb 22, 2017 at 4:32 PM, Andrei Popov wrote: > The WG decided that the negotiated TB key parameters (specifically, > signature scheme), rather than TB version, determine the size of the EKM. > This means that a =E2=80=9Cdumb=E2=80=9D (or =E2=80=9Cslim=E2=80=9D?) TTR= P supporting TB vX does not > guarantee compatibility with all TB key types that may be defined (perhap= s, > after the TTRP ships) for TB vX. > > > > =C3=98 It's even less ideal for the model that's proposed in HTTPS Token > Binding and TLS Terminating Reverse Proxies > because > the TLS Terminating Reverse Proxy (TTRP), which we are trying to keep as > "dumb" as possible, has to process the TokenBindingMessage to know the > length of the EKM(s) that it will pass along in the Token-Binding-Context > header/message. > > Parsing TB messages at TTRP is not necessary: the TTRP could pass along > all EKM lengths it supports (at the cost of extra bytes on the wire). Eve= n > then, a new signature scheme can be defined requiring an EKM length that = is > not supported by the TTRP. > > > > My preferred option is 3), where TB v 1.0 will only ever use 32-byte EKM > values. Future TB versions may define some other EKM(s). > > I could live with option 1) as well, but then I would be reluctant to > negotiate those TB key parameters that require a different EKM length (fo= r > TB v 1.0). Which effectively turns option 1) into option 3) J. > > Option 2) does not make sense to me, because TTRP can=E2=80=99t realistic= ally > require one particular model of TB processing in a datacenter (as there i= s > little reason for a datacenter operator to comply). > > Option 4) defeats the purpose of having per-signature-scheme EKM lengths. > If we don=E2=80=99t care for per-signature-scheme EKM lengths, then we sh= ould go > with 3). > > > > Cheers, > > > > Andrei > > > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Br= ian > Campbell > *Sent:* Wednesday, February 22, 2017 1:53 PM > *To:* IETF Tokbind WG > *Subject:* [Unbearable] ramifications of longer EKMs > > > > Shortly after Seoul TBPROTO-11 "Clarified that other signature schemes > may require longer exporter output > ", > which generally seems like a good thing in terms of facilitating > cryptographic agility going forward (i.e. a super-duper signature scheme > might need to sign over a longer EKM to realize its super-duperness). > > However, that future TokenBindingKeyParameters type might use a longer EK= M > has some ramifications when a TokenBindingMessage has more than one > TokenBinding that maybe weren't fully considered. A server has to parse t= he > TokenBindingMessage and look at the TokenBindingKeyParameters of each > TokenBinding in order to know the length of the EKM to use in validating > the signature on each. And possibly have to get two (or more) different E= KM > values to service a single TokenBindingMessage or request. This situation > only occurs when a referred_token_binding is sent but that's a valid case > that needs to be handled and the server can't really know if it's there > without parsing the message. So rather than getting the EKM based on the > negotiated key parameters type, the whole TokenBindingMessage needs to > effectively be preprocessed. > > It's certainly possible to do things that way but it seems potentially > error prone (especially given that all the currently defined > TokenBindingKeyParameters use 32 byte EKMs so there's likely an > ossification effect) and less than ideal. > > It's even less ideal for the model that's proposed in HTTPS Token Binding > and TLS Terminating Reverse Proxies > because > the TLS Terminating Reverse Proxy (TTRP), which we are trying to keep as > "dumb" as possible, has to process the TokenBindingMessage to know the > length of the EKM(s) that it will pass along in the Token-Binding-Context > header/message. The Token-Binding-Context message also would need to be > updated to allow for more than one EKM value. That feels rather ugly and > somewhat undermines the effort to keep as much TB related processing out = of > the TTRP as possible. > > Thoughts on this? > > Seems to me like there are a few options, > > 1) Leave it as it is and suck up the complexity on the server side and in > the TTRP spec. > > 2) Leave it as it is and suck up the complexity on the server side but > change the model of the TTRP spec to do token binding validation and > processing in the TTRP and pass just validated TokenBindingIDs (or > something) to the back-end/origin server > > 3) Go back to TB only ever using 32 byte EKM values, which isn't as crypt= o > agile but will likely be good enough for a long long time > > 4) Change things so that the EKM length used for all the TokenBindings in > a single TokenBindingMessage is determined by the negotiated key paramete= rs > type. This simplifies things considerably while still providing some > agility. The downside is not getting the benefits of a longer EKM when a > referred would use it but the provided doesn't. Which doesn't seem that b= ad > actually. > > 5) Something else and/or I'm confused and made a mistake in thinking abou= t > this whole issue. > > > > > > > > --94eb2c19a52c2a803f0549276d3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The WG decided that the negotiated TB key parameters (specifically,=20 signature scheme), rather than TB version, determine the size of the=20 EKM. This means that a =E2=80=9Cdumb=E2=80=9D (or =E2=80=9Cslim=E2=80=9D?) TTRP supporting TB vX does not guarantee compatibility with all TB key=20 types that may be defined (perhaps, after the TTRP ships) for TB vX.=


That's true. And matching= =20 up supported TB key parameters will likely be a challenge for the=20 currently proposed TTRP support model regardless.=C2=A0

=

Parsing TB messages at TTRP is not necessary: the TTRP could pass along all EKM lengths it supports (at the cost of extra bytes on the wire). Even=20 then, a new signature scheme can be defined requiring an EKM length that is not supported by the=20 TTRP.

That's a good = point and an approach I hadn't considered. Allows for the TTRP stay sim= ilarly "dumb"/"slim".=C2=A0 The extra bytes cost is not= ideal and it's feels a little ugly. But would probably be better than = the parsing approach I was thinking of.
=C2=A0

=C2=A0

My preferred option is 3), where TB v 1.0 will only ever use 32-byte EKM=20 values. Future TB versions may define some other EKM(s).

I could live with option 1) as well, but then I would be reluctant to=20 negotiate those TB key parameters that require a different EKM length=20 (for TB v 1.0). Which effectively turns option 1) into option 3) J.


I don't know that it would necessarily turn option 1) into option= 3) but I can see and concede the point.
=C2=A0

<= /p>

Option 2) does not make sense to me, because TTRP can=E2=80=99t realistically req= uire=20 one particular model of TB processing in a datacenter (as there is=20 little reason for a datacenter operator to comply).


I'm not sure I follow this?

I'd think, if this= kind of model was used, a TTRP could do all the TB validation work and jus= t expose the TB ID(s) to the backend where they can bind to whatever tokens= /cookies they are issuing. The backend apps would only be able to use TB ke= y parameters that the TTRP supports but that's pretty much true of the = other model too - the TTRP still is the one negotiating.
=C2= =A0

Option 4) defeats the purpose of having per-signature-scheme EKM lengths. If=20 we don=E2=80=99t care for per-signature-scheme EKM lengths, then we should = go=20 with 3).


It only def= eats the purpose of having per-signature-scheme EKM lengths in the case of = a refereed TB using a longer EKM than the provided. Which should be a much = less common occurrence and something that would dissipate over time as the = new TB key parameters type gets adopted/deployed.
=C2=A0

On We= d, Feb 22, 2017 at 4:32 PM, Andrei Popov <Andrei.Popov@microsoft.= com> wrote:

The WG decided that the negotiated TB key parameter= s (specifically, signature scheme), rather than TB version, determine the s= ize of the EKM. This means that a =E2=80=9Cdumb=E2=80=9D (or =E2=80=9Cslim= =E2=80=9D?) TTRP supporting TB vX does not guarantee compatibility with all TB key typ= es that may be defined (perhaps, after the TTRP ships) for TB vX.=

=C2=A0

=C3=98=C2=A0 It's even less ideal for the model that'= ;s proposed in HTTPS Token Binding and TLS Terminating Reverse Proxies because the TLS Terminating Reverse Proxy (TTRP), which we are trying to= keep as "dumb" as possible, has to process the TokenBindingMessa= ge to know the length of the EKM(s) that it will pass along in the Token-Bind= ing-Context header/message.

Parsing TB messages at TTRP is not necessary: the T= TRP could pass along all EKM lengths it supports (at the cost of extra byte= s on the wire). Even then, a new signature scheme can be defined requiring an EKM length that is not supported by the TTRP.<= u>

=C2=A0

My preferred option is 3), where TB v 1.0 will only= ever use 32-byte EKM values. Future TB versions may define some other EKM(= s).

I could live with option 1) as well, but then I wou= ld be reluctant to negotiate those TB key parameters that require a differe= nt EKM length (for TB v 1.0). Which effectively turns option 1) into option 3) J.

Option 2) does not make sense to me, because TTRP c= an=E2=80=99t realistically require one particular model of TB processing in= a datacenter (as there is little reason for a datacenter operator to comply).

Option 4) defeats the purpose of having per-signatu= re-scheme EKM lengths. If we don=E2=80=99t care for per-signature-scheme EK= M lengths, then we should go with 3).

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, February 22, 2017 1:53 PM
To: IETF Tokbind WG <unbearable@ietf.org>
Subject: [Unbearable] ramifications of longer EKMs

=C2=A0

Shortly after Seoul T= BPROTO-11 "Clarifie= d that other signature schemes may require longer exporter output"= , which generally seems like a good thing in terms of facilitating cryptogra= phic agility going forward (i.e. a super-duper signature scheme might need = to sign over a longer EKM to realize its super-duperness).

However, that future TokenBindingKeyParameters type might use a longer EKM = has some ramifications when a TokenBindingMessage has more than one TokenBi= nding that maybe weren't fully considered. A server has to parse the To= kenBindingMessage and look at the TokenBindingKeyParameters of each TokenBinding in order to know the length of the EKM to use in vali= dating the signature on each. And possibly have to get two (or more) differ= ent EKM values to service a single TokenBindingMessage or request. This sit= uation only occurs when a referred_token_binding is sent but that's a valid case that needs to be handled and the serve= r can't really know if it's there without parsing the message. So r= ather than getting the EKM based on the negotiated key parameters type, the= whole TokenBindingMessage needs to effectively be preprocessed.=C2=A0

It's certainly po= ssible to do things that way but it seems potentially error prone (especial= ly given that all the currently defined TokenBindingKeyParameters use 32 by= te EKMs so there's likely an ossification effect) and less than ideal.

It's even less id= eal for the model that's proposed in HTTPS Token Binding and TLS Terminating Reverse Proxies because the TLS Terminating Reverse Proxy (TTRP), which we are trying to= keep as "dumb" as possible, has to process the TokenBindingMessa= ge to know the length of the EKM(s) that it will pass along in the Token-Bind= ing-Context header/message. The Token-Binding-Context message also would ne= ed to be updated to allow for more than one EKM value. That feels rather ug= ly and somewhat undermines the effort to keep as much TB related processing out of the TTRP as possible. =

Thoughts on this? =

Seems to me like ther= e are a few options,

1) Leave it as it is = and suck up the complexity on the server side and in the TTRP spec.

2) Leave it as it is and suck up the complexity on the server side but chan= ge the model of the TTRP spec to do token binding validation and processing= in the TTRP and pass just validated TokenBindingIDs (or something) to the = back-end/origin server

3) Go back to TB only= ever using 32 byte EKM values, which isn't as crypto agile but will li= kely be good enough for a long long time

4) Change things so t= hat the EKM length used for all the TokenBindings in a single TokenBindingM= essage is determined by the negotiated key parameters type. This simplifies= things considerably while still providing some agility. The downside is not getting the benefits of a longer EKM whe= n a referred would use it but the provided doesn't. Which doesn't s= eem that bad actually.

5) Something else and= /or I'm confused and made a mistake in thinking about this whole issue.=

=C2=A0<= /p>






--94eb2c19a52c2a803f0549276d3e-- From nobody Wed Feb 22 16:39:16 2017 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 3267B12896F for ; Wed, 22 Feb 2017 16:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 AG2_sdIqtnFU for ; Wed, 22 Feb 2017 16:39:13 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0113.outbound.protection.outlook.com [104.47.42.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B87081293DC for ; Wed, 22 Feb 2017 16:39:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xgaZbEriXeIE0cPTk03ndgykkL4vn6IXW7ck8euZ140=; b=Mfssjwh9sqDjUJM/p3GENboBjjQ0AavnW7+wtRXElqehmFRkfZeCIBkNEBYG5A1wSebEQCOUiLvjUjJx5QTiyIHXHgRguq75eJt4bBPXoN1B6UsEcAD4FkDBh31uidXbIXED2J48M+lQl9Bck16SZQuOSFDUh6prN/uWYuJUQSE= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0843.namprd03.prod.outlook.com (10.160.163.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Thu, 23 Feb 2017 00:39:09 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0919.018; Thu, 23 Feb 2017 00:39:08 +0000 From: Andrei Popov To: Brian Campbell Thread-Topic: [Unbearable] ramifications of longer EKMs Thread-Index: AQHSjVYgmQf/q9+NMUG8uI+0qEZ9BqF1ncIggAAZn4CAAACqsA== Date: Thu, 23 Feb 2017 00:39:08 +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: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: 61c13ace-98cc-41d5-7fa7-08d45b84611e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0843; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0843; 7:fRyjE6LGvlxaBVoBqmO0dAuykIJ0NehKIt2Uw8N+5HpdBulyM5XMXIz3MJgDTrKWs836kQzxg0yCa6q39IZL3lXUH+oQcIQ3DNp1U7Cpx5I2+NwWGUTTdMiC3m5nhfYi4CToMCiRuuT6/goJZYMwa8+Utx1LMzDDtnDgVxEIGZexiBhndv90Sxs0xkvSIUvLhUND10GThk2JwQ9rPyGz2Sdj2f3pbgDlWP8of7GFeC6JuHk18BfGdOcFD+CP0kfBzl/tiRpxidRTsc7LfXfoaEct4LMwrhwC2diZz5sFiOw0RyDfTLHSVygCakNnf8XGZxdqPv0lqegV5gyTM5z1MPxJMX1GWYSRFKTSU4L+QBw= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558025)(6072148); SRVR:CY1PR0301MB0843; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0843; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39840400002)(39860400002)(39450400003)(54356999)(76176999)(10090500001)(2950100002)(2906002)(106116001)(92566002)(50986999)(3280700002)(4326007)(7696004)(33656002)(8676002)(2900100001)(6116002)(790700001)(3660700001)(5660300001)(102836003)(9686003)(54896002)(110136004)(25786008)(189998001)(38730400002)(6246003)(229853002)(122556002)(99286003)(55016002)(10290500002)(6306002)(53936002)(8990500004)(5005710100001)(8936002)(74316002)(6436002)(6506006)(86612001)(77096006)(81166006)(6916009)(7736002)(86362001)(148743002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0843; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:nspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842C76A829D345AAC18FB988C530CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 00:39:08.7719 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0843 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] ramifications of longer EKMs 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: Thu, 23 Feb 2017 00:39:15 -0000 --_000_CY1PR0301MB0842C76A829D345AAC18FB988C530CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEknbSBub3Qgc3VyZSBJIGZvbGxvdyB0aGlzPw0KDQrDmCAgSSdkIHRoaW5rLCBpZiB0aGlz IGtpbmQgb2YgbW9kZWwgd2FzIHVzZWQsIGEgVFRSUCBjb3VsZCBkbyBhbGwgdGhlIFRCIHZhbGlk YXRpb24gd29yayBhbmQganVzdCBleHBvc2UgdGhlIFRCIElEKHMpIHRvIHRoZSBiYWNrZW5kIHdo ZXJlIHRoZXkgY2FuIGJpbmQgdG8gd2hhdGV2ZXIgdG9rZW5zL2Nvb2tpZXMgdGhleSBhcmUgaXNz dWluZy4NClN1cmUsIHRoaXMgZGVzaWduIHdvdWxkIHdvcmsuIE15IHBvaW50IGlzIHRoYXQgdGhl IHRva2JpbmQtdGxzLXRlcm0gZG9jdW1lbnQgY2Fubm90IHJlcXVpcmUgb25lIHBhcnRpY3VsYXIg bW9kZWwgb2YgVEIgcHJvY2Vzc2luZywgYmVjYXVzZSBpZiB0aGlzIG9uZSBtb2RlbCBkb2VzIG5v dCBtZWV0IGEgZGF0YSBjZW50ZXLigJlzIHJlcXVpcmVtZW50cy9hcmNoaXRlY3R1cmUsIHRoZSBk b2N1bWVudCBpcyBlYXNpbHkgaWdub3JlZC4gQW5kIGl0IHdvdWxkIGJlIHBhcnRpY3VsYXJseSB1 bmRlc2lyYWJsZSB0byBsb3NlIHRoZSDigJxkdW1iL3NsaW3igJ0gVFRSUCBtb2RlbC4NCg0Kw5gg IFRoZSBiYWNrZW5kIGFwcHMgd291bGQgb25seSBiZSBhYmxlIHRvIHVzZSBUQiBrZXkgcGFyYW1l dGVycyB0aGF0IHRoZSBUVFJQIHN1cHBvcnRzIGJ1dCB0aGF0J3MgcHJldHR5IG11Y2ggdHJ1ZSBv ZiB0aGUgb3RoZXIgbW9kZWwgdG9vIC0gdGhlIFRUUlAgc3RpbGwgaXMgdGhlIG9uZSBuZWdvdGlh dGluZy4NCkJhY2tlbmQgY291bGQgcGFzcyB0aGUgVEIga2V5IHBhcmFtZXRlcnMgdG8gdGhlIFRU UlAsIG9yIHRoZXNlIGNvdWxkIGJlIHBhcnQgb2YgdGhlIFRUUlAgY29uZmlndXJhdGlvbi4gQWxs IHRoZSDigJxkdW1iL3NsaW3igJ0gVFRSUCBuZWVkcyB0byBrbm93IGlzIFRCIHByb3RvY29sIHZl cnNpb24gYW5kIGEgcHJpb3JpdGl6ZWQgbGlzdCBvZiBUQiBrZXkgcGFyYW1ldGVyIElEcy4NCg0K w5ggIEl0IG9ubHkgZGVmZWF0cyB0aGUgcHVycG9zZSBvZiBoYXZpbmcgcGVyLXNpZ25hdHVyZS1z Y2hlbWUgRUtNIGxlbmd0aHMgaW4gdGhlIGNhc2Ugb2YgYSByZWZlcmVlZCBUQiB1c2luZyBhIGxv bmdlciBFS00gdGhhbiB0aGUgcHJvdmlkZWQuDQpMZXTigJlzIHNheSBhIGNsaWVudCBuZWdvdGlh dGVzIHNpZ25hdHVyZSBzY2hlbWUgQSB3aXRoIHRoZSBSUCwgYW5kIHNpZ25hdHVyZSBzY2hlbWUg QSBjYWxscyBmb3IgYSA2NC1iaXQgRUtNLiBUaGVuIHRoZSBjbGllbnQgbmVnb3RpYXRlcyBhIHNp Z25hdHVyZSBzY2hlbWUgQiB3aXRoIHRoZSBJRFAsIGFuZCBzaWduYXR1cmUgc2NoZW1lIEIgY2Fs bHMgZm9yIGEgMzItYml0IEVLTS4gVGhlIGNsaWVudCBzZW5kcyBQcm92aWRlZCBhbmQgUmVmZXJy ZWQgYmluZGluZ3MgdG8gdGhpcyBJRFAsIGFuZCB0aGUgUmVmZXJyZWQgYmluZGluZyB1c2VzIHNp Z25hdHVyZSBzY2hlbWUgQSBpbiBjb21iaW5hdGlvbiB3aXRoIGFuIEVLTSBsZW5ndGggMzIgKHdo aWNoIGRvZXMgbm90IGFncmVlIHdpdGggdGhlIHNpZ25hdHVyZSBzY2hlbWUgZGVmaW5pdGlvbiku IElzIHRoaXMgd2hhdCB5b3XigJlyZSBwcm9wb3NpbmcgYXMgb3B0aW9uIDQpLCBvciBkaWQgSSBn ZXQgaXQgd3Jvbmc/DQo= --_000_CY1PR0301MB0842C76A829D345AAC18FB988C530CY1PR0301MB0842_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuZ21haWwtbTE1OTU5NDQ0OTIxNjM3MDEwNjltc29saXN0 cGFyYWdyYXBoLCBsaS5nbWFpbC1tMTU5NTk0NDQ5MjE2MzcwMTA2OW1zb2xpc3RwYXJhZ3JhcGgs IGRpdi5nbWFpbC1tMTU5NTk0NDQ5MjE2MzcwMTA2OW1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLW5hbWU6Z21haWwtbV8xNTk1OTQ0NDkyMTYzNzAxMDY5bXNvbGlzdHBhcmFncmFwaDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubTE1OTU5NDQ0OTIxNjM3 MDEwNjltc29saXN0cGFyYWdyYXBoLCBsaS5tMTU5NTk0NDQ5MjE2MzcwMTA2OW1zb2xpc3RwYXJh Z3JhcGgsIGRpdi5tMTU5NTk0NDQ5MjE2MzcwMTA2OW1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLW5hbWU6bV8xNTk1OTQ0NDkyMTYzNzAxMDY5bXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjAyNzQxMDQ4Ow0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTM1MTE3NTA0 NiAtMTc0MTM4NjQwNCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLXN0YXJ0LWF0OjQ7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkknbSBub3Qgc3VyZSBJIGZvbGxvdyB0aGlzPyA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkknZCB0aGluaywgaWYgdGhpcyBraW5kIG9m IG1vZGVsIHdhcyB1c2VkLCBhIFRUUlAgY291bGQgZG8gYWxsIHRoZSBUQiB2YWxpZGF0aW9uIHdv cmsgYW5kIGp1c3QgZXhwb3NlIHRoZSBUQiBJRChzKSB0byB0aGUgYmFja2VuZCB3aGVyZSB0aGV5 IGNhbiBiaW5kIHRvIHdoYXRldmVyIHRva2Vucy9jb29raWVzIHRoZXkgYXJlIGlzc3VpbmcuDQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdXJlLCB0 aGlzIGRlc2lnbiB3b3VsZCB3b3JrLiBNeSBwb2ludCBpcyB0aGF0IHRoZSB0b2tiaW5kLXRscy10 ZXJtIGRvY3VtZW50IGNhbm5vdCByZXF1aXJlIG9uZSBwYXJ0aWN1bGFyIG1vZGVsIG9mIFRCIHBy b2Nlc3NpbmcsIGJlY2F1c2UgaWYgdGhpcw0KIG9uZSBtb2RlbCBkb2VzIG5vdCBtZWV0IGEgZGF0 YSBjZW50ZXLigJlzIHJlcXVpcmVtZW50cy9hcmNoaXRlY3R1cmUsIHRoZSBkb2N1bWVudCBpcyBl YXNpbHkgaWdub3JlZC4gQW5kIGl0IHdvdWxkIGJlIHBhcnRpY3VsYXJseSB1bmRlc2lyYWJsZSB0 byBsb3NlIHRoZSDigJxkdW1iL3NsaW3igJ0gVFRSUCBtb2RlbC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpX aW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT5UaGUgYmFja2VuZCBhcHBzIHdvdWxkIG9ubHkgYmUgYWJsZSB0 byB1c2UgVEIga2V5IHBhcmFtZXRlcnMgdGhhdCB0aGUgVFRSUCBzdXBwb3J0cyBidXQgdGhhdCdz IHByZXR0eSBtdWNoIHRydWUgb2YgdGhlIG90aGVyIG1vZGVsIHRvbyAtIHRoZSBUVFJQIHN0aWxs IGlzIHRoZSBvbmUgbmVnb3RpYXRpbmcuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5CYWNr ZW5kIGNvdWxkIHBhc3MgdGhlIFRCIGtleSBwYXJhbWV0ZXJzIHRvIHRoZSBUVFJQLCBvciB0aGVz ZSBjb3VsZCBiZSBwYXJ0IG9mIHRoZSBUVFJQIGNvbmZpZ3VyYXRpb24uIEFsbCB0aGUg4oCcZHVt Yi9zbGlt4oCdIFRUUlAgbmVlZHMgdG8ga25vdw0KIGlzIFRCIHByb3RvY29sIHZlcnNpb24gYW5k IGEgcHJpb3JpdGl6ZWQgbGlzdCBvZiBUQiBrZXkgcGFyYW1ldGVyIElEcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+SXQgb25seSBkZWZlYXRzIHRoZSBwdXJwb3NlIG9mIGhhdmluZyBwZXItc2lnbmF0dXJlLXNj aGVtZSBFS00gbGVuZ3RocyBpbiB0aGUgY2FzZSBvZiBhIHJlZmVyZWVkIFRCIHVzaW5nIGEgbG9u Z2VyIEVLTSB0aGFuIHRoZSBwcm92aWRlZC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkxl dOKAmXMgc2F5IGEgY2xpZW50IG5lZ290aWF0ZXMgc2lnbmF0dXJlIHNjaGVtZSBBIHdpdGggdGhl IFJQLCBhbmQgc2lnbmF0dXJlIHNjaGVtZSBBIGNhbGxzIGZvciBhIDY0LWJpdCBFS00uIFRoZW4g dGhlIGNsaWVudCBuZWdvdGlhdGVzIGEgc2lnbmF0dXJlDQogc2NoZW1lIEIgd2l0aCB0aGUgSURQ LCBhbmQgc2lnbmF0dXJlIHNjaGVtZSBCIGNhbGxzIGZvciBhIDMyLWJpdCBFS00uIFRoZSBjbGll bnQgc2VuZHMgUHJvdmlkZWQgYW5kIFJlZmVycmVkIGJpbmRpbmdzIHRvIHRoaXMgSURQLCBhbmQg dGhlIFJlZmVycmVkIGJpbmRpbmcgdXNlcyBzaWduYXR1cmUgc2NoZW1lIEEgaW4gY29tYmluYXRp b24gd2l0aCBhbiBFS00gbGVuZ3RoIDMyICh3aGljaCBkb2VzIG5vdCBhZ3JlZSB3aXRoIHRoZSBz aWduYXR1cmUNCiBzY2hlbWUgZGVmaW5pdGlvbikuIElzIHRoaXMgd2hhdCB5b3XigJlyZSBwcm9w b3NpbmcgYXMgb3B0aW9uIDQpLCBvciBkaWQgSSBnZXQgaXQgd3Jvbmc/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR0301MB0842C76A829D345AAC18FB988C530CY1PR0301MB0842_-- From nobody Wed Feb 22 17:13:10 2017 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 04A5412949A for ; Wed, 22 Feb 2017 17:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 lOtaKGA-nJmO for ; Wed, 22 Feb 2017 17:13:07 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0098.outbound.protection.outlook.com [104.47.32.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 269DF12948D for ; Wed, 22 Feb 2017 17:04:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3EXQYHKbrGSWZ7SJ3J98rmGmClSUCTSl+SndASKUhA8=; b=Oef/jiJ8WXFuT3bs4abc6LayuyBWkPNOjDlAMb/Ljww9pu8CbmZTHtu+5TxR2ErzndKCPRQLdzv6BGBa4i6u8pq5b1FF/4KxA/20zIqm9DeIU+IXEIfp64b0Z2ep/Vre1BjQxwkzzenIsOf4nwgVi5Uzfdina4DFsljrfPIVCP4= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0843.namprd03.prod.outlook.com (10.160.163.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Thu, 23 Feb 2017 01:03:59 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0919.018; Thu, 23 Feb 2017 01:03:59 +0000 From: Andrei Popov To: Brian Campbell Thread-Topic: [Unbearable] ramifications of longer EKMs Thread-Index: AQHSjVYgmQf/q9+NMUG8uI+0qEZ9BqF1ncIggAAZn4CAAACqsIAADg1Q Date: Thu, 23 Feb 2017 01:03:59 +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: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: 03b07b83-5e78-4aa3-8e36-08d45b87d994 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0843; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0843; 7:VNbB4ZYwUld5yHYPbA1x0+WuwujRkZUannaC6Yq+UgttbOKiItpay7ugu451EVIhxKxORqkbGHieRr19I7eQzGBKWRNFNSswNNs6Kw82ni7KSo4RYKujc8BQxn2OH7xScWm3lPKZ7/26BSIKpJeEWm80aFmEM8hJ1dabQ4SYByOkR7xqcnbRkbda8wpeRa+KE7nACD/Q4HtMclrNEKX0EL+xVi7oQjASNAIgvqXXRSA5fQJwFUS9Pgm3IKEOn/zVFGk3YlRBt3G3l5MieSOJrLC3SpNwn91SeYwyCbTgnB/P2xRu+bMVz/+bG4sde7QZPCKoRTCwlWXls4sj2J3Y7JMoL+wMK0VmkDYYWcV+EIk= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558025)(6072148); SRVR:CY1PR0301MB0843; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0843; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39840400002)(39450400003)(39860400002)(377454003)(54356999)(76176999)(10090500001)(2950100002)(2906002)(92566002)(106116001)(50986999)(3280700002)(4326007)(7696004)(33656002)(8676002)(2900100001)(6116002)(790700001)(3660700001)(93886004)(5660300001)(102836003)(9686003)(54896002)(110136004)(25786008)(189998001)(38730400002)(6246003)(99286003)(229853002)(122556002)(55016002)(10290500002)(6306002)(53936002)(8990500004)(53546006)(8936002)(6436002)(74316002)(6506006)(86612001)(77096006)(5005710100001)(81166006)(6916009)(19609705001)(7736002)(86362001)(148743002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0843; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:nspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842026E974F75CE28AA264C8C530CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 01:03:59.3780 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0843 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] ramifications of longer EKMs 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: Thu, 23 Feb 2017 01:13:09 -0000 --_000_CY1PR0301MB0842026E974F75CE28AA264C8C530CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29ycmVjdGlvbiBpbmxpbmXimLouDQoNCkZyb206IFVuYmVhcmFibGUgW21haWx0bzp1bmJlYXJh YmxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmRyZWkgUG9wb3YNClNlbnQ6IFdl ZG5lc2RheSwgRmVicnVhcnkgMjIsIDIwMTcgNDozOSBQTQ0KVG86IEJyaWFuIENhbXBiZWxsIDxi Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4NCkNjOiBJRVRGIFRva2JpbmQgV0cgPHVuYmVhcmFi bGVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIHJhbWlmaWNhdGlvbnMgb2Yg bG9uZ2VyIEVLTXMNCg0KDQrDmCAgSSdtIG5vdCBzdXJlIEkgZm9sbG93IHRoaXM/DQoNCsOYICBJ J2QgdGhpbmssIGlmIHRoaXMga2luZCBvZiBtb2RlbCB3YXMgdXNlZCwgYSBUVFJQIGNvdWxkIGRv IGFsbCB0aGUgVEIgdmFsaWRhdGlvbiB3b3JrIGFuZCBqdXN0IGV4cG9zZSB0aGUgVEIgSUQocykg dG8gdGhlIGJhY2tlbmQgd2hlcmUgdGhleSBjYW4gYmluZCB0byB3aGF0ZXZlciB0b2tlbnMvY29v a2llcyB0aGV5IGFyZSBpc3N1aW5nLg0KU3VyZSwgdGhpcyBkZXNpZ24gd291bGQgd29yay4gTXkg cG9pbnQgaXMgdGhhdCB0aGUgdG9rYmluZC10bHMtdGVybSBkb2N1bWVudCBjYW5ub3QgcmVxdWly ZSBvbmUgcGFydGljdWxhciBtb2RlbCBvZiBUQiBwcm9jZXNzaW5nLCBiZWNhdXNlIGlmIHRoaXMg b25lIG1vZGVsIGRvZXMgbm90IG1lZXQgYSBkYXRhIGNlbnRlcuKAmXMgcmVxdWlyZW1lbnRzL2Fy Y2hpdGVjdHVyZSwgdGhlIGRvY3VtZW50IGlzIGVhc2lseSBpZ25vcmVkLiBBbmQgaXQgd291bGQg YmUgcGFydGljdWxhcmx5IHVuZGVzaXJhYmxlIHRvIGxvc2UgdGhlIOKAnGR1bWIvc2xpbeKAnSBU VFJQIG1vZGVsLg0KDQrDmCAgVGhlIGJhY2tlbmQgYXBwcyB3b3VsZCBvbmx5IGJlIGFibGUgdG8g dXNlIFRCIGtleSBwYXJhbWV0ZXJzIHRoYXQgdGhlIFRUUlAgc3VwcG9ydHMgYnV0IHRoYXQncyBw cmV0dHkgbXVjaCB0cnVlIG9mIHRoZSBvdGhlciBtb2RlbCB0b28gLSB0aGUgVFRSUCBzdGlsbCBp cyB0aGUgb25lIG5lZ290aWF0aW5nLg0KQmFja2VuZCBjb3VsZCBwYXNzIHRoZSBUQiBrZXkgcGFy YW1ldGVycyB0byB0aGUgVFRSUCwgb3IgdGhlc2UgY291bGQgYmUgcGFydCBvZiB0aGUgVFRSUCBj b25maWd1cmF0aW9uLiBBbGwgdGhlIOKAnGR1bWIvc2xpbeKAnSBUVFJQIG5lZWRzIHRvIGtub3cg aXMgVEIgcHJvdG9jb2wgdmVyc2lvbiBhbmQgYSBwcmlvcml0aXplZCBsaXN0IG9mIFRCIGtleSBw YXJhbWV0ZXIgSURzLg0KDQrDmCAgSXQgb25seSBkZWZlYXRzIHRoZSBwdXJwb3NlIG9mIGhhdmlu ZyBwZXItc2lnbmF0dXJlLXNjaGVtZSBFS00gbGVuZ3RocyBpbiB0aGUgY2FzZSBvZiBhIHJlZmVy ZWVkIFRCIHVzaW5nIGEgbG9uZ2VyIEVLTSB0aGFuIHRoZSBwcm92aWRlZC4NCkxldOKAmXMgc2F5 IGEgY2xpZW50IG5lZ290aWF0ZXMgc2lnbmF0dXJlIHNjaGVtZSBBIHdpdGggdGhlIFJQLCBhbmQg c2lnbmF0dXJlIHNjaGVtZSBBIGNhbGxzIGZvciBhIDY0LWJ5dGUgRUtNLiBUaGVuIHRoZSBjbGll bnQgbmVnb3RpYXRlcyBhIHNpZ25hdHVyZSBzY2hlbWUgQiB3aXRoIHRoZSBJRFAsIGFuZCBzaWdu YXR1cmUgc2NoZW1lIEIgY2FsbHMgZm9yIGEgMzItYnl0ZSBFS00uIFRoZSBjbGllbnQgc2VuZHMg UHJvdmlkZWQgYW5kIFJlZmVycmVkIGJpbmRpbmdzIHRvIHRoaXMgSURQLCBhbmQgdGhlIFJlZmVy cmVkIGJpbmRpbmcgdXNlcyBzaWduYXR1cmUgc2NoZW1lIEEgaW4gY29tYmluYXRpb24gd2l0aCBh biBFS00gbGVuZ3RoIDMyICh3aGljaCBkb2VzIG5vdCBhZ3JlZSB3aXRoIHRoZSBzaWduYXR1cmUg c2NoZW1lIGRlZmluaXRpb24pLiBJcyB0aGlzIHdoYXQgeW914oCZcmUgcHJvcG9zaW5nIGFzIG9w dGlvbiA0KSwgb3IgZGlkIEkgZ2V0IGl0IHdyb25nPw0K --_000_CY1PR0301MB0842026E974F75CE28AA264C8C530CY1PR0301MB0842_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuZ21haWwtbTE1OTU5NDQ0OTIxNjM3MDEwNjltc29saXN0 cGFyYWdyYXBoLCBsaS5nbWFpbC1tMTU5NTk0NDQ5MjE2MzcwMTA2OW1zb2xpc3RwYXJhZ3JhcGgs IGRpdi5nbWFpbC1tMTU5NTk0NDQ5MjE2MzcwMTA2OW1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLW5hbWU6Z21haWwtbV8xNTk1OTQ0NDkyMTYzNzAxMDY5bXNvbGlzdHBhcmFncmFwaDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubTE1OTU5NDQ0OTIxNjM3 MDEwNjltc29saXN0cGFyYWdyYXBoLCBsaS5tMTU5NTk0NDQ5MjE2MzcwMTA2OW1zb2xpc3RwYXJh Z3JhcGgsIGRpdi5tMTU5NTk0NDQ5MjE2MzcwMTA2OW1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLW5hbWU6bV8xNTk1OTQ0NDkyMTYzNzAxMDY5bXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww DQoJe21zby1saXN0LWlkOjEyMDI3NDEwNDg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOi0xMzUxMTc1MDQ2IC0xNzQxMzg2NDA0IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6NDsNCgltc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2JhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVs bG93Ij5Db3JyZWN0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGlubGluZTwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3MiPko8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVW5iZWFyYWJs ZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+QW5kcmVpIFBvcG92PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMjIs IDIwMTcgNDozOSBQTTxicj4NCjxiPlRvOjwvYj4gQnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBUb2tiaW5kIFdHICZs dDt1bmJlYXJhYmxlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVh cmFibGVdIHJhbWlmaWNhdGlvbnMgb2YgbG9uZ2VyIEVLTXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpX aW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT5JJ20gbm90IHN1cmUgSSBmb2xsb3cgdGhpcz8gPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5JJ2QgdGhpbmssIGlmIHRoaXMga2luZCBvZiBtb2RlbCB3 YXMgdXNlZCwgYSBUVFJQIGNvdWxkIGRvIGFsbCB0aGUgVEIgdmFsaWRhdGlvbiB3b3JrIGFuZCBq dXN0IGV4cG9zZSB0aGUgVEIgSUQocykgdG8gdGhlIGJhY2tlbmQgd2hlcmUgdGhleSBjYW4gYmlu ZCB0byB3aGF0ZXZlciB0b2tlbnMvY29va2llcyB0aGV5IGFyZSBpc3N1aW5nLg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U3VyZSwgdGhpcyBkZXNp Z24gd291bGQgd29yay4gTXkgcG9pbnQgaXMgdGhhdCB0aGUgdG9rYmluZC10bHMtdGVybSBkb2N1 bWVudCBjYW5ub3QgcmVxdWlyZSBvbmUgcGFydGljdWxhciBtb2RlbCBvZiBUQiBwcm9jZXNzaW5n LCBiZWNhdXNlIGlmIHRoaXMNCiBvbmUgbW9kZWwgZG9lcyBub3QgbWVldCBhIGRhdGEgY2VudGVy 4oCZcyByZXF1aXJlbWVudHMvYXJjaGl0ZWN0dXJlLCB0aGUgZG9jdW1lbnQgaXMgZWFzaWx5IGln bm9yZWQuIEFuZCBpdCB3b3VsZCBiZSBwYXJ0aWN1bGFybHkgdW5kZXNpcmFibGUgdG8gbG9zZSB0 aGUg4oCcZHVtYi9zbGlt4oCdIFRUUlAgbW9kZWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2Rpbmdz Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+VGhlIGJhY2tlbmQgYXBwcyB3b3VsZCBvbmx5IGJlIGFibGUgdG8gdXNlIFRC IGtleSBwYXJhbWV0ZXJzIHRoYXQgdGhlIFRUUlAgc3VwcG9ydHMgYnV0IHRoYXQncyBwcmV0dHkg bXVjaCB0cnVlIG9mIHRoZSBvdGhlciBtb2RlbCB0b28gLSB0aGUgVFRSUCBzdGlsbCBpcyB0aGUg b25lIG5lZ290aWF0aW5nLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QmFja2VuZCBjb3Vs ZCBwYXNzIHRoZSBUQiBrZXkgcGFyYW1ldGVycyB0byB0aGUgVFRSUCwgb3IgdGhlc2UgY291bGQg YmUgcGFydCBvZiB0aGUgVFRSUCBjb25maWd1cmF0aW9uLiBBbGwgdGhlIOKAnGR1bWIvc2xpbeKA nSBUVFJQIG5lZWRzIHRvIGtub3cNCiBpcyBUQiBwcm90b2NvbCB2ZXJzaW9uIGFuZCBhIHByaW9y aXRpemVkIGxpc3Qgb2YgVEIga2V5IHBhcmFtZXRlciBJRHMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkl0IG9u bHkgZGVmZWF0cyB0aGUgcHVycG9zZSBvZiBoYXZpbmcgcGVyLXNpZ25hdHVyZS1zY2hlbWUgRUtN IGxlbmd0aHMgaW4gdGhlIGNhc2Ugb2YgYSByZWZlcmVlZCBUQiB1c2luZyBhIGxvbmdlciBFS00g dGhhbiB0aGUgcHJvdmlkZWQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5MZXTigJlzIHNh eSBhIGNsaWVudCBuZWdvdGlhdGVzIHNpZ25hdHVyZSBzY2hlbWUgQSB3aXRoIHRoZSBSUCwgYW5k IHNpZ25hdHVyZSBzY2hlbWUgQSBjYWxscyBmb3IgYSA2NC08c3BhbiBzdHlsZT0iYmFja2dyb3Vu ZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPmJ5dGU8L3NwYW4+DQogRUtNLiBUaGVuIHRo ZSBjbGllbnQgbmVnb3RpYXRlcyBhIHNpZ25hdHVyZSBzY2hlbWUgQiB3aXRoIHRoZSBJRFAsIGFu ZCBzaWduYXR1cmUgc2NoZW1lIEIgY2FsbHMgZm9yIGEgMzItPHNwYW4gc3R5bGU9ImJhY2tncm91 bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij5ieXRlPC9zcGFuPiBFS00uIFRoZSBjbGll bnQgc2VuZHMgUHJvdmlkZWQgYW5kIFJlZmVycmVkIGJpbmRpbmdzIHRvIHRoaXMgSURQLCBhbmQg dGhlIFJlZmVycmVkIGJpbmRpbmcNCiB1c2VzIHNpZ25hdHVyZSBzY2hlbWUgQSBpbiBjb21iaW5h dGlvbiB3aXRoIGFuIEVLTSBsZW5ndGggMzIgKHdoaWNoIGRvZXMgbm90IGFncmVlIHdpdGggdGhl IHNpZ25hdHVyZSBzY2hlbWUgZGVmaW5pdGlvbikuIElzIHRoaXMgd2hhdCB5b3XigJlyZSBwcm9w b3NpbmcgYXMgb3B0aW9uIDQpLCBvciBkaWQgSSBnZXQgaXQgd3Jvbmc/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR0301MB0842026E974F75CE28AA264C8C530CY1PR0301MB0842_-- From nobody Thu Feb 23 05:18:42 2017 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 674C11297AC for ; Thu, 23 Feb 2017 05:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 QP8CehRUjGE9 for ; Thu, 23 Feb 2017 05:18:40 -0800 (PST) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002: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 9EFA6129717 for ; Thu, 23 Feb 2017 05:18:39 -0800 (PST) Received: by mail-yb0-x22d.google.com with SMTP id i66so8723971yba.1 for ; Thu, 23 Feb 2017 05:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d0yWMOiM0ESaxQ7pHl4uCHrCai0nflMJWV3yCdcDRQQ=; b=Hcm/2EWGneIGbHSLPQsVf+tu5b4/QYqWaAu6mbT2/nIyVH7lz4IE/Sn1rDxgUNe5tQ IXjmFO8TtDFdQyN+shNKnGavNasMQTrMGpsEnCmDJFSSpJqCNmuKkF02+bmujPFGD6qy t5/x4Grc1gAHfvzRtHzi12074Jgi2OiBgqUds= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d0yWMOiM0ESaxQ7pHl4uCHrCai0nflMJWV3yCdcDRQQ=; b=JfWQd9aY/oG5EQzZhZ1e7hCyM3F/IiQWlF2VJHPMguqx9rL+cDIt/YExaAKh0MIPnh ZnEEzjBoeBN9PP1A9eygRtTkaUDdJZ0FNWUg+pihrK3yhSXKoe/qPW7Zy+5Ig5fL0aOB kFN2VGh2+6/3kM3w9mZsxKRckfpSry6SgxndmeHQMnGUa4MvmWaTLSQGTOmyJMNhUxC6 dgJDAWyDlJGg4RHnr+Q0iUZCOGKcdLh1SrpTayAyKwss9P6PBqmfGYizvoCSCdxd0CwR moSECl7SARFxBEWpy+1c37Am9ygbCh61ITwslZWUnx3Yh8fJhH95JECw26A5YjNDsnCO qrnA== X-Gm-Message-State: AMke39mJoum6eIiIsGkKoMR1hBQZqW3zKNlVpaIC3sy72LEm8GupgTsZgLQVxVXx4/tZt8/hJjraiUCwwrGB8DyR X-Received: by 10.37.78.3 with SMTP id c3mr27024066ybb.180.1487855918785; Thu, 23 Feb 2017 05:18:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.126.131 with HTTP; Thu, 23 Feb 2017 05:18:08 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Thu, 23 Feb 2017 06:18:08 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a113e7fae84489b054932736a Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] ramifications of longer EKMs 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: Thu, 23 Feb 2017 13:18:41 -0000 --001a113e7fae84489b054932736a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > Sure, this design would work. My point is that the tokbind-tls-term > document cannot require one particular model of TB processing, because if > this one model does not meet a data center=E2=80=99s requirements/archite= cture, the > document is easily ignored. And it would be particularly undesirable to > lose the =E2=80=9Cdumb/slim=E2=80=9D TTRP model. > Are you suggesting that tokbind-tls-term should have more than one model? Or that the =E2=80=9Cdumb/slim=E2=80=9D TTRP model is most likely to be the= desired model? Backend could pass the TB key parameters to the TTRP, or these could be > part of the TTRP configuration. All the =E2=80=9Cdumb/slim=E2=80=9D TTRP = needs to know is > TB protocol version and a prioritized list of TB key parameter IDs. > Sure, that prioritized list of TB key parameter IDs is still the TTRP 'supporting' them in that it will use them in negotiation. The TB key parameter IDs the TTRP is willing/able to use will need to be the intersection of the supported TB key parameters of each of the backends. This might be cumbersome in some cases but is just the way it has to be for the =E2=80=9Cdumb/slim=E2=80=9D TTRP model. Let=E2=80=99s say a client negotiates signature scheme A with the RP, and s= ignature > scheme A calls for a 64-byte EKM. Then the client negotiates a signature > scheme B with the IDP, and signature scheme B calls for a 32-byte EKM. > The client sends Provided and Referred bindings to this IDP, and the > Referred binding uses signature scheme A in combination with an EKM lengt= h > 32 (which does not agree with the signature scheme definition). Is this > what you=E2=80=99re proposing as option 4), or did I get it wrong? > Yes, that's an accurate description of what I'd proposed as option 4) On Wed, Feb 22, 2017 at 6:03 PM, Andrei Popov wrote: > Correction inlineJ. > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *An= drei > Popov > *Sent:* Wednesday, February 22, 2017 4:39 PM > *To:* Brian Campbell > *Cc:* IETF Tokbind WG > *Subject:* Re: [Unbearable] ramifications of longer EKMs > > > > =C3=98 I'm not sure I follow this? > > =C3=98 I'd think, if this kind of model was used, a TTRP could do all th= e TB > validation work and just expose the TB ID(s) to the backend where they ca= n > bind to whatever tokens/cookies they are issuing. > > Sure, this design would work. My point is that the tokbind-tls-term > document cannot require one particular model of TB processing, because if > this one model does not meet a data center=E2=80=99s requirements/archite= cture, the > document is easily ignored. And it would be particularly undesirable to > lose the =E2=80=9Cdumb/slim=E2=80=9D TTRP model. > > =C3=98 The backend apps would only be able to use TB key parameters that= the > TTRP supports but that's pretty much true of the other model too - the TT= RP > still is the one negotiating. > > Backend could pass the TB key parameters to the TTRP, or these could be > part of the TTRP configuration. All the =E2=80=9Cdumb/slim=E2=80=9D TTRP = needs to know is > TB protocol version and a prioritized list of TB key parameter IDs. > > =C3=98 It only defeats the purpose of having per-signature-scheme EKM le= ngths > in the case of a refereed TB using a longer EKM than the provided. > > Let=E2=80=99s say a client negotiates signature scheme A with the RP, and > signature scheme A calls for a 64-byte EKM. Then the client negotiates a > signature scheme B with the IDP, and signature scheme B calls for a 32- > byte EKM. The client sends Provided and Referred bindings to this IDP, > and the Referred binding uses signature scheme A in combination with an E= KM > length 32 (which does not agree with the signature scheme definition). Is > this what you=E2=80=99re proposing as option 4), or did I get it wrong? > --001a113e7fae84489b054932736a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sur= e, this design would work. My point is that the tokbind-tls-term document c= annot require one particular model of TB processing, because if this one mo= del does not meet a data center=E2=80=99s requirements/architecture, the do= cument is easily ignored. And it would be particularly undesirable to lose = the =E2=80=9Cdumb/slim=E2=80=9D TTRP model.

Are y= ou suggesting that tokbind-tls-term should have more than one model? Or tha= t the =E2=80=9Cdumb/slim=E2=80=9D TTRP model is most likely to be the desir= ed model?=C2=A0

=

Backend could pass the TB key parameters to the TTRP, or these could be part of the TTRP configuration. All the =E2=80=9Cdumb/slim=E2=80=9D TTRP needs to = know is TB protocol version and a prioritized list of TB key parameter IDs.

Sure, that prioritized list of TB key parameter IDs is still the TTRP=20 'supporting' them in that it will use them in negotiation.

=
The TB key parameter IDs the TTRP is willing/able to use will need to be=20 the intersection of the supported TB key parameters of each of the=20 backends. This might be cumbersome in some cases but is just the way it has= to be for the =E2=80=9Cdumb/slim=E2=80=9D TTRP model.

<= /div>
=

Let=E2=80=99s say a client negotiates signatur= e scheme A with the RP, and signature scheme A calls for a 64-byte EKM. Then the client negotiates a signature scheme B with the IDP, and sig= nature scheme B calls for a 32-byte EKM. The client sends Provided and Referred bindings to this IDP, and=20 the Referred binding uses signature scheme A in combination with an EKM length 32 (which=20 does not agree with the signature scheme definition). Is this what=20 you=E2=80=99re proposing as option 4), or did I get it wrong?

Yes, that's an accurate description of what I= 'd proposed as option 4)


On Wed, Feb 22, 2017 at 6:03 PM, An= drei Popov <Andrei.Popov@microsoft.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

Correction inline<= span style=3D"font-size:11.0pt;font-family:Wingdings">J.

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Andrei Popov
Sent: Wednesday, February 22, 2017 4:39 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: IETF Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] ramifications of longer EKMs=

=C2=A0

=C3=98<= span style=3D"font:7.0pt "Times New Roman"">=C2=A0 I'm not sure I follow this? <= /p>

=C3=98<= span style=3D"font:7.0pt "Times New Roman"">=C2=A0 I'd think, if this kind of model was used, = a TTRP could do all the TB validation work and just expose the TB ID(s) to = the backend where they can bind to whatever tokens/cookies they are issuing= .

Sure, this design wo= uld work. My point is that the tokbind-tls-term document cannot require one= particular model of TB processing, because if this one model does not meet a data center=E2=80=99s requirements/architecture,= the document is easily ignored. And it would be particularly undesirable t= o lose the =E2=80=9Cdumb/slim=E2=80=9D TTRP model.

=C3=98<= span style=3D"font:7.0pt "Times New Roman"">=C2=A0 The backend apps would only be able to use TB k= ey parameters that the TTRP supports but that's pretty much true of the= other model too - the TTRP still is the one negotiating.

Backend could pass t= he TB key parameters to the TTRP, or these could be part of the TTRP config= uration. All the =E2=80=9Cdumb/slim=E2=80=9D TTRP needs to know is TB protocol version and a prioritized list of TB key parameter IDs.<= /u>

=C3=98=C2=A0 It only defeats the purpose of having per-signa= ture-scheme EKM lengths in the case of a refereed TB using a longer EKM tha= n the provided.

Let=E2=80=99s= say a client negotiates signature scheme A with the RP, and signature sche= me A calls for a 64-byte EKM. Then the client negotiates a signature scheme B with the IDP, and sig= nature scheme B calls for a 32-byte EKM. The client sends Provided and Referred bindings to this IDP, and the= Referred binding uses signature scheme A in combination with an EKM length 32 (which does n= ot agree with the signature scheme definition). Is this what you=E2=80=99re= proposing as option 4), or did I get it wrong?


--001a113e7fae84489b054932736a-- From nobody Thu Feb 23 09:53:53 2017 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 78F94129A6E for ; Thu, 23 Feb 2017 09:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DPlLzZk784Q for ; Thu, 23 Feb 2017 09:53:50 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0116.outbound.protection.outlook.com [104.47.32.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9590C12A21D for ; Thu, 23 Feb 2017 09:53:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IlaCcXIbNkjAqu5yPPLhMNqkkTA/u+PeG3OU45nqoqY=; b=n03RLmc6Ct1I6Qk3PzgagM8pnpN2Q/zw9aBEAvvUAH7LGctgvpM2Ec2QF4yKpIWfkBzCeSB9EHJvx7OigTYkjrKbubIOK8iIKoj0LBKP6M427KwiKZWEc39KUXaKxWEN2I16dRTqjiXesc0DzszqnCBq5lmygQJjMjK7NjR9an4= Received: from SN1PR0301MB2029.namprd03.prod.outlook.com (10.163.226.27) by CY1PR0301MB0841.namprd03.prod.outlook.com (10.160.163.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Thu, 23 Feb 2017 17:53:46 +0000 Received: from SN1PR0301MB2029.namprd03.prod.outlook.com ([10.163.226.27]) by SN1PR0301MB2029.namprd03.prod.outlook.com ([10.163.226.27]) with mapi id 15.01.0933.011; Thu, 23 Feb 2017 17:53:46 +0000 From: Anthony Nadalin To: Brian Campbell , Andrei Popov Thread-Topic: [Unbearable] ramifications of longer EKMs Thread-Index: AQHSjVYe/iOyf5L8EU+ZQVupoEDxs6F1rSmAgAAKOICAAAhuAIAABvKAgADNHgCAAEwncA== Date: Thu, 23 Feb 2017 17:53:46 +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: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [2001:4898:80e8:5::29d] x-ms-office365-filtering-correlation-id: 54e49b8f-2f94-4630-061a-08d45c14ea2d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0841; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0841; 7:y+OravF7zf7+Rvivpic/7v5BwW0HrGABrjmd5aoy7NCDxNWD60bFkzbd+2egU3Un9PAj7aEeR8WD3zuAhZq7df8v+uNiUzVuVWnM/QFkbw9Fz8YnGsLhWOYG/a5xGY3inuDWC5bOYFw12t31p0EZovzNjOiUhGns8JzYBSw33oStaJMjhs4U1di9il+wrfphQyxRjQE5ck47uaAVobnJAu1l3bgNQPQ2oqU0y4iaJD2H4nFdAcyOqS5dpytPjUznoSGGLNxb19jjDPgH6EZAdGQZ+f4JDoZJQJJKfsvMKZrkSa3MHJcTdLS9WZQmbiOwgq98QW3h0TeMFcnjeAyiwqpcA5h9SMikxUhVa5b3TlA= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:CY1PR0301MB0841; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0841; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39450400003)(39840400002)(39860400002)(39850400002)(189002)(377454003)(24454002)(199003)(54356999)(4326007)(50986999)(122556002)(2906002)(25786008)(102836003)(68736007)(3280700002)(5660300001)(77096006)(3660700001)(229853002)(790700001)(86362001)(19609705001)(92566002)(6506006)(54896002)(53936002)(99286003)(9686003)(86612001)(76176999)(55016002)(6306002)(236005)(1511001)(74316002)(105586002)(2561002)(8936002)(81166006)(93886004)(106116001)(106356001)(6246003)(189998001)(8676002)(53546006)(101416001)(81156014)(5005710100001)(10090500001)(2900100001)(2421001)(6116002)(6636002)(10290500002)(8990500004)(38730400002)(6436002)(2950100002)(97736004)(33656002)(7736002)(7696004)(148743002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0841; H:SN1PR0301MB2029.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB2029AD297BE87DE6330FFBE6A6530SN1PR0301MB2029_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 17:53:46.2128 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0841 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] ramifications of longer EKMs 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: Thu, 23 Feb 2017 17:53:51 -0000 --_000_SN1PR0301MB2029AD297BE87DE6330FFBE6A6530SN1PR0301MB2029_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbm90IHN1cmUgdGhlIHZhbHVlIG9mIHN0YW5kYXJkaXppbmcgdGhlIHRva2JpbmQtdGxz LXRlcm0sIG5vdCBzdXJlIGhvdyBtdWNoIGludGVyb3BlcmFiaWxpdHkgcmVxdWlyZW1lbnRzIHRo ZXJlIGFyZSBoZXJlLCBtYXliZSB0aGlzIHNob3VsZCBiZSBhbiBleHBlcmltZW50YWwgdW50aWwg d2UgZmlndXJlIG91dCBpZiB0aGVyZSBpcyBhIG5lZWQgYW5kIGlmIHNvIHdoYXQgYXJlIHRoZSBy ZXF1aXJlbWVudHMNCg0KRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIENhbXBiZWxsDQpTZW50OiBUaHVyc2RheSwg RmVicnVhcnkgMjMsIDIwMTcgNToxOCBBTQ0KVG86IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92 QG1pY3Jvc29mdC5jb20+DQpDYzogSUVURiBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSByYW1pZmljYXRpb25zIG9mIGxvbmdlciBFS01z DQoNClN1cmUsIHRoaXMgZGVzaWduIHdvdWxkIHdvcmsuIE15IHBvaW50IGlzIHRoYXQgdGhlIHRv a2JpbmQtdGxzLXRlcm0gZG9jdW1lbnQgY2Fubm90IHJlcXVpcmUgb25lIHBhcnRpY3VsYXIgbW9k ZWwgb2YgVEIgcHJvY2Vzc2luZywgYmVjYXVzZSBpZiB0aGlzIG9uZSBtb2RlbCBkb2VzIG5vdCBt ZWV0IGEgZGF0YSBjZW50ZXLigJlzIHJlcXVpcmVtZW50cy9hcmNoaXRlY3R1cmUsIHRoZSBkb2N1 bWVudCBpcyBlYXNpbHkgaWdub3JlZC4gQW5kIGl0IHdvdWxkIGJlIHBhcnRpY3VsYXJseSB1bmRl c2lyYWJsZSB0byBsb3NlIHRoZSDigJxkdW1iL3NsaW3igJ0gVFRSUCBtb2RlbC4NCg0KQXJlIHlv dSBzdWdnZXN0aW5nIHRoYXQgdG9rYmluZC10bHMtdGVybSBzaG91bGQgaGF2ZSBtb3JlIHRoYW4g b25lIG1vZGVsPyBPciB0aGF0IHRoZSDigJxkdW1iL3NsaW3igJ0gVFRSUCBtb2RlbCBpcyBtb3N0 IGxpa2VseSB0byBiZSB0aGUgZGVzaXJlZCBtb2RlbD8NCkJhY2tlbmQgY291bGQgcGFzcyB0aGUg VEIga2V5IHBhcmFtZXRlcnMgdG8gdGhlIFRUUlAsIG9yIHRoZXNlIGNvdWxkIGJlIHBhcnQgb2Yg dGhlIFRUUlAgY29uZmlndXJhdGlvbi4gQWxsIHRoZSDigJxkdW1iL3NsaW3igJ0gVFRSUCBuZWVk cyB0byBrbm93IGlzIFRCIHByb3RvY29sIHZlcnNpb24gYW5kIGEgcHJpb3JpdGl6ZWQgbGlzdCBv ZiBUQiBrZXkgcGFyYW1ldGVyIElEcy4NClN1cmUsIHRoYXQgcHJpb3JpdGl6ZWQgbGlzdCBvZiBU QiBrZXkgcGFyYW1ldGVyIElEcyBpcyBzdGlsbCB0aGUgVFRSUCAnc3VwcG9ydGluZycgdGhlbSBp biB0aGF0IGl0IHdpbGwgdXNlIHRoZW0gaW4gbmVnb3RpYXRpb24uDQpUaGUgVEIga2V5IHBhcmFt ZXRlciBJRHMgdGhlIFRUUlAgaXMgd2lsbGluZy9hYmxlIHRvIHVzZSB3aWxsIG5lZWQgdG8gYmUg dGhlIGludGVyc2VjdGlvbiBvZiB0aGUgc3VwcG9ydGVkIFRCIGtleSBwYXJhbWV0ZXJzIG9mIGVh Y2ggb2YgdGhlIGJhY2tlbmRzLiBUaGlzIG1pZ2h0IGJlIGN1bWJlcnNvbWUgaW4gc29tZSBjYXNl cyBidXQgaXMganVzdCB0aGUgd2F5IGl0IGhhcyB0byBiZSBmb3IgdGhlIOKAnGR1bWIvc2xpbeKA nSBUVFJQIG1vZGVsLg0KDQpMZXTigJlzIHNheSBhIGNsaWVudCBuZWdvdGlhdGVzIHNpZ25hdHVy ZSBzY2hlbWUgQSB3aXRoIHRoZSBSUCwgYW5kIHNpZ25hdHVyZSBzY2hlbWUgQSBjYWxscyBmb3Ig YSA2NC1ieXRlIEVLTS4gVGhlbiB0aGUgY2xpZW50IG5lZ290aWF0ZXMgYSBzaWduYXR1cmUgc2No ZW1lIEIgd2l0aCB0aGUgSURQLCBhbmQgc2lnbmF0dXJlIHNjaGVtZSBCIGNhbGxzIGZvciBhIDMy LWJ5dGUgRUtNLiBUaGUgY2xpZW50IHNlbmRzIFByb3ZpZGVkIGFuZCBSZWZlcnJlZCBiaW5kaW5n cyB0byB0aGlzIElEUCwgYW5kIHRoZSBSZWZlcnJlZCBiaW5kaW5nIHVzZXMgc2lnbmF0dXJlIHNj aGVtZSBBIGluIGNvbWJpbmF0aW9uIHdpdGggYW4gRUtNIGxlbmd0aCAzMiAod2hpY2ggZG9lcyBu b3QgYWdyZWUgd2l0aCB0aGUgc2lnbmF0dXJlIHNjaGVtZSBkZWZpbml0aW9uKS4gSXMgdGhpcyB3 aGF0IHlvdeKAmXJlIHByb3Bvc2luZyBhcyBvcHRpb24gNCksIG9yIGRpZCBJIGdldCBpdCB3cm9u Zz8NClllcywgdGhhdCdzIGFuIGFjY3VyYXRlIGRlc2NyaXB0aW9uIG9mIHdoYXQgSSdkIHByb3Bv c2VkIGFzIG9wdGlvbiA0KQ0KDQoNCk9uIFdlZCwgRmViIDIyLCAyMDE3IGF0IDY6MDMgUE0sIEFu ZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3Bv dkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpDb3JyZWN0aW9uIGlubGluZeKYui4NCg0KRnJvbTog VW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dW5i ZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEFuZHJlaSBQb3Bvdg0KU2Vu dDogV2VkbmVzZGF5LCBGZWJydWFyeSAyMiwgMjAxNyA0OjM5IFBNDQpUbzogQnJpYW4gQ2FtcGJl bGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbT4+DQpDYzogSUVURiBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPG1haWx0 bzp1bmJlYXJhYmxlQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gcmFtaWZp Y2F0aW9ucyBvZiBsb25nZXIgRUtNcw0KDQoNCj4gIEknbSBub3Qgc3VyZSBJIGZvbGxvdyB0aGlz Pw0KDQo+ICBJJ2QgdGhpbmssIGlmIHRoaXMga2luZCBvZiBtb2RlbCB3YXMgdXNlZCwgYSBUVFJQ IGNvdWxkIGRvIGFsbCB0aGUgVEIgdmFsaWRhdGlvbiB3b3JrIGFuZCBqdXN0IGV4cG9zZSB0aGUg VEIgSUQocykgdG8gdGhlIGJhY2tlbmQgd2hlcmUgdGhleSBjYW4gYmluZCB0byB3aGF0ZXZlciB0 b2tlbnMvY29va2llcyB0aGV5IGFyZSBpc3N1aW5nLg0KU3VyZSwgdGhpcyBkZXNpZ24gd291bGQg d29yay4gTXkgcG9pbnQgaXMgdGhhdCB0aGUgdG9rYmluZC10bHMtdGVybSBkb2N1bWVudCBjYW5u b3QgcmVxdWlyZSBvbmUgcGFydGljdWxhciBtb2RlbCBvZiBUQiBwcm9jZXNzaW5nLCBiZWNhdXNl IGlmIHRoaXMgb25lIG1vZGVsIGRvZXMgbm90IG1lZXQgYSBkYXRhIGNlbnRlcuKAmXMgcmVxdWly ZW1lbnRzL2FyY2hpdGVjdHVyZSwgdGhlIGRvY3VtZW50IGlzIGVhc2lseSBpZ25vcmVkLiBBbmQg aXQgd291bGQgYmUgcGFydGljdWxhcmx5IHVuZGVzaXJhYmxlIHRvIGxvc2UgdGhlIOKAnGR1bWIv c2xpbeKAnSBUVFJQIG1vZGVsLg0KDQo+ICBUaGUgYmFja2VuZCBhcHBzIHdvdWxkIG9ubHkgYmUg YWJsZSB0byB1c2UgVEIga2V5IHBhcmFtZXRlcnMgdGhhdCB0aGUgVFRSUCBzdXBwb3J0cyBidXQg dGhhdCdzIHByZXR0eSBtdWNoIHRydWUgb2YgdGhlIG90aGVyIG1vZGVsIHRvbyAtIHRoZSBUVFJQ IHN0aWxsIGlzIHRoZSBvbmUgbmVnb3RpYXRpbmcuDQpCYWNrZW5kIGNvdWxkIHBhc3MgdGhlIFRC IGtleSBwYXJhbWV0ZXJzIHRvIHRoZSBUVFJQLCBvciB0aGVzZSBjb3VsZCBiZSBwYXJ0IG9mIHRo ZSBUVFJQIGNvbmZpZ3VyYXRpb24uIEFsbCB0aGUg4oCcZHVtYi9zbGlt4oCdIFRUUlAgbmVlZHMg dG8ga25vdyBpcyBUQiBwcm90b2NvbCB2ZXJzaW9uIGFuZCBhIHByaW9yaXRpemVkIGxpc3Qgb2Yg VEIga2V5IHBhcmFtZXRlciBJRHMuDQoNCj4gIEl0IG9ubHkgZGVmZWF0cyB0aGUgcHVycG9zZSBv ZiBoYXZpbmcgcGVyLXNpZ25hdHVyZS1zY2hlbWUgRUtNIGxlbmd0aHMgaW4gdGhlIGNhc2Ugb2Yg YSByZWZlcmVlZCBUQiB1c2luZyBhIGxvbmdlciBFS00gdGhhbiB0aGUgcHJvdmlkZWQuDQpMZXTi gJlzIHNheSBhIGNsaWVudCBuZWdvdGlhdGVzIHNpZ25hdHVyZSBzY2hlbWUgQSB3aXRoIHRoZSBS UCwgYW5kIHNpZ25hdHVyZSBzY2hlbWUgQSBjYWxscyBmb3IgYSA2NC1ieXRlIEVLTS4gVGhlbiB0 aGUgY2xpZW50IG5lZ290aWF0ZXMgYSBzaWduYXR1cmUgc2NoZW1lIEIgd2l0aCB0aGUgSURQLCBh bmQgc2lnbmF0dXJlIHNjaGVtZSBCIGNhbGxzIGZvciBhIDMyLWJ5dGUgRUtNLiBUaGUgY2xpZW50 IHNlbmRzIFByb3ZpZGVkIGFuZCBSZWZlcnJlZCBiaW5kaW5ncyB0byB0aGlzIElEUCwgYW5kIHRo ZSBSZWZlcnJlZCBiaW5kaW5nIHVzZXMgc2lnbmF0dXJlIHNjaGVtZSBBIGluIGNvbWJpbmF0aW9u IHdpdGggYW4gRUtNIGxlbmd0aCAzMiAod2hpY2ggZG9lcyBub3QgYWdyZWUgd2l0aCB0aGUgc2ln bmF0dXJlIHNjaGVtZSBkZWZpbml0aW9uKS4gSXMgdGhpcyB3aGF0IHlvdeKAmXJlIHByb3Bvc2lu ZyBhcyBvcHRpb24gNCksIG9yIGRpZCBJIGdldCBpdCB3cm9uZz8NCg0K --_000_SN1PR0301MB2029AD297BE87DE6330FFBE6A6530SN1PR0301MB2029_ 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 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5nbWFp bC0NCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtO30NCnAuZ21haWwtbTk0Mzk1NTU5NDkwMjQxMjc4 bXNvbGlzdHBhcmFncmFwaCwgbGkuZ21haWwtbTk0Mzk1NTU5NDkwMjQxMjc4bXNvbGlzdHBhcmFn cmFwaCwgZGl2LmdtYWlsLW05NDM5NTU1OTQ5MDI0MTI3OG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNv LXN0eWxlLW5hbWU6Z21haWwtbV85NDM5NTU1OTQ5MDI0MTI3OG1zb2xpc3RwYXJhZ3JhcGg7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm05NDM5NTU1OTQ5MDI0MTI3 OG1zb2xpc3RwYXJhZ3JhcGgsIGxpLm05NDM5NTU1OTQ5MDI0MTI3OG1zb2xpc3RwYXJhZ3JhcGgs IGRpdi5tOTQzOTU1NTk0OTAyNDEyNzhtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1l Om1fOTQzOTU1NTk0OTAyNDEyNzhtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIG5vdCBzdXJl IHRoZSB2YWx1ZSBvZiBzdGFuZGFyZGl6aW5nIHRoZSB0b2tiaW5kLXRscy10ZXJtLCBub3Qgc3Vy ZSBob3cgbXVjaCBpbnRlcm9wZXJhYmlsaXR5IHJlcXVpcmVtZW50cyB0aGVyZSBhcmUgaGVyZSwg bWF5YmUgdGhpcyBzaG91bGQgYmUgYW4gZXhwZXJpbWVudGFsIHVudGlsIHdlIGZpZ3VyZSBvdXQg aWYgdGhlcmUgaXMgYSBuZWVkIGFuZCBpZiBzbyB3aGF0IGFyZSB0aGUgcmVxdWlyZW1lbnRzPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBv c2UiPjxvOnA+Jm5ic3A7PC9vOnA+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwv Yj4gVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u IEJlaGFsZiBPZiA8L2I+QnJpYW4gQ2FtcGJlbGw8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXks IEZlYnJ1YXJ5IDIzLCAyMDE3IDU6MTggQU08YnI+DQo8Yj5Ubzo8L2I+IEFuZHJlaSBQb3BvdiAm bHQ7QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRVRGIFRv a2JpbmQgV0cgJmx0O3VuYmVhcmFibGVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbVW5iZWFyYWJsZV0gcmFtaWZpY2F0aW9ucyBvZiBsb25nZXIgRUtNczxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdXJlLCB0aGlzIGRlc2ln biB3b3VsZCB3b3JrLiBNeSBwb2ludCBpcyB0aGF0IHRoZSB0b2tiaW5kLXRscy10ZXJtIGRvY3Vt ZW50IGNhbm5vdCByZXF1aXJlIG9uZSBwYXJ0aWN1bGFyIG1vZGVsIG9mIFRCIHByb2Nlc3Npbmcs IGJlY2F1c2UgaWYgdGhpcyBvbmUgbW9kZWwgZG9lcyBub3QgbWVldCBhIGRhdGEgY2VudGVy4oCZ cyByZXF1aXJlbWVudHMvYXJjaGl0ZWN0dXJlLCB0aGUgZG9jdW1lbnQgaXMgZWFzaWx5DQogaWdu b3JlZC4gQW5kIGl0IHdvdWxkIGJlIHBhcnRpY3VsYXJseSB1bmRlc2lyYWJsZSB0byBsb3NlIHRo ZSDigJxkdW1iL3NsaW3igJ0gVFRSUCBtb2RlbC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BcmUgeW91IHN1Z2dlc3RpbmcgdGhhdCB0b2tiaW5kLXRscy10 ZXJtIHNob3VsZCBoYXZlIG1vcmUgdGhhbiBvbmUgbW9kZWw/IE9yIHRoYXQgdGhlIOKAnGR1bWIv c2xpbeKAnSBUVFJQIG1vZGVsIGlzIG1vc3QgbGlrZWx5IHRvIGJlIHRoZSBkZXNpcmVkIG1vZGVs PyZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+QmFja2VuZCBjb3VsZCBwYXNzIHRoZSBUQiBrZXkg cGFyYW1ldGVycyB0byB0aGUgVFRSUCwgb3IgdGhlc2UgY291bGQgYmUgcGFydCBvZiB0aGUgVFRS UCBjb25maWd1cmF0aW9uLiBBbGwgdGhlIOKAnGR1bWIvc2xpbeKAnSBUVFJQIG5lZWRzIHRvIGtu b3cgaXMgVEIgcHJvdG9jb2wgdmVyc2lvbiBhbmQgYSBwcmlvcml0aXplZA0KIGxpc3Qgb2YgVEIg a2V5IHBhcmFtZXRlciBJRHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5TdXJlLCB0aGF0IHByaW9yaXRpemVkIGxpc3Qgb2YgVEIga2V5IHBhcmFtZXRlciBJRHMgaXMg c3RpbGwgdGhlIFRUUlAgJ3N1cHBvcnRpbmcnIHRoZW0gaW4gdGhhdCBpdCB3aWxsIHVzZSB0aGVt IGluIG5lZ290aWF0aW9uLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGUgVEIga2V5IHBhcmFtZXRlciBJRHMgdGhlIFRUUlAgaXMgd2lsbGlu Zy9hYmxlIHRvIHVzZSB3aWxsIG5lZWQgdG8gYmUgdGhlIGludGVyc2VjdGlvbiBvZiB0aGUgc3Vw cG9ydGVkIFRCIGtleSBwYXJhbWV0ZXJzIG9mIGVhY2ggb2YgdGhlIGJhY2tlbmRzLiBUaGlzIG1p Z2h0IGJlIGN1bWJlcnNvbWUgaW4gc29tZSBjYXNlcyBidXQgaXMganVzdCB0aGUgd2F5IGl0IGhh cyB0byBiZSBmb3IgdGhlIOKAnGR1bWIvc2xpbeKAnQ0KIFRUUlAgbW9kZWwuIDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+TGV04oCZcyBzYXkgYSBjbGllbnQgbmVnb3RpYXRlcyBzaWduYXR1cmUgc2NoZW1lIEEgd2l0 aCB0aGUgUlAsIGFuZCBzaWduYXR1cmUgc2NoZW1lIEEgY2FsbHMgZm9yIGEgNjQtPHNwYW4gc3R5 bGU9ImJhY2tncm91bmQ6eWVsbG93Ij5ieXRlPC9zcGFuPiBFS00uIFRoZW4gdGhlIGNsaWVudCBu ZWdvdGlhdGVzIGEgc2lnbmF0dXJlDQogc2NoZW1lIEIgd2l0aCB0aGUgSURQLCBhbmQgc2lnbmF0 dXJlIHNjaGVtZSBCIGNhbGxzIGZvciBhIDMyLTxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxv dyI+Ynl0ZTwvc3Bhbj4gRUtNLiBUaGUgY2xpZW50IHNlbmRzIFByb3ZpZGVkIGFuZCBSZWZlcnJl ZCBiaW5kaW5ncyB0byB0aGlzIElEUCwgYW5kIHRoZSBSZWZlcnJlZCBiaW5kaW5nIHVzZXMgc2ln bmF0dXJlIHNjaGVtZSBBIGluIGNvbWJpbmF0aW9uIHdpdGggYW4gRUtNIGxlbmd0aCAzMg0KICh3 aGljaCBkb2VzIG5vdCBhZ3JlZSB3aXRoIHRoZSBzaWduYXR1cmUgc2NoZW1lIGRlZmluaXRpb24p LiBJcyB0aGlzIHdoYXQgeW914oCZcmUgcHJvcG9zaW5nIGFzIG9wdGlvbiA0KSwgb3IgZGlkIEkg Z2V0IGl0IHdyb25nPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIHRoYXQncyBhbiBhY2N1cmF0ZSBk ZXNjcmlwdGlvbiBvZiB3aGF0IEknZCBwcm9wb3NlZCBhcyBvcHRpb24gNCk8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgRmViIDIyLCAyMDE3 IGF0IDY6MDMgUE0sIEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3Bv dkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93 Ij5Db3JyZWN0aW9uPC9zcGFuPiBpbmxpbmU8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2Rp bmdzIj5KPC9zcGFuPi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gVW5iZWFyYWJsZSBbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj51 bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmRy ZWkgUG9wb3Y8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAyMiwgMjAxNyA0 OjM5IFBNPGJyPg0KPGI+VG86PC9iPiBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBp bmdpZGVudGl0eS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBUb2tiaW5kIFdHICZs dDs8YSBocmVmPSJtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnVu YmVhcmFibGVAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVh cmFibGVdIHJhbWlmaWNhdGlvbnMgb2YgbG9uZ2VyIEVLTXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Im05NDM5NTU1OTQ5MDI0MTI3OG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+w5g8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOw0KPC9zcGFuPkknbSBub3Qgc3VyZSBJIGZv bGxvdyB0aGlzPyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtOTQzOTU1NTk0OTAyNDEyNzht c29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpXaW5nZGluZ3MiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJz cDsNCjwvc3Bhbj5JJ2QgdGhpbmssIGlmIHRoaXMga2luZCBvZiBtb2RlbCB3YXMgdXNlZCwgYSBU VFJQIGNvdWxkIGRvIGFsbCB0aGUgVEIgdmFsaWRhdGlvbiB3b3JrIGFuZCBqdXN0IGV4cG9zZSB0 aGUgVEIgSUQocykgdG8gdGhlIGJhY2tlbmQgd2hlcmUgdGhleSBjYW4gYmluZCB0byB3aGF0ZXZl ciB0b2tlbnMvY29va2llcyB0aGV5IGFyZSBpc3N1aW5nLg0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPlN1cmUsIHRoaXMgZGVzaWduIHdvdWxkIHdvcmsuIE15IHBvaW50IGlzIHRo YXQgdGhlIHRva2JpbmQtdGxzLXRlcm0gZG9jdW1lbnQgY2Fubm90IHJlcXVpcmUgb25lIHBhcnRp Y3VsYXIgbW9kZWwgb2YgVEIgcHJvY2Vzc2luZywgYmVjYXVzZSBpZiB0aGlzIG9uZSBtb2RlbCBk b2VzIG5vdCBtZWV0IGEgZGF0YSBjZW50ZXLigJlzDQogcmVxdWlyZW1lbnRzL2FyY2hpdGVjdHVy ZSwgdGhlIGRvY3VtZW50IGlzIGVhc2lseSBpZ25vcmVkLiBBbmQgaXQgd291bGQgYmUgcGFydGlj dWxhcmx5IHVuZGVzaXJhYmxlIHRvIGxvc2UgdGhlIOKAnGR1bWIvc2xpbeKAnSBUVFJQIG1vZGVs LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05NDM5NTU1OTQ5MDI0MTI3OG1zb2xpc3RwYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OldpbmdkaW5ncyI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOw0KPC9zcGFu PlRoZSBiYWNrZW5kIGFwcHMgd291bGQgb25seSBiZSBhYmxlIHRvIHVzZSBUQiBrZXkgcGFyYW1l dGVycyB0aGF0IHRoZSBUVFJQIHN1cHBvcnRzIGJ1dCB0aGF0J3MgcHJldHR5IG11Y2ggdHJ1ZSBv ZiB0aGUgb3RoZXIgbW9kZWwgdG9vIC0gdGhlIFRUUlAgc3RpbGwgaXMgdGhlIG9uZSBuZWdvdGlh dGluZy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5CYWNrZW5kIGNvdWxkIHBh c3MgdGhlIFRCIGtleSBwYXJhbWV0ZXJzIHRvIHRoZSBUVFJQLCBvciB0aGVzZSBjb3VsZCBiZSBw YXJ0IG9mIHRoZSBUVFJQIGNvbmZpZ3VyYXRpb24uIEFsbCB0aGUg4oCcZHVtYi9zbGlt4oCdIFRU UlAgbmVlZHMgdG8ga25vdyBpcyBUQiBwcm90b2NvbCB2ZXJzaW9uIGFuZCBhIHByaW9yaXRpemVk DQogbGlzdCBvZiBUQiBrZXkgcGFyYW1ldGVyIElEcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJtOTQzOTU1NTk0OTAyNDEyNzhtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6V2luZ2RpbmdzIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7DQo8L3Nw YW4+SXQgb25seSBkZWZlYXRzIHRoZSBwdXJwb3NlIG9mIGhhdmluZyBwZXItc2lnbmF0dXJlLXNj aGVtZSBFS00gbGVuZ3RocyBpbiB0aGUgY2FzZSBvZiBhIHJlZmVyZWVkIFRCIHVzaW5nIGEgbG9u Z2VyIEVLTSB0aGFuIHRoZSBwcm92aWRlZC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij5MZXTigJlzIHNheSBhIGNsaWVudCBuZWdvdGlhdGVzIHNpZ25hdHVyZSBzY2hlbWUgQSB3 aXRoIHRoZSBSUCwgYW5kIHNpZ25hdHVyZSBzY2hlbWUgQSBjYWxscyBmb3IgYSA2NC08c3BhbiBz dHlsZT0iYmFja2dyb3VuZDp5ZWxsb3ciPmJ5dGU8L3NwYW4+IEVLTS4gVGhlbiB0aGUgY2xpZW50 IG5lZ290aWF0ZXMgYSBzaWduYXR1cmUNCiBzY2hlbWUgQiB3aXRoIHRoZSBJRFAsIGFuZCBzaWdu YXR1cmUgc2NoZW1lIEIgY2FsbHMgZm9yIGEgMzItPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVs bG93Ij5ieXRlPC9zcGFuPiBFS00uIFRoZSBjbGllbnQgc2VuZHMgUHJvdmlkZWQgYW5kIFJlZmVy cmVkIGJpbmRpbmdzIHRvIHRoaXMgSURQLCBhbmQgdGhlIFJlZmVycmVkIGJpbmRpbmcgdXNlcyBz aWduYXR1cmUgc2NoZW1lIEEgaW4gY29tYmluYXRpb24gd2l0aCBhbiBFS00gbGVuZ3RoIDMyDQog KHdoaWNoIGRvZXMgbm90IGFncmVlIHdpdGggdGhlIHNpZ25hdHVyZSBzY2hlbWUgZGVmaW5pdGlv bikuIElzIHRoaXMgd2hhdCB5b3XigJlyZSBwcm9wb3NpbmcgYXMgb3B0aW9uIDQpLCBvciBkaWQg SSBnZXQgaXQgd3Jvbmc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN1PR0301MB2029AD297BE87DE6330FFBE6A6530SN1PR0301MB2029_-- From nobody Thu Feb 23 12:05:53 2017 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 EA453129A8A for ; Thu, 23 Feb 2017 12:05:51 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 n88ad8uwV-Fw for ; Thu, 23 Feb 2017 12:05:50 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002: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 5555C1299F9 for ; Thu, 23 Feb 2017 12:05:50 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id p77so897121ywg.1 for ; Thu, 23 Feb 2017 12:05:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YE3A2rcrkTPCpIOHPKqFunlFsfnJhtb3oVI74y6TUCM=; b=RgliOEU072zEN4xeBQ+T7fQDl+2VaSs+OisDzf4XROtU229Vgk4rdXCQrlQvli9a4o HIov9AmJ8WABxfJouUlqxRb7WB1wITkem2bnKWlmyI7L8T7ZcVcDhDD8VFp+rQRUQ/81 Dvji9gFVHr0fK5aAmKif3Ub7wOGOI0BW0EICVPKGQ/wMRLirc0/XX28eLtRl/pwvrmkL FZMkPWnY+d8I+WqDSAvurIyw6gFeZxmJ7o+IsJb72VhihsDD26Zd/0biZ3OZ1fJ4jOCN 2BEKevfKaPMkull2urrdoahDUzw3IRFsmkceoiTPiZomF+8ifOjTXPTvR9Q1xcnuEcfr Rcgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YE3A2rcrkTPCpIOHPKqFunlFsfnJhtb3oVI74y6TUCM=; b=rIkX/qCGbcjfqVzl2wFN7NQAkKQ3+OvD/4CEDP0MoxxmaSc0rr3gTgm6m3X0qg4Aub SprfPo+jsOKkQP270BIj9F0LmdAJEB59c3lYMev9cyH5VMK+xGuDDq2W/kzqJds9ARlL mnXqact8KS0jbB7xCdjdp+VbtFqzRuIt2G7M+pCJJywChjKCauOS4EtR8zgI9qVuRufm 8DrrZhEm3KxtAa+XmAJLoMz3xACqGk+ij0PXTtNYfbRNfpJOYtjnVNA3eRcwnVHhWkUw 3gqDfahd15Y/WTY8yEGypgGDcAgZGROSfadDAKQfED4Pgx8uslGQJMnYL7Zs5vuARsNR tQpw== X-Gm-Message-State: AMke39nf3lHvmiA8Nvv4mJwJzj+KL2Xx2ofzj6YgBhScin5r7n2lwi8gCMGBF+WHeLT15I5sVRqWKbl8IqFHg51s X-Received: by 10.129.91.139 with SMTP id p133mr29345003ywb.320.1487880349456; Thu, 23 Feb 2017 12:05:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.65.5 with HTTP; Thu, 23 Feb 2017 12:05:29 -0800 (PST) In-Reply-To: References: From: Nick Harper Date: Thu, 23 Feb 2017 12:05:29 -0800 Message-ID: To: Pranav Kukreja Content-Type: multipart/alternative; boundary=001a114c84d2b311c00549382377 Archived-At: Cc: token-binding-team , Tokbind WG , Vinod Anupam , Bill Cox Subject: Re: [Unbearable] Token binding version (0, 10) support is global on google servers 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: Thu, 23 Feb 2017 20:05:52 -0000 --001a114c84d2b311c00549382377 Content-Type: text/plain; charset=UTF-8 FYI: We are updating Google servers to only support Token Binding version (0, 13). On Fri, Jan 20, 2017 at 11:46 AM, Pranav Kukreja wrote: > Anupam, are those connections from Edge resulting in any connection errors > post the TLS handshake, especially during false start. I am chasing down > some interop issues with Edge talking to google servers with TB enabled at > the moment. If you notice anything please let us know. > > > > Thanks! > > Pranav > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Vinod > Anupam > *Sent:* Friday, January 20, 2017 10:02 AM > *To:* Bill Cox > *Cc:* Tokbind WG ; token-binding-team < > token-binding-team@google.com> > *Subject:* Re: [Unbearable] Token binding version (0, 10) support is > global on google servers > > > > > > > > On Fri, Jan 20, 2017 at 4:29 AM, Bill Cox wrote: > > I'm seeing 5.7K token binding headers per second at the moment, about 5K/s > sending both channel-ID and token binding (probably chrome), and about > 700/s with just token binding (probably not chrome). > > > > Based on information in our logs, the requests with just token binding > headers are primarily from Edge. > > > > cheers, > > -Anupam > > > > > > Bill > > -- > You received this message because you are subscribed to the Google Groups > "token-binding-team" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to token-binding-team+unsubscribe@google.com. > To post to this group, send email to token-binding-team@google.com. > To view this discussion on the web visit https://groups.google.com/a/ > google.com/d/msgid/token-binding-team/CAH9QtQHiMNKTWkExDduH%3DhuCzs% > 3DyVW%2BE7YM3Wnoh0DoeYUe08A%40mail.gmail.com > > . > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --001a114c84d2b311c00549382377 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI:
We are updating Google servers to only support To= ken Binding version (0, 13).

On Fri, Jan 20, 2017 at 11:46 AM, Pranav Kukreja <pranavk@microsoft.com> wrote:

Anupam, are those connections from Edge resulting in= any connection errors post the TLS handshake, especially during false star= t. I am chasing down some interop issues with Edge talking to google server= s with TB enabled at the moment. If you notice anything please let us know.

=C2=A0

Thanks!

Pranav

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ietf.o= rg] On Behalf Of Vinod Anupam
Sent: Friday, January 20, 2017 10:02 AM
To: Bill Cox <waywardgeek@google.com>
Cc: Tokbind WG <unbearable@ietf.org>; token-binding-team <token-binding-team@goog= le.com>
Subject: Re: [Unbearable] Token binding vers= ion (0, 10) support is global on google servers

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 20, 2017 at 4:29 AM, Bill Cox <waywardgeek@google.co= m> wrote:

I'm seeing 5.7K token binding headers per second= at the moment, about 5K/s sending both channel-ID and token binding (proba= bly chrome), and about 700/s with just token binding (probably not chrome).=

=C2=A0

Based on information in our logs, the requests with = just token binding headers are primarily from Edge.

=C2=A0

cheers,

-Anupam

=C2=A0

=C2=A0

Bill

<= span style=3D"color:#888888">--
You received this messag= e because you are subscribed to the Google Groups "token-binding-team&= quot; group.
To unsubscribe from this= group and stop receiving emails from it, send an email to token-binding-team+unsubscribe@google.com.
To post to this group, s= end email to token-binding-team@google.com.
To view this discussion = on the web visit https://groups.google.com/a/google.com/d/msgid/token-binding-team= /CAH9QtQHiMNKTWkExDduH%3DhuCzs%3DyVW%2BE7YM3Wnoh0DoeYUe08A%4= 0mail.gmail.com.

=C2=A0


_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearabl= e


--001a114c84d2b311c00549382377-- From nobody Thu Feb 23 12:13:52 2017 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 947E7129A7E for ; Thu, 23 Feb 2017 12:13:51 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9flxTJ_oRu8C for ; Thu, 23 Feb 2017 12:13:48 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0103.outbound.protection.outlook.com [104.47.42.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A4D12957F for ; Thu, 23 Feb 2017 12:13:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZlwutS15KcKt/1snzYPS6NtJVi/AAyzW/MHVyFwbTGc=; b=H8sgdkwOPu76D8JYtacea0BhCT2x3coND6wak9OUnqczLZ0kGkrqhLBmlct5hRAaKnRnrAGNVsz4YfShiZR5FkVnu43KTtt0Gx3mcRc6PPT+fUDx2OhlXwSeDjmsnDWQ26bAajaY7lKUEg9l0WpPEAlzfnTe9XyZzUqalTFpSr4= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Thu, 23 Feb 2017 20:13:44 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0919.018; Thu, 23 Feb 2017 20:13:44 +0000 From: Andrei Popov To: Brian Campbell Thread-Topic: [Unbearable] ramifications of longer EKMs Thread-Index: AQHSjVYgmQf/q9+NMUG8uI+0qEZ9BqF1ncIggAAZn4CAAACqsIAADg1QgADNxwCAAG9TYA== Date: Thu, 23 Feb 2017 20:13:44 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: 6095337f-fe04-45d2-d600-08d45c28781d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0842; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 7:cx27zar2RyYVD6R9oiKHvpt71iMmOFRRcIAKAfT72FbTE4jM64BAIvM9WK0Lr8MkrgGwdMKYvuzQgHI/jNFZ1T2lgkdgNgeLWa5pWTLQ7mw7tQU8bRrmL7lbJuuyc6kkv7k56yv2xWmiZMysK+dJYBu/TaH6BbpETyP6Y98lJ7JrT0FTdlXykyuCQMkLnAmeAv0TbDVYM1REP/1iIwN2hGgfE1N4daCCVLzbNqCqwlq771A+NyJusAG+H7f89DdhGVv+MQHvhl/5kKnWI2TVX7m/e17lQnu0Dx7Ec7+LaDezdI9zvJeVSuVvrQRP55xRbCFy01/XrKv9I5i/Xxhyfr1sIrEsFeXGZLZF0nWWBUo= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39860400002)(39850400002)(39450400003)(39410400002)(199003)(377454003)(24454002)(189002)(68736007)(7696004)(25786008)(2900100001)(4326007)(10090500001)(55016002)(93886004)(3280700002)(790700001)(9686003)(101416001)(102836003)(110136004)(54896002)(7736002)(3660700001)(236005)(6306002)(54356999)(76176999)(99286003)(86362001)(50986999)(92566002)(74316002)(97736004)(10290500002)(81156014)(229853002)(6246003)(81166006)(6436002)(6916009)(77096006)(53936002)(33656002)(38730400002)(86612001)(5660300001)(8936002)(122556002)(8676002)(8990500004)(6116002)(106116001)(5005710100001)(105586002)(106356001)(2950100002)(189998001)(53546006)(6506006)(2906002)(148743002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB08427EB93E5E942C662AF06B8C530CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 20:13:44.7407 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] ramifications of longer EKMs 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: Thu, 23 Feb 2017 20:13:51 -0000 --_000_CY1PR0301MB08427EB93E5E942C662AF06B8C530CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHRva2JpbmQtdGxzLXRlcm0gc2hvdWxkIGhhdmUg bW9yZSB0aGFuIG9uZSBtb2RlbD8NCkFsdGVybmF0aXZlbHksIHdlIG1heSBlbmQgdXAgd2l0aCBt b3JlIHRoYW4gb25lIHRva2JpbmQtdGxzLXRlcm3imLouDQoNCg0Kw5ggIE9yIHRoYXQgdGhlIOKA nGR1bWIvc2xpbeKAnSBUVFJQIG1vZGVsIGlzIG1vc3QgbGlrZWx5IHRvIGJlIHRoZSBkZXNpcmVk IG1vZGVsPw0KSXQgc2VlbXMgdW5kZXNpcmFibGUgdG8gcHJldmVudCDigJxkdW1iL3NsaW3igJ0g VFRSUHMsIHJlZ2FyZGxlc3Mgb2Ygd2hhdCB0b2tiaW5kLXRscy10ZXJtIGVuZHMgdXAgc2F5aW5n Lg0KDQoNCsOYICBZZXMsIHRoYXQncyBhbiBhY2N1cmF0ZSBkZXNjcmlwdGlvbiBvZiB3aGF0IEkn ZCBwcm9wb3NlZCBhcyBvcHRpb24gNCkNClRoZW4gd2hhdCB3ZSBoYXZlIGluIG9wdGlvbiA0KSBp cyBhbiBJRFAgdGhhdCBzdXBwb3J0cyBhIHN1YnNldCwgcmF0aGVyIHRoYW4gc3VwZXJzZXQsIG9m IGl0cyBSUOKAmXMgVEIga2V5IHBhcmFtZXRlcnMuIFdoaWNoIGlzIGEga25vd24gdHlwZSBvZiBt aXNjb25maWd1cmF0aW9uIHRoYXQgY2FuIGhhcHBlbiBiZXR3ZWVuIHRoZSBJRFAgYW5kIFJQcy4N CkluIGFueSBjYXNlLCB0aGUgVEIga2V5IHBhcmFtZXRlcnMgbmVnb3RpYXRpb24gd291bGQgbm90 IGJlIHZlcnkgcm9idXN0IGlmIHdlIHNheSB0aGF0IGEgZ2l2ZW4gc2lnbmF0dXJlIHNjaGVtZSBy ZWFsbHkgcmVxdWlyZXMgYSA2NC1ieXRlIEVLTSwgYnV0IG1heSBhbHNvIGJlIHVzZWQgd2l0aCBh IDMyLWJ5dGUgRUtNIGlmIHRoZSBiaW5kaW5nIGlzIFJlZmVycmVk4oCmDQoNCkZyb206IEJyaWFu IENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQpTZW50OiBUaHVy c2RheSwgRmVicnVhcnkgMjMsIDIwMTcgNToxOCBBTQ0KVG86IEFuZHJlaSBQb3BvdiA8QW5kcmVp LlBvcG92QG1pY3Jvc29mdC5jb20+DQpDYzogSUVURiBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSByYW1pZmljYXRpb25zIG9mIGxvbmdl ciBFS01zDQoNClN1cmUsIHRoaXMgZGVzaWduIHdvdWxkIHdvcmsuIE15IHBvaW50IGlzIHRoYXQg dGhlIHRva2JpbmQtdGxzLXRlcm0gZG9jdW1lbnQgY2Fubm90IHJlcXVpcmUgb25lIHBhcnRpY3Vs YXIgbW9kZWwgb2YgVEIgcHJvY2Vzc2luZywgYmVjYXVzZSBpZiB0aGlzIG9uZSBtb2RlbCBkb2Vz IG5vdCBtZWV0IGEgZGF0YSBjZW50ZXLigJlzIHJlcXVpcmVtZW50cy9hcmNoaXRlY3R1cmUsIHRo ZSBkb2N1bWVudCBpcyBlYXNpbHkgaWdub3JlZC4gQW5kIGl0IHdvdWxkIGJlIHBhcnRpY3VsYXJs eSB1bmRlc2lyYWJsZSB0byBsb3NlIHRoZSDigJxkdW1iL3NsaW3igJ0gVFRSUCBtb2RlbC4NCg0K QXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgdG9rYmluZC10bHMtdGVybSBzaG91bGQgaGF2ZSBtb3Jl IHRoYW4gb25lIG1vZGVsPyBPciB0aGF0IHRoZSDigJxkdW1iL3NsaW3igJ0gVFRSUCBtb2RlbCBp cyBtb3N0IGxpa2VseSB0byBiZSB0aGUgZGVzaXJlZCBtb2RlbD8NCkJhY2tlbmQgY291bGQgcGFz cyB0aGUgVEIga2V5IHBhcmFtZXRlcnMgdG8gdGhlIFRUUlAsIG9yIHRoZXNlIGNvdWxkIGJlIHBh cnQgb2YgdGhlIFRUUlAgY29uZmlndXJhdGlvbi4gQWxsIHRoZSDigJxkdW1iL3NsaW3igJ0gVFRS UCBuZWVkcyB0byBrbm93IGlzIFRCIHByb3RvY29sIHZlcnNpb24gYW5kIGEgcHJpb3JpdGl6ZWQg bGlzdCBvZiBUQiBrZXkgcGFyYW1ldGVyIElEcy4NClN1cmUsIHRoYXQgcHJpb3JpdGl6ZWQgbGlz dCBvZiBUQiBrZXkgcGFyYW1ldGVyIElEcyBpcyBzdGlsbCB0aGUgVFRSUCAnc3VwcG9ydGluZycg dGhlbSBpbiB0aGF0IGl0IHdpbGwgdXNlIHRoZW0gaW4gbmVnb3RpYXRpb24uDQpUaGUgVEIga2V5 IHBhcmFtZXRlciBJRHMgdGhlIFRUUlAgaXMgd2lsbGluZy9hYmxlIHRvIHVzZSB3aWxsIG5lZWQg dG8gYmUgdGhlIGludGVyc2VjdGlvbiBvZiB0aGUgc3VwcG9ydGVkIFRCIGtleSBwYXJhbWV0ZXJz IG9mIGVhY2ggb2YgdGhlIGJhY2tlbmRzLiBUaGlzIG1pZ2h0IGJlIGN1bWJlcnNvbWUgaW4gc29t ZSBjYXNlcyBidXQgaXMganVzdCB0aGUgd2F5IGl0IGhhcyB0byBiZSBmb3IgdGhlIOKAnGR1bWIv c2xpbeKAnSBUVFJQIG1vZGVsLg0KDQpMZXTigJlzIHNheSBhIGNsaWVudCBuZWdvdGlhdGVzIHNp Z25hdHVyZSBzY2hlbWUgQSB3aXRoIHRoZSBSUCwgYW5kIHNpZ25hdHVyZSBzY2hlbWUgQSBjYWxs cyBmb3IgYSA2NC1ieXRlIEVLTS4gVGhlbiB0aGUgY2xpZW50IG5lZ290aWF0ZXMgYSBzaWduYXR1 cmUgc2NoZW1lIEIgd2l0aCB0aGUgSURQLCBhbmQgc2lnbmF0dXJlIHNjaGVtZSBCIGNhbGxzIGZv ciBhIDMyLWJ5dGUgRUtNLiBUaGUgY2xpZW50IHNlbmRzIFByb3ZpZGVkIGFuZCBSZWZlcnJlZCBi aW5kaW5ncyB0byB0aGlzIElEUCwgYW5kIHRoZSBSZWZlcnJlZCBiaW5kaW5nIHVzZXMgc2lnbmF0 dXJlIHNjaGVtZSBBIGluIGNvbWJpbmF0aW9uIHdpdGggYW4gRUtNIGxlbmd0aCAzMiAod2hpY2gg ZG9lcyBub3QgYWdyZWUgd2l0aCB0aGUgc2lnbmF0dXJlIHNjaGVtZSBkZWZpbml0aW9uKS4gSXMg dGhpcyB3aGF0IHlvdeKAmXJlIHByb3Bvc2luZyBhcyBvcHRpb24gNCksIG9yIGRpZCBJIGdldCBp dCB3cm9uZz8NClllcywgdGhhdCdzIGFuIGFjY3VyYXRlIGRlc2NyaXB0aW9uIG9mIHdoYXQgSSdk IHByb3Bvc2VkIGFzIG9wdGlvbiA0KQ0KDQoNCk9uIFdlZCwgRmViIDIyLCAyMDE3IGF0IDY6MDMg UE0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJl aS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpDb3JyZWN0aW9uIGlubGluZeKYui4NCg0K RnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEFuZHJlaSBQb3Bv dg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyMiwgMjAxNyA0OjM5IFBNDQpUbzogQnJpYW4g Q2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGlu Z2lkZW50aXR5LmNvbT4+DQpDYzogSUVURiBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3Jn PG1haWx0bzp1bmJlYXJhYmxlQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0g cmFtaWZpY2F0aW9ucyBvZiBsb25nZXIgRUtNcw0KDQoNCj4gIEknbSBub3Qgc3VyZSBJIGZvbGxv dyB0aGlzPw0KDQo+ICBJJ2QgdGhpbmssIGlmIHRoaXMga2luZCBvZiBtb2RlbCB3YXMgdXNlZCwg YSBUVFJQIGNvdWxkIGRvIGFsbCB0aGUgVEIgdmFsaWRhdGlvbiB3b3JrIGFuZCBqdXN0IGV4cG9z ZSB0aGUgVEIgSUQocykgdG8gdGhlIGJhY2tlbmQgd2hlcmUgdGhleSBjYW4gYmluZCB0byB3aGF0 ZXZlciB0b2tlbnMvY29va2llcyB0aGV5IGFyZSBpc3N1aW5nLg0KU3VyZSwgdGhpcyBkZXNpZ24g d291bGQgd29yay4gTXkgcG9pbnQgaXMgdGhhdCB0aGUgdG9rYmluZC10bHMtdGVybSBkb2N1bWVu dCBjYW5ub3QgcmVxdWlyZSBvbmUgcGFydGljdWxhciBtb2RlbCBvZiBUQiBwcm9jZXNzaW5nLCBi ZWNhdXNlIGlmIHRoaXMgb25lIG1vZGVsIGRvZXMgbm90IG1lZXQgYSBkYXRhIGNlbnRlcuKAmXMg cmVxdWlyZW1lbnRzL2FyY2hpdGVjdHVyZSwgdGhlIGRvY3VtZW50IGlzIGVhc2lseSBpZ25vcmVk LiBBbmQgaXQgd291bGQgYmUgcGFydGljdWxhcmx5IHVuZGVzaXJhYmxlIHRvIGxvc2UgdGhlIOKA nGR1bWIvc2xpbeKAnSBUVFJQIG1vZGVsLg0KDQo+ICBUaGUgYmFja2VuZCBhcHBzIHdvdWxkIG9u bHkgYmUgYWJsZSB0byB1c2UgVEIga2V5IHBhcmFtZXRlcnMgdGhhdCB0aGUgVFRSUCBzdXBwb3J0 cyBidXQgdGhhdCdzIHByZXR0eSBtdWNoIHRydWUgb2YgdGhlIG90aGVyIG1vZGVsIHRvbyAtIHRo ZSBUVFJQIHN0aWxsIGlzIHRoZSBvbmUgbmVnb3RpYXRpbmcuDQpCYWNrZW5kIGNvdWxkIHBhc3Mg dGhlIFRCIGtleSBwYXJhbWV0ZXJzIHRvIHRoZSBUVFJQLCBvciB0aGVzZSBjb3VsZCBiZSBwYXJ0 IG9mIHRoZSBUVFJQIGNvbmZpZ3VyYXRpb24uIEFsbCB0aGUg4oCcZHVtYi9zbGlt4oCdIFRUUlAg bmVlZHMgdG8ga25vdyBpcyBUQiBwcm90b2NvbCB2ZXJzaW9uIGFuZCBhIHByaW9yaXRpemVkIGxp c3Qgb2YgVEIga2V5IHBhcmFtZXRlciBJRHMuDQoNCj4gIEl0IG9ubHkgZGVmZWF0cyB0aGUgcHVy cG9zZSBvZiBoYXZpbmcgcGVyLXNpZ25hdHVyZS1zY2hlbWUgRUtNIGxlbmd0aHMgaW4gdGhlIGNh c2Ugb2YgYSByZWZlcmVlZCBUQiB1c2luZyBhIGxvbmdlciBFS00gdGhhbiB0aGUgcHJvdmlkZWQu DQpMZXTigJlzIHNheSBhIGNsaWVudCBuZWdvdGlhdGVzIHNpZ25hdHVyZSBzY2hlbWUgQSB3aXRo IHRoZSBSUCwgYW5kIHNpZ25hdHVyZSBzY2hlbWUgQSBjYWxscyBmb3IgYSA2NC1ieXRlIEVLTS4g VGhlbiB0aGUgY2xpZW50IG5lZ290aWF0ZXMgYSBzaWduYXR1cmUgc2NoZW1lIEIgd2l0aCB0aGUg SURQLCBhbmQgc2lnbmF0dXJlIHNjaGVtZSBCIGNhbGxzIGZvciBhIDMyLWJ5dGUgRUtNLiBUaGUg Y2xpZW50IHNlbmRzIFByb3ZpZGVkIGFuZCBSZWZlcnJlZCBiaW5kaW5ncyB0byB0aGlzIElEUCwg YW5kIHRoZSBSZWZlcnJlZCBiaW5kaW5nIHVzZXMgc2lnbmF0dXJlIHNjaGVtZSBBIGluIGNvbWJp bmF0aW9uIHdpdGggYW4gRUtNIGxlbmd0aCAzMiAod2hpY2ggZG9lcyBub3QgYWdyZWUgd2l0aCB0 aGUgc2lnbmF0dXJlIHNjaGVtZSBkZWZpbml0aW9uKS4gSXMgdGhpcyB3aGF0IHlvdeKAmXJlIHBy b3Bvc2luZyBhcyBvcHRpb24gNCksIG9yIGRpZCBJIGdldCBpdCB3cm9uZz8NCg0K --_000_CY1PR0301MB08427EB93E5E942C662AF06B8C530CY1PR0301MB0842_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uZ21haWwtDQoJe21zby1zdHlsZS1uYW1lOmdtYWls LTt9DQpwLmdtYWlsLW05NDM5NTU1OTQ5MDI0MTI3OG1zb2xpc3RwYXJhZ3JhcGgsIGxpLmdtYWls LW05NDM5NTU1OTQ5MDI0MTI3OG1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFpbC1tOTQzOTU1NTk0 OTAyNDEyNzhtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fOTQzOTU1 NTk0OTAyNDEyNzhtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0KcC5tOTQzOTU1NTk0OTAyNDEyNzhtc29saXN0cGFyYWdyYXBoLCBsaS5t OTQzOTU1NTk0OTAyNDEyNzhtc29saXN0cGFyYWdyYXBoLCBkaXYubTk0Mzk1NTU5NDkwMjQxMjc4 bXNvbGlzdHBhcmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTptXzk0Mzk1NTU5NDkwMjQxMjc4bXNv bGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30N CnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjUzNDEyMTQ5NjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE0ODc5MTYzNTAgLTEyMzM2MDE3NjQgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo0Ow0KCW1zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPkFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHRva2JpbmQtdGxzLXRlcm0gc2hvdWxkIGhh dmUgbW9yZSB0aGFuIG9uZSBtb2RlbD8NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbHRlcm5hdGl2 ZWx5LCB3ZSBtYXkgZW5kIHVwIHdpdGggbW9yZSB0aGFuIG9uZQ0KPC9zcGFuPnRva2JpbmQtdGxz LXRlcm08c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj5KPC9zcGFuPi48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPk9yIHRoYXQgdGhlIOKAnGR1bWIv c2xpbeKAnSBUVFJQIG1vZGVsIGlzIG1vc3QgbGlrZWx5IHRvIGJlIHRoZSBkZXNpcmVkIG1vZGVs PzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JdCBzZWVtcyB1bmRlc2lyYWJsZSB0byBwcmV2ZW50IOKA nGR1bWIvc2xpbeKAnSBUVFJQcywgcmVnYXJkbGVzcyBvZiB3aGF0DQo8L3NwYW4+dG9rYmluZC10 bHMtdGVybSBlbmRzIHVwIHNheWluZy48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPlllcywgdGhhdCdzIGFuIGFjY3VyYXRlIGRlc2NyaXB0aW9uIG9mIHdoYXQgSSdk IHByb3Bvc2VkIGFzIG9wdGlvbiA0KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlbiB3aGF0IHdlIGhhdmUgaW4gb3B0aW9uIDQp IGlzIGFuIElEUCB0aGF0IHN1cHBvcnRzIGEgc3Vic2V0LCByYXRoZXIgdGhhbiBzdXBlcnNldCwg b2YgaXRzIFJQ4oCZcyBUQiBrZXkgcGFyYW1ldGVycy4gV2hpY2ggaXMgYSBrbm93biB0eXBlIG9m IG1pc2NvbmZpZ3VyYXRpb24gdGhhdCBjYW4gaGFwcGVuDQogYmV0d2VlbiB0aGUgSURQIGFuZCBS UHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5JbiBhbnkgY2FzZSwgdGhlIFRCIGtleSBwYXJhbWV0ZXJzIG5lZ290aWF0aW9uIHdv dWxkIG5vdCBiZSB2ZXJ5IHJvYnVzdCBpZiB3ZSBzYXkgdGhhdCBhIGdpdmVuIHNpZ25hdHVyZSBz Y2hlbWUgcmVhbGx5IHJlcXVpcmVzIGEgNjQtYnl0ZSBFS00sIGJ1dCBtYXkgYWxzbyBiZSB1c2Vk IHdpdGggYSAzMi1ieXRlDQogRUtNIGlmIHRoZSBiaW5kaW5nIGlzIFJlZmVycmVk4oCmIDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQnJpYW4gQ2Ft cGJlbGwgW21haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMjMsIDIwMTcgNToxOCBBTTxicj4NCjxiPlRvOjwvYj4g QW5kcmVpIFBvcG92ICZsdDtBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IElFVEYgVG9rYmluZCBXRyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSByYW1pZmljYXRpb25zIG9mIGxvbmdlciBF S01zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TdXJlLCB0aGlzIGRlc2lnbiB3b3VsZCB3b3JrLiBNeSBwb2ludCBpcyB0aGF0IHRoZSB0 b2tiaW5kLXRscy10ZXJtIGRvY3VtZW50IGNhbm5vdCByZXF1aXJlIG9uZSBwYXJ0aWN1bGFyIG1v ZGVsIG9mIFRCIHByb2Nlc3NpbmcsIGJlY2F1c2UgaWYgdGhpcyBvbmUgbW9kZWwgZG9lcyBub3Qg bWVldCBhIGRhdGEgY2VudGVy4oCZcyByZXF1aXJlbWVudHMvYXJjaGl0ZWN0dXJlLCB0aGUgZG9j dW1lbnQgaXMgZWFzaWx5DQogaWdub3JlZC4gQW5kIGl0IHdvdWxkIGJlIHBhcnRpY3VsYXJseSB1 bmRlc2lyYWJsZSB0byBsb3NlIHRoZSDigJxkdW1iL3NsaW3igJ0gVFRSUCBtb2RlbC48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcmUgeW91IHN1Z2dlc3Rp bmcgdGhhdCB0b2tiaW5kLXRscy10ZXJtIHNob3VsZCBoYXZlIG1vcmUgdGhhbiBvbmUgbW9kZWw/ IE9yIHRoYXQgdGhlIOKAnGR1bWIvc2xpbeKAnSBUVFJQIG1vZGVsIGlzIG1vc3QgbGlrZWx5IHRv IGJlIHRoZSBkZXNpcmVkIG1vZGVsPyZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5CYWNrZW5kIGNvdWxkIHBhc3MgdGhlIFRCIGtleSBwYXJhbWV0ZXJzIHRvIHRoZSBU VFJQLCBvciB0aGVzZSBjb3VsZCBiZSBwYXJ0IG9mIHRoZSBUVFJQIGNvbmZpZ3VyYXRpb24uIEFs bCB0aGUg4oCcZHVtYi9zbGlt4oCdDQogVFRSUCBuZWVkcyB0byBrbm93IGlzIFRCIHByb3RvY29s IHZlcnNpb24gYW5kIGEgcHJpb3JpdGl6ZWQgbGlzdCBvZiBUQiBrZXkgcGFyYW1ldGVyIElEcy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5TdXJlLCB0aGF0 IHByaW9yaXRpemVkIGxpc3Qgb2YgVEIga2V5IHBhcmFtZXRlciBJRHMgaXMgc3RpbGwgdGhlIFRU UlAgJ3N1cHBvcnRpbmcnIHRoZW0gaW4gdGhhdCBpdCB3aWxsIHVzZSB0aGVtIGluIG5lZ290aWF0 aW9uLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgVEIga2V5IHBhcmFtZXRlciBJRHMgdGhlIFRUUlAgaXMgd2lsbGluZy9hYmxlIHRvIHVz ZSB3aWxsIG5lZWQgdG8gYmUgdGhlIGludGVyc2VjdGlvbiBvZiB0aGUgc3VwcG9ydGVkIFRCIGtl eSBwYXJhbWV0ZXJzIG9mIGVhY2ggb2YgdGhlIGJhY2tlbmRzLiBUaGlzIG1pZ2h0IGJlIGN1bWJl cnNvbWUgaW4gc29tZSBjYXNlcyBidXQgaXMganVzdCB0aGUgd2F5IGl0IGhhcyB0byBiZSBmb3Ig dGhlIOKAnGR1bWIvc2xpbeKAnQ0KIFRUUlAgbW9kZWwuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5MZXTigJlzIHNheSBhIGNsaWVudCBuZWdvdGlhdGVzIHNpZ25hdHVyZSBzY2hlbWUg QSB3aXRoIHRoZSBSUCwgYW5kIHNpZ25hdHVyZSBzY2hlbWUgQSBjYWxscyBmb3IgYSA2NC08c3Bh biBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3ciPmJ5dGU8L3NwYW4+DQogRUtNLiBUaGVuIHRoZSBj bGllbnQgbmVnb3RpYXRlcyBhIHNpZ25hdHVyZSBzY2hlbWUgQiB3aXRoIHRoZSBJRFAsIGFuZCBz aWduYXR1cmUgc2NoZW1lIEIgY2FsbHMgZm9yIGEgMzItPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6 eWVsbG93Ij5ieXRlPC9zcGFuPiBFS00uIFRoZSBjbGllbnQgc2VuZHMgUHJvdmlkZWQgYW5kIFJl ZmVycmVkIGJpbmRpbmdzIHRvIHRoaXMgSURQLCBhbmQgdGhlIFJlZmVycmVkIGJpbmRpbmcgdXNl cyBzaWduYXR1cmUgc2NoZW1lDQogQSBpbiBjb21iaW5hdGlvbiB3aXRoIGFuIEVLTSBsZW5ndGgg MzIgKHdoaWNoIGRvZXMgbm90IGFncmVlIHdpdGggdGhlIHNpZ25hdHVyZSBzY2hlbWUgZGVmaW5p dGlvbikuIElzIHRoaXMgd2hhdCB5b3XigJlyZSBwcm9wb3NpbmcgYXMgb3B0aW9uIDQpLCBvciBk aWQgSSBnZXQgaXQgd3Jvbmc/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPlllcywgdGhhdCdzIGFuIGFjY3VyYXRlIGRlc2NyaXB0aW9uIG9mIHdoYXQgSSdkIHByb3Bv c2VkIGFzIG9wdGlvbiA0KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgRmViIDIyLCAyMDE3IGF0IDY6MDMgUE0sIEFuZHJlaSBQ b3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIiB0YXJn ZXQ9Il9ibGFuayI+QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2JhY2tncm91bmQ6eWVsbG93Ij5Db3JyZWN0aW9uPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IGlubGluZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3MiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4uPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFVuYmVhcmFibGUgW21haWx0bzo8YSBocmVm PSJtYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dW5i ZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5kcmVp IFBvcG92PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMjIsIDIwMTcgNDoz OSBQTTxicj4NCjxiPlRvOjwvYj4gQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpi Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5n aWRlbnRpdHkuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IElFVEYgVG9rYmluZCBXRyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj51bmJl YXJhYmxlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJh YmxlXSByYW1pZmljYXRpb25zIG9mIGxvbmdlciBFS01zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0ibTk0Mzk1NTU5NDkwMjQxMjc4bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpXaW5nZGluZ3MiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQi PiZuYnNwOw0KPC9zcGFuPkknbSBub3Qgc3VyZSBJIGZvbGxvdyB0aGlzPyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJtOTQzOTU1NTk0OTAyNDEyNzhtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncyI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+ Jm5ic3A7DQo8L3NwYW4+SSdkIHRoaW5rLCBpZiB0aGlzIGtpbmQgb2YgbW9kZWwgd2FzIHVzZWQs IGEgVFRSUCBjb3VsZCBkbyBhbGwgdGhlIFRCIHZhbGlkYXRpb24gd29yayBhbmQganVzdCBleHBv c2UgdGhlIFRCIElEKHMpIHRvIHRoZSBiYWNrZW5kIHdoZXJlIHRoZXkgY2FuIGJpbmQgdG8gd2hh dGV2ZXIgdG9rZW5zL2Nvb2tpZXMgdGhleSBhcmUgaXNzdWluZy4NCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlN1cmUsIHRoaXMgZGVzaWduIHdvdWxk IHdvcmsuIE15IHBvaW50IGlzIHRoYXQgdGhlIHRva2JpbmQtdGxzLXRlcm0gZG9jdW1lbnQgY2Fu bm90IHJlcXVpcmUgb25lIHBhcnRpY3VsYXIgbW9kZWwgb2YgVEINCiBwcm9jZXNzaW5nLCBiZWNh dXNlIGlmIHRoaXMgb25lIG1vZGVsIGRvZXMgbm90IG1lZXQgYSBkYXRhIGNlbnRlcuKAmXMgcmVx dWlyZW1lbnRzL2FyY2hpdGVjdHVyZSwgdGhlIGRvY3VtZW50IGlzIGVhc2lseSBpZ25vcmVkLiBB bmQgaXQgd291bGQgYmUgcGFydGljdWxhcmx5IHVuZGVzaXJhYmxlIHRvIGxvc2UgdGhlIOKAnGR1 bWIvc2xpbeKAnSBUVFJQIG1vZGVsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJt OTQzOTU1NTk0OTAyNDEyNzhtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5n cyI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7DQo8L3NwYW4+ VGhlIGJhY2tlbmQgYXBwcyB3b3VsZCBvbmx5IGJlIGFibGUgdG8gdXNlIFRCIGtleSBwYXJhbWV0 ZXJzIHRoYXQgdGhlIFRUUlAgc3VwcG9ydHMgYnV0IHRoYXQncyBwcmV0dHkgbXVjaCB0cnVlIG9m IHRoZSBvdGhlciBtb2RlbCB0b28gLSB0aGUgVFRSUCBzdGlsbCBpcyB0aGUgb25lIG5lZ290aWF0 aW5nLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ QmFja2VuZCBjb3VsZCBwYXNzIHRoZSBUQiBrZXkgcGFyYW1ldGVycyB0byB0aGUgVFRSUCwgb3Ig dGhlc2UgY291bGQgYmUgcGFydCBvZiB0aGUgVFRSUCBjb25maWd1cmF0aW9uLiBBbGwgdGhlIOKA nGR1bWIvc2xpbeKAnQ0KIFRUUlAgbmVlZHMgdG8ga25vdyBpcyBUQiBwcm90b2NvbCB2ZXJzaW9u IGFuZCBhIHByaW9yaXRpemVkIGxpc3Qgb2YgVEIga2V5IHBhcmFtZXRlciBJRHMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05NDM5NTU1OTQ5MDI0MTI3OG1zb2xpc3RwYXJhZ3Jh cGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+ w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7DQo8L3NwYW4+SXQg b25seSBkZWZlYXRzIHRoZSBwdXJwb3NlIG9mIGhhdmluZyBwZXItc2lnbmF0dXJlLXNjaGVtZSBF S00gbGVuZ3RocyBpbiB0aGUgY2FzZSBvZiBhIHJlZmVyZWVkIFRCIHVzaW5nIGEgbG9uZ2VyIEVL TSB0aGFuIHRoZSBwcm92aWRlZC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkxldOKAmXMgc2F5IGEgY2xpZW50IG5lZ290aWF0ZXMgc2lnbmF0dXJl IHNjaGVtZSBBIHdpdGggdGhlIFJQLCBhbmQgc2lnbmF0dXJlIHNjaGVtZSBBIGNhbGxzIGZvciBh IDY0LTxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdyI+Ynl0ZTwvc3Bhbj4NCiBFS00uIFRo ZW4gdGhlIGNsaWVudCBuZWdvdGlhdGVzIGEgc2lnbmF0dXJlIHNjaGVtZSBCIHdpdGggdGhlIElE UCwgYW5kIHNpZ25hdHVyZSBzY2hlbWUgQiBjYWxscyBmb3IgYSAzMi08c3BhbiBzdHlsZT0iYmFj a2dyb3VuZDp5ZWxsb3ciPmJ5dGU8L3NwYW4+IEVLTS4gVGhlIGNsaWVudCBzZW5kcyBQcm92aWRl ZCBhbmQgUmVmZXJyZWQgYmluZGluZ3MgdG8gdGhpcyBJRFAsIGFuZCB0aGUgUmVmZXJyZWQgYmlu ZGluZyB1c2VzIHNpZ25hdHVyZSBzY2hlbWUNCiBBIGluIGNvbWJpbmF0aW9uIHdpdGggYW4gRUtN IGxlbmd0aCAzMiAod2hpY2ggZG9lcyBub3QgYWdyZWUgd2l0aCB0aGUgc2lnbmF0dXJlIHNjaGVt ZSBkZWZpbml0aW9uKS4gSXMgdGhpcyB3aGF0IHlvdeKAmXJlIHByb3Bvc2luZyBhcyBvcHRpb24g NCksIG9yIGRpZCBJIGdldCBpdCB3cm9uZz88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR0301MB08427EB93E5E942C662AF06B8C530CY1PR0301MB0842_-- From nobody Thu Feb 23 12:22:30 2017 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 CB9D812A2A6 for ; Thu, 23 Feb 2017 12:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOnITBdpNt-a for ; Thu, 23 Feb 2017 12:22:27 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0113.outbound.protection.outlook.com [104.47.40.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6485F12A1CF for ; Thu, 23 Feb 2017 12:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9wIVIvybr/PwIWH1/Mp3MADbFO5He4yr75hs8ySCR18=; b=ZTEmHrgaBEhy1Pz42/v2w1AnFaInx7q3RCDWBi+WElUMUgYn++51Wrumwwch9lOctiyygUuw2fUQBf+Kl5Zp2eQUGFHJsjafWU+Yn7286qxmZxfCbAYf6lrrGpy7ko5L7cKwhn0iMCt8Nj4ZDM4AOsWD4HRBMSnGf3FthoSOlN4= Received: from BN3PR03MB2323.namprd03.prod.outlook.com (10.166.74.142) by DM2PR0301MB0846.namprd03.prod.outlook.com (10.160.215.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 23 Feb 2017 20:22:24 +0000 Received: from BN3PR03MB2323.namprd03.prod.outlook.com ([10.166.74.142]) by BN3PR03MB2323.namprd03.prod.outlook.com ([10.166.74.142]) with mapi id 15.01.0919.018; Thu, 23 Feb 2017 20:22:23 +0000 From: Pranav Kukreja To: Nick Harper , Andrei Popov Thread-Topic: [Unbearable] Token binding version (0, 10) support is global on google servers Thread-Index: AQHSjhA9djNS8E1N6kucanLVG+b3jaF3CJIA Date: Thu, 23 Feb 2017 20:22:23 +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: spf=none (sender IP is ) smtp.mailfrom=pranavk@microsoft.com; x-originating-ip: [2001:4898:80e8:8::40d] x-ms-office365-filtering-correlation-id: a9140c16-d060-4d1f-a20e-08d45c29ad66 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DM2PR0301MB0846; x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0846; 7:YB3Om8AVHCEcByEvm74U/B1YOw4zDGG/bm5qE/stw0JDClR1RcSNjo7YE+gK/Rtulmub+tfo5Akgg78ToAEjf4e3HvXQNwvUgK9b3/BxjGjMyg9mv0omgPHMwt2QH/L9yzB3Q8L39l1gVCM1a+oCiCwX/ro9kQeN6PdwM/l3L68qzR4BErHReelSMfHnyjZX9FDozem/mogscR10xa6A0/EPUG2cdrbvCVJDNu5FpOU4bnnC5JS4T2L7U2tRwpO3BoXMGX6MEwTx6YEyUShuK5lhHkDscvbogrke3oOnN2k845x+8QfITLCvzUd3fRRCR84K6chCS6IzyHWCZTs015oLNSUVcUlCfktDco7MDxM= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(228788266533470)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123558025)(20161123564025)(6072148); SRVR:DM2PR0301MB0846; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0846; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39860400002)(39410400002)(39850400002)(39450400003)(189002)(51914003)(69234005)(24454002)(377454003)(199003)(33656002)(5660300001)(6306002)(8676002)(7736002)(101416001)(54906002)(25786008)(102836003)(7696004)(189998001)(93886004)(76176999)(92566002)(81156014)(4326007)(86362001)(50986999)(86612001)(38730400002)(6636002)(6246003)(55016002)(6506006)(99286003)(2900100001)(2950100002)(606005)(3280700002)(74316002)(2906002)(10090500001)(236005)(2421001)(9686003)(6116002)(105586002)(790700001)(54896002)(7906003)(53936002)(54356999)(81166006)(3660700001)(106356001)(229853002)(77096006)(6436002)(122556002)(97736004)(106116001)(8990500004)(53546006)(575784001)(5005710100001)(8936002)(2561002)(10290500002)(1511001)(68736007)(19609705001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0846; H:BN3PR03MB2323.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB23233EDF7E9880C7F385385CB0530BN3PR03MB2323namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 20:22:23.4998 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0846 Archived-At: Cc: token-binding-team , Tokbind WG , Vinod Anupam , Bill Cox Subject: Re: [Unbearable] Token binding version (0, 10) support is global on google servers 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: Thu, 23 Feb 2017 20:22:30 -0000 --_000_BN3PR03MB23233EDF7E9880C7F385385CB0530BN3PR03MB2323namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 K0FuZHJlaQ0KDQpUaGFua3MgZm9yIHRoZSBoZWFkcyB1cCBOaWNrLiBDdXJyZW50IE1pY3Jvc29m dCBpcyBhZHZlcnRpc2luZyAwLjEwLCBzbyB3ZSB3aWxsIHRyYWNrIHRoaXMgdXBkYXRlIG9uIG91 ciBlbmQuDQoNCkZyb206IE5pY2sgSGFycGVyIFttYWlsdG86bmhhcnBlckBnb29nbGUuY29tXQ0K U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDIzLCAyMDE3IDEyOjA1IFBNDQpUbzogUHJhbmF2IEt1 a3JlamEgPHByYW5hdmtAbWljcm9zb2Z0LmNvbT4NCkNjOiBWaW5vZCBBbnVwYW0gPHZhbnVwYW1A Z29vZ2xlLmNvbT47IEJpbGwgQ294IDx3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPjsgVG9rYmluZCBX RyA8dW5iZWFyYWJsZUBpZXRmLm9yZz47IHRva2VuLWJpbmRpbmctdGVhbSA8dG9rZW4tYmluZGlu Zy10ZWFtQGdvb2dsZS5jb20+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFRva2VuIGJpbmRp bmcgdmVyc2lvbiAoMCwgMTApIHN1cHBvcnQgaXMgZ2xvYmFsIG9uIGdvb2dsZSBzZXJ2ZXJzDQoN CkZZSToNCldlIGFyZSB1cGRhdGluZyBHb29nbGUgc2VydmVycyB0byBvbmx5IHN1cHBvcnQgVG9r ZW4gQmluZGluZyB2ZXJzaW9uICgwLCAxMykuDQoNCk9uIEZyaSwgSmFuIDIwLCAyMDE3IGF0IDEx OjQ2IEFNLCBQcmFuYXYgS3VrcmVqYSA8cHJhbmF2a0BtaWNyb3NvZnQuY29tPG1haWx0bzpwcmFu YXZrQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkFudXBhbSwgYXJlIHRob3NlIGNvbm5lY3Rpb25z IGZyb20gRWRnZSByZXN1bHRpbmcgaW4gYW55IGNvbm5lY3Rpb24gZXJyb3JzIHBvc3QgdGhlIFRM UyBoYW5kc2hha2UsIGVzcGVjaWFsbHkgZHVyaW5nIGZhbHNlIHN0YXJ0LiBJIGFtIGNoYXNpbmcg ZG93biBzb21lIGludGVyb3AgaXNzdWVzIHdpdGggRWRnZSB0YWxraW5nIHRvIGdvb2dsZSBzZXJ2 ZXJzIHdpdGggVEIgZW5hYmxlZCBhdCB0aGUgbW9tZW50LiBJZiB5b3Ugbm90aWNlIGFueXRoaW5n IHBsZWFzZSBsZXQgdXMga25vdy4NCg0KVGhhbmtzIQ0KUHJhbmF2DQoNCkZyb206IFVuYmVhcmFi bGUgW21haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnVuYmVhcmFibGUt Ym91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBWaW5vZCBBbnVwYW0NClNlbnQ6IEZyaWRh eSwgSmFudWFyeSAyMCwgMjAxNyAxMDowMiBBTQ0KVG86IEJpbGwgQ294IDx3YXl3YXJkZ2Vla0Bn b29nbGUuY29tPG1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPj4NCkNjOiBUb2tiaW5kIFdH IDx1bmJlYXJhYmxlQGlldGYub3JnPG1haWx0bzp1bmJlYXJhYmxlQGlldGYub3JnPj47IHRva2Vu LWJpbmRpbmctdGVhbSA8dG9rZW4tYmluZGluZy10ZWFtQGdvb2dsZS5jb208bWFpbHRvOnRva2Vu LWJpbmRpbmctdGVhbUBnb29nbGUuY29tPj4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gVG9r ZW4gYmluZGluZyB2ZXJzaW9uICgwLCAxMCkgc3VwcG9ydCBpcyBnbG9iYWwgb24gZ29vZ2xlIHNl cnZlcnMNCg0KDQoNCk9uIEZyaSwgSmFuIDIwLCAyMDE3IGF0IDQ6MjkgQU0sIEJpbGwgQ294IDx3 YXl3YXJkZ2Vla0Bnb29nbGUuY29tPG1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPj4gd3Jv dGU6DQpJJ20gc2VlaW5nIDUuN0sgdG9rZW4gYmluZGluZyBoZWFkZXJzIHBlciBzZWNvbmQgYXQg dGhlIG1vbWVudCwgYWJvdXQgNUsvcyBzZW5kaW5nIGJvdGggY2hhbm5lbC1JRCBhbmQgdG9rZW4g YmluZGluZyAocHJvYmFibHkgY2hyb21lKSwgYW5kIGFib3V0IDcwMC9zIHdpdGgganVzdCB0b2tl biBiaW5kaW5nIChwcm9iYWJseSBub3QgY2hyb21lKS4NCg0KQmFzZWQgb24gaW5mb3JtYXRpb24g aW4gb3VyIGxvZ3MsIHRoZSByZXF1ZXN0cyB3aXRoIGp1c3QgdG9rZW4gYmluZGluZyBoZWFkZXJz IGFyZSBwcmltYXJpbHkgZnJvbSBFZGdlLg0KDQpjaGVlcnMsDQotQW51cGFtDQoNCg0KQmlsbA0K LS0NCllvdSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgYmVjYXVzZSB5b3UgYXJlIHN1YnNjcmliZWQg dG8gdGhlIEdvb2dsZSBHcm91cHMgInRva2VuLWJpbmRpbmctdGVhbSIgZ3JvdXAuDQpUbyB1bnN1 YnNjcmliZSBmcm9tIHRoaXMgZ3JvdXAgYW5kIHN0b3AgcmVjZWl2aW5nIGVtYWlscyBmcm9tIGl0 LCBzZW5kIGFuIGVtYWlsIHRvIHRva2VuLWJpbmRpbmctdGVhbSt1bnN1YnNjcmliZUBnb29nbGUu Y29tPG1haWx0bzp0b2tlbi1iaW5kaW5nLXRlYW0rdW5zdWJzY3JpYmVAZ29vZ2xlLmNvbT4uDQpU byBwb3N0IHRvIHRoaXMgZ3JvdXAsIHNlbmQgZW1haWwgdG8gdG9rZW4tYmluZGluZy10ZWFtQGdv b2dsZS5jb208bWFpbHRvOnRva2VuLWJpbmRpbmctdGVhbUBnb29nbGUuY29tPi4NClRvIHZpZXcg dGhpcyBkaXNjdXNzaW9uIG9uIHRoZSB3ZWIgdmlzaXQgaHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNv bS9hL2dvb2dsZS5jb20vZC9tc2dpZC90b2tlbi1iaW5kaW5nLXRlYW0vQ0FIOVF0UUhpTU5LVFdr RXhEZHVIJTNEaHVDenMlM0R5VlclMkJFN1lNM1dub2gwRG9lWVVlMDhBJTQwbWFpbC5nbWFpbC5j b208aHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9hL2dvb2dsZS5jb20vZC9tc2dpZC90b2tlbi1i aW5kaW5nLXRlYW0vQ0FIOVF0UUhpTU5LVFdrRXhEZHVIJTNEaHVDenMlM0R5VlclMkJFN1lNM1du b2gwRG9lWVVlMDhBJTQwbWFpbC5nbWFpbC5jb20/dXRtX21lZGl1bT1lbWFpbCZ1dG1fc291cmNl PWZvb3Rlcj4uDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0DQpVbmJlYXJhYmxlQGlldGYub3JnPG1haWx0 bzpVbmJlYXJhYmxlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby91bmJlYXJhYmxlDQoNCg== --_000_BN3PR03MB23233EDF7E9880C7F385385CB0530BN3PR03MB2323namp_ 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 CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4ubS02MzI3OTg1MjA5 MzA0NDU2ODI3Z21haWwtaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOm1fLTYzMjc5ODUyMDkzMDQ0 NTY4MjdnbWFpbC1ob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+JiM0MztBbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzIGZvciB0aGUgaGVhZHMgdXAgTmlj ay4gQ3VycmVudCBNaWNyb3NvZnQgaXMgYWR2ZXJ0aXNpbmcgMC4xMCwgc28gd2Ugd2lsbCB0cmFj ayB0aGlzIHVwZGF0ZSBvbiBvdXIgZW5kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gTmljayBIYXJwZXIgW21haWx0bzpuaGFycGVyQGdvb2dsZS5j b21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDIzLCAyMDE3IDEyOjA1 IFBNPGJyPg0KPGI+VG86PC9iPiBQcmFuYXYgS3VrcmVqYSAmbHQ7cHJhbmF2a0BtaWNyb3NvZnQu Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gVmlub2QgQW51cGFtICZsdDt2YW51cGFtQGdvb2dsZS5j b20mZ3Q7OyBCaWxsIENveCAmbHQ7d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbSZndDs7IFRva2JpbmQg V0cgJmx0O3VuYmVhcmFibGVAaWV0Zi5vcmcmZ3Q7OyB0b2tlbi1iaW5kaW5nLXRlYW0gJmx0O3Rv a2VuLWJpbmRpbmctdGVhbUBnb29nbGUuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W1VuYmVhcmFibGVdIFRva2VuIGJpbmRpbmcgdmVyc2lvbiAoMCwgMTApIHN1cHBvcnQgaXMgZ2xv YmFsIG9uIGdvb2dsZSBzZXJ2ZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RllJOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFy ZSB1cGRhdGluZyBHb29nbGUgc2VydmVycyB0byBvbmx5IHN1cHBvcnQgVG9rZW4gQmluZGluZyB2 ZXJzaW9uICgwLCAxMykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIEZyaSwgSmFuIDIwLCAyMDE3IGF0IDExOjQ2IEFNLCBQcmFuYXYgS3Vr cmVqYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnByYW5hdmtAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnByYW5hdmtAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbnVw YW0sIGFyZSB0aG9zZSBjb25uZWN0aW9ucyBmcm9tIEVkZ2UgcmVzdWx0aW5nIGluIGFueSBjb25u ZWN0aW9uIGVycm9ycyBwb3N0IHRoZSBUTFMgaGFuZHNoYWtlLCBlc3BlY2lhbGx5IGR1cmluZyBm YWxzZSBzdGFydC4gSSBhbSBjaGFzaW5nIGRvd24gc29tZSBpbnRlcm9wIGlzc3VlcyB3aXRoIEVk Z2UNCiB0YWxraW5nIHRvIGdvb2dsZSBzZXJ2ZXJzIHdpdGggVEIgZW5hYmxlZCBhdCB0aGUgbW9t ZW50LiBJZiB5b3Ugbm90aWNlIGFueXRoaW5nIHBsZWFzZSBsZXQgdXMga25vdy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+UHJhbmF2PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4g VW5iZWFyYWJsZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj51bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5WaW5vZCBBbnVwYW08YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBKYW51YXJ5IDIwLCAyMDE3IDEwOjAyIEFNPGJyPg0KPGI+VG86PC9iPiBCaWxsIENveCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj53 YXl3YXJkZ2Vla0Bnb29nbGUuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IFRva2JpbmQgV0cg Jmx0OzxhIGhyZWY9Im1haWx0bzp1bmJlYXJhYmxlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ dW5iZWFyYWJsZUBpZXRmLm9yZzwvYT4mZ3Q7OyB0b2tlbi1iaW5kaW5nLXRlYW0gJmx0OzxhIGhy ZWY9Im1haWx0bzp0b2tlbi1iaW5kaW5nLXRlYW1AZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnRva2VuLWJpbmRpbmctdGVhbUBnb29nbGUuY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtVbmJlYXJhYmxlXSBUb2tlbiBiaW5kaW5nIHZlcnNpb24gKDAsIDEwKSBzdXBwb3J0 IGlzIGdsb2JhbCBvbiBnb29nbGUgc2VydmVyczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P biBGcmksIEphbiAyMCwgMjAxNyBhdCA0OjI5IEFNLCBCaWxsIENveCAmbHQ7PGEgaHJlZj0ibWFp bHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj53YXl3YXJkZ2Vla0Bn b29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkknbSBzZWVpbmcgNS43SyB0b2tlbiBiaW5kaW5nIGhlYWRlcnMgcGVyIHNlY29uZCBh dCB0aGUgbW9tZW50LCBhYm91dCA1Sy9zIHNlbmRpbmcgYm90aCBjaGFubmVsLUlEIGFuZCB0b2tl biBiaW5kaW5nIChwcm9iYWJseSBjaHJvbWUpLCBhbmQgYWJvdXQgNzAwL3Mgd2l0aCBqdXN0IHRv a2VuIGJpbmRpbmcgKHByb2JhYmx5DQogbm90IGNocm9tZSkuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CYXNl ZCBvbiBpbmZvcm1hdGlvbiBpbiBvdXIgbG9ncywgdGhlIHJlcXVlc3RzIHdpdGgganVzdCB0b2tl biBiaW5kaW5nIGhlYWRlcnMgYXJlIHByaW1hcmlseSBmcm9tIEVkZ2UuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5jaGVlcnMsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi1BbnVwYW08 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv cjojODg4ODg4Ij5CaWxsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gY2xhc3M9Im0tNjMyNzk4NTIwOTMwNDQ1NjgyN2dt YWlsLWhvZW56YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPi0tDQo8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0ibS02MzI3OTg1 MjA5MzA0NDU2ODI3Z21haWwtaG9lbnpiIj5Zb3UgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGJlY2F1 c2UgeW91IGFyZSBzdWJzY3JpYmVkIHRvIHRoZSBHb29nbGUgR3JvdXBzICZxdW90O3Rva2VuLWJp bmRpbmctdGVhbSZxdW90OyBncm91cC48L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Im0tNjMyNzk4 NTIwOTMwNDQ1NjgyN2dtYWlsLWhvZW56YiI+VG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGdyb3Vw IGFuZCBzdG9wIHJlY2VpdmluZyBlbWFpbHMgZnJvbSBpdCwgc2VuZCBhbiBlbWFpbCB0bw0KPGEg aHJlZj0ibWFpbHRvOnRva2VuLWJpbmRpbmctdGVhbSYjNDM7dW5zdWJzY3JpYmVAZ29vZ2xlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnRva2VuLWJpbmRpbmctdGVhbSYjNDM7dW5zdWJzY3JpYmVAZ29v Z2xlLmNvbTwvYT4uPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJtLTYzMjc5ODUyMDkzMDQ0NTY4 MjdnbWFpbC1ob2VuemIiPlRvIHBvc3QgdG8gdGhpcyBncm91cCwgc2VuZCBlbWFpbCB0bw0KPGEg aHJlZj0ibWFpbHRvOnRva2VuLWJpbmRpbmctdGVhbUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFu ayI+dG9rZW4tYmluZGluZy10ZWFtQGdvb2dsZS5jb208L2E+Ljwvc3Bhbj48YnI+DQo8c3BhbiBj bGFzcz0ibS02MzI3OTg1MjA5MzA0NDU2ODI3Z21haWwtaG9lbnpiIj5UbyB2aWV3IHRoaXMgZGlz Y3Vzc2lvbiBvbiB0aGUgd2ViIHZpc2l0DQo8YSBocmVmPSJodHRwczovL2dyb3Vwcy5nb29nbGUu Y29tL2EvZ29vZ2xlLmNvbS9kL21zZ2lkL3Rva2VuLWJpbmRpbmctdGVhbS9DQUg5UXRRSGlNTktU V2tFeERkdUglM0RodUN6cyUzRHlWVyUyQkU3WU0zV25vaDBEb2VZVWUwOEElNDBtYWlsLmdtYWls LmNvbT91dG1fbWVkaXVtPWVtYWlsJmFtcDt1dG1fc291cmNlPWZvb3RlciIgdGFyZ2V0PSJfYmxh bmsiPg0KaHR0cHM6Ly9ncm91cHMuZ29vZ2xlLmNvbS9hL2dvb2dsZS5jb20vZC9tc2dpZC90b2tl bi1iaW5kaW5nLXRlYW0vQ0FIOVF0UUhpTU5LVFdrRXhEZHVIJTNEaHVDenMlM0R5VlclMkJFN1lN M1dub2gwRG9lWVVlMDhBJTQwbWFpbC5nbWFpbC5jb208L2E+Ljwvc3Bhbj48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpVbmJlYXJh YmxlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpVbmJlYXJhYmxlQGlldGYub3Jn Ij5VbmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZTwvYT48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN3PR03MB23233EDF7E9880C7F385385CB0530BN3PR03MB2323namp_-- From nobody Thu Feb 23 12:29:09 2017 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 E836E129D22 for ; Wed, 22 Feb 2017 15:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.887 X-Spam-Level: X-Spam-Status: No, score=-8.887 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_HI=-5, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 SoWFlId-tTtl for ; Wed, 22 Feb 2017 15:34:16 -0800 (PST) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ADAE129D29 for ; Wed, 22 Feb 2017 15:34:14 -0800 (PST) Date: Wed, 22 Feb 2017 15:34:13 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1487806453; bh=+qquOlV8c4wrT5Y9NrWpbGb9+KngAedLGEICiz7GJoE=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=HlyRxMw5//vXKyzjXIDzlfFZ/xh5M/bMsIHhxcbTKB7LQbOvPVuUosh2ZA55QrRB+ 3zSVfY/XJqBGq9Wg9B7wZtC+NKSMsJd4XwS+wLo0lyI9y/F0JYhxpDT0soOZT2d1mK 8i/piymMmFc5JUvpLNP4Y5GM2g5XGJlda04Jgtlw= From: Andrei-Popov To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58ae1ff551099_1f983f8064757140741c5"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: Andrei-Popov X-GitHub-Recipient: unbearable-ML X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Thu, 23 Feb 2017 12:29:08 -0800 Cc: Subscribed Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] ramifications of longer EKMs (#95) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Reply-To: TokenBinding/Internet-Drafts 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, 22 Feb 2017 23:34:18 -0000 ----==_mimepart_58ae1ff551099_1f983f8064757140741c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The WG decided that the negotiated TB key parameters (specifically, signa= ture scheme), rather than TB version, determine the size of the EKM. This= means that a =E2=80=9Cdumb=E2=80=9D (or =E2=80=9Cslim=E2=80=9D?) TTRP su= pporting TB vX does not guarantee compatibility with all TB key types tha= t may be defined (perhaps, after the TTRP ships) for TB vX. =EF=83=98 It's even less ideal for the model that's proposed in HTTPS Tok= en Binding and TLS Terminating Reverse Proxies because the TLS Terminatin= g Reverse Proxy (TTRP), which we are trying to keep as "dumb" as possible= , has to process the TokenBindingMessage to know the length of the EKM(s)= that it will pass along in the Token-Binding-Context header/message. Parsing TB messages at TTRP is not necessary: the TTRP could pass along a= ll EKM lengths it supports (at the cost of extra bytes on the wire). Even= then, a new signature scheme can be defined requiring an EKM length that= is not supported by the TTRP. My preferred option is 3), where TB v 1.0 will only ever use 32-byte EKM = values. Future TB versions may define some other EKM(s). I could live with option 1) as well, but then I would be reluctant to neg= otiate those TB key parameters that require a different EKM length (for T= B v 1.0). Which effectively turns option 1) into option 3) =EF=81=8A. Option 2) does not make sense to me, because TTRP can=E2=80=99t realistic= ally require one particular model of TB processing in a datacenter (as th= ere is little reason for a datacenter operator to comply). Option 4) defeats the purpose of having per-signature-scheme EKM lengths.= If we don=E2=80=99t care for per-signature-scheme EKM lengths, then we s= hould go with 3). -- = You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/TokenBinding/Internet-Drafts/issues/95#issuecomment-28= 1840618= ----==_mimepart_58ae1ff551099_1f983f8064757140741c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The WG decided that the negotiated TB key parameters (specifically, si= gnature scheme), rather than TB version, determine the size of the EKM. T= his means that a =E2=80=9Cdumb=E2=80=9D (or =E2=80=9Cslim=E2=80=9D?) TTRP= supporting TB vX does not guarantee compatibility with all TB key types = that may be defined (perhaps, after the TTRP ships) for TB vX.

=EF=83=98 It's even less ideal for the model that's proposed in HTTPS = Token Binding and TLS Terminating Reverse Proxies because the TLS Termina= ting Reverse Proxy (TTRP), which we are trying to keep as "dumb" as possi= ble, has to process the TokenBindingMessage to know the length of the EKM= (s) that it will pass along in the Token-Binding-Context header/message.<= br> Parsing TB messages at TTRP is not necessary: the TTRP could pass along a= ll EKM lengths it supports (at the cost of extra bytes on the wire). Even= then, a new signature scheme can be defined requiring an EKM length that= is not supported by the TTRP.

My preferred option is 3), where TB v 1.0 will only ever use 32-byte E= KM values. Future TB versions may define some other EKM(s).
I could live with option 1) as well, but then I would be reluctant to neg= otiate those TB key parameters that require a different EKM length (for T= B v 1.0). Which effectively turns option 1) into option 3) =EF=81=8A.
= Option 2) does not make sense to me, because TTRP can=E2=80=99t realistic= ally require one particular model of TB processing in a datacenter (as th= ere is little reason for a datacenter operator to comply).
Option 4) defeats the purpose of having per-signature-scheme EKM lengths.= If we don=E2=80=99t care for per-signature-scheme EKM lengths, then we s= hould go with 3).

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on Git= Hub, or mute the thread= .3D""

= ----==_mimepart_58ae1ff551099_1f983f8064757140741c5-- From nobody Thu Feb 23 12:58:55 2017 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 B2DDA1294DF for ; Thu, 23 Feb 2017 12:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zmartzone-eu.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 TnK5KCQ6dxz7 for ; Thu, 23 Feb 2017 12:58:51 -0800 (PST) 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 9866A129AE1 for ; Thu, 23 Feb 2017 12:58:50 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id l12so1323346lfe.0 for ; Thu, 23 Feb 2017 12:58:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tH9nulBH0C30sevw1WnqdtjbGOvEaf7x3Vieg13fUwM=; b=Jo1vOoXMda2FydHZNJeQhyVUJDWgY9zJeIKFapTT3/vON7vPm9JrKj978AqmQtrAWM DzqboTxCVUQqvxlShv2BPlVoiVCY7UTHjuC8UL4MqUDy3Kozx90DAylHhHSzQYTGfGfr FQg8NdfV7nsyZA0Ul0uZf9gQBE3/5gFov0hsktLdyfVAvovkTm9tb3ck85HiPBfm1OKL zSAetkTUpx0L+5Pi5yi7qwtzs6+CL7PyvbIw69ExU2bO02cUgq+ppfXD9p0pTMlSLRWL v0FCZA/uBQFIyAwCzHIHTzk0ygEwlATkyoz49gDJvysOkN0LzF3zCG/I23wCtDGvMtpQ qpUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tH9nulBH0C30sevw1WnqdtjbGOvEaf7x3Vieg13fUwM=; b=FtDAicycEJNt6bB5VJz4qg7NoOb0rQ1FhRJsxXgfhnRP/OePwvNrMhNDfZOBTo32cv 0Vthwcwx2S9CFDLnIAwg6yxEeSWnz6yISF5BoIWQu2ru00UDJRwpXPcEnhjJsAZ13pQQ R2EVwjuCbORdBKAmF6oMUi1fwlz8BJ7dEjCHqf9XQdRB4rNF68irAgqkHiZxEQ4FDp11 2pYPlGiyiqgizQpdx3s6Dx+tThs3rVcuMXdw5OS3i1nvOhm6nCXEl+rF80Vc/vTOAhw/ LdsFnf/aLpSHTyjY3HDBOApE9p4B31QpKFGQqsHF+5mKOD0CN1LDcunWZheAZBC244ex aN5Q== X-Gm-Message-State: AMke39nQui7ue43x+tXpCXrT+LnuEyaBPwUVwEvSeoaB2MrHFwC7Wcnnpzt9yTmU4pcXYkP/OE+wvsJ0QcHLq57H X-Received: by 10.25.157.146 with SMTP id g140mr11326650lfe.123.1487883528662; Thu, 23 Feb 2017 12:58:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.202.85 with HTTP; Thu, 23 Feb 2017 12:58:48 -0800 (PST) X-Originating-IP: [82.74.246.215] In-Reply-To: References: From: Hans Zandbelt Date: Thu, 23 Feb 2017 21:58:48 +0100 Message-ID: To: Nick Harper Content-Type: multipart/alternative; boundary=001a11411a06319a11054938e148 Archived-At: Cc: Vinod Anupam , Pranav Kukreja , Tokbind WG , token-binding-team , Bill Cox Subject: Re: [Unbearable] Token binding version (0, 10) support is global on google servers 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: Thu, 23 Feb 2017 20:58:53 -0000 --001a11411a06319a11054938e148 Content-Type: text/plain; charset=UTF-8 FYI: I'm working on a module for Apache HTTPd here: https://github.com/zmartzone/mod_token_binding which relies on Google's token_bind library https://github.com/google/token_bind any chance that that library is going to be upgraded to (0, 13) as well? Hans. On Thu, Feb 23, 2017 at 9:05 PM, Nick Harper wrote: > FYI: > We are updating Google servers to only support Token Binding version (0, > 13). > > On Fri, Jan 20, 2017 at 11:46 AM, Pranav Kukreja > wrote: > >> Anupam, are those connections from Edge resulting in any connection >> errors post the TLS handshake, especially during false start. I am chasing >> down some interop issues with Edge talking to google servers with TB >> enabled at the moment. If you notice anything please let us know. >> >> >> >> Thanks! >> >> Pranav >> >> >> >> *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Vinod >> Anupam >> *Sent:* Friday, January 20, 2017 10:02 AM >> *To:* Bill Cox >> *Cc:* Tokbind WG ; token-binding-team < >> token-binding-team@google.com> >> *Subject:* Re: [Unbearable] Token binding version (0, 10) support is >> global on google servers >> >> >> >> >> >> >> >> On Fri, Jan 20, 2017 at 4:29 AM, Bill Cox wrote: >> >> I'm seeing 5.7K token binding headers per second at the moment, about >> 5K/s sending both channel-ID and token binding (probably chrome), and about >> 700/s with just token binding (probably not chrome). >> >> >> >> Based on information in our logs, the requests with just token binding >> headers are primarily from Edge. >> >> >> >> cheers, >> >> -Anupam >> >> >> >> >> >> Bill >> >> -- >> You received this message because you are subscribed to the Google Groups >> "token-binding-team" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to token-binding-team+unsubscribe@google.com. >> To post to this group, send email to token-binding-team@google.com. >> To view this discussion on the web visit https://groups.google.com/a/go >> ogle.com/d/msgid/token-binding-team/CAH9QtQHiMNKTWkExDduH%3DhuCzs%3DyVW% >> 2BE7YM3Wnoh0DoeYUe08A%40mail.gmail.com >> >> . >> >> >> >> _______________________________________________ >> 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 > > -- hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --001a11411a06319a11054938e148 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI: I'm working on a module for Apache HTTPd here:https://github= .com/zmartzone/mod_token_binding

which rel= ies on Google's token_bind library

any chance that that library is going to be upgraded to (= 0, 13) as well?

Hans.

On Thu, Feb 23, 2017 at 9:05 PM, Nick Ha= rper <nharper@google.com> wrote:
FYI:
We are updating Google= servers to only support Token Binding version (0, 13).

On Fri, Jan 20, 2017 at 1= 1:46 AM, Pranav Kukreja <pranavk@microsoft.com> wrote:

Anupam, are those connections from Edge resulting in= any connection errors post the TLS handshake, especially during false star= t. I am chasing down some interop issues with Edge talking to google server= s with TB enabled at the moment. If you notice anything please let us know.

=C2=A0

Thanks!

Pranav

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ietf.o= rg] On Behalf Of Vinod Anupam
Sent: Friday, January 20, 2017 10:02 AM
To: Bill Cox <waywardgeek@google.com>
Cc: Tokbind WG <unbearable@ietf.org>; token-binding-team <token-binding-team@goog= le.com>
Subject: Re: [Unbearable] Token binding version (0, 10)= support is global on google servers

=C2=A0

=C2=A0

=C2=A0

On Fri, Jan 20, 2017 at 4:29 AM, Bill Cox <waywardgeek@google.co= m> wrote:

I'm seeing 5.7K token binding headers per second= at the moment, about 5K/s sending both channel-ID and token binding (proba= bly chrome), and about 700/s with just token binding (probably not chrome).=

=C2=A0

Based on information in our logs, the requests with = just token binding headers are primarily from Edge.

=C2=A0

cheers,

-Anupam

=C2=A0

=C2=A0=

Bill

--
You received this message because you are subscribed to the Google Grou= ps "token-binding-team" group.
To unsubscribe from this group and stop receiving emails from it, send = an email to token-binding-team+unsubscribe@google.com.
To post to this group, send email to token-binding-team@google.com.
To view this discussion on the web visit https://groups.google.com/a/google.com/d/msgid/token-binding-team= /CAH9QtQHiMNKTWkExDduH%3DhuCzs%3DyVW%2BE7YM3Wnoh0DoeYUe08A%40mail= .gmail.com.

=C2=A0


_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearabl= e



_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearabl= e




--
--001a11411a06319a11054938e148-- From nobody Thu Feb 23 13:00:54 2017 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 7E64C12A2E2 for ; Thu, 23 Feb 2017 13:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ffgg532tUsxP for ; Thu, 23 Feb 2017 13:00:52 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0121.outbound.protection.outlook.com [104.47.36.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1ECC12A2CC for ; Thu, 23 Feb 2017 13:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZgiqD9paAN153fTotf4R9bgB9zBwNRbEWxKV0gzx6to=; b=gIa9YruR5ZNPO5f3gdQLStq5vRr61D9XTjt6nmPAxN2JbPzh8DfH7/Ng5od1M95XTLldiAi2VspOvxJU0He+FsO72mg3flckfCjvOKPUPJql8DlZwitevwfgsY6WltqZD3F3b0o8lXrGt3ZRoBlUwz2AairVpbD6d2YXGj4+ASs= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB2026.namprd03.prod.outlook.com (10.164.2.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Thu, 23 Feb 2017 21:00:49 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0919.018; Thu, 23 Feb 2017 21:00:50 +0000 From: Andrei Popov To: Anthony Nadalin , Brian Campbell Thread-Topic: [Unbearable] ramifications of longer EKMs Thread-Index: AQHSjVYgmQf/q9+NMUG8uI+0qEZ9BqF1ncIggAAZn4CAAACqsIAADg1QgADNxwCAAE0DAIAAJ7Pw Date: Thu, 23 Feb 2017 21:00:49 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: fb2b8a26-1fba-4622-812f-08d45c2f0c18 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB2026; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB2026; 7:BKx5A5yOqLAdTNQXeFOZxZrbkAj/BAgYA8mB5nxE63AclBQddB+bXI0w8rfPwtcgLyyh8VEIp7J6yj19kAuA6T9WXpWAwz6wzPi79qGE7lQLuGtFjJV+CAfsHj27hUER2ybL1cENnKraC1XrKoqgVN+pwWxCr8DPbGpyCvWsaZaPqQb+ZT95UY2+6BrWppEcvytuhAiff4g4LMdc+rJqLmbbRUFS875Eqvk8VxWYwkXNrXv8R0Ucp6SGqHPZ/roS7+ix5XDBfb+G25X2s4xVnrIknRKOdyllidAHBflU7wZt5cdAj6p79qh0cDPJehojqgnWVf4SUzYAWe1YEwFOmtXbwyzlH7Kdk2Ic+QNAxkQ= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:CY1PR0301MB2026; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB2026; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39450400003)(39860400002)(39840400002)(39850400002)(199003)(377454003)(189002)(8990500004)(10290500002)(10090500001)(2561002)(5005710100001)(97736004)(122556002)(6436002)(7696004)(54356999)(76176999)(93886004)(189998001)(50986999)(1511001)(4326007)(3280700002)(2950100002)(790700001)(102836003)(6116002)(5660300001)(2906002)(3660700001)(2421001)(7736002)(74316002)(105586002)(19609705001)(33656002)(81166006)(92566002)(8676002)(106116001)(101416001)(53546006)(86612001)(81156014)(68736007)(8936002)(55016002)(86362001)(99286003)(2900100001)(9686003)(25786008)(6306002)(54896002)(6246003)(77096006)(229853002)(53936002)(6506006)(38730400002)(106356001)(148743002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB2026; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842CE7EE8AB1A0BC01C95268C530CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 21:00:50.0202 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB2026 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] ramifications of longer EKMs 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: Thu, 23 Feb 2017 21:00:53 -0000 --_000_CY1PR0301MB0842CE7EE8AB1A0BC01C95268C530CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG9rYmluZC10bHMtdGVybSBkb2VzIG5vdCBuZWNlc3NhcmlseSBoYXZlIHRvIGJlIG9uIHRoZSBz dGFuZGFyZHMgdHJhY2ssIGJ1dCBJIHRoaW5rIHRoZSBpc3N1ZSBCcmlhbiBoYXMgcmFpc2VkIGRl c2VydmVzIGRpc2N1c3Npb24gcmVnYXJkbGVzcyBvZiB0aGUgZGVzdGlueSBvZiB0b2tiaW5kLXRs cy10ZXJtLg0KDQpXUlQgQnJpYW7igJlzIGxpc3RlZCBvcHRpb25zLCBJIHByZWZlciAzKSBvciwg ZmFpbGluZyB0aGF0LCAxKS4NCk9wdGlvbiAyKSBhZmZlY3RzIHRoZSB0b2tiaW5kLXRscy10ZXJt IGRvY3VtZW50LCBub3QgdGhlIGNvcmUgSS1EczsgZnJvbSB0aGUgY29yZSBJLUQgcGVyc3BlY3Rp dmUgaXQgaXMgaWRlbnRpY2FsIHRvIG9wdGlvbiAxKS4NCk9wdGlvbiA0KSBtYWtlcyB0aGUgVEIg a2V5IHBhcmFtZXRlciBuZWdvdGlhdGlvbiBsZXNzIGRlZmluaXRpdmUuIEl0IHNheXMgdGhhdCB0 aGUgbGVuZ3RoIG9mIHRoZSBFS00gbm93IGRlcGVuZHMgbm90IG9ubHkgb24gdGhlIHNpZ25hdHVy ZSBzY2hlbWUgb2YgdGhlIFRCIGtleSB0aGF0IHNpZ25zIHRoaXMgRUtNLCBidXQgYWxzbyBvbiB0 aGUgdHlwZSBvZiB0aGUgQmluZGluZywgYW5kIG9uIHRoZSBzaWduYXR1cmUgc2NoZW1lIG9mIGEg ZGlmZmVyZW50LCB1bnJlbGF0ZWQgVEIga2V5Lg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9t OiBBbnRob255IE5hZGFsaW4NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyMywgMjAxNyA5OjU0 IEFNDQpUbzogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPjsgQW5k cmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4NCkNjOiBJRVRGIFRva2JpbmQg V0cgPHVuYmVhcmFibGVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW1VuYmVhcmFibGVdIHJhbWlm aWNhdGlvbnMgb2YgbG9uZ2VyIEVLTXMNCg0KSeKAmW0gbm90IHN1cmUgdGhlIHZhbHVlIG9mIHN0 YW5kYXJkaXppbmcgdGhlIHRva2JpbmQtdGxzLXRlcm0sIG5vdCBzdXJlIGhvdyBtdWNoIGludGVy b3BlcmFiaWxpdHkgcmVxdWlyZW1lbnRzIHRoZXJlIGFyZSBoZXJlLCBtYXliZSB0aGlzIHNob3Vs ZCBiZSBhbiBleHBlcmltZW50YWwgdW50aWwgd2UgZmlndXJlIG91dCBpZiB0aGVyZSBpcyBhIG5l ZWQgYW5kIGlmIHNvIHdoYXQgYXJlIHRoZSByZXF1aXJlbWVudHMNCg0KDQo= --_000_CY1PR0301MB0842CE7EE8AB1A0BC01C95268C530CY1PR0301MB0842_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuZ21haWwtbTk0Mzk1NTU5NDkwMjQx Mjc4bXNvbGlzdHBhcmFncmFwaCwgbGkuZ21haWwtbTk0Mzk1NTU5NDkwMjQxMjc4bXNvbGlzdHBh cmFncmFwaCwgZGl2LmdtYWlsLW05NDM5NTU1OTQ5MDI0MTI3OG1zb2xpc3RwYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLW5hbWU6Z21haWwtbV85NDM5NTU1OTQ5MDI0MTI3OG1zb2xpc3RwYXJhZ3JhcGg7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm05NDM5NTU1OTQ5MDI0 MTI3OG1zb2xpc3RwYXJhZ3JhcGgsIGxpLm05NDM5NTU1OTQ5MDI0MTI3OG1zb2xpc3RwYXJhZ3Jh cGgsIGRpdi5tOTQzOTU1NTk0OTAyNDEyNzhtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1u YW1lOm1fOTQzOTU1NTk0OTAyNDEyNzhtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5nbWFpbC0NCgl7bXNvLXN0eWxlLW5hbWU6Z21h aWwtO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5 bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRva2Jp bmQtdGxzLXRlcm0gZG9lcyBub3QgbmVjZXNzYXJpbHkgaGF2ZSB0byBiZSBvbiB0aGUgc3RhbmRh cmRzIHRyYWNrLCBidXQgSSB0aGluayB0aGUgaXNzdWUgQnJpYW4gaGFzIHJhaXNlZCBkZXNlcnZl cyBkaXNjdXNzaW9uIHJlZ2FyZGxlc3Mgb2YgdGhlIGRlc3Rpbnkgb2YgdG9rYmluZC10bHMtdGVy bS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V1JUIEJyaWFu4oCZcyBsaXN0ZWQgb3B0aW9ucywg SSBwcmVmZXIgMykgb3IsIGZhaWxpbmcgdGhhdCwgMSkuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9wdGlvbiAyKSBhZmZlY3RzIHRoZSB0b2tiaW5kLXRscy10ZXJtIGRv Y3VtZW50LCBub3QgdGhlIGNvcmUgSS1EczsgZnJvbSB0aGUgY29yZSBJLUQgcGVyc3BlY3RpdmUg aXQgaXMgaWRlbnRpY2FsIHRvIG9wdGlvbiAxKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9wdGlvbiA0KSBtYWtlcyB0aGUgVEIga2V5IHBhcmFtZXRlciBuZWdvdGlhdGlv biBsZXNzIGRlZmluaXRpdmUuIEl0IHNheXMgdGhhdCB0aGUgbGVuZ3RoIG9mIHRoZSBFS00gbm93 IGRlcGVuZHMgbm90IG9ubHkgb24gdGhlIHNpZ25hdHVyZSBzY2hlbWUgb2YgdGhlIFRCIGtleSB0 aGF0IHNpZ25zIHRoaXMgRUtNLCBidXQgYWxzbyBvbiB0aGUgdHlwZSBvZiB0aGUgQmluZGluZywg YW5kIG9uIHRoZSBzaWduYXR1cmUNCiBzY2hlbWUgb2YgYSBkaWZmZXJlbnQsIHVucmVsYXRlZCBU QiBrZXkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QW5kcmVpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gQW50aG9ueSBOYWRhbGluIDxicj4NCjxiPlNlbnQ6 PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMjMsIDIwMTcgOTo1NCBBTTxicj4NCjxiPlRvOjwvYj4g QnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tJmd0OzsgQW5kcmVp IFBvcG92ICZsdDtBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+ IElFVEYgVG9rYmluZCBXRyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUkU6IFtVbmJlYXJhYmxlXSByYW1pZmljYXRpb25zIG9mIGxvbmdlciBFS01zPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBub3Qgc3VyZSB0aGUg dmFsdWUgb2Ygc3RhbmRhcmRpemluZyB0aGUgdG9rYmluZC10bHMtdGVybSwgbm90IHN1cmUgaG93 IG11Y2ggaW50ZXJvcGVyYWJpbGl0eSByZXF1aXJlbWVudHMgdGhlcmUgYXJlIGhlcmUsIG1heWJl IHRoaXMgc2hvdWxkIGJlIGFuIGV4cGVyaW1lbnRhbCB1bnRpbCB3ZSBmaWd1cmUgb3V0IGlmIHRo ZXJlIGlzIGEgbmVlZCBhbmQgaWYgc28gd2hhdCBhcmUgdGhlIHJlcXVpcmVtZW50czxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48 bzpwPiZuYnNwOzwvbzpwPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls RW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR0301MB0842CE7EE8AB1A0BC01C95268C530CY1PR0301MB0842_-- From nobody Thu Feb 23 13:17:51 2017 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 B67E112A303 for ; Thu, 23 Feb 2017 13:17:48 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 OPs226FWPo7s for ; Thu, 23 Feb 2017 13:17:47 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 22AAE12A2FA for ; Thu, 23 Feb 2017 13:17:47 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id 203so277729ith.0 for ; Thu, 23 Feb 2017 13:17:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Gt/rZ7ZvXu+QYT18i8xl30n+WeL0jdD58E3BPK6OwWM=; b=KL1kpRicCjEmE64EqKn551aDhpeLhVS+NQsUQzoy/EKHu8B4K8UITBeX2BrBSfAgZv nDTkGO5Pk5ZMpYT+BbxaFzAke4DmNvn7TmiJM2p9ozvCUpURC3/GYlT6jZKAA6i2hhWV dnC8n3GLbxzDmwpqk3/lnrk1yn/Y7lQdml9YkwgV8bBItJOrM0EvxliVAp/PsYc47w0e W2ID64oYtvo3k88FKbProe4s7wgC03qAv4PhfiU27MntfJwGTRyfJmsZqDLv8I9mUO1v bliGbdMrlMoyvdmKMrJJzoqecpFJc1TSyM4Teanh6PHvwwEzRHShkr8l3U1P2ub0WaH0 XoAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Gt/rZ7ZvXu+QYT18i8xl30n+WeL0jdD58E3BPK6OwWM=; b=KM3LUTpRHqROszTW8WWLb2PEOqPpaMi49Y6uYekj51EumUHFYTqlOuK4R1Ap3iTB8D 0zeTJnYuwazYGsHz+vfko6222GFDqYGQY6RndxFR3TOTXDYzpH+1hEIiXXlt2PgiOgcM jbUJE8Ccaob9jx6PCxMy2ldcmvNbsFkJveXmeAx0/byfn6+z1Lmu1YjN90hrr0lpy4J2 aNWFQ7TEAI+us7jZUVjH0mN3IOE22ITmRzMxHd/l7lLrtmncnacfLbi/HIAv0GH7KR0w toz2RBpvsLBbHulEM7oCl6txGvhdFwYcxB0YAvgszVN5uiu7L8lnXkSosI0gHsYnk8cY qvMA== X-Gm-Message-State: AMke39k13nUW6PlgRC7VDfa/Hz+StK9CV6dx69R064iXW44bDFDUoL1yMnbE26s2bCLG1kofQens4ez9Nya1BHPj X-Received: by 10.107.39.144 with SMTP id n138mr67613ion.188.1487884665929; Thu, 23 Feb 2017 13:17:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.152.41 with HTTP; Thu, 23 Feb 2017 13:17:45 -0800 (PST) In-Reply-To: References: From: Bill Cox Date: Thu, 23 Feb 2017 13:17:45 -0800 Message-ID: To: Hans Zandbelt Content-Type: multipart/alternative; boundary=001a1140a32afb3c300549392450 Archived-At: Cc: Vinod Anupam , Pranav Kukreja , Tokbind WG , token-binding-team , Nick Harper Subject: Re: [Unbearable] Token binding version (0, 10) support is global on google servers 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: Thu, 23 Feb 2017 21:17:49 -0000 --001a1140a32afb3c300549392450 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 23, 2017 at 12:58 PM, Hans Zandbelt wrote: > FYI: I'm working on a module for Apache HTTPd here: > https://github.com/zmartzone/mod_token_binding > > which relies on Google's token_bind library > https://github.com/google/token_bind > > any chance that that library is going to be upgraded to (0, 13) as well? > > Hans. > Yes, I'll do that now. Note that Google servers will reject version (0, 10) going forward. Hopefully this will be the last switch until version (1, 0). Bill --001a1140a32afb3c300549392450 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 23, 2017 at 12:58 PM, Hans Zandbelt <hans.zandbelt@zmar= tzone.eu> wrote:
FYI: I'm working on a module for Apache HTTPd here:

which relies on Google's token_bind library

any chance that tha= t library is going to be upgraded to (0, 13) as well?

<= div>Hans.

Yes, I'll do that= now.=C2=A0 Note that Google servers will reject version (0, 10) going forw= ard.=C2=A0 Hopefully this will be the last switch until version (1, 0).

Bill=C2=A0
--001a1140a32afb3c300549392450-- From nobody Thu Feb 23 13:49:09 2017 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 01587129B06 for ; Thu, 23 Feb 2017 13:49:06 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Oz62Bh_CKeD5 for ; Thu, 23 Feb 2017 13:49:04 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 6800C12940A for ; Thu, 23 Feb 2017 13:49:04 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id d9so7042230itc.0 for ; Thu, 23 Feb 2017 13:49:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=m0lb4B/HeJDJdaYM0PRa0q7b7M6fe+yEhgNdTECCjbs=; b=eVFh7QbTWplX8QCc2EBTZNpAAfxrRTVSaXxBKDRLqWebZUv6a8pmwlx6mUf+I6yEWn zjMMbISiAms4Q2DAdweSxPPmcqaDU5nMQme2XOnoDe1ndBXVfaH83t+BpLhXyYmmf91V qYWOjK41PLBrVsmwIp4WPxKP3jM5Lt3LLlaS1c+7Pc+kZJ78yLBd3cW4QQ60ZlqahZZj vI3th1EWFtCes3Ahuu6KUZ73skdyDW3ELSH4YjRaE6VRafNRLvgKdTrnrx/T/Bued/HR d28wGjLGrdqJfL+imwVNEe4/p6C8G7IdmabFHPxsUQUu68Uy6cxhOJB0c38R/B15E0qE Cuiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=m0lb4B/HeJDJdaYM0PRa0q7b7M6fe+yEhgNdTECCjbs=; b=fKi/NVrZ47l1ReQS8ddDaj8obe78inunT6P/EGQlDG1r/A992JUNPQ/iooTnUN0ipF ZlSDWArlY89T4jAiC6DpR2vtl/jujQrePdpTHQbMXyMaHDji7xjf2ogtCPruzSzU8klt mXZFiYa9fp4Nbnj5bQn0Mk/XkEAlT1wlfMJH1V+YBPlxPBqDeQoRV5FDe+MaSkDs8DY5 PthdF1HXunMYgGD9RXonDHhQM59Uo7FxpgrIVzwcNZCf/34q+yp5mbQnpLarjj6KT46D Dow9pgK3nrQ3HyFv6XIANraC6HaWK4degRg/NX55nrpmrgJ86NnKlccLA57RIzYX3xY9 /ZQQ== X-Gm-Message-State: AMke39n3H8f33TeqpZhHf6TKiPmK9ctL8YyBnOfG1MjJ/mqWEC3Fj1ik8QsevCTxGEiq4NZfTlzNw+UpwG3C0c5E X-Received: by 10.36.203.4 with SMTP id u4mr6292625itg.99.1487886543381; Thu, 23 Feb 2017 13:49:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.152.41 with HTTP; Thu, 23 Feb 2017 13:49:02 -0800 (PST) In-Reply-To: References: From: Bill Cox Date: Thu, 23 Feb 2017 13:49:02 -0800 Message-ID: To: Hans Zandbelt Content-Type: multipart/alternative; boundary=94eb2c0b0aa0e2db1305493994bb Archived-At: Cc: Vinod Anupam , Pranav Kukreja , Tokbind WG , token-binding-team , Nick Harper Subject: Re: [Unbearable] Token binding version (0, 10) support is global on google servers 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: Thu, 23 Feb 2017 21:49:06 -0000 --94eb2c0b0aa0e2db1305493994bb Content-Type: text/plain; charset=UTF-8 The library now supports version (0, 10) through (0, 13). However Google's front-end currently still supports only (0, 10), and when it switches, it will switch to only (0, 13) On Thu, Feb 23, 2017 at 1:17 PM, Bill Cox wrote: > On Thu, Feb 23, 2017 at 12:58 PM, Hans Zandbelt < > hans.zandbelt@zmartzone.eu> wrote: > >> FYI: I'm working on a module for Apache HTTPd here: >> https://github.com/zmartzone/mod_token_binding >> >> which relies on Google's token_bind library >> https://github.com/google/token_bind >> >> any chance that that library is going to be upgraded to (0, 13) as well? >> >> Hans. >> > > Yes, I'll do that now. Note that Google servers will reject version (0, > 10) going forward. Hopefully this will be the last switch until version > (1, 0). > > Bill > --94eb2c0b0aa0e2db1305493994bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The library now supports version (0, 10) through (0, 13).= =C2=A0 However Google's front-end currently still supports only (0, 10)= , and when it switches, it will switch to only (0, 13)

On Thu, Feb 23, 2017 at 1:17 PM,= Bill Cox <waywardgeek@google.com> wrote:
On Thu, Feb 23, 2017 at 12:58 PM, Hans Za= ndbelt <hans.zandbelt@zmartzone.eu> wrote:
FYI: I'm working on a module= for Apache HTTPd here:

which relies on Google's token_= bind library
=
any chance that that library is going to be upgraded to (0, = 13) as well?

Hans.
Yes, I'll do that now.=C2=A0 Note that Google serve= rs will reject version (0, 10) going forward.=C2=A0 Hopefully this will be = the last switch until version (1, 0).

Bill=C2=A0

--94eb2c0b0aa0e2db1305493994bb-- From nobody Thu Feb 23 15:49:37 2017 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 96F47129C77 for ; Thu, 23 Feb 2017 15:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 cQMKO_413w1m for ; Thu, 23 Feb 2017 15:49:35 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 C9615129C5A for ; Thu, 23 Feb 2017 15:49:34 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id v200so3236589ywc.3 for ; Thu, 23 Feb 2017 15:49:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2zzPUiol9MnXgsg7JGMAMja5AP69SFztvZrbJujp+2I=; b=KFiP9FS1mt2SL5azzy7Sm2Bje6Zktyb7ve+ZzT26cLUj2IPLBogbyhQ5hd4emElFDD omaINNJc9RR1ru4mxDoyVLEd948GQnOWw3lbXqpL1ILk2CJYLYnstptbpgo56il1R5ql qckdWeKygz7VIpRGHko04IpeEAvyWPkzAhiGQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2zzPUiol9MnXgsg7JGMAMja5AP69SFztvZrbJujp+2I=; b=TTO6s9LLVs90Ih0K9RgertzmG3LBjfxpRM4/l0pmfrJ87ViF4cChwXPKvNiGLFOON6 9xfTl8Brdj6whHgDmc06hgV7z9wpoHz1sEvQsX9HdyUoX+5oicz4fihXRwTy8MeN37ry IxeqQ54dmk7EGu6VyhjwDNFqKQH2dylcX/VCaDBlO0Wwx0ELh7a2gywH4vSnhIrwNLBE KWIv/Ts8swdyCwbCScRDfq7q4JmMxKboXZ4xc8/darqo98CbpRszefVT0GZ3SKAWvjk+ k+bI3ChBGU/psBYBLY8tMrqzX/5PzzPLBk8DXi27WfknZQ8waeUCOI6ztvY4PHgPV8Qu w7TA== X-Gm-Message-State: AMke39nsCW595QKZIuH58a1MP9uyz9VEOAe9T+X9s+sQRjU0qjvZ/BeAnTwh5tsAkn82TUb2Gx5efhpMtqemtx+c X-Received: by 10.129.115.68 with SMTP id o65mr16629613ywc.55.1487893773912; Thu, 23 Feb 2017 15:49:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.126.131 with HTTP; Thu, 23 Feb 2017 15:49:03 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Thu, 23 Feb 2017 16:49:03 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a1149359cdbc5a905493b43d1 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] ramifications of longer EKMs 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: Thu, 23 Feb 2017 23:49:36 -0000 --001a1149359cdbc5a905493b43d1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > Then what we have in option 4) is an IDP that supports a subset, rather > than superset, of its RP=E2=80=99s TB key parameters. Which is a known ty= pe of > misconfiguration that can happen between the IDP and RPs. > I wouldn't characterize it as misconfiguration but rather just different domains supporting different sets of TB key params. And could happen even if the sets were the same but prioritized differently. > In any case, the TB key parameters negotiation would not be very robust i= f > we say that a given signature scheme really requires a 64-byte EKM, but m= ay > also be used with a 32-byte EKM if the binding is Referred=E2=80=A6 The negotiation is only for the TB key parameters for the provided binding. I'm just suggesting that the EKM length choice for the whole TB message could be tied to that. It seemed like an okay simplification at what felt like a low cost of signing over less data in the case of the referred TB otherwise using a longer EKM. You don't seem to see it as okay though and there's yet to be any other opinions expressed on it. So I can let that idea go. On Thu, Feb 23, 2017 at 1:13 PM, Andrei Popov wrote: > =C3=98 Are you suggesting that tokbind-tls-term should have more than on= e > model? > > Alternatively, we may end up with more than one tokbind-tls-termJ. > > > > =C3=98 Or that the =E2=80=9Cdumb/slim=E2=80=9D TTRP model is most likely= to be the desired > model? > > It seems undesirable to prevent =E2=80=9Cdumb/slim=E2=80=9D TTRPs, regard= less of what tokbind-tls-term > ends up saying. > > > > =C3=98 Yes, that's an accurate description of what I'd proposed as optio= n 4) > > Then what we have in option 4) is an IDP that supports a subset, rather > than superset, of its RP=E2=80=99s TB key parameters. Which is a known ty= pe of > misconfiguration that can happen between the IDP and RPs. > > In any case, the TB key parameters negotiation would not be very robust i= f > we say that a given signature scheme really requires a 64-byte EKM, but m= ay > also be used with a 32-byte EKM if the binding is Referred=E2=80=A6 > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Thursday, February 23, 2017 5:18 AM > *To:* Andrei Popov > *Cc:* IETF Tokbind WG > *Subject:* Re: [Unbearable] ramifications of longer EKMs > > > > Sure, this design would work. My point is that the tokbind-tls-term > document cannot require one particular model of TB processing, because if > this one model does not meet a data center=E2=80=99s requirements/archite= cture, the > document is easily ignored. And it would be particularly undesirable to > lose the =E2=80=9Cdumb/slim=E2=80=9D TTRP model. > > > > Are you suggesting that tokbind-tls-term should have more than one model? > Or that the =E2=80=9Cdumb/slim=E2=80=9D TTRP model is most likely to be t= he desired model? > > Backend could pass the TB key parameters to the TTRP, or these could be > part of the TTRP configuration. All the =E2=80=9Cdumb/slim=E2=80=9D TTRP = needs to know is > TB protocol version and a prioritized list of TB key parameter IDs. > > Sure, that prioritized list of TB key parameter IDs is still the TTRP > 'supporting' them in that it will use them in negotiation. > > The TB key parameter IDs the TTRP is willing/able to use will need to be > the intersection of the supported TB key parameters of each of the > backends. This might be cumbersome in some cases but is just the way it h= as > to be for the =E2=80=9Cdumb/slim=E2=80=9D TTRP model. > > > > Let=E2=80=99s say a client negotiates signature scheme A with the RP, and > signature scheme A calls for a 64-byte EKM. Then the client negotiates a > signature scheme B with the IDP, and signature scheme B calls for a 32- > byte EKM. The client sends Provided and Referred bindings to this IDP, > and the Referred binding uses signature scheme A in combination with an E= KM > length 32 (which does not agree with the signature scheme definition). Is > this what you=E2=80=99re proposing as option 4), or did I get it wrong? > > Yes, that's an accurate description of what I'd proposed as option 4) > > > > > > On Wed, Feb 22, 2017 at 6:03 PM, Andrei Popov > wrote: > > Correction inlineJ. > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *An= drei > Popov > *Sent:* Wednesday, February 22, 2017 4:39 PM > *To:* Brian Campbell > *Cc:* IETF Tokbind WG > *Subject:* Re: [Unbearable] ramifications of longer EKMs > > > > =C3=98 I'm not sure I follow this? > > =C3=98 I'd think, if this kind of model was used, a TTRP could do all th= e TB > validation work and just expose the TB ID(s) to the backend where they ca= n > bind to whatever tokens/cookies they are issuing. > > Sure, this design would work. My point is that the tokbind-tls-term > document cannot require one particular model of TB processing, because if > this one model does not meet a data center=E2=80=99s requirements/archite= cture, the > document is easily ignored. And it would be particularly undesirable to > lose the =E2=80=9Cdumb/slim=E2=80=9D TTRP model. > > =C3=98 The backend apps would only be able to use TB key parameters that= the > TTRP supports but that's pretty much true of the other model too - the TT= RP > still is the one negotiating. > > Backend could pass the TB key parameters to the TTRP, or these could be > part of the TTRP configuration. All the =E2=80=9Cdumb/slim=E2=80=9D TTRP = needs to know is > TB protocol version and a prioritized list of TB key parameter IDs. > > =C3=98 It only defeats the purpose of having per-signature-scheme EKM le= ngths > in the case of a refereed TB using a longer EKM than the provided. > > Let=E2=80=99s say a client negotiates signature scheme A with the RP, and > signature scheme A calls for a 64-byte EKM. Then the client negotiates a > signature scheme B with the IDP, and signature scheme B calls for a 32- > byte EKM. The client sends Provided and Referred bindings to this IDP, > and the Referred binding uses signature scheme A in combination with an E= KM > length 32 (which does not agree with the signature scheme definition). Is > this what you=E2=80=99re proposing as option 4), or did I get it wrong? > > > --001a1149359cdbc5a905493b43d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Then what we have in option 4) is an IDP that supports a subset, rather than superset, of its RP=E2=80=99s TB key parameters. Which is a known type of= =20 misconfiguration that can happen between the IDP and RPs.


I woul= dn't characterize it as misconfiguration but rather just different doma= ins supporting different sets of TB key params. And could happen even if th= e sets were the same but prioritized differently.=C2=A0
=C2= =A0
I= n any case, the TB key parameters negotiation would not be very robust if we say that a given signature scheme really requires a 64-byte EKM, but may also be used with a 32-byte EKM if the binding is Referred=E2=80=A6

The negotiation is only for the TB key parameters for the provided bi= nding. I'm just suggesting that the EKM length choice for the whole TB = message could be tied to that.=C2=A0 It seemed like an okay simplification = at what felt like a low cost of signing over less data in the case of the r= eferred TB otherwise using a longer EKM.=C2=A0 You don't seem to see it= as okay though and there's yet to be any other opinions expressed on i= t. So I can let that idea go.


=
On Thu, Feb 23, 2017 at 1:13 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

=C3= =98=C2=A0 Are you suggesting that tokbind-tls-term should= have more than one model? <= u>

Alternatively, we may end up with more than one tokbind-tls-termJ.

=C2=A0

=C3= =98=C2=A0 Or that the =E2=80=9Cdumb/slim=E2=80=9D TTRP mo= del is most likely to be the desired model?

It seems undesirable to prevent =E2=80=9Cdumb/slim=E2= =80=9D TTRPs, regardless of what tokbind-tls-term ends up saying.

=C2=A0

=C3=98=C2=A0 Yes, that's an accurate description of what = I'd proposed as option 4)

Then what we have in option 4) is an IDP that support= s a subset, rather than superset, of its RP=E2=80=99s TB key parameters. Wh= ich is a known type of misconfiguration that can happen between the IDP and RPs.

In any case, the TB key parameters negotiation would = not be very robust if we say that a given signature scheme really requires = a 64-byte EKM, but may also be used with a 32-byte EKM if the binding is Referred=E2=80=A6

=C2=A0

From: Brian Campbell [mailto:bcampbell@pingidentity= .com]
Sent: Thursday, February 23, 2017 5:18 AM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: IETF Tokbind= WG <unbearable= @ietf.org>
Subject: Re: [Unbearable] ramifications of longer EKMs=

=C2=A0

Sure, this design would work. My point is that the t= okbind-tls-term document cannot require one particular model of TB processi= ng, because if this one model does not meet a data center=E2=80=99s require= ments/architecture, the document is easily ignored. And it would be particularly undesirable to lose the =E2=80=9Cdum= b/slim=E2=80=9D TTRP model.

=C2=A0

Are you suggesting that tokbind-tls-term should have= more than one model? Or that the =E2=80=9Cdumb/slim=E2=80=9D TTRP model is= most likely to be the desired model?=C2=A0

Backend could pass the T= B key parameters to the TTRP, or these could be part of the TTRP configurat= ion. All the =E2=80=9Cdumb/slim=E2=80=9D TTRP needs to know is TB protocol version and a prioritized list of TB key= parameter IDs.

Sure, that prioritized = list of TB key parameter IDs is still the TTRP 'supporting' them in= that it will use them in negotiation.

The TB key parameter IDs the TTRP is willing/able to= use will need to be the intersection of the supported TB key parameters of= each of the backends. This might be cumbersome in some cases but is just t= he way it has to be for the =E2=80=9Cdumb/slim=E2=80=9D TTRP model.

=C2=A0

Let=E2=80=99s say a clie= nt negotiates signature scheme A with the RP, and signature scheme A calls = for a 64-byte EKM. Then the client negotiates a signature scheme B with the IDP, and sig= nature scheme B calls for a 32-byte EKM. The client sends Provided and Referred bind= ings to this IDP, and the Referred binding uses signature scheme A in combination with an EKM length 32 (which does not agree with the sign= ature scheme definition). Is this what you=E2=80=99re proposing as option 4= ), or did I get it wrong?

Yes, that's an accurate description of what I'= ;d proposed as option 4)

=C2=A0

=C2=A0

On Wed, Feb 22, 2017 at 6:03 PM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

Correction= inlineJ<= /span>.

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Andrei Popov
Sent: Wednesday, February 22, 2017 4:39 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: IETF Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] ramifications of longer EKMs=

=C2=A0

=C3=98= =C2=A0 I'm not sure I follow this?

=C3=98= =C2=A0 I'd think, if this kind of model was used, a TTRP could do all t= he TB validation work and just expose the TB ID(s) to the backend where the= y can bind to whatever tokens/cookies they are issuing.

Sure, this design would = work. My point is that the tokbind-tls-term document cannot require one par= ticular model of TB processing, because if this one model does not meet a data center=E2=80=99= s requirements/architecture, the document is easily ignored. And it would b= e particularly undesirable to lose the =E2=80=9Cdumb/slim=E2=80=9D TTRP mod= el.

=C3=98= =C2=A0 The backend apps would only be able to use TB key parameters that th= e TTRP supports but that's pretty much true of the other model too - th= e TTRP still is the one negotiating.

Backend could pass the T= B key parameters to the TTRP, or these could be part of the TTRP configurat= ion. All the =E2=80=9Cdumb/slim=E2=80=9D TTRP needs to know is TB protocol version and a prioritized list of TB key= parameter IDs.

=C3=98=C2=A0 It only defeats the purpose of having per-signature-scheme EKM lengt= hs in the case of a refereed TB using a longer EKM than the provided.

Let=E2=80=99s say a clie= nt negotiates signature scheme A with the RP, and signature scheme A calls = for a 64-byte EKM. Then the client negotiates a signature scheme B with the IDP, and sig= nature scheme B calls for a 32-byte EKM. The client sends Provided and Referred bind= ings to this IDP, and the Referred binding uses signature scheme A in combination with an EKM length 32 (which does not agree with the sign= ature scheme definition). Is this what you=E2=80=99re proposing as option 4= ), or did I get it wrong?

=C2=A0


--001a1149359cdbc5a905493b43d1-- From nobody Thu Feb 23 15:59:59 2017 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 143DC129C6F for ; Thu, 23 Feb 2017 15:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 L47QnRZ5z6fb for ; Thu, 23 Feb 2017 15:59:57 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002: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 B2C27129BB4 for ; Thu, 23 Feb 2017 15:59:57 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id v200so3319872ywc.3 for ; Thu, 23 Feb 2017 15:59:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G8w4afRv+JJAnDGqzX+8CBJOr4WuUuVOfpBal7L5FZ8=; b=g/8d0CLi0bTJ1WQP/wpbusbsxwlstVKjuAFxmpqbc/GE8A5UqqEWFn6hV2+4NgXO4M EEfx8fZ2RRieBAPJD3CG7vTA/giYAGjNZ58TkJuUPbrYCWqcGMTbDIzKBjEyqRxA4faD YXUMY+imW97dxST6pUmeLYoKSx7yu7pi+5XDg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G8w4afRv+JJAnDGqzX+8CBJOr4WuUuVOfpBal7L5FZ8=; b=FVO3ogG92doKcLzAm+/GmRaqgfIoP3zNnggWimR2+NU2jkSwM8hRuj6xl8+5+M4gga igV1v84ZSi/mFeWEPHIK4TouFjeGs2gQYwSpHmVRsA2mARgbfxXIrXJtqtwgGy04SovF IxTBI0itY0wYLUfnxWnWWG6p/ZCDbh8bJ8shJBJgO7O7HdjVDtS0G6BkxTzgnO9Jdia8 N5Mp3pciDPjY8bzu10VJpJ4CKbZTdSFtpl/H/TivLylZvKI45BVsrbyYF6GNSNvjogvj 5kjjbXuxJObdjwcCQxNOQl5cl1CaWwK1nZHPTsxh2r5GRZ8Z/xXzVabOVXdlL2zjT/ST 4org== X-Gm-Message-State: AMke39nF0pz96JrFvQcXXwSpKkSL9SFw0Q3Ru1/jr225pEqpPXTOVv1Ue7wiHaqV7AOCm58YrVc2vJtn9PwCSwXa X-Received: by 10.13.214.129 with SMTP id y123mr11326540ywd.25.1487894396885; Thu, 23 Feb 2017 15:59:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.126.131 with HTTP; Thu, 23 Feb 2017 15:59:26 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Thu, 23 Feb 2017 16:59:26 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=94eb2c076d5afd759e05493b688d Archived-At: Cc: Anthony Nadalin , IETF Tokbind WG Subject: Re: [Unbearable] ramifications of longer EKMs 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: Thu, 23 Feb 2017 23:59:59 -0000 --94eb2c076d5afd759e05493b688d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Andrei. I admit to having had some fondness for option 4). But I guess, at this point, I'd lean towards 3) as well. It simplifies the TTRP case as well as server processing logic (assuming the logic would be generalized to accommodate future TB key params with a longer EKM). On Thu, Feb 23, 2017 at 2:00 PM, Andrei Popov wrote: > Tokbind-tls-term does not necessarily have to be on the standards track, > but I think the issue Brian has raised deserves discussion regardless of > the destiny of tokbind-tls-term. > > > > WRT Brian=E2=80=99s listed options, I prefer 3) or, failing that, 1). > > Option 2) affects the tokbind-tls-term document, not the core I-Ds; from > the core I-D perspective it is identical to option 1). > > Option 4) makes the TB key parameter negotiation less definitive. It says > that the length of the EKM now depends not only on the signature scheme o= f > the TB key that signs this EKM, but also on the type of the Binding, and = on > the signature scheme of a different, unrelated TB key. > > > > Cheers, > > > > Andrei > > > > *From:* Anthony Nadalin > *Sent:* Thursday, February 23, 2017 9:54 AM > *To:* Brian Campbell ; Andrei Popov < > Andrei.Popov@microsoft.com> > *Cc:* IETF Tokbind WG > *Subject:* RE: [Unbearable] ramifications of longer EKMs > > > > I=E2=80=99m not sure the value of standardizing the tokbind-tls-term, not= sure how > much interoperability requirements there are here, maybe this should be a= n > experimental until we figure out if there is a need and if so what are th= e > requirements > > > > > --94eb2c076d5afd759e05493b688d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Andrei.

I admit to having ha= d some fondness for option 4). But I guess, at this point, I'd lean tow= ards 3) as well. It simplifies the TTRP case as well as server processing l= ogic (assuming the logic would be generalized to accommodate future TB key = params with a longer EKM).

<= br>
On Thu, Feb 23, 2017 at 2:00 PM, Andrei Popov= <Andrei.Popov@microsoft.com> wrote:

Tokbind-tls-term does not necessarily have to be on = the standards track, but I think the issue Brian has raised deserves discus= sion regardless of the destiny of tokbind-tls-term.

=C2=A0

WRT Brian=E2=80=99s listed options, I prefer 3) or, = failing that, 1).

Option 2) affects the tokbind-tls-term document, not= the core I-Ds; from the core I-D perspective it is identical to option 1).=

Option 4) makes the TB key parameter negotiation les= s definitive. It says that the length of the EKM now depends not only on th= e signature scheme of the TB key that signs this EKM, but also on the type = of the Binding, and on the signature scheme of a different, unrelated TB key.

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Anthony Nadalin
Sent: Thursday, February 23, 2017 9:54 AM
To: Brian Campbell <bcampbell@pingidentity.com>; Andrei Popov <Andrei.Popov@m= icrosoft.com>
Cc: IETF Tokbind WG <unbearable@ietf.org>
Subject: RE: [Unbearable] ramifications of longer EKMs=

=C2=A0

I=E2=80=99m not sure the value of standardizing the = tokbind-tls-term, not sure how much interoperability requirements there are= here, maybe this should be an experimental until we figure out if there is= a need and if so what are the requirements

<= u>=C2=A0

=C2=A0


--94eb2c076d5afd759e05493b688d-- From nobody Thu Feb 23 16:07:32 2017 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 50D12129A8F for ; Thu, 23 Feb 2017 16:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 0LER6i18R5Z3 for ; Thu, 23 Feb 2017 16:07:29 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0106.outbound.protection.outlook.com [104.47.36.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682FE1293D9 for ; Thu, 23 Feb 2017 16:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PUZNuTl/AG2p8uNE7HQPj+RSDGloOsEkAQyJFuA/L5U=; b=J5e6kgzfEMlUu+Yrdja3UgOSyYcDCeuUP5wHr/UBg+DgL6/zGfENJoK5Vs3DiNhdqOW4jfttjxeqkS8YUBwecVCdyFryfjTsxro6KDp4i9iK4sIGyoXzscZHnwaGVr/SDzU7y5HjeSFYOTAvKya+zIgi8cClFH76oeErTBe1u0o= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0841.namprd03.prod.outlook.com (10.160.163.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Fri, 24 Feb 2017 00:07:28 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0919.018; Fri, 24 Feb 2017 00:07:28 +0000 From: Andrei Popov To: Brian Campbell Thread-Topic: [Unbearable] ramifications of longer EKMs Thread-Index: AQHSjVYgmQf/q9+NMUG8uI+0qEZ9BqF1ncIggAAZn4CAAACqsIAADg1QgADNxwCAAG9TYIAAQPSAgAAAk1A= Date: Fri, 24 Feb 2017 00:07: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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: 8b310779-f7d1-4f02-4d4d-08d45c491e8b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0841; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0841; 7:DzMR0cT9PW2vev0b6bu7iWETuShgoEya3We5ST9HXjDOlm4rrVhJ0aR02q6kR8ZiLO4cspMBUxgJjlsTl/pCjY0eHBcaJck+h6tbwTWIqoE4D6kB4cnmVZ52XjGUZh+7+EMMbhZXhmZRfpPDqmeKUf/GQ2rgxE4s5gFY6HOFVPBipcxXhziS3YvRJAHpWO1HbsyQuLHV23VTSBJwyEZdMbYyBVVftUZLUnoMMylckIBDNYcCuoiJWWISg8VPwdHdXl00MFRxbmcfB6GGMI1Nta827D/hlJsk/ZQ342RHRqf2fB2W2gU9o0i/MWWIvuvLMxvqMccCBt31kqcCha5ZpchGtmAM+0Dlu5UAeA7P97k= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:CY1PR0301MB0841; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0841; x-forefront-prvs: 0228DDDDD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39840400002)(39450400003)(39410400002)(39850400002)(189002)(199003)(110136004)(6246003)(189998001)(81156014)(8676002)(101416001)(8936002)(74316002)(105586002)(106356001)(81166006)(106116001)(93886004)(6436002)(38730400002)(8990500004)(7736002)(7696004)(33656002)(97736004)(2950100002)(6916009)(6116002)(10290500002)(10090500001)(5005710100001)(2900100001)(229853002)(5660300001)(77096006)(3660700001)(790700001)(122556002)(4326007)(50986999)(54356999)(92566002)(86362001)(3280700002)(102836003)(25786008)(2906002)(86612001)(9686003)(99286003)(55016002)(76176999)(6306002)(6506006)(54896002)(53936002)(68736007)(148743002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0841; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842FF5308B0E0049C4F2A7E8C520CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2017 00:07:27.8083 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0841 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] ramifications of longer EKMs 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: Fri, 24 Feb 2017 00:07:31 -0000 --_000_CY1PR0301MB0842FF5308B0E0049C4F2A7E8C520CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEkgd291bGRuJ3QgY2hhcmFjdGVyaXplIGl0IGFzIG1pc2NvbmZpZ3VyYXRpb24gYnV0IHJh dGhlciBqdXN0IGRpZmZlcmVudCBkb21haW5zIHN1cHBvcnRpbmcgZGlmZmVyZW50IHNldHMgb2Yg VEIga2V5IHBhcmFtcy4NCkFuIFJQIG5lZ290aWF0aW5nIFRCIGtleSBwYXJhbWV0ZXJzIHRoYXQg dGhlIGNvcnJlc3BvbmRpbmcgSURQIGRvZXMgbm90IHN1cHBvcnQgbWFrZXMgaXQgaW1wb3NzaWJs ZSBmb3IgdGhlIElEUCB0byBiaW5kIHRoZSB0b2tlbiwgdGhlcmVmb3JlIEkgdGhpbmsgb2YgaXQg YXMgYSBtaXNjb25maWd1cmF0aW9uLiBVbmZvcnR1bmF0ZWx5LCBSUHMgYXJlIGxpbWl0ZWQgaW4g dGhlaXIgVEIgb3B0aW9ucyBieSB0aGVpciBJRFDigJlzIGNhcGFiaWxpdGllc+KApg0KDQoNCsOY ICBBbmQgY291bGQgaGFwcGVuIGV2ZW4gaWYgdGhlIHNldHMgd2VyZSB0aGUgc2FtZSBidXQgcHJp b3JpdGl6ZWQgZGlmZmVyZW50bHkuDQpJZiB0aGUgVEIga2V5IHBhcmFtZXRlciBzZXRzIGFyZSB0 aGUgc2FtZSwgYnV0IHByaW9yaXRpemVkIGRpZmZlcmVudGx5LCB0aGVuIHRoZXJlIGlzIG5vIHBy b2JsZW06IHRoZSBJRFAgY2FuIGhhbmRsZSB0aGUgRUtNIGxlbmd0aCByZXF1aXJlZCBieSB0aGUg c2lnbmF0dXJlIHNjaGVtZSB1c2VkIGluIHRoZSBSZWZlcnJlZCBiaW5kaW5nLCBjb3JyZWN0PyBJ IHRoaW5rIHRoZSBpc3N1ZSBvbmx5IGV4aXN0cyB3aGVuIHRoZSBJRFAgZG9lcyBub3Qgc3VwcG9y dCB0aGUgc2lnbmF0dXJlIHNjaGVtZSB0aGF0IGFuIFJQIG5lZ290aWF0ZXMuDQoNCg0Kw5ggIEJ1 dCBJIGd1ZXNzLCBhdCB0aGlzIHBvaW50LCBJJ2QgbGVhbiB0b3dhcmRzIDMpIGFzIHdlbGwuIEl0 IHNpbXBsaWZpZXMgdGhlIFRUUlAgY2FzZSBhcyB3ZWxsIGFzIHNlcnZlciBwcm9jZXNzaW5nIGxv Z2ljIChhc3N1bWluZyB0aGUgbG9naWMgd291bGQgYmUgZ2VuZXJhbGl6ZWQgdG8gYWNjb21tb2Rh dGUgZnV0dXJlIFRCIGtleSBwYXJhbXMgd2l0aCBhIGxvbmdlciBFS00pLg0KR3JlYXQuIExldOKA mXMgc2VlIGlmIHNvbWVvbmUgZWxzZSBjYXJlcyBvbmUgd2F5IG9yIGFub3RoZXIuIFRoaXMgd291 bGQgYmUgYSB0cml2aWFsIGNoYW5nZSB0byBtYWtlLCBmb2xsb3dpbmcgV0dMQ+KApg0K --_000_CY1PR0301MB0842FF5308B0E0049C4F2A7E8C520CY1PR0301MB0842_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubS0xNTA0MjY3OTk1ODAxNTgyNzAwZ21haWwtbS0yNjg0 NDg1MTQxMjY3MjA2MzY5bXNvbGlzdHBhcmFncmFwaCwgbGkubS0xNTA0MjY3OTk1ODAxNTgyNzAw Z21haWwtbS0yNjg0NDg1MTQxMjY3MjA2MzY5bXNvbGlzdHBhcmFncmFwaCwgZGl2Lm0tMTUwNDI2 Nzk5NTgwMTU4MjcwMGdtYWlsLW0tMjY4NDQ4NTE0MTI2NzIwNjM2OW1zb2xpc3RwYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLW5hbWU6bV8tMTUwNDI2Nzk5NTgwMTU4MjcwMGdtYWlsLW1fLTI2ODQ0ODUx NDEyNjcyMDYzNjltc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0Kc3Bhbi5tLTE1MDQyNjc5OTU4MDE1ODI3MDBnbWFpbC0NCgl7bXNvLXN0 eWxlLW5hbWU6bV8tMTUwNDI2Nzk5NTgwMTU4MjcwMGdtYWlsLTt9DQpwLm0tMTUwNDI2Nzk5NTgw MTU4MjcwMGdtYWlsLW0tMjY4NDQ4NTE0MTI2NzIwNjM2OW05NDM5NTU1OTQ5MDI0MTI3OG1zb2xp c3RwYXJhZ3JhcGgsIGxpLm0tMTUwNDI2Nzk5NTgwMTU4MjcwMGdtYWlsLW0tMjY4NDQ4NTE0MTI2 NzIwNjM2OW05NDM5NTU1OTQ5MDI0MTI3OG1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tLTE1MDQyNjc5 OTU4MDE1ODI3MDBnbWFpbC1tLTI2ODQ0ODUxNDEyNjcyMDYzNjltOTQzOTU1NTk0OTAyNDEyNzht c29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOm1fLTE1MDQyNjc5OTU4MDE1ODI3MDBn bWFpbC1tXy0yNjg0NDg1MTQxMjY3MjA2MzY5bTk0Mzk1NTU5NDkwMjQxMjc4bXNvbGlzdHBhcmFn cmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1p ZDo4MTk4ODE0NTg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOi0xMDMyMjYwMDIwIC0yMTA1NzI5MjYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2 ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkkgd291bGRuJ3Qg Y2hhcmFjdGVyaXplIGl0IGFzIG1pc2NvbmZpZ3VyYXRpb24gYnV0IHJhdGhlciBqdXN0IGRpZmZl cmVudCBkb21haW5zIHN1cHBvcnRpbmcgZGlmZmVyZW50IHNldHMgb2YgVEIga2V5IHBhcmFtcy4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbiBSUCBuZWdvdGlhdGluZyBUQiBrZXkgcGFyYW1ldGVy cyB0aGF0IHRoZSBjb3JyZXNwb25kaW5nIElEUCBkb2VzIG5vdCBzdXBwb3J0IG1ha2VzIGl0IGlt cG9zc2libGUgZm9yIHRoZSBJRFAgdG8gYmluZCB0aGUgdG9rZW4sIHRoZXJlZm9yZSBJIHRoaW5r IG9mIGl0IGFzIGEgbWlzY29uZmlndXJhdGlvbi4NCiBVbmZvcnR1bmF0ZWx5LCBSUHMgYXJlIGxp bWl0ZWQgaW4gdGhlaXIgVEIgb3B0aW9ucyBieSB0aGVpciBJRFDigJlzIGNhcGFiaWxpdGllc+KA pjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3Mi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT5BbmQgY291bGQgaGFwcGVuIGV2ZW4gaWYgdGhlIHNldHMgd2VyZSB0aGUgc2Ft ZSBidXQgcHJpb3JpdGl6ZWQgZGlmZmVyZW50bHkuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SWYgdGhlIFRCIGtleSBwYXJhbWV0 ZXIgc2V0cyBhcmUgdGhlIHNhbWUsIGJ1dCBwcmlvcml0aXplZCBkaWZmZXJlbnRseSwgdGhlbiB0 aGVyZSBpcyBubyBwcm9ibGVtOiB0aGUgSURQIGNhbiBoYW5kbGUgdGhlIEVLTSBsZW5ndGggcmVx dWlyZWQgYnkgdGhlIHNpZ25hdHVyZSBzY2hlbWUgdXNlZCBpbg0KIHRoZSBSZWZlcnJlZCBiaW5k aW5nLCBjb3JyZWN0PyBJIHRoaW5rIHRoZSBpc3N1ZSBvbmx5IGV4aXN0cyB3aGVuIHRoZSBJRFAg ZG9lcyBub3Qgc3VwcG9ydCB0aGUgc2lnbmF0dXJlIHNjaGVtZSB0aGF0IGFuIFJQIG5lZ290aWF0 ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QnV0IEkgZ3Vlc3MsIGF0IHRoaXMgcG9pbnQs IEknZCBsZWFuIHRvd2FyZHMgMykgYXMgd2VsbC4gSXQgc2ltcGxpZmllcyB0aGUgVFRSUCBjYXNl IGFzIHdlbGwgYXMgc2VydmVyIHByb2Nlc3NpbmcgbG9naWMgKGFzc3VtaW5nIHRoZSBsb2dpYyB3 b3VsZCBiZSBnZW5lcmFsaXplZCB0byBhY2NvbW1vZGF0ZSBmdXR1cmUgVEIga2V5IHBhcmFtcyB3 aXRoIGEgbG9uZ2VyIEVLTSkuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkdyZWF0LiBMZXTigJlzIHNl ZSBpZiBzb21lb25lIGVsc2UgY2FyZXMgb25lIHdheSBvciBhbm90aGVyLiBUaGlzIHdvdWxkIGJl IGEgdHJpdmlhbCBjaGFuZ2UgdG8gbWFrZSwgZm9sbG93aW5nIFdHTEPigKY8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR0301MB0842FF5308B0E0049C4F2A7E8C520CY1PR0301MB0842_-- From nobody Thu Feb 23 17:00:27 2017 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 3E2FF1293F4 for ; Thu, 23 Feb 2017 17:00:26 -0800 (PST) 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, HTML_MESSAGE=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=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 n_HVyKRIp9-O for ; Thu, 23 Feb 2017 17:00:24 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d: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 DE752127076 for ; Thu, 23 Feb 2017 17:00:23 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id u188so7354741qkc.2 for ; Thu, 23 Feb 2017 17:00:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6JdGmunRGc1HYz81cAC8rJNIz92FtulFe1ZjQOAQohg=; b=wD3KuL9sb9mG0o3sdnIX9AP/eldM+J+e6BNvUksCYByNkIsbVvidAFvgaL+p+jaj6G cH79tSwJJJAzUWqEA9t/p7g2hxQIHbsuqMoiuXOobvPTC8oDCypx2IgJ9H6oStMUsqsE OFMJyjU5zw5Mj/NQrnLX1Lfpit2WxEWxdolXm3RUwIc4Hk4lCDSO1PvpE5+0mR5j2xoG PlfXfTa59u92yHKSJhexcxb8qDB4lLauwBRtDTLPJPW4bpiaN+H1Su7TNyXaYYo8D2kV aw4voiXbLVb0Uj6FglUN5+vH/+2kAasV7j+Z+sc3bjmI78RrVCr8/1rgrC5eUnY5hBQ3 JMdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6JdGmunRGc1HYz81cAC8rJNIz92FtulFe1ZjQOAQohg=; b=f5TEej4PxgVywJVafmjd46xz56gL/P5oxyyu4qhry78mevloAmRQBBzZtwq/cXDf4t DflQHV/kgeRNUq68i7UlLvTSlMFM1s/4aH/ioqJhwvKwKy+NAza8HaC16Z3iyrfQ4mQY h1wT/mGi8I/34AFrPVMFzkz83daRTNEkkWNXnv7gRNeT8S790g+WfRAZoFdZayRiEeid 20mXg65Q/FBYU+PiN+f8qypauLiYWQvlMAQlwdlTESdw/Ja4860o9fYLjkBBRmhujvcx KmXkVGTg0ir5UOsUrqD0SLAs6/VdRe6t02MMQMxg60J4jdW1K5/Bb02yy5yGVdvLF+e7 QYqg== X-Gm-Message-State: AMke39lle0dSzmEt0JSghK6qc6pJ5nKHJriHI0AsRIavaPHTaIlp/wqWoGnaxzUu4X1zu6xU X-Received: by 10.55.177.133 with SMTP id a127mr37947493qkf.301.1487898022839; Thu, 23 Feb 2017 17:00:22 -0800 (PST) Received: from [192.168.8.100] ([181.201.193.82]) by smtp.gmail.com with ESMTPSA id g15sm2416640qte.58.2017.02.23.17.00.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Feb 2017 17:00:22 -0800 (PST) From: John Bradley Message-Id: <4E2A8068-E76C-4A06-9FCB-3F18775C7E96@ve7jtb.com> Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 23 Feb 2017 22:00:18 -0300 In-Reply-To: To: Andrei Popov References: X-Mailer: Apple Mail (2.3259) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c064c7c20051105493c41f9" Archived-At: Cc: IETF Tokbind WG , Brian Campbell Subject: Re: [Unbearable] ramifications of longer EKMs 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: Fri, 24 Feb 2017 01:00:26 -0000 --94eb2c064c7c20051105493c41f9 Content-Type: multipart/alternative; boundary="Apple-Mail=_9B938DD2-C0F4-4C89-946D-6284E2AD795C" --Apple-Mail=_9B938DD2-C0F4-4C89-946D-6284E2AD795C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think in the federated case having the IDP support the same or a = superset of the RP algorithms is not unreasonable. =20 It might be worth reminding people in a implementation note to have = logging for unsupported alg ekm size errors so that when a RP updates = before the server it is easier to figure out what happened. RP implementations should also allow disabling algs to allow for IDP = servers to be updated first. The idea of always using the EKM size negotiated for the provided Token = binding seems like people are more likely to get that wrong in the = clients by having multiple possible EKM size per alg. It might be simpler for the server, but if it supports the alg it will = support the EKM size, so I don=E2=80=99t think it is a big advantage for = the server.=20 It may have advantages for the reverse proxy processing. John B. > On Feb 23, 2017, at 9:07 PM, Andrei Popov = wrote: >=20 > =C3=98 I wouldn't characterize it as misconfiguration but rather just = different domains supporting different sets of TB key params. > An RP negotiating TB key parameters that the corresponding IDP does = not support makes it impossible for the IDP to bind the token, therefore = I think of it as a misconfiguration. Unfortunately, RPs are limited in = their TB options by their IDP=E2=80=99s capabilities=E2=80=A6 > =20 > =C3=98 And could happen even if the sets were the same but = prioritized differently.=20 > If the TB key parameter sets are the same, but prioritized = differently, then there is no problem: the IDP can handle the EKM length = required by the signature scheme used in the Referred binding, correct? = I think the issue only exists when the IDP does not support the = signature scheme that an RP negotiates. > =20 > =C3=98 But I guess, at this point, I'd lean towards 3) as well. It = simplifies the TTRP case as well as server processing logic (assuming = the logic would be generalized to accommodate future TB key params with = a longer EKM). > Great. Let=E2=80=99s see if someone else cares one way or another. = This would be a trivial change to make, following WGLC=E2=80=A6 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable = --Apple-Mail=_9B938DD2-C0F4-4C89-946D-6284E2AD795C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I think in the federated case having the IDP support the same = or a superset of the RP algorithms is not unreasonable.  
It might be worth reminding people in a implementation note = to have logging for unsupported alg ekm size errors so that when a RP = updates before the server it is easier to figure out what = happened.
RP implementations should also allow = disabling algs to allow for IDP servers to be updated first.

The idea of always using = the EKM size negotiated for the provided Token binding seems like people = are more likely to get that wrong in the clients by having multiple = possible EKM size per alg.

It might be simpler for the server, but  if it supports = the alg it will support the EKM size, so I don=E2=80=99t think it is a = big advantage for the server. 

It may have advantages for the reverse = proxy processing.

John B.
On Feb 23, 2017, at 9:07 PM, Andrei Popov = <Andrei.Popov@microsoft.com> wrote:

=C3=98  I = wouldn't characterize it as misconfiguration but rather just different = domains supporting different sets of TB key params.
An RP negotiating TB key parameters that the = corresponding IDP does not support makes it impossible for the IDP to = bind the token, therefore I think of it as a misconfiguration. = Unfortunately, RPs are limited in their TB options by their IDP=E2=80=99s = capabilities=E2=80=A6
 
=C3=98  And = could happen even if the sets were the same but prioritized = differently. 
If the TB key parameter sets are the same, but = prioritized differently, then there is no problem: the IDP can handle = the EKM length required by the signature scheme used in the Referred = binding, correct? I think the issue only exists when the IDP does not = support the signature scheme that an RP negotiates.
 
=C3=98  But I = guess, at this point, I'd lean towards 3) as well. It simplifies the = TTRP case as well as server processing logic (assuming the logic would = be generalized to accommodate future TB key params with a longer = EKM).
Great. Let=E2=80=99s see if someone else cares = one way or another. This would be a trivial change to make, following = WGLC=E2=80=A6
_______________________________________________
Unbearable mailing = list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable

= --Apple-Mail=_9B938DD2-C0F4-4C89-946D-6284E2AD795C-- --94eb2c064c7c20051105493c41f9 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIEORl46XYx+whTilirDnkxW9kFXa n77Oe53BtNe5SqemMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDIyNDAxMDAyM1owaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQComc5xdv8GJ47YtRjX0aBTH0mefkKEhSsmtC1vo0Jip7fH h2XQwwy3/fY4HNowdKsS6ZI8xTBu4mJ2Yeyh8CN4HVpyxKPpmYDhU1NR9T14BKnmoA3aaEEu0RCN f5fN17qmh9Y7egcB3fpPd+p+C5UFVWE/CgFhPr5G6trH/JDpDVYk26CdMZAeadTlgi5XqAkhLNyc ejAIYUm6bSPR4n3j3M/3nxrKlgoasR3l6Qp7f3RJ0UVX/koYLuG6bH/HfAQ/Mebn92qj/o3GLhz1 e4Y7piVCdyTAMK/hxGwb9I+uR7bQbwwyUMRptlJg0ujEXYsCNRcrmvGHzTeCdGr1fXeg --94eb2c064c7c20051105493c41f9-- From nobody Fri Feb 24 07:21:44 2017 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 177921298BB for ; Fri, 24 Feb 2017 07:21:43 -0800 (PST) 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, HTML_MESSAGE=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 (1024-bit key) header.d=pingidentity.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 ZQ3CssReGl8Z for ; Fri, 24 Feb 2017 07:21:36 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002: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 D7AD7129862 for ; Fri, 24 Feb 2017 07:21:35 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id q127so11134943ywg.0 for ; Fri, 24 Feb 2017 07:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c4tPV/jHbstElKVsJE0jmVbWQUKGRVd/Hkz8suRaAhk=; b=i3gfxtwAz6boHKpYD+SUqYI33pua9mp5ryjBo2AbUGPlWo5uEmG98coUGHTWIcCbl/ TPvw+f3KeJCY4/P96rnPxCI5NHdWBYCig1d6s/B018kYqTNbjak2aAHKCyRzLWr0JWNv wa32E6F8Lyub06xYVjEyrD/sRmWmZI0UDogWM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c4tPV/jHbstElKVsJE0jmVbWQUKGRVd/Hkz8suRaAhk=; b=Lzkwv7uXvFBGnbx9nG9cMlfGy4FTKO4dgSti9KTEKrJJWBJJ/8cJV5nB7J+lcgNiu0 4pQ0g3emQJzt0keinmmxS0cQ1kOelJ9HIZ7/XD6rq4iSH7rJV6S60lZVKjaxwJ/ndn+u EDejObgsbgNrUN5gnS+BiTebHA4wHi7/WgFz6dS8cjL321gz5q33Qa5qhrBc6Xwt0bUi FivwZDDV/YpewkRQNUb17NMQLj4IAvKGD+QYvBJV+ir+pCVgK6+Rsxs84aVNrp1eUC+8 eVYGSFmnHYKdR/yWvlRObQ4MwAreF8EynHM3aHZOK/AmHkfz1itT6/y4Qxh4+4PYIC9j nMjA== X-Gm-Message-State: AMke39nSzp6LKzOEe4vEAOzjlG3/Dix0L4faNyStR4Q5OPSg0p5DwZ4n+Lod1MA4qMcKzzGeiPlNoGEBDmbeuygD X-Received: by 10.129.49.73 with SMTP id x70mr1861482ywx.171.1487949695005; Fri, 24 Feb 2017 07:21:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.126.131 with HTTP; Fri, 24 Feb 2017 07:21:04 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Fri, 24 Feb 2017 08:21:04 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a1140704003f22e0549484966 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] ramifications of longer EKMs 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: Fri, 24 Feb 2017 15:21:43 -0000 --001a1140704003f22e0549484966 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > If the TB key parameter sets are the same, but prioritized differently, > then there is no problem: the IDP can handle the EKM length required by t= he > signature scheme used in the Referred binding, correct? I think the issue > only exists when the IDP does not support the signature scheme that an RP > negotiates. Yes, in that case the IDP can handle the EKM length required by the signature scheme used in the referred TB. When an IDP doesn't support a signature scheme that an RP negotiates, the IDP won't be able to validate the Referred TB. That's the case regardless of EKM length. Sorry, maybe I've been unclear about my concern or have gotten sidetracked in the discussion. My concern is about the consequences of a single TB message needing two different EKM values in order to be validated. It's certainly possible for a server to do it but it's a bit more cumbersome and may necessitate exporting key materail twice in processing a single request. And it's really awkward and likely less efficient for the TTRP case because the header message being passed to the backend needs to allow for multiple EKM values and either have all possible EKM lengths based on supported key params (as you'd suggested) or the TTRP evaluating the TB message to determine the EKM lengths needed for the given request. On Thu, Feb 23, 2017 at 5:07 PM, Andrei Popov wrote: > =C3=98 I wouldn't characterize it as misconfiguration but rather just > different domains supporting different sets of TB key params. > > An RP negotiating TB key parameters that the corresponding IDP does not > support makes it impossible for the IDP to bind the token, therefore I > think of it as a misconfiguration. Unfortunately, RPs are limited in thei= r > TB options by their IDP=E2=80=99s capabilities=E2=80=A6 > > > > =C3=98 And could happen even if the sets were the same but prioritized > differently. > > If the TB key parameter sets are the same, but prioritized differently, > then there is no problem: the IDP can handle the EKM length required by t= he > signature scheme used in the Referred binding, correct? I think the issue > only exists when the IDP does not support the signature scheme that an RP > negotiates. > > > > =C3=98 But I guess, at this point, I'd lean towards 3) as well. It simpl= ifies > the TTRP case as well as server processing logic (assuming the logic woul= d > be generalized to accommodate future TB key params with a longer EKM). > > Great. Let=E2=80=99s see if someone else cares one way or another. This w= ould be a > trivial change to make, following WGLC=E2=80=A6 > --001a1140704003f22e0549484966 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If the TB key parameter sets are the same, but prioritized differently,=20 then there is no problem: the IDP can handle the EKM length required by=20 the signature scheme used in the Referred binding, correct? I think the issue only exists when the=20 IDP does not support the signature scheme that an RP negotiates.

Yes, in that case the IDP can handle the EKM l= ength required by the signature scheme used in the referred TB. When an IDP= doesn't support a signature scheme that an RP negotiates, the IDP won&= #39;t be able to validate the Referred TB. That's the case regardless o= f EKM length. Sorry, maybe I've been unclear about my concern or have g= otten sidetracked in the discussion.=C2=A0 My concern is about the conseque= nces of a single TB message needing two different EKM values in order to be= validated. It's certainly possible for a server to do it but it's = a bit more cumbersome and may necessitate exporting key materail twice in p= rocessing a single request. And it's really awkward and likely less eff= icient for the TTRP case because the header message being passed to the bac= kend needs to allow for multiple EKM values and either have all possible EK= M lengths based on supported key params (as you'd suggested) or the TTR= P evaluating the TB message to determine the EKM lengths needed for the giv= en request.=C2=A0 =C2=A0
=C2=A0
=C2=A0

On Thu, Feb 23, 2017 at 5:07 P= M, Andrei Popov <Andrei.Popov@microsoft.com> wrote:=

=C3=98=C2=A0 I wouldn't characterize it as misconfigurat= ion but rather just different domains supporting different sets of TB key p= arams. <= u>

An RP negotiating TB key parameters that the correspo= nding IDP does not support makes it impossible for the IDP to bind the toke= n, therefore I think of it as a misconfiguration. Unfortunately, RPs are limited in their TB options by their IDP=E2=80=99s = capabilities=E2=80=A6

=C2=A0

=C3=98=C2=A0 And could happen even if the sets were the same= but prioritized differently.=C2=A0

If the TB key parameter sets are the same, but priori= tized differently, then there is no problem: the IDP can handle the EKM len= gth required by the signature scheme used in the Referred binding, correct? I think the issue only exists when the IDP = does not support the signature scheme that an RP negotiates.<= /span>

=C2=A0

=C3=98=C2=A0 But I guess, at this point, I'd lean toward= s 3) as well. It simplifies the TTRP case as well as server processing logi= c (assuming the logic would be generalized to accommodate future TB key par= ams with a longer EKM).

Great. Let=E2=80=99s see if someone else cares one wa= y or another. This would be a trivial change to make, following WGLC=E2=80= =A6


--001a1140704003f22e0549484966-- From nobody Fri Feb 24 08:30:56 2017 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 6E609120726 for ; Fri, 24 Feb 2017 08:30:55 -0800 (PST) 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, HTML_MESSAGE=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=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 T0d7lACyjex9 for ; Fri, 24 Feb 2017 08:30:53 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 D9DF512009C for ; Fri, 24 Feb 2017 08:30:52 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id x35so20768625qtc.2 for ; Fri, 24 Feb 2017 08:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8cdKkT5lVLCLDkiqUXCZlhrYm8YDChOAGBjwvARXvSU=; b=Nlwf5v9MWS0QFK/SjMcfT5/agMyMN4xlqedolS9CWZuX65TzAJr+sSa8pnP95mBH2W uVG6OjgBmKGVNSQXBklNiHNxwcX1YWqTedlMo9WvNOqyc6ZhA7X+Ua3AZzWLb9LVQWTA U9kf7n6HHCQaiH6riVd09hy1iH08pLzxyqqXZH8JUEYH7ZJZkm+dKwTxg+WnJzcWnzD+ T47Alpl2f98BLldHoZS9Jd0gYeVrhIeWBRCkw5xpdaD0pByhUqWpJgSeinwX9+4FQ/oG 9Xsaw9qP43pCvivIAzWRrC0MX7ez9wC9oQaRH4vaKWvKLfYv7yHCu+VbKw9OcOGo5fF5 Du2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8cdKkT5lVLCLDkiqUXCZlhrYm8YDChOAGBjwvARXvSU=; b=dTkhRKZTNN8w+EE2VL+3lt/ONz9yW+sCn9Jo9uNm4Fg3lPBHMqDmU4Gj515QIyXrZJ c6NCfDyLwLiOcOD6k7L0ydgb8JUuOGmRq8dIhtR94TlFthE6C8DmQh/+QRAbxL2KGUkz 6FLt/XdL30lp1/W1WSmuhIP8WSZi3o3RUgjDxR7PAzladWDrLKhC/+0IZ/uscTn7Nyls LxarkJ3wzjVso0o8nsSvSVHfbCrYmSoVUsINso9bFfe5E/8fDV5Eyvxk4jP/1Q/DNuBg f5/PMQAf0rTqFRvW/o7o/CA/bNWr7En6wlWb0BzFanLsbRC0JboZ1aRwcKC53eLEbWHA q+aQ== X-Gm-Message-State: AMke39laO/cFRhUztQNx2DpCTfLXoUID2iq0hMDPi2ylKtt7QIPgQwROzfUpUYqRFdnduuY2 X-Received: by 10.200.36.178 with SMTP id s47mr3752918qts.98.1487953851767; Fri, 24 Feb 2017 08:30:51 -0800 (PST) Received: from [192.168.86.130] ([191.115.25.29]) by smtp.gmail.com with ESMTPSA id t2sm5110034qkh.0.2017.02.24.08.30.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 08:30:50 -0800 (PST) From: John Bradley Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 24 Feb 2017 13:30:47 -0300 In-Reply-To: To: Brian Campbell References: X-Mailer: Apple Mail (2.3259) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113f448acaee72054949408a" Archived-At: Cc: Andrei Popov , IETF Tokbind WG Subject: Re: [Unbearable] ramifications of longer EKMs 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: Fri, 24 Feb 2017 16:30:55 -0000 --001a113f448acaee72054949408a Content-Type: multipart/alternative; boundary="Apple-Mail=_73A65A5A-E5A5-405A-991D-191C421222A7" --Apple-Mail=_73A65A5A-E5A5-405A-991D-191C421222A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The communication between the TTRP and the backend is generally inside a = datacenter. I don't think bandwidth is a big issue if you export all = the EKM that the TTRP supports. =20 It is a bit more work for the TTRP but it avoids processing the actual = TB header. =20 Is your concern that for servers it would be better / more efficient to = only use a single EKM size? =20 I don=E2=80=99t know if that is true if there is more than one EKM size = in play then the lower level of the stack with the EKM exporter will = need to know what size to produce based on the negotiated alg anyway. I suspect that the lower level TLS exporter will just produce multiple = EKM one for each supported alg and pass those on to whatever is doing = the token binding. If we went nuts and decided to introduce RFC7748 based Curve 448 signing = (you know someone will ask). Given that has a bit strength of ~224 bits = vs P256 and RSA 2048 that are ~112 bits someone will wat to double the = size of the nonce (I personally suspect that 256 bits as we have it = would be just fine for Curve 448) so we double the EKM to 64 bytes. How = would people implement that. We would defiantly stick with 32 bytes for Curve 25519. I don=E2=80=99t = think anyone in there right mind is going to propose RSA 4096. So I personally find the need to have a EKM larger than the current 256 = bits a touch hypothetical. If someone could point me to a good reason = I would like to know. But for the sake of alg agility how would people deal with it? John B. > On Feb 24, 2017, at 12:21 PM, Brian Campbell = wrote: >=20 > If the TB key parameter sets are the same, but prioritized = differently, then there is no problem: the IDP can handle the EKM length = required by the signature scheme used in the Referred binding, correct? = I think the issue only exists when the IDP does not support the = signature scheme that an RP negotiates. >=20 > Yes, in that case the IDP can handle the EKM length required by the = signature scheme used in the referred TB. When an IDP doesn't support a = signature scheme that an RP negotiates, the IDP won't be able to = validate the Referred TB. That's the case regardless of EKM length. = Sorry, maybe I've been unclear about my concern or have gotten = sidetracked in the discussion. My concern is about the consequences of = a single TB message needing two different EKM values in order to be = validated. It's certainly possible for a server to do it but it's a bit = more cumbersome and may necessitate exporting key materail twice in = processing a single request. And it's really awkward and likely less = efficient for the TTRP case because the header message being passed to = the backend needs to allow for multiple EKM values and either have all = possible EKM lengths based on supported key params (as you'd suggested) = or the TTRP evaluating the TB message to determine the EKM lengths = needed for the given request. =20 > =20 > =20 >=20 > On Thu, Feb 23, 2017 at 5:07 PM, Andrei Popov = > wrote: > =C3=98 I wouldn't characterize it as misconfiguration but rather just = different domains supporting different sets of TB key params. >=20 > An RP negotiating TB key parameters that the corresponding IDP does = not support makes it impossible for the IDP to bind the token, therefore = I think of it as a misconfiguration. Unfortunately, RPs are limited in = their TB options by their IDP=E2=80=99s capabilities=E2=80=A6 >=20 > =20 >=20 > =C3=98 And could happen even if the sets were the same but = prioritized differently.=20 >=20 > If the TB key parameter sets are the same, but prioritized = differently, then there is no problem: the IDP can handle the EKM length = required by the signature scheme used in the Referred binding, correct? = I think the issue only exists when the IDP does not support the = signature scheme that an RP negotiates. >=20 > =20 >=20 > =C3=98 But I guess, at this point, I'd lean towards 3) as well. It = simplifies the TTRP case as well as server processing logic (assuming = the logic would be generalized to accommodate future TB key params with = a longer EKM). >=20 > Great. Let=E2=80=99s see if someone else cares one way or another. = This would be a trivial change to make, following WGLC=E2=80=A6 >=20 >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_73A65A5A-E5A5-405A-991D-191C421222A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The communication between the TTRP and the backend is = generally inside a datacenter.  I don't think bandwidth is a big = issue if you export all the EKM that the TTRP supports.  
It is a bit more work for the TTRP but it avoids processing = the actual TB header.  

Is your concern that for servers it = would be better / more efficient to only use a single EKM size? =  
I don=E2=80=99t know if that is true if = there is more than one EKM size in play then the lower level of the = stack with the EKM exporter will need to know what size to produce based = on the negotiated alg anyway.

I suspect that the lower level TLS = exporter will just produce multiple EKM one for each supported alg and = pass those on to whatever is doing the token binding.

If we went nuts and = decided to introduce RFC7748 based Curve 448 signing (you know someone = will ask).  Given that has a bit strength of ~224 bits vs P256 and = RSA 2048 that are ~112 bits someone will wat to double the size of the = nonce (I personally suspect that 256 bits as we have it would be just = fine for Curve 448) so we double the EKM to 64 bytes.  How would = people implement that.

We would defiantly stick with 32 bytes for Curve 25519. =  I don=E2=80=99t think anyone in there right mind is going to = propose RSA 4096.

So I personally find the need to have a EKM larger than the = current 256 bits a touch hypothetical.   If someone could point me = to a good reason I would like to know.

But for the sake of alg agility how = would people deal with it?

John B.


On Feb 24, 2017, at 12:21 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

If the TB key parameter sets are the same, but prioritized differently,=20 then there is no problem: the IDP can handle the EKM length required by=20= the signature scheme used in the Referred binding, correct? I think the issue only exists when the=20= IDP does not support the signature scheme that an RP = negotiates.

Yes, in that case the IDP can handle the EKM length required = by the signature scheme used in the referred TB. When an IDP doesn't = support a signature scheme that an RP negotiates, the IDP won't be able = to validate the Referred TB. That's the case regardless of EKM length. = Sorry, maybe I've been unclear about my concern or have gotten = sidetracked in the discussion.  My concern is about the = consequences of a single TB message needing two different EKM values in = order to be validated. It's certainly possible for a server to do it but = it's a bit more cumbersome and may necessitate exporting key materail = twice in processing a single request. And it's really awkward and likely = less efficient for the TTRP case because the header message being passed = to the backend needs to allow for multiple EKM values and either have = all possible EKM lengths based on supported key params (as you'd = suggested) or the TTRP evaluating the TB message to determine the EKM = lengths needed for the given request.   
 
 

On Thu, = Feb 23, 2017 at 5:07 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

=C3=98  I wouldn't characterize it as = misconfiguration but rather just different domains supporting different = sets of TB key params.

An RP negotiating TB key parameters that the corresponding = IDP does not support makes it impossible for the IDP to bind the token, = therefore I think of it as a misconfiguration. Unfortunately, RPs are limited in their TB options by their IDP=E2=80=99s= capabilities=E2=80=A6

 

=C3=98  And could happen even if the sets = were the same but prioritized differently. 

If the TB key parameter sets are the same, but prioritized = differently, then there is no problem: the IDP can handle the EKM length = required by the signature scheme used in the Referred binding, correct? I think the issue only exists when the = IDP does not support the signature scheme that an RP negotiates.

 

=C3=98  But I guess, at this point, I'd = lean towards 3) as well. It simplifies the TTRP case as well as server = processing logic (assuming the logic would be generalized to accommodate = future TB key params with a longer EKM).

Great. Let=E2=80=99s see if someone else cares one way or = another. This would be a trivial change to make, following WGLC=E2=80=A6


_______________________________________________
Unbearable = mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable

= --Apple-Mail=_73A65A5A-E5A5-405A-991D-191C421222A7-- --001a113f448acaee72054949408a Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIBjhIbW8mpgFOnKNgyp0x429Vfpj 1qhCqUkfvJvxstZwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDIyNDE2MzA1MlowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQAyJD63VPLmlcIIyNtiKFBEJWURkGqTkCfA9XlGCLAOC/PZ RiInYHUZNTytz4i8RrIPzFLdERNTXs9mDjp3szn5l13iN+mlkA6hpTvRTuYl9e18SiPhv9jq833a 9SKrRBgS5lzWHXv1ZMBTygXYFN3+GTrXq+QhVt31r196SThQk88ClLaRPoAzOlr91zG6V43/wLQI ZxY3pQjhTq2vP+WOra2sk27HX6TW3YpDyH2vawGF2lOOtjnS5UYN5QIt4xPZvG3tUec50pOhpMyq 9n4klZyqBUYbKsCzOXyfCFJaZKz/OMliTSJhnYhfjlKnJVp2emm5DuZEUF+cscKZin+k --001a113f448acaee72054949408a-- From nobody Fri Feb 24 08:33:51 2017 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 6B990126BF6 for ; Fri, 24 Feb 2017 08:33:50 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 4ednIsKMUqWp for ; Fri, 24 Feb 2017 08:33:48 -0800 (PST) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002: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 1F18A126B6D for ; Fri, 24 Feb 2017 08:33:48 -0800 (PST) Received: by mail-yb0-x22a.google.com with SMTP id d88so6535493ybi.0 for ; Fri, 24 Feb 2017 08:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BCsishk7k+UGqshnfFnk232K5VGzwtS40yJZhdyHF84=; b=KcaoRu+x/wWUlALg8JtX4aXuAFijQY+V1VuDp5aPWH7GrQ6Tk2x+/WV5UyXmd9IBRe nhL+KhVY2T9cLucRhkrme5Io0v666RAK8Hffxk6+dLmf0UJ0lNi96QC7IxQht1J0zqib TBsvI2z+9knuGgPDFvcHKs8bNWB96Rac6gs0A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BCsishk7k+UGqshnfFnk232K5VGzwtS40yJZhdyHF84=; b=FrY5GGjS9c5y9HpEMTwWDDbXztkOPUJ8FVuPVsN5RCLJwoT6hMoCXB2WwUZwtY0aTM idy4eWrzF2DeG3Sy2cLJgrj5n2SJCXENObVbs7J5skgShcewnnCtKjbQTEQPURTsZPks S+A9H9wh/ELJTKxhqgEUqkbtizfRMjIfeNMIkIPBL/U2S36k7PaPelqGmnrUxeH8H5d8 Pv3L6bCqMr0j0eExOjethl7bYut+ryuSzNprvZnI7UVygwrc8OQYIX5QFBFOms24VbjO cEO1xIq/ssaxw7E3EbG3eqmD2/ZY0VUzXMTI7tRfl1iYwXCHWkmzWxkZApYEPAvC9UzI lRLg== X-Gm-Message-State: AMke39mJTObhVXl489LPS3ry6dzr+Bjpg9ajat/hJbrOgBykSbRgF+7vYanBj4nNIe352ufbZLgAZ7jZBl0banc6 X-Received: by 10.37.78.3 with SMTP id c3mr2153429ybb.180.1487954027209; Fri, 24 Feb 2017 08:33:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.126.131 with HTTP; Fri, 24 Feb 2017 08:33:16 -0800 (PST) In-Reply-To: <4E2A8068-E76C-4A06-9FCB-3F18775C7E96@ve7jtb.com> References: <4E2A8068-E76C-4A06-9FCB-3F18775C7E96@ve7jtb.com> From: Brian Campbell Date: Fri, 24 Feb 2017 09:33:16 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a113e7fae3c412f0549494b7d Archived-At: Cc: Andrei Popov , IETF Tokbind WG Subject: Re: [Unbearable] ramifications of longer EKMs 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: Fri, 24 Feb 2017 16:33:50 -0000 --001a113e7fae3c412f0549494b7d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > I think in the federated case having the IDP support the same or a > superset of the RP algorithms is not unreasonable. > It might be worth reminding people in a implementation note to have > logging for unsupported alg ekm size errors so that when a RP updates > before the server it is easier to figure out what happened. > RP implementations should also allow disabling algs to allow for IDP > servers to be updated first. > I think that stuff is generally relevant and applicable regardless of EKM size. It's just the nature of the protocol supporting different algorithms. EKM size is just another piece of it. > > The idea of always using the EKM size negotiated for the provided Token > binding seems like people are more likely to get that wrong in the client= s > by having multiple possible EKM size per alg. > Maybe. I suspect most or all implementations are currently using a 32 byte EKM with no regard for the alg. I guess likelihood for getting things wrong depends on perspective. And I was looking at it from the perspective of updating an implementation that only ever used 32 byte EKM to something that's aware of alg dependent lengths. > > It might be simpler for the server, but if it supports the alg it will > support the EKM size, so I don=E2=80=99t think it is a big advantage for = the > server. > Yeah, it'd be a simplification for the server but not a big one. > It may have advantages for the reverse proxy processing. > Yes. On Thu, Feb 23, 2017 at 6:00 PM, John Bradley wrote: > I think in the federated case having the IDP support the same or a > superset of the RP algorithms is not unreasonable. > It might be worth reminding people in a implementation note to have > logging for unsupported alg ekm size errors so that when a RP updates > before the server it is easier to figure out what happened. > RP implementations should also allow disabling algs to allow for IDP > servers to be updated first. > > The idea of always using the EKM size negotiated for the provided Token > binding seems like people are more likely to get that wrong in the client= s > by having multiple possible EKM size per alg. > > It might be simpler for the server, but if it supports the alg it will > support the EKM size, so I don=E2=80=99t think it is a big advantage for = the > server. > > It may have advantages for the reverse proxy processing. > > John B. > > On Feb 23, 2017, at 9:07 PM, Andrei Popov > wrote: > > =C3=98 I wouldn't characterize it as misconfiguration but rather just > different domains supporting different sets of TB key params. > An RP negotiating TB key parameters that the corresponding IDP does not > support makes it impossible for the IDP to bind the token, therefore I > think of it as a misconfiguration. Unfortunately, RPs are limited in thei= r > TB options by their IDP=E2=80=99s capabilities=E2=80=A6 > > =C3=98 And could happen even if the sets were the same but prioritized > differently. > If the TB key parameter sets are the same, but prioritized differently, > then there is no problem: the IDP can handle the EKM length required by t= he > signature scheme used in the Referred binding, correct? I think the issue > only exists when the IDP does not support the signature scheme that an RP > negotiates. > > =C3=98 But I guess, at this point, I'd lean towards 3) as well. It simpl= ifies > the TTRP case as well as server processing logic (assuming the logic woul= d > be generalized to accommodate future TB key params with a longer EKM). > Great. Let=E2=80=99s see if someone else cares one way or another. This w= ould be a > trivial change to make, following WGLC=E2=80=A6 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > > --001a113e7fae3c412f0549494b7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think = in the federated case having the IDP support the same or a superset of the = RP algorithms is not unreasonable. =C2=A0
It might be worth reminding people in a implementation note to have=20 logging for unsupported alg ekm size errors so that when a RP updates=20 before the server it is easier to figure out what happened.
RP im= plementations should also allow disabling algs to allow for IDP servers to = be updated first.

I think that stuff = is generally relevant and applicable regardless of EKM size. It's just = the nature of the protocol supporting different algorithms. EKM size is jus= t another piece of it.
=C2=A0

The idea of always using the EKM size negotiated for the provided Token=20 binding seems like people are more likely to get that wrong in the=20 clients by having multiple possible EKM size per alg.

Maybe. I suspect most or all implementations are curre= ntly using a 32 byte EKM with no regard for the alg. I guess likelihood for= getting things wrong depends on perspective.=C2=A0 And I was looking at it= from the perspective of updating an implementation that only ever used 32 = byte EKM to something that's aware of alg dependent lengths.
=
=C2=A0
=C2= =A0
It might be simpler for the server, but =C2=A0if it supports the alg it will= =20 support the EKM size, so I don=E2=80=99t think it is a big advantage for th= e=20 server.=C2=A0

Yeah, it'= ;d be a simplification for the server but not a big one.
=C2= =A0
It may have= advantages for the reverse proxy processing.
Yes.


<= div class=3D"gmail_quote">On Thu, Feb 23, 2017 at 6:00 PM, John Bradley <v= e7jtb@ve7jtb.com> wrote:
I think in the f= ederated case having the IDP support the same or a superset of the RP algor= ithms is not unreasonable. =C2=A0
It might be worth reminding people in= a implementation note to have logging for unsupported alg ekm size errors = so that when a RP updates before the server it is easier to figure out what= happened.
RP implementations should also allow disabling algs to= allow for IDP servers to be updated first.

The id= ea of always using the EKM size negotiated for the provided Token binding s= eems like people are more likely to get that wrong in the clients by having= multiple possible EKM size per alg.

It might be s= impler for the server, but =C2=A0if it supports the alg it will support the= EKM size, so I don=E2=80=99t think it is a big advantage for the server.= =C2=A0

It may have advantages for the reverse prox= y processing.

John B.
On Feb 23, 2017, at 9:07 PM, Andrei= Popov <= Andrei.Popov@microsoft.com> wrote:

= =C3=98=C2=A0=C2=A0I wouldn't characterize it as misc= onfiguration but rather just different domains supporting different sets of= TB key params.
An RP negotiating TB key parameter= s that the corresponding IDP does not support makes it impossible for the I= DP to bind the token, therefore I think of it as a misconfiguration. Unfort= unately, RPs are limited in their TB options by their IDP=E2=80=99s capabil= ities=E2=80=A6
=C2=A0
=C3=98=C2=A0=C2=A0And could happen even if th= e sets were the same but prioritized differently.=C2=A0
=
If the TB key parameter sets are the same, but prioritized diff= erently, then there is no problem: the IDP can handle the EKM length requir= ed by the signature scheme used in the Referred binding, correct? I think t= he issue only exists when the IDP does not support the signature scheme tha= t an RP negotiates.
=C2=A0<= /u>
=C3=98=C2=A0=C2=A0But I g= uess, at this point, I'd lean towards 3) as well. It simplifies the TTR= P case as well as server processing logic (assuming the logic would be gene= ralized to accommodate future TB key params with a longer EKM).
Great. Let=E2=80=99s see if someone else cares one way or an= other. This would be a trivial change to make, following WGLC=E2=80=A6
________= _______________________________________
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/= unbearable

<= br>
--001a113e7fae3c412f0549494b7d-- From nobody Fri Feb 24 09:08:39 2017 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 2273B129421 for ; Fri, 24 Feb 2017 09:08:38 -0800 (PST) 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, HTML_MESSAGE=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 (1024-bit key) header.d=pingidentity.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 DBzViYPOZ1yL for ; Fri, 24 Feb 2017 09:08:35 -0800 (PST) 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 835C712940B for ; Fri, 24 Feb 2017 09:08:27 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id d1so430273ywd.2 for ; Fri, 24 Feb 2017 09:08:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TjuMw45/FB3whIogO0+TUeO4XLuvEAQHHi7eNzdzAiI=; b=VoTz4SBA86+oY30cDkIC9qazIyar25sXQC0V83BhI6D8CFudSqe+5xCEwLyN7qlvyj Lm2AbHAhibfLIarcZBMoCD9MtW2gLFaQ8cKRecYaO6Tvvhl4GZD+KcPgNNgWvkA6wvaI fm7Z+oYBzOK6y78INrXkDOgGTxwfr3vJ01V/w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TjuMw45/FB3whIogO0+TUeO4XLuvEAQHHi7eNzdzAiI=; b=VYc42dZWfQaLZUV/Mg7WvnhwzeOa67y7Wp2192U/iwN/eZoKJymtFsWRyTbsE6ujxr o5kPAyIk7dHWqsGqj58EWJ8P04VXK4IeB4+teMrSe6vY17UTr8vWR+MaeGxzc9O/yuoC qevtYe9uddD5SjSpvlFQNKVUhvGW78x4VwpbtCK0CN+Ur8xCUfO8AiCDEhiVccsEWbkF epccgvFqdb0o8C6G/jrINM5aQukSfiXcE1KTcRwJCHQMcL2zA2N0953CthOZth/OvjEx RdAc623JcDZEuQD/QaZkD50cZWAHpN/5zmmYuJaeMo5bY40DC0c7+AE0CBVH48NmgyU8 POjQ== X-Gm-Message-State: AMke39nMcG2iXVM6WuhQFg43M3KnNrVcPBmkRuukzAMEEhGErR8U2gQvJ7cadG0zsHk6159DSqvTpFDfAkj7zjQ3 X-Received: by 10.129.160.129 with SMTP id x123mr2478068ywg.199.1487956106640; Fri, 24 Feb 2017 09:08:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.126.131 with HTTP; Fri, 24 Feb 2017 09:07:56 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Fri, 24 Feb 2017 10:07:56 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=94eb2c07de562daf0b054949c7ea Archived-At: Cc: Andrei Popov , IETF Tokbind WG Subject: Re: [Unbearable] ramifications of longer EKMs 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: Fri, 24 Feb 2017 17:08:38 -0000 --94eb2c07de562daf0b054949c7ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > The communication between the TTRP and the backend is generally inside a > datacenter. I don't think bandwidth is a big issue if you export all the > EKM that the TTRP supports. Yeah, bandwidth probably isn't a big issue. So maybe not such a concern. Sending all supported EKM lengths all the time just strikes me as an unwarranted inefficiency. But maybe it's not so bad. And anything other than 32 bytes is only theoretical at this point anyway. > It is a bit more work for the TTRP but it avoids processing the actual TB > header. > That's true and keeping it so a TTRP does not process the actual TB header seems like a good thing to maintain. Is your concern that for servers it would be better / more efficient to > only use a single EKM size? > I don=E2=80=99t know if that is true if there is more than one EKM size i= n play > then the lower level of the stack with the EKM exporter will need to know > what size to produce based on the negotiated alg anyway. > The negotiated alg only tells you about the provided TB. So the server would either have to process the TB message to see if there are other (refereed) bindings and what size EKM they'd need or get all possible EKM sizes up front. > > I suspect that the lower level TLS exporter will just produce multiple EK= M > one for each supported alg and pass those on to whatever is doing the tok= en > binding. > That may well be how things end up. I'd been thinking about it as looking at the negotiated alg and then asking for the appropriate EKM based on that. Which works for the provided but not referred. > > If we went nuts and decided to introduce RFC7748 based Curve 448 signing > (you know someone will ask). Given that has a bit strength of ~224 bits = vs > P256 and RSA 2048 that are ~112 bits someone will wat to double the size = of > the nonce (I personally suspect that 256 bits as we have it would be just > fine for Curve 448) so we double the EKM to 64 bytes. How would people > implement that. > > We would defiantly stick with 32 bytes for Curve 25519. I don=E2=80=99t = think > anyone in there right mind is going to propose RSA 4096. > > So I personally find the need to have a EKM larger than the current 256 > bits a touch hypothetical. If someone could point me to a good reason I > would like to know. > I honestly don't know the relationship between the bit strength of the signature alg and the length of the signing input needed to maintain that strength. Needing to sign over more than 256 bits does seem a a touch hypothetical. But I have nothing to back that up beyond a general guess/feeling. > > But for the sake of alg agility how would people deal with it? > I guess that's kind of the heart of the question. On Fri, Feb 24, 2017 at 9:30 AM, John Bradley wrote: > The communication between the TTRP and the backend is generally inside a > datacenter. I don't think bandwidth is a big issue if you export all the > EKM that the TTRP supports. > It is a bit more work for the TTRP but it avoids processing the actual TB > header. > > Is your concern that for servers it would be better / more efficient to > only use a single EKM size? > I don=E2=80=99t know if that is true if there is more than one EKM size i= n play > then the lower level of the stack with the EKM exporter will need to know > what size to produce based on the negotiated alg anyway. > > I suspect that the lower level TLS exporter will just produce multiple EK= M > one for each supported alg and pass those on to whatever is doing the tok= en > binding. > > If we went nuts and decided to introduce RFC7748 based Curve 448 signing > (you know someone will ask). Given that has a bit strength of ~224 bits = vs > P256 and RSA 2048 that are ~112 bits someone will wat to double the size = of > the nonce (I personally suspect that 256 bits as we have it would be just > fine for Curve 448) so we double the EKM to 64 bytes. How would people > implement that. > > We would defiantly stick with 32 bytes for Curve 25519. I don=E2=80=99t = think > anyone in there right mind is going to propose RSA 4096. > > So I personally find the need to have a EKM larger than the current 256 > bits a touch hypothetical. If someone could point me to a good reason I > would like to know. > > But for the sake of alg agility how would people deal with it? > > John B. > > > On Feb 24, 2017, at 12:21 PM, Brian Campbell > wrote: > > If the TB key parameter sets are the same, but prioritized differently, >> then there is no problem: the IDP can handle the EKM length required by = the >> signature scheme used in the Referred binding, correct? I think the issu= e >> only exists when the IDP does not support the signature scheme that an R= P >> negotiates. > > > Yes, in that case the IDP can handle the EKM length required by the > signature scheme used in the referred TB. When an IDP doesn't support a > signature scheme that an RP negotiates, the IDP won't be able to validate > the Referred TB. That's the case regardless of EKM length. Sorry, maybe > I've been unclear about my concern or have gotten sidetracked in the > discussion. My concern is about the consequences of a single TB message > needing two different EKM values in order to be validated. It's certainly > possible for a server to do it but it's a bit more cumbersome and may > necessitate exporting key materail twice in processing a single request. > And it's really awkward and likely less efficient for the TTRP case becau= se > the header message being passed to the backend needs to allow for multipl= e > EKM values and either have all possible EKM lengths based on supported ke= y > params (as you'd suggested) or the TTRP evaluating the TB message to > determine the EKM lengths needed for the given request. > > > > On Thu, Feb 23, 2017 at 5:07 PM, Andrei Popov > wrote: > >> =C3=98 I wouldn't characterize it as misconfiguration but rather just >> different domains supporting different sets of TB key params. >> >> An RP negotiating TB key parameters that the corresponding IDP does not >> support makes it impossible for the IDP to bind the token, therefore I >> think of it as a misconfiguration. Unfortunately, RPs are limited in the= ir >> TB options by their IDP=E2=80=99s capabilities=E2=80=A6 >> >> >> >> =C3=98 And could happen even if the sets were the same but prioritized >> differently. >> >> If the TB key parameter sets are the same, but prioritized differently, >> then there is no problem: the IDP can handle the EKM length required by = the >> signature scheme used in the Referred binding, correct? I think the issu= e >> only exists when the IDP does not support the signature scheme that an R= P >> negotiates. >> >> >> >> =C3=98 But I guess, at this point, I'd lean towards 3) as well. It >> simplifies the TTRP case as well as server processing logic (assuming th= e >> logic would be generalized to accommodate future TB key params with a >> longer EKM). >> >> Great. Let=E2=80=99s see if someone else cares one way or another. This = would be >> a trivial change to make, following WGLC=E2=80=A6 >> > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > > --94eb2c07de562daf0b054949c7ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The comm= unication between the TTRP and the backend is generally inside a datacenter.=C2=A0 I don't think bandwidth is a big issue if you export= all=20 the EKM that the TTRP supports. =C2=A0

Yeah= , bandwidth probably isn't a big issue. So maybe not such a concern. Se= nding all supported EKM lengths all the time just strikes me as an unwarran= ted inefficiency. But maybe it's not so bad. And anything other than 32= bytes is only theoretical at this point anyway.
=C2=A0
It is a bit more wo= rk for the TTRP but it avoids processing the actual TB header.
=C2=A0
That's true and keeping it so a TTRP = does not process the actual TB header seems like a good thing to maintain. =

=
Is your concern that for servers it would be better / more efficient t= o only use a single EKM size? =C2=A0
I don=E2=80=99t know if that is true if there is more than one EKM size in p= lay=20 then the lower level of the stack with the EKM exporter will need to=20 know what size to produce based on the negotiated alg anyway.

The negotiated alg only tells you about the provid= ed TB. So the server would either have to process the TB message to see if = there are other (refereed) bindings and what size EKM they'd need or ge= t all possible EKM sizes up front.
=C2=A0

I suspect that the lower level TLS exporter will just produce multiple=20 EKM one for each supported alg and pass those on to whatever is doing=20 the token binding.

That may well be h= ow things end up. I'd been thinking about it as looking at the negotiat= ed alg and then asking for the appropriate EKM based on that. Which works f= or the provided but not referred.
=C2=A0

If we went nuts and= decided=20 to introduce RFC7748 based Curve 448 signing (you know someone will=20 ask).=C2=A0 Given that has a bit strength of ~224 bits vs P256 and RSA 2048= =20 that are ~112 bits someone will wat to double the size of the nonce (I=20 personally suspect that 256 bits as we have it would be just fine for=20 Curve 448) so we double the EKM to 64 bytes.=C2=A0 How would people impleme= nt that.

We would defiantly stick with 32 bytes for = Curve 25519.=C2=A0 I don=E2=80=99t think anyone in there right mind is goin= g to propose RSA 4096.

So I personally find the need to have a EKM larger than the current 256=20 bits a touch hypothetical. =C2=A0 If someone could point me to a good reaso= n I would like to know.

I honestly don&#= 39;t know the relationship between the bit strength of the signature alg an= d the length of the signing input needed to maintain that strength. Needing= to sign over more than 256=20 bits does seem a a touch hypothetical. But I have nothing to back that up b= eyond a general guess/feeling.
=C2=A0

But for the sake of al= g agility how would people deal with it?

<= div>I guess that's kind of the heart of the question.

On F= ri, Feb 24, 2017 at 9:30 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
The communication between the TTRP and the backend is generally inside = a datacenter.=C2=A0 I don't think bandwidth is a big issue if you expor= t all the EKM that the TTRP supports. =C2=A0
It is a bit more work for = the TTRP but it avoids processing the actual TB header. =C2=A0
Is your concern that for servers it would be better / more eff= icient to only use a single EKM size? =C2=A0
I don=E2=80=99t know= if that is true if there is more than one EKM size in play then the lower = level of the stack with the EKM exporter will need to know what size to pro= duce based on the negotiated alg anyway.

I suspect= that the lower level TLS exporter will just produce multiple EKM one for e= ach supported alg and pass those on to whatever is doing the token binding.=

If we went nuts and decided to introduce RFC7748 = based Curve 448 signing (you know someone will ask).=C2=A0 Given that has a= bit strength of ~224 bits vs P256 and RSA 2048 that are ~112 bits someone = will wat to double the size of the nonce (I personally suspect that 256 bit= s as we have it would be just fine for Curve 448) so we double the EKM to 6= 4 bytes.=C2=A0 How would people implement that.

We= would defiantly stick with 32 bytes for Curve 25519.=C2=A0 I don=E2=80=99t= think anyone in there right mind is going to propose RSA 4096.
<= br>
So I personally find the need to have a EKM larger than the c= urrent 256 bits a touch hypothetical. =C2=A0 If someone could point me to a= good reason I would like to know.

But for the sak= e of alg agility how would people deal with it?

Jo= hn B.


On Feb 24, 2017, at 12:21 PM, Brian Campbell <bcampbell@pingiden= tity.com> wrote:

If the TB key parameter sets are the same, but prioritized differently,=20 then there is no problem: the IDP can handle the EKM length required by=20 the signature scheme used in the Referred binding, correct? I think the issue only exists when the=20 IDP does not support the signature scheme that an RP negotiates.

Yes, in that case the IDP can handle the EKM l= ength required by the signature scheme used in the referred TB. When an IDP= doesn't support a signature scheme that an RP negotiates, the IDP won&= #39;t be able to validate the Referred TB. That's the case regardless o= f EKM length. Sorry, maybe I've been unclear about my concern or have g= otten sidetracked in the discussion.=C2=A0 My concern is about the conseque= nces of a single TB message needing two different EKM values in order to be= validated. It's certainly possible for a server to do it but it's = a bit more cumbersome and may necessitate exporting key materail twice in p= rocessing a single request. And it's really awkward and likely less eff= icient for the TTRP case because the header message being passed to the bac= kend needs to allow for multiple EKM values and either have all possible EK= M lengths based on supported key params (as you'd suggested) or the TTR= P evaluating the TB message to determine the EKM lengths needed for the giv= en request.=C2=A0 =C2=A0
=C2=A0
=C2=A0

On Thu, Feb 23, 2017 at 5:07 P= M, Andrei Popov <Andrei.Popov@microsoft.com> wrote:=

= =C3=98=C2=A0 I wouldn't characterize it as misconfigurat= ion but rather just different domains supporting different sets of TB key p= arams. <= u>

An RP negotiating TB key para= meters that the corresponding IDP does not support makes it impossible for = the IDP to bind the token, therefore I think of it as a misconfiguration. Unfortunately, RPs are limited in their TB options by their IDP=E2=80=99s = capabilities=E2=80=A6

= =C2=A0

=C3=98=C2=A0 And could happen even if the sets were the same= but prioritized differently.=C2=A0

If the TB key parameter sets are th= e same, but prioritized differently, then there is no problem: the IDP can = handle the EKM length required by the signature scheme used in the Referred binding, correct? I think the issue only exists when the IDP = does not support the signature scheme that an RP negotiates.<= /span>

=C2=A0

=C3=98= =C2=A0 But I guess, at this point, I'd lean toward= s 3) as well. It simplifies the TTRP case as well as server processing logi= c (assuming the logic would be generalized to accommodate future TB key par= ams with a longer EKM).

Great.= Let=E2=80=99s see if someone else cares one way or another. This would be = a trivial change to make, following WGLC=E2=80=A6


_______________________________________________
Unbearable mailing = list
Unbearable= @ietf.org
https://www.ietf.org/mailman/listinfo/unbearable<= /a>

<= br> --94eb2c07de562daf0b054949c7ea-- From nobody Fri Feb 24 09:44:25 2017 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 14A5612944A for ; Fri, 24 Feb 2017 09:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Ya04GpgIybcc for ; Fri, 24 Feb 2017 09:44:22 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0130.outbound.protection.outlook.com [104.47.38.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C433129444 for ; Fri, 24 Feb 2017 09:44:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RkwTaB3Wa51HjmmaPTanqhSQsoVurcdU7VdN/JD68Qk=; b=LrOpqSgMjWarhiWw/SZPhPIX9tbjZZkb5bNO2dWriMPGBPn5u3n4TXrh9rbztpBbofqUpHzjPG/HRIrNi5npx/Q15VOWHDWlicRNccQmnNJRKm+lWpAzVIfw9wvpHimIRveAb/wBGj4ImdcGYr4N0rRKxyOgNqGfu40FayfAKKg= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Fri, 24 Feb 2017 17:44:15 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0919.018; Fri, 24 Feb 2017 17:44:15 +0000 From: Andrei Popov To: Brian Campbell , John Bradley Thread-Topic: [Unbearable] ramifications of longer EKMs Thread-Index: AQHSjVYgmQf/q9+NMUG8uI+0qEZ9BqF1ncIggAAZn4CAAACqsIAADg1QgADNxwCAAG9TYIAAQPSAgAAAk1CAAQPUAIAAE3uAgAAKYQCAAAXfQA== Date: Fri, 24 Feb 2017 17:44:15 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:7::1d2] x-ms-office365-filtering-correlation-id: e96627df-c7e5-42bd-e231-08d45cdcc057 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0842; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 7:zLBHik/NirqQmCxsrCD8dqZBImPHSn7TT47g28fLdssEiNy3MTyVIlfGfJ9eDVH2w3kpgTMF1/6nlEb56oQ+6+iC41wmaAwCuFgfY/ErxWYYOHTOdBwrQtrH840YoRFOZCWISyCzjOoiT3nBw/bTS6XKg61BoEc743vjOampPe9GvW3DZXB+GieiIgu58lIHmbBBKyhOeEX6uyqNyRcj8RCtlU5SBft1UQ5vuCIdM8pW2HBZGJuEp+jPnnIoYJRnBq3DfpnWpfspT6tbF8nql3b32Ng9iHatknepSvGa4DcEu9TLO+DPyRMdy9I3tkkL3KGtyWrjrGvlbiyULmGkp2jAD52VcZQcU+I807hmT0A= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 0228DDDDD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39860400002)(39840400002)(39410400002)(39450400003)(199003)(189002)(7696004)(68736007)(25786008)(2900100001)(10090500001)(55016002)(790700001)(3280700002)(4326007)(102836003)(9686003)(101416001)(93886004)(54896002)(7736002)(3660700001)(86362001)(6306002)(99286003)(76176999)(74316002)(50986999)(54356999)(92566002)(38730400002)(229853002)(6246003)(81166006)(81156014)(6436002)(10290500002)(97736004)(77096006)(53936002)(86612001)(8936002)(122556002)(8990500004)(2950100002)(5660300001)(106356001)(6116002)(5005710100001)(8676002)(106116001)(105586002)(33656002)(6506006)(2906002)(189998001)(148743002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB084254284354740947C8DDBB8C520CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2017 17:44:15.3596 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] ramifications of longer EKMs 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: Fri, 24 Feb 2017 17:44:24 -0000 --_000_CY1PR0301MB084254284354740947C8DDBB8C520CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEJ1dCBmb3IgdGhlIHNha2Ugb2YgYWxnIGFnaWxpdHkgaG93IHdvdWxkIHBlb3BsZSBkZWFs IHdpdGggaXQ/DQoNCkJyaWFu4oCZcyBvcHRpb24gMyk6IFdlIGdvIGJhY2sgdG8gc2F5aW5nIHRo YXQgdGhlIFRCIHByb3RvY29sIHZlcnNpb24gZGVmaW5lcyB0aGUgRUtNIHNpemUuIE9uY2UgYSBu ZXcgc2lnbmF0dXJlIHNjaGVtZSBpcyBwcm9wb3NlZCB0aGF0IHJlcXVpcmVzIGEgbG9uZ2VyIEVL TSwgd2XigJlsbCBuZWVkIHRvIGRlZmluZSBUQiB2IDEuMSB3aXRoLCBlLmcuLCBhIDY0LWJ5dGUg RUtNLg0KDQpCcmlhbuKAmXMgb3B0aW9uIDEpOiBXZSBzdGljayB3aXRoIHRoZSBzaWduYXR1cmUg c2NoZW1lIGRlZmluaW5nIEVLTSBzaXplLiBPbmNlIGEgbmV3IHNpZ25hdHVyZSBzY2hlbWUgaXMg cHJvcG9zZWQgdGhhdCByZXF1aXJlcyBhIGxvbmdlciBFS00sIHRoZXJlIGlzIG5vIG5lZWQgdG8g ZGVmaW5lIGEgbmV3IFRCIHByb3RvY29sIHZlcnNpb24uIEhvd2V2ZXIsIG9wZXJhdG9ycyB3aWxs aW5nIHRvIGRlcGxveSB0aGlzIG5ldyBzaWduYXR1cmUgc2NoZW1lIHdpbGwgbmVlZCB0byBlbnN1 cmUgdGhhdCB0aGVpciBpbmZyYXN0cnVjdHVyZSBzdXBwb3J0cyB0aGUgbmV3IHNpZ25hdHVyZSBz Y2hlbWUgYW5kIEVLTSBzaXplLiBXaGljaCBtYXkgaW5jbHVkZSB1cGRhdGluZyBUVFJQcywgYmFj ay1lbmQgc2VydmVycywgZXRjLiBhcyBpZiBhIG5ldyBUQiBwcm90b2NvbCB2ZXJzaW9uIHdhcyBk ZXBsb3llZC4NCg0KU28sIEnigJltIHRoaW5raW5nIHRoZXJlIGlzbuKAmXQgbXVjaCBleHRyYSBh Z2lsaXR5LCBwcmFjdGljYWxseSBzcGVha2luZywgdGhhdCB3ZSBidXkgd2l0aCBvcHRpb24gMSku DQoNCkNoZWVycywNCg0KQW5kcmVpDQo= --_000_CY1PR0301MB084254284354740947C8DDBB8C520CY1PR0301MB0842_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubTY0NTE3NDM1Mjg2OTQzODg3NDhnbWFpbC1tNjE4ODQx NjQ0NjQ2ODUzNjMyMGdtYWlsLW04MzQ2MTExODUyMDAyMTUzMTQwZ21haWwtbS0yNTI4MjYwNDUx NTI3NjUxNTQ5Z21haWwtbTQ2NzYxODM2MDE5NzgyMTkwODVnbWFpbC1tMjgyMTQ4OTY0NzEzNTEy NzIwMG1zb2xpc3RwYXJhZ3JhcGgsIGxpLm02NDUxNzQzNTI4Njk0Mzg4NzQ4Z21haWwtbTYxODg0 MTY0NDY0Njg1MzYzMjBnbWFpbC1tODM0NjExMTg1MjAwMjE1MzE0MGdtYWlsLW0tMjUyODI2MDQ1 MTUyNzY1MTU0OWdtYWlsLW00Njc2MTgzNjAxOTc4MjE5MDg1Z21haWwtbTI4MjE0ODk2NDcxMzUx MjcyMDBtc29saXN0cGFyYWdyYXBoLCBkaXYubTY0NTE3NDM1Mjg2OTQzODg3NDhnbWFpbC1tNjE4 ODQxNjQ0NjQ2ODUzNjMyMGdtYWlsLW04MzQ2MTExODUyMDAyMTUzMTQwZ21haWwtbS0yNTI4MjYw NDUxNTI3NjUxNTQ5Z21haWwtbTQ2NzYxODM2MDE5NzgyMTkwODVnbWFpbC1tMjgyMTQ4OTY0NzEz NTEyNzIwMG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV82NDUxNzQzNTI4Njk0 Mzg4NzQ4Z21haWwtbV82MTg4NDE2NDQ2NDY4NTM2MzIwZ21haWwtbV84MzQ2MTExODUyMDAyMTUz MTQwZ21haWwtbV8tMjUyODI2MDQ1MTUyNzY1MTU0OWdtYWlsLW1fNDY3NjE4MzYwMTk3ODIxOTA4 NWdtYWlsLW1fMjgyMTQ4OTY0NzEzNTEyNzIwMG1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2MTE2Njgy NzM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE4MDI5 NTgxMDggMTg3NDMzNzgyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QnV0IGZv ciB0aGUgc2FrZSBvZiBhbGcgYWdpbGl0eSBob3cgd291bGQgcGVvcGxlIGRlYWwgd2l0aCBpdD88 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5CcmlhbuKAmXMgb3B0aW9u IDMpOiBXPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ZSBnbyBiYWNrIHRvIHNheWluZyB0aGF0IHRo ZSBUQiBwcm90b2NvbCB2ZXJzaW9uIGRlZmluZXMgdGhlIEVLTSBzaXplLiBPbmNlIGEgbmV3DQog c2lnbmF0dXJlIHNjaGVtZSBpcyBwcm9wb3NlZCB0aGF0IHJlcXVpcmVzIGEgbG9uZ2VyIEVLTSwg d2XigJlsbCBuZWVkIHRvIGRlZmluZSBUQiB2IDEuMSB3aXRoLCBlLmcuLCBhIDY0LWJ5dGUgRUtN LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5CcmlhbuKAmXMgb3B0aW9uIDEpOiBXZSBzdGljayB3aXRoIHRoZSBz aWduYXR1cmUgc2NoZW1lIGRlZmluaW5nIEVLTSBzaXplLiBPbmNlIGEgbmV3IHNpZ25hdHVyZSBz Y2hlbWUgaXMgcHJvcG9zZWQgdGhhdCByZXF1aXJlcyBhIGxvbmdlciBFS00sIHRoZXJlIGlzIG5v IG5lZWQgdG8gZGVmaW5lIGEgbmV3DQogVEIgcHJvdG9jb2wgdmVyc2lvbi4gSG93ZXZlciwgb3Bl cmF0b3JzIHdpbGxpbmcgdG8gZGVwbG95IHRoaXMgbmV3IHNpZ25hdHVyZSBzY2hlbWUgd2lsbCBu ZWVkIHRvIGVuc3VyZSB0aGF0IHRoZWlyIGluZnJhc3RydWN0dXJlIHN1cHBvcnRzIHRoZSBuZXcg c2lnbmF0dXJlIHNjaGVtZSBhbmQgRUtNIHNpemUuIFdoaWNoIG1heSBpbmNsdWRlIHVwZGF0aW5n IFRUUlBzLCBiYWNrLWVuZCBzZXJ2ZXJzLCBldGMuIGFzIGlmIGEgbmV3IFRCIHByb3RvY29sDQog dmVyc2lvbiB3YXMgZGVwbG95ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNvLCBJ4oCZbSB0aGlua2luZyB0 aGVyZSBpc27igJl0IG11Y2ggZXh0cmEgYWdpbGl0eSwgcHJhY3RpY2FsbHkgc3BlYWtpbmcsIHRo YXQgd2UgYnV5IHdpdGggb3B0aW9uIDEpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaGVlcnMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkFuZHJlaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_CY1PR0301MB084254284354740947C8DDBB8C520CY1PR0301MB0842_-- From nobody Fri Feb 24 10:36:48 2017 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 0A051129499 for ; Fri, 24 Feb 2017 10:36:45 -0800 (PST) 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, HTML_MESSAGE=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=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 Y6n-ybhO1jju for ; Fri, 24 Feb 2017 10:36:43 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d: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 2B8E4129497 for ; Fri, 24 Feb 2017 10:36:43 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id u188so25888366qkc.2 for ; Fri, 24 Feb 2017 10:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=RmXg3zXGBAlpIdjYsueb/IzRHTN4fCJVDHPLilIeWqY=; b=mhq+LkMR48xwltL/98a5ld9q24nLs1jr0ROPI61odQ+7unNi6qLi3AadCdcgG+fWxA O+ez5URUxFpJgH5QSXms/WNG7wYLbku1I520e9+ODBtEEckyGCSeP92OUH2+KKxt+cHr x8Ajna0mEVM/y9/Ae3byrdPpVJvym9o9Dyb/t+8luXmq1vJKGVg2+fOcj1HG1dZaYnOT T33eMTP3BYr0yRSiC9+jOMOrkuDpou3dkP4aGXYbB9+Pc+ielwo1op2sm/OPFY9QhFpA K0bC+USQfmxbIEfCmB2A9Hjm6MBgxIP4BsMimz2jfqb1SLG04T2WBhACo40Imu+7z8MW AjNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=RmXg3zXGBAlpIdjYsueb/IzRHTN4fCJVDHPLilIeWqY=; b=C+bLuqZtOZ7i02eULjWktrk2ebZJ8VXhIAETlwJKiI+j41eBVwz3b2g/3IgMeElVoI RTcQsT/L6gSDMwTolxmYYD+rOttHd6iAGFmXXGT8lH29RUEyaP0LCK1XDfrEfb3FqCTH bmMKH+4GO2vNtOabOv/zrADBkEmfE5lxkW1giIEbS3zBZ8B+PiFCIU2+YIvhg1e5uM0H poTy2zr9jZBaDJhsjgJ9mH0OjitshUD/JfsBc5jnSo5sgFJonAjtuvpBNHQrXhI3HmjE +DR/LR9Xb2S5f7KSyzkkO+IgcpXHGwKl1mSFYAoK/FJsCpyf2UfvfhcEEJ59ds507/4r aW6w== X-Gm-Message-State: AMke39lMIGpE1VMpRMdvyuqilOtd2LZVa+ufVPBHqimTfgWkTJnDWd81JtfpXO1G4mSkMBUg X-Received: by 10.55.146.135 with SMTP id u129mr4079298qkd.219.1487961402184; Fri, 24 Feb 2017 10:36:42 -0800 (PST) Received: from [192.168.86.130] ([191.115.25.29]) by smtp.gmail.com with ESMTPSA id z8sm5311161qkz.42.2017.02.24.10.36.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 10:36:41 -0800 (PST) From: John Bradley Message-Id: <68994F88-39A6-47C0-AE1D-FC26F7C1D327@ve7jtb.com> Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 24 Feb 2017 15:36:23 -0300 In-Reply-To: To: Andrei Popov References: X-Mailer: Apple Mail (2.3259) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c08b924d41f6c05494b02da" Archived-At: Cc: IETF Tokbind WG , Brian Campbell Subject: Re: [Unbearable] ramifications of longer EKMs 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: Fri, 24 Feb 2017 18:36:45 -0000 --94eb2c08b924d41f6c05494b02da Content-Type: multipart/alternative; boundary="Apple-Mail=_ED428A50-977F-41DE-9021-7226AB7058C4" --Apple-Mail=_ED428A50-977F-41DE-9021-7226AB7058C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Personally speaking, Brian=E2=80=99s option 3 may be more practical to = manage. I think we can double our signing key strength before being under = pressure to increase the EKM size to 64 bytes. > On Feb 24, 2017, at 2:44 PM, Andrei Popov = wrote: >=20 > =C3=98 But for the sake of alg agility how would people deal with it? > =20 > Brian=E2=80=99s option 3): We go back to saying that the TB protocol = version defines the EKM size. Once a new signature scheme is proposed = that requires a longer EKM, we=E2=80=99ll need to define TB v 1.1 with, = e.g., a 64-byte EKM. > =20 > Brian=E2=80=99s option 1): We stick with the signature scheme defining = EKM size. Once a new signature scheme is proposed that requires a longer = EKM, there is no need to define a new TB protocol version. However, = operators willing to deploy this new signature scheme will need to = ensure that their infrastructure supports the new signature scheme and = EKM size. Which may include updating TTRPs, back-end servers, etc. as if = a new TB protocol version was deployed. > =20 > So, I=E2=80=99m thinking there isn=E2=80=99t much extra agility, = practically speaking, that we buy with option 1). > =20 > Cheers, > =20 > Andrei --Apple-Mail=_ED428A50-977F-41DE-9021-7226AB7058C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Personally speaking, Brian=E2=80=99s option 3 may be more = practical to manage.

I= think we can double our signing key strength before being under = pressure to increase the EKM size to 64 bytes.


On Feb 24, 2017, at 2:44 PM, = Andrei Popov <Andrei.Popov@microsoft.com> wrote:

=C3=98  But = for the sake of alg agility how would people deal with it?
 
Brian=E2=80=99s option 3): We go back to saying = that the TB protocol version defines the EKM size. Once a new signature = scheme is proposed that requires a longer EKM, we=E2=80=99ll need to = define TB v 1.1 with, e.g., a 64-byte EKM.
 
Brian=E2=80=99s option 1): We stick with the = signature scheme defining EKM size. Once a new signature scheme is = proposed that requires a longer EKM, there is no need to define a new TB = protocol version. However, operators willing to deploy this new = signature scheme will need to ensure that their infrastructure supports = the new signature scheme and EKM size. Which may include updating TTRPs, = back-end servers, etc. as if a new TB protocol version was deployed.
 
So, I=E2=80=99m thinking there isn=E2=80=99t = much extra agility, practically speaking, that we buy with option = 1).
 
Cheers,
 
Andrei

= --Apple-Mail=_ED428A50-977F-41DE-9021-7226AB7058C4-- --94eb2c08b924d41f6c05494b02da Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEICb2Gmw9QdJBJmrdfFwCJ1Hl9qFO Fu9WNtCRJjtTgJPQMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDIyNDE4MzY0MlowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQDHftmB5zQQJPaPPz6isqHffugbbN12QRMb4mJ/Wydhnviz ZLQ7PtXDXq2yOJfjbRLH1XrbWSpr1BPdhR37V/Fe8n2VNc5OvsWk3ViStkxbxMWbuek49NsCgvn7 A6/z5+0dufGnbWOxH0WFtNfOxAkdrr+tS34wU2yxxYWEC5gpgsDCHhTNR11nxAIqQ6VZgdVHVVlJ mYbjXJf/VHQzTb6Hx2aeHCNAJWdaTRd9YugOlNjXM4fBIG0uu9fD7owxy6pxGpy8iH+eU78Onazf ORP7xLk8JamGV+WxQxBVO/FLvbJnhojG5+zlj7EgDMngfSUOBmb4iNkEmD6/lUWgXxDz --94eb2c08b924d41f6c05494b02da-- From nobody Fri Feb 24 14:18:16 2017 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 1B2DA1294F8 for ; Fri, 24 Feb 2017 14:18:15 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 Ru-RjCronBUp for ; Fri, 24 Feb 2017 14:18:13 -0800 (PST) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002: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 4F3931293F9 for ; Fri, 24 Feb 2017 14:18:13 -0800 (PST) Received: by mail-yb0-x235.google.com with SMTP id d88so8668521ybi.0 for ; Fri, 24 Feb 2017 14:18:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GTImfvjWFe8OsOmxzVhCIcPa5qnZTFM7FOGSr+hnB0k=; b=Aii4ABFbLbiSvcvS/JyF7YoggxA8Oqh8nMG53+NbS/advK4jbo5ljUx5WpfBCWdAtl eve7pP+Wbeq86vSGGTLcyZAbycishw7uKiTwu9sFDBKPR9cDBsz+9W5AY5eAp9uu6143 RViBHeluuAZDtg1R+YIAIdGI1UsDSxi4miOU8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GTImfvjWFe8OsOmxzVhCIcPa5qnZTFM7FOGSr+hnB0k=; b=aATcVKq/od/JMGszMFiNLiVBp95r6Yeos2l/ahdSueSVnp3SZGnkkIU6Zxm97Io7Kt u6FySBSiaK2C1sJ3Gw7JdWufWj7IdWATdOQ9uQ7kWe7WhIP3Bg9gWFkWfi7GDquh3eij l7FiTXaDHGFAvECggKV7QIXR6abKv+zHI2mDKgtjoN55qroiPOQkWM3uXtDIO3oR3pdl HCweXhDqPFHBfM2wPqS7ImCFnAlOJ3OldZ53xYbuac33xRhNPrklH8zDLjwChyP4B71b aYELgF2kiEqbIqrOE5/r4ILXqNIq0RC0gmlbWt4d+luFm+5wFdqnvLmwFucz79pdhZ7j zI5g== X-Gm-Message-State: AMke39mDjiOeyvf6cQ1z0HhUNIRvtj4YxKoYQFsXmXl8kBQPDSayrBWboNvsCe/Mu6BJcmmWLwlGmwrrW/FZVal3 X-Received: by 10.37.163.38 with SMTP id d35mr3236579ybi.32.1487974692424; Fri, 24 Feb 2017 14:18:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.126.131 with HTTP; Fri, 24 Feb 2017 14:17:41 -0800 (PST) In-Reply-To: <68994F88-39A6-47C0-AE1D-FC26F7C1D327@ve7jtb.com> References: <68994F88-39A6-47C0-AE1D-FC26F7C1D327@ve7jtb.com> From: Brian Campbell Date: Fri, 24 Feb 2017 15:17:41 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=94eb2c19a52cfa619805494e1a21 Archived-At: Cc: Andrei Popov , IETF Tokbind WG Subject: Re: [Unbearable] ramifications of longer EKMs 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: Fri, 24 Feb 2017 22:18:15 -0000 --94eb2c19a52cfa619805494e1a21 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Double the signing key *lenght* right? Which way more than doubles the strength (for EC anyway). Or am I really bad at math? On Fri, Feb 24, 2017 at 11:36 AM, John Bradley wrote: > Personally speaking, Brian=E2=80=99s option 3 may be more practical to ma= nage. > > I think we can double our signing key strength before being under pressur= e > to increase the EKM size to 64 bytes. > > > On Feb 24, 2017, at 2:44 PM, Andrei Popov > wrote: > > =C3=98 But for the sake of alg agility how would people deal with it? > > Brian=E2=80=99s option 3): We go back to saying that the TB protocol vers= ion > defines the EKM size. Once a new signature scheme is proposed that requir= es > a longer EKM, we=E2=80=99ll need to define TB v 1.1 with, e.g., a 64-byte= EKM. > > Brian=E2=80=99s option 1): We stick with the signature scheme defining EK= M size. > Once a new signature scheme is proposed that requires a longer EKM, there > is no need to define a new TB protocol version. However, operators willin= g > to deploy this new signature scheme will need to ensure that their > infrastructure supports the new signature scheme and EKM size. Which may > include updating TTRPs, back-end servers, etc. as if a new TB protocol > version was deployed. > > So, I=E2=80=99m thinking there isn=E2=80=99t much extra agility, practica= lly speaking, > that we buy with option 1). > > Cheers, > > Andrei > > > --94eb2c19a52cfa619805494e1a21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Double the signing key *lenght* right? Which way more than= doubles the strength (for EC anyway). Or am I really bad at math?=C2=A0

On Fri, F= eb 24, 2017 at 11:36 AM, John Bradley <ve7jtb@ve7jtb.com> wr= ote:
= Personally speaking, Brian=E2=80=99s option 3 may be more practical to mana= ge.

I think we can double our signing key strength befor= e being under pressure to increase the EKM size to 64 bytes.


O= n Feb 24, 2017, at 2:44 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:=

=C3=98=C2=A0=C2=A0But = for the sake of alg agility how would people deal with it?
=C2=A0
= Brian=E2=80= =99s option 3): We go back to saying that the TB protocol version defines the EKM= size. Once a new signature scheme is proposed that requires a longer EKM, = we=E2=80=99ll need to define TB v 1.1 with, e.g., a 64-byte EKM.<= /u>
=C2=A0
Brian= =E2=80=99s option 1): We stick with the signature scheme defining EKM size.= Once a new signature scheme is proposed that requires a longer EKM, there = is no need to define a new TB protocol version. However, operators willing = to deploy this new signature scheme will need to ensure that their infrastr= ucture supports the new signature scheme and EKM size. Which may include up= dating TTRPs, back-end servers, etc. as if a new TB protocol version was de= ployed.
=C2=A0
So, I=E2=80=99m thinking there isn=E2=80=99t much extra agility= , practically speaking, that we buy with option 1).
=C2=A0
Cheers,
=C2=A0
Andrei<= /span>


--94eb2c19a52cfa619805494e1a21-- From nobody Mon Feb 27 01:19:15 2017 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 70209128AC9 for ; Mon, 27 Feb 2017 01:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 7kk296_N4Mg1 for ; Mon, 27 Feb 2017 01:19:12 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (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 A76FD128824 for ; Mon, 27 Feb 2017 01:19:11 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 07785780373 for ; Mon, 27 Feb 2017 10:19:07 +0100 (CET) To: unbearable@ietf.org References: <90198679-4549-2893-6d91-f4415df217ad@sunet.se> From: Denis Message-ID: <705b00ac-d7dc-6d9d-9c5f-e895f22f300d@free.fr> Date: Mon, 27 Feb 2017 10:19:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <90198679-4549-2893-6d91-f4415df217ad@sunet.se> Content-Type: multipart/alternative; boundary="------------04FB71F998E0B61555515783" Archived-At: Subject: Re: [Unbearable] WGLC 3 on core documents 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: Mon, 27 Feb 2017 09:19:13 -0000 This is a multi-part message in MIME format. --------------04FB71F998E0B61555515783 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Comments on draft-ietf-tokbind-protocol-13 (The Token Binding Protocol Version 1.0) On page 14 within the Security Considerations section, I appreciate the fact that the following sentences have been added: *The Token Binding protocol does not prevent cooperating clients from* *sharing a bound token.A client could intentionally export a bound* *token with the corresponding Token Binding private key, or perform* *signatures using this key on behalf of another client.* However, these sentences have been placed inside section 7.1. which is called "Security Token Replay". This security consideration has nothing to do with "Security Token Replay" but with "Client collusion". Therefore, these sentences should be placed under a new section called: "7.2. Client collusion". ====================================================================================== Comments on draft-ietf-tokbind-https-08 (Token Binding over HTTP) On page 14 within the Security Considerations section, the same kind of change as the one requested for draft-ietf-tokbind-protocol-13 (The Token Binding Protocol Version 1.0) should be done, i.e. add a new section called: "7.2. Client collusion" with the following text : *Token Binding over HTTP does not prevent cooperating clients from sharing a bound token.A client could intentionally export a bound token with the corresponding Token Binding private key, or perform signatures using this key on behalf of another client.* Denis --------------04FB71F998E0B61555515783 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Comments on draft-ietf-tokbind-protocol-13 (The Token Binding Protocol Version 1.0)

On page 14 within the Security Considerations section, I appreciate the fact that the following sentences have been added:


The Token Binding protocol does not prevent cooperating clients from
sharing a bound token. A client could intentionally export a bound
token with the corresponding Token Binding private key, or perform
 signatures using this key on behalf of another client.

However, these sentences have been placed inside section 7.1. which is called "Security Token Replay".

This security consideration has nothing to do with "Security Token Replay" but with "Client collusion".

Therefore, these sentences should be placed under a new section called: "7.2. Client collusion".

======================================================================================

Comments on draft-ietf-tokbind-https-08 (Token Binding over HTTP)

On page 14 within the Security Considerations section, the same kind of change as the one requested
for draft-ietf-tokbind-protocol-13 (The Token Binding Protocol Version 1.0) should be done, i.e. add a new section
called: "7.2. Client collusion" with the following text :

Token Binding over HTTP does not prevent cooperating clients from
sharing a bound token. A client could intentionally export a bound
token with the corresponding Token Binding private key, or perform
signatures using this key on behalf of another client.


Denis

--------------04FB71F998E0B61555515783-- From nobody Mon Feb 27 11:36:35 2017 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 7B8FB12A2F3 for ; Mon, 27 Feb 2017 11:36:33 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 jXau2Fx-uGxw for ; Mon, 27 Feb 2017 11:36:31 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 9376B126D73 for ; Mon, 27 Feb 2017 11:36:31 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id v200so43928071ywc.3 for ; Mon, 27 Feb 2017 11:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pbyk86+n3TPTXWYgmOY2zaVS7edKhp4oiyq9iTiPrqQ=; b=dYRvizh+sRQwSWKivqHbgT18zC3rGFJ+V0wq2tlMOafeC9PvjbJCrfNEMrvBoNNQVx eLdTWTKpnA1xpcn+X5cyGAxzLOjF1dPYBy0SP3+/GAkAB1COc4+8iNXqiPBctV2a2Vp9 oEbipLyaN46SVhLJVxBLHwVVsXHa9gLb3+OlG6zvYS8W/jdbOasa1A3avXIkritj+/qc M3ROK5u9ko27ueBZMuEj+fk7j9nU9ysAxJlmjENQpdF4wGiv1e6ADQetRGQdFA+ft/UD WvVesPT4VhJEp0zTAPQvQD9RC3yRXIYa+dnBULek0c3SJekIYCjN0OETy96WqFWabKM9 Cc7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pbyk86+n3TPTXWYgmOY2zaVS7edKhp4oiyq9iTiPrqQ=; b=HYVcDWy5xCBVdcYnugRl58bFLloARmxctvhSSqHfW9iJfsARwR01qVTPB+b1zLwKGe ZFEnRkJoe/xVw2/aUiP2J0oTFLf5I9DFRz4qZP/QwptnSGqPBaPu7i1Sy7b8B9tiLjeO QS4bd3OXGJUzr81DxGhwGHrvLPlDxyHrW7lFVrK/N0k9k8wpx1FXNgdg6VnljNV6gmr7 ce0qr6R8MpMgV6mznHcc7w9Ico9DorbUWd0j9ek2RO1L58qef5pf6X65CCCTE3v3Dr/E c1Rv70HAxOldaugTNwYc+aDIuRi7WISP/tjKKaPFb28N4P6KT70H25frRTV4q5yk1fES BK6A== X-Gm-Message-State: AMke39nwNBgfhI0DRpTR1WKHV7XU74i+o3XYYoa4tOncfI1F2mqTztmxOMGLhuhPNjp+z5NzRZAG61hw01Cj7UNK X-Received: by 10.37.248.13 with SMTP id u13mr12788972ybd.98.1488224190463; Mon, 27 Feb 2017 11:36:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.65.5 with HTTP; Mon, 27 Feb 2017 11:36:10 -0800 (PST) In-Reply-To: <705b00ac-d7dc-6d9d-9c5f-e895f22f300d@free.fr> References: <90198679-4549-2893-6d91-f4415df217ad@sunet.se> <705b00ac-d7dc-6d9d-9c5f-e895f22f300d@free.fr> From: Nick Harper Date: Mon, 27 Feb 2017 11:36:10 -0800 Message-ID: To: Denis Content-Type: multipart/alternative; boundary=f403045dc640384b3a0549883282 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] WGLC 3 on core documents 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: Mon, 27 Feb 2017 19:36:33 -0000 --f403045dc640384b3a0549883282 Content-Type: text/plain; charset=UTF-8 The client collusion scenario is about one client exporting a bound token for another client to use. This bound token is a security token, and reusing the token (whether it is on the same client or another client) is replaying it. Hence, "Security Token Replay" is a perfectly appropriate section for those sentences. They don't need their own section. On Mon, Feb 27, 2017 at 1:19 AM, Denis wrote: > Comments on draft-ietf-tokbind-protocol-13 (The Token Binding Protocol > Version 1.0) > > On page 14 within the Security Considerations section, I appreciate the > fact that the following sentences have been added: > > * The Token Binding protocol does not prevent cooperating clients from* > * sharing a bound token. A client could intentionally export a bound* > * token with the corresponding Token Binding private key, or perform* > * signatures using this key on behalf of another client.* > > > However, these sentences have been placed inside section 7.1. which is > called "Security Token Replay". > > This security consideration has nothing to do with "Security Token Replay" > but with "Client collusion". > > Therefore, these sentences should be placed under a new section called: > "7.2. Client collusion". > > ============================================================ > ========================== > > Comments on draft-ietf-tokbind-https-08 (Token Binding over HTTP) > > On page 14 within the Security Considerations section, the same kind of > change as the one requested > for draft-ietf-tokbind-protocol-13 (The Token Binding Protocol Version > 1.0) should be done, i.e. add a new section > called: "7.2. Client collusion" with the following text : > > > > > * Token Binding over HTTP does not prevent cooperating clients from > sharing a bound token. A client could intentionally export a bound > token with the corresponding Token Binding private key, or perform > signatures using this key on behalf of another client.* > > > Denis > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --f403045dc640384b3a0549883282 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The client collusion scenario is about one client exportin= g a bound token for another client to use. This bound token is a security t= oken, and reusing the token (whether it is on the same client or another cl= ient) is replaying it. Hence, "Security Token Replay" is a perfec= tly appropriate section for those sentences. They don't need their own = section.

On = Mon, Feb 27, 2017 at 1:19 AM, Denis <denis.ietf@free.fr> wr= ote:
=20 =20 =20
=20

Comments on draft-ietf-tokbind-protocol-13 (The Token Binding Protocol Version 1.0) <= /p>

On page 14 within the Security Considerations section, I appreciate the fact that the following sentences have been added:


=C2=A0=C2=A0 The Token Binding protocol does not prevent cooperating clients from=
=C2=A0=C2=A0 <= /span>sharing a bound token.=C2=A0 A client could intentionally export a bound
=C2=A0=C2=A0 <= /span>token with the corresponding Token Binding private key, or perform
=C2=A0=C2=A0 signatures using this key on behalf of another client.<= /span>

=C2=A0 However, these sentences have been placed inside section 7.1. which is called "Security Token Replay".

This security consideration has nothing to do with "Security Token Replay&qu= ot; but with "Client collusion".

Therefore, these sentences should be placed under a new section called: "7.2. Client collusion".

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

Comments on draft-ietf-tokbind-https-08 (Token Binding over HTTP)

On page 14 within the Security Considerations section, the same kind of change as the one requested
for draft-ietf-tokbind-protocol-13 (The Token Binding Protocol Version 1.0) should be done, i.e. add a new section
called: "7.2. Client collusion" with the following text :

=C2=A0=C2=A0 Token Binding over HTTP does not prevent cooperating clients from
=C2=A0=C2=A0 sharing a bound token.=C2=A0 A client could intentionally export a bound
=C2=A0=C2=A0 token with the corresponding Token Binding private key, or perform
=C2=A0=C2=A0 signatures using this key on behalf of another client.


Denis

=20 =20 =20 =20 =20 =20

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearabl= e


--f403045dc640384b3a0549883282-- From nobody Mon Feb 27 12:40:02 2017 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 51E871293F8 for ; Mon, 27 Feb 2017 12:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 vZQwkwW_Q5yp for ; Mon, 27 Feb 2017 12:39:59 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (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 C2F19124281 for ; Mon, 27 Feb 2017 12:39:58 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id DC42978039B; Mon, 27 Feb 2017 21:39:55 +0100 (CET) To: Nick Harper References: <90198679-4549-2893-6d91-f4415df217ad@sunet.se> <705b00ac-d7dc-6d9d-9c5f-e895f22f300d@free.fr> From: Denis Message-ID: <59f884f8-02a9-1076-6479-87415bfdd8e0@free.fr> Date: Mon, 27 Feb 2017 21:39:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1E0CD1C94B32F1D952F4EB1D" Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] WGLC 3 on core documents 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: Mon, 27 Feb 2017 20:40:01 -0000 This is a multi-part message in MIME format. --------------1E0CD1C94B32F1D952F4EB1D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Nick, For being able to speak of a "replay", there should first be a "play of the token". But in this case, there is a single"play" of it, and hence no replay. Denis > The client collusion scenario is about one client exporting a bound > token for another client to use. This bound token is a security token, > and reusing the token (whether it is on the same client or another > client) is replaying it. Hence, "Security Token Replay" is a perfectly > appropriate section for those sentences. They don't need their own > section. > > On Mon, Feb 27, 2017 at 1:19 AM, Denis > wrote: > > Comments on draft-ietf-tokbind-protocol-13 (The Token Binding > Protocol Version 1.0) > > On page 14 within the Security Considerations section, I > appreciate the fact that the following sentences have been added: > > > *The Token Binding protocol does not prevent cooperating clients from* > *sharing a bound token.A client could intentionally export a bound* > *token with the corresponding Token Binding private key, or perform* > *signatures using this key on behalf of another client.* > > However, these sentences have been placed inside section 7.1. > which is called "Security Token Replay". > > This security consideration has nothing to do with "Security Token > Replay" but with "Client collusion". > > Therefore, these sentences should be placed under a new section > called: "7.2. Client collusion". > > ====================================================================================== > > Comments on draft-ietf-tokbind-https-08 (Token Binding over HTTP) > > On page 14 within the Security Considerations section, the same > kind of change as the one requested > for draft-ietf-tokbind-protocol-13 (The Token Binding Protocol > Version 1.0) should be done, i.e. add a new section > called: "7.2. Client collusion" with the following text : > > *Token Binding over HTTP does not prevent cooperating clients from > sharing a bound token.A client could intentionally export a bound > token with the corresponding Token Binding private key, or perform > signatures using this key on behalf of another client.* > > > Denis > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > > --------------1E0CD1C94B32F1D952F4EB1D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Nick,

For being able to speak of a "replay", there should first be a "play of the token".
But in this case, there is a single"play" of it, and hence no replay.

Denis


The client collusion scenario is about one client exporting a bound token for another client to use. This bound token is a security token, and reusing the token (whether it is on the same client or another client) is replaying it. Hence, "Security Token Replay" is a perfectly appropriate section for those sentences. They don't need their own section.

On Mon, Feb 27, 2017 at 1:19 AM, Denis <denis.ietf@free.fr> wrote:

Comments on draft-ietf-tokbind-protocol-13 (The Token Binding Protocol Version 1.0)

On page 14 within the Security Considerations section, I appreciate the fact that the following sentences have been added:


   The Token Binding protocol does not prevent cooperating clients from
   sharing a bound token.  A client could intentionally export a bound
   token with the corresponding Token Binding private key, or perform
   signatures using this key on behalf of another client.

 

However, these sentences have been placed inside section 7.1. which is called "Security Token Replay".

This security consideration has nothing to do with "Security Token Replay" but with "Client collusion".

Therefore, these sentences should be placed under a new section called: "7.2. Client collusion".

======================================================================================

Comments on draft-ietf-tokbind-https-08 (Token Binding over HTTP)

On page 14 within the Security Considerations section, the same kind of change as the one requested
for draft-ietf-tokbind-protocol-13 (The Token Binding Protocol Version 1.0) should be done, i.e. add a new section
called: "7.2. Client collusion" with the following text :

   Token Binding over HTTP does not prevent cooperating clients from
   sharing a bound token.  A client could intentionally export a bound
   token with the corresponding Token Binding private key, or perform
   signatures using this key on behalf of another client.


Denis


_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable



--------------1E0CD1C94B32F1D952F4EB1D-- From nobody Mon Feb 27 12:56:03 2017 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 108F112A327 for ; Mon, 27 Feb 2017 12:56:02 -0800 (PST) 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=sunet-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 MbtuQaXUFd-p for ; Mon, 27 Feb 2017 12:56:00 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 3F0E412A31A for ; Mon, 27 Feb 2017 12:56:00 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id k202so24864722lfe.1 for ; Mon, 27 Feb 2017 12:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-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=KpzBDS/+mkNHaYZSAqW0TSTemRRAnYV6woJghg3jn+Q=; b=E829z/O9rJ4BMZ5uGcrHBbt+vhp8Vh+liGhJrfctxdlj0VGZFcTaiKPy82Jh2HSICu YyijbkzZdo34XFXEbOXpTdEDA0gHAQoc7qi0lVXxI4o9/ywTqhzbtzMzNhvY0Svc5kU0 hvASXsVqv5j/1ixpqmh46kWdUfdN+jOkoYZyu434Xz7QGGmX3eGCG+E9vROZ7kGmCfw4 33OHHyaSPP3Q1yL6GooRj7BU8eOsp0016OsrRn8+DD781zxPUcyZFddPPDrxCM5CkuNc Ax1YJwxvaAYdsZ6XCzcNQcV2GLOXLg+8ybMSinD6JrwpSrJ75UYeqBTDtxGthuDjN1/M clXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KpzBDS/+mkNHaYZSAqW0TSTemRRAnYV6woJghg3jn+Q=; b=csOI/815+E7ez+s66tlXtO6S8a8x5vxab72mye9QTe+khUNcG86W/B1hUvL+jE+Txz I/aCCUiAoTudxXAp6FMis3tb18lRfUeMz9zJQ6s0GlZ/UK7eNYV/ubmYObKrnZy9D6tW DlWAQ+0L2iJnNyVLYSA6RMC3+IonSMyFb50REGC9e32NfUJxjnhgIOwmrdA2S1gZ0NIH PAE/8weRNIMK0lE3iTctbfBwnPXil2ZFfSB7ST2JqYF5xP89s3qc+H+beF70KJUAhQRb c3LN3Vw/ZmN5weikKtAgixT1khbIQwB1VApMS7bdaRd9Blw+mohqfwz279Q9Mp11b4df eu8A== X-Gm-Message-State: AMke39nGTVOeF3/T43nOOSSYDitWNubOqDisPEGwY/xnFrkgwduztj5uSuyqg3M4pOYpRQ== X-Received: by 10.25.233.21 with SMTP id g21mr5940046lfh.130.1488228958147; Mon, 27 Feb 2017 12:55:58 -0800 (PST) Received: from [10.0.0.149] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by smtp.gmail.com with ESMTPSA id p19sm4139401lfe.1.2017.02.27.12.55.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2017 12:55:57 -0800 (PST) To: unbearable@ietf.org References: <90198679-4549-2893-6d91-f4415df217ad@sunet.se> <705b00ac-d7dc-6d9d-9c5f-e895f22f300d@free.fr> <59f884f8-02a9-1076-6479-87415bfdd8e0@free.fr> From: Leif Johansson Message-ID: <14098295-c9bc-c936-f920-3422f205cbbd@sunet.se> Date: Mon, 27 Feb 2017 21:55:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <59f884f8-02a9-1076-6479-87415bfdd8e0@free.fr> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Unbearable] WGLC 3 on core documents 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: Mon, 27 Feb 2017 20:56:02 -0000 On 2017-02-27 21:39, Denis wrote: > Nick, > > For being able to speak of a "replay", there should first be a "play of > the token". > But in this case, there is a single"play" of it, and hence no replay. This seems to be drifting into the esoteric. Denis, right now I don't see consensus for the proposed change. Anyone who feels there is merit to Denis proposal should provide their explicit "+1" to it asap. Cheers Leif From nobody Mon Feb 27 14:43:09 2017 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 D8139129456 for ; Mon, 27 Feb 2017 14:43:06 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 QwRIoQweY7U6 for ; Mon, 27 Feb 2017 14:43:04 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 81C99129441 for ; Mon, 27 Feb 2017 14:43:04 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id p77so47192579ywg.1 for ; Mon, 27 Feb 2017 14:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+piIBApWgRafh2wTcbYm05HGeTYjtCVbSqy+z3YbRzY=; b=iBGXxzHMi3L9CE4RyqbHbJhZbLZh8vLu5otGHOPdFMdh0NBr9vTKnbpzWdr7vBncGS SSl0/9jTIQJ6sK+QxBfVNr1e1JaVI38CPTY88J/MSbbb8SHGj1NvYGXfgDz26+ZWEPSE 29napFeZ30FNcjfwvJkaOrgxa/G1Mph4VJT4xY/qMHNj5pwtS9YGDNpM8Fgx/ItoppXH PpPagAygBKxrr5mRlaT+qcpSfakd3L+Lkc/2Ke4xRdw9pQ9y1Ts21ICe2/7ItSrV3TIx DekJFS4plDlOTeDjHvq6QJThdX0kqD2oG8XyoRS7Rvz1+G6SHKtUaJ7CO2l55F7PWee3 jw7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+piIBApWgRafh2wTcbYm05HGeTYjtCVbSqy+z3YbRzY=; b=GDSw3nRYydafHBXdFrUHoWcDTzkv9eeSnvMGCBGiFwsspJwXiCIBfQ1dEWcwB3qJaS hKrg+1lIW3voYgm5oyKWWxdUPIy9ha1D3u5TCxI0zj6HG2j9Nd9MzANIu1fxwCczugQX r6ifAXBW3qrvVmf7z6G0Rvl1PJe5eHeSvIgE6vDq50qxA+Pa+FweNCSmH+SVAJaUBDHm 11EN47/sgpW9sy+DT4RWLz5athBfhIMSVCbGPCx/wDAc//z3VN/f2ibNUypwZpmkfE9T dfMfx0FkgmMunpaHDi7GYvw8aCqG3D9XMEPJ5eVj6VgbCTtDo+/sMNeqzz1T3QqDVxzl Tang== X-Gm-Message-State: AMke39k3JYPS1PptUdThsiJ1USJyTvQsAVoZfXnrWLiQ23rr998LDDIxl4cFcB/sZpf6HZKwVGNCucakQzNE56QG X-Received: by 10.129.173.68 with SMTP id l4mr9119438ywk.351.1488235383655; Mon, 27 Feb 2017 14:43:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.65.5 with HTTP; Mon, 27 Feb 2017 14:42:43 -0800 (PST) In-Reply-To: References: From: Nick Harper Date: Mon, 27 Feb 2017 14:42:43 -0800 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=f403045e8a56630f9705498acd8e Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] 0-RTT Token Binding: When to switch exporters? 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: Mon, 27 Feb 2017 22:43:07 -0000 --f403045e8a56630f9705498acd8e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hearing no objections to this approach, I'll update the I-D for Chicago. On Tue, Feb 7, 2017 at 4:35 PM, Nick Harper wrote: > I've been thinking about this approach for a while (and what it would tak= e > to implement it), and I've come to the conclusion that requiring switchin= g > exporters to match the switch of encryption keys is infeasible enough tha= t > it won't get implemented. > > Instead, I propose that if a server accepts the client's 0-RTT data, then > the client uses the 0-RTT exporter for the entirety of the connection, an= d > otherwise the client uses the exporter as already specified in TBPROTO. > This still has decent security properties. > > First, consider a server that is uncomfortable enough with the early > exporter that it does not want to accept any token bindings that use that > exporter. This server rejects all early data on connections where the > client tries to negotiate token binding, and falls back on using the > existing exporter in TBPROTO with no early data. > > Next, consider a server that does accept some requests sent in early data > with a token binding that used the early exporter (the only choice in a > request in early data). For this request, since the server accepted it, i= t > has decided that the early exporter provides enough security to verify th= e > binding (otherwise this server would be in the above category). If the > early exporter was good enough for this server on a request sent in early > data, then surely that server would accept the same request (with the sam= e > token binding) when sent under the forward-secure encryption keys. > > A server accepting early data should accept any request sent in early > data. The server can't sniff the early data to reject it if it contains a > request it doesn't like (e.g. a POST request), because the early data cou= ld > contain multiple requests (e.g. in the case of HTTP/2), and the server MU= ST > process the ClientHello and immediately send the ServerHello - it cannot > wait to process all of the client's early data. It follows that if a serv= er > will accept a token-bound request in early data, then it will accept any > token-bound request in early data, meaning that the server finds the earl= y > exporter used for the token binding acceptable no matter the request. If > the server is fine with the early exporter for every request, then it > should accept the early exporter when it is used for requests not sent in > early data as well. In other words, if the server does not want to allow > the early exporter to be used for token bindings on some requests, then t= he > only logical thing for that server to do is always reject early data if > token binding is negotiated. > > On Fri, Jan 13, 2017 at 2:18 PM, Andrei Popov > wrote: > >> =C3=98 Another way to move the change in exporters out of the client's >> control would be to do it at a time that is implicit in the protocol. An >> obvious choice would be switch exporters when the client switches from >> sending early data to sending data post-handshake. >> >> I think this type of approach is better. >> >> >> >> Cheers, >> >> >> >> Andrei >> >> >> >> *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *N= ick >> Harper >> *Sent:* Friday, January 13, 2017 12:30 PM >> *To:* IETF Tokbind WG >> *Subject:* [Unbearable] 0-RTT Token Binding: When to switch exporters? >> >> >> >> The current tokbind 0-RTT draft has the TLS 1.3 early exporter value use= d >> in the TokenBinding.signature for the entirety of the connection. One po= int >> of discussion that came up in Seoul was that we shouldn't use the 0-RTT >> exporter for too long. I agree that we shouldn't use it for too long, bu= t I >> can't remember (or figure out from the meeting notes) if the reason is j= ust >> because we prefer the crypto properties of the normal exporter, or are w= e >> also trying to prevent an attacker from being able to use the 0-RTT >> exporter indefinitely? >> >> >> >> For the first case, the switch from the 0-RTT exporter to the normal >> exporter can be client-initiated. One possible design would be to have t= he >> client send an extension in the TokenBinding indicating that all future >> TokenBindings will use the normal exporter. This would function similar = to >> the ratcheting idea (from section 4.1 of the I-D), but the ratchet doesn= 't >> take effect until this indicator extension is sent (before it's sent the >> server would accept both exporters). This would likely be done in >> combination with the idea of defining new key types to indicate that the >> 0-RTT exporter is in use so the server doesn't do trial verification. >> >> >> >> If we want to move the switch from 0-RTT exporter to normal exporter out >> of the client's control (so that an attacker can't keep using the 0-RTT >> exporter indefinitely), a different solution is needed. One possible ide= a >> is to have the server send a message that conceptually means "all future >> TokenBindings must not use the 0-RTT exporter". Right now, Token Binding >> doesn't have any server-to-client messages, so this would require defini= ng >> application-specific messages. Another way to move the change in exporte= rs >> out of the client's control would be to do it at a time that is implicit= in >> the protocol. An obvious choice would be switch exporters when the clien= t >> switches from sending early data to sending data post-handshake. >> > > --f403045e8a56630f9705498acd8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hearing no objections to this approach, I'll update th= e I-D for Chicago.
 --f403045e8a56630f9705498acd8e-- From nobody Tue Feb 28 10:46:41 2017 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 E3C8B129682 for ; Tue, 28 Feb 2017 10:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 uEcfsIfWcuzY for ; Tue, 28 Feb 2017 10:46:38 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0117.outbound.protection.outlook.com [104.47.38.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 1A11B129683 for ; Tue, 28 Feb 2017 10:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rlK3wISzcP7Lwnf80ZYciXCe8ygAwl9iNuab7tQjSOw=; b=iyeQ3dxi7+AqwfssN9x/pg8YUAfTCxsWgMLWGJ6KfuGVT6gkq75QSQciHjnXPpfTHItakf5Z3a2T50+pMf8cyBBEyG91+iMfdSvB+N09oRXf0+r/8MI8TaTrcB3Y3fukL4RTCz6XNV3cnZ++0bO81LtTvLVM14WN4z83VmCgJR0= Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0089.namprd21.prod.outlook.com (10.161.141.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.3; Tue, 28 Feb 2017 18:46:35 +0000 Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) by DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) with mapi id 15.01.0961.002; Tue, 28 Feb 2017 18:46:35 +0000 From: Andrei Popov To: Nick Harper Thread-Topic: [Unbearable] 0-RTT Token Binding: When to switch exporters? Thread-Index: AQHSbdvurWwJUrGAZkyxVvys5avGZKE28kcggCd4oACAH07+gIABRECQ Date: Tue, 28 Feb 2017 18:46:35 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-microsoft-exchange-diagnostics: 1; DM2PR21MB0089; 7:QJkKLqlUvCp4P84VChTfrVREZERwme4FmnMUOBm4TYfD5sFxaIxIVf0y0u6Me/Zm8qMUEgqxRLb6F4AQ5hS4QWXAtNgRhQD/BcTEEBLh1I9RBLoVfcv4piNLbPy2eNCCQojvHu4CpOIuGisHQOiVNM295vBuQUgJplE4GVOFmfRNFEpa3TO7hFGyZRhJTmoyu/ll7goJ3JWx8NqUAmifgzf9qZlp8W5XZEvjF1Hka6oF6V3nRpmh1l0yybC3a+7dTQyMxfjWZtqMn/zhRQw8+BeEDJCcpUTY5VeLReb1DGXphRiVp68R7bVfo33VPvtDcdOYnGQF3oqu3BSGmL27gGwM+0d/6miu3b+avnQOOjA= x-ms-office365-filtering-correlation-id: a0e91e03-8188-40a1-9651-08d4600a1f73 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DM2PR21MB0089; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:DM2PR21MB0089; BCL:0; PCL:0; RULEID:; SRVR:DM2PR21MB0089; x-forefront-prvs: 0232B30BBC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39450400003)(39840400002)(39860400002)(199003)(189002)(99286003)(68736007)(8936002)(229853002)(2900100001)(9686003)(9326002)(102836003)(10090500001)(97736004)(106356001)(106116001)(105586002)(6246003)(6916009)(2906002)(76176999)(101416001)(81156014)(54356999)(7696004)(4326008)(6116002)(7736002)(50986999)(38730400002)(110136004)(8676002)(5660300001)(10290500002)(2950100002)(19609705001)(5005710100001)(790700001)(81166006)(8990500004)(6436002)(33656002)(3660700001)(3280700002)(77096006)(93886004)(74316002)(54896002)(6306002)(25786008)(55016002)(122556002)(86612001)(86362001)(6506006)(92566002)(189998001)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0089; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR21MB0091E3F087E1AECA3A63A3788C560DM2PR21MB0091namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2017 18:46:35.7659 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0089 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] 0-RTT Token Binding: When to switch exporters? 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, 28 Feb 2017 18:46:40 -0000 --_000_DM2PR21MB0091E3F087E1AECA3A63A3788C560DM2PR21MB0091namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmljaywNCg0KDQrDmCAgSW5zdGVhZCwgSSBwcm9wb3NlIHRoYXQgaWYgYSBzZXJ2ZXIgYWNj ZXB0cyB0aGUgY2xpZW50J3MgMC1SVFQgZGF0YSwgdGhlbiB0aGUgY2xpZW50IHVzZXMgdGhlIDAt UlRUIGV4cG9ydGVyIGZvciB0aGUgZW50aXJldHkgb2YgdGhlIGNvbm5lY3Rpb24sIGFuZCBvdGhl cndpc2UgdGhlIGNsaWVudCB1c2VzIHRoZSBleHBvcnRlciBhcyBhbHJlYWR5IHNwZWNpZmllZCBp biBUQlBST1RPLiBUaGlzIHN0aWxsIGhhcyBkZWNlbnQgc2VjdXJpdHkgcHJvcGVydGllcy4NCk15 IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBhbiBhdHRhY2tlciB3aG8gaGFzIGEgc3RvbGVuIGJvdW5k IHRva2VuIGFuZCBUTFMg4oCcRWFybHkgU2VjcmV04oCdIChidXQgbm90IHRoZSBjb3JyZXNwb25k aW5nIFRCIHByaXZhdGUga2V5KSwgY2FuIHN1Y2Nlc3NmdWxseSByZXBsYXkgdGhpcyB0b2tlbiwg YWxvbmdzaWRlIHRoZSBhdHRhY2tlcuKAmXMgSFRUUCByZXF1ZXN0LCB0byBhIHNlcnZlciB0aGF0 IGFsbG93cyBUTFMgMS4zIDAtUlRULiBUaGlzIHR5cGUgb2YgcmVwbGF5IGlzIHBvc3NpYmxlIGZy b20gbXVsdGlwbGUgbWFjaGluZXMsIGZvciBhcyBsb25nIGFzIHRoZSBzZXJ2ZXIgaXMgd2lsbGlu ZyB0byBhY2NlcHQgMC1SVFQgY29ubmVjdGlvbnMgYmFzZWQgb24gdGhlIHNhbWUgVExTIOKAnEVh cmx5IFNlY3JldOKAnS4gSXMgdGhpcyBjb3JyZWN0Pw0KDQpBbmQgdGhpcyBpcyBvZiBjb3Vyc2Ug aW4gYWRkaXRpb24gdG8gYSBuZXR3b3JrIGF0dGFja2VyIGJlaW5nIGFibGUgdG8gcmVwbGF5IGEg bGVnaXRpbWF0ZSBjbGllbnTigJlzIHJlcXVlc3Qgd2l0aG91dCBjaGFuZ2UgKG5vIHN0ZWFsaW5n IG9mIHRva2VucyBvciBzZWNyZXRzIHJlcXVpcmVkKSwgdW5sZXNzIHRoZSBzZXJ2ZXIgdGFrZXMg ZXh0cmFvcmRpbmFyeSBzdGVwcyB0byBwcmV2ZW50IDAtUlRUIHJlcGxheS4NCg0KDQrDmCAgQSBz ZXJ2ZXIgYWNjZXB0aW5nIGVhcmx5IGRhdGEgc2hvdWxkIGFjY2VwdCBhbnkgcmVxdWVzdCBzZW50 IGluIGVhcmx5IGRhdGEuIFRoZSBzZXJ2ZXIgY2FuJ3Qgc25pZmYgdGhlIGVhcmx5IGRhdGEgdG8g cmVqZWN0IGl0IGlmIGl0IGNvbnRhaW5zIGEgcmVxdWVzdCBpdCBkb2Vzbid0IGxpa2UgKGUuZy4g YSBQT1NUIHJlcXVlc3QpLCBiZWNhdXNlIHRoZSBlYXJseSBkYXRhIGNvdWxkIGNvbnRhaW4gbXVs dGlwbGUgcmVxdWVzdHMgKGUuZy4gaW4gdGhlIGNhc2Ugb2YgSFRUUC8yKSwgYW5kIHRoZSBzZXJ2 ZXIgTVVTVCBwcm9jZXNzIHRoZSBDbGllbnRIZWxsbyBhbmQgaW1tZWRpYXRlbHkgc2VuZCB0aGUg U2VydmVySGVsbG8gLSBpdCBjYW5ub3Qgd2FpdCB0byBwcm9jZXNzIGFsbCBvZiB0aGUgY2xpZW50 J3MgZWFybHkgZGF0YS4NCkZyb20gdGhlIGZhY3QgdGhhdCB0aGUgc2VydmVyIHNlbmRzIHRoZSBT ZXJ2ZXJIZWxsbyBhZnRlciBwcm9jZXNzaW5nIENsaWVudEhlbGxvLCBpdCBkb2VzIG5vdCBmb2xs b3cgdGhhdCB0aGUgc2VydmVyIHdpbGwgYWNjZXB0IGV2ZXJ5IHJlcXVlc3Qgc2VudCBhcyBlYXJs eSBkYXRhLiBUaGUgc2VydmVyIGNhbiB2ZXJ5IHdlbGwgcmVqZWN0IGNlcnRhaW4gcmVxdWVzdHMg YW5kL29yIHRlcm1pbmF0ZSB0aGUgaGFuZHNoYWtlIGF0IGFueSBzdGFnZS4NCg0KQ2hlZXJzLA0K DQpBbmRyZWkNCg0K --_000_DM2PR21MB0091E3F087E1AECA3A63A3788C560DM2PR21MB0091namp_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubS0xMTc4MDI3MTQwNzQzMzQ0MDI2bTI0OTU5NjM3MjE3 ODgzMTYzMTNtc29saXN0cGFyYWdyYXBoLCBsaS5tLTExNzgwMjcxNDA3NDMzNDQwMjZtMjQ5NTk2 MzcyMTc4ODMxNjMxM21zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tLTExNzgwMjcxNDA3NDMzNDQwMjZt MjQ5NTk2MzcyMTc4ODMxNjMxM21zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV8t MTE3ODAyNzE0MDc0MzM0NDAyNm1fMjQ5NTk2MzcyMTc4ODMxNjMxM21zb2xpc3RwYXJhZ3JhcGg7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5 bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDoxNTU1Mzg3NzMyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBs YXRlLWlkczoyNTc1NzA2MjAgLTc3MTY4OTA2MCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 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 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIE5pY2ssPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SW5zdGVhZCwg SSBwcm9wb3NlIHRoYXQgaWYgYSBzZXJ2ZXIgYWNjZXB0cyB0aGUgY2xpZW50J3MgMC1SVFQgZGF0 YSwgdGhlbiB0aGUgY2xpZW50IHVzZXMgdGhlIDAtUlRUIGV4cG9ydGVyIGZvciB0aGUgZW50aXJl dHkgb2YgdGhlIGNvbm5lY3Rpb24sIGFuZCBvdGhlcndpc2UgdGhlIGNsaWVudCB1c2VzIHRoZSBl eHBvcnRlciBhcyBhbHJlYWR5IHNwZWNpZmllZCBpbiBUQlBST1RPLiBUaGlzDQogc3RpbGwgaGFz IGRlY2VudCBzZWN1cml0eSBwcm9wZXJ0aWVzLjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5NeSB1bmRl cnN0YW5kaW5nIGlzIHRoYXQgYW4gYXR0YWNrZXIgd2hvIGhhcyBhIHN0b2xlbiBib3VuZCB0b2tl biBhbmQgVExTIOKAnEVhcmx5IFNlY3JldOKAnSAoYnV0IG5vdCB0aGUgY29ycmVzcG9uZGluZyBU QiBwcml2YXRlIGtleSksIGNhbiBzdWNjZXNzZnVsbHkgcmVwbGF5IHRoaXMgdG9rZW4sIGFsb25n c2lkZQ0KIHRoZSBhdHRhY2tlcuKAmXMgSFRUUCByZXF1ZXN0LCB0byBhIHNlcnZlciB0aGF0IGFs bG93cyBUTFMgMS4zIDAtUlRULiBUaGlzIHR5cGUgb2YgcmVwbGF5IGlzIHBvc3NpYmxlIGZyb20g bXVsdGlwbGUgbWFjaGluZXMsIGZvciBhcyBsb25nIGFzIHRoZSBzZXJ2ZXIgaXMgd2lsbGluZyB0 byBhY2NlcHQgMC1SVFQgY29ubmVjdGlvbnMgYmFzZWQgb24gdGhlIHNhbWUgVExTIOKAnEVhcmx5 IFNlY3JldOKAnS4gSXMgdGhpcyBjb3JyZWN0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbmQgdGhpcyBpcyBv ZiBjb3Vyc2UgaW4gYWRkaXRpb24gdG8gYSBuZXR3b3JrIGF0dGFja2VyIGJlaW5nIGFibGUgdG8g cmVwbGF5IGEgbGVnaXRpbWF0ZSBjbGllbnTigJlzIHJlcXVlc3Qgd2l0aG91dCBjaGFuZ2UgKG5v IHN0ZWFsaW5nIG9mIHRva2VucyBvciBzZWNyZXRzIHJlcXVpcmVkKSwgdW5sZXNzDQogdGhlIHNl cnZlciB0YWtlcyBleHRyYW9yZGluYXJ5IHN0ZXBzIHRvIHByZXZlbnQgMC1SVFQgcmVwbGF5Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkEgc2VydmVyIGFjY2VwdGluZyBlYXJseSBkYXRhIHNo b3VsZCBhY2NlcHQgYW55IHJlcXVlc3Qgc2VudCBpbiBlYXJseSBkYXRhLiBUaGUgc2VydmVyIGNh bid0IHNuaWZmIHRoZSBlYXJseSBkYXRhIHRvIHJlamVjdCBpdCBpZiBpdCBjb250YWlucyBhIHJl cXVlc3QgaXQgZG9lc24ndCBsaWtlIChlLmcuIGEgUE9TVCByZXF1ZXN0KSwgYmVjYXVzZSB0aGUg ZWFybHkgZGF0YSBjb3VsZCBjb250YWluDQogbXVsdGlwbGUgcmVxdWVzdHMgKGUuZy4gaW4gdGhl IGNhc2Ugb2YgSFRUUC8yKSwgYW5kIHRoZSBzZXJ2ZXIgTVVTVCBwcm9jZXNzIHRoZSBDbGllbnRI ZWxsbyBhbmQgaW1tZWRpYXRlbHkgc2VuZCB0aGUgU2VydmVySGVsbG8gLSBpdCBjYW5ub3Qgd2Fp dCB0byBwcm9jZXNzIGFsbCBvZiB0aGUgY2xpZW50J3MgZWFybHkgZGF0YS48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbSB0aGUgZmFjdCB0aGF0IHRoZSBzZXJ2ZXIgc2VuZHMgdGhlIFNlcnZlckhl bGxvIGFmdGVyIHByb2Nlc3NpbmcgQ2xpZW50SGVsbG8sIGl0IGRvZXMgbm90IGZvbGxvdyB0aGF0 IHRoZSBzZXJ2ZXIgd2lsbCBhY2NlcHQgZXZlcnkgcmVxdWVzdCBzZW50IGFzIGVhcmx5IGRhdGEu IFRoZSBzZXJ2ZXINCiBjYW4gdmVyeSB3ZWxsIHJlamVjdCBjZXJ0YWluIHJlcXVlc3RzIGFuZC9v ciB0ZXJtaW5hdGUgdGhlIGhhbmRzaGFrZSBhdCBhbnkgc3RhZ2UuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNo ZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kcmVpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_DM2PR21MB0091E3F087E1AECA3A63A3788C560DM2PR21MB0091namp_-- From nobody Tue Feb 28 11:53:14 2017 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 5EFA8126579 for ; Tue, 28 Feb 2017 11:53:09 -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 r6NreNT2Rem2 for ; Tue, 28 Feb 2017 11:53:07 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 39BC5129698 for ; Tue, 28 Feb 2017 11:53:07 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id l138so16536591ywc.0 for ; Tue, 28 Feb 2017 11:53:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9hTKWrcfkIAeILYzXgnrZ/H04VEBkYSFYG/1+X62ESI=; b=b0s5JolKvpJib8jHTWoxcEUeXHGWAw3Z1+p8oMybNnR6hyzcEx/FeS3lv3feX98/GZ FbzlvTUcLmy6EL33R8o2amYtxkNlPN/jwdZlCPH9An/5WzKUKKxjAj2A4rQt7hAPFcJP Ip8adinAZmtjC91cJu6+8FltUUR561fu1xncFInNzO4TB55nsmS0yhv0PcsyuN7En16J 7hK+QKp+XM/gzaildc+/mu2lEwJsWqElxtS0lAYgMfqP/8iZISByECiFTNOskIAbHnT+ o9LGJ9owi8JuSL/CkBQZLflJu7to9twUw5a86gKSHkyRHAg5ar1ddbTcKQdNc68O8AKb bcqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9hTKWrcfkIAeILYzXgnrZ/H04VEBkYSFYG/1+X62ESI=; b=G1DWLMDLGcf2QqnKOHsfBk2mjD0ObwraFP5/P6Xjh3IIOpvfldOozMlvEZ/GDu8kAn b+ff1eipjshBtywNmlkm2gnMwzH7u9Z6uXBFS+r60SwSmA7rMjsLGDXz1IOIe2O3zNJa VprrKFw2JMlnvvXxgL2Xvv9SbyYxdrlcPw5nef+wxbz3cWYSrK7UVjqn1gPKutYz+b5i 9NkUbGFzCD+hfnP6WGEyGCHywaNLwvH+X8HgTBACAeUyUoQsm6jj+lAHJP8CTRDdg9Mq Wu1NeqW8XJid26ZcGUjHzJ/729gnTZRFkf13kamHR7EypU+GQEqbxp2AuEHs90P+TUP7 HybA== X-Gm-Message-State: AMke39kssXV8u8DpP8dEi/YVfLDfOOIY7WAbd8+ZtmzOLUPB+UGJapLMRTPJQ0pZ963GvS21NxnoecB6Uc6IJ15P X-Received: by 10.129.75.204 with SMTP id y195mr252889ywa.320.1488311586293; Tue, 28 Feb 2017 11:53:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.65.5 with HTTP; Tue, 28 Feb 2017 11:52:45 -0800 (PST) In-Reply-To: References: From: Nick Harper Date: Tue, 28 Feb 2017 11:52:45 -0800 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a113c9f5e6adae105499c8b4f Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] 0-RTT Token Binding: When to switch exporters? 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, 28 Feb 2017 19:53:09 -0000 --001a113c9f5e6adae105499c8b4f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 28, 2017 at 10:46 AM, Andrei Popov wrote: > Hi Nick, > > > > =C3=98 Instead, I propose that if a server accepts the client's 0-RTT da= ta, > then the client uses the 0-RTT exporter for the entirety of the connectio= n, > and otherwise the client uses the exporter as already specified in TBPROT= O. > This still has decent security properties. > > My understanding is that an attacker who has a stolen bound token and TLS > =E2=80=9CEarly Secret=E2=80=9D (but not the corresponding TB private key)= , can successfully > replay this token, alongside the attacker=E2=80=99s HTTP request, to a se= rver that > allows TLS 1.3 0-RTT. This type of replay is possible from multiple > machines, for as long as the server is willing to accept 0-RTT connection= s > based on the same TLS =E2=80=9CEarly Secret=E2=80=9D. Is this correct? > > > > And this is of course in addition to a network attacker being able to > replay a legitimate client=E2=80=99s request without change (no stealing = of tokens > or secrets required), unless the server takes extraordinary steps to > prevent 0-RTT replay. > The attacker needs more than just the TLS "Early Secret". The attacker needs the resumption PSK (effectively the Early Secret), but also the ClientHello used for a 0-RTT connection and the Sec-Token-Binding header sent on that 0-RTT connection. The attacker can then replay the stolen bound token from that connection with the Sec-Token-Binding header on a new connection that uses the same ClientHello, and an attacker-chosen HTTP request. This replay is possible for as long as the server will accept that specific ClientHello (which can be shorter than how long that server will accept that resumption PSK, because the ClientHello includes the ticket age when sending early data, and section 4.2.7 of tls13 says that the server MUST validate that the ticket age is in a small tolerance of the time since it was issued). I believe this is covered in section 6.2 of https://tools.ietf.org/html/draft-ietf-tokbind-tls13-0rtt-00, and would be happy to expand on that section to make things clearer. This is all in addition to a network attacker being able to replay a 0-RTT request without changing it. This replay of a Sec-Token-Binding header for a 0-RTT request exists regardless of when the client switches from the 0-RTT exporter to the normal exporter (assuming that the server will accept the combination of 0-RTT + TB at all). > > > =C3=98 A server accepting early data should accept any request sent in e= arly > data. The server can't sniff the early data to reject it if it contains a > request it doesn't like (e.g. a POST request), because the early data cou= ld > contain multiple requests (e.g. in the case of HTTP/2), and the server MU= ST > process the ClientHello and immediately send the ServerHello - it cannot > wait to process all of the client's early data. > > From the fact that the server sends the ServerHello after processing > ClientHello, it does not follow that the server will accept every request > sent as early data. The server can very well reject certain requests and/= or > terminate the handshake at any stage. > The server chooses whether or not to accept early data before it reads that early data. This is the fact that I use to conclude that the server will accept in early data any request. The server certainly could terminate the handshake at any stage, but then it doesn't matter how we would do Token Binding on that connection, because the connection is no more. TLS 1.3 doesn't provide any mechanism for a server to say "I don't like that that request was sent in early data, please send it again now that the handshake is complete", and I'm not aware of any application layer specs (e.g. HTTP) that have such a mechanism. That's how I reached the conclusion that the server won't reject some requests sent in early data. > > > Cheers, > > > > Andrei > > > --001a113c9f5e6adae105499c8b4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 28, 2017 at 10:46 AM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

Hi Nick,

=C2=A0

=C3=98=C2= =A0 Instead, I propose that if a server accepts the= client's 0-RTT data, then the client uses the 0-RTT exporter for the e= ntirety of the connection, and otherwise the client uses the exporter as al= ready specified in TBPROTO. This still has decent security properties.

My understanding is that an attacker who has a stolen bound token= and TLS =E2=80=9CEarly Secret=E2=80=9D (but not the corresponding TB priva= te key), can successfully replay this token, alongside the attacker=E2=80=99s HTTP request, to a server that allows TLS 1.3 0-RTT= . This type of replay is possible from multiple machines, for as long as th= e server is willing to accept 0-RTT connections based on the same TLS =E2= =80=9CEarly Secret=E2=80=9D. Is this correct?

=C2=A0

And this is of course in addition to a network attacker being abl= e to replay a legitimate client=E2=80=99s request without change (no steali= ng of tokens or secrets required), unless the server takes extraordinary steps to prevent 0-RTT replay.


The attacker needs more than jus= t the TLS "Early Secret". The attacker needs the resumption PSK (= effectively the Early Secret), but also the ClientHello used for a 0-RTT co= nnection and the Sec-Token-Binding header sent on that 0-RTT connection. Th= e attacker can then replay the stolen bound token from that connection with= the Sec-Token-Binding header on a new connection that uses the same Client= Hello, and an attacker-chosen HTTP request. This replay is possible for as = long as the server will accept that specific ClientHello (which can be shor= ter than how long that server will accept that resumption PSK, because the = ClientHello includes the ticket age when sending early data, and section 4.= 2.7 of tls13 says that the server MUST validate that the ticket age is in a= small tolerance of the time since it was issued). I believe this is covere= d in section 6.2 of=C2=A0https://tools.ietf.org/html/draft-ietf-tokbind-tls13= -0rtt-00, and would be happy to expand on that section to make things c= learer. This is all in addition to a network attacker being able to replay = a 0-RTT request without changing it.

This replay o= f a Sec-Token-Binding header for a 0-RTT request exists regardless of when = the client switches from the 0-RTT exporter to the normal exporter (assumin= g that the server will accept the combination of 0-RTT + TB at all).
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

<= /span>

=C2=A0

=C3=98=C2= =A0 A server accepting early data should accept any= request sent in early data. The server can't sniff the early data to r= eject it if it contains a request it doesn't like (e.g. a POST request)= , because the early data could contain multiple requests (e.g. in the case of HTTP/2), and the server MUST proces= s the ClientHello and immediately send the ServerHello - it cannot wait to = process all of the client's early data.

From the fact that the server sends the ServerHello after process= ing ClientHello, it does not follow that the server will accept every reque= st sent as early data. The server can very well reject certain requests and/or terminate the handshake at an= y stage.


The server = chooses whether or not to accept early data before it reads that early data= . This is the fact that I use to conclude that the server will accept in ea= rly data any request. The server certainly could terminate the handshake at= any stage, but then it doesn't matter how we would do Token Binding on= that connection, because the connection is no more. TLS 1.3 doesn't pr= ovide any mechanism for a server to say "I don't like that that re= quest was sent in early data, please send it again now that the handshake i= s complete", and I'm not aware of any application layer specs (e.g= . HTTP) that have such a mechanism. That's how I reached the conclusion= that the server won't reject some requests sent in early data.

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0


--001a113c9f5e6adae105499c8b4f-- From nobody Tue Feb 28 12:55:40 2017 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 3A75A1296F5 for ; Tue, 28 Feb 2017 12:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 fVIWpyzCzOjd for ; Tue, 28 Feb 2017 12:55:37 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0113.outbound.protection.outlook.com [104.47.42.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1A21296EE for ; Tue, 28 Feb 2017 12:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6KiIymR4ylVweQ9ENqLxH6hqf8mH3tEJobbUVKrwrVc=; b=JuyaHBSanFaVJv7FhEOrfpcftk6vS6v1reLMe20FgQASbYZbjV3rtRF4ReKT+32gSX118GqdcTcp9AJjDFA9vRahdKuHe07hl80xmhRWOBBXw0t2xwcbnM4Dl8LeAwMC48n39sxua+Ls0E5MigXjkTFUYbyTHouRmR0hEqUJdpo= Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0092.namprd21.prod.outlook.com (10.161.141.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.3; Tue, 28 Feb 2017 20:55:34 +0000 Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) by DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) with mapi id 15.01.0961.002; Tue, 28 Feb 2017 20:55:34 +0000 From: Andrei Popov To: Nick Harper Thread-Topic: [Unbearable] 0-RTT Token Binding: When to switch exporters? Thread-Index: AQHSbdvurWwJUrGAZkyxVvys5avGZKE28kcggCd4oACAH07+gIABRECQgAAemICAAAhjEA== Date: Tue, 28 Feb 2017 20:55:34 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-microsoft-exchange-diagnostics: 1; DM2PR21MB0092; 7:L2vSFaK9kAVOG5/+82vP5tErjlYViKT6blFRAWI4LWBJ3Ql5m/sMJcIKUVPt6qnyXWvkROe3cNHFCH2POrAHZk1cdQfxDEHqN+GELrD6q4t0ZNTy0wA83enGTaBlIX9Xiux4S2pN0zlFjziCkcpngrHh28PSBg2gM1mb5a++iAqCeO3c67QAj5KFk6CR15EHTaUGm4Kz0OZGHYd5eCj4hM4tiMiQ7/Lzi1OfMa1b2bms1bmIi11OSa5Zdl+45VKH7HLc4t5qM+9yaWSs9YQDDeDS/+2JwQkZjxqwiOfzSECoi3AszojugRTTHlNOPz20VwOrqE8rAY1j0QCwRpb9cY8TKhOyaUNYmxdKLsWlOCI= x-ms-office365-filtering-correlation-id: b94135e7-eea0-4190-138a-08d4601c23ee x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DM2PR21MB0092; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:DM2PR21MB0092; BCL:0; PCL:0; RULEID:; SRVR:DM2PR21MB0092; x-forefront-prvs: 0232B30BBC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39860400002)(39410400002)(39850400002)(39840400002)(189002)(199003)(53936002)(106356001)(2900100001)(106116001)(3660700001)(2950100002)(105586002)(189998001)(6916009)(76176999)(97736004)(5005710100001)(8676002)(6306002)(3280700002)(7736002)(9686003)(54896002)(92566002)(81166006)(86362001)(122556002)(86612001)(74316002)(77096006)(6506006)(55016002)(81156014)(99286003)(6436002)(25786008)(2906002)(8936002)(38730400002)(229853002)(10090500001)(7696004)(101416001)(790700001)(6116002)(102836003)(54356999)(10290500002)(50986999)(33656002)(93886004)(110136004)(5660300001)(6246003)(8990500004)(68736007)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0092; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR21MB00910C83983BEE885B0E04288C560DM2PR21MB0091namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2017 20:55:34.2675 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0092 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] 0-RTT Token Binding: When to switch exporters? 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, 28 Feb 2017 20:55:39 -0000 --_000_DM2PR21MB00910C83983BEE885B0E04288C560DM2PR21MB0091namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIFRoZSBhdHRhY2tlciBuZWVkcyBtb3JlIHRoYW4ganVzdCB0aGUgVExTICJFYXJseSBTZWNy ZXQiLiBUaGUgYXR0YWNrZXIgbmVlZHMgdGhlIHJlc3VtcHRpb24gUFNLIChlZmZlY3RpdmVseSB0 aGUgRWFybHkgU2VjcmV0KSwgYnV0IGFsc28gdGhlIENsaWVudEhlbGxvIHVzZWQgZm9yIGEgMC1S VFQgY29ubmVjdGlvbiBhbmQgdGhlIFNlYy1Ub2tlbi1CaW5kaW5nIGhlYWRlciBzZW50IG9uIHRo YXQgMC1SVFQgY29ubmVjdGlvbi4NCkNvcnJlY3QsIHRoZSBDbGllbnRIZWxsbyBpcyBhbHNvIG5l ZWRlZC4gTm90IHN1cmUgdGhpcyBtYWtlcyB0aGluZ3Mgc2lnbmlmaWNhbnRseSBiZXR0ZXIsIGJ1 dCBpdCBpcyBhbiBhZGRpdGlvbmFsIHBpZWNlIHRoZSBhdHRhY2tlciBuZWVkcy4gSSBndWVzcyB3 ZeKAmXJlIHJlZmVycmluZyB0byB0aGUgc2FtZSBhdHRhY2ssIGJ1dCBkaXNhZ3JlZWluZyBvbiB3 aGV0aGVyIOKAnHRoaXMgc3RpbGwgaGFzIGRlY2VudCBzZWN1cml0eSBwcm9wZXJ0aWVz4oCd4pi6 Lg0KDQoNCsOYICBUTFMgMS4zIGRvZXNuJ3QgcHJvdmlkZSBhbnkgbWVjaGFuaXNtIGZvciBhIHNl cnZlciB0byBzYXkgIkkgZG9uJ3QgbGlrZSB0aGF0IHRoYXQgcmVxdWVzdCB3YXMgc2VudCBpbiBl YXJseSBkYXRhLCBwbGVhc2Ugc2VuZCBpdCBhZ2FpbiBub3cgdGhhdCB0aGUgaGFuZHNoYWtlIGlz IGNvbXBsZXRlIiwgYW5kIEknbSBub3QgYXdhcmUgb2YgYW55IGFwcGxpY2F0aW9uIGxheWVyIHNw ZWNzIChlLmcuIEhUVFApIHRoYXQgaGF2ZSBzdWNoIGEgbWVjaGFuaXNtLiBUaGF0J3MgaG93IEkg cmVhY2hlZCB0aGUgY29uY2x1c2lvbiB0aGF0IHRoZSBzZXJ2ZXIgd29uJ3QgcmVqZWN0IHNvbWUg cmVxdWVzdHMgc2VudCBpbiBlYXJseSBkYXRhLg0KSFRUUCBhbGxvd3MgdGhlIHNlcnZlciB0byBy ZWplY3QgaW5kaXZpZHVhbCByZXF1ZXN0cywgdGhlcmVmb3JlIEkgZGlzYWdyZWUgd2l0aCB0aGUg YWJvdmUgbG9naWMuIEUuZy4gYW4gSFRUUCBzZXJ2ZXIgY291bGQgcmVqZWN0IGEgc2VjdXJpdHkt c2Vuc2l0aXZlIHJlcXVlc3QgYXV0aGVudGljYXRlZCBieSBhIHJlcGxheWFibGUgdG9rZW4sIGJ1 dCBhY2NlcHQgb3RoZXIgcmVxdWVzdHMuDQoNCkl0IHNlZW1zIHRoYXQgdGhlIHJpZ2h0IHRoaW5n IHRvIGRvIGlzIG5vdCBhbGxvdyBUb2tlbiBCaW5kaW5nIG1lc3NhZ2VzIHVudGlsIGV4cG9ydGVy X3NlY3JldCBpcyBhdmFpbGFibGUuDQoNCkNoZWVycywNCg0KQW5kcmVpDQo= --_000_DM2PR21MB00910C83983BEE885B0E04288C560DM2PR21MB0091namp_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuZ21haWwtbS04NzY5Mjk4OTgzOTg4ODEyMjE3bXNvbGlz dHBhcmFncmFwaCwgbGkuZ21haWwtbS04NzY5Mjk4OTgzOTg4ODEyMjE3bXNvbGlzdHBhcmFncmFw aCwgZGl2LmdtYWlsLW0tODc2OTI5ODk4Mzk4ODgxMjIxN21zb2xpc3RwYXJhZ3JhcGgNCgl7bXNv LXN0eWxlLW5hbWU6Z21haWwtbV8tODc2OTI5ODk4Mzk4ODgxMjIxN21zb2xpc3RwYXJhZ3JhcGg7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLmdtYWlsLWhv ZW56Yg0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1ob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjAN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjE2OTg5Njg3MTY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi0xNTQ5NjUzMTUyIC0zNTQ2MzM5MjAgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PlRoZSBhdHRhY2tlciBuZWVkcyBtb3JlIHRoYW4ganVzdCB0aGUgVExTICZxdW90O0Vhcmx5IFNl Y3JldCZxdW90Oy4gVGhlIGF0dGFja2VyIG5lZWRzIHRoZSByZXN1bXB0aW9uIFBTSyAoZWZmZWN0 aXZlbHkgdGhlIEVhcmx5IFNlY3JldCksIGJ1dCBhbHNvIHRoZSBDbGllbnRIZWxsbyB1c2VkIGZv ciBhIDAtUlRUIGNvbm5lY3Rpb24gYW5kIHRoZSBTZWMtVG9rZW4tQmluZGluZyBoZWFkZXIgc2Vu dCBvbiB0aGF0DQogMC1SVFQgY29ubmVjdGlvbi48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q29ycmVj dCwgdGhlIENsaWVudEhlbGxvIGlzIGFsc28gbmVlZGVkLiBOb3Qgc3VyZSB0aGlzIG1ha2VzIHRo aW5ncyBzaWduaWZpY2FudGx5IGJldHRlciwgYnV0IGl0IGlzIGFuIGFkZGl0aW9uYWwgcGllY2Ug dGhlIGF0dGFja2VyIG5lZWRzLiBJIGd1ZXNzIHdl4oCZcmUgcmVmZXJyaW5nIHRvIHRoZSBzYW1l DQogYXR0YWNrLCBidXQgZGlzYWdyZWVpbmcgb24gd2hldGhlciDigJx0PC9zcGFuPmhpcyBzdGls bCBoYXMgZGVjZW50IHNlY3VyaXR5IHByb3BlcnRpZXPigJ08c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6V2luZ2RpbmdzIj5KPC9zcGFuPi48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPlRMUyAxLjMgZG9lc24ndCBwcm92aWRlIGFueSBtZWNoYW5pc20gZm9yIGEgc2Vy dmVyIHRvIHNheSAmcXVvdDtJIGRvbid0IGxpa2UgdGhhdCB0aGF0IHJlcXVlc3Qgd2FzIHNlbnQg aW4gZWFybHkgZGF0YSwgcGxlYXNlIHNlbmQgaXQgYWdhaW4gbm93IHRoYXQgdGhlIGhhbmRzaGFr ZSBpcyBjb21wbGV0ZSZxdW90OywgYW5kIEknbSBub3QgYXdhcmUgb2YgYW55IGFwcGxpY2F0aW9u IGxheWVyIHNwZWNzIChlLmcuDQogSFRUUCkgdGhhdCBoYXZlIHN1Y2ggYSBtZWNoYW5pc20uIFRo YXQncyBob3cgSSByZWFjaGVkIHRoZSBjb25jbHVzaW9uIHRoYXQgdGhlIHNlcnZlciB3b24ndCBy ZWplY3Qgc29tZSByZXF1ZXN0cyBzZW50IGluIGVhcmx5IGRhdGEuPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkhUVFAgYWxsb3dzIHRoZSBzZXJ2ZXIgdG8gcmVqZWN0IGluZGl2aWR1YWwgcmVxdWVzdHMs IHRoZXJlZm9yZSBJIGRpc2FncmVlIHdpdGggdGhlIGFib3ZlIGxvZ2ljLiBFLmcuIGFuIEhUVFAg c2VydmVyIGNvdWxkIHJlamVjdCBhIHNlY3VyaXR5LXNlbnNpdGl2ZSByZXF1ZXN0IGF1dGhlbnRp Y2F0ZWQNCiBieSBhIHJlcGxheWFibGUgdG9rZW4sIGJ1dCBhY2NlcHQgb3RoZXIgcmVxdWVzdHMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkl0IHNlZW1zIHRoYXQgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvIGlzIG5v dCBhbGxvdyBUb2tlbiBCaW5kaW5nIG1lc3NhZ2VzIHVudGlsIGV4cG9ydGVyX3NlY3JldCBpcyBh dmFpbGFibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kcmVpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM2PR21MB00910C83983BEE885B0E04288C560DM2PR21MB0091namp_-- From nobody Tue Feb 28 13:53:14 2017 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 C823812950D for ; Tue, 28 Feb 2017 13:53:12 -0800 (PST) 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, 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 l4_YUcrHflWL for ; Tue, 28 Feb 2017 13:53:11 -0800 (PST) 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 8F5C412950C for ; Tue, 28 Feb 2017 13:53:11 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id p77so18686731ywg.1 for ; Tue, 28 Feb 2017 13:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9LuOL6hQ7AbNw9JpFXc3Gs7ceL+sLxKFAO7opBArwWI=; b=gRKP9gDCPmAz7XlgpMtItwtJurgyDk6m7RDJIfJfvDDhyv2rJXsrAA1dp842DMP7+6 fguIXR/hsMwt/cDLH0Sg1XJPXGtcc+/ybNVKCRuRab8fLZLq2ZSHI0/PWjPkImEQHI+W kbWDFb8JqUDk6opoUXbmi9UPFPK6tbAEzfkTZFU+8f0DrwrZZuNLdZ5fwsh2F7c6vBkk qtKtOeGVoz8/pKMEuB21SODiHiB+JCen/c2bN1YJcKZ7DSz9WrXwvyhHguun8R5WxUTm VUqZSSdqR11HUrniOXNouW8lYlCJ3dRW0VkjWBje55q3B+B6/+rrMTySI7y0g6xYqx1M rMdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9LuOL6hQ7AbNw9JpFXc3Gs7ceL+sLxKFAO7opBArwWI=; b=LfXCHv6OfSG8uJxWGNaXGmH0f37Xx/vbILLpZXFQl4qRQ8dueBsQAwfur7KMWHIcQB sivTxUy0ZO5khipbBGQchN4LUWK+BBoNDyovS4h4yEgVcGWrywiFgG+3WbQy5LrXROJ3 JgsfnhMLyamcSo9n+IBa0hWoxarjaIViuGMSVjJS+/srfwGVpLrQq1d/8a2TvSUb76jW iHBHb06GJd5Ncoy0DDxUB0z8flG+48MEBRt5LlST1Yh6Vpzt492pgwpvLK9CJcrfrp7m 9nzYK1q5szV21NUA42sLsUfW+TGP5vt+k92I0NdJH4WRUNweubQGgpEojaunSAU1FxOP jFEg== X-Gm-Message-State: AMke39kvecr/JQ7gBS2i7ngSjRVQ890uxjBu0fyWV6Qu9FV9rfWAsLTh+pXCCwx/DMaq2q92dVCm1zFroRiAui0J X-Received: by 10.129.145.66 with SMTP id i63mr1552487ywg.137.1488318790548; Tue, 28 Feb 2017 13:53:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.65.5 with HTTP; Tue, 28 Feb 2017 13:52:50 -0800 (PST) In-Reply-To: References: From: Nick Harper Date: Tue, 28 Feb 2017 13:52:50 -0800 Message-ID: To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] 0-RTT Token Binding: When to switch exporters? 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, 28 Feb 2017 21:53:13 -0000 On Tue, Feb 28, 2017 at 12:55 PM, Andrei Popov wrote: > Correct, the ClientHello is also needed. Not sure this makes things > significantly better, but it is an additional piece the attacker needs. I > guess we=E2=80=99re referring to the same attack, but disagreeing on whet= her =E2=80=9Cthis > still has decent security properties=E2=80=9DJ. Yes, it sounds like we're talking about the same attack, and the additional piece of the ClientHello (in addition to the resumption PSK) doesn't change its feasibility that much. If we do any form of 0-RTT Token Binding, this attack will exist in some form. It is the major difference between 0-RTT Token Binding and regular Token Binding. My comment about "decent security properties" was that always using the 0-RTT exporter (if there is a token binding sent and accepted in early data) has decent security properties compared to using the 0-RTT exporter only for token bindings sent in early data. > > > It seems that the right thing to do is not allow Token Binding messages > until exporter_secret is available. That restriction would effectively mean that Token Binding can't be used with 0-RTT. From nobody Tue Feb 28 14:46:58 2017 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 A84DE129789 for ; Tue, 28 Feb 2017 14:46:57 -0800 (PST) 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, 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 4J9UIlyXgxfa for ; Tue, 28 Feb 2017 14:46:56 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 AC5D512973D for ; Tue, 28 Feb 2017 14:46:53 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id l138so19469661ywc.0 for ; Tue, 28 Feb 2017 14:46:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jOKaM7t8tWUFCQzHhjipXX5zsiYFKWSZ2qzLPt3GcPk=; b=VKa+I1+ebuqsjNzOYkLCq7fFdqG8vReuxtqrr2YFfLT9qhVLrI1feWmtBjUO5HS+BQ 6Zhn7QZjt9rmwRSi0mt3a/IrdvK/ZFvimR8PdVP6OOJ+Fqnexew66uvjiSzK8sZBbnPN iwGljErrYMZbh0RH3jq6KrUx3L2MyvcojE42z72AQoDkPjLela8mbp5iHKC60RaaW8yF E5jJM7ok5u00t9ug2xfv3jnv22FR+p+nVsIJVYmJJDH//Ci1P1m942FX767KqhzAnKsE kOAIRUwpdw7d2lQluijow/fDVBoHCV2ehf5CRF76bb3NSUwPF8cCgFoSRUNTyr6dYMoK FSMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jOKaM7t8tWUFCQzHhjipXX5zsiYFKWSZ2qzLPt3GcPk=; b=AfPWR0Nkp8LD3n3tks7nsM6CjEAoDovXjz12kYOPLc30jqh32VBdOntGJjTL1uKQDK FqNjr4qyg7RSyUyRTFEyl4C6FYAC+jdiDcakRfE0CCmNgwsSwSlB1+csuBv2Yann+bNz nx0WDJfRhilsd3ABKsyF7gD+0m+Sr8yiw1+HDQzGio+CEEh+j/NFh35ps5ytCaXIWYoG gUP7AKd2pOcPjGEk+VpGtHrwHiYZXZJTxeN9Kb32R6/6FS/aKpoXl4NwVI0kNoWXwhnc 4Dp60mocYJQCyYuE9DGU3daQknvMPnfPAeJr7h5glg7HUg6L2tYYaV2249osBMMZUg5A qm7g== X-Gm-Message-State: AMke39mNOoqeYpE+kDiw7MKGBPjsAm/aKKzpbPJzPY7f0803FLkJk0zhyG5q40cll6IQVnyrgvErm5Jed6o1P37N X-Received: by 10.129.173.68 with SMTP id l4mr1503075ywk.351.1488322012637; Tue, 28 Feb 2017 14:46:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.65.5 with HTTP; Tue, 28 Feb 2017 14:46:32 -0800 (PST) In-Reply-To: References: From: Nick Harper Date: Tue, 28 Feb 2017 14:46:32 -0800 Message-ID: To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] 0-RTT Token Binding: When to switch exporters? 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, 28 Feb 2017 22:46:57 -0000 Here's a solution that I think would handle the case of an HTTP server rejecting a request because it doesn't like the strength of the exporter used for Token Binding: - On requests sent in early data, the client uses the early exporter (it's the only option). - For requests sent after the handshake has completed, the client MAY continue to use the early exporter. - Once the client has received a response from the server, it SHOULD switch to using the (not early) exporter for new requests on that connection (requests that the client has already started to build but haven't sent yet can continue using the early exporter, per the previous point). - A server that receives a token-bound request using the early exporter MAY request that the client re-send the request using the (not early) exporter. This signal would be application-specific; for HTTP this could be done by sending a 307 status code with the Location header pointing to the same URI. A client that implements the SHOULD in the previous point will switch exporters by the time it re-sends the request. This solves the implementation problems of requiring the exporter to match which data its sent in, and I think it offers a reasonable solution for a server to reject a request because of exporter strength and have the client retry it with the regular exporter. This is only an outline of a solution and still has details that would need to be worked out. In particular, the client needs to indicate in its TokenBinding struct which exporter it used or the server has to do trial verification. On Tue, Feb 28, 2017 at 1:52 PM, Nick Harper wrote: > On Tue, Feb 28, 2017 at 12:55 PM, Andrei Popov > wrote: >> Correct, the ClientHello is also needed. Not sure this makes things >> significantly better, but it is an additional piece the attacker needs. = I >> guess we=E2=80=99re referring to the same attack, but disagreeing on whe= ther =E2=80=9Cthis >> still has decent security properties=E2=80=9DJ. > > Yes, it sounds like we're talking about the same attack, and the > additional piece of the ClientHello (in addition to the resumption > PSK) doesn't change its feasibility that much. If we do any form of > 0-RTT Token Binding, this attack will exist in some form. It is the > major difference between 0-RTT Token Binding and regular Token > Binding. My comment about "decent security properties" was that always > using the 0-RTT exporter (if there is a token binding sent and > accepted in early data) has decent security properties compared to > using the 0-RTT exporter only for token bindings sent in early data. >> >> >> It seems that the right thing to do is not allow Token Binding messages >> until exporter_secret is available. > > That restriction would effectively mean that Token Binding can't be > used with 0-RTT. From nobody Tue Feb 28 15:34:59 2017 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 7A8A4129440 for ; Tue, 28 Feb 2017 15:34:58 -0800 (PST) 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 shu64P4HqkZt for ; Tue, 28 Feb 2017 15:34:57 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0098.outbound.protection.outlook.com [104.47.37.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E473C126BF6 for ; Tue, 28 Feb 2017 15:34:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DnU/EX7Yo8ik+QpQ8tCN848IA1XFA+az70F+d9AmxH4=; b=OfkSWUhsOgPifxKJWpZb7ltAWk/HBCdI35jutUxanUbtrKpBU8GYR9a9QiDHG6tV1UPgH0wNpIfBhLguuQyqXUVB4Ta/UujJ7Ta/95AaQVti7Doxrb1BAHvUdjI7AUesTc6tA1ZIXwEmKGHmsQGp4K+mSCQJfnacFv9DPjIF9lM= Received: from SN1PR21MB0096.namprd21.prod.outlook.com (10.161.254.16) by SN1PR21MB0096.namprd21.prod.outlook.com (10.161.254.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.3; Tue, 28 Feb 2017 23:34:55 +0000 Received: from SN1PR21MB0096.namprd21.prod.outlook.com ([10.161.254.16]) by SN1PR21MB0096.namprd21.prod.outlook.com ([10.161.254.16]) with mapi id 15.01.0961.002; Tue, 28 Feb 2017 23:34:55 +0000 From: Andrei Popov To: Nick Harper Thread-Topic: [Unbearable] 0-RTT Token Binding: When to switch exporters? Thread-Index: AQHSbdvurWwJUrGAZkyxVvys5avGZKE28kcggCd4oACAH07+gIABRECQgAAemICAAAhjEIAAGSoAgAAPAQCAAAUIUA== Date: Tue, 28 Feb 2017 23:34:55 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:b::1d2] x-microsoft-exchange-diagnostics: 1; SN1PR21MB0096; 7:teWRRcYihYQqJbEhlnlX/tG99u6l1YaPLSTxYwrS0+qF0rFrsIoNRtn2sHmyNxmjX+SXiZTy6XHtwEzvS+9DOzV4RmasUTkGsAf2xqlLDRACkZBZE5W8NKIsEx6p0d17uL8m7+2DG9dR2/8cj5opS0VtQwHGQpmvvRjVb+01cSmXeFOlmGOm30vzDYPyh5d14HvCzLmbokpv2Kl8oUvycD2P4wboXyeXUy/G5ulTt5XsPusRztBQeqeJcf90XhQPaGVH4Mkt2GNfzxJmYtHuy+dYAhuvXXLRmfgvRd5A73Mag62c9/UQ/V7ko77pCOtUqr0k9KGdqiWiEAww/JTt8b9M9hqJnohmyQcaNIui0uI= x-ms-office365-filtering-correlation-id: 1fcc0b18-cf64-472f-a565-08d4603266ad x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:SN1PR21MB0096; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:SN1PR21MB0096; BCL:0; PCL:0; RULEID:; SRVR:SN1PR21MB0096; x-forefront-prvs: 0232B30BBC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39850400002)(39840400002)(39410400002)(39450400003)(199003)(189002)(3280700002)(3660700001)(38730400002)(2950100002)(122556002)(2906002)(86612001)(77096006)(5660300001)(110136004)(6916009)(6246003)(7696004)(10290500002)(5005710100001)(97736004)(8990500004)(2900100001)(33656002)(8676002)(68736007)(6506006)(189998001)(102836003)(10090500001)(86362001)(6116002)(81166006)(8936002)(6436002)(81156014)(92566002)(93886004)(9686003)(105586002)(53936002)(99286003)(54356999)(106116001)(55016002)(106356001)(229853002)(25786008)(7736002)(50986999)(101416001)(76176999)(305945005)(74316002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR21MB0096; H:SN1PR21MB0096.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 28 Feb 2017 23:34:55.1494 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR21MB0096 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] 0-RTT Token Binding: When to switch exporters? 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, 28 Feb 2017 23:34:58 -0000 Pj4gSXQgc2VlbXMgdGhhdCB0aGUgcmlnaHQgdGhpbmcgdG8gZG8gaXMgbm90IGFsbG93IFRva2Vu IEJpbmRpbmcgDQo+PiBtZXNzYWdlcyB1bnRpbCBleHBvcnRlcl9zZWNyZXQgaXMgYXZhaWxhYmxl Lg0KPg0KPiBUaGF0IHJlc3RyaWN0aW9uIHdvdWxkIGVmZmVjdGl2ZWx5IG1lYW4gdGhhdCBUb2tl biBCaW5kaW5nIGNhbid0IGJlIA0KPiB1c2VkIHdpdGggMC1SVFQuDQoNCk1vcmUgcHJlY2lzZWx5 LCB0aGlzIHdvdWxkIG1lYW4gdGhhdCBUQiAoYW5kIGJvdW5kIHRva2VucykgY2Fubm90IGJlIHNl bnQgYXMgcGFydCBvZiAwLVJUVCBkYXRhLiBUQiAoYW5kIGJvdW5kIHRva2VucykgY291bGQgc3Rp bGwgYmUgdXNlZCBhZnRlciB0aGUgc2VydmVyJ3MgcmVzcG9uc2UsIGFzIHNvb24gYXMgZXhwb3J0 ZXJfc2VjcmV0IGlzIGF2YWlsYWJsZS4NCg== From nobody Tue Feb 28 17:01:33 2017 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 6EACA12945C for ; Tue, 28 Feb 2017 17:01:26 -0800 (PST) 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, 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 mWpAqW3aAXei for ; Tue, 28 Feb 2017 17:01:25 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002: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 4FF6A1293DA for ; Tue, 28 Feb 2017 17:01:25 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id v200so21170052ywc.3 for ; Tue, 28 Feb 2017 17:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ioti1rWF0mlCwh/Kbdmk/RPG34RyKIh+NhZW6VGHNAg=; b=O9bgREIBqN3SCzDGoLkfdBlFkbngvud83L25wqyNY/mMLhlMl8/htyZyik7da3TGND YRSNo5zXWg7kXt/zoqU4pAYotivHO1oZ43pz4YSF8FpyeIiYYZiKbkWX7a6QDtJBfvO5 H1wUeXQUhC3c7dsZatVgX2+U3rqppU2U3pOmgEHLdfrkhGDfIDucGLCOnB1cR87Z1CTN /i2UaP4NnxKaCCXu2Am898bgFzr5URapv1zooO5BZ4SpTG2xCVKJDuPlO2ezs67L3vuH vgxcNjKOHa5/eF6QP/6H/c398rR2GbCpGSyuQxpj/oQ1L2+Is6zHCfDlv4j48//nXFSS VoNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ioti1rWF0mlCwh/Kbdmk/RPG34RyKIh+NhZW6VGHNAg=; b=XLf6w4GWYLLPeKXqh5Nfp7HdwmDUQbDXw8QHkC8Kiz30JnsGTEOehoGfIQGW4Nt0wm 6306jgWYGPaepEEZtiJXzmuaT918KwpQuIqZHp5yDLbS5A+acTLDmCu0whMT2QdtE8Id rQtxRakb6rSB/Ze5yhZhdhr3g0wbayl06y+Gz1ek4AftiKvFtQzlcJR9qukyqucfIC+N EBt65nUn9DXENSx4n13uwG9Fdwf87WXPqRyLmz5Ilovjw8XtXHX+4q4vu4+rTmreWMEM zQKUQeJSFBoxSpQYK3QzXGk1Agn1kIRuzJNAi3PgSKdeG3x0MUBAc/yzidONdsNy/u4u recg== X-Gm-Message-State: AMke39l6qvar11TRCeeDZd3182VNcSzy7AsiuTXuRPNk2mYiGt/zja7WEcvR0FuhwFoXK8h68KwOl5psDYbX2bUz X-Received: by 10.129.75.204 with SMTP id y195mr617714ywa.320.1488330084361; Tue, 28 Feb 2017 17:01:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.65.5 with HTTP; Tue, 28 Feb 2017 17:01:03 -0800 (PST) In-Reply-To: References: From: Nick Harper Date: Tue, 28 Feb 2017 17:01:03 -0800 Message-ID: To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] 0-RTT Token Binding: When to switch exporters? 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, 01 Mar 2017 01:01:26 -0000 On Tue, Feb 28, 2017 at 3:34 PM, Andrei Popov wrote: >>> It seems that the right thing to do is not allow Token Binding >>> messages until exporter_secret is available. >> >> That restriction would effectively mean that Token Binding can't be >> used with 0-RTT. > > More precisely, this would mean that TB (and bound tokens) cannot be sent as part of 0-RTT data. TB (and bound tokens) could still be used after the server's response, as soon as exporter_secret is available. The purpose of draft-ietf-tokbind-tls13-0rtt is to allow sending a bound token (along with a TokenBinding struct to verify the binding) in 0-RTT data, which that option doesn't allow. For HTTP, that option would mean a client resuming a connection and sending 0-RTT data can only send in 0-RTT data requests that have no cookies (or other potentially bound tokens), which is a very limited use case. From nobody Tue Feb 28 17:31:42 2017 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 A997F129559 for ; Tue, 28 Feb 2017 17:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 RLck-iq1JO6c for ; Tue, 28 Feb 2017 17:31:36 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0091.outbound.protection.outlook.com [104.47.36.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2F212950F for ; Tue, 28 Feb 2017 17:31:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rfqyys+aRB3kT31G1uD2j5PnWVbYwrmF5JGqgzfj+vo=; b=aQrrmX7d9bSpwBwZZfKw8C9PdTObMq8GICPkeBXFItOSWFNTlMZCm3CpzH4kRpeKtRosjdXq6x/2cGvqZPb+R8UTuYsMOMzKbdopWQsNOPYr03W/nKCDvLTeWSBtqEp8VyE8zLkHAXNc6VhOzt5VxU6x9vTe7T1LBMLyj20T7qs= Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0089.namprd21.prod.outlook.com (10.161.141.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.3; Wed, 1 Mar 2017 01:31:34 +0000 Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) by DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) with mapi id 15.01.0961.004; Wed, 1 Mar 2017 01:31:34 +0000 From: Andrei Popov To: Nick Harper Thread-Topic: [Unbearable] 0-RTT Token Binding: When to switch exporters? Thread-Index: AQHSbdvurWwJUrGAZkyxVvys5avGZKE28kcggCd4oACAH07+gIABRECQgAAemICAAAhjEIAAGSoAgAAPAQCAAAUIUIAAII2AgAACEkA= Date: Wed, 1 Mar 2017 01:31:34 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-microsoft-exchange-diagnostics: 1; DM2PR21MB0089; 7:synWooOF9ZdnsNt1K6PHkXV8lEapW6F+RJXCGZTlEXqT33ze5rusUdrSS03qLtLvsZ+FtAX1+Y8KGeQIOue2zWd6mP5ZOYn1QpNsl9umbWOxKnMMKxq1uQWgo4pzKMm/CKlPAqS2ZU3igLLGGTWPM1zddoj3tHbzo2G+gnEHdFOLkbnEMMlEaJDyWWdHzhfTodaeLFOQG4dUlxL06DA8Eh9sn3TJ2nGVkZ0X0vNTxzt8ia5iOGBJTmiWj/kB+Ay+EloQODZxD6AT+JiYd5gz4y189hMsx3nJmCAxORkixS+Yyl3d280WeL12spGNo4aaoTRaSu6++Ka1RFABs1bta5mzmaCgB1HBjgmX4xn9g14= x-ms-office365-filtering-correlation-id: f632daa5-d957-4025-3253-08d46042b294 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DM2PR21MB0089; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(20161123558025)(6072148); SRVR:DM2PR21MB0089; BCL:0; PCL:0; RULEID:; SRVR:DM2PR21MB0089; x-forefront-prvs: 0233768B38 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(199003)(189002)(101416001)(3280700002)(33656002)(77096006)(10290500002)(229853002)(5005710100001)(2900100001)(53936002)(55016002)(10090500001)(76176999)(54356999)(50986999)(9686003)(102836003)(6116002)(2906002)(8936002)(97736004)(92566002)(105586002)(106116001)(106356001)(93886004)(68736007)(8676002)(6246003)(25786008)(86362001)(8990500004)(7696004)(99286003)(81156014)(81166006)(6436002)(74316002)(38730400002)(2950100002)(110136004)(6506006)(7736002)(122556002)(189998001)(4326008)(305945005)(6916009)(5660300001)(86612001)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0089; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 01 Mar 2017 01:31:34.3747 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0089 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] 0-RTT Token Binding: When to switch exporters? 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, 01 Mar 2017 01:31:42 -0000 PiBGb3IgSFRUUCwgdGhhdCBvcHRpb24gd291bGQgbWVhbiBhIGNsaWVudCByZXN1bWluZyBhIGNv bm5lY3Rpb24gYW5kIHNlbmRpbmcgMC1SVFQgZGF0YSBjYW4gb25seSBzZW5kIGluIDAtUlRUIGRh dGEgcmVxdWVzdHMgdGhhdCBoYXZlIG5vIGNvb2tpZXMgKG9yIG90aGVyIHBvdGVudGlhbGx5IGJv dW5kIHRva2VucyksIHdoaWNoIGlzIGEgdmVyeSBsaW1pdGVkIHVzZSBjYXNlLg0KQWdyZWVkLCB0 aGlzIGlzIGluZGVlZCBhIGxpbWl0ZWQgdXNlLWNhc2UuIEJ1dCBzbyBpcyAwLVJUVCBhcHBsaWNh dGlvbiBkYXRhLCBpZiBvbmUgYXR0ZW1wdHMgdG8gdXNlIGl0IHNlY3VyZWx5Lg0K From nobody Tue Feb 28 21:51:37 2017 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 1C864127058 for ; Tue, 28 Feb 2017 21:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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 z8GWnTjObJND for ; Tue, 28 Feb 2017 21:51:34 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d: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 50B57120726 for ; Tue, 28 Feb 2017 21:51:34 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id n127so54389985qkf.0 for ; Tue, 28 Feb 2017 21:51:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vpKk+VGwtXjKqA6JylqIF+Y2RJy6oE3L5SZKtWrqnpA=; b=EhKyjFeVkfRWje8TFvcL2JIXrh6CC91zyT2lL8xqabfGqeosf2BM49tUTKysY7uyUF UncBbUGR4zfFl05kRRPB66BgbY478o/Uy8Vgyzae9qiEK6QWV7fuX0HfgzPsDxrMEvtm /5RnWNUB36c2/j/GGI3kYkADg+STRbWEPwN3fOXQJYdW9y3NeOwcuhEWKkrx2aqoR1tB pSz2f9KoUL+zllKhTIKOpoMUtm9bxRcbot7WKajj4ZTFVb7SFtqlRZ6NJ10K+6q0sSjn 7lK5arGA9u0BzkmGO0FqxlT2Pff8oY2PGAopDTRZyWlNiBJ8rBq+feFAhAOB375n1Lgo SOPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vpKk+VGwtXjKqA6JylqIF+Y2RJy6oE3L5SZKtWrqnpA=; b=TDbz0kpmZkblhQKvR8n90/voGThaV+XxBTqd0A4iHWdwQOrw690CWlBAr/g5jrtLTO jHF+FsYjugYYwaUn+PoUiSg73ndd36SuvbBzgojFgKVXidFWGBa+Qf9TQ3H5MY925u7N GjCHEnz86Z6bUFTBpHMYuexJhAeOH/Zvc05BLuRIs30OyGgynoyBtnXtbBHkyyFyxK+c 2jbKpB54HUu5AgDe2+yMyrD9imifENitUKdAVt8S70v6ua5Vrwa1DkEg58CH01KqISKa ap/AQ0QZ2ymaNm3alxqPPBvgRPtMBKYxqxFd6bb3U8XRepTJ06jEYVfH5vi1Gpr1lXm6 FCgg== X-Gm-Message-State: AMke39k20JatfbDq4qFA7HaVNO7t+SMr8fszHfnK/j/Ol4r6ONKTFVNjcqWJ7CQMaD97UlDdiFYpuXRhdMGipA== X-Received: by 10.200.46.208 with SMTP id i16mr7864796qta.13.1488347493051; Tue, 28 Feb 2017 21:51:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 28 Feb 2017 21:51:32 -0800 (PST) In-Reply-To: <90198679-4549-2893-6d91-f4415df217ad@sunet.se> References: <90198679-4549-2893-6d91-f4415df217ad@sunet.se> From: Martin Thomson Date: Wed, 1 Mar 2017 16:51:32 +1100 Message-ID: To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] WGLC 3 on core documents 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, 01 Mar 2017 05:51:36 -0000 This isn't going to be a short review. General (I have raised these in the past, I don't expect things to change, I just wanted to get them on the record.) These documents go to great lengths to create a generic solution that can be used in multiple protocols. However, the test set - those protocols that have been validated to work with the framework - is size 1. That makes me very nervous about the ability of this protocol to be applied in contexts outside of HTTP. (The extensions field is even less well justified, it has zero uses.) The use of a TLS extension is unnecessary complexity. Ostensibly, this is to save on latency. Any interactions with a server that might result in the creation of a token that requires this level of protection necessarily take multiple round trips. Thus, negotiating the use of this extension in the application protocol is perfectly feasible. I wish that eTLD+1 weren't baked into this. It's unnecessary if you accept a one-time cost for each origin. Only performance degrades. If we didn't bake in eTLD+1, we would create better incentives. Yes, I realize that this is a disincentive to deploy token binding. I don't believe that referred token bindings need a signature. Adding a signature only creates busy work for clients. My rationale is this: a token provider might not support the signature scheme that is negotiated with a token consumer. Therefore, the token provider might be unable to verify the signature on the referred token binding. If a security proof were to depend on the token provider verifying that signature, we have an entirely different set of constraints on the design (and a three-way negotiation to somehow build). The attack in Section 7.4 of the HTTP doc is thwarted simply by having the client send its TBID to the Token Provider. draft-ietf-tokbind-protocol-12 This doesn't really talk much about certificate-based client authentication and its relationship to that. A server that uses Section 1 Terminology: Intuitively, I read "Token Binding" as referring to the mechanism, or perhaps the signature that is carried, or perhaps the binding of the bearer token to the key pair. But it apparently means the key pair that is minted for each eTLD+1. I found that confusing. When issuing a security token to a client that supports Token Binding, a server includes the client's Token Binding ID in the token. Inclusion in the token is not necessary. The token could reference server-side state and THAT could include the public key. In order to successfully export and replay a bound security token, an attacker needs to also be able to export the client's private key, [...] The attacker only needs to be able to *use* the client's private key. Section 3 The Token Binding message is sent by the client to prove 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. The first MUST here is impossible to create a test for because this document doesn't define how the message is carried. I would suggest moving any requirement to include a token binding into the using portion (the HTTP doc). The MUST NOT forbids negotiating use of token binding in other ways. Other than the fact that you *can't* send a token binding in the clear, I see no reason to include this clause. Section 3.1 Suggested edit: o referred_token_binding - used when requesting tokens [that are intended ]to be presented to a different server. Section 3.2 I observe that it is strange to omit leading zeros in one case and require them in another. Section 3.3 It's odd that the signature doesn't cover the entire blob. More odd that it doesn't cover extensions (which makes me feel further vindicated in asking for their removal). I'd be happier if you just forbid renegotiation. The current text makes it sound really, really difficult to get this right. That it probably isn't that hard in practice is only because of the limited ways in which renegotiation is used in the real world. Note that even if messages themselves don't cross boundaries, it is possible for the processing of a message to occur on the other side of a renegotiation from when it was sent. So you can go through a lot of effort to generate a valid message and still have it fail to validate. o Context value: NULL In TLS 1.3, the context of NULL is the same as an empty sequence. That might be cause for some confusion. Section 4.1 In order to prevent cooperating servers from linking user identities, different keys SHOULD be used by the client for connections to different servers Why only SHOULD? Section 4.2 Token Bindings of type "referred_token_binding" may use different key parameters than those negotiated with this client. I think that this is true, but misleading. They MUST use whatever key parameters the client negotiated with the other server. Section 5 "the cookies" - ? "the server MUST discard the token" - this is wrong, because it implies that the server might ignore the token. In the HTTP case at least the server is required to reject the request. "the server MUST treat the token as invalid" might be better, but that leaves a lot to the application protocol. Section 6.1, 6.2 Tables would be easier to read, I think. Section 7 Since the token binding signature is a secret, you should recommend constant time validation. I am not aware of any implementation that does signature validation in constant time, but it's possible that they exist. Section 7.1 "by [the] malware" The idea that token binding keys are especially high value isn't borne out by deployment experience. I believe that no implementation is willing to apply additional protection for these keys due to the performance cost that imposes. Also, the keys are not appreciably worse to lose than some of the long-lived authentication tokens that are routinely held in browser cookie jars. If the intent is to improve the security situation, then it's true that these need to be better protected than a cookie jar, but this could say that directly instead. I really don't know what to do about the fact that they aren't that well protected in practice. Section 7.2 This appears to be identical to the text in the negotiation draft. I would remove it from this doc and instead include a reference to the negotiation security considerations section. The same would seem to apply to Section 7.5. Section 7.3 "Token Binding IDs are never transmitted in clear text" - do you actually require that? Section 7.5 The important observation here is that there are attacks that allow an attacker to force two connections to have the same exporter secret (the master section in TLS 1.2 or earlier). That's important to say. (But, see above). draft-ietf-tokbind-negotiation-07 I've already established my position: I don't think that this is necessary. I've also already shared my view on the version field in here. That's going to rust closed, if it isn't already. Section 2 Does the working group intend to remove the following? Or are those version numbers burned permanently? I note that there is no IANA registry for the version field, and no other text reserving these values. Prototype implementations of Token Binding drafts can indicate support of a specific draft version, e.g. {0, 1} or {0, 2}. Section 3 1. The server supports the Token Binding protocol version offered by the client or a lower version. This implies a very precise set of rules for handling changes in versions that isn't very well described in the document. It means that the value of the extension in any version MUST be valid in all earlier versions, though the earlier versions might only use a prefix of the encoded value. It also means that servers MUST ignore trailing octets if the version number is higher than one they support. It also implies that there can be no gaps in version support and that client MUST support a contiguous range of all versions from {0, 0} up to the version they advertise, otherwise the server might pick a version they don't know. All of that needs to be written down. Of course, it seems like you can successfully negotiate Token Binding, but then not use it: If the client does not support the Token Binding protocol version selected by the server, then the connection proceeds without Token Binding. Given that a client MUST send a Token Binding message when it is negotiated (see comment about that above), this creates a problem when the first message arrives at the server without a Token Binding message - the server and client now disagree about whether they have enabled the feature. draft-ietf-tokbind-https Abstract The abstract here is quite long. I believe that you can't include references in abstracts either (it's a style guide thing). "bind security tokens [...] to TLS [...] connections" - is that really the case? I guess that it's a transitive binding: the token is bound to the public key, the public key is then bound to the connection. However, if you read on, the server binds the tokens it issues, but it doesn't say to what, which could be misinterpreted. Section 1 "inoculating" is an odd choice of word to use. Why not just say that it "prevents the use of the token on connections unless the client is also able to prove possession of the key pair". "TokenBindingMessages" isn't used in the main doc, it uses "Token Binding messages" in full. 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). This assumes something that is no longer correct (that use of TLS == use of https://). See https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2-encryption/ Section 2 You can refer to RFC7515 for the definition of base64url rather than defining it again yourself. You already use the name (without defining it). The ABNF is incomplete, you need to define the grammar for EncodedTokenBindingMessage. The example should probably be an actual example. As it is, it's not much better than the ABNF. This section includes some rules regarding use that I think are generally unnecessary. PUT changes the resource using the enclosed "representation", not the header fields of the request. Vary can reasonably list any request header field it chooses. And the prohibition on including a token in the trailers is unnecessary, since it has to be possible to ignore trailers and presumably this is important in some way. Did you know that it is more efficient to allow multiple Sec-Token-Binding header fields than it is to have the current length-prefixed structure? You could comma separate encoded TokenBinding values and save a few bytes. I don't think that you need a SHOULD regarding header compression. Mention that it is possible and that will suffice. Section 2.1 The lack of any rules for scoping outside of the web browsing case makes me nervous. Either embrace eTLD+1 and let everyone do the same bad things, or say that if you are using cookies, use eTLD+1, otherwise use Origin. Or you could say use the same damned token across all requests if tracking isn't a concern - it's a concern that is fairly unique to browsers after all. In all cases, you need to have clear, mandatory rules. Section 3 Does this mean that a client MUST NOT pipeline requests if Token Binding is negotiated? The server also MUST process any TokenBindingMessages (or Token Binding messages) BEFORE initiating renegotiation. Section 5.2 This uses "may" and "must" a bit which makes it unclear whether there are any interoperability requirements. The fourth bullet point seems to be more than just a step in the process. Maybe this doesn't make sense to format as a bullet list. Section 5.3 When a client receives the Include-Referred-Token-Binding-ID header, it includes the referred token binding even if both the Token Provider and the Token Consumer fall under the same eTLD+1 and the provided and referred token binding IDs are the same. Note that the referred token binding is sent only on the request resulting from the redirect and not on any subsequent requests to the Token Provider. Why? Because two signatures are better somehow? Seems like busy work to me. The TokenBindingMessage SHOULD contain a TokenBinding with TokenBindingType referred_token_binding. Under what circumstances would a client NOT include a referred Token Binding? The redirect-chain approach makes my head hurt. Not because it's especially complex, but it's really hard to understand as written. It doesn't establish how TP1, despite being unable to generate a security token in the first place, is suddenly able to generate a security token later in the sequence. Isn't it easier if TP1 and TP2 just pass the ID for TC to each other over an authenticated channel (which might be the URL) so that TP2 can bind to TC directly? Section 5.5 Some of the table entries include 'n' - a number, but not all. "contain"/"containing" - use "bound to" instead This would be easier if the tokens were shown using a notation like Token2 or something like that. The sequence diagram is very hard to follow with its mix of odd notations and prose. 1a doesn't need to mention that the first server can bind to TBID1. Focus on the goal, which is describing the federated case. Section 7.3 Doesn't this belong in the main doc? For example, the client's Token Binding private key must be kept secret by the client. Why is this a "for example" and not a MUST? A client should not be tricked into sending a Sec- Token-Binding header field to a server that contains Token Binding messages about key pairs that the client does not control. What contains the messages? The server? Doesn't the header field carry these messages? I think that the integrity protection requirement is more simply stated: A client MUST NOT send a Token Binding message to a server unless it actually controls the corresponding key. This implies that an attacker MUST NOT be allowed to insert or modify a Token Binding message. Clients who do not understand that the Token Binding protocol exists are protected by virtue of not negotiating the use of the protocol. [[ It is also somewhat guaranteed by the use of the Sec- prefix, though this is a weaker assurance. ]] This might allow an attacker to either steal tokens and have them bound to their own keys, or to deny clients the ability to use the tokens they acquire legitimately. Section 7.4 See meta-level comment about the necessity of the signature. This analysis assumes that the MitM isn't able to convince the Token Consumer that the client simply doesn't support Token Binding: a much easier way to avoid having to attack the protocol. Of course, this is only possible if they can remain in-the-middle indefinitely. Please say something about this. Section 8.3 "must" or "should" and "may" all seem to be in need to capitalization or replacement with equivalent and less confusing words. On 17 February 2017 at 10:49, Leif Johansson wrote: > > This starts a 3 week WGLC on the core documents: > > https://tools.ietf.org/html/draft-ietf-tokbind-protocol-12 > https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-07 > https://tools.ietf.org/html/draft-ietf-tokbind-https-08 > > Any comments should be in hand by the 10th (any TZ). The recently > raised security considerations issue will be treated as a WGLC > comment. > > BestR > Leif & John > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable

On Tue, Feb 7, 2017 at 4:35 PM, Nick Harper <nharper@google.com> wrote:
I= 9;ve been thinking about this approach for a while (and what it would take = to implement it), and I've come to the conclusion that requiring switch= ing exporters to match the switch of encryption keys is infeasible enough t= hat it won't get implemented.

Instead, I propose tha= t if a server accepts the client's 0-RTT data, then the client uses the= 0-RTT exporter for the entirety of the connection, and otherwise the clien= t uses the exporter as already specified in TBPROTO. This still has decent = security properties.

First, consider a server that= is uncomfortable enough with the early exporter that it does not want to a= ccept any token bindings that use that exporter. This server rejects all ea= rly data on connections where the client tries to negotiate token binding, = and falls back on using the existing exporter in TBPROTO with no early data= .

Next, consider a server that does accept some re= quests sent in early data with a token binding that used the early exporter= (the only choice in a request in early data). For this request, since the = server accepted it, it has decided that the early exporter provides enough = security to verify the binding (otherwise this server would be in the above= category). If the early exporter was good enough for this server on a requ= est sent in early data, then surely that server would accept the same reque= st (with the same token binding) when sent under the forward-secure encrypt= ion keys.

A server accepting early data should acc= ept any request sent in early data. The server can't sniff the early da= ta to reject it if it contains a request it doesn't like (e.g. a POST r= equest), because the early data could contain multiple requests (e.g. in th= e case of HTTP/2), and the server MUST process the ClientHello and immediat= ely send the ServerHello - it cannot wait to process all of the client'= s early data. It follows that if a server will accept a token-bound request= in early data, then it will accept any token-bound request in early data, = meaning that the server finds the early exporter used for the token binding= acceptable no matter the request. If the server is fine with the early exp= orter for every request, then it should accept the early exporter when it i= s used for requests not sent in early data as well. In other words, if the = server does not want to allow the early exporter to be used for token bindi= ngs on some requests, then the only logical thing for that server to do is = always reject early data if token binding is negotiated.

On Fri, Jan 13, 2017 at 2:18 PM, Andrei Popov <A= ndrei.Popov@microsoft.com> wrote:

=C3=98=C2=A0 Another way to move the change in exporters out= of the client's control would be to do it at a time that is implicit i= n the protocol. An obvious choice would be switch exporters when the client= switches from sending early data to sending data post-handshake.

I think this type of approach is better.<= /u>

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ie= tf.org] On Behalf Of Nick Harper
Sent: Friday, January 13, 2017 12:30 PM
To: IETF Tokbind WG <unbearable@ietf.org>
Subject: [Unbearable] 0-RTT Token Binding: When to switch exporters?=

=C2=A0

The current tokbind 0-RTT draft has the TLS 1.3 earl= y exporter value used in the TokenBinding.signature for the entirety of the= connection. One point of discussion that came up in Seoul was that we shou= ldn't use the 0-RTT exporter for too long. I agree that we shouldn't use it for too long, but I can't r= emember (or figure out from the meeting notes) if the reason is just becaus= e we prefer the crypto properties of the normal exporter, or are we also tr= ying to prevent an attacker from being able to use the 0-RTT exporter indefinitely?

=C2=A0

For the first case, the switch from the 0-RTT export= er to the normal exporter can be client-initiated. One possible design woul= d be to have the client send an extension in the TokenBinding indicating th= at all future TokenBindings will use the normal exporter. This would function similar to the ratcheting idea (f= rom section 4.1 of the I-D), but the ratchet doesn't take effect until = this indicator extension is sent (before it's sent the server would acc= ept both exporters). This would likely be done in combination with the idea of defining new key types to indicate th= at the 0-RTT exporter is in use so the server doesn't do trial verifica= tion.

=C2=A0

If we want to move the switch from 0-RTT exporter to= normal exporter out of the client's control (so that an attacker can&#= 39;t keep using the 0-RTT exporter indefinitely), a different solution is n= eeded. One possible idea is to have the server send a message that conceptually means "all future TokenBindings must= not use the 0-RTT exporter". Right now, Token Binding doesn't hav= e any server-to-client messages, so this would require defining application= -specific messages. Another way to move the change in exporters out of the client's control would be to do it at a time t= hat is implicit in the protocol. An obvious choice would be switch exporter= s when the client switches from sending early data to sending data post-han= dshake.




On Thu, Feb 16, 2017 at 1:39 PM, John Bradley <ve7jtb@ve7jtb.com><= /span> wrote:
I suspect it is just one of those things we all think is self evid= ent.

I don=E2=80=99t think having a security considerati= on will hurt anything.

John B.

On Feb 16, 2017, at 6:29 PM, And= rei Popov <Andrei.Popov@microsoft.com> wrote:

Hi= Denis,
=C2=A0<= u>
I don=E2=80=99t mind adding l= anguage (probably in the security considerations) saying that the Token Bin= ding protocol does not prevent cooperating clients from sharing a bound tok= en.
So far I do not se= nse much enthusiasm for this in the WG though=E2=80=A6=
=C2=A0
Cheers,
= =C2=A0
Andrei
=C2=A0
From:=C2=A0Denis [mailto:denis.ietf@free.fr]=C2=A0
Sent:=C2=A0Thursday, Februa= ry 16, 2017 12:54 PM
To:=C2=A0John Bradley <ve7jtb@ve7jtb.com>; Andrei Popov <Andrei.Popov@= microsoft.com>
Cc:=C2=A0IETF TokBind WG <unbearable@ietf.org>
Subjec= t:=C2=A0Re: [Unbearable] Updated I-Ds
=C2=A0
A= ndrei,=C2=A0

You said:
The updated documents address the comments from the unbearable mailin= g list.
I don= 't believe that this is the case. I copy and paste a message sent on We= d, 21 dec 2016 at 11:16:52=C2=A0
under the topic: "WGLC on draft-ietf-tokbi= nd-https".

Denis
=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= =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

On Novembe= r 31, 2016, I sent a message saying:

This set of = documents failed to meet the terms of references of the WG charter.

= It is not resistant to the ABC attack (Alice and Bob collusion attack).
= In this attack Bob who is older than 18 colloborates with Alice and transmi= ts a token to Alice=C2=A0
who is only 14 so that she can demonstrat to a RS that= she is older than 18.

This kind of attack is not even mentionned in= the security considerations section.

This set of documents should n= ot be progressed to IETF last call unless the attack can be countered.
<= br>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

There are two options:
=C2=A0
Option A: drop thi= s series of documents, i.e. :=C2=A0

=C2=A0 draft-ietf-tokbind-protocol
= =C2=A0 draft-ietf-tokbind-https
=C2=A0 draft-ietf-tokbind-negotiation
or=C2=A0

Option B: clearly mention that the ABC attack cannot be coun= tered using TLS binding.

In case, the latter decision would be taken= by the WG, I propose a few text replacements.

Current text:

=C2=A0
=C2=
=A0Abstract=C2=A0=C2=A0=C2=A0 
=C2=A0
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 This document desc=
ribes a collection of mechanisms that allow HTTP
= 
=C2=A0=C2=A0 servers to cryptog=
raphically bind authentication tokens (such as
=C2=A0=C2=A0 cookies and OAuth to= kens) to TLS [RFC5246] conne= ctions.
=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0We describe both _first-party_ and=
 _federated_ scenarios.=C2=A0 In a
<=
span style=3D"font-size:11pt">=C2=A0=C2=A0 first-party scenario, an HTTP se=
rver is able to cryptographically
=C2=A0=C2=A0 bind the security tokens it issue=
s to a client, and which the client
=
=C2=A0=C2=A0 subsequently returns to the ser=
ver, to the TLS connection between the
=C2=A0=C2=A0 client and server.=C2=A0 Suc=
h bound security tokens are protected from
=C2=A0=C2=A0 misuse since the server =
can generally detect if they are replayed
=C2=A0=C2=A0 inappropriately, e.g., ov=
er other TLS connections. 
=C2=A0
=C2=A0=C2=A0 Federated token bindings, on the other=
 hand, allow servers to
=C2=A0=C2=A0 cryptographically bind security tokens to =
a TLS connection that the
=C2=A0=C2=A0 client has with a _different_ server than=
 the one issuing the token.
=C2=A0
 =C2=A0=C2=A0This Internet-Draft is a companion do=
cument to The Token Binding
=C2=A0=C2=A0 Protocol [I-D.ietf-tokb=
ind-protocol]
=C2=A0
=C2=
=A0
Propo=
sed additions in bl=
ue=C2=A0
=C2=A0
Abstract
=C2=A0 =C2=A0=C2=A0<=
/u>
=C2=A0=
=C2=A0=C2=A0This document describes a collection of mechanisms that allow H=
TTP
=
=C2=A0=C2=A0 servers to cryptographically bind authentication tokens (such =
as
=
=C2=A0=C2=A0 cookies and OAuth tokens) to TLS [RFC5246] connections.
=C2=A0
 =C2=A0=C2=A0We describe both _first-=
party_ and _federated_ scenarios.=C2=A0 In a
=C2=A0=C2=A0 first-party scenario, =
an HTTP server is able to cryptographically
=C2=A0=C2=A0 bind the security token=
s it issues to a client, and which the client
=C2=A0=C2=A0 subsequently returns =
to the server, to the TLS connection between the
= 
=C2=A0=C2=A0 client and server.=
=C2=A0 Such bound security tokens are protected from
=C2=A0=C2=A0 misuse since t=
he server can generally detect if they are replayed
=C2=A0=C2=A0 inappropriately=
, e.g., over other TLS connections. 
=C2=A0=

=C2=A0=
=C2=A0 However, the binding a security token to a TLS connection is<=
u>
=C2=A0=C2=A0 unable to counter collaboration attacks between two clie=
nts since
=C2=A0=C2=A0 one client can compute the necessary in=
formation for the other
=C2=A0=C2=A0 client without the need t=
o release his key(s) to the other client.
=C2=A0=

=
=C2=A0=C2=A0 For an effective protection against collaboration attacks, an<=
u>
=C2=A0=C2=A0 appropriate format of the security token, togethe=
r with an
=C2=A0 =C2=A0=C2=A0appropriate validation =
of some fields of it, must be used. 
<=
u>=C2=A0
=C2=A0=C2=A0 Federated token bindings, on the other hand, allow servers to=

=C2=
=A0=C2=A0 cryptographically bind security tokens to a TLS connection that t=
he
=
=C2=A0=C2=A0 client has with a _different_ server than the one issuing the =
token.
=C2=A0
=C2=A0=C2=A0 This Internet-Draft is a companion document to The Token B=
inding 
=C2=A0=C2=A0=C2=A0Protocol [I-D.ietf-tokbind-protocol]=
<=
/span>
=C2=A0
=C2=A0
<=
p class=3D"MsoNormal" style=3D"margin:6pt 0in 0.0001pt;font-size:12pt;font-=
family:'Times New Roman',serif">Current text:
7.1. Security Token Replay
=C2=A0=C2=A0 The goal of the Federate=
d Token Binding mechanisms is to prevent
=C2=A0=C2=A0 attackers from exporting a=
nd replaying tokens used in protocols 
=C2=A0=C2=A0=C2=A0between the client and =
Token Consumer, thereby impersonating
=C2=A0=C2=A0 legitimate users and gaining=
 access to protected resources.=C2=A0 Bound
=C2=A0=C2=A0 tokens can still be rep=
layed by malware present in the client.=C2=A0 In
<=
span style=3D"font-size:11pt;color:rgb(102,102,102)">=C2=A0=C2=A0 order to =
export the token to another machine and successfully replay
=C2=A0=C2=A0 it, the attacker also needs to export the corresponding pri=
vate key.
=C2=A0=C2=A0 The Token Binding private key is t=
herefore a high-value asset and
=C2=A0=C2=A0 MUST be stro=
ngly protected, ideally by generating it in a hardware=

=
=C2=A0=C2=A0 security module that prevents key export
=C2=A0
Proposed replacement
7.1. Security Token=C2=A0Exp=
ort and<=
span class=3D"m_-8952439419691527456Apple-converted-space">=C2=A0Replay=
<=
u>
=C2=A0
=C2=A0=C2=A0 The goal of =
the Federated Token Binding mechanisms is to prevent
=C2=A0=C2=A0 attackers from expo=
rting and replaying tokens used in protocols
=C2=A0=C2=A0 between the client and Toke=
n Consumer, thereby impersonating
=C2=A0=C2=A0 legitimate users and gaining access to=
 protected resources.=C2=A0 Bound
=C2=A0=C2=A0 tokens can still be replayed by malwar=
e present in the client.
=C2=A0=C2=A0=C2=A0They can also be exported and re-used when a client collaborates<=
u>
=
=C2=A0=C2=A0with another client.=C2=A0 In order to export the toke=
n to another
=C2=A0=C2=A0 machine and successfully use it, a client may ex=
port the
=C2=A0=C2=A0=C2=A0corresponding private key to the other client o=
r may perform all
=C2=A0=C2=A0=C2=A0the necessary computations for the oth=
er client without exporting
=C2=A0=C2=A0=C2=A0the corresponding private.=C2=A0 Protecting the Token Binding private=C2=A0
=C2=A0=C2=A0=C2=A0key, e.g. i=
n a hardware security module that prevents key export is
=C2=A0=C2=A0=C2=
=A0a good practice, but in such a case, it is inefficient to counter=

=C2=
=A0=C2=A0=C2=A0the clients collaboration attack.
Some other changes might need to be done in the s=
ame spirit.
=C2=A0
Denis
=C2=A0
Thanks.=C2=A0
=C2=A0
=C2=A0
On Feb 16, 2017, at 5= :26 PM, Andrei Popov <Andrei.Popov= @microsoft.com> wrote:
=C2=A0
The updated versions of = TBPROTO, TBNEGO and HTTPSTB have been uploaded:
<= /div>
=C2=A0
= The updated documents address the comments from the unbearable mailing list= and GitHub.
=C2=A0
Cheers,
=C2=A0
= Andrei
_______________________= ________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unb= earable
=C2=A0


________________________________=
_______________
Unbearable mailing list<=
/u>
Unbearable@ie=
tf.org
https://www.ietf.org/mailman/listinfo/unbearable<=
/a>

= =C2=A0