From nobody Sat Oct 1 03:10:33 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBCB12B250 for ; Sat, 1 Oct 2016 03:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Lj5YpFe4NVsb for ; Sat, 1 Oct 2016 03:10:29 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624FD12B04B for ; Sat, 1 Oct 2016 03:10:29 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id j28so9306840iod.2 for ; Sat, 01 Oct 2016 03:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QejF7a1H9m8HHerzng8dayf+o7ReU1MF76DjAB7u/Fs=; b=v3FpLQSzpZ3B32TY37/OWtdjhXpjyL+ypccZBTDiumaEXh9yxdiNelGnVCZcaWjcGb 6sQEKyVyHX98pGHoyoQWoYizvLkssEzuDZMQFISuPBUod+0W0nJPt6hMhgx5L/EzZWJW uhp/ZNi4OKeJ/Y/s1ROzyt8cxczv+uBExNbEYxui+KzKghfi5VcqKKlt1rsIlv+C2nz6 JQmVlDRTpU9qMJvG+Ds2NMN73fwyLB6QRGPQa9RgcLPlGZMtiXbh3IDHkM+R8ht1kYj+ tLIGlPgo2RdNQSXO//EAZntNeNbvx/9LI8ZXpwjURUJKdtYfyxD27DGnPMMjjzpzshro d8vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QejF7a1H9m8HHerzng8dayf+o7ReU1MF76DjAB7u/Fs=; b=KWPokPmdVT8ZOt4x9j09oDgcGlVens6y0d0gSYxm8E7PlJlffdpSYp0U+lved12G60 /qljtylX73AFloKif8ywH5BvYYByerGRlUU/DNwAZk6XKY9gwp9unpQFo91h5kHD6vHv 2cb5vYg2iawdDSWj5GpIVOYPk7YIgrQbUXEpbunUqUnXfwVY9iViWN9zRQnOI/bAKhh0 QHwkDNE+1yJkRQ0cL0LqSF4RAAQsoPTSVuhpuAHHVpzaSrbJtiAINvwareipd7idhWL5 Xwos+38ZWQIynFQ2PwA9wI6ZjAs5vIKZXtAQMbmAxBtY5tBbO+O7vO4cU6hxyPhduSYd 0OxA== X-Gm-Message-State: AA6/9RmX3DyDYg9w7KZbTOMuGmv4mZsMjC94vGNhIPOyYouyNUJO0rCvsYoCgaF/0JoRbftuf8+qPfRBziIKVgFB X-Received: by 10.107.30.197 with SMTP id e188mr13315381ioe.89.1475316628516; Sat, 01 Oct 2016 03:10:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.199 with HTTP; Sat, 1 Oct 2016 03:10:27 -0700 (PDT) X-Originating-IP: [172.56.12.237] Received: by 10.79.64.199 with HTTP; Sat, 1 Oct 2016 03:10:27 -0700 (PDT) In-Reply-To: <5f91fd28-1109-07bd-baf3-3f7c9e35ee31@sunet.se> References: <5f91fd28-1109-07bd-baf3-3f7c9e35ee31@sunet.se> From: John Bradley Date: Sat, 1 Oct 2016 07:10:27 -0300 Message-ID: To: Leif Johansson Content-Type: multipart/alternative; boundary=001a114072709307e8053dcaeb32 Archived-At: Cc: unbearable@ietf.org Subject: Re: [Unbearable] Seoul 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, 01 Oct 2016 10:10:31 -0000 --001a114072709307e8053dcaeb32 Content-Type: text/plain; charset=UTF-8 I am going. On Sep 29, 2016 12:44 PM, "Leif Johansson" wrote: > > Are folks planning to come to Seoul so it makes sense to have a meeting? > > I think it makes sense to have a meeting if the key contributors > are in the room! > > Cheers Leif > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a114072709307e8053dcaeb32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I am going.


On Sep 29, 2016 1= 2:44 PM, "Leif Johansson" <l= eifj@sunet.se> wrote:

Are folks planning to come to Seoul so it makes sense to have a meeting?
I think it makes sense to have a meeting if the key contributors
are in the room!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers Leif

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearabl= e
--001a114072709307e8053dcaeb32-- From nobody Sat Oct 1 04:44:30 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C17912B1C7; Sat, 1 Oct 2016 04:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, 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 wX0GlKiEH1VN; Sat, 1 Oct 2016 04:44:23 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.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 0255612B0C1; Sat, 1 Oct 2016 04:44:22 -0700 (PDT) X-AuditID: 1209190f-6e7ff70000004040-12-57efa194bfbe Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id E9.7C.16448.491AFE75; Sat, 1 Oct 2016 07:44:21 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u91BiJR0016885; Sat, 1 Oct 2016 07:44:20 -0400 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u91BiIKf016833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 1 Oct 2016 07:44:19 -0400 To: Brian Campbell , oauth , IETF Tokbind WG References: From: Justin Richer Message-ID: <07fa6f54-1ea3-7877-b624-981e5cdc754b@mit.edu> Date: Sat, 1 Oct 2016 07:44:16 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------98687EFF35F97A20E6C72B2F" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42IRYrdT15268H24we5buhar/99ktDj59hWb xbnHC5kcmD2WLPnJ5HH36EWWAKYoLpuU1JzMstQifbsEroxNZ26zFVxzrVjy/xxzA+NPwy5G Dg4JAROJjV0OXYxcHEICbUwSb6c8YoFwNjBKdBx5xgTh3GKSWNQ+lbWLkZNDWMBZ4tXXt+wg tohAuUTHlS8sIJOEBAIkVm7iAAmzCahKTF/TwgRi8wpYSezv7wCzWQRUJN6uOMgCYosKxEjs nzWTGaJGUOLkzCdgcU6BQIk3fy+A2cwCYRKNN9oYJzDyzUJSNgtJCsK2lbgzdzczhC0vsf3t HChbV2LRthXsMPHmrbOZFzCyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI10cvNLNFLTSndxAgK ZE5J/h2Mcxq8DzEKcDAq8fCeiHoXLsSaWFZcmXuIUZKDSUmU16jofbgQX1J+SmVGYnFGfFFp TmrxIUYJDmYlEV73BUA53pTEyqrUonyYlDQHi5I4b9eMA+FCAumJJanZqakFqUUwWRkODiUJ 3kkgjYJFqempFWmZOSUIaSYOTpDhPEDDb4ANLy5IzC3OTIfIn2LU5Tg298ZaJiGWvPy8VClx 3kXzgYoEQIoySvPg5oASUMLbw6avGMWB3hLmNQOmIyEeYPKCm/QKaAkT0JL8o29AlpQkIqSk GhhnFH7Lu/jU6PEvU5MXix6YGjoHmU7aMmk5m8jr+bJdB6TtraIE+p2MOtUu+Ss3RP/OvBfw 3+7Lu80L7i58pDFnaeL1Fa5ntpyZ18HP8Sv89Cum0qQ2qedv1zku3h0Q19d6g0spa/th943h asfLhMvNDK4tNLxXvtkoK2nO633KDwV/zPebrhmkxFKckWioxVxUnAgA1+fqrRsDAAA= Archived-At: Subject: Re: [Unbearable] [OAUTH-WG] explicit/implicit signaling to reveal TB ID 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, 01 Oct 2016 11:44:25 -0000 This is a multi-part message in MIME format. --------------98687EFF35F97A20E6C72B2F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit +1 to this. I think we also need to keep in mind that it's incredibly common for an OAuth client to talk to multiple resource servers with a single token from a single authorization server that's been configured (and agreed upon, out of band) to protect those resource servers. The client doesn't know or care about the details of the deployment, it just knows that it can get a token to work across various parts of the API. -- Justin On 9/30/2016 4:03 PM, Brian Campbell wrote: > Sending this to both the Tokbind and OAuth lists. > > There is text now in HTTPSTB that says that a TB ID must only be > conveyed to a different server, if the associated server explicitly > singles to do so. Specifically these two snippets, > > https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-5 > has > > However, such applications MUST only convey Token Binding IDs to > other servers if the server associated with a Token Binding ID > explicitly signals to do so, e.g., by returning an Include-Referred- > Token-Binding-ID HTTP response header field. > > > and > https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-7.3 > has > > Also, applications must take care to only reveal Token Binding IDs to > other endpoints if the server associated with a Token Binding ID > explicitly signals to do so, see Section 5 > "Implementation Considerations". > > > This seems like it might be problematic for token binding of OAuth > access tokens. Many/most OAuth flows don't begin at the resource sever > (token consumer) but at the authorization server (token provider) so > there's not an opportunity for such an explicit signal. And even when > a request is made to the resource sever (token consumer) without a > token or with a bad token, there isn't a redirect but rather a 40x is > returned (see https://tools.ietf.org/html/rfc6750#section-3 > ). > > The relationship between OAuth servers is much more of an implicit > thing in how the OAuth client application (different than a browser > client) interacts with those severs. And there's correlatable info > already flowing between the two so revealing a referred TB doesn't > make the privacy situation any different. But it can greatly improve > the security of the access tokens. > > Can the text in HTTPSTB be reworked slightly to allow for an implicit > okay or a prearrangement to reveal referred Token Binding IDs for > applications which are not web browsers? Otherwise OAuth clients will > have to ignore that MUST or a token (pun intended) but really > meaningless signal will have to be invented for OAuth (like maybe a > new auth-param with the WWW-Authenticate Response Header Field from > RFC 6750. > > > > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------98687EFF35F97A20E6C72B2F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

+1 to this.

I think we also need to keep in mind that it's incredibly common for an OAuth client to talk to multiple resource servers with a single token from a single authorization server that's been configured (and agreed upon, out of band) to protect those resource servers. The client doesn't know or care about the details of the deployment, it just knows that it can get a token to work across various parts of the API.

 -- Justin


On 9/30/2016 4:03 PM, Brian Campbell wrote:
Sending this to both the Tokbind and OAuth lists.

There is text now in HTTPSTB that says that a TB ID must only be conveyed to a different server, if the associated server explicitly singles to do so. Specifically these two snippets,

https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-5 has

   However, such applications MUST only convey Token Binding IDs to
   other servers if the server associated with a Token Binding ID
   explicitly signals to do so, e.g., by returning an Include-Referred-
   Token-Binding-ID HTTP response header field.


and https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-7.3 has

   Also, applications must take care to only reveal Token Binding IDs to
   other endpoints if the server associated with a Token Binding ID
   explicitly signals to do so, see Section 5
   "Implementation Considerations".


This seems like it might be problematic for token binding of OAuth access tokens. Many/most OAuth flows don't begin at the resource sever (token consumer) but at the authorization server (token provider) so there's not an opportunity for such an explicit signal. And even when a request is made to the resource sever (token consumer) without a token or with a bad token, there isn't a redirect but rather a 40x is returned (see https://tools.ietf.org/html/rfc6750#section-3).

The relationship between OAuth servers is much more of an implicit thing in how the OAuth client application (different than a browser client) interacts with those severs. And there's correlatable info already flowing between the two so revealing a referred TB doesn't make the privacy situation any different. But it can greatly improve the security of the access tokens.

Can the text in HTTPSTB be reworked slightly to allow for an implicit okay or a prearrangement to reveal referred Token Binding IDs for applications which are not web browsers? Otherwise OAuth clients will have to ignore that MUST or a token (pun intended) but really meaningless signal will have to be invented for OAuth (like maybe a new auth-param with the WWW-Authenticate Response Header Field from RFC 6750.



 






_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------98687EFF35F97A20E6C72B2F-- From nobody Mon Oct 3 09:24:55 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E8A1293FE for ; Mon, 3 Oct 2016 09:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 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=-2.996, 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 TsR0Tt9ESgk6 for ; Mon, 3 Oct 2016 09:24:52 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 BF9BE1293FF for ; Mon, 3 Oct 2016 09:24:51 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id i202so45441665ioi.2 for ; Mon, 03 Oct 2016 09:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n2sa6+iF5dVcSv7VLvy1chXywX7V2kAGp+itzdSel5o=; b=lC8xhAnvYVYSo4qVK5yocxRjz9+lr/BWGjQEAjuZiB8PUKSzIgj9Z/lMwsxCpPvXUo AsG2R1gOFduqxoR3qkoGBj7nuvDg3oVLbsWaJwxjOetECHXutYIT5AdpD1Q658N9lV/A ZhNqVARMUi+dg9e4oXiE4K1maagy8o3z+LHFYtKF7RH1Bv7CvPSFscpnJqGgYNPV2gm7 tgjMPHK3cL0x7TNxvnhf/hg0gTQ6I2znna99niZRPBJBvHaAlWBHqIblqUng8nRXVBvg np5QbBJxtcdmeWxlDBq3PGLvbIWg0OUAczx2r/G3cN+016MLWefyq5v2Ls6g5HP6NdVi vpIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n2sa6+iF5dVcSv7VLvy1chXywX7V2kAGp+itzdSel5o=; b=Uc/kq0S+cHd5FZ/0iLARPytKunSqNpzHqSSc+d+di9+v9kyv/U0krlDqyvP273wwtJ 6PoqaQYmq79UXowEjLulq63JxiMSwe7vdVXY5e+Kii8i7cKPoqJWaL5TcNUk2008B4oW q9OIWq8DXOLNmxB5cELUxtzA20180E2hhR/gLjCZx5bSqCaWvcMKxDluQD9SFpE6jOdg HfBTdvETpNNOLPxTip1GI7lOH779WUX2V3F1De5GK8BeFW1AsR2UEjLAILZ3bJKZVj7D KYEmfxRv34rGWIk9gHMf9/Zt0ZfSqkgMw9p+e5DjlnYoHSzYjbQX7wr+EwLBOWPo/TDK +mow== X-Gm-Message-State: AA6/9RkDeVu+EUXvrnaAoFnJQGz+OmIF0auHZhOkjYAriAwp3/tBrw/7O0KmHxhZGjNl3wnsWN6VW31JcqDqt/Hn X-Received: by 10.107.10.201 with SMTP id 70mr11072717iok.165.1475511890475; Mon, 03 Oct 2016 09:24:50 -0700 (PDT) MIME-Version: 1.0 References: <5f91fd28-1109-07bd-baf3-3f7c9e35ee31@sunet.se> In-Reply-To: From: Dirk Balfanz Date: Mon, 03 Oct 2016 16:24:39 +0000 Message-ID: To: John Bradley , Leif Johansson Content-Type: multipart/alternative; boundary=001a113eeab01865c6053df862f5 Archived-At: Cc: unbearable@ietf.org Subject: Re: [Unbearable] Seoul 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, 03 Oct 2016 16:24:54 -0000 --001a113eeab01865c6053df862f5 Content-Type: text/plain; charset=UTF-8 I'll be there as well. Dirk. On Sat, Oct 1, 2016 at 3:10 AM John Bradley wrote: > I am going. > > On Sep 29, 2016 12:44 PM, "Leif Johansson" wrote: > > > Are folks planning to come to Seoul so it makes sense to have a meeting? > > I think it makes sense to have a meeting if the key contributors > are in the room! > > Cheers Leif > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a113eeab01865c6053df862f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'll be there as well.

Dirk.
On Sat, Oct 1, 2016 at 3:10 AM= John Bradley <ve7jtb@ve7jtb.com> wrote:

I am going.


On Sep 29, 2016 12:44 PM, "Leif Johansson"= <leifj@sunet.se> wrote:

Are folks planning to come to Seoul so it makes sense to have a meeting?
I think it makes sense to have a meeting if the key contributors
are in the room!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers Leif

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/lis= tinfo/unbearable
_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/lis= tinfo/unbearable
--001a113eeab01865c6053df862f5-- From nobody Mon Oct 3 17:56:03 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CC71293E0 for ; Mon, 3 Oct 2016 17:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 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=-2.996, 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 lnHJdml-FYpa for ; Mon, 3 Oct 2016 17:55:59 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB3B128E19 for ; Mon, 3 Oct 2016 17:55:59 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id u124so26570770ywg.3 for ; Mon, 03 Oct 2016 17:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V+JYQFzg4plzLDbsrc0KnPyMd3O3JDurIRBjhENXaBM=; b=ZgzNf//dx70ZaTsU36aPdxDMI0KHfRH+4J2eCXDmbasi6l8tTdESxXiEByLbQVPv+Q l9bossjaAM3WXSCdjGkHxLJwqdVbXQpsRo6Dpqx/0lUT+9sldCmaziFcJ2N39FxLdtfZ U4rBlv5DHPYMz/o4RSKLhtWnnu/Pdv3Ic5hV7za5tRYByOttAyiYcN1keoH96TLe1W0R 0QdBiJRXhxQZsEwyD/On0CF8F+ZT8pp+Cq/kD45O6VV1OosGDQbGWY3PZGKNiOzzn+Pn /Au5cqJnjMdH8a5Ze2voDai57rXFxvK0FgtjH/ULG6lNlFfAUvo58dpi+WYptCspUXZn iuhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V+JYQFzg4plzLDbsrc0KnPyMd3O3JDurIRBjhENXaBM=; b=J4bDxuytKgc7YqsMt1uwk3FQwKMMasMJxSqyqo60sb3giox4dxADKg2zSBH3g2CCaO xT2G0Es/jJCS9o5RXXLn7/eFZHdfll3ddQI9sANTrm/EGstKjvAVFpR+hSLa3oFH1LcW QhCowHugY5JQEkG8SzcldjRLdlIZH1WqMLlcliaU5Ss8WyPCSxolhSQ3dX3aOhiDPinT kFgURAJnRp5Ej1pyzxrx/jD7Daw5LntA3VbB85ZCTgvK6T8H1YjHrcLwfctjm4yO1EyK gkThjrHXv7sY6dMwsz2M8fGxnJmjRes48/sXbWsGYrLQ715Ri/NXIaAv7teV7Zf0F8Pr lgOg== X-Gm-Message-State: AA6/9RkVoSjhO0NEWjr+sPVg9f7YIs7rop60jJWEGbg6SPG3p2IEBPWFfOfKODoeT4Csbuf21kjhdUva+3AjhrHS X-Received: by 10.13.253.134 with SMTP id n128mr810910ywf.20.1475542558975; Mon, 03 Oct 2016 17:55:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.253.7 with HTTP; Mon, 3 Oct 2016 17:55:38 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Mon, 3 Oct 2016 17:55:38 -0700 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=94eb2c06a37a148894053dff86cf Archived-At: Cc: Andrei Popov , IETF Tokbind WG Subject: Re: [Unbearable] Token Binding for 0-RTT connections X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 00:56:01 -0000 --94eb2c06a37a148894053dff86cf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I've uploaded a new draft: https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-01. The biggest change is an addition of a TLS extension to indicate that replay protections are in place. I also expanded the security considerations to describe what those replay protections might look like. If you think the replay protections should go elsewhere in the doc, I'm fine moving them around. My rationale for putting them in security considerations is that someone might come up with a way to implement replay protection that isn't in the doc, and I don't want to proscribe that they must use something from the doc if they come up with something better. (The new extension is normative.) Cheers, Nick On Thu, Sep 22, 2016 at 11:51 AM, Bill Cox wrote: > On Thu, Sep 22, 2016 at 11:12 AM, Andrei Popov > wrote: > >> My feedback for draft-nharper-0-rtt-token-binding-00 is that merely >> discussing 0-RTT TB=E2=80=99s weaker security properties in the security >> considerations is not sufficient. >> >> >> >> I think it would make sense to define the mitigation options we=E2=80=99= ve come >> up with so far, and some way to indicate the protection(s) that are in >> place, so that a peer can make an informed decision whether to use 0-RTT= TB >> or not. >> > > I agree. I also would prefer a mitigation techniques for 0-RTT security > concerns section in the TLS 1.3 doc, but that did not make it in. This i= s > pretty similar stuff: we need anti-replay on the server, key protection o= n > the client, and somehow we need to ensure signatures are fresh. When we > combine all that, I think we would have security very close to TB over > 1-RTT resumption. > --94eb2c06a37a148894053dff86cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,
I've uploaded a new draft: https://tools= .ietf.org/html/draft-nharper-0-rtt-token-binding-01. The biggest change= is an addition of a TLS extension to indicate that replay protections are = in place. I also expanded the security considerations to describe what thos= e replay protections might look like. If you think the replay protections s= hould go elsewhere in the doc, I'm fine moving them around. My rational= e for putting them in security considerations is that someone might come up= with a way to implement replay protection that isn't in the doc, and I= don't want to proscribe that they must use something from the doc if t= hey come up with something better. (The new extension is normative.)
<= div>Cheers,
Nick

On Thu, Sep 22, 2016 at 11:51 AM, Bill Cox <wa= ywardgeek@google.com> wrote:
On Thu, Sep 22, 2016 at 11:12 AM, Andrei Popov <An= drei.Popov@microsoft.com> wrote:

My feedback for draft-nharper-0-rtt-token-bind= ing-00 is that merely discussing 0-RTT TB=E2=80=99s weaker security propert= ies in the security considerations is not sufficient.<= /p>

=C2=A0

I think it would make sense to define the mitigatio= n options we=E2=80=99ve come up with so far, and some way to indicate the p= rotection(s) that are in place, so that a peer can make an informed decision whether to use 0-RTT TB or not.


I agree.=C2=A0 I also would prefer= a mitigation techniques for 0-RTT security concerns section in the TLS 1.3= doc, but that did not make it in.=C2=A0 This is pretty similar stuff: we n= eed anti-replay on the server, key protection on the client, and somehow we= need to ensure signatures are fresh.=C2=A0 When we combine all that, I thi= nk we would have security very close to TB over 1-RTT resumption.

--94eb2c06a37a148894053dff86cf-- From nobody Mon Oct 3 18:24:52 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B35127077 for ; Mon, 3 Oct 2016 18:24:49 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTXXHhve-T1s for ; Mon, 3 Oct 2016 18:24:48 -0700 (PDT) Received: from mail-qt0-f177.google.com (mail-qt0-f177.google.com [209.85.216.177]) (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 0CB4B127076 for ; Mon, 3 Oct 2016 18:24:48 -0700 (PDT) Received: by mail-qt0-f177.google.com with SMTP id 38so87887307qte.1 for ; Mon, 03 Oct 2016 18:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xOIG4Ha19/LwWKn9H0M9UtSDlVAfc+a2Cskwfh5J0qc=; b=mXBzHuA53lDXvaN+D4soL0tVYOKqNjGLIijYjgOv0gzRHQzVgoMgjIfdOnQF3ani9b JJ/DpIzXAMYRpQQELsmly73gb916tkyw7wrqTe4dsY3zg8RKeKTXE3dREakvwFp1vvLY 90v0hGucsjP3/SHYyFJJscFe7cxj5UZFrnozvea9B2PnQzqcKUjf2hNkUkCP8apZ2URz NpRZSXhl+vakchNX60MV+JE0b8LpKo+Nw6xYeCbAcbLsMy6SxrYoyfrwgfCIyARYbSyp y/eL1s4+n9BVb8iUIay8bOuldX5Lkg9rJ1WOu2BVvEOj3vJQt5p7VSsYYFGBwLssHD0E T9lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xOIG4Ha19/LwWKn9H0M9UtSDlVAfc+a2Cskwfh5J0qc=; b=igAs4Oe2lSSiP+sWcYjpEbpVljxxmvcDHifhK9rgKFax1Wgl0PUKMvJrH5E9J/LcAU mtpH8zzpe6R1qqgqc9H5rzSr71kk5LG2D9v4ysDo8NblOFzCWufbqts6vI70bgNVv9ti v3ZZlg22VYJ37kCe+Q5SwFeKqBO8F91gejL7FANFNaVDLdZs4XB+plhNqUnewwU41dG7 TFpBTyHONoj5F5+y4NjR40wXNNTVivAQqB9KByloqApza/Rki9UgKcj/w23TJK/FFIgA XSEgWPzoBxzugfULJoliWvPFbR8yK61GpMBaqzNJF9DGUOpgboeWRUhHVLkmVOdJwSY/ d1HQ== X-Gm-Message-State: AA6/9RnGqyenpKTTSmh2Wf5o+PyFXjiry2XxOUH1JEnYRuMOXVNId23T1y1XCgUrTnmRNmEjJCcWZ/nH83gRnw== X-Received: by 10.200.41.54 with SMTP id y51mr1012543qty.83.1475544227096; Mon, 03 Oct 2016 18:23:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Mon, 3 Oct 2016 18:23:46 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 4 Oct 2016 12:23:46 +1100 Message-ID: To: Nick Harper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Andrei Popov , IETF Tokbind WG , Bill Cox Subject: Re: [Unbearable] Token Binding for 0-RTT connections X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 01:24:50 -0000 I think that your analysis is a little mixed up here. It seems that you are assuming an attacker with only passive capabilities. If the attacker has access to the PSK, then it will be able to decrypt the entire connection unless a new (EC)DHE exchange is performed. That means that an active attacker can interject at any moment and use the connection from that point onward. Replay protection doesn't help in that case. On 4 October 2016 at 11:55, Nick Harper wrote: > Hi all, > I've uploaded a new draft: > https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-01. The > biggest change is an addition of a TLS extension to indicate that replay > protections are in place. I also expanded the security considerations to > describe what those replay protections might look like. If you think the > replay protections should go elsewhere in the doc, I'm fine moving them > around. My rationale for putting them in security considerations is that > someone might come up with a way to implement replay protection that isn'= t > in the doc, and I don't want to proscribe that they must use something fr= om > the doc if they come up with something better. (The new extension is > normative.) > Cheers, > Nick > > On Thu, Sep 22, 2016 at 11:51 AM, Bill Cox wrote= : >> >> On Thu, Sep 22, 2016 at 11:12 AM, Andrei Popov >> wrote: >>> >>> My feedback for draft-nharper-0-rtt-token-binding-00 is that merely >>> discussing 0-RTT TB=E2=80=99s weaker security properties in the securit= y >>> considerations is not sufficient. >>> >>> >>> >>> I think it would make sense to define the mitigation options we=E2=80= =99ve come >>> up with so far, and some way to indicate the protection(s) that are in >>> place, so that a peer can make an informed decision whether to use 0-RT= T TB >>> or not. >> >> >> I agree. I also would prefer a mitigation techniques for 0-RTT security >> concerns section in the TLS 1.3 doc, but that did not make it in. This = is >> pretty similar stuff: we need anti-replay on the server, key protection = on >> the client, and somehow we need to ensure signatures are fresh. When we >> combine all that, I think we would have security very close to TB over 1= -RTT >> resumption. > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > From nobody Mon Oct 3 18:38:15 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401D3128874 for ; Mon, 3 Oct 2016 18:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 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=-2.996, 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 IA1rEmrGM5yW for ; Mon, 3 Oct 2016 18:38:11 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B3D127078 for ; Mon, 3 Oct 2016 18:38:11 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id g192so119460372ywh.1 for ; Mon, 03 Oct 2016 18:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qJfieBHSjDAImFUj3NCMPPwf9PoJ/TWHJu3LqgTc+jA=; b=fkmviMWawWJJExPSMyayHim34HSSfemywo1XtZYy/kwOEz7SzUpGv7ycondD3gt9dd PHAh/rgF+W2k2rC7P5zbUJylfcUkvHC1oFyf5vxrVZNre4/riTdIGd/upJr/mDHUicGP QFRxq2Xc218ASFnAbfplz4FH2B7GUZOMU3xy8FeUC0M+ZR3rtr+NXBZqhSM0ryzQpTlo 2HOnJKT6GEaWVEB0bbCSuUPT4h5XzcZZDpv9FEhDoR77ezJp5mYli5oON6vwaYn3n2qu gxmW3WzY2SgaKV2Yhns6CBuemZ4JtGUCpv0EutzO3+2Am3izldQd3rkrbSG7kmSFesBs Or1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qJfieBHSjDAImFUj3NCMPPwf9PoJ/TWHJu3LqgTc+jA=; b=IuTC7ZFiFvEn4rpFC1Ml6td6/latag317BY6azX4+6fBQhhfyFY1eFpZhSPntdRKni 2GYfftfoBT7QWwlDBw7UuCJGyfBML6eLyI66TVo7QpTQ2St7f3147zQ1hTHmzeZjoAHC REcvGKuyQUrlchnq3rXGmKQJ3SBV6br+gLsjTK93oua5tvWFQXpJnZ+ZH4kAmbl5Omvt KOC5CJtOQg7zGB1OjOgtEylWBsm8QoAJo1mHbdhigoF+Wb+N+UUo+qM5RTNVaHeNXbUx kcHJPPntfuV+QSexzGu+zDqtTpx0xLE4vPIBX81HnQvy0GOo7fpjqtEEt0+INAec/VH2 P2mQ== X-Gm-Message-State: AA6/9RmlKXj+XIQhd89DUsn5ww+P3+n2GLHUXRTgkG20Y6rJnVj9ED/Fu1rEU1RjCvcl/9PxrN0A97bI4JZXSfwr X-Received: by 10.13.253.134 with SMTP id n128mr923090ywf.20.1475545090285; Mon, 03 Oct 2016 18:38:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.253.7 with HTTP; Mon, 3 Oct 2016 18:37:49 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Mon, 3 Oct 2016 18:37:49 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c06a37af53d17053e001c83 Archived-At: Cc: Andrei Popov , IETF Tokbind WG , Bill Cox Subject: Re: [Unbearable] Token Binding for 0-RTT connections X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 01:38:13 -0000 --94eb2c06a37af53d17053e001c83 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You're correct that if the attacker has access to the PSK, and it is used in the PSK-only key establishment mode, then the attacker can take over the connection. I was assuming that the PSK was for resumption and would only be used in psk_dhe_ke mode. I wasn't intending to consider an attacker with only passive capabilities. I briefly thought about the need for (EC)DHE when writing section 6.1, but it looks like I need to give more thought to pure PSK mode (and maybe the answer is require (EC)DHE). On Mon, Oct 3, 2016 at 6:23 PM, Martin Thomson wrote: > I think that your analysis is a little mixed up here. It seems that > you are assuming an attacker with only passive capabilities. > > If the attacker has access to the PSK, then it will be able to decrypt > the entire connection unless a new (EC)DHE exchange is performed. > That means that an active attacker can interject at any moment and use > the connection from that point onward. > > Replay protection doesn't help in that case. > > On 4 October 2016 at 11:55, Nick Harper wrote: > > Hi all, > > I've uploaded a new draft: > > https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-01. The > > biggest change is an addition of a TLS extension to indicate that repla= y > > protections are in place. I also expanded the security considerations t= o > > describe what those replay protections might look like. If you think th= e > > replay protections should go elsewhere in the doc, I'm fine moving them > > around. My rationale for putting them in security considerations is tha= t > > someone might come up with a way to implement replay protection that > isn't > > in the doc, and I don't want to proscribe that they must use something > from > > the doc if they come up with something better. (The new extension is > > normative.) > > Cheers, > > Nick > > > > On Thu, Sep 22, 2016 at 11:51 AM, Bill Cox > wrote: > >> > >> On Thu, Sep 22, 2016 at 11:12 AM, Andrei Popov > >> wrote: > >>> > >>> My feedback for draft-nharper-0-rtt-token-binding-00 is that merely > >>> discussing 0-RTT TB=E2=80=99s weaker security properties in the secur= ity > >>> considerations is not sufficient. > >>> > >>> > >>> > >>> I think it would make sense to define the mitigation options we=E2=80= =99ve come > >>> up with so far, and some way to indicate the protection(s) that are i= n > >>> place, so that a peer can make an informed decision whether to use > 0-RTT TB > >>> or not. > >> > >> > >> I agree. I also would prefer a mitigation techniques for 0-RTT securi= ty > >> concerns section in the TLS 1.3 doc, but that did not make it in. Thi= s > is > >> pretty similar stuff: we need anti-replay on the server, key protectio= n > on > >> the client, and somehow we need to ensure signatures are fresh. When = we > >> combine all that, I think we would have security very close to TB over > 1-RTT > >> resumption. > > > > > > > > _______________________________________________ > > Unbearable mailing list > > Unbearable@ietf.org > > https://www.ietf.org/mailman/listinfo/unbearable > > > --94eb2c06a37af53d17053e001c83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You're correct that if the attacker has access to the = PSK, and it is used in the PSK-only key establishment mode, then the attack= er can take over the connection. I was assuming that the PSK was for resump= tion and would only be used in psk_dhe_ke mode. I wasn't intending to c= onsider an attacker with only passive capabilities. I briefly thought about= the need for (EC)DHE when writing section 6.1, but it looks like I need to= give more thought to pure PSK mode (and maybe the answer is require (EC)DH= E).

On Mon, = Oct 3, 2016 at 6:23 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
I think that your ana= lysis is a little mixed up here.=C2=A0 It seems that
you are assuming an attacker with only passive capabilities.

If the attacker has access to the PSK, then it will be able to decrypt
the entire connection unless a new (EC)DHE exchange is performed.
That means that an active attacker can interject at any moment and use
the connection from that point onward.

Replay protection doesn't help in that case.

On 4 October 2016 at 11:55, Nick Harper <nharper@google.com> wrote:
> Hi all,
> I've uploaded a new draft:
> https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-01. The
> biggest change is an addition of a TLS extension to indicate that repl= ay
> protections are in place. I also expanded the security considerations = to
> describe what those replay protections might look like. If you think t= he
> replay protections should go elsewhere in the doc, I'm fine moving= them
> around. My rationale for putting them in security considerations is th= at
> someone might come up with a way to implement replay protection that i= sn't
> in the doc, and I don't want to proscribe that they must use somet= hing from
> the doc if they come up with something better. (The new extension is > normative.)
> Cheers,
> Nick
>
> On Thu, Sep 22, 2016 at 11:51 AM, Bill Cox <waywardgeek@google.com> wrote:
>>
>> On Thu, Sep 22, 2016 at 11:12 AM, Andrei Popov
>> <Andrei.Popov@mic= rosoft.com> wrote:
>>>
>>> My feedback for draft-nharper-0-rtt-token-binding-00 is t= hat merely
>>> discussing 0-RTT TB=E2=80=99s weaker security properties in th= e security
>>> considerations is not sufficient.
>>>
>>>
>>>
>>> I think it would make sense to define the mitigation options w= e=E2=80=99ve come
>>> up with so far, and some way to indicate the protection(s) tha= t are in
>>> place, so that a peer can make an informed decision whether to= use 0-RTT TB
>>> or not.
>>
>>
>> I agree.=C2=A0 I also would prefer a mitigation techniques for 0-R= TT security
>> concerns section in the TLS 1.3 doc, but that did not make it in.= =C2=A0 This is
>> pretty similar stuff: we need anti-replay on the server, key prote= ction on
>> the client, and somehow we need to ensure signatures are fresh.=C2= =A0 When we
>> combine all that, I think we would have security very close to TB = over 1-RTT
>> resumption.
>
>
>
> __________________= _____________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbe= arable
>

--94eb2c06a37af53d17053e001c83-- From nobody Tue Oct 4 00:11:17 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709821295D6 for ; Tue, 4 Oct 2016 00:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] 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 oG6R-6qpG5vS for ; Tue, 4 Oct 2016 00:11:13 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6AC1295D5 for ; Tue, 4 Oct 2016 00:11:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 6A8B416116; Tue, 4 Oct 2016 10:11:11 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id hMGcadW9JQHT; Tue, 4 Oct 2016 10:11:10 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id CA89A2310; Tue, 4 Oct 2016 10:11:10 +0300 (EEST) Date: Tue, 4 Oct 2016 10:11:05 +0300 From: Ilari Liusvaara To: Nick Harper Message-ID: <20161004071105.GA22592@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: Andrei Popov , IETF Tokbind WG , Bill Cox Subject: Re: [Unbearable] Token Binding for 0-RTT connections X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 07:11:15 -0000 On Mon, Oct 03, 2016 at 05:55:38PM -0700, Nick Harper wrote: > Hi all, > I've uploaded a new draft: > https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-01. The > biggest change is an addition of a TLS extension to indicate that replay > protections are in place. I also expanded the security considerations to > describe what those replay protections might look like. If you think the > replay protections should go elsewhere in the doc, I'm fine moving them > around. My rationale for putting them in security considerations is that > someone might come up with a way to implement replay protection that isn't > in the doc, and I don't want to proscribe that they must use something from > the doc if they come up with something better. (The new extension is > normative.) > Cheers, > Nick Some points: - The extracted value from EKM is presumably a binder, so it needs to be at least as long as the underlying PRF-hash. - Section 4.1 seems pretty misleading. It seems to imply that the problem is dealing with possible race condition. This is wrong, the only way prolbems even remotely like these can happen is if the client explicitly splits a request between 0-RTT and 1-RTT[1]. [1] 0-RTT effectively suspends the handshake until it is complete. There is no way for handshake to complete while 0-RTT is still in progress. -Ilari From nobody Tue Oct 4 17:35:29 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F51129444 for ; Tue, 4 Oct 2016 17:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 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=-2.996, 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 oWCha08pw8vZ for ; Tue, 4 Oct 2016 17:35:25 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F5D3129440 for ; Tue, 4 Oct 2016 17:35:25 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id t193so67708589ywc.2 for ; Tue, 04 Oct 2016 17:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MMiY/wNER0ccOrxtEePthdND1kLVR90hnrnSYICRqmc=; b=pQFrp3MwXiBbG5feZrvBr3MFF5UJcOSmCDmlLBnHDAlQWfWF0nrO7wzeGWpbPblhOB 3RyFHwkLh4TSxDHR304AM2VlB3VBbYBrB1QrjjKOMaCR9Frt1GjIsWHrVLtIg98yaj74 WPgdNRm4eNeUDrOCAwt3d8k5HFc4PDTqNjb8q5jMQH925NMflTblHwTOdJhoCN/8SRjT M5MN6+bsUegRlKGka30ck8YXiYVWB0+JPkWM5sSD7sYPmKVwYqnhDJJJsKUzPJ3xdw6/ oV2OWb8XjH7ZmsfCitWQdT+93A3sCJa5Uh60wqjdK7QySmmkfgXTDDYfvHpWtf44x9U3 E07Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MMiY/wNER0ccOrxtEePthdND1kLVR90hnrnSYICRqmc=; b=jf9qdjhjclBwBLnbsFUv3IIopHpY7IcvAXxX+z1RzaSGgqT9rkZXws3YvWNH3KkQ6m Mn/9myRctmLVrMH4pWByrauskItGllJHZvmVC9GTMnmCnANemx0NhMqs6+0C7v9iGI3u GONrofLk18XY8CQRkEqL6QT9szUQGqViJ7IZYuMaUUdTYJGwZDi8OumiHbzC1W4FVdYb 0Oe6R1HM/TT1rRHpgA7ApDyr606hubRue4E17OoCU1/nGoyF/saUtqnS63E+ci/kX+x1 4hv1LNuuVSHmdpdnOPloeHBgD705YqXl/0UzFEbQGQ10KWHo7YMnCofGthigkKPBnCl+ 2cJQ== X-Gm-Message-State: AA6/9RlFesff3uhYwn7pLVHljM5kYuPAAiERo8mGf5qXeXP6BKBLFG9d9O0Fg9VW7Ow/dm6PfLrMvuIzeaAukcLW X-Received: by 10.129.116.84 with SMTP id p81mr4766691ywc.7.1475627724470; Tue, 04 Oct 2016 17:35:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.253.7 with HTTP; Tue, 4 Oct 2016 17:35:03 -0700 (PDT) In-Reply-To: <20161004071105.GA22592@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161004071105.GA22592@LK-Perkele-V2.elisa-laajakaista.fi> From: Nick Harper Date: Tue, 4 Oct 2016 17:35:03 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1141cd9a56ec8a053e135a54 Archived-At: Cc: Andrei Popov , IETF Tokbind WG , Bill Cox Subject: Re: [Unbearable] Token Binding for 0-RTT connections X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 00:35:28 -0000 --001a1141cd9a56ec8a053e135a54 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 4, 2016 at 12:11 AM, Ilari Liusvaara wrote: > On Mon, Oct 03, 2016 at 05:55:38PM -0700, Nick Harper wrote: > > Hi all, > > I've uploaded a new draft: > > https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-01. The > > biggest change is an addition of a TLS extension to indicate that replay > > protections are in place. I also expanded the security considerations to > > describe what those replay protections might look like. If you think the > > replay protections should go elsewhere in the doc, I'm fine moving them > > around. My rationale for putting them in security considerations is that > > someone might come up with a way to implement replay protection that > isn't > > in the doc, and I don't want to proscribe that they must use something > from > > the doc if they come up with something better. (The new extension is > > normative.) > > Cheers, > > Nick > > Some points: > > - The extracted value from EKM is presumably a binder, so it needs to > be at least as long as the underlying PRF-hash. This draft uses the same length EKM as draft-ietf-tokbind-protocol (which is fixed at 32 bytes). Does this mean that draft-ietf-tokbind-protocol should use a longer EKM value if the TLS connection is using a larger PRF hash? - Section 4.1 seems pretty misleading. It seems to imply that the > problem is dealing with possible race condition. This is wrong, > the only way prolbems even remotely like these can happen is if > the client explicitly splits a request between 0-RTT and 1-RTT[1]. > The problem I'm addressing in section 4.1 is one of visibility of the application (where it's processing Token Binding) into the state of the TLS connection, not a race condition. Of course both the client and server TLS stacks know whether the data sent/received is 0-RTT or 1-RTT. At some level in the application, a decision is made whether the application data to write can be sent 0-RTT, and that part will have the necessary visibility. However, above that point there's no reason for it to be visible, and that's where the Token Binding header is added to the request. A sane client would likely send the entire HTTP request in early data, but a pathological client could send just the first few bytes of the HTTP request in early data, then drive the handshake to completion, and then send the rest of the HTTP request. (Or a client might be buffering messages to send, and not know at the time the message is prepared whether it will be sent in early data or not.) A server receiving such a request would need to keep track of when in the HTTP request the client sent switched from being sent 0-RTT vs 1-RTT so it can use the correct EKM to verify the TokenBindingMessage. This is what I meant by a synchronization issue - perhaps I should have described this problem differently or in more depth. > > > [1] 0-RTT effectively suspends the handshake until it is complete. > There is no way for handshake to complete while 0-RTT is still in > progress. > > > -Ilari > --001a1141cd9a56ec8a053e135a54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 4, 2016 at 12:11 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
O= n Mon, Oct 03, 2016 at 05:55:38PM -0700, Nick Harper wrote:
> Hi all,
> I've uploaded a new draft:
> https://tools.ietf.org/html/dr<= wbr>aft-nharper-0-rtt-token-binding-01. The
> biggest change is an addition of a TLS extension to indicate that repl= ay
> protections are in place. I also expanded the security considerations = to
> describe what those replay protections might look like. If you think t= he
> replay protections should go elsewhere in the doc, I'm fine moving= them
> around. My rationale for putting them in security considerations is th= at
> someone might come up with a way to implement replay protection that i= sn't
> in the doc, and I don't want to proscribe that they must use somet= hing from
> the doc if they come up with something better. (The new extension is > normative.)
> Cheers,
> Nick

Some points:

- The extracted value from EKM is presumably a binder, so it needs to
=C2=A0 be at least as long as the underlying PRF-hash.=C2=A0

=C2=A0This draft uses the same length EKM as draft-ietf-t= okbind-protocol (which is fixed at 32 bytes). Does this mean that draft-iet= f-tokbind-protocol should use a longer EKM value if the TLS connection is u= sing a larger PRF hash?

- Section 4.1 seems pretty misleading. It seems to imply that the
=C2=A0 problem is dealing with possible race condition. This is wrong,
=C2=A0 the only way prolbems even remotely like these can happen is if
=C2=A0 the client explicitly splits a request between 0-RTT and 1-RTT[1].

The problem I'm addressing in sectio= n 4.1 is one of visibility of the application (where it's processing To= ken Binding) into the state of the TLS connection, not a race condition. Of= course both the client and server TLS stacks know whether the data sent/re= ceived is 0-RTT or 1-RTT. At some level in the application, a decision is m= ade whether the application data to write can be sent 0-RTT, and that part = will have the necessary visibility. However, above that point there's n= o reason for it to be visible, and that's where the Token Binding heade= r is added to the request. A sane client would likely send the entire HTTP = request in early data, but a pathological client could send just the first = few bytes of the HTTP request in early data, then drive the handshake to co= mpletion, and then send the rest of the HTTP request. (Or a client might be= buffering messages to send, and not know at the time the message is prepar= ed whether it will be sent in early data or not.) A server receiving such a= request would need to keep track of when in the HTTP request the client se= nt switched from being sent 0-RTT vs 1-RTT so it can use the correct EKM to= verify the TokenBindingMessage. This is what I meant by a synchronization = issue - perhaps I should have described this problem differently or in more= depth.


[1] 0-RTT effectively suspends the handshake until it is complete.
There is no way for handshake to complete while 0-RTT is still in
progress.


-Ilari

--001a1141cd9a56ec8a053e135a54-- From nobody Fri Oct 7 16:53:22 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B806129483 for ; Fri, 7 Oct 2016 16:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 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=-2.996, 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 CdKmpYYYomEY for ; Fri, 7 Oct 2016 16:53:18 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920A8129431 for ; Fri, 7 Oct 2016 16:53:17 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id w3so13942839ywg.1 for ; Fri, 07 Oct 2016 16:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=yZ8dnD7l8hx2JF3buoeGf5EiPISDNYzu223TiCLaSz4=; b=e7Xy+Sv1P6m5LlO469tTBK4fuSx0pXrya3xHDkaoihhI7mPqCUZ15KatGjfk3F7y0J Wty7e582yoADf2KTpXs1n9fDUG/NMiY0BHs94LeSna3Ehd0FQNUZ1BqNxfZ7+2/9WqUq p1+g17b2vq9f8ApWZ+sDvJtRjkxqYMZx4m6jv+rv3FQIsItwAtIP9fsAUk1cl21EfuU5 JJPSinLDZPPdnCXmCuLxpDb+z8DN99Dr23RlG97cV5gfUCAIuxQGouEhfh2smTuvVxRJ SSvJdGwuyRat2ZjXNGxGuROyaRw9NIVIf0TYMqy+k1dR7Kqpq4rWZcGo2pepfJCrZFvS Ycgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yZ8dnD7l8hx2JF3buoeGf5EiPISDNYzu223TiCLaSz4=; b=aLCUvZ8UcAYSB49ujTe2HSXqKOorgmyQ1u/Mae0MloOBSxn5+EW5bHZ7y69X+BGJGM KcgZlyk4odi6KaA21IXUKIBj0UcVdIQZhpFIElA4NAc2lw6I5pPBWgZKt7bSyAMOM/23 vebb1/67JkE2TTPJJnfRLB7MNjBPASN5h59CptCmHOY3lTDHY88fJRpoJs+vWczGzEKg STI6dIBtUJ/v0BwAxeSD3jO/Z6inOCSl8unm41ZPUPX+UACLceTLS5ME6xhYzKW97Qxn 0+TQSdtC8ZDy6KuU3j5b2xpuHLEtICqTuWNFeB3DB7s1xJX3e4qyUn3kIiGYSrU6wuW2 tM2A== X-Gm-Message-State: AA6/9RnKIwy0rHwnDaJ7dWqbTL5RFKU+2rtSQXH7d3viWZngE4caSxpiwoFXBkmAqJ6iwZtbCYvo38FWjV1kJm8K X-Received: by 10.13.231.3 with SMTP id q3mr19074291ywe.242.1475884396533; Fri, 07 Oct 2016 16:53:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.253.7 with HTTP; Fri, 7 Oct 2016 16:52:56 -0700 (PDT) From: Nick Harper Date: Fri, 7 Oct 2016 16:52:56 -0700 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary=94eb2c0805042fced9053e4f1de6 Archived-At: Subject: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 07 Oct 2016 23:53:20 -0000 --94eb2c0805042fced9053e4f1de6 Content-Type: text/plain; charset=UTF-8 Right now, the Token Binding documents specify how the negotiation extension should interact with the Renegotiation Indication (RFC 5746) extension, but it could be more clear about which EKM value to use in a TokenBinding after a renegotiation occurs. Section 3.3 of TBPROTO specifies that the EKM is obtained from the current TLS connection, but RFC 5705 states that the exporter is associated with a TLS session (more specifically, a set of SecurityParameters). If we assume that TBPROTO means TLS session, then after a renegotiation occurs, the EKM value changes since the SecurityParameters changed. An alternate reading is that the EKM from the first TLS session of the TLS connection is used. For the sake of ease of implementation on client and server, I think it would be better if Token Binding uses this second reading, where the EKM to sign does not change over the lifetime of the connection. I have uploaded a pull request to tweak the language to more clearly specify this: https://github.com/TokenBinding/Internet-Drafts/pull/72. If the EKM value can change over the course of a connection, then the client and server both have to check what the EKM value is each time before using it. Both peers also have to somehow guarantee that between when they get the EKM value and when they send or receive the message using that value that no renegotiation has taken place. I think this is easy enough to guarantee for HTTP/1.1 application data, but Token Binding is agnostic of the application layer protocol. Imagine some other protocol is using Token Binding and renegotiation, and that protocol is multiplexed (like h2). In this case, one application thread could read the EKM value, prepare a TokenBinding message, and send it, while another thread does a renegotiation on the same connection between the first thread reading the EKM value and sending the signature of it. There are probably other strange interleavings of token-bound messages and renegotiations that I haven't thoroughly considered, but using the same EKM for the connection solves those problems. Does this seem like a reasonable clarification? Cheers, Nick --94eb2c0805042fced9053e4f1de6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right now, the Token Binding documents specify how the neg= otiation extension should interact with the Renegotiation Indication (RFC 5= 746) extension, but it could be more clear about which EKM value to use in = a TokenBinding after a renegotiation occurs.

Section 3.3= of TBPROTO specifies that the EKM is obtained from the current TLS connect= ion, but RFC 5705 states that the exporter is associated with a TLS session= (more specifically, a set of SecurityParameters). If we assume that TBPROT= O means TLS session, then after a renegotiation occurs, the EKM value chang= es since the SecurityParameters changed. An alternate reading is that the E= KM from the first TLS session of the TLS connection is used.

=
For the sake of ease of implementation on client and server, I t= hink it would be better if Token Binding uses this second reading, where th= e EKM to sign does not change over the lifetime of the connection. I have u= ploaded a pull request to tweak the language to more clearly specify this: = https:/= /github.com/TokenBinding/Internet-Drafts/pull/72.

<= div>If the EKM value can change over the course of a connection, then the c= lient and server both have to check what the EKM value is each time before = using it. Both peers also have to somehow guarantee that between when they = get the EKM value and when they send or receive the message using that valu= e that no renegotiation has taken place. I think this is easy enough to gua= rantee for HTTP/1.1 application data, but Token Binding is agnostic of the = application layer protocol. Imagine some other protocol is using Token Bind= ing and renegotiation, and that protocol is multiplexed (like h2). In this = case, one application thread could read the EKM value, prepare a TokenBindi= ng message, and send it, while another thread does a renegotiation on the s= ame connection between the first thread reading the EKM value and sending t= he signature of it. There are probably other strange interleavings of token= -bound messages and renegotiations that I haven't thoroughly considered= , but using the same EKM for the connection solves those problems.

Does this seem like a reasonable clarification?
<= div>Cheers,
Nick
--94eb2c0805042fced9053e4f1de6-- From nobody Sun Oct 9 17:15:10 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFBD129432 for ; Sun, 9 Oct 2016 17:15:09 -0700 (PDT) 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 O6XlGm-Ne6mJ for ; Sun, 9 Oct 2016 17:15:06 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0119.outbound.protection.outlook.com [104.47.42.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56F81293FF for ; Sun, 9 Oct 2016 17:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZNwiDO5fmeCDdMlObvRpda5/tjggAFwKoFddUMX+Rzo=; b=S7pOYMD6HRGpJZpcqIUnqBficxZnWGMExYIIhFnUziV6sp55GDEvcAEGJLAkCfVwqLOwhT3p3rzaYjNgYDNd/a4heCyyt++UMC8JhvtL8ti1Lli17FV54bdh5rZR8IYG4I2Yfpfug9fnPMmpzG0lXj4ykr4v8e7UmIf//sEfOis= 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.649.16; Mon, 10 Oct 2016 00:15: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.0649.027; Mon, 10 Oct 2016 00:15:05 +0000 From: Andrei Popov To: Nick Harper , IETF Tokbind WG Thread-Topic: [Unbearable] Clarifying Token Binding behavior with renegotiation Thread-Index: AQHSIPYAfU8tAUm590uf08aV6ED2raCgzRRQ Date: Mon, 10 Oct 2016 00:15:05 +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: [50.46.229.189] x-ms-office365-filtering-correlation-id: 6b670fe2-2fc2-4e11-5813-08d3f0a27c87 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 7:D7X2lBoQVYhp7tzcxEzC6OTUrIJFacD9dmxqJUkrCuOhPeJqyI4pIhCdZiPtzpFhdaXcOFfSj+2Y9XZgCID391WdzOaxmHqe+Xt2/CKkPFlAEkWE1SP9ltCIPXwSe7Gyh8QawNTMYfuqC98f7MzKaoGCaTdOfWf5ERlVpudW4ClPS8Z/iYa7E4fGHrciAeFHfqt8MVZQ5l1ud5xfEWkyTRav9Da9ytgB1P55ZZ2Zdc+7NC7ssR4/ckGHP8ImezoIZ/kpNcM61lF1+4bPOsthdl7km5i4rdOza8kp1Ff0pE6UqSceNkY+C7tnwjzX9e2MtN06aJc6v6xQEOJE266r3A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0842; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(35073007944872)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 0091C8F1EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(377454003)(2950100002)(101416001)(3660700001)(5001770100001)(790700001)(189998001)(87936001)(3846002)(9686002)(107886002)(97736004)(586003)(10090500001)(19609705001)(8990500004)(74316002)(10290500002)(5005710100001)(86612001)(102836003)(6116002)(2906002)(106116001)(122556002)(86362001)(7696004)(105586002)(106356001)(5660300001)(3280700002)(19617315012)(10400500002)(99286002)(5002640100001)(81166006)(92566002)(68736007)(81156014)(8676002)(76176999)(54356999)(7736002)(19580395003)(77096005)(7906003)(66066001)(33656002)(19625215002)(7846002)(19580405001)(15975445007)(16236675004)(8936002)(19300405004)(76576001)(2900100001)(11100500001)(50986999)(9326002); 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_CY1PR0301MB08422C8E25C1D9344712092F8CDB0CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2016 00:15:05.1422 (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] Clarifying Token Binding behavior with renegotiation 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, 10 Oct 2016 00:15:09 -0000 --_000_CY1PR0301MB08422C8E25C1D9344712092F8CDB0CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmljaywNCg0KDQrDmCAgU2VjdGlvbiAzLjMgb2YgVEJQUk9UTyBzcGVjaWZpZXMgdGhhdCB0 aGUgRUtNIGlzIG9idGFpbmVkIGZyb20gdGhlIGN1cnJlbnQgVExTIGNvbm5lY3Rpb24sIGJ1dCBS RkMgNTcwNSBzdGF0ZXMgdGhhdCB0aGUgZXhwb3J0ZXIgaXMgYXNzb2NpYXRlZCB3aXRoIGEgVExT IHNlc3Npb24gKG1vcmUgc3BlY2lmaWNhbGx5LCBhIHNldCBvZiBTZWN1cml0eVBhcmFtZXRlcnMp LiBJZiB3ZSBhc3N1bWUgdGhhdCBUQlBST1RPIG1lYW5zIFRMUyBzZXNzaW9uLCB0aGVuIGFmdGVy IGEgcmVuZWdvdGlhdGlvbiBvY2N1cnMsIHRoZSBFS00gdmFsdWUgY2hhbmdlcyBzaW5jZSB0aGUg U2VjdXJpdHlQYXJhbWV0ZXJzIGNoYW5nZWQuIEFuIGFsdGVybmF0ZSByZWFkaW5nIGlzIHRoYXQg dGhlIEVLTSBmcm9tIHRoZSBmaXJzdCBUTFMgc2Vzc2lvbiBvZiB0aGUgVExTIGNvbm5lY3Rpb24g aXMgdXNlZC4NCg0KSXQgaXMgdHJ1ZSB0aGF0IGluIFRMUywgYSBzZXNzaW9uIGNhbiBvdXRsYXN0 IGEgY29ubmVjdGlvbiwgYW5kIGFsc28gYSBjb25uZWN0aW9uIGNhbiBvdXRsYXN0IGEgc2Vzc2lv bi4gVGhlIGludGVudCBpbiB0aGUgVEJQUk9UTyBJLUQgaXMgdGhhdCB0aGUgY3VycmVudCBFS00g YmUgdXNlZCwgdGhhdCBpcywgdGhlIG9uZSBmcm9tIHRoZSBsYXRlc3QgVExTIHNlc3Npb24gb3Ig Y29ubmVjdGlvbi4gSSBhZ3JlZSB0aGF0IHRoZSBleGlzdGluZyBsYW5ndWFnZSBpbiB0aGUgSS1E IGlzIG92ZXItc2ltcGxpZmllZCBhbmQgZG9lcyBub3QgZnVsbHkgY29udmV5IHRoaXM7IHdpbGwg Y2xhcmlmeSBpbiB0aGUgbmV4dCByZXZpc2lvbi4NCg0KDQrDmCAgRm9yIHRoZSBzYWtlIG9mIGVh c2Ugb2YgaW1wbGVtZW50YXRpb24gb24gY2xpZW50IGFuZCBzZXJ2ZXIsIEkgdGhpbmsgaXQgd291 bGQgYmUgYmV0dGVyIGlmIFRva2VuIEJpbmRpbmcgdXNlcyB0aGlzIHNlY29uZCByZWFkaW5nLCB3 aGVyZSB0aGUgRUtNIHRvIHNpZ24gZG9lcyBub3QgY2hhbmdlIG92ZXIgdGhlIGxpZmV0aW1lIG9m IHRoZSBjb25uZWN0aW9uLg0KDQpUaGVyZSBhcmUgYSBjb3VwbGUgb2YgcmVhc29ucyBJIHRoaW5r IHdlIHNob3VsZCB1c2UgdGhlIGN1cnJlbnQgRUtNOg0KDQoxLiAgICAgIFRoaXMgZW5zdXJlcyB0 aGF0IGEgYm91bmQgdG9rZW4gaXMgbm90IHJlcGxheWVkIG9uIGEgbmV3bHkgZXN0YWJsaXNoZWQg c2Vzc2lvbiwgZXZlbiBpZiB0aGlzIG5ldyBzZXNzaW9uIGhhcyBiZWVuIGVzdGFibGlzaGVkIG9u IGFuIGV4aXN0aW5nIFRMUyBjb25uZWN0aW9uOw0KDQoyLiAgICAgIFRoaXMgYXZvaWRzIHRoZSBy ZXF1aXJlbWVudCB0aGF0IHRoZSBjbGllbnQgYW5kIHNlcnZlciByZW1lbWJlciB0aGUgZmlyc3Qg RUtNIHZhbHVlIGZvciBlYWNoIGNvbm5lY3Rpb24sIHNvIHRoYXQgdGhleSBjYW4ga2VlcCB1c2lu ZyBpdCBhZnRlciBzdWJzZXF1ZW50IHJlbmVnb3RpYXRpb24ocykuDQoNCg0Kw5ggIElmIHRoZSBF S00gdmFsdWUgY2FuIGNoYW5nZSBvdmVyIHRoZSBjb3Vyc2Ugb2YgYSBjb25uZWN0aW9uLCB0aGVu IHRoZSBjbGllbnQgYW5kIHNlcnZlciBib3RoIGhhdmUgdG8gY2hlY2sgd2hhdCB0aGUgRUtNIHZh bHVlIGlzIGVhY2ggdGltZSBiZWZvcmUgdXNpbmcgaXQuDQoNCklNSE8gaXTigJlzIGEgZ29vZCB0 aGluZyB3aGVuIGJvdGggY2xpZW50IGFuZCBzZXJ2ZXIgbWFrZSBzdXJlIHRoZSBzaWduYXR1cmUg cHJvcGVybHkgYmluZHMgdGhlIHRva2VuIHRvIHRoZSBtb3N0IGN1cnJlbnQgVExTIHNlY3JldC4g QSBsb3Qgb2Ygc2VydmVyIGFwcHMgYXJlIHN0YXRlbGVzcyBhbmQgZG9u4oCZdCB0cmFjayBUTFMg c2Vzc2lvbnMgYW5kIGNvbm5lY3Rpb25zLCBidXQgdGhleSBjYW4gYWx3YXlzIHF1ZXJ5IHRoZSBj dXJyZW50IEVLTSB2YWx1ZSBmcm9tIHRoZSBUTFMgbGF5ZXIuIE1ha2luZyBzdWNoIGFwcHMgYXdh cmUgb2YgbW9yZSBUTFMgY29udGV4dCB3b3VsZCBhZGQgc2lnbmlmaWNhbnQgY29tcGxleGl0eS4N Cg0KDQrDmCAgSW1hZ2luZSBzb21lIG90aGVyIHByb3RvY29sIGlzIHVzaW5nIFRva2VuIEJpbmRp bmcgYW5kIHJlbmVnb3RpYXRpb24sIGFuZCB0aGF0IHByb3RvY29sIGlzIG11bHRpcGxleGVkIChs aWtlIGgyKS4gSW4gdGhpcyBjYXNlLCBvbmUgYXBwbGljYXRpb24gdGhyZWFkIGNvdWxkIHJlYWQg dGhlIEVLTSB2YWx1ZSwgcHJlcGFyZSBhIFRva2VuQmluZGluZyBtZXNzYWdlLCBhbmQgc2VuZCBp dCwgd2hpbGUgYW5vdGhlciB0aHJlYWQgZG9lcyBhIHJlbmVnb3RpYXRpb24gb24gdGhlIHNhbWUg Y29ubmVjdGlvbiBiZXR3ZWVuIHRoZSBmaXJzdCB0aHJlYWQgcmVhZGluZyB0aGUgRUtNIHZhbHVl IGFuZCBzZW5kaW5nIHRoZSBzaWduYXR1cmUgb2YgaXQuDQoNClRoaXMgY29tcGxpY2F0aW9uIGdl bmVyYWxseSBleGlzdHMgZm9yIG11bHRpcGxleGVkIHByb3RvY29scyBydW5uaW5nIG92ZXIgVExT PD0xLjIgYW5kIHVzaW5nIEVLTXM7IGl0IGlzIG5vdCBzcGVjaWZpYyB0byBUb2tlbiBCaW5kaW5n Lg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBVbmJlYXJhYmxlIFttYWlsdG86dW5iZWFy YWJsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTmljayBIYXJwZXINClNlbnQ6IEZy aWRheSwgT2N0b2JlciA3LCAyMDE2IDQ6NTMgUE0NClRvOiBJRVRGIFRva2JpbmQgV0cgPHVuYmVh cmFibGVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbVW5iZWFyYWJsZV0gQ2xhcmlmeWluZyBUb2tlbiBC aW5kaW5nIGJlaGF2aW9yIHdpdGggcmVuZWdvdGlhdGlvbg0KDQpSaWdodCBub3csIHRoZSBUb2tl biBCaW5kaW5nIGRvY3VtZW50cyBzcGVjaWZ5IGhvdyB0aGUgbmVnb3RpYXRpb24gZXh0ZW5zaW9u IHNob3VsZCBpbnRlcmFjdCB3aXRoIHRoZSBSZW5lZ290aWF0aW9uIEluZGljYXRpb24gKFJGQyA1 NzQ2KSBleHRlbnNpb24sIGJ1dCBpdCBjb3VsZCBiZSBtb3JlIGNsZWFyIGFib3V0IHdoaWNoIEVL TSB2YWx1ZSB0byB1c2UgaW4gYSBUb2tlbkJpbmRpbmcgYWZ0ZXIgYSByZW5lZ290aWF0aW9uIG9j Y3Vycy4NCg0KU2VjdGlvbiAzLjMgb2YgVEJQUk9UTyBzcGVjaWZpZXMgdGhhdCB0aGUgRUtNIGlz IG9idGFpbmVkIGZyb20gdGhlIGN1cnJlbnQgVExTIGNvbm5lY3Rpb24sIGJ1dCBSRkMgNTcwNSBz dGF0ZXMgdGhhdCB0aGUgZXhwb3J0ZXIgaXMgYXNzb2NpYXRlZCB3aXRoIGEgVExTIHNlc3Npb24g KG1vcmUgc3BlY2lmaWNhbGx5LCBhIHNldCBvZiBTZWN1cml0eVBhcmFtZXRlcnMpLiBJZiB3ZSBh c3N1bWUgdGhhdCBUQlBST1RPIG1lYW5zIFRMUyBzZXNzaW9uLCB0aGVuIGFmdGVyIGEgcmVuZWdv dGlhdGlvbiBvY2N1cnMsIHRoZSBFS00gdmFsdWUgY2hhbmdlcyBzaW5jZSB0aGUgU2VjdXJpdHlQ YXJhbWV0ZXJzIGNoYW5nZWQuIEFuIGFsdGVybmF0ZSByZWFkaW5nIGlzIHRoYXQgdGhlIEVLTSBm cm9tIHRoZSBmaXJzdCBUTFMgc2Vzc2lvbiBvZiB0aGUgVExTIGNvbm5lY3Rpb24gaXMgdXNlZC4N Cg0KRm9yIHRoZSBzYWtlIG9mIGVhc2Ugb2YgaW1wbGVtZW50YXRpb24gb24gY2xpZW50IGFuZCBz ZXJ2ZXIsIEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIGlmIFRva2VuIEJpbmRpbmcgdXNlcyB0 aGlzIHNlY29uZCByZWFkaW5nLCB3aGVyZSB0aGUgRUtNIHRvIHNpZ24gZG9lcyBub3QgY2hhbmdl IG92ZXIgdGhlIGxpZmV0aW1lIG9mIHRoZSBjb25uZWN0aW9uLiBJIGhhdmUgdXBsb2FkZWQgYSBw dWxsIHJlcXVlc3QgdG8gdHdlYWsgdGhlIGxhbmd1YWdlIHRvIG1vcmUgY2xlYXJseSBzcGVjaWZ5 IHRoaXM6IGh0dHBzOi8vZ2l0aHViLmNvbS9Ub2tlbkJpbmRpbmcvSW50ZXJuZXQtRHJhZnRzL3B1 bGwvNzIuDQoNCklmIHRoZSBFS00gdmFsdWUgY2FuIGNoYW5nZSBvdmVyIHRoZSBjb3Vyc2Ugb2Yg YSBjb25uZWN0aW9uLCB0aGVuIHRoZSBjbGllbnQgYW5kIHNlcnZlciBib3RoIGhhdmUgdG8gY2hl Y2sgd2hhdCB0aGUgRUtNIHZhbHVlIGlzIGVhY2ggdGltZSBiZWZvcmUgdXNpbmcgaXQuIEJvdGgg cGVlcnMgYWxzbyBoYXZlIHRvIHNvbWVob3cgZ3VhcmFudGVlIHRoYXQgYmV0d2VlbiB3aGVuIHRo ZXkgZ2V0IHRoZSBFS00gdmFsdWUgYW5kIHdoZW4gdGhleSBzZW5kIG9yIHJlY2VpdmUgdGhlIG1l c3NhZ2UgdXNpbmcgdGhhdCB2YWx1ZSB0aGF0IG5vIHJlbmVnb3RpYXRpb24gaGFzIHRha2VuIHBs YWNlLiBJIHRoaW5rIHRoaXMgaXMgZWFzeSBlbm91Z2ggdG8gZ3VhcmFudGVlIGZvciBIVFRQLzEu MSBhcHBsaWNhdGlvbiBkYXRhLCBidXQgVG9rZW4gQmluZGluZyBpcyBhZ25vc3RpYyBvZiB0aGUg YXBwbGljYXRpb24gbGF5ZXIgcHJvdG9jb2wuIEltYWdpbmUgc29tZSBvdGhlciBwcm90b2NvbCBp cyB1c2luZyBUb2tlbiBCaW5kaW5nIGFuZCByZW5lZ290aWF0aW9uLCBhbmQgdGhhdCBwcm90b2Nv bCBpcyBtdWx0aXBsZXhlZCAobGlrZSBoMikuIEluIHRoaXMgY2FzZSwgb25lIGFwcGxpY2F0aW9u IHRocmVhZCBjb3VsZCByZWFkIHRoZSBFS00gdmFsdWUsIHByZXBhcmUgYSBUb2tlbkJpbmRpbmcg bWVzc2FnZSwgYW5kIHNlbmQgaXQsIHdoaWxlIGFub3RoZXIgdGhyZWFkIGRvZXMgYSByZW5lZ290 aWF0aW9uIG9uIHRoZSBzYW1lIGNvbm5lY3Rpb24gYmV0d2VlbiB0aGUgZmlyc3QgdGhyZWFkIHJl YWRpbmcgdGhlIEVLTSB2YWx1ZSBhbmQgc2VuZGluZyB0aGUgc2lnbmF0dXJlIG9mIGl0LiBUaGVy ZSBhcmUgcHJvYmFibHkgb3RoZXIgc3RyYW5nZSBpbnRlcmxlYXZpbmdzIG9mIHRva2VuLWJvdW5k IG1lc3NhZ2VzIGFuZCByZW5lZ290aWF0aW9ucyB0aGF0IEkgaGF2ZW4ndCB0aG9yb3VnaGx5IGNv bnNpZGVyZWQsIGJ1dCB1c2luZyB0aGUgc2FtZSBFS00gZm9yIHRoZSBjb25uZWN0aW9uIHNvbHZl cyB0aG9zZSBwcm9ibGVtcy4NCg0KRG9lcyB0aGlzIHNlZW0gbGlrZSBhIHJlYXNvbmFibGUgY2xh cmlmaWNhdGlvbj8NCkNoZWVycywNCk5pY2sNCg== --_000_CY1PR0301MB08422C8E25C1D9344712092F8CDB0CY1PR0301MB0842_ 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 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjcyMzI1OTYzMzsNCgltc28t bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTc5MDQ3MjI0NCA2NzY5 ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcw MyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxw aGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDot OS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlz dC1pZDoxODc1MjcwNDc0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBs YXRlLWlkczoyMTEwODA4MjQgMzQwNTM1ODE4IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxl dmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgTmljayw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+U2Vj dGlvbiAzLjMgb2YgVEJQUk9UTyBzcGVjaWZpZXMgdGhhdCB0aGUgRUtNIGlzIG9idGFpbmVkIGZy b20gdGhlIGN1cnJlbnQgVExTIGNvbm5lY3Rpb24sIGJ1dCBSRkMgNTcwNSBzdGF0ZXMgdGhhdCB0 aGUgZXhwb3J0ZXIgaXMgYXNzb2NpYXRlZCB3aXRoIGEgVExTIHNlc3Npb24gKG1vcmUgc3BlY2lm aWNhbGx5LCBhIHNldCBvZiBTZWN1cml0eVBhcmFtZXRlcnMpLiBJZiB3ZSBhc3N1bWUgdGhhdA0K IFRCUFJPVE8gbWVhbnMgVExTIHNlc3Npb24sIHRoZW4gYWZ0ZXIgYSByZW5lZ290aWF0aW9uIG9j Y3VycywgdGhlIEVLTSB2YWx1ZSBjaGFuZ2VzIHNpbmNlIHRoZSBTZWN1cml0eVBhcmFtZXRlcnMg Y2hhbmdlZC4gQW4gYWx0ZXJuYXRlIHJlYWRpbmcgaXMgdGhhdCB0aGUgRUtNIGZyb20gdGhlIGZp cnN0IFRMUyBzZXNzaW9uIG9mIHRoZSBUTFMgY29ubmVjdGlvbiBpcyB1c2VkLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkl0 IGlzIHRydWUgdGhhdCBpbiBUTFMsIGEgc2Vzc2lvbiBjYW4gb3V0bGFzdCBhIGNvbm5lY3Rpb24s IGFuZCBhbHNvIGEgY29ubmVjdGlvbiBjYW4gb3V0bGFzdCBhIHNlc3Npb24uIFRoZSBpbnRlbnQg aW4gdGhlIFRCUFJPVE8gSS1EIGlzIHRoYXQgdGhlIGN1cnJlbnQgRUtNIGJlIHVzZWQsIHRoYXQN CiBpcywgdGhlIG9uZSBmcm9tIHRoZSBsYXRlc3QgVExTIHNlc3Npb24gb3IgY29ubmVjdGlvbi4g SSBhZ3JlZSB0aGF0IHRoZSBleGlzdGluZyBsYW5ndWFnZSBpbiB0aGUgSS1EIGlzIG92ZXItc2lt cGxpZmllZCBhbmQgZG9lcyBub3QgZnVsbHkgY29udmV5IHRoaXM7IHdpbGwgY2xhcmlmeSBpbiB0 aGUgbmV4dCByZXZpc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwxIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5Gb3IgdGhlIHNha2Ug b2YgZWFzZSBvZiBpbXBsZW1lbnRhdGlvbiBvbiBjbGllbnQgYW5kIHNlcnZlciwgSSB0aGluayBp dCB3b3VsZCBiZSBiZXR0ZXIgaWYgVG9rZW4gQmluZGluZyB1c2VzIHRoaXMgc2Vjb25kIHJlYWRp bmcsIHdoZXJlIHRoZSBFS00gdG8gc2lnbiBkb2VzIG5vdCBjaGFuZ2Ugb3ZlciB0aGUgbGlmZXRp bWUgb2YgdGhlIGNvbm5lY3Rpb24uPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPlRoZXJlIGFyZSBhIGNvdXBsZSBvZiByZWFzb25zIEkgdGhpbmsgd2Ugc2hv dWxkIHVzZSB0aGUgY3VycmVudCBFS006PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwwIGxldmVsMSBsZm8yIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29t cG9zZSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGVuc3VyZXMgdGhhdCBh IGJvdW5kIHRva2VuIGlzIG5vdCByZXBsYXllZCBvbiBhIG5ld2x5IGVzdGFibGlzaGVkIHNlc3Np b24sIGV2ZW4gaWYgdGhpcyBuZXcgc2Vzc2lvbiBoYXMgYmVlbiBlc3RhYmxpc2hlZCBvbiBhbiBl eGlzdGluZyBUTFMgY29ubmVjdGlvbjs8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzIiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21w b3NlIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgYXZvaWRzIHRoZSByZXF1 aXJlbWVudCB0aGF0IHRoZSBjbGllbnQgYW5kIHNlcnZlciByZW1lbWJlciB0aGUgZmlyc3QgRUtN IHZhbHVlIGZvciBlYWNoIGNvbm5lY3Rpb24sIHNvIHRoYXQgdGhleSBjYW4ga2VlcCB1c2luZyBp dCBhZnRlciBzdWJzZXF1ZW50IHJlbmVnb3RpYXRpb24ocykuPG86cD48L286cD48L3NwYW4+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbEVuZENvbXBvc2UiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPklmIHRoZSBF S00gdmFsdWUgY2FuIGNoYW5nZSBvdmVyIHRoZSBjb3Vyc2Ugb2YgYSBjb25uZWN0aW9uLCB0aGVu IHRoZSBjbGllbnQgYW5kIHNlcnZlciBib3RoIGhhdmUgdG8gY2hlY2sgd2hhdCB0aGUgRUtNIHZh bHVlIGlzIGVhY2ggdGltZSBiZWZvcmUgdXNpbmcgaXQuPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9z cGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SU1ITyBpdOKAmXMg YSBnb29kIHRoaW5nIHdoZW4gYm90aCBjbGllbnQgYW5kIHNlcnZlciBtYWtlIHN1cmUgdGhlIHNp Z25hdHVyZSBwcm9wZXJseSBiaW5kcyB0aGUgdG9rZW4gdG8gdGhlIG1vc3QgY3VycmVudCBUTFMg c2VjcmV0Lg0KIEEgbG90IG9mIHNlcnZlciBhcHBzIGFyZSBzdGF0ZWxlc3MgYW5kIGRvbuKAmXQg dHJhY2sgVExTIHNlc3Npb25zIGFuZCBjb25uZWN0aW9ucywgYnV0IHRoZXkgY2FuIGFsd2F5cyBx dWVyeSB0aGUgY3VycmVudCBFS00gdmFsdWUgZnJvbSB0aGUgVExTIGxheWVyLiBNYWtpbmcgc3Vj aCBhcHBzIGF3YXJlIG9mIG1vcmUgVExTIGNvbnRleHQgd291bGQgYWRkIHNpZ25pZmljYW50IGNv bXBsZXhpdHkuPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZl bDEgbGZvMSI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPkltYWdpbmUgc29tZSBvdGhlciBwcm90b2NvbCBpcyB1c2lu ZyBUb2tlbiBCaW5kaW5nIGFuZCByZW5lZ290aWF0aW9uLCBhbmQgdGhhdCBwcm90b2NvbCBpcyBt dWx0aXBsZXhlZCAobGlrZSBoMikuIEluIHRoaXMgY2FzZSwgb25lIGFwcGxpY2F0aW9uIHRocmVh ZCBjb3VsZCByZWFkIHRoZSBFS00gdmFsdWUsIHByZXBhcmUgYSBUb2tlbkJpbmRpbmcgbWVzc2Fn ZSwgYW5kIHNlbmQgaXQsIHdoaWxlDQogYW5vdGhlciB0aHJlYWQgZG9lcyBhIHJlbmVnb3RpYXRp b24gb24gdGhlIHNhbWUgY29ubmVjdGlvbiBiZXR3ZWVuIHRoZSBmaXJzdCB0aHJlYWQgcmVhZGlu ZyB0aGUgRUtNIHZhbHVlIGFuZCBzZW5kaW5nIHRoZSBzaWduYXR1cmUgb2YgaXQuPC9zcGFuPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+VGhpcyBjb21wbGljYXRpb24gZ2VuZXJhbGx5IGV4aXN0cyBmb3IgbXVsdGlwbGV4ZWQgcHJv dG9jb2xzIHJ1bm5pbmcgb3ZlciBUTFMmbHQ7PTEuMiBhbmQgdXNpbmcgRUtNczsgaXQgaXMgbm90 IHNwZWNpZmljIHRvIFRva2VuIEJpbmRpbmcuPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRD b21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls RW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbmRyZWk8bzpwPjwvbzpwPjwv c3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRD b21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBVbmJlYXJhYmxlIFttYWlsdG86dW5i ZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5OaWNrIEhhcnBl cjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE9jdG9iZXIgNywgMjAxNiA0OjUzIFBNPGJyPg0K PGI+VG86PC9iPiBJRVRGIFRva2JpbmQgV0cgJmx0O3VuYmVhcmFibGVAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFtVbmJlYXJhYmxlXSBDbGFyaWZ5aW5nIFRva2VuIEJpbmRpbmcg YmVoYXZpb3Igd2l0aCByZW5lZ290aWF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UmlnaHQgbm93LCB0aGUgVG9rZW4gQmluZGluZyBkb2N1bWVudHMgc3BlY2lmeSBo b3cgdGhlIG5lZ290aWF0aW9uIGV4dGVuc2lvbiBzaG91bGQgaW50ZXJhY3Qgd2l0aCB0aGUgUmVu ZWdvdGlhdGlvbiBJbmRpY2F0aW9uIChSRkMgNTc0NikgZXh0ZW5zaW9uLCBidXQgaXQgY291bGQg YmUgbW9yZSBjbGVhciBhYm91dCB3aGljaCBFS00gdmFsdWUgdG8gdXNlIGluIGEgVG9rZW5CaW5k aW5nIGFmdGVyIGEgcmVuZWdvdGlhdGlvbg0KIG9jY3Vycy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gMy4zIG9mIFRCUFJPVE8gc3BlY2lmaWVz IHRoYXQgdGhlIEVLTSBpcyBvYnRhaW5lZCBmcm9tIHRoZSBjdXJyZW50IFRMUyBjb25uZWN0aW9u LCBidXQgUkZDIDU3MDUgc3RhdGVzIHRoYXQgdGhlIGV4cG9ydGVyIGlzIGFzc29jaWF0ZWQgd2l0 aCBhIFRMUyBzZXNzaW9uIChtb3JlIHNwZWNpZmljYWxseSwgYSBzZXQgb2YgU2VjdXJpdHlQYXJh bWV0ZXJzKS4gSWYgd2UgYXNzdW1lIHRoYXQgVEJQUk9UTw0KIG1lYW5zIFRMUyBzZXNzaW9uLCB0 aGVuIGFmdGVyIGEgcmVuZWdvdGlhdGlvbiBvY2N1cnMsIHRoZSBFS00gdmFsdWUgY2hhbmdlcyBz aW5jZSB0aGUgU2VjdXJpdHlQYXJhbWV0ZXJzIGNoYW5nZWQuIEFuIGFsdGVybmF0ZSByZWFkaW5n IGlzIHRoYXQgdGhlIEVLTSBmcm9tIHRoZSBmaXJzdCBUTFMgc2Vzc2lvbiBvZiB0aGUgVExTIGNv bm5lY3Rpb24gaXMgdXNlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Rm9yIHRoZSBzYWtlIG9mIGVhc2Ugb2YgaW1wbGVtZW50YXRpb24gb24g Y2xpZW50IGFuZCBzZXJ2ZXIsIEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIGlmIFRva2VuIEJp bmRpbmcgdXNlcyB0aGlzIHNlY29uZCByZWFkaW5nLCB3aGVyZSB0aGUgRUtNIHRvIHNpZ24gZG9l cyBub3QgY2hhbmdlIG92ZXIgdGhlIGxpZmV0aW1lIG9mIHRoZSBjb25uZWN0aW9uLiBJIGhhdmUg dXBsb2FkZWQgYSBwdWxsIHJlcXVlc3QNCiB0byB0d2VhayB0aGUgbGFuZ3VhZ2UgdG8gbW9yZSBj bGVhcmx5IHNwZWNpZnkgdGhpczogPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL1Rva2VuQmlu ZGluZy9JbnRlcm5ldC1EcmFmdHMvcHVsbC83MiI+DQpodHRwczovL2dpdGh1Yi5jb20vVG9rZW5C aW5kaW5nL0ludGVybmV0LURyYWZ0cy9wdWxsLzcyPC9hPi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIEVLTSB2YWx1ZSBjYW4gY2hh bmdlIG92ZXIgdGhlIGNvdXJzZSBvZiBhIGNvbm5lY3Rpb24sIHRoZW4gdGhlIGNsaWVudCBhbmQg c2VydmVyIGJvdGggaGF2ZSB0byBjaGVjayB3aGF0IHRoZSBFS00gdmFsdWUgaXMgZWFjaCB0aW1l IGJlZm9yZSB1c2luZyBpdC4gQm90aCBwZWVycyBhbHNvIGhhdmUgdG8gc29tZWhvdyBndWFyYW50 ZWUgdGhhdCBiZXR3ZWVuIHdoZW4gdGhleSBnZXQgdGhlIEVLTSB2YWx1ZQ0KIGFuZCB3aGVuIHRo ZXkgc2VuZCBvciByZWNlaXZlIHRoZSBtZXNzYWdlIHVzaW5nIHRoYXQgdmFsdWUgdGhhdCBubyBy ZW5lZ290aWF0aW9uIGhhcyB0YWtlbiBwbGFjZS4gSSB0aGluayB0aGlzIGlzIGVhc3kgZW5vdWdo IHRvIGd1YXJhbnRlZSBmb3IgSFRUUC8xLjEgYXBwbGljYXRpb24gZGF0YSwgYnV0IFRva2VuIEJp bmRpbmcgaXMgYWdub3N0aWMgb2YgdGhlIGFwcGxpY2F0aW9uIGxheWVyIHByb3RvY29sLiBJbWFn aW5lIHNvbWUgb3RoZXIgcHJvdG9jb2wNCiBpcyB1c2luZyBUb2tlbiBCaW5kaW5nIGFuZCByZW5l Z290aWF0aW9uLCBhbmQgdGhhdCBwcm90b2NvbCBpcyBtdWx0aXBsZXhlZCAobGlrZSBoMikuIElu IHRoaXMgY2FzZSwgb25lIGFwcGxpY2F0aW9uIHRocmVhZCBjb3VsZCByZWFkIHRoZSBFS00gdmFs dWUsIHByZXBhcmUgYSBUb2tlbkJpbmRpbmcgbWVzc2FnZSwgYW5kIHNlbmQgaXQsIHdoaWxlIGFu b3RoZXIgdGhyZWFkIGRvZXMgYSByZW5lZ290aWF0aW9uIG9uIHRoZSBzYW1lIGNvbm5lY3Rpb24N CiBiZXR3ZWVuIHRoZSBmaXJzdCB0aHJlYWQgcmVhZGluZyB0aGUgRUtNIHZhbHVlIGFuZCBzZW5k aW5nIHRoZSBzaWduYXR1cmUgb2YgaXQuIFRoZXJlIGFyZSBwcm9iYWJseSBvdGhlciBzdHJhbmdl IGludGVybGVhdmluZ3Mgb2YgdG9rZW4tYm91bmQgbWVzc2FnZXMgYW5kIHJlbmVnb3RpYXRpb25z IHRoYXQgSSBoYXZlbid0IHRob3JvdWdobHkgY29uc2lkZXJlZCwgYnV0IHVzaW5nIHRoZSBzYW1l IEVLTSBmb3IgdGhlIGNvbm5lY3Rpb24gc29sdmVzDQogdGhvc2UgcHJvYmxlbXMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMgdGhpcyBz ZWVtIGxpa2UgYSByZWFzb25hYmxlIGNsYXJpZmljYXRpb24/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OaWNrPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR0301MB08422C8E25C1D9344712092F8CDB0CY1PR0301MB0842_-- From nobody Mon Oct 10 11:07:06 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52FF129775 for ; Mon, 10 Oct 2016 11:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 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=-2.996, 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 x3ryuBimBm-4 for ; Mon, 10 Oct 2016 11:07:02 -0700 (PDT) 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 AFDF4129773 for ; Mon, 10 Oct 2016 11:07:02 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id u124so76696510ywg.3 for ; Mon, 10 Oct 2016 11:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rkT8viZKnXMMXSehvnn/ixquRtLX47aH7E/8y9/NNDA=; b=BWASNp94+2Dp8bNthu+jFWeVP0WB52ywnmd04t0EP4VmCuyHELVzYvv32O2+nqMDWU dEbGLKdCC2paTvOgynhfzWmTYHaJA9DQXvWReMbRLG60iSctEBZaDTrkbXl8dc//Dv2Q DzBHe5yKf7407datJDeBCstE6JL55OL/Zpuv77He7imHKE2eWGpr0BwLxDNSclPUdxoM 6J5M9GijHVrr0N9/sulF1qxCpaTEcqygSz4OJop11DVuZjdAOdW21WYGhm5oV0BnjDJS BbDomO8loM8vFsApb5fLfFaHJ/GCuARXyB4FjtT8JKJL/uFqQbuuQSZ5L04++dr4H2cW BQ/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rkT8viZKnXMMXSehvnn/ixquRtLX47aH7E/8y9/NNDA=; b=aYo1PcMxBwMvY6fAMz0+vZEZauetdiowGD8O8FY+bjAbgEXbfbyfjGyv/hfhLLj70F KnxCpfTgu3k1YenTc3Y5KF+WonJuf95CAcIJ+tRt0rzmMAaRr2/oFK9OMjmV3v9JsAj6 k6+4rViEdG8qUnDosRQaz06G/bhh/d7tWoLA2Mcj+HIIQC//MTH6vDnzywcXQ6V7DTNk RjO99m2ibFaY+LBQGBx+OXvz1Wy2x7c+mJg/wZE+rpkdpf1Qv4RiZ7a8PrAmDELkygLn 1LSmjvALhZTHCi2DCN3co+iGtcQs9nyubL2JYHK6dXkVe3qJW4EhxJISAMRsrneyF9hp qNgg== X-Gm-Message-State: AA6/9RnVUObcofkJGRobzn8GxBJ6kS7EeR0xvXdDoybhgU/b9WLV4wKWGbxEnbOUL4EsH4aMi4aGPhD7h1ulavr8 X-Received: by 10.13.231.3 with SMTP id q3mr30829358ywe.242.1476122821726; Mon, 10 Oct 2016 11:07:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.253.71 with HTTP; Mon, 10 Oct 2016 11:06:41 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Mon, 10 Oct 2016 11:06:41 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=94eb2c0805046f9cd3053e86a034 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 10 Oct 2016 18:07:04 -0000 --94eb2c0805046f9cd3053e86a034 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Oct 9, 2016 at 5:15 PM, Andrei Popov wrote: > Hi Nick, > > > > There are a couple of reasons I think we should use the current EKM: > > 1. This ensures that a bound token is not replayed on a newly > established session, even if this new session has been established on an > existing TLS connection; > This replay could only happen on an existing TLS connection. For this to happen, an attacker has to be able to read and write to the TLS stream both before and after renegotiation occurs. (Before to get the TokenBinding to replay, and after to replay the TokenBinding with whatever bound tokens and message the attacker wanted.) If the attacker has these capabilities, the attacker could just replay the TokenBinding from after the renegotiation, so it doesn't matter that they use the same EKM value. > 2. This avoids the requirement that the client and server remember > the first EKM value for each connection, so that they can keep using it > after subsequent renegotiation(s). > The server needs to remember the EKM across renegotiation regardless of whether the same EKM is used for the whole connection or a new EKM is used after renegotiation. Consider the following example with HTTP/1.1: 1. C->S: GET /foo HTTP/1.1 2. S->C: HelloRequest 3. C<->S: ClientHello, ServerHello, client auth, ChangeCipherSpec, Finished 4. S->C: HTTP/1.1 200 OK In #1, the client makes a request for a protected resource. When starting to process this request, the server needs a client certificate and sends a HelloRequest (#2) to start renegotiation. #3 has the renegotiation, with the server requesting and the client providing a certificate. Finally, in #4, the server replies to the request from #1, with the reply possibly dependent on the cert in #3. With Token Binding, the request in #1 might have a bound token. The server has to remember this request until at least #3 to process it (since the response could depend on the cert in #3), but when processing it, it also has to verify the Token Binding, using the EKM from before renegotiation. The way that makes the most sense to me for processing this request is that after #3, the server processes the request it received in #1 to generate the response in #4, which means remembering the EKM from #1 to verify the signature. Perhaps it is possible that the server verifies the Token Binding in #1 and then processes the rest of the request later, but this requires keeping track of some other state across renegotiation, and to me sounds more complicated than using the same EKM. > > > =C3=98 If the EKM value can change over the course of a connection, then= the > client and server both have to check what the EKM value is each time befo= re > using it. > > > > IMHO it=E2=80=99s a good thing when both client and server make sure the = signature > properly binds the token to the most current TLS secret. A lot of server > apps are stateless and don=E2=80=99t track TLS sessions and connections, = but they > can always query the current EKM value from the TLS layer. Making such ap= ps > aware of more TLS context would add significant complexity. > If an app is able to query the current EKM value from the TLS layer, it presumably has access to something like OpenSSL's SSL struct (which stores all state for the TLS connection). Once the TLS handshake is complete, the app could store alongside the SSL struct the EKM value for Token Binding (the app probably has an object that owns the SSL struct and manages its lifetime, that object can handle getting the EKM once the handshake is complete). The app itself doesn't need to be more aware of TLS context, and this doesn't add very much complexity. Requiring a lookup of the EKM on each request is expensive and adds more complexity than using the same EKM for the whole connection. If an app is using the Windows TLS stack, each time it queries the EKM, another IPC is required (this was a reason for not putting some of the context for the Token Binding signature in the EKM context value and instead hashing that context with the EKM). This also makes client implementations more complicated. Right now, my client implementation caches Token Binding signatures by TB key and type. If I had to look up the EKM on each request, the cache design would be significantly more complicated, or the cache would be lost entirely and we'd be re-signing on each request and lose all benefits of any HTTP header compression from signatures being the same. Overall, I think that using the same EKM for the whole connection (instead of the EKM for the most recent session) is easier and simpler to implement, and is just as secure. -Nick --94eb2c0805046f9cd3053e86a034 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Oct 9, 2016 at 5:15 PM, Andrei Popov <Andrei.Popov@mi= crosoft.com> wrote:

Hi Nick,

=C2=A0=C2=A0

There are a couple of reasons I think we shou= ld use the current EKM:

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This ensures that a bound token is not replaye= d on a newly established session, even if this new session has been establi= shed on an existing TLS connection;

This replay could only happen on an existing TLS connection. For th= is to happen, an attacker has to be able to read and write to the TLS strea= m both before and after renegotiation occurs. (Before to get the TokenBindi= ng to replay, and after to replay the TokenBinding with whatever bound toke= ns and message the attacker wanted.) If the attacker has these capabilities= , the attacker could just replay the TokenBinding from after the renegotiat= ion, so it doesn't matter that they use the same EKM value.

<= span>

2.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This avoids the requirement that the client an= d server remember the first EKM value for each connection, so that they can= keep using it after subsequent renegotiation(s).

The server needs to remember the EKM across renegotia= tion regardless of whether the same EKM is used for the whole connection or= a new EKM is used after renegotiation. Consider the following example with= HTTP/1.1:

1. C->S: GET /foo HTTP/1.1
2. S->C: HelloRequest
3. C<->S: ClientHello, ServerHell= o, client auth, ChangeCipherSpec, Finished
4. S->C: HTTP/1.1 2= 00 OK

In #1, the client makes a request for a prot= ected resource. When starting to process this request, the server needs a c= lient certificate and sends a HelloRequest (#2) to start renegotiation. #3 = has the renegotiation, with the server requesting and the client providing = a certificate. Finally, in #4, the server replies to the request from #1, w= ith the reply possibly dependent on the cert in #3.

With Token Binding, the request in #1 might have a bound token. The serve= r has to remember this request until at least #3 to process it (since the r= esponse could depend on the cert in #3), but when processing it, it also ha= s to verify the Token Binding, using the EKM from before renegotiation. The= way that makes the most sense to me for processing this request is that af= ter #3, the server processes the request it received in #1 to generate the = response in #4, which means remembering the EKM from #1 to verify the signa= ture. Perhaps it is possible that the server verifies the Token Binding in = #1 and then processes the rest of the request later, but this requires keep= ing track of some other state across renegotiation, and to me sounds more c= omplicated than using the same EKM.

=C2=A0

=C3= =98=C2=A0 If the EKM value can change over the course of = a connection, then the client and server both have to check what the EKM va= lue is each time before using it.=

=C2=A0

IMHO it=E2=80=99s a good thing when both clie= nt and server make sure the signature properly binds the token to the most = current TLS secret. A lot of server apps are stateless and don=E2=80=99t track TLS sessions an= d connections, but they can always query the current EKM value from the TLS= layer. Making such apps aware of more TLS context would add significant co= mplexity.


If = an app is able to query the current EKM value from the TLS layer, it presum= ably has access to something like OpenSSL's SSL struct (which stores al= l state for the TLS connection). Once the TLS handshake is complete, the ap= p could store alongside the SSL struct the EKM value for Token Binding (the= app probably has an object that owns the SSL struct and manages its lifeti= me, that object can handle getting the EKM once the handshake is complete).= The app itself doesn't need to be more aware of TLS context, and this = doesn't add very much complexity.

Requiring a = lookup of the EKM on each request is expensive and adds more complexity tha= n using the same EKM for the whole connection. If an app is using the Windo= ws TLS stack, each time it queries the EKM, another IPC is required (this w= as a reason for not putting some of the context for the Token Binding signa= ture in the EKM context value and instead hashing that context with the EKM= ). This also makes client implementations more complicated. Right now, my c= lient implementation caches Token Binding signatures by TB key and type. If= I had to look up the EKM on each request, the cache design would be signif= icantly more complicated, or the cache would be lost entirely and we'd = be re-signing on each request and lose all benefits of any HTTP header comp= ression from signatures being the same.

Overall, I= think that using the same EKM for the whole connection (instead of the EKM= for the most recent session) is easier and simpler to implement, and is ju= st as secure.

-Nick
--94eb2c0805046f9cd3053e86a034-- From nobody Mon Oct 10 12:46:51 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9871912945C for ; Mon, 10 Oct 2016 12:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 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=-2.996, 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 4i__e4TDfQKj for ; Mon, 10 Oct 2016 12:46:48 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 91777129435 for ; Mon, 10 Oct 2016 12:46:48 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id l13so81794805itl.1 for ; Mon, 10 Oct 2016 12:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ct3npKPvazWvL6/rnrtKoFafbp+ucdbaBl/tE/VYIfo=; b=mq09gs0BeOuh8TGqDK9/4vNAtdirhBEb7kEEbwUY4jXTgipRxuKInmb36VpD4puDpS Io3qpyruq4VAvbuIhTdDl/SCFYE3qRGsPns1hRSugaSlhwvu5llAshm15b9AxYKFDmse HDIRAsAYbhgXQTSWSRNKhTrB1tAgFuQjPhBYeQ4hTwrF8MW9eIli92CV6fkZVca2iAIH DfAKA2oWxDKBZC6TAnLSjNCxSi0O7GoeErw4eTNURir/Axt5SKnpl0BBacEIdQIXB+Ih LESiWkAVwx17vIg4xmIemEJ1HSzJMptO0ex7C4nsWkv3CHFnI5uTMUCRt45vm1A2wHMd HKrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ct3npKPvazWvL6/rnrtKoFafbp+ucdbaBl/tE/VYIfo=; b=YaK7q9REUeEuOfHWMn2X+SBWhSUhTXtAPXBXFt+XUo3Uv5iRHniUhsp2rjfnx9tYZu cQe+qXVDOa5X56n6U1kbRn6IcHpVe2C/T8GWkJc2Kr+lSYITwJP/liOwfBsluQRsiKDZ aVMhx0S/QcPQVGqircqC/PTcYJUiGifGe7C5xpla0iX73nWziAvKQoiMbBDxzLAs7NNI I8WwxWxKrhQdMD5ZZM1s3/qjJf5ls7pDEU5rAdtNLVaYLSFDo1dgHP23hSlptbQScY5u sVFs8HSeNE+ZBeoQsyCILTWXWgqSd7R8T+rltDw3teXn8hyM41/tnB9Qj9TeXDVtut6K Shzw== X-Gm-Message-State: AA6/9RkHGXEW6HL3UjzZNUHA7BBYmBIA49IhRoSEaQPZWfvgtfanL0KH5XsjlZgPoUh9jyxhqFvMRPzkwAFRaNeT X-Received: by 10.36.14.68 with SMTP id 65mr702676ite.99.1476128807825; Mon, 10 Oct 2016 12:46:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.249.169 with HTTP; Mon, 10 Oct 2016 12:46:45 -0700 (PDT) In-Reply-To: References: <20161004071105.GA22592@LK-Perkele-V2.elisa-laajakaista.fi> From: Bill Cox Date: Mon, 10 Oct 2016 12:46:45 -0700 Message-ID: To: Nick Harper Content-Type: multipart/alternative; boundary=001a1143e2003bfeab053e8805de Archived-At: Cc: Andrei Popov , Ilari Liusvaara , IETF Tokbind WG Subject: Re: [Unbearable] Token Binding for 0-RTT connections X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 19:46:50 -0000 --001a1143e2003bfeab053e8805de Content-Type: text/plain; charset=UTF-8 Nick's current draft of 0-RTT token binding for TLS 1.3 requires state be remembered server-side (in the ticket), since the server has to reject the 0-RTT attempt if the client changed the key parameters vs the original connection, and fall back to 1-RTT. This cannot be supported by the current custom extension API in BoringSSL or OpenSSL. Also, the client sends only one key parameter, rather than a list, so if the server falls back to 1-RTT, it has only one choice of key parameters, unlike a regular 1-RTT handshake. I think I agree with Nick on everything in his proposal, except for this issue. His point is that it is easier for us to modify BoringSSL to support token binding as a native extension than it is to use the custom extension API. My point is that it may be very difficult to get the OpenSSL folks to adopt a TLS 1.3 0-RTT token binding native extension compared to continuing to use the custom extension API. Just how hard should we try to continue using the custom extension API? If we decide to go with Nick's current proposal, should we push for OpenSSL to enhance this API so we can add the negotiated key parameters to the ticket, or should we push for incorporating token binding natively? Bill --001a1143e2003bfeab053e8805de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nick's current draft of 0-RTT token binding for T= LS 1.3 requires state be remembered server-side (in the ticket), since the = server has to reject the 0-RTT attempt if the client changed the key parame= ters vs the original connection, and fall back to 1-RTT.=C2=A0 This cannot = be supported by the current custom extension API in BoringSSL or OpenSSL.= =C2=A0 Also, the client sends only one key parameter, rather than a list, s= o if the server falls back to 1-RTT, it has only one choice of key paramete= rs, unlike a regular 1-RTT handshake.

I think I ag= ree with Nick on everything in his proposal, except for this issue.=C2=A0 H= is point is that it is easier for us to modify BoringSSL to support token b= inding as a native extension than it is to use the custom extension API.=C2= =A0 My point is that it may be very difficult to get the OpenSSL folks to a= dopt a TLS 1.3 0-RTT token binding native extension compared to continuing = to use the custom extension API.

Just how hard sho= uld we try to continue using the custom extension API?=C2=A0 If we decide t= o go with Nick's current proposal, should we push for OpenSSL to enhanc= e this API so we can add the negotiated key parameters to the ticket, or sh= ould we push for incorporating token binding natively?

=
Bill
--001a1143e2003bfeab053e8805de-- From nobody Mon Oct 10 13:14:29 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C91B12951F for ; Tue, 4 Oct 2016 14:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-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_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 bz5uRikSPDTQ for ; Tue, 4 Oct 2016 14:31:23 -0700 (PDT) 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 41C2012951B for ; Tue, 4 Oct 2016 14:31:22 -0700 (PDT) Date: Tue, 04 Oct 2016 14:31:21 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1475616681; bh=Qp2j7uNuWg2NlQvCKaUME2YQ0A56y2VszRlCw7j2Azc=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=KCIcG2neIxsvymfY7lwaPnOXfE7d3VldMUGLPVYpz1YnTG6xJHAufnJi18+FcQ2/B IB8jqHBXaKw5A8qWkFeGgTU2Vz310/9hlePBpU/wh/p2DqC5YMdMbMhKir6A6+UeX3 vJqJkl9qf2SvftNQ58eeb0FsaCFIYsFY92xqBS4I= From: Brian Campbell To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57f41fa9c09c_f343f93217d12b827876f"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: b---c X-GitHub-Recipient: unbearable-ML X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Mon, 10 Oct 2016 13:14:28 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] TBPROTO: provide some examples (#39) 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: Tue, 04 Oct 2016 21:31:27 -0000 ----==_mimepart_57f41fa9c09c_f343f93217d12b827876f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here are a couple of -10 TokenBindingMessages produced by Chrome Canary a= nd independently validated with code I wrote (so semi kinda pretty confid= ent that they are correct). **This one has a single ecdsap256 provided token binding :** TokenBindingMessage: `[0, 137, 0, 2, 0, 65, 64, 185, 78, 236, 69, 100, 22= 1, 93, 160, 223, 236, 230, 129, 26, 106, 218, 162, 159, 111, 14, 133, 214= , 182, 125, 237, 141, 121, 178, 38, 38, 142, 236, 183, 83, 144, 138, 53, = 204, 23, 158, 177, 216, 168, 207, 59, 61, 200, 165, 122, 2, 123, 58, 140,= 93, 236, 170, 98, 68, 100, 72, 167, 152, 194, 1, 122, 0, 64, 34, 225, 10= 0, 135, 146, 81, 53, 175, 220, 68, 202, 111, 218, 143, 15, 37, 179, 198, = 100, 37, 192, 80, 197, 146, 103, 134, 74, 138, 97, 10, 209, 4, 117, 243, = 167, 176, 170, 45, 100, 211, 160, 67, 113, 115, 220, 50, 48, 29, 150, 254= , 26, 167, 100, 142, 129, 226, 84, 223, 225, 0, 78, 93, 27, 232, 0, 0]` Base64url encoded TokenBindingMessage: `AIkAAgBBQLlO7EVk3V2g3-zmgRpq2qKfb= w6F1rZ97Y15siYmjuy3U5CKNcwXnrHYqM87PcilegJ7Ooxd7KpiRGRIp5jCAXoAQCLhZIeSUT= Wv3ETKb9qPDyWzxmQlwFDFkmeGSophCtEEdfOnsKotZNOgQ3Fz3DIwHZb-GqdkjoHiVN_hAE5= dG-gAAA` EKM: `[231, 60, 251, 165, 175, 127, 172, 129, 132, 239, 214, 106, 245, 24= 1, 20, 158, 95, 146, 108, 176, 165, 170, 77, 74, 245, 182, 172, 246, 21, = 153, 251, 252]` Base64url encoded EKM: `5zz7pa9_rIGE79Zq9fEUnl-SbLClqk1K9bas9hWZ-_w` **This one has a ecdsap256 provided and referred token binding:** TokenBindingMessage:` [1, 18, 0, 2, 0, 65, 64, 185, 78, 236, 69, 100, 221= , 93, 160, 223, 236, 230, 129, 26, 106, 218, 162, 159, 111, 14, 133, 214,= 182, 125, 237, 141, 121, 178, 38, 38, 142, 236, 183, 83, 144, 138, 53, 2= 04, 23, 158, 177, 216, 168, 207, 59, 61, 200, 165, 122, 2, 123, 58, 140, = 93, 236, 170, 98, 68, 100, 72, 167, 152, 194, 1, 122, 0, 64, 160, 159, 19= 6, 249, 249, 68, 33, 244, 30, 132, 126, 199, 248, 144, 56, 160, 184, 232,= 190, 12, 110, 208, 171, 225, 97, 174, 93, 53, 124, 151, 117, 100, 133, 8= 1, 6, 151, 137, 44, 112, 57, 86, 89, 71, 3, 65, 95, 204, 106, 45, 135, 12= 1, 40, 158, 132, 207, 33, 7, 43, 184, 99, 205, 28, 237, 157, 0, 0, 1, 2, = 0, 65, 64, 82, 225, 38, 192, 194, 224, 125, 173, 193, 178, 213, 119, 32, = 176, 126, 112, 196, 212, 85, 239, 108, 117, 31, 106, 227, 180, 126, 162, = 51, 21, 128, 212, 136, 132, 129, 2, 155, 89, 143, 244, 233, 52, 32, 166, = 161, 121, 103, 182, 212, 189, 191, 235, 68, 71, 199, 124, 183, 232, 223, = 0, 69, 218, 208, 179, 0, 64, 250, 169, 130, 88, 107, 124, 60, 48, 112, 44= , 113, 48, 172, 76, 44, 96, 23, 173, 102, 63, 195, 179, 38, 68, 232, 237,= 202, 120, 101, 163, 22, 59, 1, 161, 119, 37, 25, 68, 49, 240, 38, 45, 14= 4, 231, 200, 45, 61, 143, 65, 92, 171, 250, 141, 223, 48, 218, 246, 9, 25= 5, 197, 72, 248, 215, 66, 0, 0]` Base64url encoded TokenBindingMessage: `ARIAAgBBQLlO7EVk3V2g3-zmgRpq2qKfb= w6F1rZ97Y15siYmjuy3U5CKNcwXnrHYqM87PcilegJ7Ooxd7KpiRGRIp5jCAXoAQKCfxPn5RC= H0HoR-x_iQOKC46L4MbtCr4WGuXTV8l3VkhVEGl4kscDlWWUcDQV_Mai2HeSiehM8hByu4Y80= c7Z0AAAECAEFAUuEmwMLgfa3BstV3ILB-cMTUVe9sdR9q47R-ojMVgNSIhIECm1mP9Ok0IKah= eWe21L2_60RHx3y36N8ARdrQswBA-qmCWGt8PDBwLHEwrEwsYBetZj_DsyZE6O3KeGWjFjsBo= XclGUQx8CYtkOfILT2PQVyr-o3fMNr2Cf_FSPjXQgAA` EKM: `[69, 218, 67, 133, 84, 79, 45, 24, 148, 55, 227, 128, 173, 2, 222, = 45, 1, 1, 135, 85, 34, 212, 177, 151, 174, 124, 164, 87, 20, 204, 65, 36]= ` Base64url encoded EKM: `RdpDhVRPLRiUN-OArQLeLQEBh1Ui1LGXrnykVxTMQSQ` -- = 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/39#issuecomment-25= 1519896= ----==_mimepart_57f41fa9c09c_f343f93217d12b827876f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Here are a couple of -10 TokenBindingMessages produced by Chrome Canar= y and independently validated with code I wrote (so semi kinda pretty con= fident that they are correct).

This one has a single ecdsap256 provided token binding :
TokenBindingMessage: [0, 137, 0, 2, 0, 65, 64, 185, 78, 236, 69, 10= 0, 221, 93, 160, 223, 236, 230, 129, 26, 106, 218, 162, 159, 111, 14, 133= , 214, 182, 125, 237, 141, 121, 178, 38, 38, 142, 236, 183, 83, 144, 138,= 53, 204, 23, 158, 177, 216, 168, 207, 59, 61, 200, 165, 122, 2, 123, 58,= 140, 93, 236, 170, 98, 68, 100, 72, 167, 152, 194, 1, 122, 0, 64, 34, 22= 5, 100, 135, 146, 81, 53, 175, 220, 68, 202, 111, 218, 143, 15, 37, 179, = 198, 100, 37, 192, 80, 197, 146, 103, 134, 74, 138, 97, 10, 209, 4, 117, = 243, 167, 176, 170, 45, 100, 211, 160, 67, 113, 115, 220, 50, 48, 29, 150= , 254, 26, 167, 100, 142, 129, 226, 84, 223, 225, 0, 78, 93, 27, 232, 0, = 0]
Base64url encoded TokenBindingMessage: AIkAAgBBQLlO7EVk3V2g3-zmgRpq= 2qKfbw6F1rZ97Y15siYmjuy3U5CKNcwXnrHYqM87PcilegJ7Ooxd7KpiRGRIp5jCAXoAQCLhZ= IeSUTWv3ETKb9qPDyWzxmQlwFDFkmeGSophCtEEdfOnsKotZNOgQ3Fz3DIwHZb-GqdkjoHiVN= _hAE5dG-gAAA
EKM: [231, 60, 251, 165, 175, 127, 172, 129, 132, 239, 214, 106, 24= 5, 241, 20, 158, 95, 146, 108, 176, 165, 170, 77, 74, 245, 182, 172, 246,= 21, 153, 251, 252]
Base64url encoded EKM: 5zz7pa9_rIGE79Zq9fEUnl-SbLClqk1K9bas9hWZ-_w<= /code>

This one has a ecdsap256 provided and referred token binding:<= /strong>
TokenBindingMessage:[1, 18, 0, 2, 0, 65, 64, 185, 78, 236, 69, 100,= 221, 93, 160, 223, 236, 230, 129, 26, 106, 218, 162, 159, 111, 14, 133, = 214, 182, 125, 237, 141, 121, 178, 38, 38, 142, 236, 183, 83, 144, 138, 5= 3, 204, 23, 158, 177, 216, 168, 207, 59, 61, 200, 165, 122, 2, 123, 58, 1= 40, 93, 236, 170, 98, 68, 100, 72, 167, 152, 194, 1, 122, 0, 64, 160, 159= , 196, 249, 249, 68, 33, 244, 30, 132, 126, 199, 248, 144, 56, 160, 184, = 232, 190, 12, 110, 208, 171, 225, 97, 174, 93, 53, 124, 151, 117, 100, 13= 3, 81, 6, 151, 137, 44, 112, 57, 86, 89, 71, 3, 65, 95, 204, 106, 45, 135= , 121, 40, 158, 132, 207, 33, 7, 43, 184, 99, 205, 28, 237, 157, 0, 0, 1,= 2, 0, 65, 64, 82, 225, 38, 192, 194, 224, 125, 173, 193, 178, 213, 119, = 32, 176, 126, 112, 196, 212, 85, 239, 108, 117, 31, 106, 227, 180, 126, 1= 62, 51, 21, 128, 212, 136, 132, 129, 2, 155, 89, 143, 244, 233, 52, 32, 1= 66, 161, 121, 103, 182, 212, 189, 191, 235, 68, 71, 199, 124, 183, 232, 2= 23, 0, 69, 218, 208, 179, 0, 64, 250, 169, 130, 88, 107, 124, 60, 48, 112= , 44, 113, 48, 172, 76, 44, 96, 23, 173, 102, 63, 195, 179, 38, 68, 232, = 237, 202, 120, 101, 163, 22, 59, 1, 161, 119, 37, 25, 68, 49, 240, 38, 45= , 144, 231, 200, 45, 61, 143, 65, 92, 171, 250, 141, 223, 48, 218, 246, 9= , 255, 197, 72, 248, 215, 66, 0, 0]
Base64url encoded TokenBindingMessage: ARIAAgBBQLlO7EVk3V2g3-zmgRpq= 2qKfbw6F1rZ97Y15siYmjuy3U5CKNcwXnrHYqM87PcilegJ7Ooxd7KpiRGRIp5jCAXoAQKCfx= Pn5RCH0HoR-x_iQOKC46L4MbtCr4WGuXTV8l3VkhVEGl4kscDlWWUcDQV_Mai2HeSiehM8hBy= u4Y80c7Z0AAAECAEFAUuEmwMLgfa3BstV3ILB-cMTUVe9sdR9q47R-ojMVgNSIhIECm1mP9Ok= 0IKaheWe21L2_60RHx3y36N8ARdrQswBA-qmCWGt8PDBwLHEwrEwsYBetZj_DsyZE6O3KeGWj= FjsBoXclGUQx8CYtkOfILT2PQVyr-o3fMNr2Cf_FSPjXQgAA
EKM: [69, 218, 67, 133, 84, 79, 45, 24, 148, 55, 227, 128, 173, 2, = 222, 45, 1, 1, 135, 85, 34, 212, 177, 151, 174, 124, 164, 87, 20, 204, 65= , 36]
Base64url encoded EKM: RdpDhVRPLRiUN-OArQLeLQEBh1Ui1LGXrnykVxTMQSQ<= /code>

&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_57f41fa9c09c_f343f93217d12b827876f-- From nobody Mon Oct 10 13:26:29 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC78129742 for ; Mon, 10 Oct 2016 13:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.996 X-Spam-Level: X-Spam-Status: No, score=-4.996 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, RP_MATCHES_RCVD=-2.996, 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 vapspi2YppSc for ; Mon, 10 Oct 2016 13:26:26 -0700 (PDT) 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 10EC21295BA for ; Mon, 10 Oct 2016 13:26:26 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id t193so427123ywc.2 for ; Mon, 10 Oct 2016 13:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YTx2WuLbU0BfD+GlvWfJZS0o4QChRQtwuTwkpHCFi6w=; b=enSnC9nnFZNWnTZpYc94rH1fc+pBKvMRRo5uI6dRP5RzttF6DPI6lr4oolVIPfjt2Q ob74B2bI9SfQnpse5UknxOzaF2RhGvCj8oOtomg9v9n7oUuw3AyeRR+3lxxC8huap0gD rwYRkkMQQBdBLQfgo3HY8opYAcUj+t9KjwhhL+UcbIS0OIHBWC7puyrguu9BsDZt7ts2 isjv+zi2kV9JYi9OW0Q0rOExnT3MzMMoBe0NBPo6GIa3giewQmpwjxzZLjhz3HopXJTC OabQ2rpEx9WVN1qDBhEBbIYsxaz7QYhOD9holJiHny29uLePRpeP/45R+rN++alc79zH u+/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YTx2WuLbU0BfD+GlvWfJZS0o4QChRQtwuTwkpHCFi6w=; b=a5B+4tC3bl4tGTV4h9Ci2Tn9HWaxR8ZV2TAqDt6VjwAcPe9M7kytRIM6365VDtrp6y EVs1yAtz/Z77RuJVCFOmCRrKsh73TUUfftjnFE4ZeDd1iM+xSLKqU/iMn/vMxrFiAH3z IxBAyGu5vk0O5AiAdgoIV/nvKc8Yoy44LiFYS18V6o/bAqRDN5VbZrBZWxx1bfveWp9N Z008sn1LjdjYKTR6rwVZqio/9doUPAd4sSmnoyDVCK0kc+T5rw/ZQn6V9HyxuuU/Paln IRQZ2rO1tSOkb4ovtUm/ZQo7r5iIY0FjCerslx3kPBNHVVJZfJbnYqfYtZAWutWY7x1e hk5A== X-Gm-Message-State: AA6/9Rk3yG+TZJwSXMAdi+Rsoy0MWuKbO6/Sfo+ajoeNzn8R0nwTzHwntpG5eow13kZin7prVWjEbUhhpIZvWnTC X-Received: by 10.13.230.6 with SMTP id p6mr4928ywe.253.1476130773565; Mon, 10 Oct 2016 13:19:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.253.71 with HTTP; Mon, 10 Oct 2016 13:19:13 -0700 (PDT) In-Reply-To: References: <20161004071105.GA22592@LK-Perkele-V2.elisa-laajakaista.fi> From: Nick Harper Date: Mon, 10 Oct 2016 13:19:13 -0700 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=94eb2c0889fe670c28053e887a41 Archived-At: Cc: Andrei Popov , Ilari Liusvaara , IETF Tokbind WG Subject: Re: [Unbearable] Token Binding for 0-RTT connections X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 20:26:28 -0000 --94eb2c0889fe670c28053e887a41 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 10, 2016 at 12:46 PM, Bill Cox wrote: > Nick's current draft of 0-RTT token binding for TLS 1.3 requires state be > remembered server-side (in the ticket), since the server has to reject the > 0-RTT attempt if the client changed the key parameters vs the original > connection, and fall back to 1-RTT. This cannot be supported by the > current custom extension API in BoringSSL or OpenSSL. Also, the client > sends only one key parameter, rather than a list, so if the server falls > back to 1-RTT, it has only one choice of key parameters, unlike a regular > 1-RTT handshake. > The client still sends a list of key parameters in the TB extension in the ClientHello (on a 0-RTT connection), so if the server falls back to 1-RTT it can choose a different parameter. (I think a previous draft had the client sending only one to avoid the server having to remember, with the downside of not being able to choose a new parameter.) > > I think I agree with Nick on everything in his proposal, except for this > issue. His point is that it is easier for us to modify BoringSSL to > support token binding as a native extension than it is to use the custom > extension API. My point is that it may be very difficult to get the > OpenSSL folks to adopt a TLS 1.3 0-RTT token binding native extension > compared to continuing to use the custom extension API. > > Just how hard should we try to continue using the custom extension API? > If we decide to go with Nick's current proposal, should we push for OpenSSL > to enhance this API so we can add the negotiated key parameters to the > ticket, or should we push for incorporating token binding natively? > > Bill > --94eb2c0889fe670c28053e887a41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 10, 2016 at 12:46 PM, Bill Cox <waywardgeek@google.co= m> wrote:
=
Nick's current draft of 0-RTT token binding for TLS 1.3 requires s= tate be remembered server-side (in the ticket), since the server has to rej= ect the 0-RTT attempt if the client changed the key parameters vs the origi= nal connection, and fall back to 1-RTT.=C2=A0 This cannot be supported by t= he current custom extension API in BoringSSL or OpenSSL.=C2=A0 Also, the cl= ient sends only one key parameter, rather than a list, so if the server fal= ls back to 1-RTT, it has only one choice of key parameters, unlike a regula= r 1-RTT handshake.

The client s= till sends a list of key parameters in the TB extension in the ClientHello = (on a 0-RTT connection), so if the server falls back to 1-RTT it can choose= a different parameter. (I think a previous draft had the client sending on= ly one to avoid the server having to remember, with the downside of not bei= ng able to choose a new parameter.)

I think I agree with Nick on everything i= n his proposal, except for this issue.=C2=A0 His point is that it is easier= for us to modify BoringSSL to support token binding as a native extension = than it is to use the custom extension API.=C2=A0 My point is that it may b= e very difficult to get the OpenSSL folks to adopt a TLS 1.3 0-RTT token bi= nding native extension compared to continuing to use the custom extension A= PI.

Just how hard should we try to continue using = the custom extension API?=C2=A0 If we decide to go with Nick's current = proposal, should we push for OpenSSL to enhance this API so we can add the = negotiated key parameters to the ticket, or should we push for incorporatin= g token binding natively?

Bill

--94eb2c0889fe670c28053e887a41-- From nobody Wed Oct 12 12:17:37 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB14E12963A for ; Wed, 12 Oct 2016 12:17:34 -0700 (PDT) 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 9VgISnbYmTCi for ; Wed, 12 Oct 2016 12:17:33 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0138.outbound.protection.outlook.com [104.47.42.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E710412950A for ; Wed, 12 Oct 2016 12:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JipZozhPtcN0/eOjsOaM2Iw7w27B9MZ3mmDgNXCNCyc=; b=C6lHktVy9hxOLhb7FMDGsp/P5JNS6K8LssTgBPlJnq+xN5z19wtzuUiR35+2F6dimFhvsyfZAQe1dHV6HnRM97SZtIdbssNcWvV7rp7n5ezI8JLgplUtA7fa5G+zAwNc5YqkMOQOeTu5OB7GKJJSGHjHN6cnjIsZByzsnzLK2B4= 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.649.16; Wed, 12 Oct 2016 19:17:30 +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.0649.027; Wed, 12 Oct 2016 19:17:30 +0000 From: Andrei Popov To: Nick Harper Thread-Topic: [Unbearable] Clarifying Token Binding behavior with renegotiation Thread-Index: AQHSIPYAfU8tAUm590uf08aV6ED2raCgzRRQgAEzGoCAAzA0MA== Date: Wed, 12 Oct 2016 19:17:29 +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::1d2] x-ms-office365-filtering-correlation-id: 1c7c350e-750c-4400-c623-08d3f2d469a9 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 7:ZNou3avsJB9cmAnDK0UjpUKw04TidQ8R2F415cG1CREyU7aSJuXMaqj3jBUwo6ViUwl+WG/yWrizSdMVlaoOWnW00PjA44Rco6MUFo7apPSM5tWYhgjJsdBF4xcO82MORH+Y6Nph5HYWBzQSQOkRpcsXUua/qr/ZleUN5p2EiexdF1kr9qjONFeddbAQ/OO6rSPQssKffNmj3D//FKDyg+5KjP6C1ron/NyK6CHWTjV9DziZOHWZadrFNLpAlmMRBP4rxWpGgpMjbGX4a0IuUO2HiPyreANGY28TU0Pceyr/dBDB6ptm+HAVLar7Ua6N+6NWTLYCXiLNjX372DtSI8h2EEgwlKt8Av6N+0N+xmCWyPinMHWGt5d8hfVJ0xSS x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0844; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(2900100001)(122556002)(86612001)(586003)(4326007)(54356999)(6116002)(76176999)(9686002)(87936001)(5005710100001)(101416001)(10290500002)(86362001)(15975445007)(10400500002)(50986999)(77096005)(92566002)(19625215002)(561944003)(16236675004)(790700001)(102836003)(33656002)(106116001)(19580395003)(19300405004)(8990500004)(106356001)(105586002)(68736007)(76576001)(3660700001)(3280700002)(99286002)(81166006)(8936002)(8676002)(11100500001)(5002640100001)(81156014)(97736004)(110136003)(7696004)(7846002)(5660300001)(189998001)(7736002)(2906002)(10090500001)(74316002)(6916009)(2950100002)(3826002); 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_CY1PR0301MB08428A90149E40D94FED4D9C8CDD0CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2016 19:17:29.8606 (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] Clarifying Token Binding behavior with renegotiation 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, 12 Oct 2016 19:17:35 -0000 --_000_CY1PR0301MB08428A90149E40D94FED4D9C8CDD0CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEZvciB0aGlzIHRvIGhhcHBlbiwgYW4gYXR0YWNrZXIgaGFzIHRvIGJlIGFibGUgdG8gcmVh ZCBhbmQgd3JpdGUgdG8gdGhlIFRMUyBzdHJlYW0gYm90aCBiZWZvcmUgYW5kIGFmdGVyIHJlbmVn b3RpYXRpb24gb2NjdXJzLiAoQmVmb3JlIHRvIGdldCB0aGUgVG9rZW5CaW5kaW5nIHRvIHJlcGxh eSwgYW5kIGFmdGVyIHRvIHJlcGxheSB0aGUgVG9rZW5CaW5kaW5nIHdpdGggd2hhdGV2ZXIgYm91 bmQgdG9rZW5zIGFuZCBtZXNzYWdlIHRoZSBhdHRhY2tlciB3YW50ZWQuKSBJZiB0aGUgYXR0YWNr ZXIgaGFzIHRoZXNlIGNhcGFiaWxpdGllcywgdGhlIGF0dGFja2VyIGNvdWxkIGp1c3QgcmVwbGF5 IHRoZSBUb2tlbkJpbmRpbmcgZnJvbSBhZnRlciB0aGUgcmVuZWdvdGlhdGlvbiwgc28gaXQgZG9l c24ndCBtYXR0ZXIgdGhhdCB0aGV5IHVzZSB0aGUgc2FtZSBFS00gdmFsdWUuDQpOb3QgbmVjZXNz YXJpbHk6IGxldOKAmXMgc2F5IHRoZSBpbml0aWFsIFRMUyBzZXNzaW9uIGlzIE1JVE3igJllZCBh bmQgdGhlIGF0dGFja2VyIEEgdHJhbnNwYXJlbnRseSBwYXNzZXMgbWVzc2FnZXMgYmV0d2VlbiBD IGFuZCBTLiBJbiB0aGUgcHJvY2VzcywgQSBnYWlucyBhY2Nlc3MgdG8gdGhlIFRCIG1lc3NhZ2Ug YW5kIHRoZSB0b2tlbiBmcm9tIHRoaXMgaW5pdGlhbCBUTFMgc2Vzc2lvbi4NCldpdGggeW91ciBw cm9wb3NhbCBpbiBwbGFjZSwgbm93IEEgY2FuIHRyaWdnZXIgcmVuZWdvdGlhdGlvbiB3aXRoIFMg YW5kIHByZXNlbnQgdGhlIHNhbWUgdG9rZW4gYW5kIHRoZSBzYW1lIFRCIG1lc3NhZ2UsIGFuZCBp bXBlcnNvbmF0ZSBDIGZyb20gYSBkaWZmZXJlbnQgbWFjaGluZSwgd2l0aG91dCBhY2Nlc3MgdG8g dGhlIFRCIGtleSBzZWN1cmVseSBzdG9yZWQgYnkgQy4NCklmIHRoZSBsYXRlc3QgRUtNIGlzIHJl cXVpcmVkIGFmdGVyIHJlbmVnb3RpYXRpb24gKGFzIGl0IGN1cnJlbnRseSBpcywgYWxiZWl0IGFk bWl0dGVkbHkgdGhlIGxhbmd1YWdlIGlzIGZsYXdlZCksIEEgbmVlZHMgdG8gZ2VuZXJhdGUgYSBu ZXcgc2lnbmF0dXJlIGFmdGVyIHJlbmVnb3RpYXRpb24sIHVzaW5nIHRoZSBsYXRlc3QgRUtNLCBh bmQgQSBjYW7igJl0IGRvIGl0IHdpdGhvdXQgYWNjZXNzIHRvIHRoZSBUQiBrZXkuDQoNCg0Kw5gg IFRoZSBzZXJ2ZXIgbmVlZHMgdG8gcmVtZW1iZXIgdGhlIEVLTSBhY3Jvc3MgcmVuZWdvdGlhdGlv biByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhlIHNhbWUgRUtNIGlzIHVzZWQgZm9yIHRoZSB3aG9s ZSBjb25uZWN0aW9uIG9yIGEgbmV3IEVLTSBpcyB1c2VkIGFmdGVyIHJlbmVnb3RpYXRpb24uIENv bnNpZGVyIHRoZSBmb2xsb3dpbmcgZXhhbXBsZSB3aXRoIEhUVFAvMS4xOuKApg0KQXMgeW91IG5v dGUgeW91cnNlbGYsIHRoZSBiaW5kaW5nIGNhbiBiZSB2ZXJpZmllZCBhdCBzdGVwIDEsIHNvIHJl bWVtYmVyaW5nIG11bHRpcGxlIEVLTXMgdnMuIHZlcmlmeWluZyBUQnMgYXMgdGhleSBhcnJpdmUg aXMgYW4gaW1wbGVtZW50YXRpb24gY2hvaWNlLiBJIHNlZSBubyByZWFzb24gZm9yIHRoZSBUQiBz cGVjIHRvIGxvY2sgYW4gaW1wbGVtZW50YXRpb24gaW50byBvbmUgY2hvaWNlLg0KDQoNCsOYICBS ZXF1aXJpbmcgYSBsb29rdXAgb2YgdGhlIEVLTSBvbiBlYWNoIHJlcXVlc3QgaXMgZXhwZW5zaXZl IGFuZCBhZGRzIG1vcmUgY29tcGxleGl0eSB0aGFuIHVzaW5nIHRoZSBzYW1lIEVLTSBmb3IgdGhl IHdob2xlIGNvbm5lY3Rpb24uDQpBZ2FpbiwgeW914oCZcmUgYXNzdW1pbmcgdGhhdCB0aGUgc2Vy dmVyIGFwcGxpY2F0aW9uIGhhcyBhIG5vdGlvbiBvZiDigJxjb25uZWN0aW9u4oCdLCB3aGVyZWFz IG1hbnkgb2YgdGhlbSBhcmUgZGVzaWduZWQgdG8gb25seSB1bmRlcnN0YW5kIOKAnHJlcXVlc3Ti gJ0uDQoNCg0Kw5ggIElmIGFuIGFwcCBpcyB1c2luZyB0aGUgV2luZG93cyBUTFMgc3RhY2ssIGVh Y2ggdGltZSBpdCBxdWVyaWVzIHRoZSBFS00sIGFub3RoZXIgSVBDIGlzIHJlcXVpcmVkICh0aGlz IHdhcyBhIHJlYXNvbiBmb3Igbm90IHB1dHRpbmcgc29tZSBvZiB0aGUgY29udGV4dCBmb3IgdGhl IFRva2VuIEJpbmRpbmcgc2lnbmF0dXJlIGluIHRoZSBFS00gY29udGV4dCB2YWx1ZSBhbmQgaW5z dGVhZCBoYXNoaW5nIHRoYXQgY29udGV4dCB3aXRoIHRoZSBFS00pLg0KVGhhbmtzIGZvciB0aGlu a2luZyBhYm91dCBXaW5kb3dz4pi6LiBPbiBXaW5kb3dzLCBIVFRQIG1pZGRsZXdhcmUgY2FjaGVz IHRoZSBjdXJyZW50IEVLTSwgc28gdGhlcmUgaXMgbm8gbmVlZCB0byBkbyBJUEMgZm9yIGVhY2gg cmVxdWVzdC4NCg0KDQrDmCAgUmlnaHQgbm93LCBteSBjbGllbnQgaW1wbGVtZW50YXRpb24gY2Fj aGVzIFRva2VuIEJpbmRpbmcgc2lnbmF0dXJlcyBieSBUQiBrZXkgYW5kIHR5cGUuDQpUaGlzIHNv dW5kcyBsaWtlIGEgYnVnOiBFS00gc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGNhY2hlIGluZGV4LCBi ZWNhdXNlIGl04oCZcyBwYXJ0IG9mIHRoZSBkYXRhIGJlaW5nIHNpZ25lZCBieSBhIHBhcnRpY3Vs YXIgc2lnbmF0dXJlLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0K --_000_CY1PR0301MB08428A90149E40D94FED4D9C8CDD0CY1PR0301MB0842_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubS0zMDc2OTIzNzQ2NzY3MDQyMzkwbTYwNTYyNTMxMzg4 Mjk3NjI5NjNtc29saXN0cGFyYWdyYXBoLCBsaS5tLTMwNzY5MjM3NDY3NjcwNDIzOTBtNjA1NjI1 MzEzODgyOTc2Mjk2M21zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tLTMwNzY5MjM3NDY3NjcwNDIzOTBt NjA1NjI1MzEzODgyOTc2Mjk2M21zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV8t MzA3NjkyMzc0Njc2NzA0MjM5MG1fNjA1NjI1MzEzODgyOTc2Mjk2M21zb2xpc3RwYXJhZ3JhcGg7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5 bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDozODg1MDI1ODM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi0xMjE3NDkxNTEwIC04MTI4NTAxMzQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDozOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJy aTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkZvciB0aGlz IHRvIGhhcHBlbiwgYW4gYXR0YWNrZXIgaGFzIHRvIGJlIGFibGUgdG8gcmVhZCBhbmQgd3JpdGUg dG8gdGhlIFRMUyBzdHJlYW0gYm90aCBiZWZvcmUgYW5kIGFmdGVyIHJlbmVnb3RpYXRpb24gb2Nj dXJzLiAoQmVmb3JlIHRvIGdldCB0aGUgVG9rZW5CaW5kaW5nIHRvIHJlcGxheSwgYW5kIGFmdGVy IHRvIHJlcGxheSB0aGUgVG9rZW5CaW5kaW5nIHdpdGggd2hhdGV2ZXIgYm91bmQNCiB0b2tlbnMg YW5kIG1lc3NhZ2UgdGhlIGF0dGFja2VyIHdhbnRlZC4pIElmIHRoZSBhdHRhY2tlciBoYXMgdGhl c2UgY2FwYWJpbGl0aWVzLCB0aGUgYXR0YWNrZXIgY291bGQganVzdCByZXBsYXkgdGhlIFRva2Vu QmluZGluZyBmcm9tIGFmdGVyIHRoZSByZW5lZ290aWF0aW9uLCBzbyBpdCBkb2Vzbid0IG1hdHRl ciB0aGF0IHRoZXkgdXNlIHRoZSBzYW1lIEVLTSB2YWx1ZS48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Tm90IG5lY2Vzc2FyaWx5OiBsZXTigJlzIHNheSB0aGUgaW5pdGlhbCBUTFMgc2Vzc2lvbiBpcyBN SVRN4oCZZWQgYW5kIHRoZSBhdHRhY2tlciBBIHRyYW5zcGFyZW50bHkgcGFzc2VzIG1lc3NhZ2Vz IGJldHdlZW4gQyBhbmQgUy4gSW4gdGhlIHByb2Nlc3MsIEEgZ2FpbnMgYWNjZXNzIHRvIHRoZSBU QiBtZXNzYWdlDQogYW5kIHRoZSB0b2tlbiBmcm9tIHRoaXMgaW5pdGlhbCBUTFMgc2Vzc2lvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPldpdGggeW91ciBwcm9wb3NhbCBpbiBwbGFjZSwgbm93IEEgY2FuIHRyaWdnZXIgcmVuZWdv dGlhdGlvbiB3aXRoIFMgYW5kIHByZXNlbnQgdGhlIHNhbWUgdG9rZW4gYW5kIHRoZSBzYW1lIFRC IG1lc3NhZ2UsIGFuZCBpbXBlcnNvbmF0ZSBDIGZyb20gYSBkaWZmZXJlbnQgbWFjaGluZSwgd2l0 aG91dA0KIGFjY2VzcyB0byB0aGUgVEIga2V5IHNlY3VyZWx5IHN0b3JlZCBieSBDLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SWYg dGhlIGxhdGVzdCBFS00gaXMgcmVxdWlyZWQgYWZ0ZXIgcmVuZWdvdGlhdGlvbiAoYXMgaXQgY3Vy cmVudGx5IGlzLCBhbGJlaXQgYWRtaXR0ZWRseSB0aGUgbGFuZ3VhZ2UgaXMgZmxhd2VkKSwgQSBu ZWVkcyB0byBnZW5lcmF0ZSBhIG5ldyBzaWduYXR1cmUgYWZ0ZXIgcmVuZWdvdGlhdGlvbiwgdXNp bmcNCiB0aGUgbGF0ZXN0IEVLTSwgYW5kIEEgY2Fu4oCZdCBkbyBpdCB3aXRob3V0IGFjY2VzcyB0 byB0aGUgVEIga2V5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGUgc2VydmVyIG5lZWRzIHRvIHJlbWVtYmVyIHRoZSBF S00gYWNyb3NzIHJlbmVnb3RpYXRpb24gcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSBzYW1lIEVL TSBpcyB1c2VkIGZvciB0aGUgd2hvbGUgY29ubmVjdGlvbiBvciBhIG5ldyBFS00gaXMgdXNlZCBh ZnRlciByZW5lZ290aWF0aW9uLiBDb25zaWRlciB0aGUgZm9sbG93aW5nIGV4YW1wbGUgd2l0aCBI VFRQLzEuMTrigKY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+QXMgeW91IG5vdGUgeW91cnNlbGYsIHRoZSBiaW5kaW5nIGNhbiBiZSB2ZXJpZmll ZCBhdCBzdGVwIDEsIHNvIHJlbWVtYmVyaW5nIG11bHRpcGxlIEVLTXMgdnMuIHZlcmlmeWluZyBU QnMgYXMgdGhleSBhcnJpdmUgaXMgYW4gaW1wbGVtZW50YXRpb24gY2hvaWNlLiBJIHNlZSBubyBy ZWFzb24gZm9yDQogdGhlIFRCIHNwZWMgdG8gbG9jayBhbiBpbXBsZW1lbnRhdGlvbiBpbnRvIG9u ZSBjaG9pY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7D mDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+UmVxdWlyaW5nIGEgbG9va3VwIG9m IHRoZSBFS00gb24gZWFjaCByZXF1ZXN0IGlzIGV4cGVuc2l2ZSBhbmQgYWRkcyBtb3JlIGNvbXBs ZXhpdHkgdGhhbiB1c2luZyB0aGUgc2FtZSBFS00gZm9yIHRoZSB3aG9sZSBjb25uZWN0aW9uLjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5BZ2FpbiwgeW914oCZcmUgYXNzdW1pbmcgdGhhdCB0aGUgc2Vy dmVyIGFwcGxpY2F0aW9uIGhhcyBhIG5vdGlvbiBvZiDigJxjb25uZWN0aW9u4oCdLCB3aGVyZWFz IG1hbnkgb2YgdGhlbSBhcmUgZGVzaWduZWQgdG8gb25seSB1bmRlcnN0YW5kIOKAnHJlcXVlc3Ti gJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SWYgYW4gYXBwIGlzIHVzaW5nIHRoZSBXaW5k b3dzIFRMUyBzdGFjaywgZWFjaCB0aW1lIGl0IHF1ZXJpZXMgdGhlIEVLTSwgYW5vdGhlciBJUEMg aXMgcmVxdWlyZWQgKHRoaXMgd2FzIGEgcmVhc29uIGZvciBub3QgcHV0dGluZyBzb21lIG9mIHRo ZSBjb250ZXh0IGZvciB0aGUgVG9rZW4gQmluZGluZyBzaWduYXR1cmUgaW4gdGhlIEVLTSBjb250 ZXh0IHZhbHVlIGFuZCBpbnN0ZWFkIGhhc2hpbmcNCiB0aGF0IGNvbnRleHQgd2l0aCB0aGUgRUtN KS48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzIGZvciB0aGlua2luZyBhYm91dCBXaW5kb3dz PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5n cyI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi4gT24gV2luZG93cywNCiBIVFRQIG1pZGRsZXdh cmUgY2FjaGVzIHRoZSBjdXJyZW50IEVLTSwgc28gdGhlcmUgaXMgbm8gbmVlZCB0byBkbyBJUEMg Zm9yIGVhY2ggcmVxdWVzdC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlJpZ2h0IG5vdywg bXkgY2xpZW50IGltcGxlbWVudGF0aW9uIGNhY2hlcyBUb2tlbiBCaW5kaW5nIHNpZ25hdHVyZXMg YnkgVEIga2V5IGFuZCB0eXBlLjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIHNvdW5kcyBsaWtl IGEgYnVnOiBFS00gc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGNhY2hlIGluZGV4LCBiZWNhdXNlIGl0 4oCZcyBwYXJ0IG9mIHRoZSBkYXRhIGJlaW5nIHNpZ25lZCBieSBhIHBhcnRpY3VsYXIgc2lnbmF0 dXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFuZHJlaTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR0301MB08428A90149E40D94FED4D9C8CDD0CY1PR0301MB0842_-- From nobody Wed Oct 12 14:35:20 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE97129673 for ; Wed, 12 Oct 2016 14:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.996 X-Spam-Level: X-Spam-Status: No, score=-4.996 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=-2.996, 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 HiJEWyYXUtWa for ; Wed, 12 Oct 2016 14:35:16 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002: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 E31BC129498 for ; Wed, 12 Oct 2016 14:35:15 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id e20so24193856ybb.0 for ; Wed, 12 Oct 2016 14:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NY7abFfbK2B9OaqBKgr6J9KwomZbzi7+3+GOq9QVw+g=; b=ckV3N4y3dhENj2gGCjgX4SCnoTicCKLfAAWRnHg+AX0OiDSTxQ6WU3+cteGbZ3SnFJ Od+7aWT29Tn9TFJ443SGVaAIlg6H3Yri5pOUrBYKyjghaOouRMh6qwBV1KByTRcllsNa EVIRwiAngjKYVmRIGg5jogNWTfXGnKT4Sm9n3eOKUFqI9zp4epiz3RRc1Ck8NG4gb1yq sGIO+KwL3ulc3ZhHVTJcD9GU62eHwsPXX7uDCVxTYdMvFKfozier+MTkBlfP4deqPUOQ Vf5iIgR7HXLqBxg0JlQH6tp7mWGhyA3f8LShsmugN+Hq7zjEi3LACQNtnpyGXvDVGGEX EdWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NY7abFfbK2B9OaqBKgr6J9KwomZbzi7+3+GOq9QVw+g=; b=Iq5nhMNkmdJOLAJNclH+Ag1f0orBDH4AnSqYKShVwXW9fIEFTzXrP5xzL4ZnIp3E3a pIdRm93lwLy6fSeuc1QILwy3uFP7uFzDc04ln0pdl0WiyjFblX4Madbxpl1BVveM210Z VPCZ4WU5OHRQd19VJLpLT8YlVZwwKhU8CHKbfp236LacDr4vJP8J9SWl7ulsmKeDfPwH 2KgIMdc0EBbUq2X621gM+AdBjHnqFE+n7Jy1+/PQuEUmSaAAOliNAkMmAHT5XkWMhgfT ikh8vHcl4PQzlS//4JyaUIGyBp4dpBX1DAUHTuPgbjpQl43QZhzBlVRmxaeI3ySyTl/n Gj5w== X-Gm-Message-State: AA6/9RkzHj7JPksjXVN+7xbMXR7UIEt20Qx47J1U8ggBy4GKEzUakHX4Qr8+3qxu+Tts3c5jGzJQe1fHacRDXpJu X-Received: by 10.37.171.178 with SMTP id v47mr2895837ybi.88.1476308115032; Wed, 12 Oct 2016 14:35:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.253.71 with HTTP; Wed, 12 Oct 2016 14:34:54 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Wed, 12 Oct 2016 14:34:54 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=94eb2c08bb82c6fe53053eb1c470 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 12 Oct 2016 21:35:18 -0000 --94eb2c08bb82c6fe53053eb1c470 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 12, 2016 at 12:17 PM, Andrei Popov wrote: > =C3=98 For this to happen, an attacker has to be able to read and write = to > the TLS stream both before and after renegotiation occurs. (Before to get > the TokenBinding to replay, and after to replay the TokenBinding with > whatever bound tokens and message the attacker wanted.) If the attacker h= as > these capabilities, the attacker could just replay the TokenBinding from > after the renegotiation, so it doesn't matter that they use the same EKM > value. > > Not necessarily: let=E2=80=99s say the initial TLS session is MITM=E2=80= =99ed and the > attacker A transparently passes messages between C and S. In the process,= A > gains access to the TB message and the token from this initial TLS sessio= n. > > With your proposal in place, now A can trigger renegotiation with S and > present the same token and the same TB message, and impersonate C from a > different machine, without access to the TB key securely stored by C. > > If the latest EKM is required after renegotiation (as it currently is, > albeit admittedly the language is flawed), A needs to generate a new > signature after renegotiation, using the latest EKM, and A can=E2=80=99t = do it > without access to the TB key. > I'm assuming that the MITM attacker A sits somewhere on the network path between C and S, that the TLS connection is between C and S (i.e. A is not terminating TLS, since otherwise that would break the TB), and that A somehow has the capability to read and write to the TLS connection (so that it can send/receive renegotiation messages). If this is the case, then A can hijack the connection and send whatever application data it wants over the existing connection (using the TB message and token it has from earlier), and drop all traffic to/from C (or send a TCP RST to C if it wants to). Which EKM is used post-renegotiation doesn't affect what A can do in this attack. In TLS 1.3, the EKM doesn't change after post-handshake auth (it also doesn't cover client certs). Using the same EKM for the whole TLS connection in 1.2 is analogous to the EKM in 1.3. I don't see any security benefits to using the new EKM. > > > =C3=98 The server needs to remember the EKM across renegotiation regardl= ess > of whether the same EKM is used for the whole connection or a new EKM is > used after renegotiation. Consider the following example with HTTP/1.1:= =E2=80=A6 > > As you note yourself, the binding can be verified at step 1, so > remembering multiple EKMs vs. verifying TBs as they arrive is an > implementation choice. I see no reason for the TB spec to lock an > implementation into one choice. > This change doesn't prevent a server from verifying TBs before renego if it wishes - it can verify before or after. This also doesn't require that a server remember multiple EKMs, it requires that it only remember one. Most likely, the server will have cached the EKM to use (instead of getting it from the TLS stack each time), and it's easier to cache just the first one than it is to cache the current one. > > > =C3=98 Requiring a lookup of the EKM on each request is expensive and ad= ds > more complexity than using the same EKM for the whole connection. > > Again, you=E2=80=99re assuming that the server application has a notion o= f > =E2=80=9Cconnection=E2=80=9D, whereas many of them are designed to only u= nderstand > =E2=80=9Crequest=E2=80=9D. > At some point in the server stack, it's aware of the connection. I agree that at some level of the server application stack, it just understands a "request". However, to process a request with Token Binding, it needs some amount of information from the connection (e.g. the EKM in the signature to verify). Whatever provides that information to the application that only understands "request" is aware of the connection, and can provide the first EKM. > > > Thanks for thinking about WindowsJ. On Windows, HTTP middleware caches > the current EKM, so there is no need to do IPC for each request. > I'm assuming then that the Windows HTTP middleware is aware of renegotiation so that it can update its cached EKM value after renegotiation occurs. A simpler caching logic to implement is to cache the first EKM from the connection. Applications that only need an EKM for Token Binding will find it easier to implement an EKM cache that caches only the first value, instead of implementing a cache that is aware of renegotiation and updates/invalidates when renegotiation happens. The complication with multiplexed protocols and TLS <=3D 1.2 isn't due to t= he use of EKM, it's due to the use of renegotiation (which is why HTTP/2 forbids renegotiation). If Token Binding is going to work with generic application protocols (which is the case as the drafts are currently set up) and with renegotiation, then it needs to specify how this problem should be handled. One possible way is to say that certain combinations aren't allowed, but it needs to say something to solve this problem. Using one EKM for the whole connection is another way to solve this problem for the generic case. Right now, I see no security benefit to using the post-renegotiation EKM (instead of the first EKM of the connection), and I see something that is harder to implement. My preference would be to completely forbid renegotiation with Token Binding, but it sounds like you have uses for it. Instead, I think this proposal provides what you need and also keeps things simple for implementations. --94eb2c08bb82c6fe53053eb1c470 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 12, 2016 at 12:17 PM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

=C3= =98=C2=A0 For this to happen, an attacker has to be able = to read and write to the TLS stream both before and after renegotiation occ= urs. (Before to get the TokenBinding to replay, and after to replay the Tok= enBinding with whatever bound tokens and message the attacker wanted.) If the attacker has these capabil= ities, the attacker could just replay the TokenBinding from after the reneg= otiation, so it doesn't matter that they use the same EKM value.

Not necessarily: let=E2=80=99s say the initial TLS session is MIT= M=E2=80=99ed and the attacker A transparently passes messages between C and= S. In the process, A gains access to the TB message and the token from this initial TLS session.

With your proposal in place, now A can trigger renegotiation with= S and present the same token and the same TB message, and impersonate C fr= om a different machine, without access to the TB key securely stored by C.

If the latest EKM is required after renegotiation (as it currentl= y is, albeit admittedly the language is flawed), A needs to generate a new = signature after renegotiation, using the latest EKM, and A can=E2=80=99t do it without access to the TB key.


I'm assuming that = the MITM attacker A sits somewhere on the network path between C and S, tha= t the TLS connection is between C and S (i.e. A is not terminating TLS, sin= ce otherwise that would break the TB), and that A somehow has the capabilit= y to read and write to the TLS connection (so that it can send/receive rene= gotiation messages). If this is the case, then A can hijack the connection = and send whatever application data it wants over the existing connection (u= sing the TB message and token it has from earlier), and drop all traffic to= /from C (or send a TCP RST to C if it wants to). Which EKM is used post-ren= egotiation doesn't affect what A can do in this attack.

<= /div>
In TLS 1.3, the EKM doesn't change after post-handshake auth = (it also doesn't cover client certs). Using the same EKM for the whole = TLS connection in 1.2 is analogous to the EKM in 1.3. I don't see any s= ecurity benefits to using the new EKM.

=C2=A0

=C3=98=C2=A0 The server needs to remember the EKM across ren= egotiation regardless of whether the same EKM is used for the whole connect= ion or a new EKM is used after renegotiation. Consider the following exampl= e with HTTP/1.1:=E2=80=A6

As you note yourself, the binding can be verified at step 1, so r= emembering multiple EKMs vs. verifying TBs as they arrive is an implementat= ion choice. I see no reason for the TB spec to lock an implementation into one choice.=C2=A0


This change doesn't prevent a= server from verifying TBs before renego if it wishes - it can verify befor= e or after. This also doesn't require that a server remember multiple E= KMs, it requires that it only remember one. Most likely, the server will ha= ve cached the EKM to use (instead of getting it from the TLS stack each tim= e), and it's easier to cache just the first one than it is to cache the= current one.=C2=A0
=

=C2=A0

=C3= =98=C2=A0 Requiring a lookup of the EKM on each request i= s expensive and adds more complexity than using the same EKM for the whole = connection.

Again, you=E2=80=99re assuming that the server application has a = notion of =E2=80=9Cconnection=E2=80=9D, whereas many of them are designed t= o only understand =E2=80=9Crequest=E2=80=9D.


At some point in the server stack, it's aware = of the connection. I agree that at some level of the server application sta= ck, it just understands a "request". However, to process a reques= t with Token Binding, it needs some amount of information from the connecti= on (e.g. the EKM in the signature to verify). Whatever provides that inform= ation to the application that only understands "request" is aware= of the connection, and can provide the first EKM.=C2=A0

=C2=A0

Thanks for thinking about WindowsJ. On Windows, HTTP middleware caches the current EKM, so there is no need to do IPC for = each request.


I'= m assuming then that the Windows HTTP middleware is aware of renegotiation = so that it can update its cached EKM value after renegotiation occurs. A si= mpler caching logic to implement is to cache the first EKM from the connect= ion. Applications that only need an EKM for Token Binding will find it easi= er to implement an EKM cache that caches only the first value, instead of i= mplementing a cache that is aware of renegotiation and updates/invalidates = when renegotiation happens.

The complication with = multiplexed protocols and TLS <=3D 1.2 isn't due to the use of EKM, = it's due to the use of renegotiation (which is why HTTP/2 forbids reneg= otiation). If Token Binding is going to work with generic application proto= cols (which is the case as the drafts are currently set up) and with renego= tiation, then it needs to specify how this problem should be handled. One p= ossible way is to say that certain combinations aren't allowed, but it = needs to say something to solve this problem. Using one EKM for the whole c= onnection is another way to solve this problem for the generic case.
<= div>
Right now, I see no security benefit to using the post-r= enegotiation EKM (instead of the first EKM of the connection), and I see so= mething that is harder to implement. My preference would be to completely f= orbid renegotiation with Token Binding, but it sounds like you have uses fo= r it. Instead, I think this proposal provides what you need and also keeps = things simple for implementations.
--94eb2c08bb82c6fe53053eb1c470-- From nobody Thu Oct 13 12:54:04 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064BF129554 for ; Thu, 13 Oct 2016 12:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 V1ycRIdDFv4L for ; Thu, 13 Oct 2016 12:54:01 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 E51FB129448 for ; Thu, 13 Oct 2016 12:54:00 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id i202so97354775ioi.2 for ; Thu, 13 Oct 2016 12:54:00 -0700 (PDT) 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=QvVO+KlbZu8kKWDak0OgMHzZGYgd5kjuc2n5TdstlYM=; b=DFeeJFvkGhaoCRFTr1csdbgQip8N1lfPFey7JIdfgnDNqNONbGjtHNxgmGZQSF0Xbl sgRNiz1OOH4qQNk9AxepEzUUWP6xw5ABhA2QcuUvsafugkwaVt8vLZqD8KbnyvmF5g9B 9JpKkWPWoMumPKG2uGvvB79CabX9SjaLqudaI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QvVO+KlbZu8kKWDak0OgMHzZGYgd5kjuc2n5TdstlYM=; b=IOWPJQuUNYdlC9GD+Ez/QnW8jqeVfxXsPU/ZBiwyCByNh4wh/TDD+M+p/YNMT1eUB/ mwYIZce1mPwP6KfygJxAY4KFQEp8J4Qtwz5vWcDrv1V0jij3y+AFM9di+imLp+ej1hKg ChUjacZhp/J78PFqVMb8xbWSI7qyou9KB0Zgbtd0QFzOEXe1V+Z0Q2bfQghxrYPgvoDM JtLNfTTDiurmFBXaTJXbWWWrZQqc7F/1I9b5LeeRw68dAGX6GfXtAF0scgH3iKVjE4nb cJv43sh5KtMuKeArH62CZJCjaTcpsuLgR9h7/ZSyRr0HGmbeEyAGquVcoXpIdyWuLTxB Cb4Q== X-Gm-Message-State: AA6/9Rm6NyqvN+YRwxhmpb5wigpvQZatbm2cO7nTf6HBSZK15YVubdthSKpO+mQKc//0mF1ED0+n9Lwn1V6tFmg2 X-Received: by 10.107.201.17 with SMTP id z17mr8587034iof.156.1476388439781; Thu, 13 Oct 2016 12:53:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.5.148 with HTTP; Thu, 13 Oct 2016 12:53:29 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 13 Oct 2016 13:53:29 -0600 Message-ID: To: Nick Harper Content-Type: multipart/alternative; boundary=94eb2c0c1184810c43053ec478bc Archived-At: Cc: Andrei Popov , IETF Tokbind WG Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 13 Oct 2016 19:54:04 -0000 --94eb2c0c1184810c43053ec478bc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Given the current intent of the draft, where renegotiation is allowed and the EKM is from the current or most recent TLS session/connection, how is a server expected to handle things when renegotiation happens? In some (many/all?) cases, for a period of time around renegotiation the server can't know for sure if a TB message was prepared with the before EKM or the after EKM. To work reliably it seems like the server would need to retain both EKM values for a short but not entirely determinate period of time and check the TB signature over both. That seems cumbersome. Nick's proposal addresses that issue (though I'm not sure if it's the *right* thing to do or not). Disallowing renegotiation with Token Binding would also address it (but Andrei has stated a need for it). But I agree that the draft(s) should say something to solve this problem or provide guidance. On Wed, Oct 12, 2016 at 3:34 PM, Nick Harper wrote: > > > On Wed, Oct 12, 2016 at 12:17 PM, Andrei Popov > wrote: > >> =C3=98 For this to happen, an attacker has to be able to read and write= to >> the TLS stream both before and after renegotiation occurs. (Before to ge= t >> the TokenBinding to replay, and after to replay the TokenBinding with >> whatever bound tokens and message the attacker wanted.) If the attacker = has >> these capabilities, the attacker could just replay the TokenBinding from >> after the renegotiation, so it doesn't matter that they use the same EKM >> value. >> >> Not necessarily: let=E2=80=99s say the initial TLS session is MITM=E2=80= =99ed and the >> attacker A transparently passes messages between C and S. In the process= , A >> gains access to the TB message and the token from this initial TLS sessi= on. >> >> With your proposal in place, now A can trigger renegotiation with S and >> present the same token and the same TB message, and impersonate C from a >> different machine, without access to the TB key securely stored by C. >> >> If the latest EKM is required after renegotiation (as it currently is, >> albeit admittedly the language is flawed), A needs to generate a new >> signature after renegotiation, using the latest EKM, and A can=E2=80=99t= do it >> without access to the TB key. >> > > I'm assuming that the MITM attacker A sits somewhere on the network path > between C and S, that the TLS connection is between C and S (i.e. A is no= t > terminating TLS, since otherwise that would break the TB), and that A > somehow has the capability to read and write to the TLS connection (so th= at > it can send/receive renegotiation messages). If this is the case, then A > can hijack the connection and send whatever application data it wants ove= r > the existing connection (using the TB message and token it has from > earlier), and drop all traffic to/from C (or send a TCP RST to C if it > wants to). Which EKM is used post-renegotiation doesn't affect what A can > do in this attack. > > In TLS 1.3, the EKM doesn't change after post-handshake auth (it also > doesn't cover client certs). Using the same EKM for the whole TLS > connection in 1.2 is analogous to the EKM in 1.3. I don't see any securit= y > benefits to using the new EKM. > >> >> >> =C3=98 The server needs to remember the EKM across renegotiation regard= less >> of whether the same EKM is used for the whole connection or a new EKM is >> used after renegotiation. Consider the following example with HTTP/1.1:= =E2=80=A6 >> >> As you note yourself, the binding can be verified at step 1, so >> remembering multiple EKMs vs. verifying TBs as they arrive is an >> implementation choice. I see no reason for the TB spec to lock an >> implementation into one choice. >> > > This change doesn't prevent a server from verifying TBs before renego if > it wishes - it can verify before or after. This also doesn't require that= a > server remember multiple EKMs, it requires that it only remember one. Mos= t > likely, the server will have cached the EKM to use (instead of getting it > from the TLS stack each time), and it's easier to cache just the first on= e > than it is to cache the current one. > >> >> >> =C3=98 Requiring a lookup of the EKM on each request is expensive and a= dds >> more complexity than using the same EKM for the whole connection. >> >> Again, you=E2=80=99re assuming that the server application has a notion = of >> =E2=80=9Cconnection=E2=80=9D, whereas many of them are designed to only = understand >> =E2=80=9Crequest=E2=80=9D. >> > > At some point in the server stack, it's aware of the connection. I agree > that at some level of the server application stack, it just understands a > "request". However, to process a request with Token Binding, it needs som= e > amount of information from the connection (e.g. the EKM in the signature = to > verify). Whatever provides that information to the application that only > understands "request" is aware of the connection, and can provide the fir= st > EKM. > >> >> >> Thanks for thinking about WindowsJ. On Windows, HTTP middleware caches >> the current EKM, so there is no need to do IPC for each request. >> > > I'm assuming then that the Windows HTTP middleware is aware of > renegotiation so that it can update its cached EKM value after > renegotiation occurs. A simpler caching logic to implement is to cache th= e > first EKM from the connection. Applications that only need an EKM for Tok= en > Binding will find it easier to implement an EKM cache that caches only th= e > first value, instead of implementing a cache that is aware of renegotiati= on > and updates/invalidates when renegotiation happens. > > The complication with multiplexed protocols and TLS <=3D 1.2 isn't due to > the use of EKM, it's due to the use of renegotiation (which is why HTTP/2 > forbids renegotiation). If Token Binding is going to work with generic > application protocols (which is the case as the drafts are currently set > up) and with renegotiation, then it needs to specify how this problem > should be handled. One possible way is to say that certain combinations > aren't allowed, but it needs to say something to solve this problem. Usin= g > one EKM for the whole connection is another way to solve this problem for > the generic case. > > Right now, I see no security benefit to using the post-renegotiation EKM > (instead of the first EKM of the connection), and I see something that is > harder to implement. My preference would be to completely forbid > renegotiation with Token Binding, but it sounds like you have uses for it= . > Instead, I think this proposal provides what you need and also keeps thin= gs > simple for implementations. > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --94eb2c0c1184810c43053ec478bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Given the current intent of the draft, where rene= gotiation is=20 allowed and the EKM is from the current or most recent TLS=20 session/connection, how is a server expected to handle things when=20 renegotiation happens? In some (many/all?) cases, for a period of time arou= nd renegotiation the=20 server can't know for sure if a TB message was prepared with the before= =20 EKM or the after EKM. To work reliably it seems like the server would=20 need to retain both EKM values for a short but not entirely determinate=20 period of time and check the TB signature over both. That seems cumbersome.= Nick's proposal addresses that issue (though I'm not sure if it= 9;s the *right* thing to do or not). Disallowing renegotiation with Token B= inding would also address it (but Andrei has stated a need for it). But I a= gree that the draft(s) should say something to solve this problem or provid= e guidance.

On Wed, Oct 12, 2016 at 3:34 PM, Nick Harper &= lt;nharper@google.c= om> wrote:


On Wed, Oct 12, 2016 at 12:17 PM, Andrei Popov <= Andrei.Popo= v@microsoft.com> wrote:

=C3=98=C2=A0 For this to happen, an attacker has to be able = to read and write to the TLS stream both before and after renegotiation occ= urs. (Before to get the TokenBinding to replay, and after to replay the Tok= enBinding with whatever bound tokens and message the attacker wanted.) If the attacker has these capabil= ities, the attacker could just replay the TokenBinding from after the reneg= otiation, so it doesn't matter that they use the same EKM value.

Not necessarily: let=E2=80=99s say the initial TLS session is MIT= M=E2=80=99ed and the attacker A transparently passes messages between C and= S. In the process, A gains access to the TB message and the token from this initial TLS session.

With your proposal in place, now A can trigger renegotiation with= S and present the same token and the same TB message, and impersonate C fr= om a different machine, without access to the TB key securely stored by C.

If the latest EKM is required after renegotiation (as it currentl= y is, albeit admittedly the language is flawed), A needs to generate a new = signature after renegotiation, using the latest EKM, and A can=E2=80=99t do it without access to the TB key.


I'm assumin= g that the MITM attacker A sits somewhere on the network path between C and= S, that the TLS connection is between C and S (i.e. A is not terminating T= LS, since otherwise that would break the TB), and that A somehow has the ca= pability to read and write to the TLS connection (so that it can send/recei= ve renegotiation messages). If this is the case, then A can hijack the conn= ection and send whatever application data it wants over the existing connec= tion (using the TB message and token it has from earlier), and drop all tra= ffic to/from C (or send a TCP RST to C if it wants to). Which EKM is used p= ost-renegotiation doesn't affect what A can do in this attack.

In TLS 1.3, the EKM doesn't change after post-handshak= e auth (it also doesn't cover client certs). Using the same EKM for the= whole TLS connection in 1.2 is analogous to the EKM in 1.3. I don't se= e any security benefits to using the new EKM.

=C2=A0

=C3=98=C2=A0 The server needs to remember the EKM across ren= egotiation regardless of whether the same EKM is used for the whole connect= ion or a new EKM is used after renegotiation. Consider the following exampl= e with HTTP/1.1:=E2=80=A6

As you note yourself, the binding can be verified at step 1, so r= emembering multiple EKMs vs. verifying TBs as they arrive is an implementat= ion choice. I see no reason for the TB spec to lock an implementation into one choice.=C2=A0


This change doesn't pr= event a server from verifying TBs before renego if it wishes - it can verif= y before or after. This also doesn't require that a server remember mul= tiple EKMs, it requires that it only remember one. Most likely, the server = will have cached the EKM to use (instead of getting it from the TLS stack e= ach time), and it's easier to cache just the first one than it is to ca= che the current one.=C2=A0

=C2=A0

=C3=98=C2=A0 Requiring a lookup of the EKM on each request i= s expensive and adds more complexity than using the same EKM for the whole = connection.

Again, you=E2=80=99re assuming that the server application has a = notion of =E2=80=9Cconnection=E2=80=9D, whereas many of them are designed t= o only understand =E2=80=9Crequest=E2=80=9D.


At some point in the server stack, it's= aware of the connection. I agree that at some level of the server applicat= ion stack, it just understands a "request". However, to process a= request with Token Binding, it needs some amount of information from the c= onnection (e.g. the EKM in the signature to verify). Whatever provides that= information to the application that only understands "request" i= s aware of the connection, and can provide the first EKM.=C2=A0

=C2=A0

Thanks for thinking about WindowsJ. On Windows, HTTP middleware caches the current EKM, so there is no need to do IPC for = each request.


I'm assuming then that the Windows HTTP middleware is aware of renegot= iation so that it can update its cached EKM value after renegotiation occur= s. A simpler caching logic to implement is to cache the first EKM from the = connection. Applications that only need an EKM for Token Binding will find = it easier to implement an EKM cache that caches only the first value, inste= ad of implementing a cache that is aware of renegotiation and updates/inval= idates when renegotiation happens.

The complicatio= n with multiplexed protocols and TLS <=3D 1.2 isn't due to the use o= f EKM, it's due to the use of renegotiation (which is why HTTP/2 forbid= s renegotiation). If Token Binding is going to work with generic applicatio= n protocols (which is the case as the drafts are currently set up) and with= renegotiation, then it needs to specify how this problem should be handled= . One possible way is to say that certain combinations aren't allowed, = but it needs to say something to solve this problem. Using one EKM for the = whole connection is another way to solve this problem for the generic case.=

Right now, I see no security benefit to using the= post-renegotiation EKM (instead of the first EKM of the connection), and I= see something that is harder to implement. My preference would be to compl= etely forbid renegotiation with Token Binding, but it sounds like you have = uses for it. Instead, I think this proposal provides what you need and also= keeps things simple for implementations.

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


--94eb2c0c1184810c43053ec478bc-- From nobody Thu Oct 13 13:07:03 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8462C1295DC for ; Thu, 13 Oct 2016 13:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 XwzpwsSD1Xyn for ; Thu, 13 Oct 2016 13:07:00 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 D594212954D for ; Thu, 13 Oct 2016 13:06:59 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id k64so251773itb.0 for ; Thu, 13 Oct 2016 13:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:cc; bh=Ezk0hbEYJ5f3ekOS07mfl09M7UhmIB6MXLDTkjW7cOM=; b=gw+ULrZtYA7mi7Q1tOP0BTSsyOufeohrP89dgFpZtORvguAaoGyycOuMeR9HZVn4ks lSbnTeqPQtD7I266BnYsORXk50eJ5MsuADA4orRLAqxSP/Lj+P5yg8RRkkVDqMliuWJw XZ9C2EpfBMs4xNBZsdZ1SOceT4qgIbIa1S82M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Ezk0hbEYJ5f3ekOS07mfl09M7UhmIB6MXLDTkjW7cOM=; b=AHJhvvXhYLIXvKLJOGKT0G/WGM/ValNM1QMwinE4BB9Bd6dMn74vTc4geOHpNw9OlP A/xrdpvh8A93yWzdBz9bMr7ijUJ4DPbn5+L1Jm8SqPotTJe98K9a6WfCVRELb+S7mvXB LC7U3aeGpakGSXp0L7/b20pIpR+F3MS6gw1lOsYQGUsw4rDkjh0gE7DC4fRzpNEQQNxk JVjg9UfdBTI61mJ/jo0CDYZGpwoTei4hz85AEhJiiiTXRtq9FJ4KVckEc0bOD4Uh/lUI VuJiFhUJ/yT0cOs73goswWOYH/A9rnYc93Nl6C2YExWnc5OFYKg6uJCTi7zGwe2mGOPP rXgQ== X-Gm-Message-State: AA6/9RmanW2XGNxlb41WHqTvcyHCWbOMIJTci/hGm5pJSnolXMzyzq0W5Be5CsTHTFL93Dvh9c0efMexUjJAtDrK X-Received: by 10.36.87.130 with SMTP id u124mr8312185ita.35.1476389218673; Thu, 13 Oct 2016 13:06:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.5.148 with HTTP; Thu, 13 Oct 2016 13:06:28 -0700 (PDT) From: Brian Campbell Date: Thu, 13 Oct 2016 14:06:28 -0600 Message-ID: To: Nick Harper Content-Type: multipart/alternative; boundary=001a11436eb8ee0239053ec4a6f0 Archived-At: Cc: IETF Tokbind WG Subject: [Unbearable] clarification question (was Re: Clarifying Token Binding behavior with renegotiation) 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, 13 Oct 2016 20:07:01 -0000 --001a11436eb8ee0239053ec4a6f0 Content-Type: text/plain; charset=UTF-8 Practically isn't the EKM obtained from the PRF and master secret of the TLS session and the client and server random values are from the handshake that set up the current TLS connection? That's the behavior I've seen with Chrome. When multiple connections are established via abbreviated handshake, each connection has a different EKM for TB because the client and server random values differ. On Fri, Oct 7, 2016 at 5:52 PM, Nick Harper wrote: > > Section 3.3 of TBPROTO specifies that the EKM is obtained from the current > current TLS connection, but RFC 5705 states that the exporter is associated > with a TLS session (more specifically, a set of SecurityParameters). > > --001a11436eb8ee0239053ec4a6f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Practically isn't the EKM obtained from the PRF a= nd master secret of the TLS session and the client and server random values= are from the handshake that set up the current TLS connection?

That's the behavior I've seen with Chrome. When multiple connecti= ons are established via abbreviated handshake, each connection has a differ= ent EKM for TB because the client and server random values differ.=C2=A0


On Fri, Oct 7, 2016 at 5:52 PM, Nick Harper <nharper@google.com&g= t; wrote:

Section 3.3 of TBPROTO specifies that the E= KM is obtained from the current current TLS connection, but RFC 5705 states= that the exporter is associated with a TLS session (more specifically, a s= et of SecurityParameters).



<= /div>
--001a11436eb8ee0239053ec4a6f0-- From nobody Thu Oct 13 13:22:02 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F04129666 for ; Thu, 13 Oct 2016 13:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.996 X-Spam-Level: X-Spam-Status: No, score=-4.996 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=-2.996, 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 4eCDzaJjjGPd for ; Thu, 13 Oct 2016 13:21:58 -0700 (PDT) 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 6B509129662 for ; Thu, 13 Oct 2016 13:21:57 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id o189so10146329yba.1 for ; Thu, 13 Oct 2016 13:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=61XNHwdLoBxgkFqUQeyOPNnbfow1c2arZyoItt2Frjs=; b=QrJxjdKgvR5iMLYC3KPgiIpjFhze4AGFsl1xAvkz7Gfu0hUY96qswjORJhHun+NcQd MMLOfptJe3r7/j7jVNradeO6ktM5He63I8pkio3W+pp+z4vU4E9uK+fL2QdlZ+ZANCvE eYdoDx4se2TP7KTcOnwl5/3QgPCoELrx+1t9zFiit7CVBz8SyTbCu1ZHwCGPP5o1z63s meGf20l3sttOvjBwKnKLU8e0HRLK9eGTvMlnCKUwijMmvsXRk8GEinK2Im/dwTTnHcxk 20BG4KPCPRlKvnXIVW+Dnwle+wPLMAAWMCwhLKPyyq5k+QJkQ4/Fct6+2MnWoBQfMzRv Mz3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=61XNHwdLoBxgkFqUQeyOPNnbfow1c2arZyoItt2Frjs=; b=kOqAAwe2ppPUQcLDpgfcC62ELpngqEh7t0tSJdYVbvPuU6BdOVz7E5xmvkIixJBfny vWXqMHdOzFfgx+Yp6/RxBlz2jobNs21RjOllgv1fmySKWsaELsExvx9avQUmm+gSjOOb ukI1MdaVkEBvD9WzFL4TNC1ZJzT9Ba+ruecLjb+jRFRJKO2zyfVWB1fFiPZ0A2mfYa2Z kU7V9DLLKfq6ykQadXM49dI9I2sKPF5msrrdy8CbcloeL+dhtaROJAB6U2WwwzrszciU ZJ0ATFheXt0kf5odU6DsVho24Zs0i00u59N5ca9Ozm/H9J6Hn32oE4CYFCbIPBRQW90e u/uw== X-Gm-Message-State: AA6/9RlZdZjl0SBJGkqvkBsQoOPHR0kop4Lk31Hu54DtH5phaXePg/g4dnSAm6aLpAx6zF8MxgWzIhObdlm6TUus X-Received: by 10.37.214.12 with SMTP id n12mr7095454ybg.164.1476390116565; Thu, 13 Oct 2016 13:21:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.253.71 with HTTP; Thu, 13 Oct 2016 13:21:36 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Thu, 13 Oct 2016 13:21:36 -0700 Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary=001a114fcb70730446053ec4dc15 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] clarification question (was Re: Clarifying Token Binding behavior with renegotiation) 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, 13 Oct 2016 20:22:00 -0000 --001a114fcb70730446053ec4dc15 Content-Type: text/plain; charset=UTF-8 The EKM is computed from the SecurityParameters, which include the client and server random values from the latest handshake on the TLS connection. (The EKM definition also includes SecurityParameters.master_secret, which is from the TLS session.) I think there's nomenclature confusion here, since TLS session commonly means the thing with the master secret that can be resumed. Perhaps it would have been more accurate to say that an EKM is dependent on both the TLS connection and the TLS session? You're correct that when a TLS session is resumed multiple times, each connection for resumption has a different EKM. On Thu, Oct 13, 2016 at 1:06 PM, Brian Campbell wrote: > Practically isn't the EKM obtained from the PRF and master secret of the > TLS session and the client and server random values are from the handshake > that set up the current TLS connection? > > That's the behavior I've seen with Chrome. When multiple connections are > established via abbreviated handshake, each connection has a different EKM > for TB because the client and server random values differ. > > > On Fri, Oct 7, 2016 at 5:52 PM, Nick Harper wrote: > >> >> Section 3.3 of TBPROTO specifies that the EKM is obtained from the >> current current TLS connection, but RFC 5705 states that the exporter is >> associated with a TLS session (more specifically, a set of >> SecurityParameters). >> >> > > > --001a114fcb70730446053ec4dc15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The EKM is computed from the SecurityParameters, which inc= lude the client and server random values from the latest handshake on the T= LS connection. (The EKM definition also includes SecurityParameters.master_= secret, which is from the TLS session.) I think there's nomenclature co= nfusion here, since TLS session commonly means the thing with the master se= cret that can be resumed. Perhaps it would have been more accurate to say t= hat an EKM is dependent on both the TLS connection and the TLS session?
You're correct that when a TLS session is resumed multi= ple times, each connection for resumption has a different EKM.
<= div class=3D"gmail_extra">
On Thu, Oct 13, 20= 16 at 1:06 PM, Brian Campbell <bcampbell@pingidentity.com>= wrote:
Prac= tically isn't the EKM obtained from the PRF and master secret of the TL= S session and the client and server random values are from the handshake th= at set up the current TLS connection?

That's the behavior = I've seen with Chrome. When multiple connections are established via ab= breviated handshake, each connection has a different EKM for TB because the= client and server random values differ.=C2=A0


On Fri, Oct 7, 2016 at= 5:52 PM, Nick Harper <nharper@google.com> wrote:

Section 3.3 of TBPROTO specifies that the EKM is obtained from the cu= rrent current TLS connection, but RFC 5705 states that the exporter is asso= ciated with a TLS session (more specifically, a set of SecurityParameters).=





--001a114fcb70730446053ec4dc15-- From nobody Thu Oct 13 13:45:01 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08E912946B for ; Thu, 13 Oct 2016 13:44:59 -0700 (PDT) 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 CbKHTQ45C9XX for ; Thu, 13 Oct 2016 13:44:57 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0136.outbound.protection.outlook.com [104.47.36.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B368F12960A for ; Thu, 13 Oct 2016 13:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QqNuAcRvEK7dhGINr+z7Y0TaSmnPeS9bUjWzb73j4CA=; b=JTPREArcgdLlnyc8BOq8rgVwSD83K4Gv8ENjKnOrkTa3k5IIW+Fnnn7PjcFPHW15iHi7sXJcqsgjjqGvD8/uWgXhbqrh4k5PqMRKtzlH0kTKBq2Su3MIYtkKAxmgogJVpd0G7X7hBZ0kgkaGNgdMDpYIa4Qg55EBcOUFNO2o6PI= 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.649.16; Thu, 13 Oct 2016 20:44:55 +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.0649.027; Thu, 13 Oct 2016 20:44:55 +0000 From: Andrei Popov To: Brian Campbell , Nick Harper Thread-Topic: [Unbearable] clarification question (was Re: Clarifying Token Binding behavior with renegotiation) Thread-Index: AQHSJY1i86mHvH0RyE6XmdNXmYTpeqCm2Y2w Date: Thu, 13 Oct 2016 20:44: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::1d2] x-ms-office365-filtering-correlation-id: 44b49cfc-3993-41f6-0757-08d3f3a9ca07 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0843; 7:metoiHM8V7C24ZxSPhlKw06T7PeNInqA1EXIXSg/XGEYeddBgSsMD0OKci4mD7K8D3sjVrvQXIHmGiZFG0p2RaOiflmaFD8lQa36feHfUSRg/DVnejTm9QywKCpgpSt1OcYnYSzVrvD3NERmEJo1/0cJ2U1KaXbE/vUpmEo05+xQX/JNNsA5svHWWuOVIO4m8BxOcLsxwB+mdE4CyF+XZj/T6lliY3jN6xMH2WKJcExKYqkt68pcnBSCRjkKmWcifp5Bhvggx/lw2Zu4i4/RJzvkUDAvaNnTeXCOJuxHjnZgV5lksi0T5UX5D8LEo0V+qv+R1EJK2t9iDT8xrq8YC0Z2sN6kyMVbm+UH/GCB/2A4wB0X02yWXLZRD/hiZe1/ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0843; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0843; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0843; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(189002)(377454003)(199003)(2900100001)(86612001)(5002640100001)(99286002)(81166006)(77096005)(7696004)(19580395003)(19580405001)(7736002)(3660700001)(92566002)(3280700002)(7846002)(4326007)(19625215002)(15975445007)(11100500001)(87936001)(790700001)(2950100002)(102836003)(586003)(97736004)(6116002)(33656002)(5001770100001)(54356999)(76176999)(50986999)(68736007)(86362001)(74316002)(5005710100001)(2906002)(10400500002)(16236675004)(8936002)(122556002)(5660300001)(10090500001)(10290500002)(8676002)(8990500004)(189998001)(106116001)(105586002)(76576001)(81156014)(101416001)(106356001)(9686002)(19300405004)(3826002); 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_CY1PR0301MB0842C36B331586CFBDF7D75C8CDC0CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2016 20:44:55.0810 (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] clarification question (was Re: Clarifying Token Binding behavior with renegotiation) 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, 13 Oct 2016 20:45:00 -0000 --_000_CY1PR0301MB0842C36B331586CFBDF7D75C8CDC0CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIFByYWN0aWNhbGx5IGlzbid0IHRoZSBFS00gb2J0YWluZWQgZnJvbSB0aGUgUFJGIGFuZCBt YXN0ZXIgc2VjcmV0IG9mIHRoZSBUTFMgc2Vzc2lvbiBhbmQgdGhlIGNsaWVudCBhbmQgc2VydmVy IHJhbmRvbSB2YWx1ZXMgYXJlIGZyb20gdGhlIGhhbmRzaGFrZSB0aGF0IHNldCB1cCB0aGUgY3Vy cmVudCBUTFMgY29ubmVjdGlvbj8NCkNvcnJlY3QsIHRoZSBFS00gaXMgZGlmZmVyZW50IGluIGVh Y2ggcmVzdW1lZCBUTFMgY29ubmVjdGlvbiwgYW5kIGluIGVhY2ggcmVuZWdvdGlhdGVkIFRMUyBz ZXNzaW9uLiBUaGlzIGlzIHdoeSB3ZSBjYW4gdXNlIEVLTSB0byBwcm92ZSBwb3NzZXNzaW9uIG9m IHRoZSBUQiBrZXlz4pi6Lg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBVbmJlYXJhYmxl IFttYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4g Q2FtcGJlbGwNClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDEzLCAyMDE2IDE6MDYgUE0NClRvOiBO aWNrIEhhcnBlciA8bmhhcnBlckBnb29nbGUuY29tPg0KQ2M6IElFVEYgVG9rYmluZCBXRyA8dW5i ZWFyYWJsZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtVbmJlYXJhYmxlXSBjbGFyaWZpY2F0aW9uIHF1 ZXN0aW9uICh3YXMgUmU6IENsYXJpZnlpbmcgVG9rZW4gQmluZGluZyBiZWhhdmlvciB3aXRoIHJl bmVnb3RpYXRpb24pDQoNClByYWN0aWNhbGx5IGlzbid0IHRoZSBFS00gb2J0YWluZWQgZnJvbSB0 aGUgUFJGIGFuZCBtYXN0ZXIgc2VjcmV0IG9mIHRoZSBUTFMgc2Vzc2lvbiBhbmQgdGhlIGNsaWVu dCBhbmQgc2VydmVyIHJhbmRvbSB2YWx1ZXMgYXJlIGZyb20gdGhlIGhhbmRzaGFrZSB0aGF0IHNl dCB1cCB0aGUgY3VycmVudCBUTFMgY29ubmVjdGlvbj8NClRoYXQncyB0aGUgYmVoYXZpb3IgSSd2 ZSBzZWVuIHdpdGggQ2hyb21lLiBXaGVuIG11bHRpcGxlIGNvbm5lY3Rpb25zIGFyZSBlc3RhYmxp c2hlZCB2aWEgYWJicmV2aWF0ZWQgaGFuZHNoYWtlLCBlYWNoIGNvbm5lY3Rpb24gaGFzIGEgZGlm ZmVyZW50IEVLTSBmb3IgVEIgYmVjYXVzZSB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIgcmFuZG9tIHZh bHVlcyBkaWZmZXIuDQoNCg0KT24gRnJpLCBPY3QgNywgMjAxNiBhdCA1OjUyIFBNLCBOaWNrIEhh cnBlciA8bmhhcnBlckBnb29nbGUuY29tPG1haWx0bzpuaGFycGVyQGdvb2dsZS5jb20+PiB3cm90 ZToNCg0KU2VjdGlvbiAzLjMgb2YgVEJQUk9UTyBzcGVjaWZpZXMgdGhhdCB0aGUgRUtNIGlzIG9i dGFpbmVkIGZyb20gdGhlIGN1cnJlbnQgY3VycmVudCBUTFMgY29ubmVjdGlvbiwgYnV0IFJGQyA1 NzA1IHN0YXRlcyB0aGF0IHRoZSBleHBvcnRlciBpcyBhc3NvY2lhdGVkIHdpdGggYSBUTFMgc2Vz c2lvbiAobW9yZSBzcGVjaWZpY2FsbHksIGEgc2V0IG9mIFNlY3VyaXR5UGFyYW1ldGVycykuDQoN Cg0KDQo= --_000_CY1PR0301MB0842C36B331586CFBDF7D75C8CDC0CY1PR0301MB0842_ 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 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjkxMzkwMTM5NTsNCgltc28t bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTQyNzg4ODUyNiAtMTA5 NjE0OTY2OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0 YXJ0LWF0OjM7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGlu O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+UHJhY3RpY2FsbHkgaXNuJ3QgdGhlIEVL TSBvYnRhaW5lZCBmcm9tIHRoZSBQUkYgYW5kIG1hc3RlciBzZWNyZXQgb2YgdGhlIFRMUyBzZXNz aW9uIGFuZCB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIgcmFuZG9tIHZhbHVlcyBhcmUgZnJvbSB0aGUg aGFuZHNoYWtlIHRoYXQgc2V0IHVwIHRoZSBjdXJyZW50IFRMUyBjb25uZWN0aW9uPzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Db3JyZWN0LCB0 aGUgRUtNIGlzIGRpZmZlcmVudCBpbiBlYWNoIHJlc3VtZWQgVExTIGNvbm5lY3Rpb24sIGFuZCBp biBlYWNoIHJlbmVnb3RpYXRlZCBUTFMgc2Vzc2lvbi4gVGhpcyBpcyB3aHkgd2UgY2FuIHVzZSBF S00gdG8gcHJvdmUgcG9zc2Vzc2lvbiBvZiB0aGUgVEIga2V5czwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3MiPko8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kcmVpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBVbmJlYXJh YmxlIFttYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5CcmlhbiBDYW1wYmVsbDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgT2N0b2JlciAx MywgMjAxNiAxOjA2IFBNPGJyPg0KPGI+VG86PC9iPiBOaWNrIEhhcnBlciAmbHQ7bmhhcnBlckBn b29nbGUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBUb2tiaW5kIFdHICZsdDt1bmJlYXJh YmxlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbVW5iZWFyYWJsZV0gY2xhcmlm aWNhdGlvbiBxdWVzdGlvbiAod2FzIFJlOiBDbGFyaWZ5aW5nIFRva2VuIEJpbmRpbmcgYmVoYXZp b3Igd2l0aCByZW5lZ290aWF0aW9uKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlByYWN0aWNhbGx5IGlzbid0 IHRoZSBFS00gb2J0YWluZWQgZnJvbSB0aGUgUFJGIGFuZCBtYXN0ZXIgc2VjcmV0IG9mIHRoZSBU TFMgc2Vzc2lvbiBhbmQgdGhlIGNsaWVudCBhbmQgc2VydmVyIHJhbmRvbSB2YWx1ZXMgYXJlIGZy b20gdGhlIGhhbmRzaGFrZSB0aGF0IHNldCB1cCB0aGUgY3VycmVudCBUTFMgY29ubmVjdGlvbj88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCdzIHRoZSBi ZWhhdmlvciBJJ3ZlIHNlZW4gd2l0aCBDaHJvbWUuIFdoZW4gbXVsdGlwbGUgY29ubmVjdGlvbnMg YXJlIGVzdGFibGlzaGVkIHZpYSBhYmJyZXZpYXRlZCBoYW5kc2hha2UsIGVhY2ggY29ubmVjdGlv biBoYXMgYSBkaWZmZXJlbnQgRUtNIGZvciBUQiBiZWNhdXNlIHRoZSBjbGllbnQgYW5kIHNlcnZl ciByYW5kb20gdmFsdWVzIGRpZmZlci4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBPY3QgNywgMjAxNiBhdCA1OjUyIFBNLCBOaWNr IEhhcnBlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPm5oYXJwZXJAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9u IDMuMyBvZiBUQlBST1RPIHNwZWNpZmllcyB0aGF0IHRoZSBFS00gaXMgb2J0YWluZWQgZnJvbSB0 aGUgY3VycmVudCBjdXJyZW50IFRMUyBjb25uZWN0aW9uLCBidXQgUkZDIDU3MDUgc3RhdGVzIHRo YXQgdGhlIGV4cG9ydGVyIGlzIGFzc29jaWF0ZWQgd2l0aCBhIFRMUyBzZXNzaW9uIChtb3JlIHNw ZWNpZmljYWxseSwgYSBzZXQgb2YgU2VjdXJpdHlQYXJhbWV0ZXJzKS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR0301MB0842C36B331586CFBDF7D75C8CDC0CY1PR0301MB0842_-- From nobody Thu Oct 13 13:55:40 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC16129544 for ; Thu, 13 Oct 2016 13:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ClBH95cI69hV for ; Thu, 13 Oct 2016 13:55:37 -0700 (PDT) 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 E5F671295CE for ; Thu, 13 Oct 2016 13:55:36 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id l13so195685964itl.1 for ; Thu, 13 Oct 2016 13:55:36 -0700 (PDT) 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=a8FXAe5/3Vsz0x+bDXTo6tEWgno34fY6Oip7e+jT0jI=; b=pVFX4vYhd2gbul9TEa1qEA7ax54XLhMHAaKUZ0Mm2u3UNMQxAAmGjh9GBcVgFJiYwz ZNQvzEDrptV/OhtR9dgwSS5Bh7iu9pVwZ3zBzRhdUF4mxIB+QsE6eo3CW9H5Z5dZGfQd lFYcQ6zvvEuxPuYs4PBRFag97FrD73Y2GNd8M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a8FXAe5/3Vsz0x+bDXTo6tEWgno34fY6Oip7e+jT0jI=; b=YGc5gQxA5ImNbrU/vvHz5usWGvm3rS0QawLTOH06nXZbPWvR4dVc+bns+h5+C/x1G8 S0/Y5JK0WJz9YavcJWoeG8z7btfLDtWH2+4Hk05JW6YI9DYXo4o1BocCATDjM2B5Av9/ B7mNDxkcHsWZ8rHX2hlviSuTFkwY/DZkzkYnl3H9AeplMeYNYP2WwWQMU/AavS6u2uNO RqmNmS/etL42JeM/pP7d/DAUHBOX3PHcQBK1OGE81Obxrd07O2M4Ci7sLHp+ebsjsGqg WTrHPSLF+wfSwY0EFfqGN4KswnhflS6XM1KmGe7+8TZ9QWeuVR+0ptGoubljT2JtsyFN KofA== X-Gm-Message-State: AA6/9RkHKT3MQPdQmnBiH7KUcxsRH1BIbH/0BhGOOO4J0OcTsZ+T71Lt90kuZpRCQSqsd6OwRn3t64jAAuLzLQ8K X-Received: by 10.36.87.130 with SMTP id u124mr8504084ita.35.1476392136060; Thu, 13 Oct 2016 13:55:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.5.148 with HTTP; Thu, 13 Oct 2016 13:55:03 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 13 Oct 2016 14:55:03 -0600 Message-ID: To: Nick Harper Content-Type: multipart/alternative; boundary=001a11436eb8d1c94d053ec55454 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] clarification question (was Re: Clarifying Token Binding behavior with renegotiation) 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, 13 Oct 2016 20:55:39 -0000 --001a11436eb8d1c94d053ec55454 Content-Type: text/plain; charset=UTF-8 Thanks Nick. The question was more of just a sanity check on my part. The nomenclature is confusing. At least for someone like myself who is unfamiliar with the details of TLS. I just wanted to reconcile the behavior I've observed with what you'd said to make sure I wasn't off base. On Thu, Oct 13, 2016 at 2:21 PM, Nick Harper wrote: > The EKM is computed from the SecurityParameters, which include the client > and server random values from the latest handshake on the TLS connection. > (The EKM definition also includes SecurityParameters.master_secret, which > is from the TLS session.) I think there's nomenclature confusion here, > since TLS session commonly means the thing with the master secret that can > be resumed. Perhaps it would have been more accurate to say that an EKM is > dependent on both the TLS connection and the TLS session? > > You're correct that when a TLS session is resumed multiple times, each > connection for resumption has a different EKM. > > On Thu, Oct 13, 2016 at 1:06 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> Practically isn't the EKM obtained from the PRF and master secret of the >> TLS session and the client and server random values are from the handshake >> that set up the current TLS connection? >> >> That's the behavior I've seen with Chrome. When multiple connections are >> established via abbreviated handshake, each connection has a different EKM >> for TB because the client and server random values differ. >> >> >> On Fri, Oct 7, 2016 at 5:52 PM, Nick Harper wrote: >> >>> >>> Section 3.3 of TBPROTO specifies that the EKM is obtained from the >>> current current TLS connection, but RFC 5705 states that the exporter is >>> associated with a TLS session (more specifically, a set of >>> SecurityParameters). >>> >>> >> >> >> > --001a11436eb8d1c94d053ec55454 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Nick. The question was more of just a sanity check = on my part. The nomenclature is confusing. At least for someone like myself= who is unfamiliar with the details of TLS. I just wanted to reconcile the = behavior I've observed with what you'd said to make sure I wasn'= ;t off base.

On Thu, Oct 13, 2016 at 2:21 PM, Nick Harper <nharper@google.com> wrote:
The = EKM is computed from the SecurityParameters, which include the client and s= erver random values from the latest handshake on the TLS connection. (The E= KM definition also includes SecurityParameters.master_secret, which is= from the TLS session.) I think there's nomenclature confusion here, si= nce TLS session commonly means the thing with the master secret that can be= resumed. Perhaps it would have been more accurate to say that an EKM is de= pendent on both the TLS connection and the TLS session?

= You're correct that when a TLS session is resumed multiple times, each = connection for resumption has a different EKM.

On Thu, Oct 13, 2016 at 1:06 PM, Brian Campbell <= ;bcampbell@= pingidentity.com> wrote:
Practically isn't the EKM obtained from the PRF and= master secret of the TLS session and the client and server random values a= re from the handshake that set up the current TLS connection?

= That's the behavior I've seen with Chrome. When multiple connection= s are established via abbreviated handshake, each connection has a differen= t EKM for TB because the client and server random values differ.=C2=A0
=


On Fri, Oct 7, 2016 at 5:52 PM, Nick Harper <nharper@google.com>= wrote:

Section 3.3 of TBPROTO specifies that the EKM= is obtained from the current current TLS connection, but RFC 5705 states t= hat the exporter is associated with a TLS session (more specifically, a set= of SecurityParameters).






--001a11436eb8d1c94d053ec55454-- From nobody Thu Oct 13 13:56:11 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913601295CE for ; Thu, 13 Oct 2016 13:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6UkfSuV1ZWW for ; Thu, 13 Oct 2016 13:56:08 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0102.outbound.protection.outlook.com [104.47.42.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F470129544 for ; Thu, 13 Oct 2016 13:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q/7UQIx9D7xCsvHibfipHdROHSZpGVbsb0S7EUEX0II=; b=k7V3AgVhiFeme3nOGftjVFnhrif94Mr+/DTZeChknWJ8VkYKMpvbYWpCvnUB21KclRNYoZPm3Gc3kVYwtFVNmRTSWMeBNJUNlQ0c3tn1PD8BVjK8c6RdYSo5RURrV6OnsKFlqcMm4z1WPZUQTiMK76QXUA1uIGI4oO/M2m6SGf0= 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.649.16; Thu, 13 Oct 2016 20:56:07 +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.0649.027; Thu, 13 Oct 2016 20:56:07 +0000 From: Andrei Popov To: Brian Campbell , Nick Harper Thread-Topic: [Unbearable] Clarifying Token Binding behavior with renegotiation Thread-Index: AQHSIPYAfU8tAUm590uf08aV6ED2raCgzRRQgAEzGoCAAzA0MIAALqIAgAF1/4CAAA6RAA== Date: Thu, 13 Oct 2016 20:56:06 +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::1d2] x-ms-office365-filtering-correlation-id: 3fad7b95-01ac-48df-7544-08d3f3ab5a83 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 7:FnVdatWtT0RtU1ahLZy0/45IawHV4Ka41KoA2PZBKYiADJJnB7M3q+58R6mXT402Th6WEae2jZqfUc1zskhgb+Q8Js93SONV0RsyQy1JrjLvKOwAYmQk2JgqNFZhypHr39r24izRRBmbgSF/JDOpzTmqZ1mTY07nqWAvIi1Jt55eaeKWC+qXt740G3thlllDgv2xyoK2yU9sg1OSbFRd0Lcxaae2qGFy7FS8MY2hRfiRKrEZ+lO2sdSDxrdvUGeCdNNBjkbROi3u+O+W0UtqXXDIw8NN4epOrzZ/2aPZ7E+8nVVO7KxhFxYet/KTGur/6ap/60VYJOAlx7gMczGtaFxf6Y1fG1wTwwae/8IV32B9vN4mApoFr+JgiReXeXH+ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0842; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(5001770100001)(81156014)(586003)(97736004)(101416001)(33656002)(7736002)(7696004)(189998001)(8936002)(10290500002)(10400500002)(5005710100001)(74316002)(9686002)(81166006)(4326007)(68736007)(19625215002)(93886004)(8676002)(2906002)(2950100002)(5660300001)(3660700001)(11100500001)(76576001)(87936001)(790700001)(106116001)(106356001)(77096005)(7846002)(6116002)(102836003)(16236675004)(76176999)(54356999)(105586002)(15975445007)(92566002)(99286002)(10090500001)(5002640100001)(86362001)(3280700002)(19580395003)(122556002)(2900100001)(8990500004)(50986999)(19300405004)(86612001)(3826002); 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_CY1PR0301MB0842ADABE7166771D634C32B8CDC0CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2016 20:56:06.9541 (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] Clarifying Token Binding behavior with renegotiation 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, 13 Oct 2016 20:56:10 -0000 --_000_CY1PR0301MB0842ADABE7166771D634C32B8CDC0CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEdpdmVuIHRoZSBjdXJyZW50IGludGVudCBvZiB0aGUgZHJhZnQsIHdoZXJlIHJlbmVnb3Rp YXRpb24gaXMgYWxsb3dlZCBhbmQgdGhlIEVLTSBpcyBmcm9tIHRoZSBjdXJyZW50IG9yIG1vc3Qg cmVjZW50IFRMUyBzZXNzaW9uL2Nvbm5lY3Rpb24sIGhvdyBpcyBhIHNlcnZlciBleHBlY3RlZCB0 byBoYW5kbGUgdGhpbmdzIHdoZW4gcmVuZWdvdGlhdGlvbiBoYXBwZW5zPyBJbiBzb21lIChtYW55 L2FsbD8pIGNhc2VzLCBmb3IgYSBwZXJpb2Qgb2YgdGltZSBhcm91bmQgcmVuZWdvdGlhdGlvbiB0 aGUgc2VydmVyIGNhbid0IGtub3cgZm9yIHN1cmUgaWYgYSBUQiBtZXNzYWdlIHdhcyBwcmVwYXJl ZCB3aXRoIHRoZSBiZWZvcmUgRUtNIG9yIHRoZSBhZnRlciBFS00uDQpJ4oCZbSBub3QgYXdhcmUg b2YgYSBzaXR1YXRpb24gd2hlcmUgdGhlIHNlcnZlciBjYW7igJl0IGtub3cgZm9yIHN1cmUuDQoN CjEuICAgICAgIFRMUyBoYW5kc2hha2UgaXMgY29tcGxldGUuIFRoZSBjbGllbnQgc2VuZHMgdGhl IGZpcnN0IFRCIG1lc3NhZ2UgYXMgcGFydCBvZiB0aGUgZmlyc3QgYXBwbGljYXRpb25fZGF0YSBy ZWNvcmQgb2YgdGhpcyBUTFMgc2Vzc2lvbiBvciBjb25uZWN0aW9uLg0KDQoyLiAgICAgICBUaGUg c2VydmVyIHZhbGlkYXRlcyB0aGUgVEIgbWVzc2FnZSwgdXNpbmcgdGhlIGN1cnJlbnQgc2Vzc2lv bi9jb25uZWN0aW9u4oCZcyBFS00uIElmIHZhbGlkYXRpb24gc3VjY2VlZHMsIGNvbnRpbnVlIHRv IHN0ZXAgMy4NCg0KMy4gICAgICAgVGhlIHNlcnZlciBwcm9jZXNzZXMgdGhlIHJlc3Qgb2YgdGhl IGFwcGxpY2F0aW9uX2RhdGEsIGRldGVybWluZXMgdGhhdCBlLmcuIGNsaWVudCBhdXRoIGlzIHJl cXVpcmVkLCBhbmQgdHJpZ2dlcnMgcmVuZWdvdGlhdGlvbi4gR28gdG8gc3RlcCAxLg0KDQpDaGVl cnMsDQoNCkFuZHJlaQ0K --_000_CY1PR0301MB0842ADABE7166771D634C32B8CDC0CY1PR0301MB0842_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubTE1NjMzMjA5MzA2OTA2MTc0NjFnbWFpbC1tLTc4MDEz MTQ1NzM1MzMwMjUyNjVtLTU1Mzk1NTU3NTQ0MDMyOTc4OTZtc29saXN0cGFyYWdyYXBoLCBsaS5t MTU2MzMyMDkzMDY5MDYxNzQ2MWdtYWlsLW0tNzgwMTMxNDU3MzUzMzAyNTI2NW0tNTUzOTU1NTc1 NDQwMzI5Nzg5Nm1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tMTU2MzMyMDkzMDY5MDYxNzQ2MWdtYWls LW0tNzgwMTMxNDU3MzUzMzAyNTI2NW0tNTUzOTU1NTc1NDQwMzI5Nzg5Nm1zb2xpc3RwYXJhZ3Jh cGgNCgl7bXNvLXN0eWxlLW5hbWU6bV8xNTYzMzIwOTMwNjkwNjE3NDYxZ21haWwtbV8tNzgwMTMx NDU3MzUzMzAyNTI2NW1fLTU1Mzk1NTU3NTQ0MDMyOTc4OTZtc29saXN0cGFyYWdyYXBoOw0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjAN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlz dCBsMA0KCXttc28tbGlzdC1pZDo1Mzg4NTc5NjA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi04NzEwNTE2MzIgMTc1MjMyODQzMCA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjM7DQoJbXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250 LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21z by1saXN0LWlkOjExMTQwMTA5NTg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjU0NDUwMzM0IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAz IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwx OmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGlu O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+R2l2ZW4gdGhlIGN1cnJlbnQgaW50ZW50IG9mIHRo ZSBkcmFmdCwgd2hlcmUgcmVuZWdvdGlhdGlvbiBpcyBhbGxvd2VkIGFuZCB0aGUgRUtNIGlzIGZy b20gdGhlIGN1cnJlbnQgb3IgbW9zdCByZWNlbnQgVExTIHNlc3Npb24vY29ubmVjdGlvbiwgaG93 IGlzIGEgc2VydmVyIGV4cGVjdGVkIHRvIGhhbmRsZSB0aGluZ3Mgd2hlbiByZW5lZ290aWF0aW9u IGhhcHBlbnM/IEluIHNvbWUgKG1hbnkvYWxsPykNCiBjYXNlcywgZm9yIGEgcGVyaW9kIG9mIHRp bWUgYXJvdW5kIHJlbmVnb3RpYXRpb24gdGhlIHNlcnZlciBjYW4ndCBrbm93IGZvciBzdXJlIGlm IGEgVEIgbWVzc2FnZSB3YXMgcHJlcGFyZWQgd2l0aCB0aGUgYmVmb3JlIEVLTSBvciB0aGUgYWZ0 ZXIgRUtNLjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5J4oCZbSBub3QgYXdhcmUgb2YgYSBzaXR1YXRp b24gd2hlcmUgdGhlIHNlcnZlciBjYW7igJl0IGtub3cgZm9yIHN1cmUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+VExTIGhhbmRzaGFrZSBpcyBjb21wbGV0ZS4gVGhlIGNsaWVudCBzZW5kcyB0 aGUgZmlyc3QgVEIgbWVzc2FnZSBhcyBwYXJ0IG9mIHRoZSBmaXJzdCBhcHBsaWNhdGlvbl9kYXRh IHJlY29yZCBvZiB0aGlzIFRMUyBzZXNzaW9uIG9yIGNvbm5lY3Rpb24uDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5UaGUgc2VydmVyIHZhbGlkYXRlcyB0aGUgVEIgbWVzc2FnZSwgdXNpbmcg dGhlIGN1cnJlbnQgc2Vzc2lvbi9jb25uZWN0aW9u4oCZcyBFS00uIElmIHZhbGlkYXRpb24gc3Vj Y2VlZHMsIGNvbnRpbnVlIHRvIHN0ZXAgMy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps MSBsZXZlbDEgbGZvMyI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUg c2VydmVyIHByb2Nlc3NlcyB0aGUgcmVzdCBvZiB0aGUgYXBwbGljYXRpb25fZGF0YSwgZGV0ZXJt aW5lcyB0aGF0IGUuZy4gY2xpZW50IGF1dGggaXMgcmVxdWlyZWQsIGFuZCB0cmlnZ2VycyByZW5l Z290aWF0aW9uLiBHbyB0byBzdGVwIDEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNoZWVycyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+QW5kcmVpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_CY1PR0301MB0842ADABE7166771D634C32B8CDC0CY1PR0301MB0842_-- From nobody Thu Oct 13 14:30:25 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1351296AF for ; Thu, 13 Oct 2016 14:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ImAWvHFtKJpd for ; Thu, 13 Oct 2016 14:30:23 -0700 (PDT) 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 113E3129604 for ; Thu, 13 Oct 2016 14:30:22 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id o19so95553252ito.1 for ; Thu, 13 Oct 2016 14:30:22 -0700 (PDT) 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=o2Os6OzWO7v6yzY8Wo30UDn2x4SFEsoK7jWFhbq4dMg=; b=KiJKty1eYIVT0YYMQ+REYooJ+YZjSkCPrFdIoB0x1DXsufncKG/GWyPvxENDqJg+lX FoG6hs3IZ42nBpMqTgPIUd4FYV9O9K7iHALL4ViXw3kcBvnYHnY3wkoiSkHXX4/u8ZaQ 94VZn5eIDoUsuRYOggYreNlVa66dWH/GuZ0Is= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o2Os6OzWO7v6yzY8Wo30UDn2x4SFEsoK7jWFhbq4dMg=; b=RNgRt4aapmaZ2eNYuCzXtwcxg+xM2jN3GKpNaZ7tn+9cmd1lpB4RVRLOcRMbG3K+Wm nRuZrZZ4Uf20YDFSyfFHg27jdVwM/MbxLLseUCX6Il2O9eGQsLAW45jl453uzM5TOXYL 2I0EtLKIA9rHITTMfAUgg5YZNMgwEoP6vSZ+jcacVx5A5zUBUt7JTtnlG2R24lAbZAVJ UTWKFrJT9DGwYRAw6hIIFydyhiQblYVACQWnZbIuWBI+f6AazANjaCAlVjN3ZQLeY9M4 0THhetnZPHRCm/TP5sbcJjtSbIXFFE1iKzq2WrbQLLLzxgCazzjZt0fh//agrqoeMrtx DWpA== X-Gm-Message-State: AA6/9RlJhUdoY8ZAmzR4Ng1bzh2pUKPBnOg8STUyNtnlPciyNZtKAsDklM0JjWFwD9s/gddFNt6S3nrUI6qMM5Iz X-Received: by 10.36.147.135 with SMTP id y129mr9126862itd.11.1476394222110; Thu, 13 Oct 2016 14:30:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.5.148 with HTTP; Thu, 13 Oct 2016 14:29:51 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 13 Oct 2016 15:29:51 -0600 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=94eb2c07d1b4285e9b053ec5d16a Archived-At: Cc: IETF Tokbind WG , Nick Harper Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 13 Oct 2016 21:30:25 -0000 --94eb2c07d1b4285e9b053ec5d16a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What if, for example, the client were to initiate renegotiation after step 1 and before 2? On Thu, Oct 13, 2016 at 2:56 PM, Andrei Popov wrote: > =C3=98 Given the current intent of the draft, where renegotiation is all= owed > and the EKM is from the current or most recent TLS session/connection, ho= w > is a server expected to handle things when renegotiation happens? In some > (many/all?) cases, for a period of time around renegotiation the server > can't know for sure if a TB message was prepared with the before EKM or t= he > after EKM. > > I=E2=80=99m not aware of a situation where the server can=E2=80=99t know = for sure. > > 1. TLS handshake is complete. The client sends the first TB message > as part of the first application_data record of this TLS session or > connection. > > 2. The server validates the TB message, using the current > session/connection=E2=80=99s EKM. If validation succeeds, continue to ste= p 3. > > 3. The server processes the rest of the application_data, > determines that e.g. client auth is required, and triggers renegotiation. > Go to step 1. > > > > Cheers, > > > > Andrei > --94eb2c07d1b4285e9b053ec5d16a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What if, for example, the client were to initiate renegoti= ation after step 1 and before 2?

<= div class=3D"gmail_quote">On Thu, Oct 13, 2016 at 2:56 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

=C3=98=C2=A0 Given the current intent of the draft, where re= negotiation is allowed and the EKM is from the current or most recent TLS s= ession/connection, how is a server expected to handle things when renegotia= tion happens? In some (many/all?) cases, for a period of time around renegotiation the server can't know= for sure if a TB message was prepared with the before EKM or the after EKM= .

I=E2=80=99m not aware of a situation where the serv= er can=E2=80=99t know for sure.

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 TLS handshake is complete. The client sends th= e first TB message as part of the first application_data record of this TLS= session or connection.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 The server validates the TB message, using the= current session/connection=E2=80=99s EKM. If validation succeeds, continue= to step 3.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 The server processes the rest of the applicati= on_data, determines that e.g. client auth is required, and triggers renegot= iation. Go to step 1.

=C2=A0

Cheers,

=C2=A0

Andrei


--94eb2c07d1b4285e9b053ec5d16a-- From nobody Thu Oct 13 14:55:22 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C9112948D for ; Thu, 13 Oct 2016 14:55:21 -0700 (PDT) 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 d3oYVDIrPxvu for ; Thu, 13 Oct 2016 14:55:19 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0109.outbound.protection.outlook.com [104.47.36.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F381A1293F3 for ; Thu, 13 Oct 2016 14:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hZ3UuMwBhT2u1pghCcBySzdd7srw/idpA5rLd07YM/0=; b=dVGYJznzJ/VclfSQUK4l8wIZb96DQ/RQmhPhCst9X0/026Lxcd9PShJDKK5LYtdbyKTmhecPSdhjMkSMMEj8g4FAFuir1a26CwnCeA/2TcTDuWFJ3cNndnlRxCa0m0QD4yUQ7b9OVxt95CwvVc3e47BN19P1BSzs3VpNFGNe1/g= 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.649.16; Thu, 13 Oct 2016 21:55: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.0649.027; Thu, 13 Oct 2016 21:55:17 +0000 From: Andrei Popov To: Brian Campbell Thread-Topic: [Unbearable] Clarifying Token Binding behavior with renegotiation Thread-Index: AQHSIPYAfU8tAUm590uf08aV6ED2raCgzRRQgAEzGoCAAzA0MIAALqIAgAF1/4CAAA6RAIAADFyAgAACGLA= Date: Thu, 13 Oct 2016 21:55:17 +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::1d2] x-ms-office365-filtering-correlation-id: 762fb364-5657-42e3-b911-08d3f3b39ea0 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 7:yOkZRFzSi7NAvifAVaFTEav4fADxcE/ftYC5H2k1gUr+X3GQgaAI39r7VhT5ouf75GFd588Y1AAj8tOrQCqrM0kLivNQUakcnCD4Z7lvBPJ6wAS9dxchG6mFalFK6U0qVlFuUMRa62C2R8jLUxNnSqrws4HcVo9V+i7fr87XqRKQEXMcuUVxmrKBuEzQIWBg1VMUX6hREIQsMBi97+oV9qX6hoUdTyz7eQonNGjUwg0Pd3/55MJtToQhjOTSa6B/wE77mqAp89NU+lI+pstd3XIK8tddsAMEizz5wq/sFCS6ug2/tnySyKHohylYwI/oppyczJwltm+xGsfBQ2FHfc15qoWZG+icfnbSv0Zjv9H2AtEtPmmwSu5g+j0xj5Ap x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0844; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(24454002)(189002)(377454003)(19580405001)(81156014)(81166006)(110136003)(97736004)(3280700002)(7696004)(76576001)(99286002)(68736007)(3660700001)(8936002)(11100500001)(105586002)(8676002)(74316002)(7736002)(5002640100001)(93886004)(2906002)(10090500001)(2950100002)(189998001)(5660300001)(6916009)(7846002)(50986999)(4326007)(10290500002)(10400500002)(77096005)(92566002)(15975445007)(54356999)(6116002)(2900100001)(101416001)(5005710100001)(87936001)(76176999)(586003)(86612001)(19580395003)(19300405004)(106356001)(8990500004)(106116001)(9686002)(86362001)(122556002)(19625215002)(16236675004)(102836003)(33656002)(790700001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0844; 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_CY1PR0301MB084207BCBE1C3EB8A0BD73448CDC0CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2016 21:55:17.1947 (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 , Nick Harper Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 13 Oct 2016 21:55:22 -0000 --_000_CY1PR0301MB084207BCBE1C3EB8A0BD73448CDC0CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MS4gICAgICAgVExTIGhhbmRzaGFrZSBpcyBjb21wbGV0ZS4gVGhlIGNsaWVudCBzZW5kcyB0aGUg Zmlyc3QgVEIgbWVzc2FnZSBhcyBwYXJ0IG9mIHRoZSBmaXJzdCBhcHBsaWNhdGlvbl9kYXRhIHJl Y29yZCBvZiB0aGlzIFRMUyBzZXNzaW9uIG9yIGNvbm5lY3Rpb24uDQoNCjEuNSAgIFRoZSBjbGll bnQgc2VuZHMgYSBDbGllbnRIZWxsbyB0byByZW5lZ290aWF0ZS4NCg0KMi4gICAgICAgVGhlIHNl cnZlciB2YWxpZGF0ZXMgdGhlIFRCIG1lc3NhZ2UsIHVzaW5nIHRoZSBjdXJyZW50IHNlc3Npb24v Y29ubmVjdGlvbuKAmXMgRUtNLiBJZiB2YWxpZGF0aW9uIHN1Y2NlZWRzLCBjb250aW51ZSB0byBz dGVwIDMuDQoNCjMuICAgICAgIFRoZSBzZXJ2ZXIgcHJvY2Vzc2VzIHRoZSByZXN0IG9mIHRoZSBh cHBsaWNhdGlvbl9kYXRhIGFuZCBwb3NzaWJseSBzZW5kcyBhIHJlc3BvbnNlLg0KDQo0LiAgICAg ICBUaGUgc2VydmVyIHByb2Nlc3NlcyB0aGUgcmVuZWdvdGlhdGlvbiBDbGllbnRIZWxsby4gQW4g SFRUUCBzZXJ2ZXIgd2lsbCBsaWtlbHkgaGF2ZSBjbGllbnQtaW5pdGlhdGVkIHJlbmVnb3RpYXRp b24gZGlzYWJsZWQsIGJ1dCBpZiBub3QsIGl0IHdpbGwgcGVyZm9ybSB0aGUgaGFuZHNoYWtlLiBH byB0byBzdGVwIDEuDQoNCkEgVExTIHNlcnZlciBhbHdheXMga25vd3Mgd2hhdCBUTFMgc2Vzc2lv bi9jb25uZWN0aW9uIGEgZ2l2ZW4gYXBwbGljYXRpb25fZGF0YSBtZXNzYWdlIGJlbG9uZ3MgdG8s IG90aGVyd2lzZSBpdCB3b3VsZCBub3QgYmUgYWJsZSB0byBkZWNyeXB0IHRoaXMgYXBwbGljYXRp b25fZGF0YSBpbiB0aGUgZmlyc3QgcGxhY2UuDQpBbmQgYXBwbGljYXRpb25fZGF0YSBjYXJyaWVz IHRoZSBUQiBtZXNzYWdlLg0KDQpGcm9tOiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOmJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tXQ0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTMsIDIwMTYgMjoz MCBQTQ0KVG86IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+DQpDYzog TmljayBIYXJwZXIgPG5oYXJwZXJAZ29vZ2xlLmNvbT47IElFVEYgVG9rYmluZCBXRyA8dW5iZWFy YWJsZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gQ2xhcmlmeWluZyBUb2tl biBCaW5kaW5nIGJlaGF2aW9yIHdpdGggcmVuZWdvdGlhdGlvbg0KDQpXaGF0IGlmLCBmb3IgZXhh bXBsZSwgdGhlIGNsaWVudCB3ZXJlIHRvIGluaXRpYXRlIHJlbmVnb3RpYXRpb24gYWZ0ZXIgc3Rl cCAxIGFuZCBiZWZvcmUgMj8NCg0KT24gVGh1LCBPY3QgMTMsIDIwMTYgYXQgMjo1NiBQTSwgQW5k cmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92 QG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KPiAgR2l2ZW4gdGhlIGN1cnJlbnQgaW50ZW50IG9m IHRoZSBkcmFmdCwgd2hlcmUgcmVuZWdvdGlhdGlvbiBpcyBhbGxvd2VkIGFuZCB0aGUgRUtNIGlz IGZyb20gdGhlIGN1cnJlbnQgb3IgbW9zdCByZWNlbnQgVExTIHNlc3Npb24vY29ubmVjdGlvbiwg aG93IGlzIGEgc2VydmVyIGV4cGVjdGVkIHRvIGhhbmRsZSB0aGluZ3Mgd2hlbiByZW5lZ290aWF0 aW9uIGhhcHBlbnM/IEluIHNvbWUgKG1hbnkvYWxsPykgY2FzZXMsIGZvciBhIHBlcmlvZCBvZiB0 aW1lIGFyb3VuZCByZW5lZ290aWF0aW9uIHRoZSBzZXJ2ZXIgY2FuJ3Qga25vdyBmb3Igc3VyZSBp ZiBhIFRCIG1lc3NhZ2Ugd2FzIHByZXBhcmVkIHdpdGggdGhlIGJlZm9yZSBFS00gb3IgdGhlIGFm dGVyIEVLTS4NCknigJltIG5vdCBhd2FyZSBvZiBhIHNpdHVhdGlvbiB3aGVyZSB0aGUgc2VydmVy IGNhbuKAmXQga25vdyBmb3Igc3VyZS4NCg0KMS4gICAgICAgVExTIGhhbmRzaGFrZSBpcyBjb21w bGV0ZS4gVGhlIGNsaWVudCBzZW5kcyB0aGUgZmlyc3QgVEIgbWVzc2FnZSBhcyBwYXJ0IG9mIHRo ZSBmaXJzdCBhcHBsaWNhdGlvbl9kYXRhIHJlY29yZCBvZiB0aGlzIFRMUyBzZXNzaW9uIG9yIGNv bm5lY3Rpb24uDQoNCjIuICAgICAgIFRoZSBzZXJ2ZXIgdmFsaWRhdGVzIHRoZSBUQiBtZXNzYWdl LCB1c2luZyB0aGUgY3VycmVudCBzZXNzaW9uL2Nvbm5lY3Rpb27igJlzIEVLTS4gSWYgdmFsaWRh dGlvbiBzdWNjZWVkcywgY29udGludWUgdG8gc3RlcCAzLg0KDQozLiAgICAgICBUaGUgc2VydmVy IHByb2Nlc3NlcyB0aGUgcmVzdCBvZiB0aGUgYXBwbGljYXRpb25fZGF0YSwgZGV0ZXJtaW5lcyB0 aGF0IGUuZy4gY2xpZW50IGF1dGggaXMgcmVxdWlyZWQsIGFuZCB0cmlnZ2VycyByZW5lZ290aWF0 aW9uLiBHbyB0byBzdGVwIDEuDQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCg== --_000_CY1PR0301MB084207BCBE1C3EB8A0BD73448CDC0CY1PR0301MB0842_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubTY3MTAzNzE2ODk5MzcxMzM3NThtc29saXN0cGFyYWdy YXBoLCBsaS5tNjcxMDM3MTY4OTkzNzEzMzc1OG1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tNjcxMDM3 MTY4OTkzNzEzMzc1OG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV82NzEwMzcx Njg5OTM3MTMzNzU4bXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpz cGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxT dHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6NzQ2NTMyMDEyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTk2MjA5MjQ2O30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDolMTsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 LjI1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2 ZWwtc3RhcnQtYXQ6NTsNCgltc28tbGV2ZWwtdGV4dDoiJTFcLiUyIjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6LjVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC10ZXh0OiIlMVwuJTJcLiUzIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MS4waW47DQoJdGV4dC1p bmRlbnQ6LS41aW47fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10ZXh0OiIlMVwuJTJc LiUzXC4lNCI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEuMjVpbjsNCgl0ZXh0LWluZGVudDotLjVpbjt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLXRleHQ6IiUxXC4lMlwuJTNcLiU0XC4lNSI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEuNzVpbjsNCgl0ZXh0LWluZGVudDotLjc1aW47fQ0KQGxpc3Qg bDA6bGV2ZWw2DQoJe21zby1sZXZlbC10ZXh0OiIlMVwuJTJcLiUzXC4lNFwuJTVcLiU2IjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJbWFyZ2luLWxlZnQ6Mi4waW47DQoJdGV4dC1pbmRlbnQ6LS43NWluO30NCkBsaXN0IGwwOmxl dmVsNw0KCXttc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4lM1wuJTRcLiU1XC4lNlwuJTciOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN CgltYXJnaW4tbGVmdDoyLjVpbjsNCgl0ZXh0LWluZGVudDotMS4waW47fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC10ZXh0OiIlMVwuJTJcLiUzXC4lNFwuJTVcLiU2XC4lN1wuJTgiOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDoyLjc1aW47DQoJdGV4dC1pbmRlbnQ6LTEuMGluO30NCkBsaXN0IGww OmxldmVsOQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4lM1wuJTRcLiU1XC4lNlwuJTdcLiU4 XC4lOSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjMuMGluOw0KCXRleHQtaW5kZW50Oi0xLjBpbjt9DQpA bGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMTE0MDEwOTU4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo1NDQ1MDMzNCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcx NTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6 bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwx OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VExTIGhh bmRzaGFrZSBpcyBjb21wbGV0ZS4gVGhlIGNsaWVudCBzZW5kcyB0aGUgZmlyc3QgVEIgbWVzc2Fn ZSBhcyBwYXJ0IG9mIHRoZSBmaXJzdCBhcHBsaWNhdGlvbl9kYXRhIHJlY29yZCBvZiB0aGlzIFRM UyBzZXNzaW9uIG9yIGNvbm5lY3Rpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps MCBsZXZlbDIgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjU8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGNsaWVudCBzZW5kcyBhIENsaWVudEhl bGxvIHRvIHJlbmVnb3RpYXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVs MSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBzZXJ2ZXIg dmFsaWRhdGVzIHRoZSBUQiBtZXNzYWdlLCB1c2luZyB0aGUgY3VycmVudCBzZXNzaW9uL2Nvbm5l Y3Rpb27igJlzIEVLTS4gSWYgdmFsaWRhdGlvbiBzdWNjZWVkcywgY29udGludWUgdG8gc3RlcCAz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBzZXJ2ZXIgcHJvY2Vzc2VzIHRoZSByZXN0 IG9mIHRoZSBhcHBsaWNhdGlvbl9kYXRhIGFuZCBwb3NzaWJseSBzZW5kcyBhIHJlc3BvbnNlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjQu PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBzZXJ2ZXIgcHJvY2Vzc2VzIHRoZSByZW5lZ290 aWF0aW9uIENsaWVudEhlbGxvLiBBbiBIVFRQIHNlcnZlciB3aWxsIGxpa2VseSBoYXZlIGNsaWVu dC1pbml0aWF0ZWQgcmVuZWdvdGlhdGlvbiBkaXNhYmxlZCwgYnV0IGlmIG5vdCwgaXQgd2lsbCBw ZXJmb3JtIHRoZSBoYW5kc2hha2UuDQogR28gdG8gc3RlcCAxLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BIFRM UyBzZXJ2ZXIgYWx3YXlzIGtub3dzIHdoYXQgVExTIHNlc3Npb24vY29ubmVjdGlvbiBhIGdpdmVu IGFwcGxpY2F0aW9uX2RhdGEgbWVzc2FnZSBiZWxvbmdzIHRvLCBvdGhlcndpc2UgaXQgd291bGQg bm90IGJlIGFibGUgdG8gZGVjcnlwdCB0aGlzIGFwcGxpY2F0aW9uX2RhdGEgaW4gdGhlIGZpcnN0 DQogcGxhY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5BbmQgYXBwbGljYXRpb25fZGF0YSBjYXJyaWVzIHRoZSBUQiBtZXNzYWdl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQnJp YW4gQ2FtcGJlbGwgW21haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbV0NCjxicj4NCjxi PlNlbnQ6PC9iPiBUaHVyc2RheSwgT2N0b2JlciAxMywgMjAxNiAyOjMwIFBNPGJyPg0KPGI+VG86 PC9iPiBBbmRyZWkgUG9wb3YgJmx0O0FuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tJmd0Ozxicj4N CjxiPkNjOjwvYj4gTmljayBIYXJwZXIgJmx0O25oYXJwZXJAZ29vZ2xlLmNvbSZndDs7IElFVEYg VG9rYmluZCBXRyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtVbmJlYXJhYmxlXSBDbGFyaWZ5aW5nIFRva2VuIEJpbmRpbmcgYmVoYXZpb3Igd2l0 aCByZW5lZ290aWF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hh dCBpZiwgZm9yIGV4YW1wbGUsIHRoZSBjbGllbnQgd2VyZSB0byBpbml0aWF0ZSByZW5lZ290aWF0 aW9uIGFmdGVyIHN0ZXAgMSBhbmQgYmVmb3JlIDI/DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgT2N0IDEzLCAyMDE2IGF0IDI6NTYgUE0sIEFu ZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29t IiB0YXJnZXQ9Il9ibGFuayI+QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJt NjcxMDM3MTY4OTkzNzEzMzc1OG1zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdCI+Jm5ic3A7DQo8L3NwYW4+R2l2ZW4gdGhlIGN1cnJlbnQgaW50ZW50IG9m IHRoZSBkcmFmdCwgd2hlcmUgcmVuZWdvdGlhdGlvbiBpcyBhbGxvd2VkIGFuZCB0aGUgRUtNIGlz IGZyb20gdGhlIGN1cnJlbnQgb3IgbW9zdCByZWNlbnQgVExTIHNlc3Npb24vY29ubmVjdGlvbiwg aG93IGlzIGEgc2VydmVyIGV4cGVjdGVkIHRvIGhhbmRsZSB0aGluZ3Mgd2hlbiByZW5lZ290aWF0 aW9uIGhhcHBlbnM/IEluIHNvbWUgKG1hbnkvYWxsPykgY2FzZXMsIGZvciBhIHBlcmlvZA0KIG9m IHRpbWUgYXJvdW5kIHJlbmVnb3RpYXRpb24gdGhlIHNlcnZlciBjYW4ndCBrbm93IGZvciBzdXJl IGlmIGEgVEIgbWVzc2FnZSB3YXMgcHJlcGFyZWQgd2l0aCB0aGUgYmVmb3JlIEVLTSBvciB0aGUg YWZ0ZXIgRUtNLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPknigJltIG5vdCBhd2FyZSBvZiBhIHNpdHVhdGlvbiB3aGVyZSB0aGUgc2VydmVy IGNhbuKAmXQga25vdyBmb3Igc3VyZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i bTY3MTAzNzE2ODk5MzcxMzM3NThtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjEu PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VExTIGhhbmRzaGFrZSBp cyBjb21wbGV0ZS4gVGhlIGNsaWVudCBzZW5kcyB0aGUgZmlyc3QgVEIgbWVzc2FnZSBhcyBwYXJ0 IG9mIHRoZSBmaXJzdCBhcHBsaWNhdGlvbl9kYXRhIHJlY29yZCBvZiB0aGlzIFRMUyBzZXNzaW9u IG9yIGNvbm5lY3Rpb24uDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTY3MTAz NzE2ODk5MzcxMzM3NThtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjIuPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHNlcnZlciB2YWxpZGF0ZXMg dGhlIFRCIG1lc3NhZ2UsIHVzaW5nIHRoZSBjdXJyZW50IHNlc3Npb24vY29ubmVjdGlvbuKAmXMg RUtNLiBJZiB2YWxpZGF0aW9uIHN1Y2NlZWRzLCBjb250aW51ZSB0byBzdGVwIDMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im02NzEwMzcxNjg5OTM3MTMzNzU4bXNvbGlzdHBhcmFn cmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4zLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPlRoZSBzZXJ2ZXIgcHJvY2Vzc2VzIHRoZSByZXN0IG9mIHRoZSBhcHBsaWNhdGlv bl9kYXRhLCBkZXRlcm1pbmVzIHRoYXQgZS5nLiBjbGllbnQgYXV0aCBpcyByZXF1aXJlZCwgYW5k IHRyaWdnZXJzIHJlbmVnb3RpYXRpb24uIEdvIHRvIHN0ZXAgMS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkNoZWVycyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiM4ODg4ODgiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM4ODg4ODgiPkFuZHJlaTwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6Izg4ODg4OCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR0301MB084207BCBE1C3EB8A0BD73448CDC0CY1PR0301MB0842_-- From nobody Thu Oct 13 16:12:39 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F192D1296C4 for ; Thu, 13 Oct 2016 16:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.996 X-Spam-Level: X-Spam-Status: No, score=-4.996 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, RP_MATCHES_RCVD=-2.996, 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 UWDxGqfmNMBF for ; Thu, 13 Oct 2016 16:12:37 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F00129471 for ; Thu, 13 Oct 2016 16:12:37 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id 184so36992502yby.2 for ; Thu, 13 Oct 2016 16:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VZGoBaj+F2PmnTx+2usYJ8cgtLJoqN+UFKelkJ1F1as=; b=QhxmK1MXtAz3DGb5bo3oU2ugoF+fBC7wKanaLKjvURg+Z5p4nccwxT7oUbzBxZieKo houji4xE9FnfOuCnmMF90vbHQ++tNXdipAoHiTAw17CcNzglt3t94Z00VZTHjnoAgTz4 QUG0dYxTQ4/F5/j0Z1ENLQ9ZroLrOCrxifzTakbmy28mGrjABRHWa7i+WoKK5QYOLM0y qZYdJG57RGvTa8NHdfI2ds6BA0iHEluiPwVn9W13eanLEHe8A6tgNjTbNvQdjlBpgL43 8LJz9IdJCVNci+lkRaSdjgZtNT701aJQv4a91d246hrkIDnP/feHYz5VuloOSD9A+Buw yJzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VZGoBaj+F2PmnTx+2usYJ8cgtLJoqN+UFKelkJ1F1as=; b=FbCATg3GZXyng12qHXEOw+nCl3r3kJF7uAQprvNZ7WuEfaP0BDGQXn9+J5h+lu6QBk eR3QZe+9xwHzXQTlXDhmo6Vj9nyhXU/++8WzSZ8Yjx/sDhS1iFfOW/vXryb7sKWGrYc1 Tw2m67nJ6OLqo91SEEYnNmREHMWWK2bTFgtwlC3aX4Ov5jkP8ICAmItPNM5ZvlBLMenn RqlH35nm1Ul2pq9pseXDRCFWKpAwG45AjID2a+wz7sBtUu4mP7AxNZaZVCWSxHhQVqfG pmw6Q14EBZoxmWH0wAe8iD6MSr7CzY8nyyka0doFye0aa6hs9rIpqrjX0TXGCJ2K+9Ai 2w3w== X-Gm-Message-State: AA6/9RkbKnFyWVDl4WTTyor3MdAt6wTWNPcFt4/NamDFRvk4LIPB+aBLQheXyWIs7ZmHWe0zHo11BVt61SjW2gur X-Received: by 10.37.6.138 with SMTP id 132mr2675536ybg.88.1476400356072; Thu, 13 Oct 2016 16:12:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.253.71 with HTTP; Thu, 13 Oct 2016 16:12:15 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Thu, 13 Oct 2016 16:12:15 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a113c564cc5ac58053ec73e33 Archived-At: Cc: IETF Tokbind WG , Brian Campbell Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 13 Oct 2016 23:12:39 -0000 --001a113c564cc5ac58053ec73e33 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 13, 2016 at 2:55 PM, Andrei Popov wrote: > > A TLS server always knows what TLS session/connection a given > application_data message belongs to, otherwise it would not be able to > decrypt this application_data in the first place. > > And application_data carries the TB message. > > > Does the application always know what TLS session/SecurityParameters an application_data message belongs to? I imagine the application only has an interface like SSL_read to read application data from the TLS stack, and when processing the TB message, it makes another call to the TLS stack some time delta later to get the EKM. The SSL_read interface only provides a sequence of bytes, not some identifier for the TLS session that the application could use when querying for the EKM later. I'm thinking of something like what Brian mentioned: 0. Client and Server establish a TLS connection 1. Client sends some app data with a TB 2. Client sends a ClientHello to start renegotiation 3. Server reads app data sent by Client from TLS connection 4. Server's TLS stack continues the TLS renegotiation handshake 5. Meanwhile, the server's application stack processes the app data, including verifying the TB signature of the EKM. In step 5, the application stack queries the TLS stack for the EKM. If step 4's handshake has finished before the application queries for the EKM, the application will get the new EKM when it wants the old EKM. (Or the application might query the TLS stack for the EKM during renegotiation, which the TLS stack might not support.) Obviously this is dependent on how the TLS stack is implemented and what interfaces it provides to the application. This is all assuming that there's a well-defined way to identify a TokenBindingMessage as belonging to a particular set of application_data TLS messages, that all of those application_data messages ended up on the same side of the ChangeCipherSpec message, and that ChangeCipherSpec is the correct point to use (instead of e.g. Finished) to indicate that renegotiation has completed and the new EKM instead of the old EKM should be used. --001a113c564cc5ac58053ec73e33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Oct 13, 2016 at 2:55 PM, Andrei Popov <Andrei.Popov@micro= soft.com> wrote:=C2=A0

A TLS server always knows what TLS session/connecti= on a given application_data message belongs to, otherwise it would not be a= ble to decrypt this application_data in the first place.

And application_data carries the TB message.=

=C2=A0

=C2=A0
Does the application always know what TLS session/Secur= ityParameters an application_data message belongs to? I imagine the applica= tion only has an interface like SSL_read to read application data from the = TLS stack, and when processing the TB message, it makes another call to the= TLS stack some time delta later to get the EKM. The SSL_read interface onl= y provides a sequence of bytes, not some identifier for the TLS session tha= t the application could use when querying for the EKM later.

=
I'm thinking of something like what Brian mentioned:
0. Client and Server establish a TLS connection
1. Client send= s some app data with a TB
2. Client sends a ClientHello to start = renegotiation
3. Server reads app data sent by Client from TLS co= nnection
4. Server's TLS stack continues the TLS renegotiatio= n handshake
5. Meanwhile, the server's application stack proc= esses the app data, including verifying the TB signature of the EKM.
<= div>
In step 5, the application stack queries the TLS stack f= or the EKM. If step 4's handshake has finished before the application q= ueries for the EKM, the application will get the new EKM when it wants the = old EKM. (Or the application might query the TLS stack for the EKM during r= enegotiation, which the TLS stack might not support.) Obviously this is dep= endent on how the TLS stack is implemented and what interfaces it provides = to the application.

This is all assuming that ther= e's a well-defined way to identify a TokenBindingMessage as belonging t= o a particular set of application_data TLS messages, that all of those appl= ication_data messages ended up on the same side of the ChangeCipherSpec mes= sage, and that ChangeCipherSpec is the correct point to use (instead of e.g= . Finished) to indicate that renegotiation has completed and the new EKM in= stead of the old EKM should be used.
--001a113c564cc5ac58053ec73e33-- From nobody Thu Oct 13 18:10:17 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AF2129440 for ; Thu, 13 Oct 2016 18:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KzbJ5UV-Qr4 for ; Thu, 13 Oct 2016 18:10:14 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADADB1293DA for ; Thu, 13 Oct 2016 18:10:14 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id n189so122872948qke.0 for ; Thu, 13 Oct 2016 18:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PEeSqDPNW9TJhV02VX7KOjAeMIfxuXIAV3AwJPBEDsg=; b=mzb6V6L8on5AZzmGy+C6bwD9iCL7gPXLQrB2kFG3vc9uBZUd2aZhla3Jmasch3677f +zLXlOu8ubTZ/f7SG41U6/1T2rHWeNX3ltuTtBp93T61bjHG1j6/BVTfcOECgDW47gbs 3mb3dER4q5veufwYk6QGiAdWafrEfZBKrCdYrrrySXJeDXKKhNDlD64hck8aImnjkyxC A9cJdVT8dF//IhpjIMDja203Q/lVucus37hbgYCd+TkmT2cmAgvMLxh7Nvzf96bUo9cn 0Ku7KLI54kGbsoAOFryvN4KSYHid5m9cKTnjGAUUWKGASX6ZGDlzrps4fnath1Fyawmt rqiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PEeSqDPNW9TJhV02VX7KOjAeMIfxuXIAV3AwJPBEDsg=; b=ZBPEnyvGKSe1nvDj/QeXkE6oHqOhxhcnmmxjUd2118Il5Yb8EjL+XqCg56EZnnDm7n TIzsSYId/Zo425DGI9/xaB2NuWp1g1S0C2vsIFj8jTdGsDhYbGSHqaV8xg55hYYo1tdw FOU+IEc3V1Ihv5mOrsuOrS/2GpLsupxgIpb+kdeSZgTwdQ7YifhG1AVF6ORIAuIicqeW u02hnNzQKYatNwK5RzOamw+/ldzspbUTE9heYTWMoZkRKdcESmE4sGR8D25TIC54SWSJ KClRNESU07FPnykMX1negXEOB9uY7nHxQK+TM7kfUju/EvyMYx6ZDtIiM1BBJ4fdwVYp SJmQ== X-Gm-Message-State: AA6/9RlLy79YdV6yGiHPPktSENivF6iZuwLuLi34+f19HQ+aZbxttcGBYRXFkinSauf5hGhOxFp2SUpLBYly+w== X-Received: by 10.55.163.214 with SMTP id m205mr9026269qke.68.1476407413813; Thu, 13 Oct 2016 18:10:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 13 Oct 2016 18:10:13 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 14 Oct 2016 12:10:13 +1100 Message-ID: To: Nick Harper Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Andrei Popov , Brian Campbell , IETF Tokbind WG Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 14 Oct 2016 01:10:16 -0000 Yes, requests that span a renegotiation can fail. Of course, you could arrange things so that the renegotiation is triggered after validating the TB and avoid the problem. I don't think we need to add extra complexity to deal with this. If anything this makes me more confident that removing renegotiation from TLS 1.3 was the right choice. On 14 October 2016 at 10:12, Nick Harper wrote: > > On Thu, Oct 13, 2016 at 2:55 PM, Andrei Popov > wrote: >> >> A TLS server always knows what TLS session/connection a given >> application_data message belongs to, otherwise it would not be able to >> decrypt this application_data in the first place. >> >> And application_data carries the TB message. >> >> > > > Does the application always know what TLS session/SecurityParameters an > application_data message belongs to? I imagine the application only has an > interface like SSL_read to read application data from the TLS stack, and > when processing the TB message, it makes another call to the TLS stack some > time delta later to get the EKM. The SSL_read interface only provides a > sequence of bytes, not some identifier for the TLS session that the > application could use when querying for the EKM later. > > I'm thinking of something like what Brian mentioned: > 0. Client and Server establish a TLS connection > 1. Client sends some app data with a TB > 2. Client sends a ClientHello to start renegotiation > 3. Server reads app data sent by Client from TLS connection > 4. Server's TLS stack continues the TLS renegotiation handshake > 5. Meanwhile, the server's application stack processes the app data, > including verifying the TB signature of the EKM. > > In step 5, the application stack queries the TLS stack for the EKM. If step > 4's handshake has finished before the application queries for the EKM, the > application will get the new EKM when it wants the old EKM. (Or the > application might query the TLS stack for the EKM during renegotiation, > which the TLS stack might not support.) Obviously this is dependent on how > the TLS stack is implemented and what interfaces it provides to the > application. > > This is all assuming that there's a well-defined way to identify a > TokenBindingMessage as belonging to a particular set of application_data TLS > messages, that all of those application_data messages ended up on the same > side of the ChangeCipherSpec message, and that ChangeCipherSpec is the > correct point to use (instead of e.g. Finished) to indicate that > renegotiation has completed and the new EKM instead of the old EKM should be > used. > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > From nobody Thu Oct 13 18:16:00 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC86127735 for ; Thu, 13 Oct 2016 18:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJgMZp21MQ8X for ; Thu, 13 Oct 2016 18:15:56 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0126.outbound.protection.outlook.com [104.47.32.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 3A33D1294E5 for ; Thu, 13 Oct 2016 18:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7jXSYRFzC9O0lG+/SDCOZqcP+tN3rPhGCdjhz0SkCMg=; b=VmDpC+yk0jzAQL+lrNRrza/Vle7/kabwP+Gs4iG8OR1wviI6J0pe/9YuMLNgnCB//C8pL6d7DEoJwAFdbMhfRVXKkTsb7FofPln7S6FHSagf65qRz1uSwOoAPcn1gntLQ/i2gqjU4NRrqU39rGTkEZBHsOxciJ1l87+YySS5XNY= 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.649.16; Fri, 14 Oct 2016 01:15:52 +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.0649.027; Fri, 14 Oct 2016 01:15:52 +0000 From: Andrei Popov To: Martin Thomson , Nick Harper , "Dirk Balfanz (balfanz@google.com)" Thread-Topic: [Unbearable] Clarifying Token Binding behavior with renegotiation Thread-Index: AQHSIPYAfU8tAUm590uf08aV6ED2raCgzRRQgAEzGoCAAzA0MIAALqIAgAF1/4CAAA6RAIAADFyAgAACGLCAABqEgIAAIPaAgAAAVDA= Date: Fri, 14 Oct 2016 01:15:52 +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::1d2] x-ms-office365-filtering-correlation-id: f9864353-2103-43c2-994d-08d3f3cfa412 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0841; 7:1He9E7cSYNgL9DvTWLCExtuF/pC8xY4ba8eSYWGFf6+Yxs9gttcu9L//5qyfoD+TNQXoHJFJq/+ZWONY/7VCkfWpgXea0wj5aIPEqymBlg21j0Je5J4O9XJiw+R5o8Pe2W1MdnuC0FrTXz8AxOTgjxY1oMv/5t4WNo+bjw3gYV4e+oajlNZdml5ESxgklNwuhuxvSXaD8AVCMMwEz5llP0/p4SS2Co+o6QDRX+vDxCjagMzNvJm0Qk8DJnK6FIoF9CrywPVv1k5Lfeuq5m3rQIO5WqYEoQFYHsIXLLzLNrYyeGz5JkdFLgEoNJC0olRFC47LG2Wzkd6jzkvw9zAQYlSGf/6ysLJYjGiS9zQUTWxNmhASEBF4Frm1GT9pqS9b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0841; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0841; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0841; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(13464003)(377454003)(24454002)(189002)(97736004)(19580405001)(5001770100001)(7696004)(87936001)(4326007)(9686002)(11100500001)(50986999)(54356999)(76176999)(68736007)(86612001)(7736002)(33656002)(99286002)(74316002)(2950100002)(81166006)(8676002)(81156014)(106116001)(10090500001)(105586002)(5660300001)(106356001)(5002640100001)(10290500002)(86362001)(122556002)(7846002)(10400500002)(5005710100001)(586003)(102836003)(6116002)(2906002)(189998001)(15975445007)(101416001)(92566002)(76576001)(2900100001)(3280700002)(77096005)(8990500004)(93886004)(3660700001)(305945005)(8936002)(19580395003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0841; 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2016 01:15:52.3091 (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 , Brian Campbell Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 14 Oct 2016 01:15:59 -0000 KyBEaXJrDQoNCkkgZ3Vlc3MsIHRoZSBrZXkgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBjYXJlIHRv IGRvIHByb29mIG9mIHBvc3Nlc3Npb24gYWZ0ZXIgcmVuZWdvdGlhdGlvbiwgb3Igd291bGQgYmUg Y29udGVudCB1c2luZyBhIHN0YWxlIEVLTSBmcm9tIHRoZSBiZWdpbm5pbmcgb2YgdGhlIGNvbm5l Y3Rpb24uDQoNCk15IHZvdGUgaXMgdG8gdXNlIHRoZSBsYXRlc3QgRUtNIGFuZCBwcm9wZXIgcHJv b2Ygb2YgcG9zc2Vzc2lvbiBhZnRlciByZW5lZ290aWF0aW9uOyBOaWNrIGFwcGVhcnMgdG8gdGhp bmsgdGhhdCBQT1AgYWZ0ZXIgcmVuZWdvdGlhdGlvbiBpcyBubyB1c2UgYW5kIGEgaGFzc2xlIHRv IGltcGxlbWVudC4NCkFueW9uZSBlbHNlIGhhcyBhbiBvcGluaW9uPw0KDQpDaGVlcnMsDQoNCkFu ZHJlaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFydGluIFRob21zb24g W21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dIA0KU2VudDogVGh1cnNkYXksIE9jdG9i ZXIgMTMsIDIwMTYgNjoxMCBQTQ0KVG86IE5pY2sgSGFycGVyIDxuaGFycGVyQGdvb2dsZS5jb20+ DQpDYzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT47IElFVEYgVG9r YmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz47IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxA cGluZ2lkZW50aXR5LmNvbT4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gQ2xhcmlmeWluZyBU b2tlbiBCaW5kaW5nIGJlaGF2aW9yIHdpdGggcmVuZWdvdGlhdGlvbg0KDQpZZXMsIHJlcXVlc3Rz IHRoYXQgc3BhbiBhIHJlbmVnb3RpYXRpb24gY2FuIGZhaWwuICBPZiBjb3Vyc2UsIHlvdSBjb3Vs ZCBhcnJhbmdlIHRoaW5ncyBzbyB0aGF0IHRoZSByZW5lZ290aWF0aW9uIGlzIHRyaWdnZXJlZCBh ZnRlciB2YWxpZGF0aW5nIHRoZSBUQiBhbmQgYXZvaWQgdGhlIHByb2JsZW0uDQoNCkkgZG9uJ3Qg dGhpbmsgd2UgbmVlZCB0byBhZGQgZXh0cmEgY29tcGxleGl0eSB0byBkZWFsIHdpdGggdGhpcy4g IElmIGFueXRoaW5nIHRoaXMgbWFrZXMgbWUgbW9yZSBjb25maWRlbnQgdGhhdCByZW1vdmluZyBy ZW5lZ290aWF0aW9uIGZyb20gVExTIDEuMyB3YXMgdGhlIHJpZ2h0IGNob2ljZS4NCg0KT24gMTQg T2N0b2JlciAyMDE2IGF0IDEwOjEyLCBOaWNrIEhhcnBlciA8bmhhcnBlckBnb29nbGUuY29tPiB3 cm90ZToNCj4NCj4gT24gVGh1LCBPY3QgMTMsIDIwMTYgYXQgMjo1NSBQTSwgQW5kcmVpIFBvcG92 IA0KPiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+DQo+IHdyb3RlOg0KPj4NCj4+IEEgVExT IHNlcnZlciBhbHdheXMga25vd3Mgd2hhdCBUTFMgc2Vzc2lvbi9jb25uZWN0aW9uIGEgZ2l2ZW4g DQo+PiBhcHBsaWNhdGlvbl9kYXRhIG1lc3NhZ2UgYmVsb25ncyB0bywgb3RoZXJ3aXNlIGl0IHdv dWxkIG5vdCBiZSBhYmxlIA0KPj4gdG8gZGVjcnlwdCB0aGlzIGFwcGxpY2F0aW9uX2RhdGEgaW4g dGhlIGZpcnN0IHBsYWNlLg0KPj4NCj4+IEFuZCBhcHBsaWNhdGlvbl9kYXRhIGNhcnJpZXMgdGhl IFRCIG1lc3NhZ2UuDQo+Pg0KPj4NCj4NCj4NCj4gRG9lcyB0aGUgYXBwbGljYXRpb24gYWx3YXlz IGtub3cgd2hhdCBUTFMgc2Vzc2lvbi9TZWN1cml0eVBhcmFtZXRlcnMgDQo+IGFuIGFwcGxpY2F0 aW9uX2RhdGEgbWVzc2FnZSBiZWxvbmdzIHRvPyBJIGltYWdpbmUgdGhlIGFwcGxpY2F0aW9uIG9u bHkgDQo+IGhhcyBhbiBpbnRlcmZhY2UgbGlrZSBTU0xfcmVhZCB0byByZWFkIGFwcGxpY2F0aW9u IGRhdGEgZnJvbSB0aGUgVExTIA0KPiBzdGFjaywgYW5kIHdoZW4gcHJvY2Vzc2luZyB0aGUgVEIg bWVzc2FnZSwgaXQgbWFrZXMgYW5vdGhlciBjYWxsIHRvIA0KPiB0aGUgVExTIHN0YWNrIHNvbWUg dGltZSBkZWx0YSBsYXRlciB0byBnZXQgdGhlIEVLTS4gVGhlIFNTTF9yZWFkIA0KPiBpbnRlcmZh Y2Ugb25seSBwcm92aWRlcyBhIHNlcXVlbmNlIG9mIGJ5dGVzLCBub3Qgc29tZSBpZGVudGlmaWVy IGZvciANCj4gdGhlIFRMUyBzZXNzaW9uIHRoYXQgdGhlIGFwcGxpY2F0aW9uIGNvdWxkIHVzZSB3 aGVuIHF1ZXJ5aW5nIGZvciB0aGUgRUtNIGxhdGVyLg0KPg0KPiBJJ20gdGhpbmtpbmcgb2Ygc29t ZXRoaW5nIGxpa2Ugd2hhdCBCcmlhbiBtZW50aW9uZWQ6DQo+IDAuIENsaWVudCBhbmQgU2VydmVy IGVzdGFibGlzaCBhIFRMUyBjb25uZWN0aW9uIDEuIENsaWVudCBzZW5kcyBzb21lIA0KPiBhcHAg ZGF0YSB3aXRoIGEgVEIgMi4gQ2xpZW50IHNlbmRzIGEgQ2xpZW50SGVsbG8gdG8gc3RhcnQgDQo+ IHJlbmVnb3RpYXRpb24gMy4gU2VydmVyIHJlYWRzIGFwcCBkYXRhIHNlbnQgYnkgQ2xpZW50IGZy b20gVExTIA0KPiBjb25uZWN0aW9uIDQuIFNlcnZlcidzIFRMUyBzdGFjayBjb250aW51ZXMgdGhl IFRMUyByZW5lZ290aWF0aW9uIA0KPiBoYW5kc2hha2UgNS4gTWVhbndoaWxlLCB0aGUgc2VydmVy J3MgYXBwbGljYXRpb24gc3RhY2sgcHJvY2Vzc2VzIHRoZSANCj4gYXBwIGRhdGEsIGluY2x1ZGlu ZyB2ZXJpZnlpbmcgdGhlIFRCIHNpZ25hdHVyZSBvZiB0aGUgRUtNLg0KPg0KPiBJbiBzdGVwIDUs IHRoZSBhcHBsaWNhdGlvbiBzdGFjayBxdWVyaWVzIHRoZSBUTFMgc3RhY2sgZm9yIHRoZSBFS00u IElmIA0KPiBzdGVwIDQncyBoYW5kc2hha2UgaGFzIGZpbmlzaGVkIGJlZm9yZSB0aGUgYXBwbGlj YXRpb24gcXVlcmllcyBmb3IgdGhlIA0KPiBFS00sIHRoZSBhcHBsaWNhdGlvbiB3aWxsIGdldCB0 aGUgbmV3IEVLTSB3aGVuIGl0IHdhbnRzIHRoZSBvbGQgRUtNLiANCj4gKE9yIHRoZSBhcHBsaWNh dGlvbiBtaWdodCBxdWVyeSB0aGUgVExTIHN0YWNrIGZvciB0aGUgRUtNIGR1cmluZyANCj4gcmVu ZWdvdGlhdGlvbiwgd2hpY2ggdGhlIFRMUyBzdGFjayBtaWdodCBub3Qgc3VwcG9ydC4pIE9idmlv dXNseSB0aGlzIA0KPiBpcyBkZXBlbmRlbnQgb24gaG93IHRoZSBUTFMgc3RhY2sgaXMgaW1wbGVt ZW50ZWQgYW5kIHdoYXQgaW50ZXJmYWNlcyANCj4gaXQgcHJvdmlkZXMgdG8gdGhlIGFwcGxpY2F0 aW9uLg0KPg0KPiBUaGlzIGlzIGFsbCBhc3N1bWluZyB0aGF0IHRoZXJlJ3MgYSB3ZWxsLWRlZmlu ZWQgd2F5IHRvIGlkZW50aWZ5IGEgDQo+IFRva2VuQmluZGluZ01lc3NhZ2UgYXMgYmVsb25naW5n IHRvIGEgcGFydGljdWxhciBzZXQgb2YgDQo+IGFwcGxpY2F0aW9uX2RhdGEgVExTIG1lc3NhZ2Vz LCB0aGF0IGFsbCBvZiB0aG9zZSBhcHBsaWNhdGlvbl9kYXRhIA0KPiBtZXNzYWdlcyBlbmRlZCB1 cCBvbiB0aGUgc2FtZSBzaWRlIG9mIHRoZSBDaGFuZ2VDaXBoZXJTcGVjIG1lc3NhZ2UsIA0KPiBh bmQgdGhhdCBDaGFuZ2VDaXBoZXJTcGVjIGlzIHRoZSBjb3JyZWN0IHBvaW50IHRvIHVzZSAoaW5z dGVhZCBvZiBlLmcuIA0KPiBGaW5pc2hlZCkgdG8gaW5kaWNhdGUgdGhhdCByZW5lZ290aWF0aW9u IGhhcyBjb21wbGV0ZWQgYW5kIHRoZSBuZXcgRUtNIA0KPiBpbnN0ZWFkIG9mIHRoZSBvbGQgRUtN IHNob3VsZCBiZSB1c2VkLg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBVbmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KPiBVbmJlYXJhYmxlQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJs ZQ0KPg0K From nobody Thu Oct 13 18:31:18 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5FC129446 for ; Thu, 13 Oct 2016 18:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 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=-2.996, 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 VmNBWSG0lugv for ; Thu, 13 Oct 2016 18:31:13 -0700 (PDT) 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 9E9DB127735 for ; Thu, 13 Oct 2016 18:31:13 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id w3so65893278ywg.1 for ; Thu, 13 Oct 2016 18:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vAwmrkPsw8Y+eyXl6Vbo/NcRRJDeFdx6r7baxIXqIIk=; b=eltdlaKJZ0sNX/geeUem9zMTlW9ooca8aMErM0AOgFzGoK1kaZnfXHl3qrGr860tfT SK96rHNWb0wzrQ8CvsT39JsjANMR4NV32xCA5kBL5AUIf0f44PDyeINmRykwFSexy1R0 SSIJ99BjeqYdq7fRQ/objk88oTJht6yeqH+v6b/miUiZnhNryFhumO77qpIUQs89sT8n i1UfHt6FFG5KFowFUy1UtRoEJlECXcZf5J9/jz3I9FaG1mAX8B8T3Rzl9NdIAs+ZjHH8 dOShwZq5kP5NCd/2i/TzZbmiPTcsyMywUF4okwg45Zhjz5jNJIFEWMHwfAKnXA1w7reG gEUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vAwmrkPsw8Y+eyXl6Vbo/NcRRJDeFdx6r7baxIXqIIk=; b=Fza8j9EgMVKBIJ3X/E+xrjtVp1Q/0I+/MoWdtSC0tuoC4Ab0BRx0L7z2xy6V9w2l3n OGmI9CjIC53NlEYWT1jZuOas0J3hRIp1WL1b/lWdvlUrPVXs07sDAKQD5EC3TJMfIeyQ 9xau27q3DDf30hKPe/zl2uKyZdfXmazhqD/I7jom2FRf/wo93jKEg6GATiPXC9Vh0mEA pMv07t2aS/33woKMOXqgV6p7OCwUc7cMQTtfWEDqFtTEshWghDVVPhx5Ohmp0bB01l4D g6F2FK4uLjnHc1UgS2+cEhxEvWJtA3fVC2trP+0CfQRMwQgJhGVDxjS4dO6uelPImACF TL6w== X-Gm-Message-State: AA6/9RkUKY7kDLsMLBkPqboG05rwt6/lm9voB07GjdDEJfhNw1/O2OrMBsIDZrtN9o5wBBPdVuldqXYNFgEBg5Zg X-Received: by 10.129.116.84 with SMTP id p81mr8255186ywc.7.1476408672451; Thu, 13 Oct 2016 18:31:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.253.71 with HTTP; Thu, 13 Oct 2016 18:30:51 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Thu, 13 Oct 2016 18:30:51 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a1141cd9a7786f4053ec92eae Archived-At: Cc: "Dirk Balfanz \(balfanz@google.com\)" , IETF Tokbind WG , Brian Campbell , Martin Thomson Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 14 Oct 2016 01:31:16 -0000 --001a1141cd9a7786f4053ec92eae Content-Type: text/plain; charset=UTF-8 Correct, I think that using the EKM from the latest handshake provides no additional value. I think implementation difficulty might be more than just "a hassle" - it might be impossible to implement with OpenSSL's current API. Additionally, it requires that an application protocol that uses both renegotiation and Token Binding define a clear boundary between application data pre-renegotiation and application data post-renegotiation. On Thu, Oct 13, 2016 at 6:15 PM, Andrei Popov wrote: > + Dirk > > I guess, the key question is whether we care to do proof of possession > after renegotiation, or would be content using a stale EKM from the > beginning of the connection. > > My vote is to use the latest EKM and proper proof of possession after > renegotiation; Nick appears to think that POP after renegotiation is no use > and a hassle to implement. > Anyone else has an opinion? > > Cheers, > > Andrei > > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Thursday, October 13, 2016 6:10 PM > To: Nick Harper > Cc: Andrei Popov ; IETF Tokbind WG < > unbearable@ietf.org>; Brian Campbell > Subject: Re: [Unbearable] Clarifying Token Binding behavior with > renegotiation > > Yes, requests that span a renegotiation can fail. Of course, you could > arrange things so that the renegotiation is triggered after validating the > TB and avoid the problem. > > I don't think we need to add extra complexity to deal with this. If > anything this makes me more confident that removing renegotiation from TLS > 1.3 was the right choice. > > On 14 October 2016 at 10:12, Nick Harper wrote: > > > > On Thu, Oct 13, 2016 at 2:55 PM, Andrei Popov > > > > wrote: > >> > >> A TLS server always knows what TLS session/connection a given > >> application_data message belongs to, otherwise it would not be able > >> to decrypt this application_data in the first place. > >> > >> And application_data carries the TB message. > >> > >> > > > > > > Does the application always know what TLS session/SecurityParameters > > an application_data message belongs to? I imagine the application only > > has an interface like SSL_read to read application data from the TLS > > stack, and when processing the TB message, it makes another call to > > the TLS stack some time delta later to get the EKM. The SSL_read > > interface only provides a sequence of bytes, not some identifier for > > the TLS session that the application could use when querying for the EKM > later. > > > > I'm thinking of something like what Brian mentioned: > > 0. Client and Server establish a TLS connection 1. Client sends some > > app data with a TB 2. Client sends a ClientHello to start > > renegotiation 3. Server reads app data sent by Client from TLS > > connection 4. Server's TLS stack continues the TLS renegotiation > > handshake 5. Meanwhile, the server's application stack processes the > > app data, including verifying the TB signature of the EKM. > > > > In step 5, the application stack queries the TLS stack for the EKM. If > > step 4's handshake has finished before the application queries for the > > EKM, the application will get the new EKM when it wants the old EKM. > > (Or the application might query the TLS stack for the EKM during > > renegotiation, which the TLS stack might not support.) Obviously this > > is dependent on how the TLS stack is implemented and what interfaces > > it provides to the application. > > > > This is all assuming that there's a well-defined way to identify a > > TokenBindingMessage as belonging to a particular set of > > application_data TLS messages, that all of those application_data > > messages ended up on the same side of the ChangeCipherSpec message, > > and that ChangeCipherSpec is the correct point to use (instead of e.g. > > Finished) to indicate that renegotiation has completed and the new EKM > > instead of the old EKM should be used. > > > > _______________________________________________ > > Unbearable mailing list > > Unbearable@ietf.org > > https://www.ietf.org/mailman/listinfo/unbearable > > > --001a1141cd9a7786f4053ec92eae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Correct, I think that using the EKM from the latest handsh= ake provides no additional value. I think implementation difficulty might b= e more than just "a hassle" - it might be impossible to implement= with OpenSSL's current API. Additionally, it requires that an applicat= ion protocol that uses both renegotiation and Token Binding define a clear = boundary between application data pre-renegotiation and application data po= st-renegotiation.

On Thu, Oct 13, 2016 at 6:15 PM, Andrei Popov <<= a href=3D"mailto:Andrei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov= @microsoft.com> wrote:
+ Di= rk

I guess, the key question is whether we care to do proof of possession afte= r renegotiation, or would be content using a stale EKM from the beginning o= f the connection.

My vote is to use the latest EKM and proper proof of possession after reneg= otiation; Nick appears to think that POP after renegotiation is no use and = a hassle to implement.
Anyone else has an opinion?

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:ma= rtin.thomson@gmail.com]
Sent: Thursday, October 13, 2016 6:10 PM
To: Nick Harper <nharper@google.co= m>
Cc: Andrei Popov <Andrei.P= opov@microsoft.com>; IETF Tokbind WG <unbearable@ietf.org>; Brian Campbell <bcampbell@pingidentity.com>
Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiat= ion

Yes, requests that span a re= negotiation can fail.=C2=A0 Of course, you could arrange things so that the= renegotiation is triggered after validating the TB and avoid the problem.<= br>
I don't think we need to add extra complexity to deal with this.=C2=A0 = If anything this makes me more confident that removing renegotiation from T= LS 1.3 was the right choice.

On 14 October 2016 at 10:12, Nick Harper <nharper@google.com> wrote:
>
> On Thu, Oct 13, 2016 at 2:55 PM, Andrei Popov
> <Andrei.Popov@microso= ft.com>
> wrote:
>>
>> A TLS server always knows what TLS session/connection a given
>> application_data message belongs to, otherwise it would not be abl= e
>> to decrypt this application_data in the first place.
>>
>> And application_data carries the TB message.
>>
>>
>
>
> Does the application always know what TLS session/SecurityParameters > an application_data message belongs to? I imagine the application only=
> has an interface like SSL_read to read application data from the TLS > stack, and when processing the TB message, it makes another call to > the TLS stack some time delta later to get the EKM. The SSL_read
> interface only provides a sequence of bytes, not some identifier for > the TLS session that the application could use when querying for the E= KM later.
>
> I'm thinking of something like what Brian mentioned:
> 0. Client and Server establish a TLS connection 1. Client sends some > app data with a TB 2. Client sends a ClientHello to start
> renegotiation 3. Server reads app data sent by Client from TLS
> connection 4. Server's TLS stack continues the TLS renegotiation > handshake 5. Meanwhile, the server's application stack processes t= he
> app data, including verifying the TB signature of the EKM.
>
> In step 5, the application stack queries the TLS stack for the EKM. If=
> step 4's handshake has finished before the application queries for= the
> EKM, the application will get the new EKM when it wants the old EKM. > (Or the application might query the TLS stack for the EKM during
> renegotiation, which the TLS stack might not support.) Obviously this<= br> > is dependent on how the TLS stack is implemented and what interfaces > it provides to the application.
>
> This is all assuming that there's a well-defined way to identify a=
> TokenBindingMessage as belonging to a particular set of
> application_data TLS messages, that all of those application_data
> messages ended up on the same side of the ChangeCipherSpec message, > and that ChangeCipherSpec is the correct point to use (instead of e.g.=
> Finished) to indicate that renegotiation has completed and the new EKM=
> instead of the old EKM should be used.
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbe= arable
>

--001a1141cd9a7786f4053ec92eae-- From nobody Fri Oct 14 14:57:54 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356761298CE for ; Fri, 14 Oct 2016 14:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 37RtMH2ljuEH for ; Fri, 14 Oct 2016 14:57:49 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 3A50B1298C8 for ; Fri, 14 Oct 2016 14:57:49 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id 4so3134834itv.0 for ; Fri, 14 Oct 2016 14:57:49 -0700 (PDT) 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=thz0uZC0j4QRcmxh3hKXI1QePQiHCWQNCkEPn9anpx4=; b=pOuUfsCC4LiV2NkNvMN8UbJ+p8yfuwqnHUfhWAbLscMYptIYPK4xkGyDSLNtAcyP41 WCYaSgei0s5RvgXDzYXXCZ59368u6I4h2ukju/RshUPA8WGwtvw7lgfAk+gpuC9AYh2q oMn3CBRVdYiODYgYo+WYw8XofDMns7PuaHZ/g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=thz0uZC0j4QRcmxh3hKXI1QePQiHCWQNCkEPn9anpx4=; b=UOBfhXUoY/UW7tS/djZ7Gc3X3XSof2JbJAJBiFlVwsLkz6x9Pl28oeCetpj/uP38Xd jvkUEi+nZIjACTJPxdzauLrTR8KWrryZhZWH6/GH6EyxPRndabjg9FZc2FZOW36PTf8k qJ8T4I4a2DrScs//uLYZw9WUxYGMDNibqgJ+hyRyRgd8uyUJ97nitoELryQGI5LGr0l3 8i2t3a+WQ+T8gxY7wez6+JjXQ5p9R3ioGzvZnFv1mp25h8oiMIa7l2ApybxQIKgcT+qL WM9KLWRCuxy9/azoxH63KSlCeROlV9PMZ11zAydRu3vbOa6uoIImSbAZcGV58KMmUQYD 7sfA== X-Gm-Message-State: AA6/9RnEpE0jabWjl7ZZcGSOd8XogQtrAfOldFJpTVLevM2WYBdvJ3yJ+WFTqm/6k2t+7KJgmBtqLwRn4tXyGVpL X-Received: by 10.36.121.131 with SMTP id z125mr248261itc.79.1476482268289; Fri, 14 Oct 2016 14:57:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.5.148 with HTTP; Fri, 14 Oct 2016 14:57:17 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Fri, 14 Oct 2016 15:57:17 -0600 Message-ID: To: Nick Harper Content-Type: multipart/alternative; boundary=001a114abbd21e8048053eda5153 Archived-At: Cc: "Dirk Balfanz \(balfanz@google.com\)" , Andrei Popov , Martin Thomson , IETF Tokbind WG Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 14 Oct 2016 21:57:52 -0000 --001a114abbd21e8048053eda5153 Content-Type: text/plain; charset=UTF-8 There's an abstraction implied by TLS that's followed by most, if not all, TLS implementations/APIs where the application is exposed to reading and writing the application data and is mostly shielded from the other details of the happens at the TLS layer like the crypto or when exactly a renegotiation might have happened. In principle in the messaging there is a clear way to know what application data is associated with which master secret / EKM, but in practice the application data is opaque to the TLS layer and the TLS stuff is hidden from the application. I do think there's a problem here but not sure how serious or likely it actually is. How much is renegotiation really done? Or will be done with TB? As has been noted, TLS 1.3 and HTTP2 are doing away with it. In my own product experience, we did it years ago to support asking for client auth on certain resources but it was always pretty flaky and we disabled it when the renegotiation vulnerability came out and then never turned it back on. And what's the impact of using the other EKM? The connection gets terminated and the client probably tries again. Maybe one could get into a nasty cycle there. But it might not even be a visible issue in most cases. Taking a step back, it seems there are a few options: - Leave things as they are and just let things fall out as they may and hope it's not too bad (I think this is what Martin advocated for) - Leave things as they are and make some mention of the possibility of the issue and maybe ways that could be used to deal with it (I do think that retaining and checking multiple EKMs for a short time around the renegotiation could work but is definitely a hassle) - Prohibit the use of TB and renegotiation together - Take Nick's proposal of using only the EKM from the initial handshake (I don't claim to fully understand the security ramifications but it's not clear to me that security is degraded by this) On Thu, Oct 13, 2016 at 7:30 PM, Nick Harper wrote: > Correct, I think that using the EKM from the latest handshake provides no > additional value. I think implementation difficulty might be more than just > "a hassle" - it might be impossible to implement with OpenSSL's current > API. Additionally, it requires that an application protocol that uses both > renegotiation and Token Binding define a clear boundary between application > data pre-renegotiation and application data post-renegotiation. > > On Thu, Oct 13, 2016 at 6:15 PM, Andrei Popov > wrote: > >> + Dirk >> >> I guess, the key question is whether we care to do proof of possession >> after renegotiation, or would be content using a stale EKM from the >> beginning of the connection. >> >> My vote is to use the latest EKM and proper proof of possession after >> renegotiation; Nick appears to think that POP after renegotiation is no use >> and a hassle to implement. >> Anyone else has an opinion? >> >> Cheers, >> >> Andrei >> >> -----Original Message----- >> From: Martin Thomson [mailto:martin.thomson@gmail.com] >> Sent: Thursday, October 13, 2016 6:10 PM >> To: Nick Harper >> Cc: Andrei Popov ; IETF Tokbind WG < >> unbearable@ietf.org>; Brian Campbell >> Subject: Re: [Unbearable] Clarifying Token Binding behavior with >> renegotiation >> >> Yes, requests that span a renegotiation can fail. Of course, you could >> arrange things so that the renegotiation is triggered after validating the >> TB and avoid the problem. >> >> I don't think we need to add extra complexity to deal with this. If >> anything this makes me more confident that removing renegotiation from TLS >> 1.3 was the right choice. >> >> On 14 October 2016 at 10:12, Nick Harper wrote: >> > >> > On Thu, Oct 13, 2016 at 2:55 PM, Andrei Popov >> > >> > wrote: >> >> >> >> A TLS server always knows what TLS session/connection a given >> >> application_data message belongs to, otherwise it would not be able >> >> to decrypt this application_data in the first place. >> >> >> >> And application_data carries the TB message. >> >> >> >> >> > >> > >> > Does the application always know what TLS session/SecurityParameters >> > an application_data message belongs to? I imagine the application only >> > has an interface like SSL_read to read application data from the TLS >> > stack, and when processing the TB message, it makes another call to >> > the TLS stack some time delta later to get the EKM. The SSL_read >> > interface only provides a sequence of bytes, not some identifier for >> > the TLS session that the application could use when querying for the >> EKM later. >> > >> > I'm thinking of something like what Brian mentioned: >> > 0. Client and Server establish a TLS connection 1. Client sends some >> > app data with a TB 2. Client sends a ClientHello to start >> > renegotiation 3. Server reads app data sent by Client from TLS >> > connection 4. Server's TLS stack continues the TLS renegotiation >> > handshake 5. Meanwhile, the server's application stack processes the >> > app data, including verifying the TB signature of the EKM. >> > >> > In step 5, the application stack queries the TLS stack for the EKM. If >> > step 4's handshake has finished before the application queries for the >> > EKM, the application will get the new EKM when it wants the old EKM. >> > (Or the application might query the TLS stack for the EKM during >> > renegotiation, which the TLS stack might not support.) Obviously this >> > is dependent on how the TLS stack is implemented and what interfaces >> > it provides to the application. >> > >> > This is all assuming that there's a well-defined way to identify a >> > TokenBindingMessage as belonging to a particular set of >> > application_data TLS messages, that all of those application_data >> > messages ended up on the same side of the ChangeCipherSpec message, >> > and that ChangeCipherSpec is the correct point to use (instead of e.g. >> > Finished) to indicate that renegotiation has completed and the new EKM >> > instead of the old EKM should be used. >> > >> > _______________________________________________ >> > Unbearable mailing list >> > Unbearable@ietf.org >> > https://www.ietf.org/mailman/listinfo/unbearable >> > >> > > --001a114abbd21e8048053eda5153 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There's an abstraction implied by TLS that's follo= wed by most, if not all, TLS implementations/APIs where the application is = exposed to reading and writing the application data and is mostly shielded = from the other details of the happens at the TLS layer like the crypto or w= hen exactly a renegotiation might have happened.=C2=A0 In principle in the = messaging there is a clear way to know what application data is associated = with which master secret / EKM, but in practice the application data is opa= que to the TLS layer and the TLS stuff is hidden from the application. I do= think there's a problem here but not sure how serious or likely it act= ually is. How much is renegotiation really done? Or will be done with TB? A= s has been noted, TLS 1.3 and HTTP2 are doing away with it. In my own produ= ct experience, we did it years ago to support asking for client auth on cer= tain resources but it was always pretty flaky and we disabled it when the r= enegotiation vulnerability came out and then never turned it back on. And w= hat's the impact of using the other EKM? The connection gets terminated= and the client probably tries again. Maybe one could get into a nasty cycl= e there. But it might not even be a visible issue in most cases.

Taking a step back, it seems there are a few options:
    =
  • Leave things as they are and just let things fall out as they may and h= ope it's not too bad (I think this is what Martin advocated for)
    • Leave things as they are and make some mention of the possibility of the = issue and maybe ways that could be used to deal with it (I do think that re= taining and checking multiple EKMs for a short time around the renegotiatio= n could work but is definitely a hassle)=C2=A0
  • Prohibit the us= e of TB and renegotiation together
  • Take Nick's proposal of= using only the EKM from the initial handshake (I don't claim to fully = understand the security ramifications but it's not clear to me that sec= urity is degraded by this)



On Thu, Oct 13, 2016 at 7:30 PM, = Nick Harper <nharper@google.com> wrote:
Correct, I think that using the EKM from th= e latest handshake provides no additional value. I think implementation dif= ficulty might be more than just "a hassle" - it might be impossib= le to implement with OpenSSL's current API. Additionally, it requires t= hat an application protocol that uses both renegotiation and Token Binding = define a clear boundary between application data pre-renegotiation and appl= ication data post-renegotiation.

On Thu, Oct 13= , 2016 at 6:15 PM, Andrei Popov <Andrei.Popov@microsoft.com&g= t; wrote:
+ Dirk

I guess, the key question is whether we care to do proof of possession afte= r renegotiation, or would be content using a stale EKM from the beginning o= f the connection.

My vote is to use the latest EKM and proper proof of possession after reneg= otiation; Nick appears to think that POP after renegotiation is no use and = a hassle to implement.
Anyone else has an opinion?

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com]
Sent: Thursday, October 13, 2016 6:10 PM
To: Nick Harper <nharper@google.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; IETF Tokbind WG <unbearable@ietf.org&g= t;; Brian Campbell <bcampbell@pingidentity.com>
Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiat= ion

Yes, requests that span a renegotiation can fail.=C2=A0 Of co= urse, you could arrange things so that the renegotiation is triggered after= validating the TB and avoid the problem.

I don't think we need to add extra complexity to deal with this.=C2=A0 = If anything this makes me more confident that removing renegotiation from T= LS 1.3 was the right choice.

On 14 October 2016 at 10:12, Nick Harper <nharper@google.com> wrote:
>
> On Thu, Oct 13, 2016 at 2:55 PM, Andrei Popov
> <An= drei.Popov@microsoft.com>
> wrote:
>>
>> A TLS server always knows what TLS session/connection a given
>> application_data message belongs to, otherwise it would not be abl= e
>> to decrypt this application_data in the first place.
>>
>> And application_data carries the TB message.
>>
>>
>
>
> Does the application always know what TLS session/SecurityParameters > an application_data message belongs to? I imagine the application only=
> has an interface like SSL_read to read application data from the TLS > stack, and when processing the TB message, it makes another call to > the TLS stack some time delta later to get the EKM. The SSL_read
> interface only provides a sequence of bytes, not some identifier for > the TLS session that the application could use when querying for the E= KM later.
>
> I'm thinking of something like what Brian mentioned:
> 0. Client and Server establish a TLS connection 1. Client sends some > app data with a TB 2. Client sends a ClientHello to start
> renegotiation 3. Server reads app data sent by Client from TLS
> connection 4. Server's TLS stack continues the TLS renegotiation > handshake 5. Meanwhile, the server's application stack processes t= he
> app data, including verifying the TB signature of the EKM.
>
> In step 5, the application stack queries the TLS stack for the EKM. If=
> step 4's handshake has finished before the application queries for= the
> EKM, the application will get the new EKM when it wants the old EKM. > (Or the application might query the TLS stack for the EKM during
> renegotiation, which the TLS stack might not support.) Obviously this<= br> > is dependent on how the TLS stack is implemented and what interfaces > it provides to the application.
>
> This is all assuming that there's a well-defined way to identify a=
> TokenBindingMessage as belonging to a particular set of
> application_data TLS messages, that all of those application_data
> messages ended up on the same side of the ChangeCipherSpec message, > and that ChangeCipherSpec is the correct point to use (instead of e.g.=
> Finished) to indicate that renegotiation has completed and the new EKM=
> instead of the old EKM should be used.
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ie= tf.org
> https://www.ietf.org/mailman/listinfo/unbe= arable
>


--001a114abbd21e8048053eda5153-- From nobody Mon Oct 17 03:44:02 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FAF1295ED for ; Mon, 17 Oct 2016 03:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifIgjJF01ynw for ; Mon, 17 Oct 2016 03:43:58 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49A31295DC for ; Mon, 17 Oct 2016 03:43:57 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id z190so225949384qkc.2 for ; Mon, 17 Oct 2016 03:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DIAiTa1DCaOxjMJzTBq8l4KTIC9fQM52TZl+I7NiRg8=; b=v2RUPW6oEL8n6/BmApuJbh52DZFnE7A7XJqChgYqlzijA8jmhNzo95w2nzfiNK0s36 +ZzBZ97q2MrufQ4ZetSqVIR3i6E0JCp+2hC22Ish614nCpFxmDMw3M7IjGVEpkWI8+p1 ZgProwKOOOeiZI4yuyxV75Yn9J5pF1vqIkxlVmV1fjIU7lgb0aLRnd8ctW7b/OKs4nCE jhKUG78cVJGOeZexWZ8wYZw7k2v3OgwkyJR534T4FhG+2aHRTcoqqUFSovACPy3gwlsu HXIJJiUL+9RBgrLk35+oF8j3MC3G5Dd4lNUmz4JyFq1nlLhNorpu1LcVZod8V63gAzwy VzGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DIAiTa1DCaOxjMJzTBq8l4KTIC9fQM52TZl+I7NiRg8=; b=D83GUa8PVju43cZ6vRIv/N53QVzf7adUdLPdqngpnoNn83HTFAqz607eJPMR7PfCdm xb8ApgrzDUkdDvp84Wp13lXssxYQkMJ5fT+UPhNArh+lFihVRhhCPLxFLGlJJBYOBuY9 /iQk+yjEhjwIrkC8+tpnpJ9xO+At7LwHCmznCg1sf/58YuuYN3URaxoJa3ziC8abxJGA AdeCRdP3e7BjQJKK20Jl5Rzhxzi/1xeFMK59luKe1st8p7WhZmiwIy5WtMpIjrswvhEu CoHpUtdeRMquLLdg4jmcX/8p0rHZus1VtCJ4G0Fp+BF/Sq7QyJ9aYXVQtp8Ve7EIL+q0 QtAw== X-Gm-Message-State: AA6/9RmzWtpU1lQUkXavMz+dRNmVf/tbTfKNSedU1PH1bG9KtELLbgajrzJvfcyWnuNU6QQS7veWt8sBJticow== X-Received: by 10.55.163.214 with SMTP id m205mr22294977qke.68.1476701037089; Mon, 17 Oct 2016 03:43:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 17 Oct 2016 03:43:56 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 17 Oct 2016 21:43:56 +1100 Message-ID: To: Brian Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Andrei Popov , "Dirk Balfanz \(balfanz@google.com\)" , IETF Tokbind WG , Nick Harper Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 17 Oct 2016 10:43:59 -0000 On 15 October 2016 at 08:57, Brian Campbell wrote: > Leave things as they are and just let things fall out as they may and hope > it's not too bad (I think this is what Martin advocated for) > Leave things as they are and make some mention of the possibility of the > issue and maybe ways that could be used to deal with it (I do think that > retaining and checking multiple EKMs for a short time around the > renegotiation could work but is definitely a hassle) I think that we should say use the EKM that is based on the current MS. I am very happy to see text that explains the hazards of renegotiation in this context and that initiators of renegotiation should ensure that they line their ducks up correctly (with all the ins-and-outs, etc...). Note: I have no problem with a server that receives a request that triggers renegotiation checking the token BEFORE initiating renegotiation. That seems OK to me. I am concerned that requiring that the server also check afterwards is just guaranteeing failure. And I don't think that we have a retry built in here, so that could be a hard failure. I hope that is not what Andrei is advocating, because I think that I agree with his view on this. From nobody Mon Oct 17 10:37:00 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3C7129987 for ; Mon, 17 Oct 2016 10:36:58 -0700 (PDT) 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 p1CABuoFhbNc for ; Mon, 17 Oct 2016 10:36:56 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0100.outbound.protection.outlook.com [104.47.40.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 8F4B512997F for ; Mon, 17 Oct 2016 10:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=urZmWcoXKwBWB2PGWQ/QY3ZPIwllZX2Xnc9ex22x/s4=; b=QmG6itFqXy3irdQYE/lTKuuH3x30eBZzQVgoyonHA0J9JaSSWArNDnXoMkiESmB68e4B8t/DP+tKkuk/pZVO5RPdnrMQxmLrHerowFXumbT8VNrm6FOOesdlKs/voNCAW3O/EiXjgWcKeLlwNlHvXueAZgBkbcy4P0giUZ28k3I= 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.649.16; Mon, 17 Oct 2016 17:36:46 +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.0649.027; Mon, 17 Oct 2016 17:36:46 +0000 From: Andrei Popov To: Martin Thomson , Brian Campbell Thread-Topic: [Unbearable] Clarifying Token Binding behavior with renegotiation Thread-Index: AQHSIPYAfU8tAUm590uf08aV6ED2raCgzRRQgAEzGoCAAzA0MIAALqIAgAF1/4CAAA6RAIAADFyAgAACGLCAABqEgIAAIPaAgAAAVDCAAAVwgIABVqmAgAP63QCAAHGoIA== Date: Mon, 17 Oct 2016 17:36:45 +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::1d2] x-ms-office365-filtering-correlation-id: a93e3392-409e-4516-9c11-08d3f6b42ab1 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 7:WhmLEsEpz1/yAOF0CG0pwwoWkmr+mATqXbTfNATGXSLmK8KJ+B8kuaJAs3Zh0hghy1WiIHWB1qSyyngydnxs5ih9J2Xt1Fr9SAtto+e6MLB9Fmf824CjVgn8X1upu52mPuqosWeT7vQHZmCzZIa1iITioPpp9NEQXHz2m/+5kE9+etLbo7nzKUNt8e+F4sszVQiaYTdayjd/LTbyNMwhqWCIowsZuRHoY27Nqvs8s6oAIozoQ/q19xhSKqlHvbx2JvIV67Q3BVqZhlRbRdz0jK13Dqq/obSSMsvNhhmaPbH0sTC22XDG0PE7EZsGRa3KhZEFDtqX0d8N+f674qs12tWPMPZ7B6eFK6ItQAsp7J6Laj6DaVGkzJ7zF8VZakak x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0844; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844; x-forefront-prvs: 0098BA6C6C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(51444003)(189002)(199003)(2900100001)(87936001)(5660300001)(586003)(10290500002)(4326007)(50986999)(77096005)(10400500002)(92566002)(86612001)(122556002)(54356999)(305945005)(5005710100001)(102836003)(8990500004)(106356001)(33656002)(9686002)(106116001)(3660700001)(76576001)(99286002)(68736007)(7696004)(8676002)(11100500001)(3280700002)(8936002)(6116002)(81156014)(5001770100001)(76176999)(101416001)(86362001)(7846002)(189998001)(74316002)(5002640100001)(7736002)(93886004)(10090500001)(2906002)(2950100002)(81166006)(105586002)(97736004)(3826002); 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2016 17:36:45.8529 (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 , "Dirk Balfanz \(balfanz@google.com\)" , Nick Harper Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 17 Oct 2016 17:36:58 -0000 PiBJIHRoaW5rIHRoYXQgd2Ugc2hvdWxkIHNheSB1c2UgdGhlIEVLTSB0aGF0IGlzIGJhc2VkIG9u IHRoZSBjdXJyZW50IE1TLiAgDQpPdGhlcndpc2UsIHdlJ3JlIGVmZmVjdGl2ZWx5IHNheWluZyB0 aGVyZSBpcyBubyBwcm9vZiBvZiBwb3NzZXNzaW9uIG9mIHRoZSBUQiBrZXkgYWZ0ZXIgcmVuZWdv dGlhdGlvbi4NCg0KPiBJIGFtIHZlcnkgaGFwcHkgdG8gc2VlIHRleHQgdGhhdCBleHBsYWlucyB0 aGUgaGF6YXJkcyBvZiByZW5lZ290aWF0aW9uIGluIHRoaXMgY29udGV4dCBhbmQgdGhhdCBpbml0 aWF0b3JzIG9mIHJlbmVnb3RpYXRpb24gc2hvdWxkIGVuc3VyZSB0aGF0IHRoZXkgbGluZSB0aGVp ciBkdWNrcyB1cCBjb3JyZWN0bHkgKHdpdGggYWxsIHRoZSBpbnMtYW5kLW91dHMsIGV0Yy4uLiku DQpJJ2xsIGFkZCBzb21lIHRleHQgdG8gdGhpcyBlZmZlY3QgaW4gdGhlIG5leHQgcmV2aXNpb24u DQoNCj4gTm90ZTogSSBoYXZlIG5vIHByb2JsZW0gd2l0aCBhIHNlcnZlciB0aGF0IHJlY2VpdmVz IGEgcmVxdWVzdCB0aGF0IHRyaWdnZXJzIHJlbmVnb3RpYXRpb24gY2hlY2tpbmcgdGhlIHRva2Vu IEJFRk9SRSBpbml0aWF0aW5nIHJlbmVnb3RpYXRpb24uICBUaGF0IHNlZW1zIE9LIHRvIG1lLg0K WWVzLCB0aGlzIGlzIHRoZSBpZGVhIChhbmQgdGhpcyBpcyBob3cgd2UndmUgY3VycmVudGx5IGlt cGxlbWVudGVkIGl0KS4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg== From nobody Wed Oct 19 13:31:03 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BEA129463 for ; Wed, 19 Oct 2016 13:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 pxdZ2_d74u7E for ; Wed, 19 Oct 2016 13:31:00 -0700 (PDT) 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 3DDA11293E3 for ; Wed, 19 Oct 2016 13:31:00 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id m138so43279290itm.0 for ; Wed, 19 Oct 2016 13:31:00 -0700 (PDT) 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=PGaT6vETdSL2yI5TOx1dgkqObvl/ljnhdQZZr+YGddw=; b=MjR/6TQx76+yraPNiL5OyPb5x1UQMIvFmCENOlnBu7s3hXux7oahb5Pnl1r4C+Hl1U RoYbbbVPrK8oRAZ8UXyms/HoWKIoZIM6QNlUD55aIrypPj8x66WITwudOw2a1oNXdy9q sbfDI8wpqTjL3ZOh+beE0u9Txxe38+2veFv3E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PGaT6vETdSL2yI5TOx1dgkqObvl/ljnhdQZZr+YGddw=; b=Rp/ZlC9Dml2/o9m3Pc4m+Y2H2xfdNz7WQQe8EkzEw5i8ymHJBzNPKzGTRbWdTKkJGA BGrY1uLucAdW19NEMiQsSxIaY3T5KgbF93F+bBfDGAxKoubyDYpuC5dnv3ldVfv6MOd9 NPmJc6s/5fKTMGAzrQ4Zs+VF6lXmyQc3XlOjR4d0NSN3twyKlso/BdWaeIkYiKjdm0Qi cDaKjUrX5xpDCXbE3VvB/ZhGHPMlCVrWBx+CB538wwuII7i20N5hvg8UxERlXhfF7ett mHiHZbuJk8moa+sgHyt6fu5tNI2GE6CYG/wKj50yIXMMdVl8eCvB8JAJAIZ9Q+xvorgy Zq/A== X-Gm-Message-State: AA6/9Rm0ebk5PQ3goC5JgGnyQ6H5aZVRnbZiB92n14BWrGc8qx8HOYD1dzMKKQgN9PRnsJsRD9gwwEl9YWKxHaV1 X-Received: by 10.107.13.194 with SMTP id 185mr8363394ion.122.1476909059390; Wed, 19 Oct 2016 13:30:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.5.148 with HTTP; Wed, 19 Oct 2016 13:30:28 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 19 Oct 2016 14:30:28 -0600 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a113a2b04da020d053f3dafa5 Archived-At: Cc: "Dirk Balfanz \(balfanz@google.com\)" , IETF Tokbind WG , Martin Thomson , Nick Harper Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 19 Oct 2016 20:31:01 -0000 --001a113a2b04da020d053f3dafa5 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 17, 2016 at 11:36 AM, Andrei Popov wrote: > > > Note: I have no problem with a server that receives a request that > triggers renegotiation checking the token BEFORE initiating renegotiation. > That seems OK to me. > Yes, this is the idea (and this is how we've currently implemented it). > > What happens in that implementation, if the client has pipelined other requests that have a TB message produced with the first EKM? Meaning the request is already in flight but not yet processed when the server initiates renegotiation. --001a113a2b04da020d053f3dafa5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Oct 17, 2016 at 11:36 AM, Andrei Popov <Andrei.Popov@micr= osoft.com> wrote:

> Note: I have no problem with a server that receives a request that tri= ggers renegotiation checking the token BEFORE initiating renegotiation.=C2= =A0 That seems OK to me.
Yes, this is the idea (and this is how we've currently implement= ed it).


What happens in that implementation, i= f the client has pipelined other requests that have a TB message produced w= ith the first EKM? Meaning the request is already in flight but not yet pro= cessed when the server initiates renegotiation.
--001a113a2b04da020d053f3dafa5-- From nobody Wed Oct 19 14:08:21 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3141296A2 for ; Wed, 19 Oct 2016 14:08:20 -0700 (PDT) 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 TY67kEOxZo5s for ; Wed, 19 Oct 2016 14:08:18 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0100.outbound.protection.outlook.com [104.47.38.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 8839D1294D6 for ; Wed, 19 Oct 2016 14:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZuH4W4neSyYQkcYhOq6Nd6musp3x0jKhhEtBn+QGNQA=; b=h7C3wVo3LSS2QSziRxhl48kyybMsz8YPjK/1+smhr5XvGZFPkRHbAN6SLd5G7+b4ztJ0wey/PLjtpSjIqJiTWjPXglAeCuaGNT+w9zRrj8qUYUyCA9vYf57xdbPdgXZH9DTjdqzQm6Wi0vz5vnrmu1yT9lt8i/xXFksOIE8G3QA= Received: from BY1PR0301MB0838.namprd03.prod.outlook.com (10.160.193.144) by BY1PR0301MB0837.namprd03.prod.outlook.com (10.160.193.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Wed, 19 Oct 2016 21:08:11 +0000 Received: from BY1PR0301MB0838.namprd03.prod.outlook.com ([10.160.193.144]) by BY1PR0301MB0838.namprd03.prod.outlook.com ([10.160.193.144]) with mapi id 15.01.0639.019; Wed, 19 Oct 2016 21:08:11 +0000 From: Andrei Popov To: Brian Campbell Thread-Topic: [Unbearable] Clarifying Token Binding behavior with renegotiation Thread-Index: AQHSIPYAfU8tAUm590uf08aV6ED2raCgzRRQgAEzGoCAAzA0MIAALqIAgAF1/4CAAA6RAIAADFyAgAACGLCAABqEgIAAIPaAgAAAVDCAAAVwgIABVqmAgAP63QCAAHGoIIADVuIAgAAJ/5A= Date: Wed, 19 Oct 2016 21:08:11 +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: [50.46.229.189] x-ms-office365-filtering-correlation-id: aca4ce09-8c30-42d6-93ad-08d3f86408a8 x-microsoft-exchange-diagnostics: 1; BY1PR0301MB0837; 7:2g1hcf4w6fa14Rc4UKgjv1RUXBFaP0CtoIHQN4B2CNWbhjy7uQJqNGbA5M5lmaYdnzj1fOFYolirBdFL3zcTY5TcY9q0jOxidcGZW1sP+9ZPgUgSYKQ2zxC+vOllb4Oz0Q/53dasGVUNDO+JXLcqqVEbw1B0VgX9VPw2yQ4ibt9A6vx03ea8wAwSyfJHrivCOeSugUFjRDjCM0/Tt6gmm4iEgEo4WLRBfsFOaCrL2lMlFy5ImUB41pc63vIu5+hYb1oP/ifJxX9bT6y3wDHcdHJLfjG4doQzSq4ugEYRISLVXH+53iMqTMWHL652oHM9MfwmRyxHbCJEuBQoyuxb4L3KkCFtNjQGemdz8AoxkZo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB0837; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060202)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BY1PR0301MB0837; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB0837; x-forefront-prvs: 0100732B76 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(24454002)(377454003)(19625215002)(10090500001)(122556002)(106116001)(6916009)(2950100002)(19580395003)(33656002)(19580405001)(99286002)(8936002)(106356001)(4326007)(105586002)(5660300001)(101416001)(8990500004)(66066001)(5005710100001)(10290500002)(189998001)(2906002)(86612001)(10400500002)(16236675004)(7696004)(110136003)(9686002)(68736007)(5002640100001)(8676002)(86362001)(81166006)(93886004)(19300405004)(3280700002)(3660700001)(54356999)(76176999)(74316002)(87936001)(50986999)(586003)(15975445007)(81156014)(7846002)(77096005)(76576001)(790700001)(6116002)(19609705001)(7736002)(97736004)(92566002)(102836003)(11100500001)(3846002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB0837; H:BY1PR0301MB0838.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_BY1PR0301MB0838BD67462D4910BC46040E8CD20BY1PR0301MB0838_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2016 21:08:11.3180 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0301MB0837 Archived-At: Cc: "Dirk Balfanz \(balfanz@google.com\)" , IETF Tokbind WG , Martin Thomson , Nick Harper Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 19 Oct 2016 21:08:20 -0000 --_000_BY1PR0301MB0838BD67462D4910BC46040E8CD20BY1PR0301MB0838_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSByZXF1ZXN0IHRoYXQgaGFzIGFuIGludmFsaWQgYmluZGluZyAoYXMgaW4gYSBzaWduYXR1cmUg b3ZlciB0aGUgd3JvbmcgRUtNIHZhbHVlKSB3aWxsIGZhaWwuDQoNCkZyb206IEJyaWFuIENhbXBi ZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQpTZW50OiBXZWRuZXNkYXks IE9jdG9iZXIgMTksIDIwMTYgMTozMCBQTQ0KVG86IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92 QG1pY3Jvc29mdC5jb20+DQpDYzogTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWls LmNvbT47IE5pY2sgSGFycGVyIDxuaGFycGVyQGdvb2dsZS5jb20+OyBEaXJrIEJhbGZhbnogKGJh bGZhbnpAZ29vZ2xlLmNvbSkgPGJhbGZhbnpAZ29vZ2xlLmNvbT47IElFVEYgVG9rYmluZCBXRyA8 dW5iZWFyYWJsZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gQ2xhcmlmeWlu ZyBUb2tlbiBCaW5kaW5nIGJlaGF2aW9yIHdpdGggcmVuZWdvdGlhdGlvbg0KDQoNCk9uIE1vbiwg T2N0IDE3LCAyMDE2IGF0IDExOjM2IEFNLCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNy b3NvZnQuY29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQo+ IE5vdGU6IEkgaGF2ZSBubyBwcm9ibGVtIHdpdGggYSBzZXJ2ZXIgdGhhdCByZWNlaXZlcyBhIHJl cXVlc3QgdGhhdCB0cmlnZ2VycyByZW5lZ290aWF0aW9uIGNoZWNraW5nIHRoZSB0b2tlbiBCRUZP UkUgaW5pdGlhdGluZyByZW5lZ290aWF0aW9uLiAgVGhhdCBzZWVtcyBPSyB0byBtZS4NClllcywg dGhpcyBpcyB0aGUgaWRlYSAoYW5kIHRoaXMgaXMgaG93IHdlJ3ZlIGN1cnJlbnRseSBpbXBsZW1l bnRlZCBpdCkuDQoNCldoYXQgaGFwcGVucyBpbiB0aGF0IGltcGxlbWVudGF0aW9uLCBpZiB0aGUg Y2xpZW50IGhhcyBwaXBlbGluZWQgb3RoZXIgcmVxdWVzdHMgdGhhdCBoYXZlIGEgVEIgbWVzc2Fn ZSBwcm9kdWNlZCB3aXRoIHRoZSBmaXJzdCBFS00/IE1lYW5pbmcgdGhlIHJlcXVlc3QgaXMgYWxy ZWFkeSBpbiBmbGlnaHQgYnV0IG5vdCB5ZXQgcHJvY2Vzc2VkIHdoZW4gdGhlIHNlcnZlciBpbml0 aWF0ZXMgcmVuZWdvdGlhdGlvbi4NCg== --_000_BY1PR0301MB0838BD67462D4910BC46040E8CD20BY1PR0301MB0838_ 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 CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uZ21haWwtDQoJe21z by1zdHlsZS1uYW1lOmdtYWlsLTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5BIHJlcXVlc3QgdGhhdCBoYXMgYW4gaW52YWxpZCBiaW5kaW5nIChhcyBpbiBhIHNpZ25h dHVyZSBvdmVyIHRoZSB3cm9uZyBFS00gdmFsdWUpIHdpbGwgZmFpbC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tXQ0K PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgT2N0b2JlciAxOSwgMjAxNiAxOjMwIFBNPGJy Pg0KPGI+VG86PC9iPiBBbmRyZWkgUG9wb3YgJmx0O0FuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29t Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdt YWlsLmNvbSZndDs7IE5pY2sgSGFycGVyICZsdDtuaGFycGVyQGdvb2dsZS5jb20mZ3Q7OyBEaXJr IEJhbGZhbnogKGJhbGZhbnpAZ29vZ2xlLmNvbSkgJmx0O2JhbGZhbnpAZ29vZ2xlLmNvbSZndDs7 IElFVEYgVG9rYmluZCBXRyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBDbGFyaWZ5aW5nIFRva2VuIEJpbmRpbmcgYmVoYXZp b3Igd2l0aCByZW5lZ290aWF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIE1vbiwgT2N0IDE3LCAyMDE2IGF0IDExOjM2IEFNLCBBbmRyZWkgUG9wb3YgJmx0Ozxh IGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsi PkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7IE5vdGU6IEkgaGF2ZSBubyBw cm9ibGVtIHdpdGggYSBzZXJ2ZXIgdGhhdCByZWNlaXZlcyBhIHJlcXVlc3QgdGhhdCB0cmlnZ2Vy cyByZW5lZ290aWF0aW9uIGNoZWNraW5nIHRoZSB0b2tlbiBCRUZPUkUgaW5pdGlhdGluZyByZW5l Z290aWF0aW9uLiZuYnNwOyBUaGF0IHNlZW1zIE9LIHRvIG1lLjwvc3Bhbj48YnI+DQpZZXMsIHRo aXMgaXMgdGhlIGlkZWEgKGFuZCB0aGlzIGlzIGhvdyB3ZSd2ZSBjdXJyZW50bHkgaW1wbGVtZW50 ZWQgaXQpLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V2hhdCBoYXBwZW5zIGluIHRoYXQgaW1wbGVtZW50YXRpb24sIGlmIHRoZSBj bGllbnQgaGFzIHBpcGVsaW5lZCBvdGhlciByZXF1ZXN0cyB0aGF0IGhhdmUgYSBUQiBtZXNzYWdl IHByb2R1Y2VkIHdpdGggdGhlIGZpcnN0IEVLTT8gTWVhbmluZyB0aGUgcmVxdWVzdCBpcyBhbHJl YWR5IGluIGZsaWdodCBidXQgbm90IHlldCBwcm9jZXNzZWQgd2hlbiB0aGUgc2VydmVyIGluaXRp YXRlcw0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+cmVuZWdvdGlhdGlvbi48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BY1PR0301MB0838BD67462D4910BC46040E8CD20BY1PR0301MB0838_-- From nobody Wed Oct 19 14:15:03 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBEB12965C for ; Wed, 19 Oct 2016 14:15:01 -0700 (PDT) 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 OFXldGOdm_HY for ; Wed, 19 Oct 2016 14:14:59 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0107.outbound.protection.outlook.com [104.47.36.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F441294D6 for ; Wed, 19 Oct 2016 14:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qv4MSJKTsL7kz3i/pdeIUZqWBJQ1HqTuiiA/NsCe3WY=; b=TKQkOETh3bssOLgbB1coupmNIdrWX4Ckd/vmEjOUIthVgr1i+RXIzB3V+rNWbBkZRIULzij/Y8yC+N4x+J30+txXUMC30kmUBSZDJXnlgg+TMmLC3MK/cHziyjiHWGlmz6KQTa3QJce1PR8eKj1K1go3C2NJN+5j/GRPhakUHxI= Received: from BY1PR0301MB0838.namprd03.prod.outlook.com (10.160.193.144) by BY1PR0301MB0840.namprd03.prod.outlook.com (10.160.193.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Wed, 19 Oct 2016 21:14:56 +0000 Received: from BY1PR0301MB0838.namprd03.prod.outlook.com ([10.160.193.144]) by BY1PR0301MB0838.namprd03.prod.outlook.com ([10.160.193.144]) with mapi id 15.01.0639.019; Wed, 19 Oct 2016 21:14:56 +0000 From: Andrei Popov To: Andrei Popov , Brian Campbell Thread-Topic: [Unbearable] Clarifying Token Binding behavior with renegotiation Thread-Index: AQHSKk3X8FdEb1+m+kS68yk52gq5Tg== Date: Wed, 19 Oct 2016 21:14:56 +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: [50.46.229.189] x-ms-office365-filtering-correlation-id: 4ec7dff9-5fee-4b6f-2daf-08d3f864fa24 x-microsoft-exchange-diagnostics: 1; BY1PR0301MB0840; 7:r3/0Oc3OqZybWRZ9BtABPm78ZvsGwXVijTsnAtFPkl4FW8yoXtqx1F7EAGF4EjcGXJlQbZSkdVaNuBXsTmo4sC1yPlUjFB9EdV+lCXixCxqXlahoxoBpgc2yiCG2AcOJRyT3QvaIUhdQzVgTs0V9WVSqoAAtZVl2/gg0MJ2SrqHldTPVj2DLeKXPv/DJaFEVv8KoG9PM03Op6yjLkfdO5fgQQ7fHjHTrzDjTynuh+ikTOLTAjjVG1P9aKtCVTePJVYgnWGQ9pZvNXbPpxy0PCtVod48PvB8y+FM6MwijNKRk0Csrg6l5miEpAWnoX2ze+OhlWbUM509OAS28EutCk0PJd1tCAeJycTFsD5wJUN8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB0840; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BY1PR0301MB0840; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB0840; x-forefront-prvs: 0100732B76 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(24454002)(377454003)(189002)(2906002)(7696004)(7736002)(87936001)(66066001)(790700001)(74316002)(7846002)(19609705001)(1511001)(68736007)(76576001)(92566002)(86362001)(86612001)(15975445007)(2950100002)(19625215002)(2561002)(97736004)(11100500001)(2900100001)(189998001)(77096005)(5001770100001)(19300405004)(9686002)(101416001)(10090500001)(54356999)(33656002)(5002640100001)(81156014)(8936002)(16236675004)(19580405001)(8990500004)(76176999)(50986999)(5660300001)(10400500002)(5005710100001)(10290500002)(19580395003)(586003)(3660700001)(106356001)(106116001)(105586002)(6116002)(3846002)(99286002)(102836003)(122556002)(4326007)(81166006)(2421001)(93886004)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB0840; H:BY1PR0301MB0838.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_BY1PR0301MB08380AD673A63DECBCD39DBF8CD20BY1PR0301MB0838_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2016 21:14:56.3808 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0301MB0840 Archived-At: Cc: Martin Thomson , IETF Tokbind WG , "Dirk Balfanz \(balfanz@google.com\)" , Nick Harper Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 19 Oct 2016 21:15:01 -0000 --_000_BY1PR0301MB08380AD673A63DECBCD39DBF8CD20BY1PR0301MB0838_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG8gZWxhYm9yYXRlIGEgYml0LCBpbiB5b3VyIHNwZWNpZmljIGV4YW1wbGUsIGlmIHRoZSBUTFMg c2VydmVyIGlzIGFibGUgdG8gZGVjcnlwdCB0aGUgcGlwZWxpbmVkIG1lc3NhZ2VzLCB0aGVuIHRo ZSBzZXJ2ZXLigJlzIEVLTSBpcyBzdGlsbCB0aGUgc2FtZSBvbmUgdGhlIGNsaWVudCB1c2VkIGZv ciB0aGUgYmluZGluZy4gQW5kIGlmIHRoZSBzZXJ2ZXIgaXMgdW5hYmxlIHRvIGRlY3J5cHQgdGhl IG1lc3NhZ2VzLCBpdCBkb2VzIG5vdCBtYXR0ZXIgdGhhdCB0aGVpciBiaW5kaW5nIGlzIGFsc28g aW52YWxpZOKApg0KDQpGcm9tOiBVbmJlYXJhYmxlIFttYWlsdG86dW5iZWFyYWJsZS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5kcmVpIFBvcG92DQpTZW50OiBXZWRuZXNkYXksIE9j dG9iZXIgMTksIDIwMTYgMjowOCBQTQ0KVG86IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGlu Z2lkZW50aXR5LmNvbT4NCkNjOiBEaXJrIEJhbGZhbnogKGJhbGZhbnpAZ29vZ2xlLmNvbSkgPGJh bGZhbnpAZ29vZ2xlLmNvbT47IElFVEYgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz47 IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+OyBOaWNrIEhhcnBlciA8 bmhhcnBlckBnb29nbGUuY29tPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBDbGFyaWZ5aW5n IFRva2VuIEJpbmRpbmcgYmVoYXZpb3Igd2l0aCByZW5lZ290aWF0aW9uDQoNCkEgcmVxdWVzdCB0 aGF0IGhhcyBhbiBpbnZhbGlkIGJpbmRpbmcgKGFzIGluIGEgc2lnbmF0dXJlIG92ZXIgdGhlIHdy b25nIEVLTSB2YWx1ZSkgd2lsbCBmYWlsLg0KDQpGcm9tOiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRv OmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE5 LCAyMDE2IDE6MzAgUE0NClRvOiBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQu Y29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+DQpDYzogTWFydGluIFRob21z b24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwu Y29tPj47IE5pY2sgSGFycGVyIDxuaGFycGVyQGdvb2dsZS5jb208bWFpbHRvOm5oYXJwZXJAZ29v Z2xlLmNvbT4+OyBEaXJrIEJhbGZhbnogKGJhbGZhbnpAZ29vZ2xlLmNvbTxtYWlsdG86YmFsZmFu ekBnb29nbGUuY29tPikgPGJhbGZhbnpAZ29vZ2xlLmNvbTxtYWlsdG86YmFsZmFuekBnb29nbGUu Y29tPj47IElFVEYgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86dW5iZWFy YWJsZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIENsYXJpZnlpbmcgVG9r ZW4gQmluZGluZyBiZWhhdmlvciB3aXRoIHJlbmVnb3RpYXRpb24NCg0KDQpPbiBNb24sIE9jdCAx NywgMjAxNiBhdCAxMTozNiBBTSwgQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0 LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KPiBOb3Rl OiBJIGhhdmUgbm8gcHJvYmxlbSB3aXRoIGEgc2VydmVyIHRoYXQgcmVjZWl2ZXMgYSByZXF1ZXN0 IHRoYXQgdHJpZ2dlcnMgcmVuZWdvdGlhdGlvbiBjaGVja2luZyB0aGUgdG9rZW4gQkVGT1JFIGlu aXRpYXRpbmcgcmVuZWdvdGlhdGlvbi4gIFRoYXQgc2VlbXMgT0sgdG8gbWUuDQpZZXMsIHRoaXMg aXMgdGhlIGlkZWEgKGFuZCB0aGlzIGlzIGhvdyB3ZSd2ZSBjdXJyZW50bHkgaW1wbGVtZW50ZWQg aXQpLg0KDQpXaGF0IGhhcHBlbnMgaW4gdGhhdCBpbXBsZW1lbnRhdGlvbiwgaWYgdGhlIGNsaWVu dCBoYXMgcGlwZWxpbmVkIG90aGVyIHJlcXVlc3RzIHRoYXQgaGF2ZSBhIFRCIG1lc3NhZ2UgcHJv ZHVjZWQgd2l0aCB0aGUgZmlyc3QgRUtNPyBNZWFuaW5nIHRoZSByZXF1ZXN0IGlzIGFscmVhZHkg aW4gZmxpZ2h0IGJ1dCBub3QgeWV0IHByb2Nlc3NlZCB3aGVuIHRoZSBzZXJ2ZXIgaW5pdGlhdGVz IHJlbmVnb3RpYXRpb24uDQo= --_000_BY1PR0301MB08380AD673A63DECBCD39DBF8CD20BY1PR0301MB0838_ 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 CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uZ21haWwtDQoJe21z by1zdHlsZS1uYW1lOmdtYWlsLTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG8gZWxhYm9yYXRlIGEgYml0LCBp biB5b3VyIHNwZWNpZmljIGV4YW1wbGUsIGlmIHRoZSBUTFMgc2VydmVyIGlzIGFibGUgdG8gZGVj cnlwdCB0aGUgcGlwZWxpbmVkIG1lc3NhZ2VzLCB0aGVuIHRoZSBzZXJ2ZXLigJlzIEVLTSBpcyBz dGlsbCB0aGUgc2FtZSBvbmUgdGhlIGNsaWVudCB1c2VkIGZvciB0aGUNCiBiaW5kaW5nLiBBbmQg aWYgdGhlIHNlcnZlciBpcyB1bmFibGUgdG8gZGVjcnlwdCB0aGUgbWVzc2FnZXMsIGl0IGRvZXMg bm90IG1hdHRlciB0aGF0IHRoZWlyIGJpbmRpbmcgaXMgYWxzbyBpbnZhbGlk4oCmPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21w b3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFVuYmVhcmFibGUg W21haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PkFuZHJlaSBQb3Bvdjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE9jdG9iZXIgMTksIDIw MTYgMjowOCBQTTxicj4NCjxiPlRvOjwvYj4gQnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbEBw aW5naWRlbnRpdHkuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gRGlyayBCYWxmYW56IChiYWxmYW56 QGdvb2dsZS5jb20pICZsdDtiYWxmYW56QGdvb2dsZS5jb20mZ3Q7OyBJRVRGIFRva2JpbmQgV0cg Jmx0O3VuYmVhcmFibGVAaWV0Zi5vcmcmZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRo b21zb25AZ21haWwuY29tJmd0OzsgTmljayBIYXJwZXIgJmx0O25oYXJwZXJAZ29vZ2xlLmNvbSZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBDbGFyaWZ5aW5nIFRva2Vu IEJpbmRpbmcgYmVoYXZpb3Igd2l0aCByZW5lZ290aWF0aW9uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BIHJlcXVlc3QgdGhh dCBoYXMgYW4gaW52YWxpZCBiaW5kaW5nIChhcyBpbiBhIHNpZ25hdHVyZSBvdmVyIHRoZSB3cm9u ZyBFS00gdmFsdWUpIHdpbGwgZmFpbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IEJyaWFuIENhbXBiZWxsIFs8YSBocmVmPSJtYWlsdG86YmNhbXBi ZWxsQHBpbmdpZGVudGl0eS5jb20iPm1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwv YT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBPY3RvYmVyIDE5LCAyMDE2IDE6MzAg UE08YnI+DQo8Yj5Ubzo8L2I+IEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJl aS5Qb3BvdkBtaWNyb3NvZnQuY29tIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRp bi50aG9tc29uQGdtYWlsLmNvbSI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9hPiZndDs7IE5p Y2sgSGFycGVyICZsdDs8YSBocmVmPSJtYWlsdG86bmhhcnBlckBnb29nbGUuY29tIj5uaGFycGVy QGdvb2dsZS5jb208L2E+Jmd0OzsgRGlyayBCYWxmYW56ICg8YSBocmVmPSJtYWlsdG86YmFsZmFu ekBnb29nbGUuY29tIj5iYWxmYW56QGdvb2dsZS5jb208L2E+KSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmJhbGZhbnpAZ29vZ2xlLmNvbSI+YmFsZmFuekBnb29nbGUuY29tPC9hPiZndDs7DQogSUVURiBU b2tiaW5kIFdHICZsdDs8YSBocmVmPSJtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZyI+dW5iZWFy YWJsZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJs ZV0gQ2xhcmlmeWluZyBUb2tlbiBCaW5kaW5nIGJlaGF2aW9yIHdpdGggcmVuZWdvdGlhdGlvbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE9jdCAxNywgMjAx NiBhdCAxMTozNiBBTSwgQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBv cG92QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0 LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsgTm90 ZTogSSBoYXZlIG5vIHByb2JsZW0gd2l0aCBhIHNlcnZlciB0aGF0IHJlY2VpdmVzIGEgcmVxdWVz dCB0aGF0IHRyaWdnZXJzIHJlbmVnb3RpYXRpb24gY2hlY2tpbmcgdGhlIHRva2VuIEJFRk9SRSBp bml0aWF0aW5nIHJlbmVnb3RpYXRpb24uJm5ic3A7IFRoYXQgc2VlbXMgT0sgdG8gbWUuPC9zcGFu Pjxicj4NClllcywgdGhpcyBpcyB0aGUgaWRlYSAoYW5kIHRoaXMgaXMgaG93IHdlJ3ZlIGN1cnJl bnRseSBpbXBsZW1lbnRlZCBpdCkuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGhhcHBlbnMgaW4gdGhhdCBpbXBsZW1lbnRh dGlvbiwgaWYgdGhlIGNsaWVudCBoYXMgcGlwZWxpbmVkIG90aGVyIHJlcXVlc3RzIHRoYXQgaGF2 ZSBhIFRCIG1lc3NhZ2UgcHJvZHVjZWQgd2l0aCB0aGUgZmlyc3QgRUtNPyBNZWFuaW5nIHRoZSBy ZXF1ZXN0IGlzIGFscmVhZHkgaW4gZmxpZ2h0IGJ1dCBub3QgeWV0IHByb2Nlc3NlZCB3aGVuIHRo ZSBzZXJ2ZXIgaW5pdGlhdGVzDQo8c3BhbiBjbGFzcz0iZ21haWwtIj5yZW5lZ290aWF0aW9uLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY1PR0301MB08380AD673A63DECBCD39DBF8CD20BY1PR0301MB0838_-- From nobody Wed Oct 19 14:24:23 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BE3129704 for ; Wed, 19 Oct 2016 14:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 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.431, 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 IPYayGRPloFH for ; Wed, 19 Oct 2016 14:24:20 -0700 (PDT) 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 AE5121296E1 for ; Wed, 19 Oct 2016 14:24:19 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id o68so61064566qkf.3 for ; Wed, 19 Oct 2016 14:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U1Kf+nkkntUGZWL2xQPtDwb+EPDiFUJN8UhHIMq69Mk=; b=jkRGQnI7Vrjj+2GIzXeBte+2/fAizXgktbf38MAP7JOXfmYfSYCWly8Q9obm8oYxnM 4d0y2zJ7bFj+tX6DwoXWDWQsRhqhfNFgGxPkxDaWAI3dUfBhL5sb8V3QdQGwTWNA7Zrb c7I7u/FIc2fuzgHC8bLIonl2/6x4Im2JZRuPu4arFhwwVAVw/yrDLJ75MTZdaRjrhciW t8FFDd8HVUvASfajE6EoYa9welUpys5pIWWDpupzE0DXG4qBfv2E6WqjJwusJ70n0bwH NntC+OK9bZP6Eo8ni2EF5tAsLF2ET+IRczn4gk9DH9lSWd2IsbjL4xVr0rXAqYOjgKrc 5VMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U1Kf+nkkntUGZWL2xQPtDwb+EPDiFUJN8UhHIMq69Mk=; b=ePOGwe4DGa5uL8Is69ZClsmPCM87ILVHm9QfTAYe+D8YI5/GO4efAMXoGa6QLQPOfF fjDfsSeE9+hE9GcFdWiPR8pOk1Q7e1QNlubs8/oXt211jUINXNEvMiAy1yX0arWhIJTB +fWyY7nuiZBjdAduAxv2WmWAmW2W81hqmXvNvavu1xBA/QclzoDU8NRbkGp36EDotAsK +qJ2JS2HcwlepFt4TU3b3Y2im/0MVjFzc+3qOW47BIV8oegILUd/sJittVg+G5JjPhbd LTGpRhqm6cRvCVOzunh9lqPfUyVWF+PRS939SQncr3kfdXmaiXJpzckKVj+YQj8OQ2OM qt4A== X-Gm-Message-State: ABUngvey6V1ehLicZBj+zmZJ9Aq1KPGFnaikbWZ1y+JrmE/7HnrI+uuDG6xLU27CLMDsWnsvRDK3TuCU20N+LOS3 X-Received: by 10.55.49.8 with SMTP id x8mr7795182qkx.188.1476912258639; Wed, 19 Oct 2016 14:24:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.169.94 with HTTP; Wed, 19 Oct 2016 14:23:58 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Wed, 19 Oct 2016 14:23:58 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a11490d688af8a9053f3e6e23 Archived-At: Cc: Martin Thomson , IETF Tokbind WG , Brian Campbell , "Dirk Balfanz \(balfanz@google.com\)" Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 19 Oct 2016 21:24:22 -0000 --001a11490d688af8a9053f3e6e23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think what Brian was saying is that a client sends multiple HTTP/1.1 pipelined requests (e.g. A and B), with B sent before waiting on a reply for A from the server. What if request A is the one that triggers renegotiation? A token binding in B will still sign the same EKM as A. How does the server handle the valid token binding in request B? On Wed, Oct 19, 2016 at 2:14 PM, Andrei Popov wrote: > To elaborate a bit, in your specific example, if the TLS server is able t= o > decrypt the pipelined messages, then the server=E2=80=99s EKM is still th= e same one > the client used for the binding. And if the server is unable to decrypt t= he > messages, it does not matter that their binding is also invalid=E2=80=A6 > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *An= drei > Popov > *Sent:* Wednesday, October 19, 2016 2:08 PM > *To:* Brian Campbell > *Cc:* Dirk Balfanz (balfanz@google.com) ; IETF > Tokbind WG ; Martin Thomson ; > Nick Harper > *Subject:* Re: [Unbearable] Clarifying Token Binding behavior with > renegotiation > > > > A request that has an invalid binding (as in a signature over the wrong > EKM value) will fail. > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com > ] > *Sent:* Wednesday, October 19, 2016 1:30 PM > *To:* Andrei Popov > *Cc:* Martin Thomson ; Nick Harper < > nharper@google.com>; Dirk Balfanz (balfanz@google.com) ; > IETF Tokbind WG > *Subject:* Re: [Unbearable] Clarifying Token Binding behavior with > renegotiation > > > > > > On Mon, Oct 17, 2016 at 11:36 AM, Andrei Popov > wrote: > > > > Note: I have no problem with a server that receives a request that > triggers renegotiation checking the token BEFORE initiating renegotiation= . > That seems OK to me. > Yes, this is the idea (and this is how we've currently implemented it). > > > > What happens in that implementation, if the client has pipelined other > requests that have a TB message produced with the first EKM? Meaning the > request is already in flight but not yet processed when the server > initiates renegotiation. > --001a11490d688af8a9053f3e6e23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think what Brian was saying is that a client sends multi= ple HTTP/1.1 pipelined requests (e.g. A and B), with B sent before waiting = on a reply for A from the server. What if request A is the one that trigger= s renegotiation? A token binding in B will still sign the same EKM as A. Ho= w does the server handle the valid token binding in request B?

On Wed, Oct 19, 2016 at = 2:14 PM, Andrei Popov <Andrei.Popov@microsoft.com> = wrote:

To elaborate a bit, in your specific example, if th= e TLS server is able to decrypt the pipelined messages, then the server=E2= =80=99s EKM is still the same one the client used for the binding. And if the server is unable to decrypt the messages, it does not = matter that their binding is also invalid=E2=80=A6

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Andrei Popov
Sent: Wednesday, October 19, 2016 2:08 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Dirk Balfanz (balfanz@google.com) <balfanz@google.com>; IETF Tokbind WG <unbearable@ietf.org>; M= artin Thomson <martin.thomson@gmail.com>; Nick Harper <nharper@google.com>
Subject: Re: [Unbearable] Clarifying Token Binding behavior with ren= egotiation

=C2=A0

A request that has an invalid binding (as in a sign= ature over the wrong EKM value) will fail.

=C2=A0

From: Brian Campbell [mailto:bcampbell@pin= gidentity.com]
Sent: Wednesday, October 19, 2016 1:30 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Martin Thomson <martin.thomson@gmail.com>; Nick Harper <nharper@google.com>= ; Dirk Balfanz (bal= fanz@google.com) <balfanz@google.com>; IETF Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] Clarifying Token Binding behavior with ren= egotiation

=C2=A0

=C2=A0

On Mon, Oct 17, 2016 at 11:36 AM, Andrei Popov <<= a href=3D"mailto:Andrei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov= @microsoft.com> wrote:


> Note: I have no problem wit= h a server that receives a request that triggers renegotiation checking the= token BEFORE initiating renegotiation.=C2=A0 That seems OK to me. Yes, this is the idea (and this is how we've currently implemented it).=

=C2=A0

What happens in that implementation, if the client h= as pipelined other requests that have a TB message produced with the first = EKM? Meaning the request is already in flight but not yet processed when th= e server initiates renegotiation.<= /u>


--001a11490d688af8a9053f3e6e23-- From nobody Wed Oct 19 14:27:14 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E175C129704 for ; Wed, 19 Oct 2016 14:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 7Qk6SE83l9VA for ; Wed, 19 Oct 2016 14:27:12 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 1BD6C129472 for ; Wed, 19 Oct 2016 14:27:12 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 66so45305121itl.1 for ; Wed, 19 Oct 2016 14:27:12 -0700 (PDT) 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=Ny4SIKwOYhHd0zQmkMGVjDszThVf17MrAx3LqbQQqLo=; b=SKXdGnzvgbzQrC3lJ67mPzz17ZLy6ReA3IEwR7KKHnKgxiuLzauiELYvWlrsEPCJpW jZLiZkFyrwYD3fsiZjy/ldRgTxJct8weXYD24dPP3slQUYhaNsRwwDuLfF2NEOsnlPGy j1dwlzIdWZy5ar189ubPAsYdu0ECCJwoMrCAU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ny4SIKwOYhHd0zQmkMGVjDszThVf17MrAx3LqbQQqLo=; b=g2asatrqiXJqRPerJdfRXW1lRjmIpYhVTv2fRcyl5EMdW5jI2tj+xHhZBzsDyXcU+E nfv3uTOxt4fiISnUeldqhTB0PGNJw7dlruheXMJ/ft2S6ctv1d36AfJShCr47QEv174f JwalP1CspxThEoqb5BncJ+L1l2nan4kcekCZsBC1747TYP3tIYyWZWgzq1YVxYBs/9v8 zdFlfELq2Axj3hvU8w2pZXQcEdQ80/9P92tDfglx964e/JQP5LiaCdv70A7NyBqm5U4O AEq/Ir4r10tPmNUuLmWhoLqSdiw8nlLbEocu6MEYhfI6SguiiFYFL/RGL9WZ9vLJjLvW VUSA== X-Gm-Message-State: AA6/9Rn9Vs5z1vUE8bFnYTWjYoEvM+pjp1SP892Bz9POz4MTVHppshFqWACBuyV+swhz4iqmL1msRQp2KxZRiqdq X-Received: by 10.36.253.200 with SMTP id m191mr5150765ith.35.1476912429907; Wed, 19 Oct 2016 14:27:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.5.148 with HTTP; Wed, 19 Oct 2016 14:26:39 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 19 Oct 2016 15:26:39 -0600 Message-ID: To: Nick Harper Content-Type: multipart/alternative; boundary=94eb2c0361e2bfed12053f3e787d Archived-At: Cc: Martin Thomson , Andrei Popov , "Dirk Balfanz \(balfanz@google.com\)" , IETF Tokbind WG Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 19 Oct 2016 21:27:14 -0000 --94eb2c0361e2bfed12053f3e787d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, that's what I'm asking. Thanks for clarifying, Nick. On Wed, Oct 19, 2016 at 3:23 PM, Nick Harper wrote: > I think what Brian was saying is that a client sends multiple HTTP/1.1 > pipelined requests (e.g. A and B), with B sent before waiting on a reply > for A from the server. What if request A is the one that triggers > renegotiation? A token binding in B will still sign the same EKM as A. Ho= w > does the server handle the valid token binding in request B? > > On Wed, Oct 19, 2016 at 2:14 PM, Andrei Popov > wrote: > >> To elaborate a bit, in your specific example, if the TLS server is able >> to decrypt the pipelined messages, then the server=E2=80=99s EKM is stil= l the same >> one the client used for the binding. And if the server is unable to decr= ypt >> the messages, it does not matter that their binding is also invalid=E2= =80=A6 >> >> >> >> *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *A= ndrei >> Popov >> *Sent:* Wednesday, October 19, 2016 2:08 PM >> *To:* Brian Campbell >> *Cc:* Dirk Balfanz (balfanz@google.com) ; IETF >> Tokbind WG ; Martin Thomson < >> martin.thomson@gmail.com>; Nick Harper >> *Subject:* Re: [Unbearable] Clarifying Token Binding behavior with >> renegotiation >> >> >> >> A request that has an invalid binding (as in a signature over the wrong >> EKM value) will fail. >> >> >> >> *From:* Brian Campbell [mailto:bcampbell@pingidentity.com >> ] >> *Sent:* Wednesday, October 19, 2016 1:30 PM >> *To:* Andrei Popov >> *Cc:* Martin Thomson ; Nick Harper < >> nharper@google.com>; Dirk Balfanz (balfanz@google.com) < >> balfanz@google.com>; IETF Tokbind WG >> *Subject:* Re: [Unbearable] Clarifying Token Binding behavior with >> renegotiation >> >> >> >> >> >> On Mon, Oct 17, 2016 at 11:36 AM, Andrei Popov < >> Andrei.Popov@microsoft.com> wrote: >> >> >> > Note: I have no problem with a server that receives a request that >> triggers renegotiation checking the token BEFORE initiating renegotiatio= n. >> That seems OK to me. >> Yes, this is the idea (and this is how we've currently implemented it). >> >> >> >> What happens in that implementation, if the client has pipelined other >> requests that have a TB message produced with the first EKM? Meaning the >> request is already in flight but not yet processed when the server >> initiates renegotiation. >> > > --94eb2c0361e2bfed12053f3e787d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, that's what I'm asking. Thanks for clarifying= , Nick.

On Wed, Oct 19, 2016 at 3:23 PM, Nick Harper <nharper@google.com>= wrote:
I think w= hat Brian was saying is that a client sends multiple HTTP/1.1 pipelined req= uests (e.g. A and B), with B sent before waiting on a reply for A from the = server. What if request A is the one that triggers renegotiation? A token b= inding in B will still sign the same EKM as A. How does the server handle t= he valid token binding in request B?

On Wed, O= ct 19, 2016 at 2:14 PM, Andrei Popov <Andrei.Popov@microsoft.com<= /a>> wrote:

To elaborate a bit, in your specific example, if th= e TLS server is able to decrypt the pipelined messages, then the server=E2= =80=99s EKM is still the same one the client used for the binding. And if the server is unable to decrypt the messages, it does not = matter that their binding is also invalid=E2=80=A6

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ie= tf.org] On Behalf Of Andrei Popov
Sent: Wednesday, October 19, 2016 2:08 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Dirk Balfanz (balfanz@google.com) <balfanz@google.com>; IETF Tokbind WG <unbearable@ietf.org>; M= artin Thomson <martin.thomson@gmail.com>; Nick Harper <nharper@google.com>
Subject: Re: [Unbearable] Clarifying Token Binding behavior with ren= egotiation

=C2=A0

A request that has an invalid binding (as in a sign= ature over the wrong EKM value) will fail.

=C2=A0

From: Brian Campbell [mailto:bcampbell@pingiden= tity.com]
Sent: Wednesday, October 19, 2016 1:30 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Martin Thomson <martin.thomson@gmail.com>; Nick Harper <nharper@google.com>= ; Dirk Balfanz (bal= fanz@google.com) <balfanz@google.com>; IETF Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] Clarifying Token Binding behavior with ren= egotiation

=C2=A0

=C2=A0

On Mon, Oct 17, 2016 at 11:36 AM, Andrei Popov <<= a href=3D"mailto:Andrei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov= @microsoft.com> wrote:


> Note: I= have no problem with a server that receives a request that triggers renego= tiation checking the token BEFORE initiating renegotiation.=C2=A0 That seem= s OK to me.
Yes, this is the idea (and this is how we've currently implemented it).=

=C2=A0

What happens in that implementation, if the client h= as pipelined other requests that have a TB message produced with the first = EKM? Meaning the request is already in flight but not yet processed when th= e server initiates renegotiatio= n.



--94eb2c0361e2bfed12053f3e787d-- From nobody Wed Oct 19 19:42:23 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9845F129473 for ; Wed, 19 Oct 2016 19:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0npPDDitNb9m for ; Wed, 19 Oct 2016 19:42:20 -0700 (PDT) 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 36A961293E0 for ; Wed, 19 Oct 2016 19:42:20 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id n189so69281338qke.0 for ; Wed, 19 Oct 2016 19:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/oz3VZYmyXHyeV8Z3mwjeISW2W67xx3a/GsXMYqaDsw=; b=efUM4dszl1fEBgUQMQi4upjBsR24f7yGP5KbOf7benQZWFhWLYgGtC60T7Uyj4RVPS T72S2ZNVR49f2JTwAALW9p7xubZeeg+MO5oypZpc+g8//4myjTe/u/Hfp6leKYUxNUHY E5k6onYO5B9lKP+e37LlLok0Z4woppt2J/Eq1NjND3d3BlDEyI/DDQNj/L2Sz+S7mTUN 8TgjXr7pwsSwbIvVFE6Szk/htT6wYXQiwUpvpdfceu9xYT/LWVyB3sJwLDNGoM5oZggH 6PT/Y6qYhp3zHOIgZDqwIde+hYLCQz2N3M6vpqqIA0cMD9HHWmpt8+2IE/MUfgppT+4Y /SvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/oz3VZYmyXHyeV8Z3mwjeISW2W67xx3a/GsXMYqaDsw=; b=K1T5tgi4VnH7VmodDZydmKRY90XoHDxf0gHJt9Vfo99jE+mebXJEj+DhLwIx4QDJr0 uHp7c1+tFhNlqI8eU5vY8uZJaCy5lC+IauA3w6NP2AGk+rcgGF6dl2xyQi3Fn+JiC6UC fBQq97zyOY09D1zCEOaDl187xq/TfnbHgQJrINO6WwvFaUhZsw3xVm3hftNA/LIEteV6 bT+DLN2K6N9BzoJTjP71uXh3ibVtd9FMrQQrYVs+LnrZrR4x/PC7FzU+jHefid1v2Fzg +TXO8lySQiYe3GAiEoJGC7Yv1teGot2hECdN+zx+bIt+9Uq3RPAI5ybXM1jy7dzaDfmC 93GA== X-Gm-Message-State: AA6/9Rmv2+9wUDd4rKbGl+Iv0Md3MmMJ4IAmbep3h15A8WkzgrezbvIFWEVk8CGHHt27kRCFYBOS9sPTa1IYaQ== X-Received: by 10.55.99.17 with SMTP id x17mr8662626qkb.147.1476931339421; Wed, 19 Oct 2016 19:42:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 19 Oct 2016 19:42:18 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 20 Oct 2016 13:42:18 +1100 Message-ID: To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF Tokbind WG , Brian Campbell , "Dirk Balfanz \(balfanz@google.com\)" , Nick Harper Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 20 Oct 2016 02:42:21 -0000 On 20 October 2016 at 08:14, Andrei Popov wrot= e: > To elaborate a bit, in your specific example, if the TLS server is able t= o > decrypt the pipelined messages, then the server=E2=80=99s EKM is still th= e same one > the client used for the binding. And if the server is unable to decrypt t= he > messages, it does not matter that their binding is also invalid=E2=80=A6 Isn't it the case that until ChangeCipherSpec arrives, the old read (client write) keys are in place. However, the server might still have moved its master secret to the new keys. In that case, the client could be out of luck and those pipelined requests might fail. But if, like in NSS, your implementation is careful to maintain the old master secret and it knows how to look at the right one, then it might work. Of course, NSS looks at the server write keys so it would fail in this case. Of course, this is probably one of those corner cases that caused pipelining to be a widespread failure. From nobody Thu Oct 20 10:23:56 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856DC12964D for ; Thu, 20 Oct 2016 10:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3t4A0iMDJAZ for ; Thu, 20 Oct 2016 10:23:53 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0130.outbound.protection.outlook.com [104.47.36.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 41BCE1295B9 for ; Thu, 20 Oct 2016 10:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kM/NYwHPTOmRpQeOz2H2kfLYiL9rES+TpMDIvVzL5vc=; b=d9jYbSbnWB3xrh2Sm1T+L9Ry41XEiEr2Swnr3a2U+ssOPehG5xM0l9q5APhSui+wf8pwN16vzX4JDsU4voUlZrFiTLgu3phUFQ9wxJeKPl0DiqOA22h0AonzaraebGexYtfiNwxTx6QWHGLbnzYB6Nmkg1oZ495QznLZ4ZBAB3A= Received: from BY1PR0301MB0838.namprd03.prod.outlook.com (10.160.193.144) by BY1PR0301MB0838.namprd03.prod.outlook.com (10.160.193.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Thu, 20 Oct 2016 17:23:48 +0000 Received: from BY1PR0301MB0838.namprd03.prod.outlook.com ([10.160.193.144]) by BY1PR0301MB0838.namprd03.prod.outlook.com ([10.160.193.144]) with mapi id 15.01.0639.019; Thu, 20 Oct 2016 17:23:48 +0000 From: Andrei Popov To: Martin Thomson Thread-Topic: [Unbearable] Clarifying Token Binding behavior with renegotiation Thread-Index: AQHSKnuVOh5ujgkixk66hP2kv/P+JKCxkTcw Date: Thu, 20 Oct 2016 17:23:48 +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::1d2] x-ms-office365-filtering-correlation-id: 575cf5cf-5cd4-4031-82bb-08d3f90ddab8 x-microsoft-exchange-diagnostics: 1; BY1PR0301MB0838; 7:ZoBTI7MEVUlIZGc13O5Bzi40wI5+sjW/e4IWndb9RLo13VrpNeQMjpQMMJsgyjQrWsacDK1Gzk1JdH+dTjnpHhmnuzTxKFqBckC4OnKQINQaK8yjQd72RtNkJFe1294TZ370ZEvTJ45vf4/lkWEcnRyaSbv5HguuhKYeLdPsyReZEVufTgyDYYfVcYV15T9Hy7YHSdJyPgp+MokIPPU2twMDgJY8E6q4bw6YRG22TNC7YI1c1EyQ2/eycs8JS0GmiVAv5GOne1bM/92r9/o7hRmKLRabKIDeZ8m5Z5qQENxfPXzvbORwsopBVUi/FwiBXlPoEXcc4GtPVSRgDvQM33hXNs/w9xvVGS870WG6pvo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB0838; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY1PR0301MB0838; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB0838; x-forefront-prvs: 01018CB5B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(13464003)(24454002)(377454003)(199003)(86612001)(54356999)(11100500001)(6916009)(77096005)(105586002)(102836003)(8676002)(87936001)(92566002)(2950100002)(76576001)(110136003)(189998001)(10090500001)(19580405001)(9686002)(7696004)(2900100001)(19580395003)(3280700002)(33656002)(50986999)(122556002)(106116001)(106356001)(81156014)(4326007)(10400500002)(81166006)(5005710100001)(68736007)(586003)(7736002)(305945005)(8990500004)(93886004)(74316002)(3660700001)(8936002)(76176999)(5002640100001)(7846002)(86362001)(6116002)(101416001)(10290500002)(2906002)(5660300001)(97736004)(99286002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB0838; H:BY1PR0301MB0838.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: 20 Oct 2016 17:23:48.6600 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0301MB0838 Archived-At: Cc: IETF Tokbind WG , Brian Campbell , "Dirk Balfanz \(balfanz@google.com\)" , Nick Harper Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 20 Oct 2016 17:23:55 -0000 PiBJc24ndCBpdCB0aGUgY2FzZSB0aGF0IHVudGlsIENoYW5nZUNpcGhlclNwZWMgYXJyaXZlcywg dGhlIG9sZCByZWFkIChjbGllbnQgd3JpdGUpIGtleXMgYXJlIGluIHBsYWNlLg0KQ29ycmVjdCwg VExTIDEuMiBSRkMgc2F5czoNCiJJZiBhIHJlaGFuZHNoYWtlIG9jY3VycyB3aGlsZSBkYXRhIGlz IGZsb3dpbmcgb24gYSBjb25uZWN0aW9uLA0KICAgdGhlIGNvbW11bmljYXRpbmcgcGFydGllcyBt YXkgY29udGludWUgdG8gc2VuZCBkYXRhIHVzaW5nIHRoZSBvbGQNCiAgIENpcGhlclNwZWMuICBI b3dldmVyLCBvbmNlIHRoZSBDaGFuZ2VDaXBoZXJTcGVjIGhhcyBiZWVuIHNlbnQsIHRoZQ0KICAg bmV3IENpcGhlclNwZWMgTVVTVCBiZSB1c2VkLiAgVGhlIGZpcnN0IHNpZGUgdG8gc2VuZCB0aGUN CiAgIENoYW5nZUNpcGhlclNwZWMgZG9lcyBub3Qga25vdyB0aGF0IHRoZSBvdGhlciBzaWRlIGhh cyBmaW5pc2hlZA0KICAgY29tcHV0aW5nIHRoZSBuZXcga2V5aW5nIG1hdGVyaWFsIChlLmcuLCBp ZiBpdCBoYXMgdG8gcGVyZm9ybSBhDQogICB0aW1lLWNvbnN1bWluZyBwdWJsaWMga2V5IG9wZXJh dGlvbikuICBUaHVzLCBhIHNtYWxsIHdpbmRvdyBvZiB0aW1lLA0KICAgZHVyaW5nIHdoaWNoIHRo ZSByZWNpcGllbnQgbXVzdCBidWZmZXIgdGhlIGRhdGEsIE1BWSBleGlzdC4iDQoNCj4gSG93ZXZl ciwgdGhlIHNlcnZlciBtaWdodCBzdGlsbCBoYXZlIG1vdmVkIGl0cyBtYXN0ZXIgc2VjcmV0IHRv IHRoZSBuZXcga2V5cy4gIEluIHRoYXQgY2FzZSwgdGhlIGNsaWVudCBjb3VsZCBiZSBvdXQgb2Yg bHVjayBhbmQgdGhvc2UgcGlwZWxpbmVkIHJlcXVlc3RzIG1pZ2h0IGZhaWwuDQpUaGUgY2xpZW50 IHNlbmRzIGFwcGxpY2F0aW9uX2RhdGEgZWl0aGVyIGJlZm9yZSBvciBhZnRlciBDQ1MuIElmIHNl bnQgYmVmb3JlLCB0aGUgYmluZGluZyBpcyB0byB0aGUgb2xkIG1hc3RlciBzZWNyZXQuIElmIHNl bnQgYWZ0ZXIsIHRoZSBiaW5kaW5nIGlzIHRvIHRoZSBuZXcgbWFzdGVyIHNlY3JldC4NClRoZSBz ZXJ2ZXIgcmVjZWl2ZXMgYXBwbGljYXRpb25fZGF0YSBlaXRoZXIgYmVmb3JlIG9yIGFmdGVyIEND Uy4gSWYgcmVjZWl2ZWQgYmVmb3JlLCB0aGUgYmluZGluZyBpcyB0byB0aGUgb2xkIG1hc3RlciBz ZWNyZXQuIElmIHNlbnQgYWZ0ZXIsIHRoZSBiaW5kaW5nIGlzIHRvIHRoZSBuZXcgbWFzdGVyIHNl Y3JldC4NCg0KSW4gb3RoZXIgd29yZHMsIGlmIHRoZSBiaW5kaW5nIGlzIHRvIHRoZSBzYW1lIG1h c3RlciBzZWNyZXQgdGhhdCBwcm9kdWNlZCB0aGUga2V5IHdpdGggd2hpY2ggYXBwbGljYXRpb25f ZGF0YSBpcyBlbmNyeXB0ZWQsIHRoZW4gYm90aCBtZXNzYWdlIGRlY3J5cHRpb24gYW5kIFRCIHZl cmlmaWNhdGlvbiBzdWNjZWVkLg0KDQpJZiB0aGUgYmluZGluZyBpcyB0byBvbmUgbWFzdGVyIHNl Y3JldCwgYW5kIHRoZSBlbmNyeXB0aW9uIGtleSBpcyBhIHByb2R1Y3Qgb2YgYW5vdGhlciBtYXN0 ZXIgc2VjcmV0LCB0aGVuIGVpdGhlciBkZWNyeXB0aW9uIG9yIFRCIHZlcmlmaWNhdGlvbiB3aWxs IGZhaWwuIFRoaXMgbWlzbWF0Y2ggaXMgaW5kaWNhdGl2ZSBvZiBhbiBpbXBsZW1lbnRhdGlvbiBi dWcgb3IgYSB0b2tlbiByZXBsYXkgYXR0YWNrLg0KDQo+IEkgdGhpbmsgd2hhdCBCcmlhbiB3YXMg c2F5aW5nIGlzIHRoYXQgYSBjbGllbnQgc2VuZHMgbXVsdGlwbGUgSFRUUC8xLjEgcGlwZWxpbmVk IHJlcXVlc3RzIChlLmcuIEEgYW5kIEIpLCB3aXRoIEIgc2VudCBiZWZvcmUgd2FpdGluZyBvbiBh IHJlcGx5IGZvciBBIGZyb20gdGhlIHNlcnZlci4gV2hhdCBpZiByZXF1ZXN0IEEgaXMgdGhlIG9u ZSB0aGF0IHRyaWdnZXJzIHJlbmVnb3RpYXRpb24/IEEgdG9rZW4gYmluZGluZyBpbiBCIHdpbGwg c3RpbGwgc2lnbiB0aGUgc2FtZSBFS00gYXMgQS4gSG93IGRvZXMgdGhlIHNlcnZlciBoYW5kbGUg dGhlIHZhbGlkIHRva2VuIGJpbmRpbmcgaW4gcmVxdWVzdCBCPw0KVW5kZXJzdG9vZC4gDQpJbiB0 aGlzIGNhc2UsIHRoZSBzZXJ2ZXIgcmVjZWl2ZXMgcmVxdWVzdCBCIGJlZm9yZSBDQ1MsIHNvIGl0 IHdpbGwgc3VjY2Vzc2Z1bGx5IGRlY3J5cHQgdXNpbmcgb2xkIGtleXMsIGFuZCB0aGUgRUtNIGJh c2VkIG9uIHRoZSBvbGQgbWFzdGVyIHNlY3JldCB3aWxsIGJlIHVzZWQuIEl0IGlzIHRydWUgdGhh dCB0aGUgc2VydmVyIG1heSBoYXZlIGNhbGN1bGF0ZWQgdGhlIG5ldyBtYXN0ZXIgc2VjcmV0IGJl Zm9yZSByZWNlaXZpbmcgQ0NTLCBidXQgdGhlIG9sZCBtYXN0ZXIgc2VjcmV0IChvciB0aGUgb2xk IEVLTSkgaGFzIHRvIGJlIGtlcHQgYXJvdW5kIHVudGlsIENDUywganVzdCBsaWtlIHRoZSBvbGQg c2Vzc2lvbiBrZXlzIGhhdmUgdG8gYmUga2VwdCBhcm91bmQgdW50aWwgQ0NTLg0KDQpDaGVlcnMs DQoNCkFuZHJlaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFydGluIFRo b21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dIA0KU2VudDogV2VkbmVzZGF5 LCBPY3RvYmVyIDE5LCAyMDE2IDc6NDIgUE0NClRvOiBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3Bv dkBtaWNyb3NvZnQuY29tPg0KQ2M6IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbT47IERpcmsgQmFsZmFueiAoYmFsZmFuekBnb29nbGUuY29tKSA8YmFsZmFuekBnb29n bGUuY29tPjsgSUVURiBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPjsgTmljayBIYXJw ZXIgPG5oYXJwZXJAZ29vZ2xlLmNvbT4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gQ2xhcmlm eWluZyBUb2tlbiBCaW5kaW5nIGJlaGF2aW9yIHdpdGggcmVuZWdvdGlhdGlvbg0KDQpPbiAyMCBP Y3RvYmVyIDIwMTYgYXQgMDg6MTQsIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29m dC5jb20+IHdyb3RlOg0KPiBUbyBlbGFib3JhdGUgYSBiaXQsIGluIHlvdXIgc3BlY2lmaWMgZXhh bXBsZSwgaWYgdGhlIFRMUyBzZXJ2ZXIgaXMgDQo+IGFibGUgdG8gZGVjcnlwdCB0aGUgcGlwZWxp bmVkIG1lc3NhZ2VzLCB0aGVuIHRoZSBzZXJ2ZXLigJlzIEVLTSBpcyBzdGlsbCANCj4gdGhlIHNh bWUgb25lIHRoZSBjbGllbnQgdXNlZCBmb3IgdGhlIGJpbmRpbmcuIEFuZCBpZiB0aGUgc2VydmVy IGlzIA0KPiB1bmFibGUgdG8gZGVjcnlwdCB0aGUgbWVzc2FnZXMsIGl0IGRvZXMgbm90IG1hdHRl ciB0aGF0IHRoZWlyIGJpbmRpbmcgDQo+IGlzIGFsc28gaW52YWxpZOKApg0KDQoNCklzbid0IGl0 IHRoZSBjYXNlIHRoYXQgdW50aWwgQ2hhbmdlQ2lwaGVyU3BlYyBhcnJpdmVzLCB0aGUgb2xkIHJl YWQgKGNsaWVudCB3cml0ZSkga2V5cyBhcmUgaW4gcGxhY2UuICBIb3dldmVyLCB0aGUgc2VydmVy IG1pZ2h0IHN0aWxsIGhhdmUgbW92ZWQgaXRzIG1hc3RlciBzZWNyZXQgdG8gdGhlIG5ldyBrZXlz LiAgSW4gdGhhdCBjYXNlLCB0aGUgY2xpZW50IGNvdWxkIGJlIG91dCBvZiBsdWNrIGFuZCB0aG9z ZSBwaXBlbGluZWQgcmVxdWVzdHMgbWlnaHQgZmFpbC4NCkJ1dCBpZiwgbGlrZSBpbiBOU1MsIHlv dXIgaW1wbGVtZW50YXRpb24gaXMgY2FyZWZ1bCB0byBtYWludGFpbiB0aGUgb2xkIG1hc3RlciBz ZWNyZXQgYW5kIGl0IGtub3dzIGhvdyB0byBsb29rIGF0IHRoZSByaWdodCBvbmUsIHRoZW4gaXQg bWlnaHQgd29yay4gIE9mIGNvdXJzZSwgTlNTIGxvb2tzIGF0IHRoZSBzZXJ2ZXIgd3JpdGUga2V5 cyBzbyBpdCB3b3VsZCBmYWlsIGluIHRoaXMgY2FzZS4NCg0KT2YgY291cnNlLCB0aGlzIGlzIHBy b2JhYmx5IG9uZSBvZiB0aG9zZSBjb3JuZXIgY2FzZXMgdGhhdCBjYXVzZWQgcGlwZWxpbmluZyB0 byBiZSBhIHdpZGVzcHJlYWQgZmFpbHVyZS4NCg== From nobody Thu Oct 20 10:59:50 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8087B12958C for ; Thu, 20 Oct 2016 10:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 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.431, SPF_PASS=-0.001] autolearn=unavailable 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 47dX_iCCSOup for ; Thu, 20 Oct 2016 10:59:48 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d: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 4467E129694 for ; Thu, 20 Oct 2016 10:53:42 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id f128so103987792qkb.1 for ; Thu, 20 Oct 2016 10:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Zt2h1TWxyFQhbICevzA+szzLlqF98HVTaqET5wg9MPU=; b=R+qVu4oIQXoCBuUwVDn9tiQNfp8QNxBnnVfLsP5Xyyv67dK6tiunxVG/tghiagh23n 4p8+vJB7zZ2hEeF8EPpEwlJgFqrIuJyqua3rPj+Ut3fRFaphShH6Tof3aYIcUJXGJgrX wnQ65+UjwIYuBqBgO73abGJoz48bH50qIFhmZJf5Js/JqpcLHmeLz+yQ58brZ+kcNAVk R5gl+UWWNT07G8N2SoK8IF9bm2Op1FEUhVcLSIm3zu2zyP3VsaZMcjwXRNsjowXD5eKl vZxO/BoIyEfcilH/YW85V6V6PPPToetkXO2GxmhdDfmCjsTyPCqopwjM9Yv800kc4mPO k87Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Zt2h1TWxyFQhbICevzA+szzLlqF98HVTaqET5wg9MPU=; b=fAg/lPeSsdXfgyQrnBUxhO7ssEzLqD1jNvDYpxtMpJPJ2il7in+rlnKbl5lNenorki JFqstCxjNVJEQn6Wo+aTApIc04kDxYv9Vl67FnwPE/NjBolnZR9M3nVZ7J2r47Wetpdx pRioZgcVb4aotj0autDlsjEpuKkED1w92p1CvzOjprDN0qPiohJjoGwH0IvK4me13bVA e/d2bwePj3/uylEaw2YzzTBRApLk3dKxt3jnTJqYjoeHYuYGAMcl9uQnUIXBiRUqaVN0 ME485n0IodYbJ5WvGsrdSlYtO1GjmjbSYeSJysCE9RYs6AlOjYWss6HEeJk7HFwnkMl7 uRHg== X-Gm-Message-State: ABUngvcJE+2jeoJAjvrE+EIm1JieOpTzz39LuCU1/oRPY/v/Xe+uqo/vL47PKQPEhQN1RhnA5q3i9EY2WeC9N8o4 X-Received: by 10.55.215.6 with SMTP id m6mr1416010qki.244.1476986021275; Thu, 20 Oct 2016 10:53:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.169.94 with HTTP; Thu, 20 Oct 2016 10:53:20 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Thu, 20 Oct 2016 10:53:20 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a1149dcbc234bf4053f4f9bd4 Archived-At: Cc: "Dirk Balfanz \(balfanz@google.com\)" , IETF Tokbind WG , Brian Campbell , Martin Thomson Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 20 Oct 2016 17:59:49 -0000 --001a1149dcbc234bf4053f4f9bd4 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 20, 2016 at 10:23 AM, Andrei Popov wrote: > > > I think what Brian was saying is that a client sends multiple HTTP/1.1 > pipelined requests (e.g. A and B), with B sent before waiting on a reply > for A from the server. What if request A is the one that triggers > renegotiation? A token binding in B will still sign the same EKM as A. How > does the server handle the valid token binding in request B? > Understood. > In this case, the server receives request B before CCS, so it will > successfully decrypt using old keys, and the EKM based on the old master > secret will be used. It is true that the server may have calculated the new > master secret before receiving CCS, but the old master secret (or the old > EKM) has to be kept around until CCS, just like the old session keys have > to be kept around until CCS. > > The server needs to keep the old EKM around until it receives CCS. But, the server could also send a Token-Bound message to the client after the server sends CCS/Finished (and before receiving the client's CCS), so the server has a period of time where it needs to keep track of 2 EKMs. If limited to specific application protocols, I don't think that using the latest EKM is intractable, but I think it is much more complicated both in the spec and in implementation. The above example, with what Andrei proposes, requires the server to keep track of multiple EKMs at the same time, and have logic in place to update the cached EKMs at the appropriate time in the renegotiation. My proposal is simpler to implement - the client or server computes the EKM after the connection's initial handshake completes, and then doesn't have to worry about any of this for the rest of the connection. --001a1149dcbc234bf4053f4f9bd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 20, 2016 at 10:23 AM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

> I think what Brian was saying is that a client sends multiple HTTP/1.1= pipelined requests (e.g. A and B), with B sent before waiting on a reply f= or A from the server. What if request A is the one that triggers renegotiat= ion? A token binding in B will still sign the same EKM as A. How does the s= erver handle the valid token binding in request B?
Understood.
In this case, the server receives request B before CCS, so it will successf= ully decrypt using old keys, and the EKM based on the old master secret wil= l be used. It is true that the server may have calculated the new master se= cret before receiving CCS, but the old master secret (or the old EKM) has t= o be kept around until CCS, just like the old session keys have to be kept = around until CCS.

The server needs to keep the old EKM around until it receives CCS. But, th= e server could also send a Token-Bound message to the client after the serv= er sends CCS/Finished (and before receiving the client's CCS), so the s= erver has a period of time where it needs to keep track of 2 EKMs.

If limited to specific application protocols, I don't = think that using the latest EKM is intractable, but I think it is much more= complicated both in the spec and in implementation. The above example, wit= h what Andrei proposes, requires the server to keep track of multiple EKMs = at the same time, and have logic in place to update the cached EKMs at the = appropriate time in the renegotiation. My proposal is simpler to implement = - the client or server computes the EKM after the connection's initial = handshake completes, and then doesn't have to worry about any of this f= or the rest of the connection.
--001a1149dcbc234bf4053f4f9bd4-- From nobody Thu Oct 20 11:09:43 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897A2129670 for ; Thu, 20 Oct 2016 11:09:41 -0700 (PDT) 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 zKoUym_DII5z for ; Thu, 20 Oct 2016 11:09:39 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0118.outbound.protection.outlook.com [104.47.34.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 A158F12969C for ; Thu, 20 Oct 2016 11:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Le+iTWB9YbRTg96HCBonGq6o7Aakir6+4sG59R8ZjHI=; b=n8n+KSf9kItv4bxBqSZzWossk+t58QjKox/DoaJdYVIlARDVgCpYRQlTgamjtxckGbUI42PoseGK0FsUuqXd1y39SxJsx4bwf+EzU4mEw7QoQknH1LeaoZxXjkCxmV4x1alkAN4UEzWL0lAHFBEyLAKUVVOacuxXjpiddJ5eoZk= Received: from BY1PR0301MB0838.namprd03.prod.outlook.com (10.160.193.144) by BY1PR0301MB0837.namprd03.prod.outlook.com (10.160.193.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Thu, 20 Oct 2016 18:09:36 +0000 Received: from BY1PR0301MB0838.namprd03.prod.outlook.com ([10.160.193.144]) by BY1PR0301MB0838.namprd03.prod.outlook.com ([10.160.193.144]) with mapi id 15.01.0639.019; Thu, 20 Oct 2016 18:09:36 +0000 From: Andrei Popov To: Nick Harper Thread-Topic: [Unbearable] Clarifying Token Binding behavior with renegotiation Thread-Index: AQHSKnuVOh5ujgkixk66hP2kv/P+JKCxkTcwgAAPgQCAAACO4A== Date: Thu, 20 Oct 2016 18:09:36 +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::1d2] x-ms-office365-filtering-correlation-id: de572a72-b5af-43e2-29b4-08d3f9144077 x-microsoft-exchange-diagnostics: 1; BY1PR0301MB0837; 7:iBvox22hyJk2lz76twH+oiXZAfSCon3EJODE6QqcSeY4+zskCvD7rSFVByCjSKGtxQegn+rZOvtSsqWh9ylxm9RGRFzTK4lGPH5hya0gttm83+QAh3q7URLIaWFB20ilPZ9Wy2TAUVviOv+Hs5rp1aoUmlj+GcIwqdeBwBzaFSu+auVYp4Dy7BNRE5TGG5oqAIWVzU/qjSpJfUr11ExUWKdrXQDQ+7aX0we9+XSFnT6h9rurFdpuDAF94af35tn1/++TDAmoTLekwK2JYzzs022m+i0lmg4CDgLdjmHGS7+VKNcKetIq1M9IaTwnRPCMTiY85zvScGQZDxDglOasQbH6VEzBmhtMglL5av7zwA8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB0837; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060202)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY1PR0301MB0837; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB0837; x-forefront-prvs: 01018CB5B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(101416001)(122556002)(6916009)(561944003)(2950100002)(106116001)(19580395003)(33656002)(99286002)(4326007)(8936002)(106356001)(5660300001)(105586002)(8990500004)(10090500001)(86612001)(10290500002)(189998001)(5005710100001)(16236675004)(2906002)(10400500002)(7696004)(102836003)(68736007)(8676002)(86362001)(19300405004)(93886004)(9686002)(81166006)(3660700001)(586003)(81156014)(50986999)(76176999)(87936001)(15975445007)(7846002)(54356999)(110136003)(5002640100001)(19625215002)(74316002)(6116002)(7736002)(97736004)(76576001)(790700001)(92566002)(11100500001)(77096005)(3280700002)(2900100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB0837; H:BY1PR0301MB0838.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_BY1PR0301MB083883B4191238E44332562C8CD50BY1PR0301MB0838_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2016 18:09:36.3085 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0301MB0837 Archived-At: Cc: "Dirk Balfanz \(balfanz@google.com\)" , IETF Tokbind WG , Brian Campbell , Martin Thomson Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 20 Oct 2016 18:09:41 -0000 --_000_BY1PR0301MB083883B4191238E44332562C8CD50BY1PR0301MB0838_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggICBJZiBsaW1pdGVkIHRvIHNwZWNpZmljIGFwcGxpY2F0aW9uIHByb3RvY29scywgSSBkb24n dCB0aGluayB0aGF0IHVzaW5nIHRoZSBsYXRlc3QgRUtNIGlzIGludHJhY3RhYmxlLCAuLi4NCk5v dyB0aGF0IHdlIGFncmVlIHRoaXMgY2FuIGJlIGRvbmUsIHdl4oCZcmUgYmFjayB0byB0aGUgY29y ZSBvZiB0aGUgaXNzdWU6IHdoZXRoZXIgaXQgaXMgdXNlZnVsIHRvIHByb3ZlIHBvc3Nlc3Npb24g b2YgdGhlIFRCIGtleSBhZnRlciByZW5lZ290aWF0aW5nIG9uIHRoZSBzYW1lIGNvbm5lY3Rpb24u IFRoaXMgaXMgd2hlcmUgTmljayBhbmQgSSBkaWZmZXIuDQoNCg0Kw5ggIOKApmJ1dCBJIHRoaW5r IGl0IGlzIG11Y2ggbW9yZSBjb21wbGljYXRlZCBib3RoIGluIHRoZSBzcGVjIGFuZCBpbiBpbXBs ZW1lbnRhdGlvbi4gVGhlIGFib3ZlIGV4YW1wbGUsIHdpdGggd2hhdCBBbmRyZWkgcHJvcG9zZXMs IHJlcXVpcmVzIHRoZSBzZXJ2ZXIgdG8ga2VlcCB0cmFjayBvZiBtdWx0aXBsZSBFS01zIGF0IHRo ZSBzYW1lIHRpbWUsIGFuZCBoYXZlIGxvZ2ljIGluIHBsYWNlIHRvIHVwZGF0ZSB0aGUgY2FjaGVk IEVLTXMgYXQgdGhlIGFwcHJvcHJpYXRlIHRpbWUgaW4gdGhlIHJlbmVnb3RpYXRpb24uDQpUaGlz IHRyYWNraW5nIGxvZ2ljIGFscmVhZHkgZXhpc3RzIGZvciByZWFkL3dyaXRlIGtleXMgaW4gYWxs IFRMUyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBzdXBwb3J0IHJlbmVnb3RpYXRpb24uIFRoZSBvbmx5 IGNoYW5nZSBpcyB0byBhZGQgRUtNIHRvIHRoZSBzdGF0ZS4gQW5kIGl0IGlzIG9uZSBwcmV2aW91 cyBFS00sIG5vdCBtdWx0aXBsZSBFS01zLCBhbmQgb25seSB0byBiZSBjYWNoZWQgYWxvbmdzaWRl IHJlYWQvd3JpdGUga2V5cyB1bnRpbCBDU1MgaXMgcmVjZWl2ZWQgKGVzc2VudGlhbGx5LCB3aGls ZSB0aGUgaGFuZHNoYWtlIGlzIG9uLWdvaW5nKS4NCg0KDQrDmCAgTXkgcHJvcG9zYWwgaXMgc2lt cGxlciB0byBpbXBsZW1lbnQgLSB0aGUgY2xpZW50IG9yIHNlcnZlciBjb21wdXRlcyB0aGUgRUtN IGFmdGVyIHRoZSBjb25uZWN0aW9uJ3MgaW5pdGlhbCBoYW5kc2hha2UgY29tcGxldGVzLCBhbmQg dGhlbiBkb2Vzbid0IGhhdmUgdG8gd29ycnkgYWJvdXQgYW55IG9mIHRoaXMgZm9yIHRoZSByZXN0 IG9mIHRoZSBjb25uZWN0aW9uLg0KTmlja+KAmXMgcHJvcG9zYWwgcmVxdWlyZXMgdGhhdCBhbiBp bXBsZW1lbnRhdGlvbiB0cmFja3MgY29ubmVjdGlvbiBzdGF0dXMgYW5kIHN0b3JlcyB0aGUgZmly c3QgRUtNIG9mIHRoZSBjb25uZWN0aW9uIGZvciB0aGUgZHVyYXRpb24gb2YgdGhlIGNvbm5lY3Rp b24sIGFuZCB0aGVuIGtub3dzIHRvIHVzZSB0aGUgc3RhbGUgRUtNIGZvciBUb2tlbiBCaW5kaW5n LCBidXQgKGhvcGVmdWxseSkgdGhlIGN1cnJlbnQgRUtNIGZvciBldmVyeXRoaW5nIGVsc2XigKYN CkZyb20gdGhlIFRMUyBwZXJzcGVjdGl2ZSwgSSBkb27igJl0IHRoaW5rIGl0IGlzIGEgZ29vZCBp ZGVhIHRvIGludHJvZHVjZSBhIGNvbmNlcHQgb2Ygc3RhbGUgRUtNLg0K --_000_BY1PR0301MB083883B4191238E44332562C8CD50BY1PR0301MB0838_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaW0NCgl7bXNvLXN0eWxlLW5hbWU6aW07fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6MTE1OTAzMDY3OTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6MTA0MTEwNTgzNCAtMTA5MzM3MDc1NiA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1s aXN0LWlkOjE5MTkzNjMxNTY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi0xNzAzOTE3ODA0IDM2MDg2Njg0OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBs MTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxp YnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwx OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+SWYgbGltaXRlZCB0byBzcGVjaWZpYyBhcHBsaWNhdGlv biBwcm90b2NvbHMsIEkgZG9uJ3QgdGhpbmsgdGhhdCB1c2luZyB0aGUgbGF0ZXN0IEVLTSBpcyBp bnRyYWN0YWJsZSwgLi4uPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk5vdyB0aGF0IHdlIGFncmVlIHRo aXMgY2FuIGJlIGRvbmUsIHdl4oCZcmUgYmFjayB0byB0aGUgY29yZSBvZiB0aGUgaXNzdWU6IHdo ZXRoZXIgaXQgaXMgdXNlZnVsIHRvIHByb3ZlIHBvc3Nlc3Npb24gb2YgdGhlIFRCIGtleSBhZnRl ciByZW5lZ290aWF0aW5nIG9uIHRoZSBzYW1lIGNvbm5lY3Rpb24uDQogVGhpcyBpcyB3aGVyZSBO aWNrIGFuZCBJIGRpZmZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwxIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT7igKZidXQgSSB0aGlu ayBpdCBpcyBtdWNoIG1vcmUgY29tcGxpY2F0ZWQgYm90aCBpbiB0aGUgc3BlYyBhbmQgaW4gaW1w bGVtZW50YXRpb24uIFRoZSBhYm92ZSBleGFtcGxlLCB3aXRoIHdoYXQgQW5kcmVpIHByb3Bvc2Vz LCByZXF1aXJlcyB0aGUgc2VydmVyIHRvIGtlZXAgdHJhY2sgb2YgbXVsdGlwbGUgRUtNcyBhdCB0 aGUgc2FtZSB0aW1lLCBhbmQgaGF2ZSBsb2dpYyBpbiBwbGFjZSB0byB1cGRhdGUNCiB0aGUgY2Fj aGVkIEVLTXMgYXQgdGhlIGFwcHJvcHJpYXRlIHRpbWUgaW4gdGhlIHJlbmVnb3RpYXRpb24uPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgdHJhY2tpbmcgbG9naWMgYWxyZWFkeSBleGlzdHMgZm9y IHJlYWQvd3JpdGUga2V5cyBpbiBhbGwgVExTIGltcGxlbWVudGF0aW9ucyB0aGF0IHN1cHBvcnQg cmVuZWdvdGlhdGlvbi4gVGhlIG9ubHkgY2hhbmdlIGlzIHRvIGFkZCBFS00gdG8gdGhlIHN0YXRl LiBBbmQgaXQgaXMgb25lIHByZXZpb3VzDQogRUtNLCBub3QgbXVsdGlwbGUgRUtNcywgYW5kIG9u bHkgdG8gYmUgY2FjaGVkIGFsb25nc2lkZSByZWFkL3dyaXRlIGtleXMgdW50aWwgQ1NTIGlzIHJl Y2VpdmVkIChlc3NlbnRpYWxseSwgd2hpbGUgdGhlIGhhbmRzaGFrZSBpcyBvbi1nb2luZykuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+PCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+TXkgcHJvcG9zYWwgaXMgc2ltcGxlciB0byBpbXBsZW1l bnQgLSB0aGUgY2xpZW50IG9yIHNlcnZlciBjb21wdXRlcyB0aGUgRUtNIGFmdGVyIHRoZSBjb25u ZWN0aW9uJ3MgaW5pdGlhbCBoYW5kc2hha2UgY29tcGxldGVzLCBhbmQgdGhlbiBkb2Vzbid0IGhh dmUgdG8gd29ycnkgYWJvdXQgYW55IG9mIHRoaXMgZm9yIHRoZSByZXN0IG9mIHRoZSBjb25uZWN0 aW9uLjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5OaWNr4oCZcyBwcm9wb3NhbCByZXF1aXJlcyB0aGF0 IGFuIGltcGxlbWVudGF0aW9uIHRyYWNrcyBjb25uZWN0aW9uIHN0YXR1cyBhbmQgc3RvcmVzIHRo ZSBmaXJzdCBFS00gb2YgdGhlIGNvbm5lY3Rpb24gZm9yIHRoZSBkdXJhdGlvbiBvZiB0aGUgY29u bmVjdGlvbiwgYW5kIHRoZW4ga25vd3MgdG8gdXNlDQogdGhlIHN0YWxlIEVLTSBmb3IgVG9rZW4g QmluZGluZywgYnV0IChob3BlZnVsbHkpIHRoZSBjdXJyZW50IEVLTSBmb3IgZXZlcnl0aGluZyBl bHNl4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tIHRoZSBUTFMgcGVyc3BlY3RpdmUsIEkgZG9u4oCZdCB0aGluayBpdCBp cyBhIGdvb2QgaWRlYSB0byBpbnRyb2R1Y2UgYSBjb25jZXB0IG9mIHN0YWxlIEVLTS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY1PR0301MB083883B4191238E44332562C8CD50BY1PR0301MB0838_-- From nobody Thu Oct 20 11:48:26 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F01A129584 for ; Thu, 20 Oct 2016 11:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 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.431, 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 v37gIOfJQMXf for ; Thu, 20 Oct 2016 11:48:22 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d: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 6AE1B12948F for ; Thu, 20 Oct 2016 11:48:22 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id z190so111325997qkc.2 for ; Thu, 20 Oct 2016 11:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RETA2jEVTLiBdocXdtiO2G7QvJiVieW9mAshMpmkE94=; b=h5S2QneVQgvN2TFXEjBkwvmLGBLlq0Qw+35O8zStxLkwpQ6IQcxvkK8omZfo7IclL2 ydfkQQyHHLmJP9UfQt301AHjTY81lE01HysoIZO4M37tv4sGNTE/mvv4qV3aZ8t9QZws 53rJ+KE8kk8WSO2Ds5BwchBukNBoq/zPbngx0S57uCasK2eshErD0cq5XsxpQ4bXIKoD jd8prHFBlc10HYBsAZp1SmwJl0W2CCfr6i7vL7heO5p1UpuFhyhFG8n01oPHvdz2cbnx VuYlQda7X0dZ2wtAo2snW/vq0UZvF6/6+1TEeRTl/ZLRbaAd8sYkZNzB/Dy//MRYV7Ls K4eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RETA2jEVTLiBdocXdtiO2G7QvJiVieW9mAshMpmkE94=; b=TuzGI/DuyPXFlMAnsPh9ux80vE9qAFnnzKDXhHvJGdHS8ZVVz4/2BMM9c0OtuWbikq 4nz2lYjR8lyAthmRRzAo/iOOQf+bYxaSqaQ20IRrbW3aeGkV1aZEqMekVY//tOOIbTgT Xcv1XIv3wPhnRbYylmz1zRuiO+gwvnNsU6VsK1fIW48W0LuZ1w7qHSSZBpdibZyeAcx3 pF3u/FQF4onpBGPT3/j7jf5lx/TD5ItCIJ1fAkQfVpDIThaUTykPCL3qTP8DTNDHfezl zGbA9gUr+YgaF6eoGPWgPaU8H0EtB/AXbrlSqjhjrVC5l/Gs28LVuJ7DLPHFOk8DPNdS Dufg== X-Gm-Message-State: ABUngvfiXrAU8nvXhy5yhrgU/7f2ai8HND8h5HX4DEfjB4dwMQ8nAtB97HKv+v1lWjVbzjKUbAoImRV3wWeHOH2N X-Received: by 10.55.215.6 with SMTP id m6mr1661566qki.244.1476989301163; Thu, 20 Oct 2016 11:48:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.169.94 with HTTP; Thu, 20 Oct 2016 11:48:00 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Thu, 20 Oct 2016 11:48:00 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a1149dcbca26f89053f505ee2 Archived-At: Cc: "Dirk Balfanz \(balfanz@google.com\)" , IETF Tokbind WG , Brian Campbell , Martin Thomson Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 20 Oct 2016 18:48:25 -0000 --001a1149dcbca26f89053f505ee2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 20, 2016 at 11:09 AM, Andrei Popov wrote: > =C3=98 If limited to specific application protocols, I don't think that > using the latest EKM is intractable, ... > > Now that we agree this can be done, we=E2=80=99re back to the core of the= issue: > whether it is useful to prove possession of the TB key after renegotiatin= g > on the same connection. This is where Nick and I differ. > If proving possession of the TB key after renegotiation is that important, why not bind your tokens to the client certificate presented in renegotiation (instead of the token binding keys)? Then we could forbid renegotiation with Token Binding and this whole problem goes away. > > > =C3=98 =E2=80=A6but I think it is much more complicated both in the spec= and in > implementation. The above example, with what Andrei proposes, requires th= e > server to keep track of multiple EKMs at the same time, and have logic in > place to update the cached EKMs at the appropriate time in the > renegotiation. > > This tracking logic already exists for read/write keys in all TLS > implementations that support renegotiation. The only change is to add EKM > to the state. And it is one previous EKM, not multiple EKMs, and only to = be > cached alongside read/write keys until CSS is received (essentially, whil= e > the handshake is on-going). > This is assuming that the TLS stack is caching the EKM. BoringSSL/OpenSSL and NSS provide a function that calculates the EKM based on the current connection state, so a Token Binding implementation using one of those TLS stacks would have to duplicate that logic. A Token Binding implementation using one of those stacks is most likely going to implement its own cache of the EKM, and caching a single value is easier than invalidating and caching multiple values. > > > =C3=98 My proposal is simpler to implement - the client or server comput= es > the EKM after the connection's initial handshake completes, and then > doesn't have to worry about any of this for the rest of the connection. > > Nick=E2=80=99s proposal requires that an implementation tracks connection= status > and stores the first EKM of the connection for the duration of the > connection, and then knows to use the stale EKM for Token Binding, but > (hopefully) the current EKM for everything else=E2=80=A6 > > From the TLS perspective, I don=E2=80=99t think it is a good idea to intr= oduce a > concept of stale EKM. > The Token Binding implementation would store that EKM, not the TLS stack (see above about the TLS stack only knowing how to compute an EKM based on the current connection state). This doesn't affect other users of the EKM. --001a1149dcbca26f89053f505ee2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 20, 2016 at 11:09 AM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

=C3=98=C2=A0 =C2=A0If limited to specific applicatio= n protocols, I don't think that using the latest EKM is intractable, ..= .

Now that we agree this can be done, we=E2=80=99re b= ack to the core of the issue: whether it is useful to prove possession of t= he TB key after renegotiating on the same connection. This is where Nick and I differ.

<= br>
If proving possession of the TB key after renegotiation is th= at important, why not bind your tokens to the client certificate presented = in renegotiation (instead of the token binding keys)? Then we could forbid = renegotiation with Token Binding and this whole problem goes away.

=C2=A0

=C3=98=C2=A0 =E2=80=A6but I think it is much more complicate= d both in the spec and in implementation. The above example, with what Andr= ei proposes, requires the server to keep track of multiple EKMs at the same= time, and have logic in place to update the cached EKMs at the appropriate time in the renegotiation.=

This tracking logic already exists for read/write k= eys in all TLS implementations that support renegotiation. The only change = is to add EKM to the state. And it is one previous EKM, not multiple EKMs, and only to be cached alongside read/write keys un= til CSS is received (essentially, while the handshake is on-going).<= /p>


This is assuming that the T= LS stack is caching the EKM. BoringSSL/OpenSSL and NSS provide a function t= hat calculates the EKM based on the current connection state, so a Token Bi= nding implementation using one of those TLS stacks would have to duplicate = that logic. A Token Binding implementation using one of those stacks is mos= t likely going to implement its own cache of the EKM, and caching a single = value is easier than invalidating and caching multiple values.
=

=C2=A0

=C3=98=C2=A0 My proposal is simpler to implement - the clien= t or server computes the EKM after the connection's initial handshake c= ompletes, and then doesn't have to worry about any of this for the rest= of the connection.

Nick=E2=80=99s proposal requires that an implementa= tion tracks connection status and stores the first EKM of the connection fo= r the duration of the connection, and then knows to use the stale EKM for Token Binding, but (hopefully) the current EKM for every= thing else=E2=80=A6

From the TLS perspective, I don=E2=80=99t think it = is a good idea to introduce a concept of stale EKM.

<= /blockquote>

The Token Binding implementation would stor= e that EKM, not the TLS stack (see above about the TLS stack only knowing h= ow to compute an EKM based on the current connection state). This doesn'= ;t affect other users of the EKM.

--001a1149dcbca26f89053f505ee2-- From nobody Thu Oct 20 12:16:45 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333181296B9 for ; Thu, 20 Oct 2016 12:16:44 -0700 (PDT) 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 GcxaEzkPXVDB for ; Thu, 20 Oct 2016 12:16:42 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0110.outbound.protection.outlook.com [104.47.41.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24CA61296A1 for ; Thu, 20 Oct 2016 12:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mLtQym6nAcaXxHrAmBqVZFmx7DdWGwTe4MjRbSYg0Q0=; b=lMhL3atAF6bE8Fn+ZRVuShWmj+N0MNhfCQhrMk7mF/6FcFiJXbqvvxunHFJ9v9d0hdABhDhFSbJTMOh2iE5HIy/BRNIgpynrBXxJri8E/6nXQzyhhirXfnch84Ucv9b23bRMOXiGnxfq9B9dQG/DdJgmrWuJU8ND7QBOetkj88o= Received: from BY1PR0301MB0838.namprd03.prod.outlook.com (10.160.193.144) by BY1PR0301MB0838.namprd03.prod.outlook.com (10.160.193.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Thu, 20 Oct 2016 19:16:39 +0000 Received: from BY1PR0301MB0838.namprd03.prod.outlook.com ([10.160.193.144]) by BY1PR0301MB0838.namprd03.prod.outlook.com ([10.160.193.144]) with mapi id 15.01.0639.019; Thu, 20 Oct 2016 19:16:39 +0000 From: Andrei Popov To: Nick Harper Thread-Topic: [Unbearable] Clarifying Token Binding behavior with renegotiation Thread-Index: AQHSKnuVOh5ujgkixk66hP2kv/P+JKCxkTcwgAAPgQCAAACO4IAADrgAgAAARtA= Date: Thu, 20 Oct 2016 19:16:39 +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::1d2] x-ms-office365-filtering-correlation-id: 2ac3f3a4-8c3d-47a4-7412-08d3f91d9e9e x-microsoft-exchange-diagnostics: 1; BY1PR0301MB0838; 7:VLf5gznTl60yxEUOyCwuK1nxaNj+eDijSSBIrT9YhdFaoi1H8t/4T+PbCFTcurFWJp2EVu1bXCj6+Wpz2qcHw81mYq3O8Tj9TngOeN6K9qa+mrmVio8IPx5GzqOjzaJzIbbo7DMErl5l01voiSe16vymBOgL19YzvavrWKUT9ZI+febZbGgEyT259TeoMrvMBx0YGZ49g9jsiF/ObpMf4iwAFt35zDLqzqm0Ezs6ayAClvwU1XKbHOBB2PQ9pyJyvJ6TfyWUuWM5gjWy51E9lQI+vbffNOYVNRGXqzpA4qYz7cMZ1ZpyJe0MLPnhEFCCnqDC8GevW10uSJ4x/bLLtHkf5iC3fZ5v7ub/WvmOE/g= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB0838; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY1PR0301MB0838; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB0838; x-forefront-prvs: 01018CB5B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(586003)(7736002)(68736007)(5005710100001)(3660700001)(8936002)(76176999)(5002640100001)(93886004)(74316002)(8990500004)(106356001)(106116001)(122556002)(50986999)(81166006)(10400500002)(4326007)(81156014)(5660300001)(10290500002)(101416001)(2906002)(99286002)(97736004)(16236675004)(19625215002)(790700001)(86362001)(6116002)(7846002)(8676002)(102836003)(2950100002)(92566002)(87936001)(105586002)(189998001)(110136003)(76576001)(19300405004)(86612001)(54356999)(77096005)(6916009)(11100500001)(15975445007)(33656002)(9686002)(7696004)(10090500001)(19580395003)(3280700002)(2900100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB0838; H:BY1PR0301MB0838.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_BY1PR0301MB0838D275FB7FA966F1CAA67A8CD50BY1PR0301MB0838_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2016 19:16:39.8361 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0301MB0838 Archived-At: Cc: "Dirk Balfanz \(balfanz@google.com\)" , IETF Tokbind WG , Brian Campbell , Martin Thomson Subject: Re: [Unbearable] Clarifying Token Binding behavior with renegotiation 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, 20 Oct 2016 19:16:44 -0000 --_000_BY1PR0301MB0838D275FB7FA966F1CAA67A8CD50BY1PR0301MB0838_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIElmIHByb3ZpbmcgcG9zc2Vzc2lvbiBvZiB0aGUgVEIga2V5IGFmdGVyIHJlbmVnb3RpYXRp b24gaXMgdGhhdCBpbXBvcnRhbnQsIHdoeSBub3QgYmluZCB5b3VyIHRva2VucyB0byB0aGUgY2xp ZW50IGNlcnRpZmljYXRlIHByZXNlbnRlZCBpbiByZW5lZ290aWF0aW9uIChpbnN0ZWFkIG9mIHRo ZSB0b2tlbiBiaW5kaW5nIGtleXMpPyBUaGVuIHdlIGNvdWxkIGZvcmJpZCByZW5lZ290aWF0aW9u IHdpdGggVG9rZW4gQmluZGluZyBhbmQgdGhpcyB3aG9sZSBwcm9ibGVtIGdvZXMgYXdheS4NCkJl Y2F1c2UgaXQgc2VlbXMgbW9yZSBzaW1wbGUvbGVzcyBlcnJvci1wcm9uZSB0byB1c2Ugb25lIHR5 cGUgb2YgdG9rZW4gYmluZGluZyByZWdhcmRsZXNzIG9mIHRoZSBjbGllbnQgYXV0aGVudGljYXRp b24gbWVjaGFuaXNtLg0K --_000_BY1PR0301MB0838D275FB7FA966F1CAA67A8CD50BY1PR0301MB0838_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubTMwMzY3MDMyMDE1Mjc3MzA3MTJtc29saXN0cGFyYWdy YXBoLCBsaS5tMzAzNjcwMzIwMTUyNzczMDcxMm1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tMzAzNjcw MzIwMTUyNzczMDcxMm1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV8zMDM2NzAz MjAxNTI3NzMwNzEybXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9z ZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTI3OTI1NDg7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIwNDUzMjQzMiAtMTIwNjMyMjUzMCA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFz dC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPklmIHBy b3ZpbmcgcG9zc2Vzc2lvbiBvZiB0aGUgVEIga2V5IGFmdGVyIHJlbmVnb3RpYXRpb24gaXMgdGhh dCBpbXBvcnRhbnQsIHdoeSBub3QgYmluZCB5b3VyIHRva2VucyB0byB0aGUgY2xpZW50IGNlcnRp ZmljYXRlIHByZXNlbnRlZCBpbiByZW5lZ290aWF0aW9uIChpbnN0ZWFkIG9mIHRoZSB0b2tlbiBi aW5kaW5nIGtleXMpPyBUaGVuIHdlIGNvdWxkIGZvcmJpZCByZW5lZ290aWF0aW9uIHdpdGgNCiBU b2tlbiBCaW5kaW5nIGFuZCB0aGlzIHdob2xlIHByb2JsZW0gZ29lcyBhd2F5LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5CZWNhdXNlIGl0IHNl ZW1zIG1vcmUgc2ltcGxlL2xlc3MgZXJyb3ItcHJvbmUgdG8gdXNlIG9uZSB0eXBlIG9mIHRva2Vu IGJpbmRpbmcgcmVnYXJkbGVzcyBvZiB0aGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlz bS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY1PR0301MB0838D275FB7FA966F1CAA67A8CD50BY1PR0301MB0838_-- From nobody Fri Oct 21 16:29:59 2016 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 D39DE1299AD; Fri, 21 Oct 2016 16:21:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709208486.28214.18174042310284260669.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:24 -0700 Archived-At: Cc: unbearable@ietf.org, stephen.farrell@cs.tcd.ie Subject: [Unbearable] tokbind - Requested session has been scheduled for IETF 97 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, 21 Oct 2016 23:21:26 -0000 Dear Leif Johansson, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tokbind Session 1 (2:00:00) Monday, Afternoon Session II 1550-1750 Room Name: Studio 4 size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Token Binding Area Name: Security Area Session Requester: Leif Johansson Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: ace tls oauth Special Requests: Key contributors are unable to attend on Friday. Please if possible avoid Friday scheduling. ---------------------------------------------------------