From nobody Sat Jul 1 09:53:27 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A671296CF; Sat, 1 Jul 2017 09:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 ia4noafoN33U; Sat, 1 Jul 2017 09:53:25 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 AD7EF128896; Sat, 1 Jul 2017 09:53:24 -0700 (PDT) X-AuditID: 1209190d-2cfff7000000040f-63-5957d3834a5f Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 6E.E7.01039.383D7595; Sat, 1 Jul 2017 12:53:23 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v61GrM7h018326; Sat, 1 Jul 2017 12:53:22 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v61GrHxS008113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 1 Jul 2017 12:53:20 -0400 Date: Sat, 1 Jul 2017 11:53:17 -0500 From: Benjamin Kaduk To: Nick Harper Cc: John Bradley , IETF Tokbind WG , Leif Johansson , "tokbind-chairs@ietf.org" Message-ID: <20170701165317.GT68391@kduck.kaduk.org> References: <149868793805.5443.4284920405751222901@ietfa.amsl.com> <20170629024818.GI68391@kduck.kaduk.org> <9057a735-a907-d06c-327b-a959e4f554f0@sunet.se> <97A1224B-5B6C-41EC-9FE0-CA0DE53746E1@ve7jtb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IRYrdT0W2+HB5pMPGVusWC3q3MFv079jFa LJ8/n83i3OOFTBar7/5lc2D1WLCp1GPJkp9MHns39bF73L69kSWAJYrLJiU1J7MstUjfLoEr 49aaN2wFN3kqHu5Yz9TA2MvVxcjJISFgIjHp43OWLkYuDiGBxUwS5xYsYINwNjBKzF73lgnC ucIkcfX8Y1aQFhYBFYkDbxcxg9hsQHZD92UwWwTInn/1OitIA7PAZkaJU/NegDUIC3hJzFj0 hAXE5gXad+X+b6ipW5glJpy8AZUQlDg5E6KIWUBL4sa/l0BFHEC2tMTyfxwgYU6BWIl/Wzew gdiiAsoSfw/fY5nAKDALSfcsJN2zELoXMDKvYpRNya3SzU3MzClOTdYtTk7My0st0jXSy80s 0UtNKd3ECAptTkneHYz/7nodYhTgYFTi4d0QEhYpxJpYVlyZe4hRkoNJSZR35bXQSCG+pPyU yozE4oz4otKc1OJDjBIczEoivEarwiOFeFMSK6tSi/JhUtIcLErivOIajRFCAumJJanZqakF qUUwWRkODiUJ3imXgBoFi1LTUyvSMnNKENJMHJwgw3mAhiu2gAwvLkjMLc5Mh8ifYlSUEudt vAiUEABJZJTmwfWCUo9E9v6aV4ziQK8I8zKAVPEA0xZc9yugwUxAg4VnhIAMLklESEk1MLKf Xjd/053uk1Kea3NCy39YZC1Z5fWhrCCpTinqzCK2dUfmBu0SfXcytCG/S1DTy2iKqOuc+rDz FcdMFGv8+1qZWGu6Z1nNNZv66PUKWWOR5cbf7wm+2/O+RG+H2T3DqRO+rWrY+E2rvtyzhmFr qMpyi20maRp6/L9W+fZ5pqjc61O7HHXqkBJLcUaioRZzUXEiAJcXeWIYAwAA Archived-At: Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-tls13-0rtt-02.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 16:53:26 -0000 Hi Nick, On Thu, Jun 29, 2017 at 08:16:33PM +0000, Andrei Popov wrote: > * A good point, if the attacks are still possible then supporting 0-RTT is problematic. > * On the other hand 0-RTT is a big speed boost for resumed connections. It is hard to imagine that servers are going to disable it to use token binding over the long term. > > There is often a tradeoff between security and performance; some servers may choose 0-RTT based on their business requirements, and others may choose TB. I do not think that it is necessary to reconcile TB and 0-RTT (although it would have been awesome if we could). From my perspective, it is more important to keep TB secure than to make it work with 0-RTT: replayable TB would be a waste of CPU cycles. I agree with Andrei that there is a tradeoff and keeping TB secure is important. For a long time I have been generally opposed to 0-RTT TB at a gut level, but I may have recently gained an intuition for how to articulate my concerns in a more concrete fashion. That is, as a server, I am interested in TB providing binding to the channel between the client and myself. But, since 0-RTT does not include any server contributions, in some sense 0-RTT TB is only binding to "half of the channel" (the client's contribution), and even though it is/ends up being bound to my (as the server) connection to the client, the same octets on the wire could also end up being bound to a different connection emanating from the client. So I as a server have a weaker security guarantee, and I would prefer to retain the stronger security property. -Ben From nobody Mon Jul 10 23:31:27 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAED13145F for ; Mon, 10 Jul 2017 23:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.79 X-Spam-Level: X-Spam-Status: No, score=-4.79 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_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ZvxOdJ_Gza8R for ; Mon, 10 Jul 2017 23:31:23 -0700 (PDT) Received: from o3.sgmail.github.com (o3.sgmail.github.com [192.254.112.98]) (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 A18C412EBF9 for ; Mon, 10 Jul 2017 23:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:to:subject:mime-version:content-type:content-transfer-encoding; s=s20150108; bh=fTuqbYmjiy5dji0HgIR8cnjAzIE=; b=SFj8c7pkcPbCFD6z FgkizF1AHK5wYSKf6XVSDR939AiNP62aYDdTzPMt3ARCYuEqTJwSyod0/1+orbGV yHp8QflM3YCqWlnLNDF2k9bS032i+ZBIhDuoC2QS2xqfovogbil0mp/eddD/kUHi sdEcEiyQGjFpPEK+jCjTyO6WA7c= Received: by filter0454p1mdw1.sendgrid.net with SMTP id filter0454p1mdw1-1456-596470B8-21 2017-07-11 06:31:20.39525523 +0000 UTC Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2a-ext-cp1-prd.iad.github.net [192.30.253.16]) by ismtpd0001p1iad1.sendgrid.net (SG) with ESMTP id BO5nqQmMRG6271QchWjpdw for ; Tue, 11 Jul 2017 06:31:20.410 +0000 (UTC) Date: Tue, 11 Jul 2017 06:31:20 +0000 (UTC) From: GitHub To: unbearable-ML Message-ID: <596470b839787_7faa3fdd4972fbf88614738@github-staff3-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_596470b838b35_7faa3fdd4972fbf8861462c"; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Auto-Response-Suppress: All categories: terms-of-service-update X-SG-EID: 9Yqp9dCIIwZxB0MVAPExrXlt7a4/46ALD9aG/N3UOYp2BM1peQoFl3+VtyWMSYM9oQjtXIO9yQUKV+ jy6py4I9/+02c3YYNyMqz9TzXm8EjEdyVlOhc5TBZLLZuV2SmEn6byN89Ajq77ogovlotui7fvKiRq tJMMO6kYflGWL6trq8F2FT5JheVhbFmevS9aSgbNbO5n91PWwKAdybz4ug== X-SG-ID: r8NHDv7ipxry1t+c3B8AksGE44bQ0laBULM2PGBCaHQV210sHWwZZ+atgUAUDUGO Archived-At: Subject: [Unbearable] Updates to GitHub Terms of Service X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 06:31:26 -0000 ----==_mimepart_596470b838b35_7faa3fdd4972fbf8861462c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Updated Terms of Service and new Site Policy repository ------------------------------------------------------------ We're updating our Terms of Service (https://help.github.com/articles/githu= b-terms-of-service/) and Corporate Terms of Service (https://help.github.co= m/articles/github-corporate-terms-of-service/). These revisions are the res= ult of community feedback, along with clarifications and improvements to th= e readability of both documents. All changes are in separate pull requests = in a new working repository, github/site-policy (https://github.com/github/= site-policy). Here, you can view, comment, and suggest additional updates= =E2=80=94or fork a copy to adapt for your own site. Please submit your comments by 5:00 pm PST on Friday, July 28. After that, = we=E2=80=99ll take a week to go through your comments and make changes to i= mprove the Terms. The new Terms will become effective on Monday, August 7. Pull requests welcome ------------------------------------------------------------ We welcome you to look over our changes and share your input using the new = Site Policy repository. Please follow our Contributor Guidelines (https://g= ithub.com/github/site-policy/blob/master/CONTRIBUTING.md) , and let us know= if you see anything you think should be different=E2=80=94whether it=E2=80= =99s a missed typo or a rule that might have implications we haven=E2=80=99= t thought of. Overview of changes ------------------------------------------------------------ * Updates to GitHub Terms of Service (https://github.com/github/site-policy= /pull/1) : Added a =E2=80=9CPrivate Repositories=E2=80=9D section as Sectio= n E, updated the licenses granted in Section D for clarity, and updated the= Complete Agreement subsection in Section S, =E2=80=9CMiscellaneous=E2=80= =9D * Updates to GitHub Corporate Terms of Service (https://github.com/github/s= ite-policy/pull/2) : Added a "Private Repositories" section as Section E, u= pdated the licenses granted in Section D for clarity, updated the Complete = Agreement subsection, and added a Publicity subsection to Section S, "Misce= llaneous" * Added a product description to the GitHub Business Plan Addendum (https:/= /help.github.com/articles/github-business-plan-addendum/) * Updated the Amendment to GitHub Terms of Service Applicable to U.S. Feder= al Government Users (https://help.github.com/amendment-to-github-terms-of-s= ervice-applicable-to-u-s-federal-government-users/) to reflect previous cha= nges to notification policy Can't comment before July 28? No problem! The site policy repository is alw= ays open, so you can send us feedback any time. Check out the blog post (ht= tps://github.com/blog/2393-open-sourcing-our-site-policies-and-new-changes-= to-our-terms-of-service) to learn more, or give us your feedback (https://g= ithub.com/github/site-policy/issues/). We'd love to hear if our project hel= ped you create policy foundations for your business. ------------------------------------------------------------ Email preferences (https://github.com/settings/emails) =C2=B7 Terms (https:= //help.github.com/articles/github-terms-of-service/) =C2=B7 Privacy (https:= //help.github.com/articles/github-privacy-policy/) =C2=B7 Sign into GitHub = (https://github.com/login) GitHub, Inc. 88 Colin P Kelly Jr St. San Francisco, CA 94107 ----==_mimepart_596470b838b35_7faa3fdd4972fbf8861462c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Terms of service update
Updated Terms of Service and new Site P= olicy repository
3D"GitHub"

Updated Terms of Service and new Site P= olicy repository

We're updating our Terms of Service and Corporate Terms of Service. These revisions are the result of communit= y feedback, along with clarifications and improvements to the readability o= f both documents. All changes are in separate pull requests in a new workin= g repository, github/s= ite-policy. Here, you can view, comment, and suggest additional updates= —or fork a copy to adapt for your own site.

Please submit your comments by 5:00 pm PST on Frida= y, July 28. After that, we=E2=80=99ll take a week to go through your commen= ts and make changes to improve the Terms. The new Terms will become effecti= ve on Monday, August 7.

Pull requests welcome

We welcome you to look over our changes and share y= our input using the new Site Policy repository. Please follow our C= ontributor Guidelines, and let us know if you see anything you think sh= ould be different=E2=80=94whether it=E2=80=99s a missed typo or a rule that= might have implications we haven=E2=80=99t thought of.

Overview of changes

Can't comment before July 28? No problem! The site = policy repository is always open, so you can send us feedback any time. Che= ck out the blog post to learn = more, or give us your feedback. We'd love to hear if our project helped you create po= licy foundations for your business.

Email preferences · Terms · Privacy · Sign into GitHub

GitH= ub, Inc.
= 88 Colin P Kelly Jr St.
San Francisco, CA 94107
----==_mimepart_596470b838b35_7faa3fdd4972fbf8861462c-- From nobody Tue Jul 11 14:53:51 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3361317DF for ; Tue, 11 Jul 2017 14:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 bxzlr0TqiY2v for ; Tue, 11 Jul 2017 14:53:48 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1824E1270B4 for ; Tue, 11 Jul 2017 14:53:48 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id z78so3135490lff.0 for ; Tue, 11 Jul 2017 14:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/mk4PDqEIxlG5yfl2UIM2EdHSzrfdqJ5EIdHuXH0CXQ=; b=QpR2SmaRZnzwq2QvTQ9Zp48Z/BlEJPv+vQoL226UmbofT1AjpNguyBb2cA0PLtCwY3 9LzBcbURGpU2UMFk8g8NuPBiGSvfja7kdAocJ06xIDnPa8KmXLfNJaWL0t4yHXWsn3ku DByNC9K6vjrDpddKy+8KSYCG/YJqoVHXCcpC23FJpu7qHfWnPRDAeDB88KlVuPoKi6oc V80mSqK2k6ukg61A0UWKVunPJvIXFSz3cO3qFyH5J7esMSAZ98knZ3JnmTkKPp5L2eT6 jFEmBVWnxtvkzd4L60eI1We4zWl7bcCPFNGWtbbsvEmwUjEmjcuSB5T/UrQ545U7YtSB riiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/mk4PDqEIxlG5yfl2UIM2EdHSzrfdqJ5EIdHuXH0CXQ=; b=g30X0hVkLpMC2hWaQ4tWmnrUiUbW/8fyT9O0qYKpCyVjt0YkTrTgEs/4qfj39fYrSt pZ09DteHpp5Vub8/wnl1s6zxZR0wP6/0VbOkXRUv/rGJv6vcqFN+ljhO6SJyya5fkB5m TaHfxSs4SU8l0YtiXXDjCwRPkYcPySHhzoFVoGyM+JPYOwHWnAjl6/4fpGwsXUAm9JDc 4LkBRNOVrXolv7x4jjGjZ1mWCzMO+OSrFDkdfFUuZH6cuJvYCXoPD59V1iQlkUBIcES9 tkYIGD1IwQU0J4YOXqsYJN8bKvfA0bTKFvmNFwiNg7r2Zt7/GPLmjU2dmpEhGS6FswpR JKuA== X-Gm-Message-State: AIVw111mDs6H+enCcVZ4G27rw0rvPEEuBONOCXkBnFak9bGm+VSfcCWO h6JnTKZH46CCApjgZ1l1bN+nBb8bMOTkPmMIwQ== X-Received: by 10.25.161.77 with SMTP id k74mr538957lfe.97.1499810026126; Tue, 11 Jul 2017 14:53:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.44.73 with HTTP; Tue, 11 Jul 2017 14:53:25 -0700 (PDT) In-Reply-To: <20170701165317.GT68391@kduck.kaduk.org> References: <149868793805.5443.4284920405751222901@ietfa.amsl.com> <20170629024818.GI68391@kduck.kaduk.org> <9057a735-a907-d06c-327b-a959e4f554f0@sunet.se> <97A1224B-5B6C-41EC-9FE0-CA0DE53746E1@ve7jtb.com> <20170701165317.GT68391@kduck.kaduk.org> From: Nick Harper Date: Tue, 11 Jul 2017 14:53:25 -0700 Message-ID: To: Benjamin Kaduk Cc: John Bradley , IETF Tokbind WG , Leif Johansson , "tokbind-chairs@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-tls13-0rtt-02.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 21:53:51 -0000 On Sat, Jul 1, 2017 at 9:53 AM, Benjamin Kaduk wrote: > Hi Nick, > > On Thu, Jun 29, 2017 at 08:16:33PM +0000, Andrei Popov wrote: >> There is often a tradeoff between security and performance; some servers= may choose 0-RTT based on their business requirements, and others may choo= se TB. I do not think that it is necessary to reconcile TB and 0-RTT (altho= ugh it would have been awesome if we could). From my perspective, it is mor= e important to keep TB secure than to make it work with 0-RTT: replayable T= B would be a waste of CPU cycles. > > I agree with Andrei that there is a tradeoff and keeping TB secure is imp= ortant. I agree that there are trade-offs to be made between security and performance, and I agree that some clients and servers when choosing to do Token Binding will want it to be as secure as possible. I'm a little confused by what you mean when you say "keeping TB secure is important". 0-RTT TB does not change the security properties of the existing TB in TBNEGO/TBPROTO. > > For a long time I have been generally opposed to 0-RTT TB at a gut level, > but I may have recently gained an intuition for how to articulate my > concerns in a more concrete fashion. That is, as a server, I am interest= ed > in TB providing binding to the channel between the client and myself. > But, since 0-RTT does not include any server contributions, in some sense > 0-RTT TB is only binding to "half of the channel" (the client's contribut= ion), > and even though it is/ends up being bound to my (as the server) connectio= n > to the client, the same octets on the wire could also end up being bound > to a different connection emanating from the client. So I as a server > have a weaker security guarantee, and I would prefer to retain the strong= er > security property. > > -Ben There is a server contribution to the exporter value signed in 0-RTT TB - the server contribution is the PSK from the NewSessionTicket issued on the original connection. 0-RTT TB is just like using client certificates with TLS resumption: with client certificates there is only a signature on the original connection, and the client auth state is carried over from the previous connection on resumption. With 0-RTT TB, there is a signature on both the original and resumed connection, but this signature just proves that the private key was used at the beginning of the original connection (since the resumed connection's signature could hypothetically be computed then as well). In both cases - client certs and 0-RTT TB - we have proof of possession of the private key at the beginning of the original connection, but not at the beginning of the resumed connection. I think having comparable security to client certificates is a decent bar that 0-RTT TB meets. I know that 1-RTT TB meets a higher security bar, and I don't expect to convince those wanting to trade performance for this additional security that they should implement 0-RTT TB. I'm trying to make the case that 0-RTT TB is not a waste of resources and that it provides a decent level of security for those wishing to use it. From nobody Tue Jul 11 17:24:01 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9724513181D; Tue, 11 Jul 2017 17:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 3oAQ6F1K8UZo; Tue, 11 Jul 2017 17:23:58 -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 AABB813180F; Tue, 11 Jul 2017 17:23:58 -0700 (PDT) X-AuditID: 1209190f-2e3ff70000003f98-7d-59656c1c5f2e Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 55.78.16280.C1C65695; Tue, 11 Jul 2017 20:23:57 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v6C0NtCH032505; Tue, 11 Jul 2017 20:23:56 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v6C0Np19022195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Jul 2017 20:23:53 -0400 Date: Tue, 11 Jul 2017 19:23:51 -0500 From: Benjamin Kaduk To: Nick Harper Cc: John Bradley , IETF Tokbind WG , Leif Johansson , "tokbind-chairs@ietf.org" Message-ID: <20170712002351.GZ80947@kduck.kaduk.org> References: <149868793805.5443.4284920405751222901@ietfa.amsl.com> <20170629024818.GI68391@kduck.kaduk.org> <9057a735-a907-d06c-327b-a959e4f554f0@sunet.se> <97A1224B-5B6C-41EC-9FE0-CA0DE53746E1@ve7jtb.com> <20170701165317.GT68391@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hRV1pXNSY002Pie1WJB71Zmi/4d+xgt ls+fz2Zx7vFCJovVd/+yObB6LNhU6rFkyU8mj72b+tg9bt/eyBLAEsVlk5Kak1mWWqRvl8CV 0dPlU3BSvmLq6l7mBsYuyS5GTg4JAROJeyd3snQxcnEICSxmkvg0Zy0rhLORUeLqgmYo5yqT xKJ77ewgLSwCqhIvd8xiBrHZBFQkGrovg9kiQPb8q9fBGpgFNjNKnJr3ghUkISzgJTFj0RMW EJsXaN++V/1Q+5axSDyYsYoNIiEocXImRBGzgJbEjX8vmboYOYBsaYnl/zhATE6BQIk53+tA KkQFlCX+Hr7HMoFRYBaS5llImmchNC9gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6KXm1mi l5pSuokRHNaS/DsY5zR4H2IU4GBU4uFtuJASKcSaWFZcmXuIUZKDSUmUNygWKMSXlJ9SmZFY nBFfVJqTWnyIUYKDWUmEN/YBUI43JbGyKrUoHyYlzcGiJM4rrtEYISSQnliSmp2aWpBaBJOV 4eBQkuA9n5UaKSRYlJqeWpGWmVOCkGbi4AQZzgM03DsaqIa3uCAxtzgzHSJ/ilFRSpz3ViZQ QgAkkVGaB9cLSjsS2ftrXjGKA70izMsNsoIHmLLgul8BDWYCGrwmG+Tq4pJEhJRUAyMPV+TF C0s0w97OZLx+7NmqjVyTSnwvK66u3hno4/ZcSJ97+6fS9+tXGVy7eHRH2sN3+Q4Tj/ExvqgT TbBcvMHcZJ6baWDUVwW9lysZeGUuLkn8mbnFIf/7rQSPVtbLBVW8pb+nd7ypK1vx99EjxhPN mkXq4ezCJ9I6hf5FvXJ11WDZ23VrboMSS3FGoqEWc1FxIgDv4PrLFgMAAA== Archived-At: Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-tls13-0rtt-02.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 00:24:01 -0000 On Tue, Jul 11, 2017 at 02:53:25PM -0700, Nick Harper wrote: > On Sat, Jul 1, 2017 at 9:53 AM, Benjamin Kaduk wrote: > > Hi Nick, > > > > On Thu, Jun 29, 2017 at 08:16:33PM +0000, Andrei Popov wrote: > >> There is often a tradeoff between security and performance; some servers may choose 0-RTT based on their business requirements, and others may choose TB. I do not think that it is necessary to reconcile TB and 0-RTT (although it would have been awesome if we could). From my perspective, it is more important to keep TB secure than to make it work with 0-RTT: replayable TB would be a waste of CPU cycles. > > > > I agree with Andrei that there is a tradeoff and keeping TB secure is important. > > I agree that there are trade-offs to be made between security and > performance, and I agree that some clients and servers when choosing > to do Token Binding will want it to be as secure as possible. I'm a > little confused by what you mean when you say "keeping TB secure is > important". 0-RTT TB does not change the security properties of the > existing TB in TBNEGO/TBPROTO. My interpretation was (to very very roughly paraphrase) that this is a question of branding -- that is, when we say that something is secured with Token Binding, we want that to mean the high level of security. > > For a long time I have been generally opposed to 0-RTT TB at a gut level, > > but I may have recently gained an intuition for how to articulate my > > concerns in a more concrete fashion. That is, as a server, I am interested > > in TB providing binding to the channel between the client and myself. > > But, since 0-RTT does not include any server contributions, in some sense > > 0-RTT TB is only binding to "half of the channel" (the client's contribution), > > and even though it is/ends up being bound to my (as the server) connection > > to the client, the same octets on the wire could also end up being bound > > to a different connection emanating from the client. So I as a server > > have a weaker security guarantee, and I would prefer to retain the stronger > > security property. > > > > -Ben > > There is a server contribution to the exporter value signed in 0-RTT > TB - the server contribution is the PSK from the NewSessionTicket > issued on the original connection. 0-RTT TB is just like using client > certificates with TLS resumption: with client certificates there is > only a signature on the original connection, and the client auth state > is carried over from the previous connection on resumption. With 0-RTT > TB, there is a signature on both the original and resumed connection, > but this signature just proves that the private key was used at the > beginning of the original connection (since the resumed connection's > signature could hypothetically be computed then as well). In both > cases - client certs and 0-RTT TB - we have proof of possession of the > private key at the beginning of the original connection, but not at > the beginning of the resumed connection. I think having comparable > security to client certificates is a decent bar that 0-RTT TB meets. I agree about the transitive contribution. My intent was to indicate a desire for a current/fresh server contribution that is specific to the current connection. I'm also not sure that using client certificates as a comparison is the right place to set the bar. > I know that 1-RTT TB meets a higher security bar, and I don't expect > to convince those wanting to trade performance for this additional > security that they should implement 0-RTT TB. I'm trying to make the > case that 0-RTT TB is not a waste of resources and that it provides a > decent level of security for those wishing to use it. I mean, you should probably continue to make your case. At some point the WG will have to decide whether it is "good enough" to merit the stamp of approval as an okay thing for consumers of TB to be able to choose to use (or not use). -Ben From nobody Fri Jul 14 09:59:55 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBCC128B8D for ; Fri, 14 Jul 2017 09:59:54 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tu5Ef0hZuBro for ; Fri, 14 Jul 2017 09:59:52 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 CC7E8126C22 for ; Fri, 14 Jul 2017 09:59:52 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id q85so48122101pfq.1 for ; Fri, 14 Jul 2017 09:59:52 -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; bh=1SJdM3ZsQBov7sQe+AuEithIX7eSkVfOEdJ5pak7V04=; b=mQUNuSTwloDs+M8/hoIZDxNc2eC4zm/OhEAx+YcQ7tyycY4eHdpLIwegppqSpVhWaX OZ14lM1G8Toih6kKxlwysI2FwzaGdGngpRW5qIB13UE5knQCeaBGMcHaLgzZ1Bzp4JQ+ Cyc2pbYbPl+vZdp0+FSy3ksLt3yEcz2XV9FHU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1SJdM3ZsQBov7sQe+AuEithIX7eSkVfOEdJ5pak7V04=; b=M1wrFsTX9ikH7V7P6TOMG971o9YL/Csx2LYE8i6IZ7FfspFjF4dz+UQ0/K3X7vB5WJ +w8rMidnpxbJ0ua5JyZ6KsAhjmFgHaZOEE56/hI8QkkdvxM+ujY6RbWzDIB9dTrzrGhk UMsS5Sasmn62KzFWSC9Q/a9CZ/U8z8hDN8Gk9GfWVcBUp8c8FczC2XrEHcVB2ZIP3gd1 Nzd5tTd+UeunfcWpCTQFhAeB4FgSo5ZFfbLAXw29t6xURT3/Sb0vcbR8e8zGsjxCCB+a 703NC5uzu26jDXsuBOIMKxjm9GCoBaSPhk7qzVI/YC0oTJpzSyZh4Z+xA/MCHvN293sk Z2hg== X-Gm-Message-State: AIVw1123zZ+IpWAWBa3Vaxob+uJ3TYtN3cTQJ2LaXyrjJQCQx+0nnkkv zKqJ+gUbzLrVtRv1WdZxhvZOOsHUhnY/jlhhTXRKt6NCDaNTCEOirR1dviIvIYEtIf/93snCg1F nacCkHi6nM1L7WQ== X-Received: by 10.98.15.71 with SMTP id x68mr6319495pfi.176.1500051592124; Fri, 14 Jul 2017 09:59:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Fri, 14 Jul 2017 09:59:21 -0700 (PDT) From: Brian Campbell Date: Fri, 14 Jul 2017 10:59:21 -0600 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary="001a1137741e4b3841055449facf" Archived-At: Subject: [Unbearable] HTTPS Token Binding with TLS Terminating Reverse Proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 16:59:54 -0000 --001a1137741e4b3841055449facf Content-Type: text/plain; charset="UTF-8" Just a not-so-subtle reminder that HTTPS Token Binding with TLS Terminating Reverse Proxies is one of the agenda items for Monday's meeting in Prague and it would be great if there was some familiarity with it going into the meeting. It's relativity short as drafts go, if you're looking for something to read en route to the meeting: https://tools.ietf.org/html/ draft-campbell-tokbind-ttrp-00 -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --001a1137741e4b3841055449facf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just a not-so-subtle reminder that HTTPS Token Bindin= g with TLS Terminating Reverse Proxies is one of the agenda items for Monda= y's meeting in Prague and it would be great if there was some familiari= ty with it going into the meeting. It's relativity short as drafts go, = if you're looking for something to read en route to the meeting: https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-00=

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a1137741e4b3841055449facf-- From nobody Fri Jul 14 14:24:02 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FBC129B33 for ; Fri, 14 Jul 2017 14:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyuzKL0IupgI for ; Fri, 14 Jul 2017 14:23:59 -0700 (PDT) Received: from treenet.co.nz (unknown [121.99.228.82]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD63129AA8 for ; Fri, 14 Jul 2017 14:23:56 -0700 (PDT) Received: from [192.168.137.92] (unknown [121.98.43.66]) by treenet.co.nz (Postfix) with ESMTPA id 9A38666044C; Sat, 15 Jul 2017 09:23:53 +1200 (NZST) To: Brian Campbell , IETF Tokbind WG References: From: Amos Jeffries Message-ID: Date: Sat, 15 Jul 2017 09:23:52 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Unbearable] HTTPS Token Binding with TLS Terminating Reverse Proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 21:24:01 -0000 On 15/07/17 04:59, Brian Campbell wrote: > Just a not-so-subtle reminder that HTTPS Token Binding with TLS > Terminating Reverse Proxies is one of the agenda items for Monday's > meeting in Prague and it would be great if there was some familiarity > with it going into the meeting. It's relativity short as drafts go, if > you're looking for something to read en route to the meeting: > https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-00 > > I wont be at the meeting. But reviewing anyway. Several of the processing requirements in section 2.2 appear to be re-inventing already existing HTTP mechanisms without referencing them, nor integrating with them to support proxies that only implement HTTP - not TB. Firstly; Section 2.2 bullet item #1 places a normative MUST requirement on removing "Sec-Token-Binding" header from the clients request when forwarding. Since the TLS connection is one "hop" this duplicates HTTP hop-by-hop header requirements. Such headers are governed by RFC 7230 section 6.1 and required (also a normative MUST) to be listed in the HTTP Connection header by the sender. Such that even if the receiving proxy is not implementing this specification, it will still fail-safe by removing the header. Secondly; Section 2.2 bullet item #4 and the paragraph following it define the same behaviour for the "Provided-Token-Binding-ID" and "Referred-Token-Binding-ID" headers. These two are not such a clear case of hop-by-hop since without the TLS there is the possibility of other hops between reverse-proxy and origin server. I believe it still worth at least referencing the HTTP Connection header as something that SHOULD be used to improve secure behaviour for messages containing those headers - the exception being when there are known to be multiple HTTP hops within the backend network. NP: I know the TLS layer should be negotiating use of TB, so the sender "knows" the recipient implements this draft. But there is a possibility of the TLS decryption being done by other software than the HTTP processing, or opaquely relayed by an agent that negotiates TB, while the HTTP is processed by a proxy that does not support it. Use of the HTTP Connection header ensure the TB security is maintained even in those type of misconfiguration scenarios. AYJ From nobody Fri Jul 14 15:07:34 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D02012EC2B for ; Fri, 14 Jul 2017 15:07:32 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihU29YOaf29p for ; Fri, 14 Jul 2017 15:07:29 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 BA7DD12EC57 for ; Fri, 14 Jul 2017 15:07:29 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id e7so51201718pfk.0 for ; Fri, 14 Jul 2017 15:07:29 -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=Yaws0+tlzmQhK3CXQVCNsFSBxUn644e3SdXdCxPg+lc=; b=bLtu1fhf3RFyiOmAhvXJ07sXvJZA9M3xlz6A5tHx9m8m1H8tNRIwVJ46CBkA59nIqB CYFNozXV/TxrDzBJqCcwZFzbXcAVa46xRXjeX5p56u8WV732Jr+USCPtanzwCaz0P6oP Ubm1oojvE4yN3IC2+w0i8dy6rPvGf8zFEHEHY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Yaws0+tlzmQhK3CXQVCNsFSBxUn644e3SdXdCxPg+lc=; b=UQsbulGoZyzZrXWLSA0/dQGjH1lzGLJer7KvFf+hwuBPZZt8L+VWTtyAvsJR84GiW6 KYEfpJEBeRXWShgBSHLNzL+DcsEJeqml+lIVJ+Ot2auEMyQZftBQwjblLWzmXewImspx njSsvr/JmTt9pfAYzchHI4ypZVJ6gZieRP9/n7cP9zrbsT94Q75qPUWeT7M3Hf2LwRb1 ZwFT7szs344Zlj/eU/TsGx1gQ57NKdrPEUXXcykYdEG9LlMk5G+75Lk/fon3Z6th8Pdg nZSUTpwdLqC0xvPkpk5KMfOzovtGnIu5cLkIWAmK0anCRNvPLieAvWpQng6H04wt28bf RPYw== X-Gm-Message-State: AIVw113Dy5DjFdQ3o6Rrc134eWAm7IiVH0o1xlOAxljIib0k5uIOFrk5 JbVmCvQLDxsw17segWvzL47U480WKvvHmKZmPs4tqx3zdKcmbJuvElMmPmXzZ6zL3S0fIjcdLQe 01Pn8IN1AYbdnug== X-Received: by 10.84.237.15 with SMTP id s15mr18596996plk.100.1500070049323; Fri, 14 Jul 2017 15:07:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.151.199 with HTTP; Fri, 14 Jul 2017 15:06:57 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Fri, 14 Jul 2017 16:06:57 -0600 Message-ID: To: Amos Jeffries Cc: IETF Tokbind WG Content-Type: multipart/alternative; boundary="94eb2c1ceb7e6dbd8905544e464c" Archived-At: Subject: Re: [Unbearable] HTTPS Token Binding with TLS Terminating Reverse Proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 22:07:32 -0000 --94eb2c1ceb7e6dbd8905544e464c Content-Type: text/plain; charset="UTF-8" The "Sec-Token-Binding" header is defined in https://tools.ietf.org/html/draft-ietf-tokbind-https and the WG decided not to list "Sec-Token-Binding" in the Connection header field in that document. https://mailarchive.ietf.org/arch/search/?email_list= unbearable&q=%22on+not+listing+%27Sec-Token-Binding% 27+in+the+Connection+header+field%3F%22 will turn up at least some of that discussion. It wouldn't make sense for this draft to require different behavior of the client. Especially when the client won't know (and shouldn't know) if it's talking to a reverse proxy or not. "Provided-Token-Binding-ID" and "Referred-Token-Binding-ID" are not hop-by-hop. They are providing info from the TTRP to the backend, whatever that backend is. And the backend may involve additional layers of proxies or it may not. But that's beyond the scope of this document. On Fri, Jul 14, 2017 at 3:23 PM, Amos Jeffries wrote: > On 15/07/17 04:59, Brian Campbell wrote: > >> Just a not-so-subtle reminder that HTTPS Token Binding with TLS >> Terminating Reverse Proxies is one of the agenda items for Monday's meeting >> in Prague and it would be great if there was some familiarity with it going >> into the meeting. It's relativity short as drafts go, if you're looking for >> something to read en route to the meeting: https://tools.ietf.org/html/dr >> aft-campbell-tokbind-ttrp-00 > raft-campbell-tokbind-ttrp-00> >> >> > I wont be at the meeting. But reviewing anyway. > > > Several of the processing requirements in section 2.2 appear to be > re-inventing already existing HTTP mechanisms without referencing them, nor > integrating with them to support proxies that only implement HTTP - not TB. > > > Firstly; > > Section 2.2 bullet item #1 places a normative MUST requirement on removing > "Sec-Token-Binding" header from the clients request when forwarding. > > Since the TLS connection is one "hop" this duplicates HTTP hop-by-hop > header requirements. Such headers are governed by RFC 7230 section 6.1 and > required (also a normative MUST) to be listed in the HTTP Connection header > by the sender. Such that even if the receiving proxy is not implementing > this specification, it will still fail-safe by removing the header. > > > Secondly; > > Section 2.2 bullet item #4 and the paragraph following it define the same > behaviour for the "Provided-Token-Binding-ID" and > "Referred-Token-Binding-ID" headers. > > > These two are not such a clear case of hop-by-hop since without the TLS > there is the possibility of other hops between reverse-proxy and origin > server. I believe it still worth at least referencing the HTTP Connection > header as something that SHOULD be used to improve secure behaviour for > messages containing those headers - the exception being when there are > known to be multiple HTTP hops within the backend network. > > > > NP: I know the TLS layer should be negotiating use of TB, so the sender > "knows" the recipient implements this draft. But there is a possibility of > the TLS decryption being done by other software than the HTTP processing, > or opaquely relayed by an agent that negotiates TB, while the HTTP is > processed by a proxy that does not support it. Use of the HTTP Connection > header ensure the TB security is maintained even in those type of > misconfiguration scenarios. > > AYJ > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --94eb2c1ceb7e6dbd8905544e464c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The "Sec-Token-Binding" header is defined i= n https://= tools.ietf.org/html/draft-ietf-tokbind-https and the WG decided not to = list "Sec-Token-Binding" in the Connection header field in that d= ocument. https://mailarchive.ietf.org/arch/search/?email_list=3Dunbearable&q=3D%22on+not+listing+%= 27Sec-Token-Binding%27+in+the+Connection+header+field%3F%22 w= ill turn up at least some of that discussion. It wouldn't make sense fo= r this draft to require different behavior of the client. Especially when t= he client won't know (and shouldn't know) if it's talking to a = reverse proxy or not.=C2=A0

"Provided-Token-Binding= -ID" and "Referred-Token-Binding-ID" are not hop-by-hop. The= y are providing info from the TTRP to the backend, whatever that backend is= . And the backend may involve additional layers of proxies or it may not. B= ut that's beyond the scope of this document.





On Fri, Jul 14, 2017 at 3:23 PM, Amos Jeffries <squid3@treen= et.co.nz> wrote:
On 15/07= /17 04:59, Brian Campbell wrote:
Just a not-so-subtle reminder that HTTPS Token Binding with TLS Terminating= Reverse Proxies is one of the agenda items for Monday's meeting in Pra= gue and it would be great if there was some familiarity with it going into = the meeting. It's relativity short as drafts go, if you're looking = for something to read en route to the meeting: https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-00 &l= t;https://tools.ietf.org/html/draft-c= ampbell-tokbind-ttrp-00>


I wont be at the meeting. But reviewing anyway.


Several of the processing requirements in section 2.2 appear to be re-inven= ting already existing HTTP mechanisms without referencing them, nor integra= ting with them to support proxies that only implement HTTP - not TB.


Firstly;

Section 2.2 bullet item #1 places a normative MUST requirement on removing = "Sec-Token-Binding" header from the clients request when forwardi= ng.

Since the TLS connection is one "hop" this duplicates HTTP hop-by= -hop header requirements. Such headers are governed by RFC 7230 section 6.1= and required (also a normative MUST) to be listed in the HTTP Connection h= eader by the sender. Such that even if the receiving proxy is not implement= ing this specification, it will still fail-safe by removing the header.


Secondly;

Section 2.2 bullet item #4 and the paragraph following it define the same b= ehaviour for the "Provided-Token-Binding-ID" and "Referred-T= oken-Binding-ID" headers.


These two are not such a clear case of hop-by-hop since without the TLS the= re is the possibility of other hops between reverse-proxy and origin server= . I believe it still worth at least referencing the HTTP Connection header = as something that SHOULD be used to improve secure behaviour for messages c= ontaining those headers - the exception being when there are known to be mu= ltiple HTTP hops within the backend network.



NP: I know the TLS layer should be negotiating use of TB, so the sender &qu= ot;knows" the recipient implements this draft. But there is a possibil= ity of the TLS decryption being done by other software than the HTTP proces= sing, or opaquely relayed by an agent that negotiates TB, while the HTTP is= processed by a proxy that does not support it. Use of the HTTP Connection = header ensure the TB security is maintained even in those type of misconfig= uration scenarios.

AYJ


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c1ceb7e6dbd8905544e464c-- From nobody Mon Jul 17 03:38:00 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78741318A3 for ; Mon, 17 Jul 2017 03:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFXGmmPJKcO6 for ; Mon, 17 Jul 2017 03:37:58 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 437A3131893 for ; Mon, 17 Jul 2017 03:37:58 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id 35so42739857uax.3 for ; Mon, 17 Jul 2017 03:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lnl0zYooVTeRKyor0TJg4P82xZNeBJwTQdOpqsirRCk=; b=ZeiYbMBZeNq2wJcyTon46eBq1anGUsLAmnnNRM4dB7nFnRNQMNPzrxEp2Tff+Gm/l0 JwkcXGs0a7aSG84Bywy+B09L0LM9R0CD8bE7lh7Z3MWmkGr4XagBOaUJavYt57zJKu14 VKuiB2SABBRlH4oVypShuffxrKTUb4/9UGbgs9nV8TJp3I/CcNXOn3dKWNcSFGb3T7QD mjF71M3epUT9K3hvE2oc+Qje5oGi+aJEWdWAQAnWtgOuwzEYpl6x6BVKlQOkCPiVmJSs CgOx+dKr84tZWjd1x5mKTXAfYMfRc9WDMH1K/OfIqLW8MPrGMs0ZB3sr68nwGAR+ud0l xGOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lnl0zYooVTeRKyor0TJg4P82xZNeBJwTQdOpqsirRCk=; b=U58xhR6bmGMwZkbeuLOowxPwwAuUItQCXwvDeTauVVsiVg0xzG8CX2wq7RC25phqMH x+ZQO+SQlljotjMYNBtvJoR3RZ4JBcqbeu1EvyRTLv2aXsN9QX+al+T7VX8fgp/qrFCO s7rKlZtEq99V9Ki5BPDSbSStf6ynGK91i8+CnEBa7hxvw8DfxGkqPf/ch8LA2MmNZ537 CQWiVJRgReCn9c+kN9s/iLUzw2vfbjbHXpwFlmEXU363KqewYv+ronBtm+2bh82WaMh+ uvYNcQz4FC8h266KUdrO5clq3FmkWbASal0bRcvHBv4iCoRkWfTYn2nCq0d7NBL6v0xO SqkQ== X-Gm-Message-State: AIVw112FQPJUu4nAWfGgfggcq5U/XbEYkDKMxnk268TNVICUmw+fwf5t DfBrvt7GiGz83fwBRSaID6WoOpO+kVLh X-Received: by 10.31.52.74 with SMTP id b71mr1087818vka.18.1500287877037; Mon, 17 Jul 2017 03:37:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.176.67 with HTTP; Mon, 17 Jul 2017 03:37:56 -0700 (PDT) In-Reply-To: References: From: Piotr Sikora Date: Mon, 17 Jul 2017 12:37:56 +0200 Message-ID: To: Brian Campbell Cc: IETF Tokbind WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Unbearable] HTTPS Token Binding with TLS Terminating Reverse Proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 10:38:00 -0000 Hey Brian, looks good, thanks for working on that! One question: > Reverse proxies SHOULD only add the headers to requests that are > forwarded to trusted backend servers. Why? What's the attack vector, security and/or privacy implications here? Best regards, Piotr Sikora On Fri, Jul 14, 2017 at 6:59 PM, Brian Campbell wrote: > Just a not-so-subtle reminder that HTTPS Token Binding with TLS Terminating > Reverse Proxies is one of the agenda items for Monday's meeting in Prague > and it would be great if there was some familiarity with it going into the > meeting. It's relativity short as drafts go, if you're looking for something > to read en route to the meeting: > https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-00 > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you. > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > From nobody Mon Jul 17 03:54:05 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDA5131838 for ; Mon, 17 Jul 2017 03:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Xpj8et7afek for ; Mon, 17 Jul 2017 03:54:01 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C02120725 for ; Mon, 17 Jul 2017 03:54:01 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id 123so4846015pgj.1 for ; Mon, 17 Jul 2017 03:54:01 -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=SQYhdgFKG45bwCmbDxtHK7P+18ppTJh4mwsCnx2ff98=; b=cPjmbhwgqTpMywgkVMbgAcHIHlbgr3boPFLhQy9GHg3iKaMGipDunNT5lm3Ols92JL pEFGAxSGGaYyEolKfODCSQKOgw2ZJYUxBG1aHpgNNc3htv7iYwAEXj8Js03HfJQA0KGV 8Xcg0E905ZVX4nLhR40hfNFyplTHB1rx0u8KQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SQYhdgFKG45bwCmbDxtHK7P+18ppTJh4mwsCnx2ff98=; b=HGefrkhzNGZ16NUxAb4hUxUA2BmcO4wf4wMLduuCjKu/vgPbFYJT1BHSHjHsz+0RYj TzqptSFV+A0JhGxnlRJGRgHZBg6yWEIZXWFPhkPU0Qebv1nPP5U1+q27BoQhAfIIEdrV p8J6XvUr2hdg6Sicakm6eVJEUI8Cg0CC+sz9kaSQ2BWWIZLsp+bUMZeY7pcx2fvEFqO+ E64k+zL1PiA1pofmyJ2Ta8EVJwKdC5xnOe9bMOXcFlbnh7sLtr53e14/NOINcK0fDtAJ 35XPpzxYvkQNj4RnuNVKFhfQIJjEn/T1kMA8+jzetRekqn3DT+ha0xsJZ+cGvunpp5Io 313g== X-Gm-Message-State: AIVw113y2clzll4T7eRDhl8p5RTRNlv/IKozursa7/B5BiPIOfh4FcDj cI9ZiVFFBeeJw5VxHImig6MK6fUFW5UJ6KiMO5UCOOiyO+jfLxCmCs7P2n0uv/SVN8wHen1EQva 1fmaz/hxXF6U= X-Received: by 10.84.237.15 with SMTP id s15mr30252772plk.100.1500288841000; Mon, 17 Jul 2017 03:54:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Mon, 17 Jul 2017 03:53:30 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 17 Jul 2017 12:53:30 +0200 Message-ID: To: Piotr Sikora Cc: IETF Tokbind WG Content-Type: multipart/alternative; boundary="94eb2c1ceb7e6dd7160554813715" Archived-At: Subject: Re: [Unbearable] HTTPS Token Binding with TLS Terminating Reverse Proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 10:54:03 -0000 --94eb2c1ceb7e6dd7160554813715 Content-Type: text/plain; charset="UTF-8" To be honest, I didn't have a specific attack vector or security/privacy implication in mind around that. It just seemed like something that should generally be part of reverse proxy set up. Do you think it's too restrictive/perspective? Or do you know of some use-case where a reverse proxy wouldn't know/trust the servers that it sits in front of? On Mon, Jul 17, 2017 at 12:37 PM, Piotr Sikora wrote: > Hey Brian, > looks good, thanks for working on that! > > One question: > > > Reverse proxies SHOULD only add the headers to requests that are > > forwarded to trusted backend servers. > > Why? What's the attack vector, security and/or privacy implications here? > > Best regards, > Piotr Sikora > > On Fri, Jul 14, 2017 at 6:59 PM, Brian Campbell > wrote: > > Just a not-so-subtle reminder that HTTPS Token Binding with TLS > Terminating > > Reverse Proxies is one of the agenda items for Monday's meeting in Prague > > and it would be great if there was some familiarity with it going into > the > > meeting. It's relativity short as drafts go, if you're looking for > something > > to read en route to the meeting: > > https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-00 > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged > > material for the sole use of the intended recipient(s). Any review, use, > > distribution or disclosure by others is strictly prohibited. If you have > > received this communication in error, please notify the sender > immediately > > by e-mail and delete the message and any file attachments from your > > computer. Thank you. > > _______________________________________________ > > Unbearable mailing list > > Unbearable@ietf.org > > https://www.ietf.org/mailman/listinfo/unbearable > > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --94eb2c1ceb7e6dd7160554813715 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To be honest, I didn't have a specific attack vector o= r security/privacy implication in mind around that. It just seemed like som= ething that should generally be part of reverse proxy set up. Do you think = it's too restrictive/perspective? Or do you know of some use-case where= a reverse proxy wouldn't know/trust the servers that it sits in front = of?=C2=A0

On Mon, Jul 17, 2017 at 12:37 PM, Piotr Sikora <piotrsikora@google= .com> wrote:
Hey Brian,
looks good, thanks for working on that!

One question:

>=C2=A0 =C2=A0Reverse proxies SHOULD only add the headers to requests th= at are
>=C2=A0 =C2=A0forwarded to trusted backend servers.

Why? What's the attack vector, security and/or privacy implications her= e?

Best regards,
Piotr Sikora

On Fri, Jul 14, 2017 at 6:59 PM, Brian Campbell
<bcampbell@pingidentity.co= m> wrote:
> Just a not-so-subtle reminder that HTTPS Token Binding with TLS Termin= ating
> Reverse Proxies is one of the agenda items for Monday's meeting in= Prague
> and it would be great if there was some familiarity with it going into= the
> meeting. It's relativity short as drafts go, if you're looking= for something
> to read en route to the meeting:
> https://tools.ietf.org/html/draf= t-campbell-tokbind-ttrp-00
>
> CONFIDENTIALITY NOTICE: This email may contain confidentia= l and privileged
> material for the sole use of the intended recipient(s). Any review, us= e,
> distribution or disclosure by others is strictly prohibited.=C2=A0 If = you have
> received this communication in error, please notify the sender immedia= tely
> by e-mail and delete the message and any file attachments from your > computer. Thank you.
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbe= arable
>


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c1ceb7e6dd7160554813715-- From nobody Mon Jul 17 04:18:07 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F983131461 for ; Mon, 17 Jul 2017 04:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVVAXjN4sMEL for ; Mon, 17 Jul 2017 04:18:04 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 8F267127599 for ; Mon, 17 Jul 2017 04:18:04 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id 35so43709667uax.3 for ; Mon, 17 Jul 2017 04:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N6HS/DDv4QtNV+BUgdfvfwYzMBdCDOzobYMczCczigc=; b=HkE6eTGvchQl0UBkg4XPZbS8bAGbBEIykeRUhxA68/oDUBCtXal2eOWxuEjy+h4IFp zyxYfyPQlttu9b91o+8B9gGh4M7KgZz+hWVauPjrxfoAIpbQCxXuVf1WNUPNda7p5HfW 9olBKVHz0kBmvXx7oAHFDSIwLhFopZWCpJ9fxeUb4Rt1jWUlSI90rLMM4jfqyyMKrn27 zM2Z4ri8NRPXGe8bJ3s8cHU8w50Uw6wtlwBzRSXQ0J/rh/Zb1+NR1i87wDcG69JHWveN 8IjruofN/pBHqyaZHDD41MwF7KrZEjehra7KudnSvTJTriM3klhRJIYZMUaxBgcHBLcn aAiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N6HS/DDv4QtNV+BUgdfvfwYzMBdCDOzobYMczCczigc=; b=jQCfIHYX7765oDUi5VRhjORu2S30pyLEmN3W5+lIRfEAGwcDG2FLjo4Ki7qMvBp+7g 9voSkZ2wp9m4Leenr+GMdChlEkSPSmqrTX/IgNoPbntLmb5S1S9zZom81ipcwdERQQ97 cXlI447SGC7g9sFHVmAKV1FcCBZP5V8pCCb8AiXQq6rDKarlGsSSsAT1+l86HJjo/bqz x7baUX0lAvNiFxPbnbt/To+/jHlvTgvzuP2vd5+mAxTtzIVmC/v92HpIF/MKsiwvMAlG aN+G07Uf9aZ4ou7bFRCSchSHhCreO5FvN+2E+fqUGxM1K2LUjwSi2xAKLjzpDWRNKj0N 4rMA== X-Gm-Message-State: AIVw111EpemreAMO0WM+3cZejU/6qAOk77iafAWlafyragvHvSPDWnMM YBZddSIF4Y647NldN/6dcU+JFRIml8uNNedCfQ== X-Received: by 10.159.50.137 with SMTP id l9mr10471110uab.89.1500290283444; Mon, 17 Jul 2017 04:18:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.176.67 with HTTP; Mon, 17 Jul 2017 04:18:02 -0700 (PDT) In-Reply-To: References: From: Piotr Sikora Date: Mon, 17 Jul 2017 13:18:02 +0200 Message-ID: To: Brian Campbell Cc: IETF Tokbind WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Unbearable] HTTPS Token Binding with TLS Terminating Reverse Proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 11:18:06 -0000 Hey Brian, from the CDN point of view, all backend servers are untrusted, but I don't see any reason why CDNs shouldn't forward Provided-Token-Binding-ID to the origin servers. Also, Token Binding is supposed to protect Cookies (among other things), which don't have such restriction, so this seems unnecessary. Best regards, Piotr Sikora On Mon, Jul 17, 2017 at 12:53 PM, Brian Campbell wrote: > To be honest, I didn't have a specific attack vector or security/privacy > implication in mind around that. It just seemed like something that should > generally be part of reverse proxy set up. Do you think it's too > restrictive/perspective? Or do you know of some use-case where a reverse > proxy wouldn't know/trust the servers that it sits in front of? > > On Mon, Jul 17, 2017 at 12:37 PM, Piotr Sikora > wrote: >> >> Hey Brian, >> looks good, thanks for working on that! >> >> One question: >> >> > Reverse proxies SHOULD only add the headers to requests that are >> > forwarded to trusted backend servers. >> >> Why? What's the attack vector, security and/or privacy implications here? >> >> Best regards, >> Piotr Sikora >> >> On Fri, Jul 14, 2017 at 6:59 PM, Brian Campbell >> wrote: >> > Just a not-so-subtle reminder that HTTPS Token Binding with TLS >> > Terminating >> > Reverse Proxies is one of the agenda items for Monday's meeting in >> > Prague >> > and it would be great if there was some familiarity with it going into >> > the >> > meeting. It's relativity short as drafts go, if you're looking for >> > something >> > to read en route to the meeting: >> > https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-00 >> > >> > CONFIDENTIALITY NOTICE: This email may contain confidential and >> > privileged >> > material for the sole use of the intended recipient(s). Any review, use, >> > distribution or disclosure by others is strictly prohibited. If you >> > have >> > received this communication in error, please notify the sender >> > immediately >> > by e-mail and delete the message and any file attachments from your >> > computer. Thank you. >> > _______________________________________________ >> > Unbearable mailing list >> > Unbearable@ietf.org >> > https://www.ietf.org/mailman/listinfo/unbearable >> > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you. From nobody Mon Jul 17 05:30:40 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C257C131B6C for ; Mon, 17 Jul 2017 05:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_UbZwuSE8TV for ; Mon, 17 Jul 2017 05:30:16 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 4DAE8131668 for ; Mon, 17 Jul 2017 05:30:11 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id q85so75816587pfq.1 for ; Mon, 17 Jul 2017 05:30:11 -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=v90piOS4TF2AyIUrN+iWIL6PxNn5WfuEOf8XpdA1XN4=; b=Wy1jmOCbSZLOEPb9JLcDr96icC69V+Jv6DTti5ufjqv1G2Dr+JMCuBqeqbI6MoS9Ib mWExVEqvJqAcrp34uMf702VApFFhpRipNoxD4id6DFzidboXAfsxZvgyv5UbgXLSCepE XSt4tPBxAfUHzBjOEBUapknbm9Ufx4SEOnnCQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v90piOS4TF2AyIUrN+iWIL6PxNn5WfuEOf8XpdA1XN4=; b=BGhsobG39+5HEfC3IEgKil2gEKy2gaK0T4Q9sbgSy38pPwUujKkhYeNFaFqwddmC+M ciAA0SSD30mR9ch+8pf4nx2S0kPe/PyPVUOdwCuyJjvWUBsiMPbAKsRwFsoI6mwrtTGG xumi0dlnlwNdjrF5bkrFot1fOD1DZrchTXEbj3jNKM0STEKhM1WC82Xsz7F2L5ZBIl/L gxLyQuSHYiLNdcsgue0qGT3lb/+C1gPow8A/dOZUGLaAVlVsI7esZmRdRaiWy6QbEnsh rRJrPik7o1rBDdnXu4DMmUuFCW2FlLYmKdT6PwHA2CQvT95wbAmxvqD3+b/xKuj5zubA UWpg== X-Gm-Message-State: AIVw111W6dhSy5nJ4vWNZlLuC/SL6bJ59S2gJ3iWOn8aWk5S4LqoFfh6 hH9/8B7ga5rx04otpOnnDHKdRTXdvzdapktaFTWJqJsWcN8qD+jMmSglPHqn/w6xMJ9eAkQSUzt kcVx5LDSoCDY= X-Received: by 10.98.217.10 with SMTP id s10mr978898pfg.204.1500294610820; Mon, 17 Jul 2017 05:30:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Mon, 17 Jul 2017 05:29:40 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 17 Jul 2017 14:29:40 +0200 Message-ID: To: Piotr Sikora Cc: IETF Tokbind WG Content-Type: multipart/alternative; boundary="f403045cc3a2563dc00554828fc9" Archived-At: Subject: Re: [Unbearable] HTTPS Token Binding with TLS Terminating Reverse Proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 12:30:25 -0000 --f403045cc3a2563dc00554828fc9 Content-Type: text/plain; charset="UTF-8" For any given domain, a CDN would know the origin server(s) where it should forward requests it cannot fulfill, right? That's what I was trying to get at in the statement in the draft - that the reverse proxy only dispatch requests to origin sever(s) known/configured to be associated with the domain of the original request. Perhaps "trust" isn't the right word and that sentence can be reworded to be more reflective of that? Or is such a restriction/requirement so implicit in the deployment of any reverse proxy so doesn't need any treatment in this document? On Mon, Jul 17, 2017 at 1:18 PM, Piotr Sikora wrote: > Hey Brian, > from the CDN point of view, all backend servers are untrusted, but I > don't see any reason why CDNs shouldn't forward > Provided-Token-Binding-ID to the origin servers. > > Also, Token Binding is supposed to protect Cookies (among other > things), which don't have such restriction, so this seems unnecessary. > > Best regards, > Piotr Sikora > > On Mon, Jul 17, 2017 at 12:53 PM, Brian Campbell > wrote: > > To be honest, I didn't have a specific attack vector or security/privacy > > implication in mind around that. It just seemed like something that > should > > generally be part of reverse proxy set up. Do you think it's too > > restrictive/perspective? Or do you know of some use-case where a reverse > > proxy wouldn't know/trust the servers that it sits in front of? > > > > On Mon, Jul 17, 2017 at 12:37 PM, Piotr Sikora > > wrote: > >> > >> Hey Brian, > >> looks good, thanks for working on that! > >> > >> One question: > >> > >> > Reverse proxies SHOULD only add the headers to requests that are > >> > forwarded to trusted backend servers. > >> > >> Why? What's the attack vector, security and/or privacy implications > here? > >> > >> Best regards, > >> Piotr Sikora > >> > >> On Fri, Jul 14, 2017 at 6:59 PM, Brian Campbell > >> wrote: > >> > Just a not-so-subtle reminder that HTTPS Token Binding with TLS > >> > Terminating > >> > Reverse Proxies is one of the agenda items for Monday's meeting in > >> > Prague > >> > and it would be great if there was some familiarity with it going into > >> > the > >> > meeting. It's relativity short as drafts go, if you're looking for > >> > something > >> > to read en route to the meeting: > >> > https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-00 > >> > > >> > CONFIDENTIALITY NOTICE: This email may contain confidential and > >> > privileged > >> > material for the sole use of the intended recipient(s). Any review, > use, > >> > distribution or disclosure by others is strictly prohibited. If you > >> > have > >> > received this communication in error, please notify the sender > >> > immediately > >> > by e-mail and delete the message and any file attachments from your > >> > computer. Thank you. > >> > _______________________________________________ > >> > Unbearable mailing list > >> > Unbearable@ietf.org > >> > https://www.ietf.org/mailman/listinfo/unbearable > >> > > > > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged > > material for the sole use of the intended recipient(s). Any review, use, > > distribution or disclosure by others is strictly prohibited. If you have > > received this communication in error, please notify the sender > immediately > > by e-mail and delete the message and any file attachments from your > > computer. Thank you. > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --f403045cc3a2563dc00554828fc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For any given domain, a CDN would know the origin ser= ver(s) where it should forward requests it cannot fulfill, right?

T= hat's what I was trying to get at in the statement in the draft - that = the reverse proxy only dispatch requests to origin sever(s) known/configure= d to be associated with the domain of the original request. Perhaps "t= rust" isn't the right word and that sentence can be reworded to be= more reflective of that? Or is such a restriction/requirement so implicit = in the deployment of any reverse proxy so doesn't need any treatment in= this document?

On Mon, Jul 17, 2017 at 1:18 PM, Piotr Sikora <piotr= sikora@google.com> wrote:
H= ey Brian,
from the CDN point of view, all backend servers are untrusted, but I
don't see any reason why CDNs shouldn't forward
Provided-Token-Binding-ID to the origin servers.

Also, Token Binding is supposed to protect Cookies (among other
things), which don't have such restriction, so this seems unnecessary.<= br>
Best regards,
Piotr Sikora

On Mon, Jul 17, 2017 at 12:53 PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:
> To be honest, I didn't have a specific attack vector or security/p= rivacy
> implication in mind around that. It just seemed like something that sh= ould
> generally be part of reverse proxy set up. Do you think it's too > restrictive/perspective? Or do you know of some use-case where a rever= se
> proxy wouldn't know/trust the servers that it sits in front of? >
> On Mon, Jul 17, 2017 at 12:37 PM, Piotr Sikora <piotrsikora@google.com>
> wrote:
>>
>> Hey Brian,
>> looks good, thanks for working on that!
>>
>> One question:
>>
>> >=C2=A0 =C2=A0Reverse proxies SHOULD only add the headers to re= quests that are
>> >=C2=A0 =C2=A0forwarded to trusted backend servers.
>>
>> Why? What's the attack vector, security and/or privacy implica= tions here?
>>
>> Best regards,
>> Piotr Sikora
>>
>> On Fri, Jul 14, 2017 at 6:59 PM, Brian Campbell
>> <bcampbell@pingid= entity.com> wrote:
>> > Just a not-so-subtle reminder that HTTPS Token Binding with T= LS
>> > Terminating
>> > Reverse Proxies is one of the agenda items for Monday's m= eeting in
>> > Prague
>> > and it would be great if there was some familiarity with it g= oing into
>> > the
>> > meeting. It's relativity short as drafts go, if you'r= e looking for
>> > something
>> > to read en route to the meeting:
>> > https://tools.ietf.org/html/= draft-campbell-tokbind-ttrp-00
>> >
>> > CONFIDENTIALITY NOTICE: This email may contain confidential a= nd
>> > privileged
>> > material for the sole use of the intended recipient(s). Any r= eview, use,
>> > distribution or disclosure by others is strictly prohibited.= =C2=A0 If you
>> > have
>> > received this communication in error, please notify the sende= r
>> > immediately
>> > by e-mail and delete the message and any file attachments fro= m your
>> > computer. Thank you.
>> > _______________________________________________
>> > Unbearable mailing list
>> > Unbearable@ietf.org
>> > https://www.ietf.org/mailman/list= info/unbearable
>> >
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged
> material for the sole use of the intended recipient(s). Any review, us= e,
> distribution or disclosure by others is strictly prohibited.=C2=A0 If = you have
> received this communication in error, please notify the sender immedia= tely
> by e-mail and delete the message and any file attachments from your > computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --f403045cc3a2563dc00554828fc9-- From nobody Mon Jul 17 06:35:17 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3DF131BA9 for ; Mon, 17 Jul 2017 06:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgzMeOpB2UL5 for ; Mon, 17 Jul 2017 06:35:13 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 AE2C9131B9A for ; Mon, 17 Jul 2017 06:35:13 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id b64so24238782uab.0 for ; Mon, 17 Jul 2017 06:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MESW+WttgoZI9/Ls5tvKjBM/Ai9Bj6x6YHUyzi4rTsA=; b=ZQffXkWvfo5atDu7qdoFFMsf1iQRSZcHM7qZv7rxlLhc1K/2mk71tYeTRqrEJ7+0TW OcZfldx4b+Uc/fTiFP+K0nn9A0/MULCBqlMWJWJbSufsPv+AO8axLMi76EBAVPav77eK YnF0oXHY0xy5MtAevlLmCtomlBoLGnyC6r78xNP+8TnCfveJiIgw2DkcvOLKF3B1cfV1 WKdnWytD1Xxzmll1p2E6aW+C/duCb5K5m6aq6QOca9fzyVwazcEqyWMOAL8bUu6wsoJ4 KFeuTwpCOAxochcM1gD6nDV3t6vBGWolumHoDVAUuCr+WnQjr3UN5YSDQyp0c5E9TZ6T qQYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MESW+WttgoZI9/Ls5tvKjBM/Ai9Bj6x6YHUyzi4rTsA=; b=n8fPalglNnCC9cx5GaULFLV1Y939rMU95AAmQNIf1g3Cv54JhWRZ/ucVfFKrcsHlti d437DkMBy9NKS7r5qmZ5YSLeCG+oK8pqgLdzISqmmYKRLZrPWZJw7jVj7yC2BcwqRoWl wCFEYRcfwcvUCcdILmY4nUURwcyg0TwhF0psm2YPk5RM6GFjF1Sbyf6xEN8QK3tozO55 gLaoh+r7V3D3SYxzlQ0U9BYS4eyHEPwdGhT/L1OaQOB8GAbigrYXZKYB2fSW/ZkG0zv8 zlTaImbn/W02TgGq8Aud0nI/PdH4369+0aofZbiy1P0fiQRsZ3XAKKbOh5sw6y6CC/Fl a+kA== X-Gm-Message-State: AIVw111HQ6IFkL6qx0daMclUUuy3FbyD8w/HI8VZxXXYfLVwSAieZquR 5IcAU9KwtwnsuHwE1cToaJqsVRNXnyMr X-Received: by 10.159.49.19 with SMTP id m19mr12620478uab.46.1500298512436; Mon, 17 Jul 2017 06:35:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.176.67 with HTTP; Mon, 17 Jul 2017 06:35:11 -0700 (PDT) In-Reply-To: References: From: Piotr Sikora Date: Mon, 17 Jul 2017 15:35:11 +0200 Message-ID: To: Brian Campbell Cc: IETF Tokbind WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Unbearable] HTTPS Token Binding with TLS Terminating Reverse Proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 13:35:16 -0000 Well, it's kind of given that requests are sent only to backends that are configured for a particular domain. That applies to whole requests, and not only to Provided-Token-Binding-ID header, so I think this is unnecessary restriction that will only confuse readers. Best regards, Piotr Sikora On Mon, Jul 17, 2017 at 2:29 PM, Brian Campbell wrote: > For any given domain, a CDN would know the origin server(s) where it should > forward requests it cannot fulfill, right? > > That's what I was trying to get at in the statement in the draft - that the > reverse proxy only dispatch requests to origin sever(s) known/configured to > be associated with the domain of the original request. Perhaps "trust" isn't > the right word and that sentence can be reworded to be more reflective of > that? Or is such a restriction/requirement so implicit in the deployment of > any reverse proxy so doesn't need any treatment in this document? > > On Mon, Jul 17, 2017 at 1:18 PM, Piotr Sikora > wrote: >> >> Hey Brian, >> from the CDN point of view, all backend servers are untrusted, but I >> don't see any reason why CDNs shouldn't forward >> Provided-Token-Binding-ID to the origin servers. >> >> Also, Token Binding is supposed to protect Cookies (among other >> things), which don't have such restriction, so this seems unnecessary. >> >> Best regards, >> Piotr Sikora >> >> On Mon, Jul 17, 2017 at 12:53 PM, Brian Campbell >> wrote: >> > To be honest, I didn't have a specific attack vector or security/privacy >> > implication in mind around that. It just seemed like something that >> > should >> > generally be part of reverse proxy set up. Do you think it's too >> > restrictive/perspective? Or do you know of some use-case where a reverse >> > proxy wouldn't know/trust the servers that it sits in front of? >> > >> > On Mon, Jul 17, 2017 at 12:37 PM, Piotr Sikora >> > wrote: >> >> >> >> Hey Brian, >> >> looks good, thanks for working on that! >> >> >> >> One question: >> >> >> >> > Reverse proxies SHOULD only add the headers to requests that are >> >> > forwarded to trusted backend servers. >> >> >> >> Why? What's the attack vector, security and/or privacy implications >> >> here? >> >> >> >> Best regards, >> >> Piotr Sikora >> >> >> >> On Fri, Jul 14, 2017 at 6:59 PM, Brian Campbell >> >> wrote: >> >> > Just a not-so-subtle reminder that HTTPS Token Binding with TLS >> >> > Terminating >> >> > Reverse Proxies is one of the agenda items for Monday's meeting in >> >> > Prague >> >> > and it would be great if there was some familiarity with it going >> >> > into >> >> > the >> >> > meeting. It's relativity short as drafts go, if you're looking for >> >> > something >> >> > to read en route to the meeting: >> >> > https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-00 >> >> > >> >> > CONFIDENTIALITY NOTICE: This email may contain confidential and >> >> > privileged >> >> > material for the sole use of the intended recipient(s). Any review, >> >> > use, >> >> > distribution or disclosure by others is strictly prohibited. If you >> >> > have >> >> > received this communication in error, please notify the sender >> >> > immediately >> >> > by e-mail and delete the message and any file attachments from your >> >> > computer. Thank you. >> >> > _______________________________________________ >> >> > Unbearable mailing list >> >> > Unbearable@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/unbearable >> >> > >> > >> > >> > >> > CONFIDENTIALITY NOTICE: This email may contain confidential and >> > privileged >> > material for the sole use of the intended recipient(s). Any review, use, >> > distribution or disclosure by others is strictly prohibited. If you >> > have >> > received this communication in error, please notify the sender >> > immediately >> > by e-mail and delete the message and any file attachments from your >> > computer. Thank you. > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you. From nobody Mon Jul 17 08:19:00 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DD3131C72 for ; Mon, 17 Jul 2017 08:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 X_TnHEAfanLM for ; Mon, 17 Jul 2017 08:18:51 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83CAC131C65 for ; Mon, 17 Jul 2017 08:18:51 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id v193so48750381ywg.2 for ; Mon, 17 Jul 2017 08:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=a1QZtylsJaAKOOi4Koi6Bj2w2fMkgUxiyUrh71JEAjE=; b=MyjhgOPN46LzPjyAqZhM/mUd2mTataT8srAmTHuXvuBv01si//+5SvlXGjc4DbzOt5 SKzslyFIa9IMf29Ladappw7MpqpSRgo5LLB3u6+FqQCQrOYIiAYPMmi++6eh4UFf/QwL F+LoKjY+xzT6gf4pHhkHoJIztXh8iPRp5cfGYFpFHdSI7xx7L4sTKMCNQMRUuQHOvhSn fyKiBNxzOqe96/eUUFq6XHOoRLVbFeFpTLvafCzMGGxQYc/8ud0w4NFQXd+evYqcZ3KT PWyx23Ap3ThKoG2O4neFdMiPnp/WcnvHZNBJ33ZGB87D2jp+48ZQDJFfHokVxKgLRXef CZig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=a1QZtylsJaAKOOi4Koi6Bj2w2fMkgUxiyUrh71JEAjE=; b=rhQgBBGJxkYVIvkMCq3//N4KprkfYZIwZOVqvXU0OijU9qfpPt3pOksoLJmt1ID9v/ 1ypsQdjBqcJFtCTrk7Ky2s0RRDv7kuJ9hMN+oI7RkQ6eWv2sCf9zr4u2rk9TaMrzvLRG HZM3jer9ttFdYBVaqmktPfLGNYb9aaTTMFzU4JrEjFbdfR4aZRNE6ArXSFBQp3vlK0xl ASsUHgSh9PvTEPTrKrBS8Q8b1gqa7C0F0XtBgukjLuzB/w37KZxg2H84d9LBQ8g/qFGB ZQLLhUZaW/b7WkJ2BLwRy16YO1+3+o0gJBt87g700beteqZVZtKBStSb2MyoPUfY04ax 5kUA== X-Gm-Message-State: AIVw112AxJdhPslSGbOVFeCabBfB0MLw/9azkr4RDU0Mu0NxokgxOAKo GX+IO5ZPgtacKjc8zpAp/pgSqjQU4fMc X-Received: by 10.129.156.2 with SMTP id t2mr16537495ywg.44.1500304730543; Mon, 17 Jul 2017 08:18:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Mon, 17 Jul 2017 08:18:10 -0700 (PDT) From: Eric Rescorla Date: Mon, 17 Jul 2017 08:18:10 -0700 Message-ID: To: HTTP Working Group , IETF Tokbind WG Content-Type: multipart/alternative; boundary="94eb2c0b789284f6fe055484eabc" Archived-At: Subject: [Unbearable] Dealing with header injection through reverse proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 15:18:54 -0000 --94eb2c0b789284f6fe055484eabc Content-Type: text/plain; charset="UTF-8" i folks, We had a discussion today in TOKBIND about handling security-sensitive indications in HTTP headers (this came up in the context of https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-01). The setting here is that you have a network with a TLS reverse proxy serving the origin server, and the TLS proxy is responsible for doing some security check and telling the server about it. E.g., Client Proxy Server <--- TLS w/ client auth ---> <----- HTTP with cert ---> The client does TLS client authentication with the proxy and then passes the certificate to the back-end server in an injected HTTP header (e.g., X-Client-Certificate). In order for this to be secure, the proxy has to *strip* any security sensitive headers sent by the client. Otherwise, the client could inject their own headers that would appear to come from the proxy. Obviously, this design doesn't fail safe if the proxy fails to strip the headers. One way in which this can happen is if you have a large network of load balancers fronting a server network and you somehow incompletely misconfigure either the servers or the proxies, so that a server which supports this mechanism ends up behind a proxy which does not (and hence does not strip the headers). So, it would be nice to do something better that wasn't too heavyweight, especailly as a general solution. One natural design is simply to have a shared key between the proxy and the server. In that case, it's easy to demonstrate that the header is injected, as in [0][1] X-Client-Certificate: , The obvious objection to this design is that it requires you to establish the shared key, and people were concerned about having to configure it into the proxy. I'm aware of a number of designs here: - Configure it via some sort of remote configuration mechanism. - The proxy could send it to the server on its first request (might require some trickery on the server). - If you have a TLS channel between Proxy and Server you can use a TLS exporter. - If you have a H2 connection between the two, you can have the server provide it in a settings frame. - Use a signature by the proxy using its private key over something e.g., S(K, "Token binding"). If you use a mostly fixed string, then the server just needs to verify it once. Do people have other thoughts on this problem? Other good ways to establish the key? Other ideas for how to address it? -Ekr [0] I'd originally suggested HMACing, but that's actually not necessary, though obviously stronger. [1] Note that you could have a generic solution, like a header which listed all the injected headers, but with the same security mechanism. --94eb2c0b789284f6fe055484eabc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
i folks,

We had a discussion= today in TOKBIND about handling security-sensitive
indications i= n HTTP headers (this came up in the context of
setting here= is that you have a network with a TLS reverse proxy
serving the = origin server, and the TLS proxy is responsible for doing
some se= curity check and telling the server about it. E.g.,

=C2=A0 =C2=A0 Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Proxy =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Server
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2= =A0 <--- TLS w/ client auth ---> <----- HTTP with cert --->

The client does TLS client authentication with the pr= oxy and then
passes the certificate to the back-end server in an = injected HTTP
header (e.g., X-Client-Certificate). In order for t= his to be secure,
the proxy has to *strip* any security sensitive= headers sent by the
client. Otherwise, the client could inject t= heir own headers that
would appear to come from the proxy.
<= div>
Obviously, this design doesn't fail safe if the prox= y fails to
strip the headers. One way in which this can happen is= if you
have a large network of load balancers fronting a server = network
and you somehow incompletely misconfigure either the serv= ers
or the proxies, so that a server which supports this mechanis= m
ends up behind a proxy which does not (and hence does not strip=
the headers). So, it would be nice to do something better that
wasn't too heavyweight, especailly as a general solution.

One natural design is simply to have a shared key betw= een the
proxy and the server. In that case, it's easy to demo= nstrate
that the header is injected, as in [0][1]

<= /div>
=C2=A0 =C2=A0X-Client-Certificate: <key>, <certificate&g= t;

The obvious objection to this design is that it= requires you to
establish the shared key, and people were concer= ned about having to
configure it into the proxy. I'm aware of= a number of designs here:

- Configure it via some= sort of remote configuration mechanism.
- The proxy could send i= t to the server on its first request
=C2=A0 (might require some t= rickery on the server).
- If you have a TLS channel between Proxy= and Server you can
=C2=A0 use a TLS exporter.
- If you= have a H2 connection between the two, you can have the
=C2=A0 se= rver provide it in a settings frame.
- Use a signature by the pro= xy using its private key over something
=C2=A0 e.g., S(K, "T= oken binding"). If you use a mostly fixed string,
=C2=A0 the= n the server just needs to verify it once.

Do peop= le have other thoughts on this problem? Other good ways to
establ= ish the key? Other ideas for how to address it?

-E= kr


[0] I'd originally suggested= HMACing, but that's actually not
necessary, though obviously= stronger.

[1] Note that you could have a generic = solution, like a header which
listed all the injected headers, bu= t with the same security mechanism.

--94eb2c0b789284f6fe055484eabc-- From nobody Mon Jul 17 08:50:31 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC4912EC12 for ; Mon, 17 Jul 2017 08:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnz9VSER8GNV for ; Mon, 17 Jul 2017 08:50:28 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E937131C7D for ; Mon, 17 Jul 2017 08:50:24 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id f67so88423897wmh.1 for ; Mon, 17 Jul 2017 08:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=1pwQNwg8h3cy+VV1zlLYQjKHzXwoiyJCjHveIuPhbkU=; b=lmyXMzhf+HykbI+1sGdUpoEqXtnIW3MO41Xn2irYZsYkcASC3qt76/4HWtKNfEOMeM eDbM88ZxFIgwt5MO+xQGzXaCdPdYHyaa4IzdY8jMAfIDZcfq3aEuqDyyVLHjIjQ7UdiH C5K91GnKmFq3vivIWJSh2CvevE/Knh3OF9HCw4XOtS+xIsB+mvgXnwhATpu7Epvh0l/G r+fd1hN7NvHndFFZcEag/UoLHSgXxNbtCJuZDiLDQ6LFh3JXX07RZY80fCtYnyNXExNZ 5UZfXUZEXnRw5VSNZ9eTwLVMtP1GVgNoIqz87ZygbyiES7rORzUpnZoz2xBqmqsPkSoB 26TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=1pwQNwg8h3cy+VV1zlLYQjKHzXwoiyJCjHveIuPhbkU=; b=KmPY9qlgy2d4ocblioSZINAIa5uyfq/YYu1/IYFsO1FXcoNNdsqIeKG//5f3hQOR9G up1MB67KpSdLKlyKiF22Jgg/CnHhOQWKqgl5qGqLXI7JKXlgFUVUTqMf35wGxis4/+Q4 xzm2brvF3rNt3QAYUns39SB/UjzXbzna/sCmAs6wxZTAAkwrb1W4+YOAgb8BTMKd8aSF /A8rB0Nhc99qLnv91GioMheXRsIoUTEOie6MgLkQPfhc2zYLLv2PspIGwkbiAWH2Jvas AIDU0gPL2kXsWp9oAoEYuW5OGSKJBQX8friiw6emPBWtnR51or5r/Pngmj4tdwnrp2oU a/wg== X-Gm-Message-State: AIVw113FjFaNcUS4OArEXsjUWqx1DXhSK3mtt17Ev+A9JCuxDYAIwhVf KJr4BU4ktY25AREK0rgxBw== X-Received: by 10.28.181.6 with SMTP id e6mr5312472wmf.25.1500306623041; Mon, 17 Jul 2017 08:50:23 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:fd4d:a3a2:d45d:796b? ([2001:67c:1232:144:fd4d:a3a2:d45d:796b]) by smtp.gmail.com with ESMTPSA id y100sm16112097wmh.7.2017.07.17.08.50.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 08:50:21 -0700 (PDT) To: IETF Tokbind WG From: Leif Johansson Message-ID: <853ba12d-5859-1545-611d-74f0b1fbf533@sunet.se> Date: Mon, 17 Jul 2017 17:50:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] WG adoption of draft-campbell-tokbind-ttrp-00 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 15:50:31 -0000 In the f2f meeting in Prague there was clear consensus to adopt draft-campbell-tokbind-ttrp-00 as draft-ietf-tokbind-ttrp-00 making this a WG document. If anyone on the list disagrees, now is the time to speak up. Cheers Leif & John From nobody Mon Jul 17 09:01:16 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8C0131C91 for ; Mon, 17 Jul 2017 09:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=osu.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zfbsd_eovA4V for ; Mon, 17 Jul 2017 09:01:13 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0094.outbound.protection.outlook.com [104.47.34.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC3A8131C6F for ; Mon, 17 Jul 2017 09:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osu.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SCEpj9XYqfcpkJ3IjLRvcBQVoS0GJzmdy3HXCxSH4ic=; b=ClmuKYUNs73o4j6XjksK/5LJg3QPK1D/QxlOL5Amx2x2xzZROEz3KeoD4JEzj772b8wbV3Bx5646ichvBy5bzb8U+rjVTNMrVoq1TNZNsyfGPW+HcbrBS2g5NDuG1eib4tWNgShJl4yFEh6fJvzhQpxky+zUrhTZCHswYa6R2JU= Received: from MWHPR01CA0026.prod.exchangelabs.com (10.172.172.140) by CY1PR0101MB0924.prod.exchangelabs.com (10.160.139.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 16:01:11 +0000 Received: from CO1NAM05FT024.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::201) by MWHPR01CA0026.outlook.office365.com (2603:10b6:300:101::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13 via Frontend Transport; Mon, 17 Jul 2017 16:01:11 +0000 Authentication-Results: spf=pass (sender IP is 128.146.138.9) smtp.mailfrom=osu.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=osu.edu; Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 128.146.138.9 as permitted sender) receiver=protection.outlook.com; client-ip=128.146.138.9; helo=cio-socc-esr03.osuad.osu.edu; Received: from cio-socc-esr03.osuad.osu.edu (128.146.138.9) by CO1NAM05FT024.mail.protection.outlook.com (10.152.96.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1261.15 via Frontend Transport; Mon, 17 Jul 2017 16:01:11 +0000 Received: from CIO-TNC-HT06.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1.2 with cipher AES256-SHA256 (256/256 bits)) (No client certificate requested) by cio-socc-esr03.osuad.osu.edu (Postfix) with ESMTPS id 46B8399; Mon, 17 Jul 2017 12:01:10 -0400 (EDT) Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.03.0319.002; Mon, 17 Jul 2017 12:01:10 -0400 From: "Cantor, Scott" To: Eric Rescorla , IETF Tokbind WG Thread-Topic: [Unbearable] Dealing with header injection through reverse proxies Thread-Index: AQHS/xADE0gv6ETK2EqMkQxjDxHEtKJYLPbQ Date: Mon, 17 Jul 2017 16:01:08 +0000 Message-ID: <9846A6064BD102419D06814DD0D78DE13BCACE34@CIO-TNC-D2MBX02.osuad.osu.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.94.228] x-header-sapphire: true Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:128.146.138.9; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39400400002)(39840400002)(39850400002)(39410400002)(39450400003)(2980300002)(438002)(189002)(199003)(2920100001)(189998001)(14454004)(50466002)(55846006)(86362001)(2900100001)(478600001)(75432002)(8936002)(109096001)(356003)(5660300001)(106466001)(88552002)(229853002)(6246003)(66066001)(2950100002)(47776003)(38730400002)(5250100002)(2906002)(50986999)(76176999)(54356999)(55016002)(626005)(7696004)(8676002)(23676002)(305945005)(33656002)(7736002)(7596002)(6116002)(102836003)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0101MB0924; H:cio-socc-esr03.osuad.osu.edu; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT024; 1:T3NJ6BzItaKCHYKmu7aH4itQr6cAZ2YjnPWL/McMs4qTgAB6y4AK/bZH5rNNwujgfPGSzHarLxdrP8Tcje7dmL0U6A8jmfuuXQDcFQSh6nrWX6Y81h91fY9D07fyTUAIfbDbYvDxa5+p4L9ZqZRfix28lIDNSiBFp2TpQuSUtXBhoZRkooy6MOuGHpaYQZ0gSy5g4ZcfIQCtvOPVQ1rERQXf9ab4wzGx1M/YCMgNDNyw+9jvYBHqw0lmw456M33MfGQjH3arvWu2/o3ZjiFqV3sA8vurYcOINwJEcev1Vkv3zVx1hjwayV7fxflwE4PNavq8oiApIzc3i01AdqisAXN4Z6rUtDNmX5QVhdxV8ah91OnGNIurx7yNu19fwdHR3gEPCNWLXH9El0Zv1GuC6xttAoGFz1nsVJs2orsoWrb+z98aFpa5BDpaTlv0LJAhKeh5y7xN1eKNdWfWhekTGC3Bbh50kuKJ8dPqwdadIocxNvsRmboPxhSDrqcZ6j3I0G5h0Yzr78jopLFT+agoOwUkGUPT2LxUwHJKKAQiebt7Yv/Qe4mcASRdZXaiOZwc+dC2aGnllhMf1b6DBnQ9L5S1XEuBhX9+PY92cEfZs+RAvYXBXboNderQ3lfHRG7kyBU3VMA71sCBRnYzi+42HCvm1kGSXbKS2hm6hfUFFfN/NoRHqc2GnpNpj9YHPmAAvMsACb3eZ9jMJHRyzWrVo5lexWvyipN6yfWR3qKsUZ7HMjdyDkdC8QpGtn45wUelaFD5sEmd8WtEn6DPl/0VVBwSLscZsQFvJ2s1/JZbXiDCf6CKYxXZy5Pr+Vl8v2HRFzx04pkkqWPZFSxjAn2YZWUpQqCZbGAvq2wIXgUOFb06dQh3/www9U0uaGA7OEWlAU1AjD0hsU2/UoHSaH2DBw== X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1a54669d-9538-4fb1-592a-08d4cd2d0b7c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(8251501002)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR0101MB0924; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjAxMDFNQjA5MjQ7Mzpoem9HdW9TeTlrcVBhL3VrRFVrQ3dnbEln?= =?utf-8?B?aW1oVlloMS8zS0hJSWtySU4zRHovRlY1dmV5TFFpUmFoMnA3MWJZdlRzYTJM?= =?utf-8?B?OG1WQWhWU2tHdEZQSXZ0eVVVYnBZaGR5M2w4YWNYb1dRY05jd01jMDB2K1dK?= =?utf-8?B?Z2dGUG9IbGpHTjQ5ckZOWnNKQlFGVWpXVTFIclp2azFBWmJlOTlPQWswY2ZI?= =?utf-8?B?ZEg4MXFGdU1zNXRjaVVPSDE3TDltWDA2RkZ2S3FsZFU0V2c1b25UYUVvOVpN?= =?utf-8?B?aFlneFpMS2pKWnNEeDdPeEVJSmRYSEVPeU42S1Y4RnpvZ09NWEdQbVByNGpR?= =?utf-8?B?WmpVeTNQdDlNa1NtNFl2UlhHNm9yL3Y0WHNBK1c4a0pua1NGUkx2ZXA4a2Q4?= =?utf-8?B?WTJZamUrYXRHUVA3RGFObjJnRVRuYy9xaVI1Sm5DUjdJdC9iZHhBaE5SQ0w3?= =?utf-8?B?SHVZK05UTzBQSkUvVEFwU1VJTkJkQ0loTTFOd0JrSXRmOURSYzAyczBDZTc4?= =?utf-8?B?V2RZSzJ5eURmT0ppMW9PdHIyWHYwV1ZEaElTNGJOa1loVGRLUHJxS1UzYnJT?= =?utf-8?B?R3VJSFBIQjY3eUlZb01vNmI0dE9wNk9QdkxWQXloUkNvNVBzdDVaeWxxZ1l4?= =?utf-8?B?Z1lpVHlnWUt5WFp5a0Z1WndZQ3RCRW5GSktoUXQ3TkFHSk53cXJGZHRSQ2dU?= =?utf-8?B?T291U2I5ZCtWL3llVmw4Z0hCaFFPODZjVDhrTWwyQUNCV3lCTnJ5TGthQnNP?= =?utf-8?B?WGlSbGg3K09tM0Q2VGNla2lheUd1aFFIbnlWQWVUbDgwMlVzRTY5NzRFK2t1?= =?utf-8?B?c0NtMng3cGNjVTYzOStJWnc4ZG1iL2V6aUJWVzBLazZ6d1FYOE91SmxHT0VT?= =?utf-8?B?cWFLNjFMeVZGcGdkUjFFS1J1Q0lqenN3ZGNCV2Y4cytEdmdwYktjV2dQajJu?= =?utf-8?B?aW5WZEtYc1VBNml3Z0hZMkxjV1RhMEYxallRNXo1VmI1VmZOMnZpTENzUzla?= =?utf-8?B?LzdWYlhUMldsMjJDNklOOXBlelZ6b3dsZW40dXRiVXVXd3BXaVYvYW0wZENs?= =?utf-8?B?TFk0enY0eUh4VTErVmo2bEcySEpacEVKWUpqSE1FWWdlUTdRQXVaUUgzMlRv?= =?utf-8?B?ZGFWVkV4bEJzR1BlT3BucVV0emVzcWhWdWhXNGN4ZTJwWFVhNHQvNEprdjNk?= =?utf-8?B?aUVlUnBqOUU3cWRuUkJmYjFpUTdFcXRiT3RqM0xxbDYva0hFdm00ZGdnWlFE?= =?utf-8?B?NkpCMlhSd3JiMTVQaStnVHVhTVhzRS9mbkxWS3ROSURjRWJwUEt6ZHZlcEZl?= =?utf-8?B?Y2lhUVZxTHhSRU93PT0=?= X-MS-TrafficTypeDiagnostic: CY1PR0101MB0924: X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB0924; 25:k+f0SyHicmzwmyvplf9uwgexQuv2VAeOfW6w5B74LDiyTLeCKW6ACML3WGLrnXTFM7tXwmdLK+mdMeSdXQYAZteQJi3JA0OJv7ZrW++/KLIkdEhVkbcwtB+0wEAM57x78xMfODmRr9rSe738jPGPLFmP/v1W+bsvaOrPvkKgGxFLstkEEVmUJwDL0wMzgyyAmOrj/JQyXAPRre5NO6i34PZZc4E0TuAaJRVurr7WLJ+/Sx/c3rQPKgEHq5LUFgWzQNYFy9IepXV4Xcf2uHOKouvpsAf/WMEEs1TocBS0wcdML5kWC1I/FF1M9MTh1SxoczfNMys7WQInc5a55v4CJ9kc2q8Szn9PHqP6+wnM2f2afZfMofO1UUFvvv1vYoRJEWlDL5Rh1nwKm+8BjzDL67OY7gjsws2KhKdGGa/hj8kJwb775MknLIyXb7XuWYjZDeHonwKR0UEEnVKi4c2ZnqFP6zj/upeK7t9XBH34U+lscSmxKI7P4DUWO60XgUVKlngyJ05NTGN/yDMKU3sEKHZiwntYsD35amKxmXE8ZNj0rGjrMkDMMs27dfxfyFY1OsdQydVMBuyylYjd+u63S8Ty4xT86CBMZ1yhnri2oBfEEtWGUjNZ+KlN5QWGzgWXyReSV6xKwOwz9DBS9dlnl/mGg2bt4qk+AZ1sn21DPwXfFO+XVVwygx5QZNzbMcmFxXZTy7Va/VrbBM51MC2q81sthffv3r6ikmU1DOhh2ZJ7jmySFDbeaEuFe6BMCePeArj1ViZ3SuzpGvfxe3WzclLsTPgU+9eofuEF/dirg/k7OHLvxwO+Hv/sl/TOEGnvOiIQ5vrL+0B1dUmh5tILwQ5v2susl5YjN6HWLXKyGAPRX2MILLpTPCEuJ0JCyuC0YwTm+pZ+1yGmPh7vw9CCFq5DBIwU5tItzpGjFGf1Td8= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB0924; 31:4TuDBVOqq7+BtAcPYvWUs05ALASRAah4lnXUk+vtH1KchU9F3uBXmpS+qRaw+f2aKiY+6bo43mUyZgxJFEBRLJdWg9L6QhFTVpRDw65Ffj1yk+AhsavzwrrsE+GgaT4MP9ZPbx9ZitskWxCExq5/Qdj8H6U71TAro2OdC/xxVBHv/IGdaSWBSznxjrAdWIeeuA0L6uySAAs18XCjaQgH06THZ9UNBPazeZdgko5Ae1SAlc6YmlQP/3lAkKFjMYKrofDiKtqEHQjq3MACkAIIH5HJefShGJppeMPc/l0Y6O5Bv3IPCTyiVA4KouMEDYIsutvDpVl9tRejL/asevBj85NG9P0V/Qh9Q/ecv/ji/D0ff5zH7yTlsqFdI2khJtqmbeN1nlolSsmEsppsepkTb1TPrOKlJxQAGgCFLE2wDvE7DTHEWePUo6761qvwjOmT4lU0yGPyomJXvj1m/7KtVA107Q9UTrBZW1du4w7qnCVugxoIn3MBq1ENR5xtHARNStNORNxERX4k+OsuSoO+STNulu+2kTJ+D6nGaUoCFHdGiHDfopvDVyCm8JWbx+U2ggyzzBl5Nha8jqCMEKDOx/I/+SqZeBQL5rX1O0aKSwF3LDJNzA/NoSVTgDmJzrBblyqKv6Ur+C9rXfDHah1PJ3jA2iK+on0f1um77EJ7JDDJZOkSNrFapMSpEpsSB1jN X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB0924; 20:DNbemSrksy7zwpLIgzbWA8vadvSYCNo0XOE4YO8+DstWrMJKssplMk9U27oLkvALUFsHfXWkERZAFqHoDuSPRk8wxyJ3CMrUyTcmp6rjyTcncDV0b6UqbJdn8yIkFs4gbbLmwYyF0g0UXH5uk68bSBV1Ov3F7RnN6ykzRWTQGWBpDyaxg1+WjnI0Ne0D0go/AOLIiw4F2obWLxWgpkP3kbXp04xP9X6IUI4FqTazg56FLsIdB1wMJw8+JzGyTHoefL/NCUt6y5qEo+Tt0n6dPOdWcRd5WYLvslAvm2rylmJx5AQaRWU/ex7kH5eMu9efdSuYXsGXonX1Pbc1Jb04Ln/C+A6ZBretfJDFApNJQzlNXiaVr2iTk/TJNzZ41Euz85zZcBri6Gzr5qtsHhJkzXBmiWwa4BUQ8rSUCr73IxWuQJoudPGcmOOWL0MlZbCWwJJZz4zP13AbwmrihvhaxYnfQLFQtoD2t1AhPFKGEgVkcdE3uYwmb6DWBiOoTRFV X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(158140799945019); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(2017060910075)(5005006)(13016025)(13018025)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93004095)(10201501046)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0101MB0924; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0101MB0924; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjAxMDFNQjA5MjQ7NDpFbXIvemZZUkVrU0dmSEwwSWtNdVNBSWZu?= =?utf-8?B?eHBtZHhDVy80V0dkN3hQU3VqMERNTktqTUk3WDArRnBtL2hyLzlHTXB1QVU4?= =?utf-8?B?ZGhON3ZsUitlZEx3cXRRN1lEZzBZWkVBTWQxdFRpOEtKSWVYb2phaG9QY081?= =?utf-8?B?WXJoMlR2TU5zbHNkaWFJbXREQ25yWE5HcFlrc0hLZEo0OUxuaXlsckxUY0JO?= =?utf-8?B?aFZ3NnZuWkpSR0kycVRJSnFkWkgyd2V2bEhOSlMwcDlnOXNYL3Z2Vk5OaWZN?= =?utf-8?B?cVZHSUR3SVJsTUszanRTaGxWTk0yUHZiOXVKZjFPNVZxWXdJb0FQVjVaMGNQ?= =?utf-8?B?VFFWYm9zRWxDTkZhOE53MzN1cTN6ZkE3ZWRDRUtWcXB3UDBDSTc2QlhaSktz?= =?utf-8?B?M1FOZ0NOWmRxL2s5ZFl1N09pM25lclR6VzJkbzBLRGxPMUdzTG5tQkhNRndk?= =?utf-8?B?eS9mVTBHc2JGeHRMRjhaeUVDaVJ5Y1hNZXkwVStSU2pReEh2NDg3eHA0dTkr?= =?utf-8?B?ejJ2YTNBS05DZlh2NThyWDhTekxkUWY2NVQ5OTU5b1ZYRmFBWU51QkNldG0x?= =?utf-8?B?dWxNc21MdU5mYzAxTE5Tbnd4ZkVpS1poT0FzdDZVQlhTYkF0d0x4MlZZSTd6?= =?utf-8?B?ajBMNmt3RU5uTG94V2JTUmFCSVloQzhBM2NQR2hwaHU0bTFXbnU1NlE5ZWtr?= =?utf-8?B?RGhacG1mQlhtQnlqWVRjb3VaNWNvSGpUVTltYy9RREt5MjZPakVZakhjbkF5?= =?utf-8?B?TnFIZFk2cHV0VWNNZlNQQ2hsdnlZVm9PZkNXQTV4eExvWWlnUHBuaWdGL1I1?= =?utf-8?B?cDAvdmdkS1NUMU1WTlhPbVZ5ZUxraElZdWFYdExCYWlGZ0laWHg0c205KzM0?= =?utf-8?B?dUYxN3VFZ0pqWUtQV3dTUGlBSkltS3FVM0NIcXRsMDdjdmg0ZzRPWm9yTWVa?= =?utf-8?B?a3pkK2ZQYkVzaXk3SG5qcWZhaTI3WFRlNWUzRlJoRHVibXVXdDZsNmhQSnQ1?= =?utf-8?B?SjRRRU5YcUNWZUlPOUZBUGdxaUdaanloU2RnY0lHaWpBVnNXY24rcENCcElx?= =?utf-8?B?SU52akRRaEpaZFJvczFsNStqZDM2ajRuTUhtOG1BTVV0UVU3QlVPVG1FWDkr?= =?utf-8?B?elJoTWd6Njdxb1YxbnRMQzg1QnAyNm9kclBQZHRRNjBZSzk2R2JBTC8rcm10?= =?utf-8?B?NXlna0R0MzJTMmI5YlNNYXpJc3JVWnVpcmtpUDFaWDBsTDRJK05FQlhibnVB?= =?utf-8?B?YnFPcWFtOHRxODk2WE44MTRKM0hWYkZpZE9mSkkyK1pnUXZvSmpuMGNRS09m?= =?utf-8?B?dXNNNE40czJLNmZubURNOEFwOE9LMmVpejVUTUpjOXdoa2VsWWdSQnp1dmhW?= =?utf-8?B?V2RIb1E4ditwTytOZVR4c2pOMnZ5eER3SzlpWWtLbE5UMmtERFA3NElwR05X?= =?utf-8?B?R2dMSGlrNW1aa1k1amYyWHBaR0t2cWhCUG8wL3ppSnpYTVR4QVovMmJOditV?= =?utf-8?B?akhPdlBLZytJaHkrNFpSdTMwRHd3ZVFzdWtld1AzL0xLcGNicTQ1QTFRb1Fu?= =?utf-8?B?Z2ozM2s0aDlLR09mcktyN0Vwci9MMmNyZjBId040dmFkUkJKT0VQcHc5cGtl?= =?utf-8?B?ZkZzK2FadnhCSnc5YW5Zd2pHQjU4c0V2NmNiN3g1NUc0bnpDY1pkWmlBYndi?= =?utf-8?B?eFQ1QnhIY2ZKSUgxQmFaTDAxblpzMFlGSUoxcmtOWElWdFQrRUlDaHIxNzB5?= =?utf-8?Q?8N6hdc3QNsQgJy4r+unJgRVtyHwsTGo1Uvxsf0=3D?= X-Forefront-PRVS: 0371762FE7 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjAxMDFNQjA5MjQ7MjM6aUNzdGpURVF2M1JGZUIreGw2SGFXTlBj?= =?utf-8?B?dWJYUzYwbTJzenltNFYxZ3hneWQ0RDlrazQvaXlYWXB6N1RqSDBkbkVNZ0g0?= =?utf-8?B?Q1JVMUo3cGtFdGFtbjl4SlR2bXpUSTQvT0JmaUczZWlaU3FyNUV4SVBXTmJm?= =?utf-8?B?SDNNN3ArSXQza0hybm5Mb0l6dTA3VDZwbjVaL1hnRUdUcVRSWS9XQWFLdDFj?= =?utf-8?B?SFZWckkxTW11NjZUaFZqcDRhS2JSaGgzOFl6RDBsM2xvOVRxcXgrM1d0c1gw?= =?utf-8?B?WFpRdyswY1BJck1EckdRcFVaTzRsbkpOaFM0TlJ1ZjJ0aXUwS2hPSlhxS0lX?= =?utf-8?B?eW10TVVCNmdML0xFL2NMQ1l5L3pNcktvb2FnRjl3TFU5a0NuSnBpdy9KNTI1?= =?utf-8?B?bUdURHVYVzRRRXljbHYxRzkxZERpT2JJYVJVOWhUaDNqOTNTaDFqRGtya2tu?= =?utf-8?B?alE5UnRGeFZLVlBXUWpYdW1yNmVTQUNlMllCUG5PODRNSlBPcmlEemcrL0o5?= =?utf-8?B?cDNreXdEUE44NTdseHZFbzNIend3REZFT2xFK1lHYzB0VkhPVGZXTjZzNkpD?= =?utf-8?B?VXorU21jYy90bU1vbkozL1lwSUFBMUtHcUpGUmkzc0hMY0p1ZU9HSTNVb0F6?= =?utf-8?B?cUFlaVpaSDNqUkdoR1lMakdlS1BacXFOVUgyb3J4Nk14NEp6YmFOcFdhLy9J?= =?utf-8?B?QkZEMlkybWkrK0VaWXBpY3htR0dQcW0reldXa3Q2N2E3cWs0UXNpeExidGhj?= =?utf-8?B?d0ZPL2VGRFBBRklhcjlxZ1ZQTVU5VXVTaFJmYjU3aEUvdG11Q0xtdTMvMERu?= =?utf-8?B?d2kvWEVXOENKbll6N0g5UG9MZWM5ZDhJRVBZN3ZiVm85S0VFSzRzc1h2N0Nn?= =?utf-8?B?RGpGTUVERHlyemw1cUNJUVM5cWo4OXp3d3hZVDZyR3JNQ3N5bjJTM3piR3V2?= =?utf-8?B?N0Ezcjk4ZC9HVEVQOGt3OSt3L0V2UGcwaTZPejZNd0Z5bDlSMHo0d0xKcDdy?= =?utf-8?B?WkN2WVFqNGxTbENjK2QrM2pheEVmeUJydnFyVWkyOWZCdDVsbmgvVGJ4Y05q?= =?utf-8?B?Y1JOL3UzVVFJeE5tYzJCN0ZrbnlaaFpneWhUdkU4OHdRWUJrWmYvMGJIMTZX?= =?utf-8?B?ek1uZkgxM05XaXhNdWRyTFdvUjg0Y3R0dHJrc1R0RUdaV2tQUU9QcmJHUjlH?= =?utf-8?B?U0xLRnNLc1Q4ckxqUTJZQWdSejl6WEovU0lPamI2SVViTWs2RS9rVW5RQzFN?= =?utf-8?B?YTdwc0VCTzRMWWx4TTkySkpuWGRYdXJJcDdQYk81QUZIZm9tZytwMGdaSFA3?= =?utf-8?B?Y0JPQWpDVHNjaEpGYlQ2NzY4bkovOU1aeHlhaUtEMy92ZUNnbkFhQkZnbTU5?= =?utf-8?B?cW0vWWpzYmMrRzZpN2JsZlVMcG1RMGNaZjloenhka0lWQkFBcEhIeGxxYjdv?= =?utf-8?B?N3Nzd0JoRHRvM0NlSjNZY0pMbTRqTDlUeGVKUi93QUlCeXZoci83S1pabFk5?= =?utf-8?B?eGhWK2E0aFdZd3gvSEhiS2FSOWk4WEptVWFSd3hpNVpnTkVYSFVlZWhVdTEy?= =?utf-8?B?MUVML2JjODlONkIyeThPV0dvLzN2Um83ZWNBNWEzWVJ6dlM3NnlrbGZGd1F2?= =?utf-8?Q?LtQvTHk5ysFgs7M2ll3rPA?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjAxMDFNQjA5MjQ7NjozVHlOcGpiLytzdzJ5WFV6SXFidGpHeVZP?= =?utf-8?B?d01KRHZHQmtsYWpGRENxYUlBREJqTnNKdGw3eS9meE1DNDUwWFZpMHlNaUpI?= =?utf-8?B?WWdTenlzdmZHRVRVK2NkeHhxRVFhcWJRRGpJV1lscDVZZG9UNXg4OGtKUmVt?= =?utf-8?B?bHFPNG9HNFRTdnRjOTh1T1BpWkQ0ZzMveUxEQ0xkMFlPTVdZQkc4YlhuMkpX?= =?utf-8?B?WCtlZGRrNTNyVFF4Y2x5SW01ZDVCUUJSWmtoeU1MNjR4REZ0Rlh3M0dGNTF1?= =?utf-8?B?TGhuT3ZuM2tlbjQ1N2JKZTAzRkFDZVo4eWc4d3gvVTZCVVkrYVAwK1NIdnlD?= =?utf-8?B?UFNnWi9hNlJsUmZrYjlyVmdiYnVUejF3VDFBT3RrcE9HOU51amFSVXIvTGR3?= =?utf-8?B?TmZJODBObDVjWHlyRlh6ZVBETjFqdk5RdGlTRVhqQkMxTyt2R21JYnEvWjds?= =?utf-8?B?ZVVtdTJrQ2FDZzZpY0tpVXdoWW5BWTNlYlEyMHc1NlFBYmZJbUxFSHFYbGxN?= =?utf-8?B?S2xvREp4MWlEV2pWbW16QlduZnFmd2xubXlLdHpqRXJmMi95Ti96VGVxMG1N?= =?utf-8?B?SjVUcFQyOTBUSExNQXc3cExydi84NENnb1ZqbnM2bFA5K3FHdkpnbEk2QkZv?= =?utf-8?B?VCtGWDNIOWVQc0tMeUg5N0ZKbW45d3poblF1MzdZQmVuSFVoa0ZscGRDaGd3?= =?utf-8?B?UTVSVFhVbTRhQ2NHSWc3M2hGejlaMHZ6ZWpBdGp5OThOSnZQTExpSWd1eDJi?= =?utf-8?B?SDVDblFKRTBnN1Z1akErSHpZRFdGaEpkYWhZTUk0aWhUTURyWGUvZW91STVS?= =?utf-8?B?YkpPbVJxMnJCL2cwL25wK0tWbE4xOHZ5ZHBPQi9aNm5DekV5S0xOcHliQUVx?= =?utf-8?B?bHhDZkE0dm1PUG5OczEwOGZadXdqdWJqMXNpMkFZMUVNMEhRczlQbmFQaHRE?= =?utf-8?B?NE8rNmxKWkJJU3VXMFgraTVlcks2ZHBIdnoyeTBMeHZBbnh4ZWZIWU1pZkc4?= =?utf-8?B?NTk3WHY0U2g0cXh0Q2toT1NJSldyNDJRSnd5V1YzcEVYWCt0YVZuVUt2NldJ?= =?utf-8?B?cTlMY01CWi9yclZHdW9zcE5JTjJoT24waDRqdVV2VFNsUW0yRjBzNk5GQlEz?= =?utf-8?B?Ti9FZWZaZTVJb0ZNYjhkVUVLNUswNERzKzQ5cnFoemdjanhuZ0o0NSs3MFpW?= =?utf-8?B?SldNaVBvSS96OFFSVVdXdzQvVEJZSmtaQXMwdUNMbXRadWo0V1Z5eit0OWhQ?= =?utf-8?B?RkhxUzMreS95UE0vMllhSWFIR1QvRm1yMVpOdXFOVVVZaWorSU53L2k2bWJX?= =?utf-8?Q?jBs3ZJFNUM5Q4YlXzm2jucfrBYtbLtc2A=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB0924; 5:U6Ri9B0ndJ8QVS1TwqtJfJ4OcbBYRkpxzCY5SQ/KCQJHMn+jrYQY9848fnyWJq+AR1CGJZw5Ik4nbyLleZiwcTbBbqtqTgeq7TKwM3y5oRbKEs+e30e+EA4XSpOCmIxZWvK+Aw+rkR4JnLTr2O2vduEvnJCLbFMrKUy36hRuzXCCeNphD31jnp5PKt2HFZIcK/Fa+cFEIg8vpk2mwndy3h2zexO5Ld7v2amoQF08YWVMo7JhLCF3E0XliJRg4zm8p5aVQRu+IZcpHMkA1cPB0/oh/F0+7HHrGVuG1X3cTiKmlVqx5tYwGkDK/jVSNd3AYEQlVnnz0hmTDyEEFNpXTtWfxUhbfvk8hV4VTqEM4bdJNnDHHFI3UUZ4CA1XIn/7CGyk38+q4Eq6D3ivfeGdEwD8sxMhTAPsKzk2CWZytDoeGU5UnPoNiVyBJzX7y1Voaaa9/+bnpagRomlbwe65LOsxN+T5aqX02evyIVMh5YO4WtbWHQ8bmpTppxvZAwdS; 24:bS+VtXzXs4COPtOXQaTsch9KJpQ8UVhDwAjGjPNYIbiPSJ7yT2HBFmswBRcSqRokjrhkrJP0PM+7e33u5K9jcZ/tHrJa3UbQPqN0Uoy0dHk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB0924; 7:4t4ZrLsw+5U7KoMO5hgkGd0OlpyVEInAisj6nYA6+d4uYaS5V0Asb2Dsg3Ei5NkR+MNz7RnHsw7VyWhpuYKA7TYltZ/EFCPLmrcSiSNARduMH/mKI0OYhl6H56LYL39rdrTlM243l9uwDTIBuTDL7MY2w7+VGvuSLD2qUJt3kB2RTMbm+kRmBxIj0JNzEALa2kndJf/4Op5hxG0GUPPKGnKbWQsE2Ej7tHaBrv4ZOqtRkScJ45RZf+cQoRa75RUHE9jxFh9d5Pgg2kNfCE7HQ72YjCqBXBEQ8Hg1ogu1G+iQjtRE3wXNUGzCuQ7s4MnySZ1lp/O5U68wOezUVkZZqlcP4EayrX3SozYcIAiXNcKjB8YSpZrAX7TgWeCVtog5uB7YCUdc3sx4iD+g3MQJvpCYRjkSLg2jGPoKGFLNIEFVxb4rVz7fgyCiIgOQnllpyP6C4Fryq8WcwaKDlFufsgrQ+Gwd983oEZgFo2W7U/OUZ66v9OxT6co0GeXrAovPddTEKLABc5H74VqeyFb7QXwIkp8zp6JMs8VXwVe+6cukeLZ8L/gDDmNoGt89Hbp8xqXf7NuvCdDGg+sL+fn14QuKT+qidHy5nVl3+3qJctuFW0Z/x+SzCmBNzcT8fiJL5aftKGxZzZp4ye9hosyWtZwJ+sXbg8VymgKjGJki2yKbvi8gbBbok6nITdX8bu2ea9TA79YE9ApUvtikm1gVcmlK+M2PgoEV/JqRp2Eo/GcEm2KZP8WXDO72EFXTaefFUYmVNYyZhwSJSqv4KVJ9jpqTEh5qosPAY8RKRZDpyOU= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB0924; 20:z4x4yY1bIlE9tolxDP39ypASsM96pq1qxpBoGfO5vZSh34V2adFy2DzjjWF21m7v5okVpr1fb//5OoW8qj7F2fyARu561wj93n2OcPxJnBOLFhp0W1nGsEJt6QnHOU1wlzB3PDCEHZao56dKOa+wJROwCWXhMYLAXK6nKxW+3hs= X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 16:01:11.4441 (UTC) X-MS-Exchange-CrossTenant-Id: eb095636-1052-4895-952b-1ff9df1d1121 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=eb095636-1052-4895-952b-1ff9df1d1121; Ip=[128.146.138.9]; Helo=[cio-socc-esr03.osuad.osu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0101MB0924 Archived-At: Subject: Re: [Unbearable] Dealing with header injection through reverse proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 16:01:15 -0000 PiBEbyBwZW9wbGUgaGF2ZSBvdGhlciB0aG91Z2h0cyBvbiB0aGlzIHByb2JsZW0/IE90aGVyIGdv b2Qgd2F5cyB0bw0KPiBlc3RhYmxpc2ggdGhlIGtleT8gT3RoZXIgaWRlYXMgZm9yIGhvdyB0byBh ZGRyZXNzIGl0Pw0KDQpJIGRvbid0IHRoaW5rIGl0J3MgYSB0ZWNobmljYWwgcHJvYmxlbSBpbiBt b3N0IG9yZ2FuaXphdGlvbnMsIGl0J3MgYSAid2lsbCIgcHJvYmxlbS4gVW5sZXNzIHlvdSBjYW4g Z2V0IHRoZSBsb2FkIGJhbGFuY2VycyB0byBzaW1wbHkgcmVxdWlyZSBzb21lIG1lY2hhbmlzbSB0 byBkbyB0aGlzIG1vcmUgc2VjdXJlbHksIGl0IHdpbGwganVzdCBub3QgZ2V0IGRvbmUgYnkgYSBs b3Qgb2YgZGVwbG95ZXJzLCBhbmQgaWYgeW91IHByZXN1cHBvc2VkIHRoZSBkZXBsb3llcnMgY2Fy ZWQsIHRoZXknZCBmaWx0ZXIgdGhlIGhlYWRlcnMgYW5kIHlvdSB3b3VsZG4ndCBuZWVkIHRvIGRv IGFueXRoaW5nIG5lY2Vzc2FyaWx5Lg0KDQpJIHNheSB0aGlzIGFmdGVyIGhhdmluZyByZXBvcnRl ZCB0byBteSBvd24gb3JnYW5pemF0aW9uIHRoYXQgb3VyIHRyYW5zbWlzc2lvbiBvZiBwcm94aWVk IGNsaWVudCBJUCBhZGRyZXNzIHRvIHNlcnZpY2VzIHRvIHVzZSBpbiBhc3NvY2lhdGluZyBjb29r aWVzIGFuZCBsb2dnaW5nIGFjdGl2aXR5IHdhc24ndCBzYWZlLCBhbmQgdGhlIHJlc3BvbnNlIHdh cyB0byBpZ25vcmUgaXQuDQoNCi0tIFNjb3R0DQoNCg== From nobody Mon Jul 17 09:07:28 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEA1128BC8 for ; Mon, 17 Jul 2017 09:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 SFFUUp_uLlNA for ; Mon, 17 Jul 2017 09:07:25 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 F3671131C8F for ; Mon, 17 Jul 2017 09:07:24 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id e199so17506607pfh.2 for ; Mon, 17 Jul 2017 09:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4Y+I0XNy2hTfNUR9epvidYPjbK7ZXNQcUVFlkEjxXpE=; b=r7PNjbtcdKEEc5sEJmj457pQuIBpipWUDagUi1J1Ob5Zjx3vjIxMOWPquD9BGi82ru CHmmpnpWeHKUaN+Vwh6WjZ0HvvbrpDdPY+e5SuhWAfQ9sXDXlK7b17F+lJZNZ5LxFg7x PGkfc3lWw7uVc8CGAOUyP5WXGJQ4N1L41MdZWVzIQp/zC26sJ9YXFdQI0Bodn7vPfosB T8nOtUZMVUKFNhsoYFXHWW3abujPMvxAhxCDoMdQuPxc4PJpXko+2J7J0YzYK5hSwRWJ Cy+L1rlpdS6wZCI2jW54Xh5q4jV8+so3X/H4rWjay6B4QZDGSDTbGg0LYB5cKIbCZzaS rgxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4Y+I0XNy2hTfNUR9epvidYPjbK7ZXNQcUVFlkEjxXpE=; b=R5THRehuk6OdvLDMqJ4ik/UrcuR2orDyq5WqY0fVG4flyG77/OkM3GmWXccwWEMxPJ 3ZfDOJvPsFzjYVa/pHPyRTiILbpK77+pQ984InorAovS049EaT1io/RpBQI2eHdiEy8n kR7BywcHwFI0DeKZUumcqNXs4rgFsJIU5GwjJmhZHUHf7FCe5VsnC5jnYtmIBm2LS7xD HvyHYBABxAJSRpWOFZt3oow9a/CN1QOMfKzPylpX0v1tWtWriIEZ6ec2AXsUYMzwfSMj 7snudWDT/oA6WLXMaYfGn/d2qMTwmPSJZ1d3tXd9zs6O2I5yYNuclfXAeDetej8fA6/c 7pOg== X-Gm-Message-State: AIVw110/xZf6IkNgKb0VcRFrYxIVLhHsXl9K6F180uUAMbmzUgdG7cWN aHslC/NWe1W9aWTID6mWnX7nSRT3h8X8 X-Received: by 10.98.42.4 with SMTP id q4mr20115468pfq.143.1500307644540; Mon, 17 Jul 2017 09:07:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.181.42 with HTTP; Mon, 17 Jul 2017 09:06:44 -0700 (PDT) In-Reply-To: References: From: Ted Lemon Date: Mon, 17 Jul 2017 18:06:44 +0200 Message-ID: To: Eric Rescorla Cc: HTTP Working Group , IETF Tokbind WG Content-Type: multipart/alternative; boundary="001a1145cd5e34fd8f0554859873" Archived-At: Subject: Re: [Unbearable] Dealing with header injection through reverse proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 16:07:27 -0000 --001a1145cd5e34fd8f0554859873 Content-Type: text/plain; charset="UTF-8" I was reluctant to go to the mic to say this because I'm very much an innocent customer of this work, not an expert on the topic. But from my perspective, while I see and value the ability to do this (I happen to use nginx), I am very uncomfortable with the problem you described, ekr--I would much rather that this failed safe than failed insecure. So I don't really feel qualified to say "yes, we should do what you have proposed, and here's how I would do it," but I am definitely rooting for that to happen. On Mon, Jul 17, 2017 at 5:18 PM, Eric Rescorla wrote: > i folks, > > We had a discussion today in TOKBIND about handling security-sensitive > indications in HTTP headers (this came up in the context of > https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-01). The > setting here is that you have a network with a TLS reverse proxy > serving the origin server, and the TLS proxy is responsible for doing > some security check and telling the server about it. E.g., > > Client Proxy Server > > <--- TLS w/ client auth ---> <----- HTTP with cert ---> > > The client does TLS client authentication with the proxy and then > passes the certificate to the back-end server in an injected HTTP > header (e.g., X-Client-Certificate). In order for this to be secure, > the proxy has to *strip* any security sensitive headers sent by the > client. Otherwise, the client could inject their own headers that > would appear to come from the proxy. > > Obviously, this design doesn't fail safe if the proxy fails to > strip the headers. One way in which this can happen is if you > have a large network of load balancers fronting a server network > and you somehow incompletely misconfigure either the servers > or the proxies, so that a server which supports this mechanism > ends up behind a proxy which does not (and hence does not strip > the headers). So, it would be nice to do something better that > wasn't too heavyweight, especailly as a general solution. > > One natural design is simply to have a shared key between the > proxy and the server. In that case, it's easy to demonstrate > that the header is injected, as in [0][1] > > X-Client-Certificate: , > > The obvious objection to this design is that it requires you to > establish the shared key, and people were concerned about having to > configure it into the proxy. I'm aware of a number of designs here: > > - Configure it via some sort of remote configuration mechanism. > - The proxy could send it to the server on its first request > (might require some trickery on the server). > - If you have a TLS channel between Proxy and Server you can > use a TLS exporter. > - If you have a H2 connection between the two, you can have the > server provide it in a settings frame. > - Use a signature by the proxy using its private key over something > e.g., S(K, "Token binding"). If you use a mostly fixed string, > then the server just needs to verify it once. > > Do people have other thoughts on this problem? Other good ways to > establish the key? Other ideas for how to address it? > > -Ekr > > > [0] I'd originally suggested HMACing, but that's actually not > necessary, though obviously stronger. > > [1] Note that you could have a generic solution, like a header which > listed all the injected headers, but with the same security mechanism. > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --001a1145cd5e34fd8f0554859873 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was reluctant to go to the mic to say this because I'= ;m very much an innocent customer of this work, not an expert on the topic.= =C2=A0 But from my perspective, while I see and value the ability to do th= is (I happen to use nginx), I am very uncomfortable with the problem you de= scribed, ekr--I would much rather that this failed safe than failed insecur= e. =C2=A0 So I don't really feel qualified to say "yes, we should = do what you have proposed, and here's how I would do it," but I am= definitely rooting for that to happen.
On Mon, Jul 17, 2017 at 5:18 PM, Eric Rescorla = <ekr= @rtfm.com> wrote:
i folks,

We had a discussion today i= n TOKBIND about handling security-sensitive
indications in HTTP h= eaders (this came up in the context of
https://tool= s.ietf.org/html/draft-campbell-tokbind-ttrp-01).=C2=A0 The
setting here is that you have a network with a TLS reverse proxy
serving the origin server, and the TLS proxy is responsible for doi= ng
some security check and telling the server about it. E.g.,

=C2=A0 =C2=A0 Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Proxy =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Server
=C2=A0 =C2=A0=C2=A0=
=C2=A0 =C2=A0 <--- TLS w/ client auth ---> <----- HTTP = with cert --->

The client does TLS client authe= ntication with the proxy and then
passes the certificate to the b= ack-end server in an injected HTTP
header (e.g., X-Client-Certifi= cate). In order for this to be secure,
the proxy has to *strip* a= ny security sensitive headers sent by the
client. Otherwise, the = client could inject their own headers that
would appear to come f= rom the proxy.

Obviously, this design doesn't = fail safe if the proxy fails to
strip the headers. One way in whi= ch this can happen is if you
have a large network of load balance= rs fronting a server network
and you somehow incompletely misconf= igure either the servers
or the proxies, so that a server which s= upports this mechanism
ends up behind a proxy which does not (and= hence does not strip
the headers). So, it would be nice to do so= mething better that
wasn't too heavyweight, especailly as a g= eneral solution.

One natural design is simply to h= ave a shared key between the
proxy and the server. In that case, = it's easy to demonstrate
that the header is injected, as in [= 0][1]

=C2=A0 =C2=A0X-Client-Certificate: <key&g= t;, <certificate>

The obvious objection to t= his design is that it requires you to
establish the shared key, a= nd people were concerned about having to
configure it into the pr= oxy. I'm aware of a number of designs here:

- = Configure it via some sort of remote configuration mechanism.
- T= he proxy could send it to the server on its first request
=C2=A0 = (might require some trickery on the server).
- If you have a TLS = channel between Proxy and Server you can
=C2=A0 use a TLS exporte= r.
- If you have a H2 connection between the two, you can have th= e
=C2=A0 server provide it in a settings frame.
- Use a= signature by the proxy using its private key over something
=C2= =A0 e.g., S(K, "Token binding"). If you use a mostly fixed string= ,
=C2=A0 then the server just needs to verify it once.
=
Do people have other thoughts on this problem? Other good wa= ys to
establish the key? Other ideas for how to address it?
=

-Ekr


[0] I'= d originally suggested HMACing, but that's actually not
neces= sary, though obviously stronger.

[1] Note that you= could have a generic solution, like a header which
listed all th= e injected headers, but with the same security mechanism.


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


--001a1145cd5e34fd8f0554859873-- From nobody Mon Jul 17 09:34:19 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9053131CB9 for ; Mon, 17 Jul 2017 09:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh3-X863L85M for ; Mon, 17 Jul 2017 09:34:12 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c: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 5FCE1131CB2 for ; Mon, 17 Jul 2017 09:34:02 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id f67so89710920wmh.1 for ; Mon, 17 Jul 2017 09:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iAnoFHZGiXAIT1HDxYajY54CyLv9+c7nKC4rMPLaSM8=; b=EG9YJNSyZ1Zpaukis86h6NPWTUfag1N6Yyjgj2BcS2UFIj41yFQ/piXqOwh9+wRbvs 3+YMZnvieW+i8V+xBHm65RdTFjEEzIikFReu2FrK/eVVXle4PNVv3NNv3dCx43UvfZ+9 kyqmdoyRhrtBK/j6ueTJHXp6b/6ZvbBrE/hmkcUiqTl97Jj+0Wt3yXeQb4iD6lK+RRH6 2pOTXwOV3c0aHjs0Z5CuHGh1dm5eiYW9GPWKCHVHe8bb/JOktOTyBdt764a1y9fGfkB7 a89mccU3X7hsuxAuc5j7XEysAAkAkhje4JeR7HKL4yddAICmoQGElzF58dUN+D67S7TF Gvhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iAnoFHZGiXAIT1HDxYajY54CyLv9+c7nKC4rMPLaSM8=; b=NFMavy3UvxbWKFEJy0cuPVWcIVJzopuU4a8x2VL4JXd5HQqbGqcJxoCZxMZrwP3Vap brbWujVBxqvPruTaUzZTjNZHx9J67ybVY4XVyPdzMvcAOMjIOKQVn8lMuZF6DyswqJTN So1BbmJvh+8NZ5jRVp/dxwCZl54Ds6QwV+BOANbl5bz5gtEIS2YzUpy2LDzizB4Fhrn5 xUGUTamUloyFm0UG//2DiM7HdlCDZnLyOSiE2tx8cyJMkpOE3vctoxMSFITm833wOMw8 JJbtCeiNOgbLMDNbV555yjkQpS9pgS2Lky8JMqFslEpkaiZldjopAObSWl2Xj2gBOZnJ hv0A== X-Gm-Message-State: AIVw113/3QWzbKLCFDkbWkrj2NMlto9w5yC8Kn3TUapoycDxA89fheFy EzhQOAb85pOXycAo X-Received: by 10.28.46.132 with SMTP id u126mr5415109wmu.48.1500309240550; Mon, 17 Jul 2017 09:34:00 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:184:31a1:58c5:f51b:f835? ([2001:67c:1232:184:31a1:58c5:f51b:f835]) by smtp.gmail.com with ESMTPSA id 9sm51616wml.25.2017.07.17.09.33.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 09:33:59 -0700 (PDT) From: John Bradley Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 17 Jul 2017 18:33:56 +0200 In-Reply-To: Cc: HTTP Working Group , IETF Tokbind WG To: Eric Rescorla References: X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114228305cd230055485f723" Archived-At: Subject: Re: [Unbearable] Dealing with header injection through reverse proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 16:34:15 -0000 --001a114228305cd230055485f723 Content-Type: multipart/alternative; boundary="Apple-Mail=_DC135451-453B-4FA7-9A05-7242A2BF39EE" --Apple-Mail=_DC135451-453B-4FA7-9A05-7242A2BF39EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It would be good if the new mechanism could also be applied to existing = reverse proxy headders like SSL_CLIENT_CERT and SSL_CLIENT_CERT_CHAINn = without breaking the existing parsing. That might lead to a preference for a header that lists the injected = headers as a possibility. John B. =20 > On Jul 17, 2017, at 5:18 PM, Eric Rescorla wrote: >=20 > i folks, >=20 > We had a discussion today in TOKBIND about handling security-sensitive > indications in HTTP headers (this came up in the context of > https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-01 = ). The > setting here is that you have a network with a TLS reverse proxy > serving the origin server, and the TLS proxy is responsible for doing > some security check and telling the server about it. E.g., >=20 > Client Proxy Server > =20 > <--- TLS w/ client auth ---> <----- HTTP with cert ---> >=20 > The client does TLS client authentication with the proxy and then > passes the certificate to the back-end server in an injected HTTP > header (e.g., X-Client-Certificate). In order for this to be secure, > the proxy has to *strip* any security sensitive headers sent by the > client. Otherwise, the client could inject their own headers that > would appear to come from the proxy. >=20 > Obviously, this design doesn't fail safe if the proxy fails to > strip the headers. One way in which this can happen is if you > have a large network of load balancers fronting a server network > and you somehow incompletely misconfigure either the servers > or the proxies, so that a server which supports this mechanism > ends up behind a proxy which does not (and hence does not strip > the headers). So, it would be nice to do something better that > wasn't too heavyweight, especailly as a general solution. >=20 > One natural design is simply to have a shared key between the > proxy and the server. In that case, it's easy to demonstrate > that the header is injected, as in [0][1] >=20 > X-Client-Certificate: , >=20 > The obvious objection to this design is that it requires you to > establish the shared key, and people were concerned about having to > configure it into the proxy. I'm aware of a number of designs here: >=20 > - Configure it via some sort of remote configuration mechanism. > - The proxy could send it to the server on its first request > (might require some trickery on the server). > - If you have a TLS channel between Proxy and Server you can > use a TLS exporter. > - If you have a H2 connection between the two, you can have the > server provide it in a settings frame. > - Use a signature by the proxy using its private key over something > e.g., S(K, "Token binding"). If you use a mostly fixed string, > then the server just needs to verify it once. >=20 > Do people have other thoughts on this problem? Other good ways to > establish the key? Other ideas for how to address it? >=20 > -Ekr >=20 >=20 > [0] I'd originally suggested HMACing, but that's actually not > necessary, though obviously stronger. >=20 > [1] Note that you could have a generic solution, like a header which > listed all the injected headers, but with the same security mechanism. >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_DC135451-453B-4FA7-9A05-7242A2BF39EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii It would be good if the new mechanism could also be applied = to existing reverse proxy headders like SSL_CLIENT_CERT and = SSL_CLIENT_CERT_CHAINn without breaking the existing parsing.

That might lead to a = preference for a header that lists the injected headers as a = possibility.

John B.

 
On Jul 17, 2017, at 5:18 PM, Eric Rescorla = <ekr@rtfm.com> = wrote:

i folks,

We had a discussion today in TOKBIND = about handling security-sensitive
indications in = HTTP headers (this came up in the context of
https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-01)= .  The
setting here is that you have a network = with a TLS reverse proxy
serving the origin server, = and the TLS proxy is responsible for doing
some = security check and telling the server about it. E.g.,

    Client =                   =  Proxy                 =     Server
    
    <--- TLS w/ client auth ---> <----- = HTTP with cert --->

The client does TLS client authentication with the proxy and = then
passes the certificate to the back-end server = in an injected HTTP
header (e.g., = X-Client-Certificate). In order for this to be secure,
the proxy has to *strip* any security sensitive headers sent = by the
client. Otherwise, the client could inject = their own headers that
would appear to come from = the proxy.

Obviously, this design doesn't fail safe if the proxy fails = to
strip the headers. One way in which this can = happen is if you
have a large network of load = balancers fronting a server network
and you somehow = incompletely misconfigure either the servers
or the = proxies, so that a server which supports this mechanism
ends up behind a proxy which does not (and hence does not = strip
the headers). So, it would be nice to do = something better that
wasn't too heavyweight, = especailly as a general solution.

One natural design is simply to have a = shared key between the
proxy and the server. In = that case, it's easy to demonstrate
that the header = is injected, as in [0][1]

   X-Client-Certificate: <key>, = <certificate>

The obvious objection to this design is that it requires you = to
establish the shared key, and people were = concerned about having to
configure it into the = proxy. I'm aware of a number of designs here:

- Configure it via some sort of remote = configuration mechanism.
- The proxy could send it = to the server on its first request
  (might = require some trickery on the server).
- If you have = a TLS channel between Proxy and Server you can
 = use a TLS exporter.
- If you have a H2 connection = between the two, you can have the
  server = provide it in a settings frame.
- Use a signature = by the proxy using its private key over something
  e.g., S(K, "Token binding"). If you use a mostly fixed = string,
  then the server just needs to verify = it once.

Do = people have other thoughts on this problem? Other good ways to
establish the key? Other ideas for how to address = it?

-Ekr


[0] I'd originally = suggested HMACing, but that's actually not
necessary,= though obviously stronger.

[1] Note that you could have a generic solution, like a = header which
listed all the injected headers, but = with the same security mechanism.

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

= --Apple-Mail=_DC135451-453B-4FA7-9A05-7242A2BF39EE-- --001a114228305cd230055485f723 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIO4jkka21n34ZWSMdrvOkrVQe+eI 88ie0DFXnFfXowbdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDcxNzE2MzQwMFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQCdLRjPcex/KF7ForWT15CYaJaUAyPJfevC5GtDrZu7Hnmf mJrnShFNGAtohr32IDU+x6vRfQQUcH5gV81HvLeLmZCskNnQeX/P+z9D8hdmnjtVHdJ9rCKJSlQi EVvMzyV3gwx4aLYouI2zUyM4fHEZgEH+ETiqFlsw2RlKAc43xLOw+ATvHSKuC95xiXRkM1XyZmLU rmihA6BeIRkkatHm7eYGG4TrpcKLK534h9/TV4XQmlPXdJgqQ+WjG6/KptuVisjd0feACuTRSEGC aHd9QmuCIEIUrldn07lmQjKtUzh+tXctYoTS0bSdo/rXYMU3PxiSoNB1+kYq+YTGlVlz --001a114228305cd230055485f723-- From nobody Mon Jul 17 11:45:17 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653CB131537 for ; Mon, 17 Jul 2017 11:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85k8f_8FkITf for ; Mon, 17 Jul 2017 11:45:13 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id F34EE1200ED for ; Mon, 17 Jul 2017 11:45:12 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v6HIj79i010082; Mon, 17 Jul 2017 20:45:07 +0200 Date: Mon, 17 Jul 2017 20:45:07 +0200 From: Willy Tarreau To: Eric Rescorla Cc: HTTP Working Group , IETF Tokbind WG Message-ID: <20170717184507.GA10072@1wt.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Subject: Re: [Unbearable] Dealing with header injection through reverse proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 18:45:15 -0000 Hi Eric, On Mon, Jul 17, 2017 at 08:18:10AM -0700, Eric Rescorla wrote: > i folks, > > We had a discussion today in TOKBIND about handling security-sensitive > indications in HTTP headers (this came up in the context of > https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-01). The > setting here is that you have a network with a TLS reverse proxy > serving the origin server, and the TLS proxy is responsible for doing > some security check and telling the server about it. E.g., > > Client Proxy Server > > <--- TLS w/ client auth ---> <----- HTTP with cert ---> > > The client does TLS client authentication with the proxy and then > passes the certificate to the back-end server in an injected HTTP > header (e.g., X-Client-Certificate). In order for this to be secure, > the proxy has to *strip* any security sensitive headers sent by the > client. Otherwise, the client could inject their own headers that > would appear to come from the proxy. > > Obviously, this design doesn't fail safe if the proxy fails to > strip the headers. One way in which this can happen is if you > have a large network of load balancers fronting a server network > and you somehow incompletely misconfigure either the servers > or the proxies, so that a server which supports this mechanism > ends up behind a proxy which does not (and hence does not strip > the headers). So, it would be nice to do something better that > wasn't too heavyweight, especailly as a general solution. > > One natural design is simply to have a shared key between the > proxy and the server. In that case, it's easy to demonstrate > that the header is injected, as in [0][1] > > X-Client-Certificate: , > > The obvious objection to this design is that it requires you to > establish the shared key, and people were concerned about having to > configure it into the proxy. I'm aware of a number of designs here: (...) What I've seen and used was slightly different : 1) proxies unconditionally remove the header field 2) proxies unconditionally add the new header field even with no certificate 3) servers verify that there is exactly one header field This way even if step 1 above fails (eg: usual typo in the rule needed to strip the header field which nobody notices since nobody injects such a field name), step 2 ensures that any injection will be detected in step 3. In my opinion, it's important to stick to simple principles that can be troubleshooted and fixed in field. For example I've had to deal with signed header fields in the past and it used to be a great pain to debug for everyone involved, to the point that people undervalue the extra security. Simply prepending a clearly visible static value into a field could help without adding much hassle but that's more or less where the realistic limit lies in my opinion. Cheers, Willy From nobody Mon Jul 17 13:35:08 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3A2131C3E for ; Mon, 17 Jul 2017 13:35:07 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDm2RFxiug7D for ; Mon, 17 Jul 2017 13:35:04 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0116.outbound.protection.outlook.com [104.47.32.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8860B131B33 for ; Mon, 17 Jul 2017 13:35:04 -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=oiBbMZsVtGItACsxuXCPHpY6tLpb/lnyLiKdmHQL2Gs=; b=Qa0u+kc22Fbfpc2GXC+k2kVx/LZxKhHtvcvaNLieHuY3RrEctQlPDPU3UuEhG7n5DMhpr3sHtbcgDo8zC/fcfGlyZlgyCbHXvxqLapnossYlMubCYoaVhwaekjX68WeTa1tCbBcJRVuGrHfJwiHMsW79sgjywEMGMYF1ULcXym4= Received: from DM5PR21MB0284.namprd21.prod.outlook.com (10.173.174.19) by DM5PR21MB0124.namprd21.prod.outlook.com (10.173.173.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.2; Mon, 17 Jul 2017 20:35:03 +0000 Received: from DM5PR21MB0284.namprd21.prod.outlook.com ([10.173.174.19]) by DM5PR21MB0284.namprd21.prod.outlook.com ([10.173.174.19]) with mapi id 15.01.1282.008; Mon, 17 Jul 2017 20:35:03 +0000 From: Anthony Nadalin To: Leif Johansson , IETF Tokbind WG Thread-Topic: [Unbearable] WG adoption of draft-campbell-tokbind-ttrp-00 Thread-Index: AQHS/xRvpKAPfchK1kW7724yuY/xe6JYeitc Date: Mon, 17 Jul 2017 20:35:02 +0000 Message-ID: References: <853ba12d-5859-1545-611d-74f0b1fbf533@sunet.se> In-Reply-To: <853ba12d-5859-1545-611d-74f0b1fbf533@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sunet.se; dkim=none (message not signed) header.d=none;sunet.se; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [13.90.24.116] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR21MB0124; 7:R5j1gbL+1M8xxrcRvB809qs3x+2AVyZDfyNNz5auNyOvtMHIt01R4V4c47M9bYB33AoHtZG0fmyr8ncN6Y6N/p3qzXmnaaRgExQpFyxa+lbiWDqzsuZ3X0wjK9metTjVVVrsQhbm0j/1taB/84M3SmK/IUAMFtq8Pz6D9Mu6Ds7VF8xgFaByeD63OrvE+JTwnS1i2tnqadfLTqw6YWvQXvTDsRFP6lB8AkytSb1jXkk5GVUA0atI9SG5A41arq/mYfkd1WyDAcmC8PW9vazyqLOvauzPJQjacn1O7rJcv2yhrHjAJtpb1qe5huqZqqXK7UHYRMMB3ltaPtviOeMFdEOLiQ1yo/r0paAqHNLZijZPb3OeLpPIc8CLyncUN+0RhzB9pcqalzY+UbWG49tp3xla9BwFInZj4HJN/EfeZCCXEooiJIv1xh4S4XOFdP+VnbTx9qj8tq8+Fd4xnsNTRPCD+KpcZAEgiQFVPNSYvXvHHU5sa/bcvehoJ8vvhHwwlBKOMri56GAuSleE5fAOR+rxqYgoBr/N7S6RDYAdRxj1aVNFE3l1/qrinb0zm9h37axzAYT4xYqDSI4ep+lxgdpARqvkGSps234x1T6NRxIcve8e7Yju9AKRmSLqdoEXBBGgLyvnjgG96AOZ0rINSyS4Zp/IoV2f68m0KHVH7/AvGGk42qMa5fSAOsPnNarwz3SKH+VjqSLReyCyffCUfKIiVguJd3un+wAqki1t5117/nqtjaF3cW45zagKT1ll3FzNYsI7FBwLWiXfJUvyV8HyFPhA59Hg98NSM1qBbXaLENzhr9cjj0foaxAGHxr/ x-ms-office365-filtering-correlation-id: 812f5e47-0c55-4a3f-1640-08d4cd534d74 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR21MB0124; x-ms-traffictypediagnostic: DM5PR21MB0124: x-exchange-antispam-report-test: UriScan:(158342451672863)(26388249023172)(236129657087228)(189930954265078)(100405760836317)(81439100147899)(219752817060721)(69029272430364)(164587983369549); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(2017060910075)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR21MB0124; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR21MB0124; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39410400002)(39850400002)(39450400003)(39860400002)(39400400002)(377454003)(7736002)(8936002)(14454004)(74316002)(966005)(189998001)(6506006)(230783001)(77096006)(6246003)(5005710100001)(99286003)(478600001)(10290500003)(236005)(55016002)(81166006)(38730400002)(6436002)(25786009)(9686003)(229853002)(53546010)(54896002)(606006)(6306002)(53936002)(8676002)(3280700002)(7696004)(10090500001)(3846002)(2906002)(3660700001)(102836003)(6116002)(66066001)(2900100001)(2950100002)(33656002)(5660300001)(86362001)(50986999)(76176999)(54356999)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0124; H:DM5PR21MB0284.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR21MB0284C327BDC667EE11EC722DA6A00DM5PR21MB0284namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 20:35:02.7712 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0124 Archived-At: Subject: Re: [Unbearable] WG adoption of draft-campbell-tokbind-ttrp-00 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 20:35:07 -0000 --_000_DM5PR21MB0284C327BDC667EE11EC722DA6A00DM5PR21MB0284namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So I'm not sure of the value of this as we and the their companies have alr= eady implemented solutions that are different than what is being proposed. = This also does not work for a lot of our use cases where there is an untrus= ted proxy. Most of our cases are also within our own infrastructure so no q= uestion the need for standardization. ________________________________ From: Unbearable on behalf of Leif Johansson = Sent: Monday, July 17, 2017 5:50:20 PM To: IETF Tokbind WG Subject: [Unbearable] WG adoption of draft-campbell-tokbind-ttrp-00 In the f2f meeting in Prague there was clear consensus to adopt draft-campbell-tokbind-ttrp-00 as draft-ietf-tokbind-ttrp-00 making this a WG document. If anyone on the list disagrees, now is the time to speak up. Cheers Leif & John _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Funbearable&data=3D02%7C01%7Ctonynad%40microsoft= .com%7C06e4b840a7a94372b5e008d4cd2b8f26%7C72f988bf86f141af91ab2d7cd011db47%= 7C1%7C0%7C636359034357583877&sdata=3DhW8BlMQm1Sf%2BjDXeAQ9%2BeHIxXMroROFSue= gdWpdX8DA%3D&reserved=3D0 --_000_DM5PR21MB0284C327BDC667EE11EC722DA6A00DM5PR21MB0284namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
So I'm not sure of the value of this as we and= the their companies have already implemented solutions that are different = than what is being proposed. This also does not work for a lot of our use c= ases where there is an untrusted proxy. Most of our cases are also within our own infrastructure so no question th= e need for standardization.

From: Unbearable <unbe= arable-bounces@ietf.org> on behalf of Leif Johansson <leifj@sunet.se&= gt;
Sent: Monday, July 17, 2017 5:50:20 PM
To: IETF Tokbind WG
Subject: [Unbearable] WG adoption of draft-campbell-tokbind-ttrp-00<= /font>
 

In the f2f meeting in Prague there was clear consensus to adopt
draft-campbell-tokbind-ttrp-00 as draft-ietf-tokbind-ttrp-00
making this a WG document.

If anyone on the list disagrees, now is the time to speak up.

        Cheers Leif & John

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://na01.safelinks.pr= otection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo= %2Funbearable&data=3D02%7C01%7Ctonynad%40microsoft.com%7C06e4b840a7a943= 72b5e008d4cd2b8f26%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63635903435= 7583877&sdata=3DhW8BlMQm1Sf%2BjDXeAQ9%2BeHIxXMroROFSuegdWpdX8DA%3D&= reserved=3D0
 --_000_DM5PR21MB0284C327BDC667EE11EC722DA6A00DM5PR21MB0284namp_-- From nobody Mon Jul 17 22:17:34 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8892D12706D for ; Mon, 17 Jul 2017 22:17:33 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVADNNdeNrxt for ; Mon, 17 Jul 2017 22:17:31 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 01F0D126557 for ; Mon, 17 Jul 2017 22:17:31 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id e199so5678404pfh.2 for ; Mon, 17 Jul 2017 22:17:30 -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=fGDXqVQISF9emqwy05tL7ccqxeLR62/uIEPXVxJ+hf4=; b=hJzMPwaJl9PURqG0zhYz3agt9gD2aAYnv1r1AazBqwNh60DjxOhoL7KlOyz5Pv02D3 EG4tK+isuEXIQR85RQtuM1OX6eE2a2QO0ivCq2Aun8DbLmzk5/b9jnWG6qBFHcfD0NKa xioB6WOzScmLp3BlL0xu1yNjjRK8DEv0mOWOM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fGDXqVQISF9emqwy05tL7ccqxeLR62/uIEPXVxJ+hf4=; b=q1+X+4cBiYUs1N2UlPiC/nVeh4dySHpurcqZcq/FunyAHK2Kaajz9HqBVU0CZiKNLr tCv9r7+ZQhR+VXFIwAZbLYy9SVwIGSv9Fs7XvPQj4WSfQwarl0x0THGGJ4XxEh6Z6DEg qubRT1u/HRo/A/QLvLEmi54oAqJ8FmxxEPT+XQYa/fgdX//kCc3IL5qVn3/M/HzWLuIo sGdPvtzKf+dxBHja78HkoEjB217EN5KsMJyyrKNtTElVVWr2VzDlO26t6zKlsWuMBNnd OD294LQjqpMiLTW34wpdfsMo+QMVpG+zhAKJMhQaNvN9HBjswVIY3DazRpnyUsoEmm8F 5aKA== X-Gm-Message-State: AIVw112oI8/d9TrRPSIMJceMhMWS2O6ebeO2CA154drsL8mUmwaZAKHI 3ac+ZvA+IhHQNETTKft6Tu4hwY6+YVOfnM1GMp2DxSQzi2p7iy2qISDSvnaemXAG6zMdiEI+paD PxUks9U3+xWo= X-Received: by 10.84.179.36 with SMTP id a33mr1275237plc.144.1500355050511; Mon, 17 Jul 2017 22:17:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Mon, 17 Jul 2017 22:16:59 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Tue, 18 Jul 2017 07:16:59 +0200 Message-ID: To: Piotr Sikora Cc: IETF Tokbind WG Content-Type: multipart/alternative; boundary="94eb2c13ead0d2bd6d055490a1f3" Archived-At: Subject: Re: [Unbearable] HTTPS Token Binding with TLS Terminating Reverse Proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 05:17:33 -0000 --94eb2c13ead0d2bd6d055490a1f3 Content-Type: text/plain; charset="UTF-8" Fair enough. I'll plan to remove the sentence in a future draft. Thanks for the review and feedback, Piotr. On Mon, Jul 17, 2017 at 3:35 PM, Piotr Sikora wrote: > Well, it's kind of given that requests are sent only to backends that > are configured for a particular domain. That applies to whole > requests, and not only to Provided-Token-Binding-ID header, so I think > this is unnecessary restriction that will only confuse readers. > > Best regards, > Piotr Sikora > > On Mon, Jul 17, 2017 at 2:29 PM, Brian Campbell > wrote: > > For any given domain, a CDN would know the origin server(s) where it > should > > forward requests it cannot fulfill, right? > > > > That's what I was trying to get at in the statement in the draft - that > the > > reverse proxy only dispatch requests to origin sever(s) known/configured > to > > be associated with the domain of the original request. Perhaps "trust" > isn't > > the right word and that sentence can be reworded to be more reflective of > > that? Or is such a restriction/requirement so implicit in the deployment > of > > any reverse proxy so doesn't need any treatment in this document? > > > > On Mon, Jul 17, 2017 at 1:18 PM, Piotr Sikora > > wrote: > >> > >> Hey Brian, > >> from the CDN point of view, all backend servers are untrusted, but I > >> don't see any reason why CDNs shouldn't forward > >> Provided-Token-Binding-ID to the origin servers. > >> > >> Also, Token Binding is supposed to protect Cookies (among other > >> things), which don't have such restriction, so this seems unnecessary. > >> > >> Best regards, > >> Piotr Sikora > >> > >> On Mon, Jul 17, 2017 at 12:53 PM, Brian Campbell > >> wrote: > >> > To be honest, I didn't have a specific attack vector or > security/privacy > >> > implication in mind around that. It just seemed like something that > >> > should > >> > generally be part of reverse proxy set up. Do you think it's too > >> > restrictive/perspective? Or do you know of some use-case where a > reverse > >> > proxy wouldn't know/trust the servers that it sits in front of? > >> > > >> > On Mon, Jul 17, 2017 at 12:37 PM, Piotr Sikora < > piotrsikora@google.com> > >> > wrote: > >> >> > >> >> Hey Brian, > >> >> looks good, thanks for working on that! > >> >> > >> >> One question: > >> >> > >> >> > Reverse proxies SHOULD only add the headers to requests that are > >> >> > forwarded to trusted backend servers. > >> >> > >> >> Why? What's the attack vector, security and/or privacy implications > >> >> here? > >> >> > >> >> Best regards, > >> >> Piotr Sikora > >> >> > >> >> On Fri, Jul 14, 2017 at 6:59 PM, Brian Campbell > >> >> wrote: > >> >> > Just a not-so-subtle reminder that HTTPS Token Binding with TLS > >> >> > Terminating > >> >> > Reverse Proxies is one of the agenda items for Monday's meeting in > >> >> > Prague > >> >> > and it would be great if there was some familiarity with it going > >> >> > into > >> >> > the > >> >> > meeting. It's relativity short as drafts go, if you're looking for > >> >> > something > >> >> > to read en route to the meeting: > >> >> > https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-00 > >> >> > > >> >> > CONFIDENTIALITY NOTICE: This email may contain confidential and > >> >> > privileged > >> >> > material for the sole use of the intended recipient(s). Any review, > >> >> > use, > >> >> > distribution or disclosure by others is strictly prohibited. If > you > >> >> > have > >> >> > received this communication in error, please notify the sender > >> >> > immediately > >> >> > by e-mail and delete the message and any file attachments from your > >> >> > computer. Thank you. > >> >> > _______________________________________________ > >> >> > Unbearable mailing list > >> >> > Unbearable@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/unbearable > >> >> > > >> > > >> > > >> > > >> > CONFIDENTIALITY NOTICE: This email may contain confidential and > >> > privileged > >> > material for the sole use of the intended recipient(s). Any review, > use, > >> > distribution or disclosure by others is strictly prohibited. If you > >> > have > >> > received this communication in error, please notify the sender > >> > immediately > >> > by e-mail and delete the message and any file attachments from your > >> > computer. Thank you. > > > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged > > material for the sole use of the intended recipient(s). Any review, use, > > distribution or disclosure by others is strictly prohibited. If you have > > received this communication in error, please notify the sender > immediately > > by e-mail and delete the message and any file attachments from your > > computer. Thank you. > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --94eb2c13ead0d2bd6d055490a1f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Fair enough. I'll plan to remove the sentence in = a future draft.

Thanks for the review and feedback, Piotr.=C2= =A0

On = Mon, Jul 17, 2017 at 3:35 PM, Piotr Sikora <piotrsikora@google.com> wrote:
Well, it's kind o= f given that requests are sent only to backends that
are configured for a particular domain. That applies to whole
requests, and not only to Provided-Token-Binding-ID header, so I think
this is unnecessary restriction that will only confuse readers.

Best regards,
Piotr Sikora

On Mon, Jul 17, 2017 at 2:29 PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:
> For any given domain, a CDN would know the origin server(s) where it s= hould
> forward requests it cannot fulfill, right?
>
> That's what I was trying to get at in the statement in the draft -= that the
> reverse proxy only dispatch requests to origin sever(s) known/configur= ed to
> be associated with the domain of the original request. Perhaps "t= rust" isn't
> the right word and that sentence can be reworded to be more reflective= of
> that? Or is such a restriction/requirement so implicit in the deployme= nt of
> any reverse proxy so doesn't need any treatment in this document?<= br> >
> On Mon, Jul 17, 2017 at 1:18 PM, Piotr Sikora <piotrsikora@google.com>
> wrote:
>>
>> Hey Brian,
>> from the CDN point of view, all backend servers are untrusted, but= I
>> don't see any reason why CDNs shouldn't forward
>> Provided-Token-Binding-ID to the origin servers.
>>
>> Also, Token Binding is supposed to protect Cookies (among other >> things), which don't have such restriction, so this seems unne= cessary.
>>
>> Best regards,
>> Piotr Sikora
>>
>> On Mon, Jul 17, 2017 at 12:53 PM, Brian Campbell
>> <bcampbell@pingid= entity.com> wrote:
>> > To be honest, I didn't have a specific attack vector or s= ecurity/privacy
>> > implication in mind around that. It just seemed like somethin= g that
>> > should
>> > generally be part of reverse proxy set up. Do you think it= 9;s too
>> > restrictive/perspective? Or do you know of some use-case wher= e a reverse
>> > proxy wouldn't know/trust the servers that it sits in fro= nt of?
>> >
>> > On Mon, Jul 17, 2017 at 12:37 PM, Piotr Sikora <piotrsikora@google.com>
>> > wrote:
>> >>
>> >> Hey Brian,
>> >> looks good, thanks for working on that!
>> >>
>> >> One question:
>> >>
>> >> >=C2=A0 =C2=A0Reverse proxies SHOULD only add the head= ers to requests that are
>> >> >=C2=A0 =C2=A0forwarded to trusted backend servers. >> >>
>> >> Why? What's the attack vector, security and/or privac= y implications
>> >> here?
>> >>
>> >> Best regards,
>> >> Piotr Sikora
>> >>
>> >> On Fri, Jul 14, 2017 at 6:59 PM, Brian Campbell
>> >> <bcampbe= ll@pingidentity.com> wrote:
>> >> > Just a not-so-subtle reminder that HTTPS Token Bindi= ng with TLS
>> >> > Terminating
>> >> > Reverse Proxies is one of the agenda items for Monda= y's meeting in
>> >> > Prague
>> >> > and it would be great if there was some familiarity = with it going
>> >> > into
>> >> > the
>> >> > meeting. It's relativity short as drafts go, if = you're looking for
>> >> > something
>> >> > to read en route to the meeting:
>> >> > https://tools.ietf.= org/html/draft-campbell-tokbind-ttrp-00
>> >> >
>> >> > CONFIDENTIALITY NOTICE: This email may contain confi= dential and
>> >> > privileged
>> >> > material for the sole use of the intended recipient(= s). Any review,
>> >> > use,
>> >> > distribution or disclosure by others is strictly pro= hibited.=C2=A0 If you
>> >> > have
>> >> > received this communication in error, please notify = the sender
>> >> > immediately
>> >> > by e-mail and delete the message and any file attach= ments from your
>> >> > computer. Thank you.
>> >> > _______________________________________________=
>> >> > Unbearable mailing list
>> >> > Unbearable@ie= tf.org
>> >> > https://www.ietf.org/mailman/= listinfo/unbearable
>> >> >
>> >
>> >
>> >
>> > CONFIDENTIALITY NOTICE: This email may contain confidential a= nd
>> > privileged
>> > material for the sole use of the intended recipient(s). Any r= eview, use,
>> > distribution or disclosure by others is strictly prohibited.= =C2=A0 If you
>> > have
>> > received this communication in error, please notify the sende= r
>> > immediately
>> > by e-mail and delete the message and any file attachments fro= m your
>> > computer. Thank you.
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged
> material for the sole use of the intended recipient(s). Any review, us= e,
> distribution or disclosure by others is strictly prohibited.=C2=A0 If = you have
> received this communication in error, please notify the sender immedia= tely
> by e-mail and delete the message and any file attachments from your > computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c13ead0d2bd6d055490a1f3-- From nobody Tue Jul 18 01:51:30 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCE7131DC6 for ; Tue, 18 Jul 2017 01:51:28 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qQhO8M_F2xg for ; Tue, 18 Jul 2017 01:51:26 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e: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 9A051131DD0 for ; Tue, 18 Jul 2017 01:51:15 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id u5so8990552pgq.3 for ; Tue, 18 Jul 2017 01:51:15 -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=IBnclmPkdguYMJx5DK8wwkO5W46KH70ZrpFZYtYSNOs=; b=nRhmn1An42NnqWSUHj+W5i6saM3dfWIQCK3n811lmmz6b2tT0SPllGkZFsCyCYpWxT QidHmOaWHZLvk6+/6yPBFfG+9Bahc9AwCg8VbKCkA1WNtdj44OijPplLTl7XV+QylYw9 vmLx0Vf1UTt646Ps0eWheU4KyqVzCE+jbzOtU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IBnclmPkdguYMJx5DK8wwkO5W46KH70ZrpFZYtYSNOs=; b=MfOGuZNC9XTMGpYcRB9x/IacEP1/wV4WsjGf6oVl9mnzQrYzgx1nfBRp2k98HweNo9 OnkgLSiFm0bWHZO0Wtw587R2aA7c6w3pLM6fZoFEv8anGuJRqZCDb3P2xVL4jaGcECuS bysUaTOSJWxAVGldFdR8Z3ywI0nFSU+jdtosHnpII+SunnFPJw/inWe8h4r9ufktQG9d VxIueWjA8mTHBPewaHLvqKfyITLgU2PtW4v8UThRk62mgvXTYwqrRbKNWS8pFfIu+jYC hZ+4HizK9s7wNXXaG2bHb+I4YEKK6HDUvXze2W/SX31rnzqU8zsWUArIUsCa/W2BBJxs aliw== X-Gm-Message-State: AIVw110vgChfwBk47WZzxpc8zdz4EHTPYdLw/UFTQAU7gs+UqcMZ0Upe ETBmy7xNRxBQdJGaqF9gLg+1Y9zuLlVtwr+eHhGcTIJsr7Iit1bTvPo5gnR6mNfTWudlMJBjhWM TfqVPd8BR7jE= X-Received: by 10.101.87.200 with SMTP id q8mr598743pgr.110.1500367875104; Tue, 18 Jul 2017 01:51:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Tue, 18 Jul 2017 01:50:44 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Tue, 18 Jul 2017 10:50:44 +0200 Message-ID: To: Eric Rescorla Cc: HTTP Working Group , IETF Tokbind WG Content-Type: multipart/alternative; boundary="089e08236ba03a7a2b0554939eff" Archived-At: Subject: Re: [Unbearable] Dealing with header injection through reverse proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 08:51:29 -0000 --089e08236ba03a7a2b0554939eff Content-Type: text/plain; charset="UTF-8" I perhaps didn't articulate it well in the meeting yesterday but I'd like to reiterate that, in my opinion and I don't think I'm alone, it would be very inappropriate for -tokbind-ttrp to define a one-off mechanism for the origin server to detect client injection of the headers. The potential problem of client header injection is not at all unique to the functionality of that draft so the draft shouldn't define a unique solution. It would be useful if there were a common standardized mechanism for doing detecting/preventing client header injection that the -tokbind-ttrp draft could refer to (the generic solution that Ekr mentions in his [1] seems preferable precisely because it is generally applicable). In the absence of a generic solution existing currently, stripping/sanitizing the headers is the de facto means of dealing with the situation in practice today, is sufficient when properly implemented, and is normatively required by the text in -tokbind-ttrp. It's true that, if the reverse proxy is defective/misconfigured, it doesn't fail safe but in the context of -tokbind-ttrp that failure mode is far from catastrophic. Such a failure loses the protections afforded by token binding, which is not ideal, but it is the current state of just about everything on the web today so it's not *that* bad. On Mon, Jul 17, 2017 at 5:18 PM, Eric Rescorla wrote: > i folks, > > We had a discussion today in TOKBIND about handling security-sensitive > indications in HTTP headers (this came up in the context of > https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-01). The > setting here is that you have a network with a TLS reverse proxy > serving the origin server, and the TLS proxy is responsible for doing > some security check and telling the server about it. E.g., > > Client Proxy Server > > <--- TLS w/ client auth ---> <----- HTTP with cert ---> > > The client does TLS client authentication with the proxy and then > passes the certificate to the back-end server in an injected HTTP > header (e.g., X-Client-Certificate). In order for this to be secure, > the proxy has to *strip* any security sensitive headers sent by the > client. Otherwise, the client could inject their own headers that > would appear to come from the proxy. > > Obviously, this design doesn't fail safe if the proxy fails to > strip the headers. One way in which this can happen is if you > have a large network of load balancers fronting a server network > and you somehow incompletely misconfigure either the servers > or the proxies, so that a server which supports this mechanism > ends up behind a proxy which does not (and hence does not strip > the headers). So, it would be nice to do something better that > wasn't too heavyweight, especailly as a general solution. > > One natural design is simply to have a shared key between the > proxy and the server. In that case, it's easy to demonstrate > that the header is injected, as in [0][1] > > X-Client-Certificate: , > > The obvious objection to this design is that it requires you to > establish the shared key, and people were concerned about having to > configure it into the proxy. I'm aware of a number of designs here: > > - Configure it via some sort of remote configuration mechanism. > - The proxy could send it to the server on its first request > (might require some trickery on the server). > - If you have a TLS channel between Proxy and Server you can > use a TLS exporter. > - If you have a H2 connection between the two, you can have the > server provide it in a settings frame. > - Use a signature by the proxy using its private key over something > e.g., S(K, "Token binding"). If you use a mostly fixed string, > then the server just needs to verify it once. > > Do people have other thoughts on this problem? Other good ways to > establish the key? Other ideas for how to address it? > > -Ekr > > > [0] I'd originally suggested HMACing, but that's actually not > necessary, though obviously stronger. > > [1] Note that you could have a generic solution, like a header which > listed all the injected headers, but with the same security mechanism. > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --089e08236ba03a7a2b0554939eff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I perhaps didn't articulate it well in the meetin= g yesterday but I'd like to reiterate that, in my opinion and I don'= ;t think I'm alone, it would be very inappropriate for -tokbind-ttrp to= define a one-off mechanism for the origin server to detect client injectio= n of the headers. The potential problem of client header injection is not a= t all unique to the functionality of that draft so the draft shouldn't = define a unique solution. It would be useful if there were a common standar= dized mechanism for doing detecting/preventing client header injection that= the -tokbind-ttrp draft could refer to (the generic solution that Ekr ment= ions in his [1] seems preferable precisely because it is generally applicab= le). In the absence of a generic solution existing currently, stripping/san= itizing the headers is the de facto means of dealing with the situation in = practice today, is sufficient when properly implemented, and is normatively= required by the text in -tokbind-ttrp. It's true that, if the reverse = proxy is defective/misconfigured, it doesn't fail safe but in the conte= xt of -tokbind-ttrp that failure mode is far from catastrophic. Such a fail= ure loses the protections afforded by token binding, which is not ideal, bu= t it is the current state of just about everything on the web today so it&#= 39;s not *that* bad.




=C2=A0
=

On Mon, Jul 17, 2= 017 at 5:18 PM, Eric Rescorla <ekr@rtfm.com> wrote:
i folks,

We had a discussion today in TOKBIND about handling security-sensitive
indications in HTTP headers (this came up in the context of
https://tools.ietf.org/html/draft-campbell-tokbind-tt= rp-01).=C2=A0 The
setting here is that you have a networ= k with a TLS reverse proxy
serving the origin server, and the TLS= proxy is responsible for doing
some security check and telling t= he server about it. E.g.,

=C2=A0 =C2=A0 Client =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Proxy =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Server
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 <--- TLS w/ client = auth ---> <----- HTTP with cert --->

The = client does TLS client authentication with the proxy and then
pas= ses the certificate to the back-end server in an injected HTTP
he= ader (e.g., X-Client-Certificate). In order for this to be secure,
the proxy has to *strip* any security sensitive headers sent by the
=
client. Otherwise, the client could inject their own headers that
would appear to come from the proxy.

Obvious= ly, this design doesn't fail safe if the proxy fails to
strip= the headers. One way in which this can happen is if you
have a l= arge network of load balancers fronting a server network
and you = somehow incompletely misconfigure either the servers
or the proxi= es, so that a server which supports this mechanism
ends up behind= a proxy which does not (and hence does not strip
the headers). S= o, it would be nice to do something better that
wasn't too he= avyweight, especailly as a general solution.

One n= atural design is simply to have a shared key between the
proxy an= d the server. In that case, it's easy to demonstrate
that the= header is injected, as in [0][1]

=C2=A0 =C2=A0X-C= lient-Certificate: <key>, <certificate>

The obvious objection to this design is that it requires you to
establish the shared key, and people were concerned about having to
<= div>configure it into the proxy. I'm aware of a number of designs here:=

- Configure it via some sort of remote configurat= ion mechanism.
- The proxy could send it to the server on its fir= st request
=C2=A0 (might require some trickery on the server).
- If you have a TLS channel between Proxy and Server you can
<= div>=C2=A0 use a TLS exporter.
- If you have a H2 connection betw= een the two, you can have the
=C2=A0 server provide it in a setti= ngs frame.
- Use a signature by the proxy using its private key o= ver something
=C2=A0 e.g., S(K, "Token binding"). If yo= u use a mostly fixed string,
=C2=A0 then the server just needs to= verify it once.

Do people have other thoughts on = this problem? Other good ways to
establish the key? Other ideas f= or how to address it?

-Ekr


[0] I'd originally suggested HMACing, but that's a= ctually not
necessary, though obviously stronger.

<= /div>
[1] Note that you could have a generic solution, like a header wh= ich
listed all the injected headers, but with the same security m= echanism.


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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --089e08236ba03a7a2b0554939eff-- From nobody Tue Jul 18 02:16:22 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B018131945 for ; Tue, 18 Jul 2017 02:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2td4TEGgFLSu for ; Tue, 18 Jul 2017 02:16:18 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 9150E131DC8 for ; Tue, 18 Jul 2017 02:16:18 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id 64so16287487uae.2 for ; Tue, 18 Jul 2017 02:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4zo8+Cj3pVLpcov7TmNNdLREt2rSh7lrsbGkJ7JC5Io=; b=NhDS4k92Cdy7otfUCKAvLkzUl78Zgcvp/6/KGQuRI8oA9cAtv2tFCYB8MfOgnxSD// kYRdabn94V78GWOwGPmjMy0ZLZS7RjVUXtKE+E4+4c8vB/5SlyK7EmujQkIMFeAGECyo I2dLcsMzSG2yXutQ1TghC/LeavM1IarQcK0x3DLBs7ll3LXKsvrRTInX1wvoqCJBB6K3 xr72GDR8rUPhGl39f/JpIOfQ91l4pLZ36jZZx4FFckj69MBjqK+gDhU9D9cqNGKl5aL+ uV3yAERVrQnmvs6tysz3WlJ62G18m4+11kgRZcaqKv1BVni3ZrlnOwv//QJUUb4vysNW qhlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4zo8+Cj3pVLpcov7TmNNdLREt2rSh7lrsbGkJ7JC5Io=; b=K2km8C4hzNJ15sEvsMU5wzMTgARtnf0MxhzHXeYrXN/NTd7hirf3g44veCwppoGTMs hXD0vFFseKKCHRP8xdsE4VR3y+8Upy+YM2B3mdtVy/p3kV3b8Wa50u9fjXWyC51Uz2S0 F3o3BTJ29thcu4SvQC/XEHmgqbNsKZmzsAb5YABMKvgeK6Kfg6f/+A7CVCF3rtaMhOOf YrPFBPKeAmsVMbSSQKUtzNpfCRL5iCwjRABnbrZkIHNTC5IS1H71UldSzQ7nMv4+jB4/ xuvc63kDZWZCSHr1YST5wsQhIU3MeBUABFcEdUgUhg2tVtjMBOCQEFSG/TwOmZ9LjLpP 2vtw== X-Gm-Message-State: AIVw112sXefSKgsxJBB6BvBwHK2d0GX02WYPy4Mfap6phrJF/QoPn70e G23u07hO59BVzsB+UeH1XjTbnl8ru1QK X-Received: by 10.31.133.80 with SMTP id h77mr320486vkd.14.1500369377475; Tue, 18 Jul 2017 02:16:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.176.67 with HTTP; Tue, 18 Jul 2017 02:16:16 -0700 (PDT) In-Reply-To: References: From: Piotr Sikora Date: Tue, 18 Jul 2017 11:16:16 +0200 Message-ID: To: Patrick McManus Cc: Eric Rescorla , HTTP Working Group , IETF Tokbind WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Unbearable] Dealing with header injection through reverse proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 09:16:20 -0000 Hey Patrick, > If the problem can be reduced to the above then I think there are some http > features that are worth considering if you're willing to look at it as a > single hop requirement: > > a] if the proxy->server link is h1 then the x-client-certificate name can be > included in the Connection header sent to the server (and the server can > enforce this property). Any naive proxy receiving that same combination from > a malicious client would remove the request-header of the same name before > forwarding it on to the server and then generate its own Connection header. This would work... but only in a single-hop deployments. > b] if the proxy->server link is h2 then you can inject connection-specific > information into the stream with an extension frame type (and the server can > enforce this property). You don't need to negotiate it with SETTINGS (which > is nice, because that's a round trip.) and these frames are hop to hop > (proxies that don't understand a frame type MUST drop them). Putting "internal" headers into a new HTTP/2 frame instead of mixing them with client headers in the HEADERS frame is the idea that I've been toying for a while now, mostly for multi-hop proxy deployments. However, it's unclear whether the backend server should receive only client headers (which wouldn't solve this particular issue) or both, and how should this work with "internal" headers crossing organizational boundaries (i.e. CDN terminating TLS and forwarding "X-Client-Certificate" header to the origin server). Also, this requires end-to-end HTTP/2, which is pretty much non-existent nowadays, since most proxies don't support HTTP/2 to backends (yet). Having said that, this is something that I definitely want to see done, regardless of whether it's the right solution for this particular issue or not. Best regards, Piotr Sikora From nobody Tue Jul 18 02:20:23 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB8E131DD2 for ; Tue, 18 Jul 2017 02:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2PwBgNcX7Ol for ; Tue, 18 Jul 2017 02:20:20 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 83B72131DC7 for ; Tue, 18 Jul 2017 02:20:18 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id z22so16345628uah.1 for ; Tue, 18 Jul 2017 02:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pnJj1xGMWzkB/dY6mU5c042WxmIomRLVLQyZbaVVsVw=; b=Ok6Yd3EmzzRJYfJlR+HBMPB8LEUzacFuK9kCcSsX2xo4FV1uatJ+XCO/KyY2SG72ee zPMt5wDIa7sy5OoZrvUcT02x2nN1hMM6Upu8FyCxuwazJAaRv5NzpSg6Q6tJip2pPk+M 1mEQ8u+3RASIAX8/tTAuANDiXmFAjqF/j4QiUokHycFRqGXrY6arXm6xNHMkhmhRfi8e ZdAAZ9kG9EFBOKi6KV1muLW1S3HHuw09d4WJju/vlJB46CWBgkKzxq+GmdEVJdjUMDiK 85jY/ra3Dvd1faRYQ6C2wYgMCIiUInpNlO3lTztkSUqwjSlMhqhOsnX/lfuvjcc18BSg vaug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pnJj1xGMWzkB/dY6mU5c042WxmIomRLVLQyZbaVVsVw=; b=Hw0R9dq6qrWEWDJkTxl4y/KqBFWW8XFgZiqecT+9uFIb0nH8QQcEqeBaz6l7usIzUv 9GMTyqstmzeMJlLFTZFbcn9omYvkDtUKfWlY2AI6ew0N6FgAcanozeEUcydqh3hANT8R uGEn2zyipircYNbSf5PQytTdnOaQPM5+SW2HZC3dug6crytE2/PUwVT44Qk0Wdh6gS/9 0WzNgpZ/ut700NXbjFlabS/k4JL+U6aBgyO7NxKGLcH6kszCLxaAbpphPw2Nj9p2Akfz sLsFKWn3bgVmTmkBU5swpijbpcH3jbeWTG4I4ODrHGdpHbiYRyt/pNyvfuI7HqdYgD2J gW3g== X-Gm-Message-State: AIVw113/8ToV5leQhggZPprjlLwxHY2//RBqCxJzZTItysWjvlh2EbBF o7OibP4h8EkX8WTa4N1FvQ/XPy/0n9O8rq0= X-Received: by 10.31.169.15 with SMTP id s15mr371620vke.70.1500369617468; Tue, 18 Jul 2017 02:20:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.176.67 with HTTP; Tue, 18 Jul 2017 02:20:16 -0700 (PDT) In-Reply-To: <20170717184507.GA10072@1wt.eu> References: <20170717184507.GA10072@1wt.eu> From: Piotr Sikora Date: Tue, 18 Jul 2017 11:20:16 +0200 Message-ID: To: Willy Tarreau Cc: Eric Rescorla , IETF Tokbind WG , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Unbearable] Dealing with header injection through reverse proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 09:20:22 -0000 Hey Willy, > What I've seen and used was slightly different : > 1) proxies unconditionally remove the header field > 2) proxies unconditionally add the new header field even with no > certificate > 3) servers verify that there is exactly one header field > > This way even if step 1 above fails (eg: usual typo in the rule needed > to strip the header field which nobody notices since nobody injects > such a field name), step 2 ensures that any injection will be detected > in step 3. This is exactly what the current draft suggests and what EKR objects, because misconfigured proxy that doesn't know about "X-Client-Certificate" won't execute steps 1-3 for the "X-Client-Certificate" header. Best regards, Piotr Sikora From nobody Tue Jul 18 02:23:44 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2B4131945 for ; Tue, 18 Jul 2017 02:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0IGFP3bXXMf for ; Tue, 18 Jul 2017 02:23:41 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418D6131A67 for ; Tue, 18 Jul 2017 02:23:41 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id y47so1137828uag.0 for ; Tue, 18 Jul 2017 02:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FGL7N6oYtCPhiVOp9aFcVoFgD1pkDDHgjpTstfpAzUg=; b=Re16EI3fGlDhZCp4e0UC4Jk1O1zQR4owJDjZvlgy0zSRui4gdh9yGIBvDKAChsonpA UoG4HS47D9qWkVvTYMG7kvlzM70O5HyieWBTJ/2mBSGgJbtxAgRUXBMRuJ7z3tRVdxgv BSG3cQqSt4/3NNPb7RW8sH+nJS/w7NmNPj0nQb3gUrk1+l0CKdEr2GdNYmaoPdW8yXQh hYA7Hr+G6WEjq0+4qywTYFSzxJwZ4Pg/PxPPAscf3qccc/ULaKFE/5wJjqRW4P0oJWlV piJvczjEMz9WXuBFKANCnugABPDhJdZIusuvBqno8DTg98ssv/iw2X/pZ4/pauh3dtQc /KBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FGL7N6oYtCPhiVOp9aFcVoFgD1pkDDHgjpTstfpAzUg=; b=kicktd/choQ9GZ2WYea/ql04+1ySXVRbVjvybC+/l4G8jkW0geQh0eF4tnfQbgVvCf aJP1eELtUfRWKoSmI352DLvrAU/d/eypLvLUgtUwXi06dmNZPqiGhZoyAvHuIeSrlSfd aocFF41RHaFZx+0TfOOe5zbNuFXVEUNebaBcDvFmGnPk8ZZ+nJNrbpuR5r6NelxUrjqW LZSk+5PyCKPIrd3A2tjHtN3a2mYpHmLsxyyU8OD/8UbQL3tvI5n0cEWg3hwLH7NRYftx qTlmJM+RVV6VYKtI+GWdxsQ1bgq8i0JCH99wchXcuyPdtKfpaPMqEzcwqlabWyErujIE gdzw== X-Gm-Message-State: AIVw1131aCzaOE8TnYN5RjZiGqD/RNGDPUhefu8FoKmbY51Ywv+PXCTi Ackq/7MW93jryHXXGxUEt/ipUeHgQZPQ X-Received: by 10.159.49.19 with SMTP id m19mr384257uab.46.1500369820107; Tue, 18 Jul 2017 02:23:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.176.67 with HTTP; Tue, 18 Jul 2017 02:23:39 -0700 (PDT) In-Reply-To: References: From: Piotr Sikora Date: Tue, 18 Jul 2017 11:23:39 +0200 Message-ID: To: Brian Campbell Cc: Eric Rescorla , IETF Tokbind WG , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Unbearable] Dealing with header injection through reverse proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 09:23:43 -0000 Hey Brian, > I perhaps didn't articulate it well in the meeting yesterday but I'd like to > reiterate that, in my opinion and I don't think I'm alone, it would be very > inappropriate for -tokbind-ttrp to define a one-off mechanism for the origin > server to detect client injection of the headers. The potential problem of > client header injection is not at all unique to the functionality of that > draft so the draft shouldn't define a unique solution. It would be useful if > there were a common standardized mechanism for doing detecting/preventing > client header injection that the -tokbind-ttrp draft could refer to (the > generic solution that Ekr mentions in his [1] seems preferable precisely > because it is generally applicable). In the absence of a generic solution > existing currently, stripping/sanitizing the headers is the de facto means > of dealing with the situation in practice today, is sufficient when properly > implemented, and is normatively required by the text in -tokbind-ttrp. It's > true that, if the reverse proxy is defective/misconfigured, it doesn't fail > safe but in the context of -tokbind-ttrp that failure mode is far from > catastrophic. Such a failure loses the protections afforded by token > binding, which is not ideal, but it is the current state of just about > everything on the web today so it's not *that* bad. I agree. I don't believe that TOKBIND-TTRP draft should be blocked on this. Best regards, Piotr Sikora From nobody Tue Jul 18 02:27:12 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC90E131AE6 for ; Tue, 18 Jul 2017 02:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6FB9nWfR54P for ; Tue, 18 Jul 2017 02:27:04 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 ABEEA131DD5 for ; Tue, 18 Jul 2017 02:27:03 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id a10so20470658wrd.0 for ; Tue, 18 Jul 2017 02:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=SX9Vub6fBW9CoyXGquWrY5FiKg9Jsj89bIgFhizZ30I=; b=cNQxNMcIuWBgJ4d8IRuzm5R6O61/qDGn8VDxZMU2wPQc3DFcAMO3UO+/uFH2nSFuly V+ftCdk3P/E+qQ75In2IOkxzgI0VFFYeTxfl3Hmclj4gPAhsMpDn0gZt1gO3t32RCvSa kyaxNzD1b09nTA6AQBN/hEQNaPUhC5uD8oij99R+O+IRQ3JDMsyx4+VrILkYIVASiOcI RIU/yaubKFgmI7GP/iu5ERyzZQHcpFb+l0w2VA2CNu3SHIeN0Vo21xx3mnnoFQr3hpGC UK2oU+TXycgCWYjE2JhymOp3GBwN7UoR3z9Q6SN01tMKMmyBXYG7yZRfzDQULeH6Z4fB oTWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SX9Vub6fBW9CoyXGquWrY5FiKg9Jsj89bIgFhizZ30I=; b=FOBbtozBk8s667sDrEM4+dt6CozDsXGIMnjqbViuNClvGFLGLMF3U4I8YnxZhvt1Rt 0EcSZZyFRtkotSICq+NKkwOS63Ap+ziNEGGGXbMMy/bUFNHtAekmdxwHS7addPGRihop PYH5ru+7v9WCPHyxUflrMLs7RFxIOHEjQzPzVQHv9BIpNAdx42j35cF7yL628eyikNG0 zhlIeVQbJCzDMMERD53HzbDtwltQ4Y8FNVFX3Ys2ztQBJjskdPRaSZpSqu2kJuVD55up Xyt91Hl7zsSvYU3liOEvEAdxgMGO3e02aMmd6GbqLnPm5G/2Dcc0fnUNR0gy5QFp/MiU 5Ftg== X-Gm-Message-State: AIVw1113UlQUXu3/6/5AktgtwFgqS6OS+himaNGklvvrSKRXllfjDiJn JhL6CD8vWaaoShKKdUvVPQ== X-Received: by 10.223.161.11 with SMTP id o11mr546951wro.16.1500370021715; Tue, 18 Jul 2017 02:27:01 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:fd4d:a3a2:d45d:796b? ([2001:67c:370:128:fd4d:a3a2:d45d:796b]) by smtp.gmail.com with ESMTPSA id w142sm454263wme.5.2017.07.18.02.27.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 02:27:01 -0700 (PDT) To: unbearable@ietf.org References: From: Leif Johansson Message-ID: Date: Tue, 18 Jul 2017 11:27:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Unbearable] Dealing with header injection through reverse proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 09:27:11 -0000 > Having said that, this is something that I definitely want to see > done, regardless of whether it's the right solution for this > particular issue or not. With my chair hat on I'll note that this threat is sent to both the tokbind list and the http WG list I am however working on the assumption that if a general solution for protection against header injection turns up it will probably not get done in this WG I also think it is up to the WG to decide if we want to depend on such a solution or stick to Brians approach of saying "you MUST have solution" in the security considerations section (and potentially dealing with an IESG DISCUSS at a later stage). Cheers Leif From nobody Tue Jul 18 02:27:43 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1CC131DC9 for ; Tue, 18 Jul 2017 02:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.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 YAhTiuVLGTDb for ; Tue, 18 Jul 2017 02:27:31 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 0D9B0131DCE for ; Tue, 18 Jul 2017 02:27:31 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id q85so8759319pfq.1 for ; Tue, 18 Jul 2017 02:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eardcHx57DyFGnCZvH0PqvCA2VSV9snsk2uxs20wX1A=; b=EPxVmZhbj3xe1RQ7ON9h6uNAAzcTwYfUDk2BZWqK1t3BPs8FFacJBXx8Wum8GLoR4K 0cyIQLDTfqA3qDjQPOd1buWURU6HO0DoVWF8FPyOkN05g8ul0ewfPDLZmUalglTtGG/1 SsdkWv3GOaqaAlFR/ZKa3/QZFetpaGlRbUtobj4hmWUIW7OwtFfYQ4dfVxiBOUdzujNI tEqJETmyM8PxKcCAmDEutUBjIpVd8rx5wiaJKHPm6XwApti7jqy5ZILeJFhUuEaRP+Ao VGQlHo3rFG4phz8/Qk9rI4TBhtdOdka0aXkrHn5UdOzMRni6APbmYGFdqLdhVipW9d/l faAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eardcHx57DyFGnCZvH0PqvCA2VSV9snsk2uxs20wX1A=; b=FpmQFATUrquRZvx3+t7GdvqRnf/a/WeX1HmmoLhbof1tGee0BF1XACQ96vpZF6Bnf3 4Lj4FtYXPPs/xXr+Uvg24ajhMSFNcsCfYuVRZkBdpEGBBt/VG5UoJb29+aKYIZn4nUhm gEsSW4AlVTx9u5ejheltB4kl8zjGdypOTYKgKE3x45klmmmH/Kgf5nAY4EAjJoJWuqwj 7wwRC8F/vDU4AekZzLdv2/knLvjetNogOBZ+qtebuEiVw5fHMkuev0jjQ96DGmU7zDCW U+v5HgYPLPCxbA+vLrjI44ZaMNs9YQnoB6Qt9EdsEXbvDpn1KdDUIuLMbQOLjtwsWNmc SPvQ== X-Gm-Message-State: AIVw111E6+R6UD+rcOwtryV7HpS9GT9JOb+cO5w3XVnfdmuH5jJxfSy3 pDxiBXKVDVDeSul/jZnWEI/ITvypKoHy X-Received: by 10.84.211.34 with SMTP id b31mr766435pli.230.1500370050629; Tue, 18 Jul 2017 02:27:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.137.2 with HTTP; Tue, 18 Jul 2017 02:27:09 -0700 (PDT) In-Reply-To: References: From: Joseph Salowey Date: Tue, 18 Jul 2017 11:27:09 +0200 Message-ID: To: Brian Campbell Cc: Eric Rescorla , IETF Tokbind WG , HTTP Working Group Content-Type: multipart/alternative; boundary="001a114c7a6ce65bfe0554941fbc" Archived-At: Subject: Re: [Unbearable] Dealing with header injection through reverse proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 09:27:40 -0000 --001a114c7a6ce65bfe0554941fbc Content-Type: text/plain; charset="UTF-8" I agree that this is a larger problem than just the token binding headers and is a problem with proxy generated headers in general. Also if sanitization is properly implemented it solves the problem of header injection, however over the years I have run into many situations where proxies are mis-configured allowing header injection with sometimes disastrous consequences. I'd like to see a more fail-safe approach. In my experience these deployments usually have the following characteristics: 1. There is usually configuration required on both proxy and application. I think it would be possible to coordinate a secret in most cases, but it would be additional work. 2. TLS is often not deployed between proxy and application, however it might be OK to require TLS for a secure deployment. 3. H2 is often not deployed, however this may change over time. 4. The proxy often generates multiple headers and it would be good to protect all of them. On Tue, Jul 18, 2017 at 10:50 AM, Brian Campbell wrote: > I perhaps didn't articulate it well in the meeting yesterday but I'd like > to reiterate that, in my opinion and I don't think I'm alone, it would be > very inappropriate for -tokbind-ttrp to define a one-off mechanism for the > origin server to detect client injection of the headers. The potential > problem of client header injection is not at all unique to the > functionality of that draft so the draft shouldn't define a unique > solution. It would be useful if there were a common standardized mechanism > for doing detecting/preventing client header injection that the > -tokbind-ttrp draft could refer to (the generic solution that Ekr mentions > in his [1] seems preferable precisely because it is generally applicable). > In the absence of a generic solution existing currently, > stripping/sanitizing the headers is the de facto means of dealing with the > situation in practice today, is sufficient when properly implemented, and > is normatively required by the text in -tokbind-ttrp. It's true that, if > the reverse proxy is defective/misconfigured, it doesn't fail safe but in > the context of -tokbind-ttrp that failure mode is far from catastrophic. > Such a failure loses the protections afforded by token binding, which is > not ideal, but it is the current state of just about everything on the web > today so it's not *that* bad. > > > > > > > On Mon, Jul 17, 2017 at 5:18 PM, Eric Rescorla wrote: > >> i folks, >> >> We had a discussion today in TOKBIND about handling security-sensitive >> indications in HTTP headers (this came up in the context of >> https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-01). The >> setting here is that you have a network with a TLS reverse proxy >> serving the origin server, and the TLS proxy is responsible for doing >> some security check and telling the server about it. E.g., >> >> Client Proxy Server >> >> <--- TLS w/ client auth ---> <----- HTTP with cert ---> >> >> The client does TLS client authentication with the proxy and then >> passes the certificate to the back-end server in an injected HTTP >> header (e.g., X-Client-Certificate). In order for this to be secure, >> the proxy has to *strip* any security sensitive headers sent by the >> client. Otherwise, the client could inject their own headers that >> would appear to come from the proxy. >> >> Obviously, this design doesn't fail safe if the proxy fails to >> strip the headers. One way in which this can happen is if you >> have a large network of load balancers fronting a server network >> and you somehow incompletely misconfigure either the servers >> or the proxies, so that a server which supports this mechanism >> ends up behind a proxy which does not (and hence does not strip >> the headers). So, it would be nice to do something better that >> wasn't too heavyweight, especailly as a general solution. >> >> One natural design is simply to have a shared key between the >> proxy and the server. In that case, it's easy to demonstrate >> that the header is injected, as in [0][1] >> >> X-Client-Certificate: , >> >> The obvious objection to this design is that it requires you to >> establish the shared key, and people were concerned about having to >> configure it into the proxy. I'm aware of a number of designs here: >> >> - Configure it via some sort of remote configuration mechanism. >> - The proxy could send it to the server on its first request >> (might require some trickery on the server). >> - If you have a TLS channel between Proxy and Server you can >> use a TLS exporter. >> - If you have a H2 connection between the two, you can have the >> server provide it in a settings frame. >> - Use a signature by the proxy using its private key over something >> e.g., S(K, "Token binding"). If you use a mostly fixed string, >> then the server just needs to verify it once. >> >> Do people have other thoughts on this problem? Other good ways to >> establish the key? Other ideas for how to address it? >> >> -Ekr >> >> >> [0] I'd originally suggested HMACing, but that's actually not >> necessary, though obviously stronger. >> >> [1] Note that you could have a generic solution, like a header which >> listed all the injected headers, but with the same security mechanism. >> >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --001a114c7a6ce65bfe0554941fbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that this is a larger problem than just the token = binding headers and is a problem with proxy generated headers in general.= =C2=A0 Also if sanitization is properly implemented it solves the problem o= f header injection, however over the years I have run into many situations = where proxies are mis-configured allowing header injection with sometimes d= isastrous consequences. =C2=A0 I'd like to see a more fail-safe approac= h.=C2=A0

In my experience these deployments usually have= the following characteristics:
1. There is usually configuration= required on both proxy and application.=C2=A0 I think it would be possible= to coordinate a secret in most cases, but it would be additional work.=C2= =A0
2. TLS is often not deployed between proxy and application, h= owever it might be OK to require TLS for a secure deployment.
3. = H2 is often not deployed, however this may change over time.=C2=A0
4. The proxy often generates multiple headers and it would be good to pro= tect all of them.=C2=A0

On Tue, Jul 18, 2017 at 10:50 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
I perhaps didn't articulate it well in= the meeting yesterday but I'd like to reiterate that, in my opinion an= d I don't think I'm alone, it would be very inappropriate for -tokb= ind-ttrp to define a one-off mechanism for the origin server to detect clie= nt injection of the headers. The potential problem of client header injecti= on is not at all unique to the functionality of that draft so the draft sho= uldn't define a unique solution. It would be useful if there were a com= mon standardized mechanism for doing detecting/preventing client header inj= ection that the -tokbind-ttrp draft could refer to (the generic solution th= at Ekr mentions in his [1] seems preferable precisely because it is general= ly applicable). In the absence of a generic solution existing currently, st= ripping/sanitizing the headers is the de facto means of dealing with the si= tuation in practice today, is sufficient when properly implemented, and is = normatively required by the text in -tokbind-ttrp. It's true that, if t= he reverse proxy is defective/misconfigured, it doesn't fail safe but i= n the context of -tokbind-ttrp that failure mode is far from catastrophic. = Such a failure loses the protections afforded by token binding, which is no= t ideal, but it is the current state of just about everything on the web to= day so it's not *that* bad.




=C2=A0
<= /div>

<= div class=3D"h5">On Mon, Jul 17, 2017 at 5:18 PM, Eric Rescorla <ekr@rtfm.com= > wrote:
<= div class=3D"h5">
i folks,

We= had a discussion today in TOKBIND about handling security-sensitive
<= div>indications in HTTP headers (this came up in the context of
<= a href=3D"https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-01" targe= t=3D"_blank">https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-0= 1).=C2=A0 The
setting here is that you have a network wi= th a TLS reverse proxy
serving the origin server, and the TLS pro= xy is responsible for doing
some security check and telling the s= erver about it. E.g.,

=C2=A0 =C2=A0 Client =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Proxy =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Server
=
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 <--- TLS w/ client auth= ---> <----- HTTP with cert --->

The clie= nt does TLS client authentication with the proxy and then
passes = the certificate to the back-end server in an injected HTTP
header= (e.g., X-Client-Certificate). In order for this to be secure,
th= e proxy has to *strip* any security sensitive headers sent by the
client. Otherwise, the client could inject their own headers that
would appear to come from the proxy.

Obviously, = this design doesn't fail safe if the proxy fails to
strip the= headers. One way in which this can happen is if you
have a large= network of load balancers fronting a server network
and you some= how incompletely misconfigure either the servers
or the proxies, = so that a server which supports this mechanism
ends up behind a p= roxy which does not (and hence does not strip
the headers). So, i= t would be nice to do something better that
wasn't too heavyw= eight, especailly as a general solution.

One natur= al design is simply to have a shared key between the
proxy and th= e server. In that case, it's easy to demonstrate
that the hea= der is injected, as in [0][1]

=C2=A0 =C2=A0X-Clien= t-Certificate: <key>, <certificate>

Th= e obvious objection to this design is that it requires you to
est= ablish the shared key, and people were concerned about having to
= configure it into the proxy. I'm aware of a number of designs here:

- Configure it via some sort of remote configuration = mechanism.
- The proxy could send it to the server on its first r= equest
=C2=A0 (might require some trickery on the server).
<= div>- If you have a TLS channel between Proxy and Server you can
= =C2=A0 use a TLS exporter.
- If you have a H2 connection between = the two, you can have the
=C2=A0 server provide it in a settings = frame.
- Use a signature by the proxy using its private key over = something
=C2=A0 e.g., S(K, "Token binding"). If you us= e a mostly fixed string,
=C2=A0 then the server just needs to ver= ify it once.

Do people have other thoughts on this= problem? Other good ways to
establish the key? Other ideas for h= ow to address it?

-Ekr

[0] I'd originally suggested HMACing, but that's actua= lly not
necessary, though obviously stronger.

[1] Note that you could have a generic solution, like a header which<= /div>
listed all the injected headers, but with the same security mecha= nism.


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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.
____________________= ___________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearabl= e


--001a114c7a6ce65bfe0554941fbc-- From minfrin@sharp.fm Tue Jul 18 03:54:03 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53B7129459 for ; Tue, 18 Jul 2017 03:54:03 -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, RP_MATCHES_RCVD=-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=sharp.fm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sV84vVANRjyw for ; Tue, 18 Jul 2017 03:54:01 -0700 (PDT) Received: from chandler.sharp.fm (chandler.sharp.fm [80.168.143.3]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6D7127058 for ; Tue, 18 Jul 2017 03:54:01 -0700 (PDT) Received: from [10.105.12.110] (unknown [5.56.169.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: minfrin@sharp.fm) by chandler.sharp.fm (Postfix) with ESMTPSA id 8B8C76B043; Tue, 18 Jul 2017 11:44:52 +0100 (BST) DKIM-Filter: OpenDKIM Filter v2.11.0 chandler.sharp.fm 8B8C76B043 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sharp.fm; s=default; t=1500374692; bh=yDYmlFkymIg2OAEdah7zI5yt76DdVijv4HWFc3QOCTM=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=cyZpTd8qxaCeELri7KdYEE6x03O6a+ekZJ5MQYDh1+oJvdtMKfZLv76zlgbJG+DK/ zphub+i/ZhXY5+xgS6I4pKn4cVOF7XzN8GpNdzWf+kEEFwIRF+IxafAYtBoN2MNOrI r2hM0QcL3FsMTB9UmNgCSU86bN2qvnajzf1DWmPk= From: Graham Leggett Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D323B12A-6C2B-43F9-A2EC-C660F334983A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 18 Jul 2017 12:53:59 +0200 In-Reply-To: Cc: HTTP Working Group , IETF Tokbind WG To: Eric Rescorla References: X-Mailer: Apple Mail (2.3273) Archived-At: X-Mailman-Approved-At: Tue, 18 Jul 2017 04:41:27 -0700 Subject: Re: [Unbearable] Dealing with header injection through reverse proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 10:54:49 -0000 --Apple-Mail=_D323B12A-6C2B-43F9-A2EC-C660F334983A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 17 Jul 2017, at 5:18 PM, Eric Rescorla wrote: > We had a discussion today in TOKBIND about handling security-sensitive > indications in HTTP headers (this came up in the context of > https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-01 = ). The > setting here is that you have a network with a TLS reverse proxy > serving the origin server, and the TLS proxy is responsible for doing > some security check and telling the server about it. E.g., >=20 > Client Proxy Server > =20 > <--- TLS w/ client auth ---> <----- HTTP with cert =E2=80=94> A few years ago I needed to solve this problem. I needed a secure, typo-proof way of passing the original IP address = from the frontend endpoints, through various reverse proxies, through = various service layers which in turn were fronted with various reverse = proxies, to an eventual service that cared what the IP address was. In this scenario, it is trivial to misconfigure things and have the = wrong IP address passed on, which was a problem for us. What we had was a signed header: X-Foo: SIGNATUREORERROR;value The frontend endpoint would sign this header, turning X-Foo: value into = the above. Each layer that the header passed through that cared would then verify = the header, and if the header verified successfully it would be passed = through unchanged. If the header did not verify, the contents of the = header was replaced with an error message like so and the value = discarded: X-Foo: error:signature-expired-or-whatever; What this did was two things: - Any value that couldn=E2=80=99t be verified was discarded, ie the part = after the semicolon was made blank. This stopped developers ignoring the = failed signatures. - The error message was put there so that a bone could be thrown to = whoever had to troubleshoot the header. The error would include the IP = address of the node that discarded the value, and what the error was. I can dig out the pattern we used, it solved a lot of practical problems = with signing headers. Regards, Graham =E2=80=94 --Apple-Mail=_D323B12A-6C2B-43F9-A2EC-C660F334983A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On 17 Jul 2017, at 5:18 PM, Eric Rescorla <ekr@rtfm.com> wrote:

We = had a discussion today in TOKBIND about handling security-sensitive
indications in HTTP headers (this came up in the context = of
https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-01)= .  The
setting here is that you have a network = with a TLS reverse proxy
serving the origin server, = and the TLS proxy is responsible for doing
some = security check and telling the server about it. E.g.,

    Client =                   =  Proxy                 =     Server
    
    <--- TLS w/ client auth ---> <----- = HTTP with cert =E2=80=94>

A few years ago I needed to solve this = problem.

I needed a secure, = typo-proof way of passing the original IP address from the frontend = endpoints, through various reverse proxies, through various service = layers which in turn were fronted with various reverse proxies, to an = eventual service that cared what the IP address was.

In this scenario, it is trivial to misconfigure = things and have the wrong IP address passed on, which was a problem for = us.

What we had was a signed = header:

X-Foo: = SIGNATUREORERROR;value

The frontend = endpoint would sign this header, turning X-Foo: value into the = above.

Each layer that the header = passed through that cared would then verify the header, and if the = header verified successfully it would be passed through unchanged. If = the header did not verify, the contents of the header was replaced with = an error message like so and the value discarded:

X-Foo: = error:signature-expired-or-whatever;

What this did was two things:

- Any value that couldn=E2=80=99t be verified was = discarded, ie the part after the semicolon was made blank. This stopped = developers ignoring the failed signatures.

- The error message was put there so that a bone = could be thrown to whoever had to troubleshoot the header. The error = would include the IP address of the node that discarded the value, and = what the error was.

I can dig out = the pattern we used, it solved a lot of practical problems with signing = headers.

Regards,
Graham
=E2=80=94
<= div>
= --Apple-Mail=_D323B12A-6C2B-43F9-A2EC-C660F334983A-- From nobody Tue Jul 18 04:49:29 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56868131DF4 for ; Tue, 18 Jul 2017 04:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 WjxPnuHLR_1w for ; Tue, 18 Jul 2017 04:49:25 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0B165131B13 for ; Tue, 18 Jul 2017 04:49:24 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v6IBnJ11012231; Tue, 18 Jul 2017 13:49:19 +0200 Date: Tue, 18 Jul 2017 13:49:19 +0200 From: Willy Tarreau To: Piotr Sikora Cc: Eric Rescorla , IETF Tokbind WG , HTTP Working Group Message-ID: <20170718114919.GA11568@1wt.eu> References: <20170717184507.GA10072@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Subject: Re: [Unbearable] Dealing with header injection through reverse proxies X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 11:49:27 -0000 Hi Piotr, On Tue, Jul 18, 2017 at 11:20:16AM +0200, Piotr Sikora wrote: > Hey Willy, > > > What I've seen and used was slightly different : > > 1) proxies unconditionally remove the header field > > 2) proxies unconditionally add the new header field even with no > > certificate > > 3) servers verify that there is exactly one header field > > > > This way even if step 1 above fails (eg: usual typo in the rule needed > > to strip the header field which nobody notices since nobody injects > > such a field name), step 2 ensures that any injection will be detected > > in step 3. > > This is exactly what the current draft suggests and what EKR objects, > because misconfigured proxy that doesn't know about > "X-Client-Certificate" won't execute steps 1-3 for the > "X-Client-Certificate" header. In fact, all depends on the amount of misconfiguration expected. If we have to consider that a proxy suddenly becomes totally transparent, then prepending a secret token before the actual value detects it. Willy From nobody Wed Jul 19 10:16:14 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23B7131A55 for ; Wed, 19 Jul 2017 10:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sR2FCTJoZYm for ; Wed, 19 Jul 2017 10:16:04 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D02131474 for ; Wed, 19 Jul 2017 10:16:04 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id s4so2870535pgr.5 for ; Wed, 19 Jul 2017 10:16:04 -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=gcC/KmsPLyIyueM85A0fucKq+zhiJUUNfcAJ1eVePgw=; b=WHSBIVIS+fs2lIEushzXCwjKOqDXMBk+3KjfArzLC1BQBOce4R17xlCmv9Q4Ov/XLw oIycK1r4Xe+bpRURut4d5DxdnuJmQQW/CMD48O8fZGNIR2MHpigCrKFxy2YZUyICknaU RI/6/zgewMe6K9dm5mK6cJ8Azu3Bq2212gBB0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gcC/KmsPLyIyueM85A0fucKq+zhiJUUNfcAJ1eVePgw=; b=UwUt6pcx42wOXg79Ja1VJeUdcMOCVi4JBcTE6AyoatDWJx+Q3XL4LZTJuASGrLxNNm 4z7uQhxxVZRMfrXbsY6uGAGRgf2WndwzvEvsak0nIhmfrdK7v9sOonx1phL9RmTkP5s3 OLckj3LeZWV9w0Y/yErubPgO4mwoxDuadBdAH4QdVEBpb30Mywq0G5305HV7tvakci+Z PEn90xQcYYnYoBZgEuuL2mI2wVJcy5EAKRl8tyVM3atxU/iCE8CQ8D4vO2z0F+NfbIl7 xtehpzbSUUNuSn7MhVP/V+DEjtUzkDmhBvB/XWzDPJN2cAfi7ehxEYNmM8yFaBW5xTUk 5Z+Q== X-Gm-Message-State: AIVw1111twHNANsumtj0wwT+LcyGdLFKpmxftVcvYuP6c23oHYm6Wqg7 Tu2vdfwAvDVo6S5oY2jwtuMRPww+ANj+AJmMwIpSPH2BBQE7qINuCiKZyuTRgcz+gW5Ixua6HUU DiG1CLUwINO4= X-Received: by 10.84.231.15 with SMTP id f15mr872007plk.253.1500484564038; Wed, 19 Jul 2017 10:16:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Wed, 19 Jul 2017 10:15:33 -0700 (PDT) In-Reply-To: References: <853ba12d-5859-1545-611d-74f0b1fbf533@sunet.se> From: Brian Campbell Date: Wed, 19 Jul 2017 19:15:33 +0200 Message-ID: To: Anthony Nadalin Cc: Leif Johansson , IETF Tokbind WG Content-Type: multipart/alternative; boundary="f403043607d86e5a080554aec9fa" Archived-At: Subject: Re: [Unbearable] WG adoption of draft-campbell-tokbind-ttrp-00 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 17:16:13 -0000 --f403043607d86e5a080554aec9fa Content-Type: text/plain; charset="UTF-8" The intent of the draft is to help facilitate interoperability between independently developed and/or deployed components. And there is value in standardization for that. But of course conformance to the draft isn't required in cases, like perhaps those that you mention where everything is within your own infrastructure, where that kind of interoperability isn't important. On Mon, Jul 17, 2017 at 10:35 PM, Anthony Nadalin wrote: > So I'm not sure of the value of this as we and the their companies have > already implemented solutions that are different than what is being > proposed. This also does not work for a lot of our use cases where there is > an untrusted proxy. Most of our cases are also within our own > infrastructure so no question the need for standardization. > > ------------------------------ > *From:* Unbearable on behalf of Leif > Johansson > *Sent:* Monday, July 17, 2017 5:50:20 PM > *To:* IETF Tokbind WG > *Subject:* [Unbearable] WG adoption of draft-campbell-tokbind-ttrp-00 > > > In the f2f meeting in Prague there was clear consensus to adopt > draft-campbell-tokbind-ttrp-00 as draft-ietf-tokbind-ttrp-00 > making this a WG document. > > If anyone on the list disagrees, now is the time to speak up. > > Cheers Leif & John > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Funbearable&data=02%7C01% > 7Ctonynad%40microsoft.com%7C06e4b840a7a94372b5e008d4cd2b8f26% > 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636359034357583877&sdata= > hW8BlMQm1Sf%2BjDXeAQ9%2BeHIxXMroROFSuegdWpdX8DA%3D&reserved=0 > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --f403043607d86e5a080554aec9fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The intent of the draft is to help facilitate interoperab= ility between independently developed and/or deployed components. And there= is value in standardization for that. But of course conformance to the dra= ft isn't required in cases, like perhaps those that you mention where e= verything is within your own infrastructure, where that kind of interoperab= ility isn't important.

On Mon, Jul 17, 2017 at 10:35 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:
So I'm not sure of the value of this as we= and the their companies have already implemented solutions that are differ= ent than what is being proposed. This also does not work for a lot of our u= se cases where there is an untrusted proxy. Most of our cases are also within our own infrastructure so no question th= e need for standardization.

From: Unbearable <unbearable-bounces@ietf.org> on behalf of Leif Johansson <= leifj@sunet.se><= br> Sent: Monday, July 17, 2017 5:50:20 PM
To: IETF Tokbind WG
Subject: [Unbearable] WG adoption of draft-campbell-tokbind-ttrp-00<= /font>
=C2=A0

In the f2f meeting in Prague there was clear consensus to adopt
draft-campbell-tokbind-ttrp-00 as draft-ietf-tokbind-ttrp-00
making this a WG document.

If anyone on the list disagrees, now is the time to speak up.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Cheers Leif & John

_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
= https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%= 2Fwww.ietf.org%2Fmailman%2Flistinfo%2Funbearable&data=3D02%7C= 01%7Ctonynad%40microsoft.com%7C06e4b840a7a94372b5e008d4cd2b8= f26%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63635903435= 7583877&sdata=3DhW8BlMQm1Sf%2BjDXeAQ9%2BeHIxXMroROFSuegdWpdX8= DA%3D&reserved=3D0

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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --f403043607d86e5a080554aec9fa-- From nobody Thu Jul 20 01:03:49 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C95129B7F for ; Thu, 20 Jul 2017 01:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 IX6cbV1lx71m for ; Thu, 20 Jul 2017 01:03:45 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0126.outbound.protection.outlook.com [104.47.36.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 EB566131A7E for ; Thu, 20 Jul 2017 01:03:34 -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=1VjiQjQo0Lb2t44QPXNBgbge1S5tkYHRf+Q4P20++Qg=; b=KyoyeBouWxqZ7hmSYDxOZBq2fnwFzhm8PlZrY0HjcUcoC/AK/o9HQuTmbnuWPvC3icgTz/aB1BSwrIKwrLJF6UXcg6G+RJqKd/34dJXzzfsXKOaUO1D6pvC6t5IsoebOVddaI876uPjc6h+5IODjJIOEsbPTxbAxSgLAOjCcW0w= Received: from MWHPR21MB0286.namprd21.prod.outlook.com (10.173.53.16) by MWHPR21MB0159.namprd21.prod.outlook.com (10.173.52.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.2; Thu, 20 Jul 2017 08:03:32 +0000 Received: from MWHPR21MB0286.namprd21.prod.outlook.com ([10.173.53.16]) by MWHPR21MB0286.namprd21.prod.outlook.com ([10.173.53.16]) with mapi id 15.01.1282.008; Thu, 20 Jul 2017 08:03:32 +0000 From: Anthony Nadalin To: Brian Campbell CC: Leif Johansson , IETF Tokbind WG Thread-Topic: [Unbearable] WG adoption of draft-campbell-tokbind-ttrp-00 Thread-Index: AQHS/xRvpKAPfchK1kW7724yuY/xe6JYeitcgALs7oCAAM/csA== Date: Thu, 20 Jul 2017 08:03:31 +0000 Message-ID: References: <853ba12d-5859-1545-611d-74f0b1fbf533@sunet.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=tonynad@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-07-20T01:03:29.1160251-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [62.168.35.69] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0159; 7:r9AwxogcFZFKQ8IUvWdt+XXWcYd6Ci+eRBJ4CfNqNj31B+VPzKhwNk+hKi+lUQ+VZFmPlAcq1ObjuOy6SxHkFRj+HwFuPUbQSl2UGW7VnZ0VM3sDu3FsuHIaYdY4XIQ7W7HRlyPp89Mk+21lLRpb1iwpWsGVxM9avWg4PsCS9C6mGjLogO/3YM2xqr5RoASxmhAQ4/uXWw4zoJvB5ucA/cdjPjEMzXbXjIbyvV5ib6EEJX1X59PvRa3SVbGg2s3bWZfREuxXOIX9tDm8e5IMCNznkOD1amamMcKRx4QBw9CzrlZGcHe0J1nJI+//ZjRj+wnGMSxQKqgQLn/Giu3lP2pZPu1TWhxqixREbBtZSPUDEW2zHjXRO6rXGeOWQeym6yJHR9/q0Lcws3s5I6Ejkzcl13BMRN4Qp8OuwfGJl4lWQcX6wNdOxHR/Iadht3N9zkFoDOvVtO4AtkJNqj+YTXlWJCHcEesNIeqrsvW6eRPcF4wwEGLDgtU5LTYhLy+IvdAfCSeexXln3Ket4rkaHtmxZJPD831x/YjmcE9JWPTYLipJ0sVbW8gz0pqembQnsCSO/RDPBaU7IMjk0gVkfGaYYyqIS1br2NRR35l6da6o4U56hgrOP6/WVuPkw+3Pv98KqBAM1tW+LoT2LoAJq3Kg0Jqg/QKFaza/0d0Hg7Orv9ynx+1jDakONvgZ0ozMjLM327rdKiMCYHE1rU20miEnwqWMEr2plNqoSHnC1WnI1Li3R9p4BpySwlnFXgU41L/HNEd6U5CMGjCqANHLlIn6aYzLcND/uSyOn6UXDrkvT1XZ7IsKKxG6QULRbgl9 x-ms-office365-filtering-correlation-id: 934bcfd9-c85b-4b6f-3189-08d4cf45d075 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0159; x-ms-traffictypediagnostic: MWHPR21MB0159: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(236129657087228)(189930954265078)(48057245064654)(100405760836317)(148574349560750)(219752817060721)(21748063052155)(69029272430364); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123560025)(20161123564025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0159; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0159; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39400400002)(39410400002)(39850400002)(39860400002)(39450400003)(39840400002)(36304003)(24454002)(377454003)(25786009)(478600001)(99286003)(6306002)(110136004)(54896002)(38730400002)(55016002)(236005)(54906002)(6246003)(53546010)(189998001)(6506006)(77096006)(7736002)(86612001)(86362001)(229853002)(7696004)(53936002)(10290500003)(66066001)(9686003)(3280700002)(2906002)(5890100001)(230783001)(4326008)(6916009)(2950100002)(19609705001)(10090500001)(966005)(74316002)(76176999)(6436002)(3660700001)(81166006)(8990500004)(5660300001)(54356999)(8936002)(790700001)(606006)(102836003)(2900100001)(8676002)(33656002)(14454004)(3846002)(6116002)(50986999)(5005710100001)(42262002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0159; H:MWHPR21MB0286.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0286C88911267D9D68728500A6A70MWHPR21MB0286namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 08:03:32.0460 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0159 Archived-At: Subject: Re: [Unbearable] WG adoption of draft-campbell-tokbind-ttrp-00 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 08:03:47 -0000 --_000_MWHPR21MB0286C88911267D9D68728500A6A70MWHPR21MB0286namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWF5YmUgdGhpcyBzaG91bGQganVzdCBiZSBhbiBJbmZvcm1hdGlvbmFsIGFuZCBub3Qgc3RhbmRh cmRzIHRyYWNrDQoNCkZyb206IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdp ZGVudGl0eS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMTksIDIwMTcgMTA6MTYgQU0NClRv OiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT4NCkNjOiBMZWlmIEpvaGFu c3NvbiA8bGVpZmpAc3VuZXQuc2U+OyBJRVRGIFRva2JpbmQgV0cgPHVuYmVhcmFibGVAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LWNhbXBi ZWxsLXRva2JpbmQtdHRycC0wMA0KDQpUaGUgaW50ZW50IG9mIHRoZSBkcmFmdCBpcyB0byBoZWxw IGZhY2lsaXRhdGUgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIGluZGVwZW5kZW50bHkgZGV2ZWxv cGVkIGFuZC9vciBkZXBsb3llZCBjb21wb25lbnRzLiBBbmQgdGhlcmUgaXMgdmFsdWUgaW4gc3Rh bmRhcmRpemF0aW9uIGZvciB0aGF0LiBCdXQgb2YgY291cnNlIGNvbmZvcm1hbmNlIHRvIHRoZSBk cmFmdCBpc24ndCByZXF1aXJlZCBpbiBjYXNlcywgbGlrZSBwZXJoYXBzIHRob3NlIHRoYXQgeW91 IG1lbnRpb24gd2hlcmUgZXZlcnl0aGluZyBpcyB3aXRoaW4geW91ciBvd24gaW5mcmFzdHJ1Y3R1 cmUsIHdoZXJlIHRoYXQga2luZCBvZiBpbnRlcm9wZXJhYmlsaXR5IGlzbid0IGltcG9ydGFudC4N Cg0KT24gTW9uLCBKdWwgMTcsIDIwMTcgYXQgMTA6MzUgUE0sIEFudGhvbnkgTmFkYWxpbiA8dG9u eW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+PiB3cm90ZToN ClNvIEknbSBub3Qgc3VyZSBvZiB0aGUgdmFsdWUgb2YgdGhpcyBhcyB3ZSBhbmQgdGhlIHRoZWly IGNvbXBhbmllcyBoYXZlIGFscmVhZHkgaW1wbGVtZW50ZWQgc29sdXRpb25zIHRoYXQgYXJlIGRp ZmZlcmVudCB0aGFuIHdoYXQgaXMgYmVpbmcgcHJvcG9zZWQuIFRoaXMgYWxzbyBkb2VzIG5vdCB3 b3JrIGZvciBhIGxvdCBvZiBvdXIgdXNlIGNhc2VzIHdoZXJlIHRoZXJlIGlzIGFuIHVudHJ1c3Rl ZCBwcm94eS4gTW9zdCBvZiBvdXIgY2FzZXMgYXJlIGFsc28gd2l0aGluIG91ciBvd24gaW5mcmFz dHJ1Y3R1cmUgc28gbm8gcXVlc3Rpb24gdGhlIG5lZWQgZm9yIHN0YW5kYXJkaXphdGlvbi4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFVuYmVhcmFibGUgPHVuYmVh cmFibGUtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3Jn Pj4gb24gYmVoYWxmIG9mIExlaWYgSm9oYW5zc29uIDxsZWlmakBzdW5ldC5zZTxtYWlsdG86bGVp ZmpAc3VuZXQuc2U+Pg0KU2VudDogTW9uZGF5LCBKdWx5IDE3LCAyMDE3IDU6NTA6MjAgUE0NClRv OiBJRVRGIFRva2JpbmQgV0cNClN1YmplY3Q6IFtVbmJlYXJhYmxlXSBXRyBhZG9wdGlvbiBvZiBk cmFmdC1jYW1wYmVsbC10b2tiaW5kLXR0cnAtMDANCg0KDQpJbiB0aGUgZjJmIG1lZXRpbmcgaW4g UHJhZ3VlIHRoZXJlIHdhcyBjbGVhciBjb25zZW5zdXMgdG8gYWRvcHQNCmRyYWZ0LWNhbXBiZWxs LXRva2JpbmQtdHRycC0wMCBhcyBkcmFmdC1pZXRmLXRva2JpbmQtdHRycC0wMA0KbWFraW5nIHRo aXMgYSBXRyBkb2N1bWVudC4NCg0KSWYgYW55b25lIG9uIHRoZSBsaXN0IGRpc2FncmVlcywgbm93 IGlzIHRoZSB0aW1lIHRvIHNwZWFrIHVwLg0KDQogICAgICAgIENoZWVycyBMZWlmICYgSm9obg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVW5iZWFy YWJsZSBtYWlsaW5nIGxpc3QNClVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOlVuYmVhcmFibGVA aWV0Zi5vcmc+DQpodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnVu YmVhcmFibGUmZGF0YT0wMiU3QzAxJTdDdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN0MwNmU0Yjg0 MGE3YTk0MzcyYjVlMDA4ZDRjZDJiOGYyNiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdDMSU3QzAlN0M2MzYzNTkwMzQzNTc1ODM4Nzcmc2RhdGE9aFc4QmxNUW0xU2YlMkJqRFhl QVE5JTJCZUhJeFhNcm9ST0ZTdWVnZFdwZFg4REElM0QmcmVzZXJ2ZWQ9MA0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVW5iZWFyYWJsZSBtYWlsaW5n IGxpc3QNClVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGU8aHR0cHM6Ly9u YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3 d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ1bmJlYXJhYmxlJmRhdGE9MDIlN0Mw MSU3Q3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdDYjEzNTU1ODBkYjEwNDViYTdiMGYwOGQ0Y2Vj OWQ2ZmYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2MzYw ODEzNjY4NzUzOTMzJnNkYXRhPUI1VTcyb1dXSVAlMkI1WERFVDNyRnVwdTRRNW12cFFsT2s2TG1k UGxEUU00TSUzRCZyZXNlcnZlZD0wPg0KDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMg ZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZv ciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywg dXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVs ZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0 ZXIuIFRoYW5rIHlvdS4NCg== --_000_MWHPR21MB0286C88911267D9D68728500A6A70MWHPR21MB0286namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJ IjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAN Cgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5NYXliZSB0aGlzIHNob3VsZCBqdXN0IGJlIGFuIEluZm9ybWF0aW9uYWwgYW5kIG5v dCBzdGFuZGFyZHMgdHJhY2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJyaWFu IENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gV2VkbmVzZGF5LCBKdWx5IDE5LCAyMDE3IDEwOjE2IEFNPGJyPg0KPGI+VG86PC9i PiBBbnRob255IE5hZGFsaW4gJmx0O3RvbnluYWRAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IExlaWYgSm9oYW5zc29uICZsdDtsZWlmakBzdW5ldC5zZSZndDs7IElFVEYgVG9rYmlu ZCBXRyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtVbmJlYXJhYmxlXSBXRyBhZG9wdGlvbiBvZiBkcmFmdC1jYW1wYmVsbC10b2tiaW5kLXR0cnAt MDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaW50ZW50IG9mIHRo ZSBkcmFmdCBpcyB0byBoZWxwIGZhY2lsaXRhdGUgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIGlu ZGVwZW5kZW50bHkgZGV2ZWxvcGVkIGFuZC9vciBkZXBsb3llZCBjb21wb25lbnRzLiBBbmQgdGhl cmUgaXMgdmFsdWUgaW4gc3RhbmRhcmRpemF0aW9uIGZvciB0aGF0LiBCdXQgb2YgY291cnNlIGNv bmZvcm1hbmNlIHRvIHRoZSBkcmFmdCBpc24ndCByZXF1aXJlZCBpbiBjYXNlcywgbGlrZQ0KIHBl cmhhcHMgdGhvc2UgdGhhdCB5b3UgbWVudGlvbiB3aGVyZSBldmVyeXRoaW5nIGlzIHdpdGhpbiB5 b3VyIG93biBpbmZyYXN0cnVjdHVyZSwgd2hlcmUgdGhhdCBraW5kIG9mIGludGVyb3BlcmFiaWxp dHkgaXNuJ3QgaW1wb3J0YW50Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBNb24sIEp1bCAxNywgMjAxNyBhdCAxMDozNSBQTSwgQW50aG9ueSBOYWRh bGluICZsdDs8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9i bGFuayI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGlkPSJtXzU4MDE0NTg0MTQwNzI4NTI0 NDJ4X2NvbXBvc2UtY29udGFpbmVyIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U28gSSdtIG5vdCBzdXJlIG9mIHRoZSB2YWx1ZSBvZiB0aGlzIGFzIHdlIGFuZCB0aGUgdGhl aXIgY29tcGFuaWVzIGhhdmUgYWxyZWFkeSBpbXBsZW1lbnRlZCBzb2x1dGlvbnMgdGhhdCBhcmUg ZGlmZmVyZW50IHRoYW4gd2hhdCBpcyBiZWluZyBwcm9wb3NlZC4gVGhpcyBhbHNvIGRvZXMgbm90 IHdvcmsgZm9yIGEgbG90IG9mIG91ciB1c2UgY2FzZXMgd2hlcmUgdGhlcmUgaXMgYW4gdW50cnVz dGVkIHByb3h5Lg0KIE1vc3Qgb2Ygb3VyIGNhc2VzIGFyZSBhbHNvIHdpdGhpbiBvdXIgb3duIGlu ZnJhc3RydWN0dXJlIHNvIG5vIHF1ZXN0aW9uIHRoZSBuZWVkIGZvciBzdGFuZGFyZGl6YXRpb24u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBz aXplPSI0IiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPGRpdiBpZD0ibV81 ODAxNDU4NDE0MDcyODUyNDQyeF9kaXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+IFVuYmVhcmFibGUgJmx0OzxhIGhyZWY9Im1haWx0bzp1bmJl YXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj51bmJlYXJhYmxlLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KIG9uIGJlaGFsZiBvZiBMZWlmIEpvaGFuc3NvbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmxlaWZqQHN1bmV0LnNlIiB0YXJnZXQ9Il9ibGFuayI+bGVpZmpAc3VuZXQu c2U8L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMTcsIDIwMTcgNTo1MDoy MCBQTTxicj4NCjxiPlRvOjwvYj4gSUVURiBUb2tiaW5kIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFtVbmJlYXJhYmxlXSBXRyBhZG9wdGlvbiBvZiBkcmFmdC1jYW1wYmVsbC10b2tiaW5kLXR0cnAt MDA8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGJyPg0KSW4g dGhlIGYyZiBtZWV0aW5nIGluIFByYWd1ZSB0aGVyZSB3YXMgY2xlYXIgY29uc2Vuc3VzIHRvIGFk b3B0PGJyPg0KZHJhZnQtY2FtcGJlbGwtdG9rYmluZC10dHJwLTAwIGFzIGRyYWZ0LWlldGYtdG9r YmluZC10dHJwLTAwPGJyPg0KbWFraW5nIHRoaXMgYSBXRyBkb2N1bWVudC48YnI+DQo8YnI+DQpJ ZiBhbnlvbmUgb24gdGhlIGxpc3QgZGlzYWdyZWVzLCBub3cgaXMgdGhlIHRpbWUgdG8gc3BlYWsg dXAuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IENoZWVycyBMZWlmICZhbXA7IEpvaG48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5V bmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3Jn JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdW5iZWFyYWJsZSZhbXA7ZGF0YT0wMiU3QzAxJTdDdG9u eW5hZCU0MG1pY3Jvc29mdC5jb20lN0MwNmU0Yjg0MGE3YTk0MzcyYjVlMDA4ZDRjZDJiOGYyNiU3 QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYzNTkwMzQzNTc1 ODM4NzcmYW1wO3NkYXRhPWhXOEJsTVFtMVNmJTJCakRYZUFROSUyQmVISXhYTXJvUk9GU3VlZ2RX cGRYOERBJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9uYTAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0 Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ1bmJlYXJhYmxlJmFtcDtkYXRhPTAyJTdDMDEl N0N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3QzA2ZTRiODQwYTdhOTQzNzJiNWUwMDhkNGNkMmI4 ZjI2JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjM1OTAz NDM1NzU4Mzg3NyZhbXA7c2RhdGE9aFc4QmxNUW0xU2YlMkJqRFhlQVE5JTJCZUhJeFhNcm9ST0ZT dWVnZFdwZFg4REElM0QmYW1wO3Jlc2VydmVkPTA8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpV bmJlYXJhYmxlQGlldGYub3JnIj5VbmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdW5iZWFyYWJsZSZh bXA7ZGF0YT0wMiU3QzAxJTdDdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN0NiMTM1NTU4MGRiMTA0 NWJhN2IwZjA4ZDRjZWM5ZDZmZiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdD MSU3QzAlN0M2MzYzNjA4MTM2Njg3NTM5MzMmYW1wO3NkYXRhPUI1VTcyb1dXSVAlMkI1WERFVDNy RnVwdTRRNW12cFFsT2s2TG1kUGxEUU00TSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZTwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5k b3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVt YWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3Ig dGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuDQogQW55IHJldmlldywg dXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFu ZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBj b21wdXRlci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MWHPR21MB0286C88911267D9D68728500A6A70MWHPR21MB0286namp_-- From nobody Thu Jul 20 03:38:38 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FD012EAF7 for ; Thu, 20 Jul 2017 03:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com; domainkeys=pass (1024-bit key) header.sender=andreipo=microsoft.com@github.com header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45MH8AAXDoBT for ; Thu, 20 Jul 2017 03:38:35 -0700 (PDT) Received: from m69-169.mailgun.net (m69-169.mailgun.net [166.78.69.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AD2131C01 for ; Thu, 20 Jul 2017 03:38:34 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1500547113; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=Co+yUIF5Uj1gdVWucEDb2RkV2Q80BIKVqC/h636+hVk=; b=tzfF49tAGWAXlB4fVFeSloqpMg4sAgfPNcZSzGT9LAD6ZtZzkqLNw6IT82h7hLPESbvccVrT PP/RfYWpO1C5iGaB78rrqTm27A/81rfuVMGwN0eulzu49Za7AFvR4qraVBIJZF44KWXZCcPa IXAUDIOLsBYozq+AcTlN9MOdVII= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=JopBWEYtHcl9H21xAUexHniEItQ6FckDV9wddQ18QmnEF2PNhq5X84n1RTL+ZqZG2sboUE tFQx59TqAL6t5vlnBxZj+/FyJQTFMFAQ07kkXHegS4OuJ2rQBWJIt3XetBfc+yMcQZyyYr+B /JHU6Uf3aFjrtdDQUOTN3zw1PrPzY= Sender: andreipo=microsoft.com@github.com X-Mailgun-Sending-Ip: 166.78.69.169 X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Received: from github.com (Unknown [192.30.252.42]) by mxa.mailgun.org with ESMTP id 59708829.7fdc08524a20-smtp-out-n01; Thu, 20 Jul 2017 10:38:33 -0000 (UTC) Date: Thu, 20 Jul 2017 03:38:33 -0700 From: Andrei Popov Reply-To: Andrei Popov To: unbearable@ietf.org Message-ID: <59708829255cb_b0e3fefd3de9c2c51167@hookshot-fe1-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_597088292520c_b0e3fefd3de9c2c510ea"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] 0efda2: Fixed I-D nits. X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 10:38:37 -0000 ----==_mimepart_597088292520c_b0e3fefd3de9c2c510ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: 0efda2fd2599cea9b3d9711914b21c34af41efae https://github.com/TokenBinding/Internet-Drafts/commit/0efda2fd2599cea9b3d9711914b21c34af41efae Author: Andrei Popov Date: 2017-07-20 (Thu, 20 Jul 2017) Changed paths: M README.md R draft-ietf-tokbind-negotiation-08.xml A draft-ietf-tokbind-negotiation-09.xml R draft-ietf-tokbind-protocol-14.xml A draft-ietf-tokbind-protocol-15.xml Log Message: ----------- Fixed I-D nits. ----==_mimepart_597088292520c_b0e3fefd3de9c2c510ea-- From nobody Thu Jul 20 03:47:32 2017 Return-Path: X-Original-To: unbearable@ietf.org Delivered-To: unbearable@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCAA129AD1; Thu, 20 Jul 2017 03:47:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: unbearable@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150054765066.24062.10954891820137978390@ietfa.amsl.com> Date: Thu, 20 Jul 2017 03:47:30 -0700 Archived-At: Subject: [Unbearable] I-D Action: draft-ietf-tokbind-negotiation-09.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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 Jul 2017 10:47:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding WG of the IETF. Title : Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Filename : draft-ietf-tokbind-negotiation-09.txt Pages : 8 Date : 2017-07-20 Abstract: This document specifies a Transport Layer Security (TLS) extension for the negotiation of Token Binding protocol version and key parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-negotiation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-09 https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-negotiation-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-negotiation-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 20 03:50:48 2017 Return-Path: X-Original-To: unbearable@ietf.org Delivered-To: unbearable@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9EC131B09; Thu, 20 Jul 2017 03:50:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: unbearable@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150054784808.24185.8269094874321173547@ietfa.amsl.com> Date: Thu, 20 Jul 2017 03:50:48 -0700 Archived-At: Subject: [Unbearable] I-D Action: draft-ietf-tokbind-protocol-15.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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 Jul 2017 10:50:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding WG of the IETF. Title : The Token Binding Protocol Version 1.0 Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Jeff Hodges Filename : draft-ietf-tokbind-protocol-15.txt Pages : 17 Date : 2017-07-20 Abstract: This document specifies Version 1.0 of the Token Binding protocol. The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, the Token Binding identifiers are only conveyed over TLS and can be reset by the user at any time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tokbind-protocol-15 https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-protocol-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-protocol-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 20 04:01:55 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DE2131687 for ; Thu, 20 Jul 2017 04:01:53 -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 EZ20-oZGL-WK for ; Thu, 20 Jul 2017 04:01:51 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0092.outbound.protection.outlook.com [104.47.38.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3936129AD1 for ; Thu, 20 Jul 2017 04:01:50 -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=pWd6uHs7ZIvtUNsvmAajWXa28UkmYsZsAOT3j54FT3M=; b=NVUFp2mQ7mCmfPXgSNEUlYtGqy/vC+Rpwz/5OWj4wJa3CTUIDojn1jFIovqv88BX8xhgNT7tQXerh8OylcLFENibmFWVjdEksrCMl91vwZdenPa2VhQToT6NVmgRXgBS8s7bN6DQgT69dQHLynHdKf2JUHHF1oMLuZ6QrGOCDwc= Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0076.namprd21.prod.outlook.com (10.161.141.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.7; Thu, 20 Jul 2017 11:01:49 +0000 Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::c8c3:4f7d:e655:1fb2]) by DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::c8c3:4f7d:e655:1fb2%13]) with mapi id 15.01.1304.007; Thu, 20 Jul 2017 11:01:49 +0000 From: Andrei Popov To: IETF Tokbind WG Thread-Topic: Updated TBNEGO and TBPROTO Thread-Index: AdMBRl39RvVNTXIzQgGnhO7Tc5tsZQ== Date: Thu, 20 Jul 2017 11:01:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:67c:1232:184:f5ce:6e9b:d5c1:2697] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR21MB0076; 7:dYJQ0ij+h8/dJO7qMpJOwyehnWfT0601HHgWOr9hL2+BRaEl/dp6EozNlcqgJxTUP3IstvCSM2bfZsTPS1gBTOuA5BOCx2YiDHfNve6cQLP2CyxMSxV0L+Rfxr/ZFJIoLuZOpn84MrDeyOaMBf1xXReMWQa3zp+/hr8A8vQ+CvIN4/qSrDVKMI/teT0DMfXMsImoi7fAUskis23Jeb/clflhXpA2/qYaOupbl8o/hQCgetCcIxifZhDYdeXR/dw1w0o5r86QV4sM316vtSMGEsZkCKnfDEVblZNEV5E0tx59XJL45Iq4WNmjFtv99B9TS7efbiTo5Gx0EpyR4QQCPUjzT4laiyCP4DEIXnc046/BSbX4oDrkPWSwqQVEKarckut8Fj/MsamAfS7bsEQESB3LlTOANrUqfmtscIjw9JiU8eOsgSUVg1VVJO8Bx3kcx4HMZfxHBycPg4EpQ7a8VnxAEj4u45A/XZJ/3S37rPHXst9hqHLqmPmsPAIcCShfOZ6ZDMobaOBBHXV1NLRwDHSYdaxVKaYNoeVz+eLMw/vi9IsY1UgFJNYn+1kQ1QeCMZjZy44f3JzxlrtOa2zOZiVqkK6FEf4kxpLNQi1JmThT0Dpx8V0mpBcXDTYlJMOB01v7OBJfjrKB1tTIwA98uHyN2FDBtqxOi7cp3A9nEy8c0VLqyWlaJY7MJIpGpgcFL6NONK3KkPj4ps5jd4SaufHC4S6PTgN3aDW4aIS0ty37GiIwgZtuj9kLG8g7DvxM1F5/9Sx2jGDP8NZlCSqAWGR5gSpnwNSSs95PrMFZ+vsiTOkrOgGK7iljOKEJG5kW x-ms-office365-filtering-correlation-id: 2cfe2188-0dab-4cc3-ff58-08d4cf5eb847 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR21MB0076; x-ms-traffictypediagnostic: DM2PR21MB0076: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(236129657087228)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR21MB0076; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR21MB0076; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39840400002)(39860400002)(39410400002)(39850400002)(39400400002)(2906002)(74316002)(6506006)(5250100002)(14454004)(9686003)(236005)(54896002)(6306002)(33656002)(10090500001)(72206003)(3280700002)(606006)(5660300001)(3660700001)(6916009)(6116002)(102836003)(790700001)(7736002)(25786009)(478600001)(189998001)(558084003)(50986999)(54356999)(38730400002)(7696004)(10290500003)(5005710100001)(110136004)(8936002)(53936002)(6436002)(81166006)(86362001)(99286003)(3480700004)(2900100001)(55016002)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0076; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR21MB00917DA02F5364FE9B59EE988CA70DM2PR21MB0091namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 11:01:48.9122 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0076 Archived-At: Subject: [Unbearable] Updated TBNEGO and TBPROTO X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:01:53 -0000 --_000_DM2PR21MB00917DA02F5364FE9B59EE988CA70DM2PR21MB0091namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TBNEGO-09 an= d TBPROTO-15 fi= x issues identified by the I-D nits tool, mostly unused RFC references or r= eferences to obsolete RFCs. Cheers, Andrei --_000_DM2PR21MB00917DA02F5364FE9B59EE988CA70DM2PR21MB0091namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

TBNEGO-09 and TBPR= OTO-15 fix issues identified by the I-D nits tool, mostly unused RFC re= ferences or references to obsolete RFCs.

 

Cheers,

 

Andrei

--_000_DM2PR21MB00917DA02F5364FE9B59EE988CA70DM2PR21MB0091namp_-- From nobody Fri Jul 21 00:28:54 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B631D12714F for ; Fri, 21 Jul 2017 00:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NotXLI7Nr3bz for ; Fri, 21 Jul 2017 00:28:50 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A04129A92 for ; Fri, 21 Jul 2017 00:28:50 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id y43so78845468wrd.3 for ; Fri, 21 Jul 2017 00:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=vJtkrhopPyjyfTFugu59HtTLOIs/Yjwzeq9WE8EsFX0=; b=w9ldpPweH+ZNOhQPWi/8ngQj0cFNKtcM6xkzEjFDtwYBBsTnryqzyKG+U1lieBN8QN a0ruGGqyn+7eLAmdd+/2YX0ImXyL7a2u8L0Sde3dtShdFX9VKuQqfKzIoD9MsmX0xAGi SKblTdHi068F3tHqDiFSlWEIP/kyYRBSImF/yPvqCIePxdZTtxM8dMpBjOjO4xLQDxdK /4Q6W7broIc76ZpSol19T4tAPoyg2R//3XnRHc3owHn49yx5bvI0GItzwdB7CfNdLf6y C4hvuwhOJfCNfB964jVmDEjjxxVOUA0lfLhccUAqlzT06adS40DKbHhR/RBBDKlm6KMw MqVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vJtkrhopPyjyfTFugu59HtTLOIs/Yjwzeq9WE8EsFX0=; b=MISkMxCr1BB2UJ1jtkYeGSqWQXpcLdfKFZlWehBVUard/eADXvV16IvCxexrz4eosa duwA1v1wWUnQhQL70Nd/2EnD2N9KWprmIpxyDv+CLLFH+CLrFEUDzdUyl0W3OmS2TdB+ PqMAOxbA3Pi2xAc7fstYFbKWchrnVpITIJ14PsbbPBG/w8Bt7RARUtVO+eeWfCutCGbV rcJaXiRDM4ZjrDzSx8J/D3aM1eoSR75nmOGKA/HOJWZevjoYo7ixXoxLSNYquRIexWkP vNkFD404qWVd6ObbHXfWBoN3gJxnyAOX+hdU3Fu5Eak1Kv+TeZmBX2ju3CadnLy2edqJ JrfQ== X-Gm-Message-State: AIVw112yO9lkhf/eiyEx4JTYBt88fHrIBWnVnG+3PqonatKkSAJmmjZG 9OUmp8v7QWK7BtBZyilWDQ== X-Received: by 10.223.138.182 with SMTP id y51mr9155186wry.83.1500622128435; Fri, 21 Jul 2017 00:28:48 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:9490:a0c5:8deb:dc85? ([2001:67c:1232:144:9490:a0c5:8deb:dc85]) by smtp.gmail.com with ESMTPSA id w96sm7773034wrc.33.2017.07.21.00.28.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jul 2017 00:28:47 -0700 (PDT) From: Leif Johansson To: IETF Tokbind WG References: <853ba12d-5859-1545-611d-74f0b1fbf533@sunet.se> Message-ID: <0d7c3fcd-9140-6b0e-752b-81978d331869@sunet.se> Date: Fri, 21 Jul 2017 09:28:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <853ba12d-5859-1545-611d-74f0b1fbf533@sunet.se> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Unbearable] WG adoption of draft-campbell-tokbind-ttrp-00 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 07:28:53 -0000 On 2017-07-17 17:50, Leif Johansson wrote: > > In the f2f meeting in Prague there was clear consensus to adopt > draft-campbell-tokbind-ttrp-00 as draft-ietf-tokbind-ttrp-00 > making this a WG document. > > If anyone on the list disagrees, now is the time to speak up. > > Cheers Leif & John > I think we can deal with Tonys concerns in the WG and given the strong support for adopting the document in the WG meeting I'm calling rough consensus on this. Brian: go ahead and publish draft-ietf-tokbind-ttrp-00 at your convenience. Cheers Leif From nobody Fri Jul 21 02:01:56 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14E112EB2B for ; Fri, 21 Jul 2017 02:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com; domainkeys=pass (1024-bit key) header.sender=balfanz=google.com@github.com header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zg-PTBucC5Gy for ; Fri, 21 Jul 2017 02:01:48 -0700 (PDT) Received: from m69-170.mailgun.net (m69-170.mailgun.net [166.78.69.170]) (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 4B7B5129B55 for ; Fri, 21 Jul 2017 02:01:48 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1500627707; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=EoBpxSwr1qlBrfTeCfsHUxytK+9o4bq6I/fJHx4ZuFU=; b=PZ+nMgq3uKhrwoPK7J0itc7vpZlIMRbV2GfPFXIaQyO+jIEm1pLxb7GIrL+zz4l2kzomslOC K9Z+Fyoi3CkrmOMMJZCh2+7LbWEFNElqCjxEEqBc7DB8+46UJVBMHKmphoORhDVtWaLudL9Y nyYI5ZpyRyckHMaSXh8t6PSXnso= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=DyX9Mh+Rcf46d9kHQHguqRxXV2AdS9VTLYsCujmzB65+w+M3eb512HZJSackXz68p7Lvsn f4pUWDeQx8LerkZijrvk6/CeZ8XDTYmVZivfQ3SPnTbIeow22ue4y42hg6OGcu/LFfzXchGl d0tpus6akABVpR5jS1VfEETgaqlos= Sender: balfanz=google.com@github.com X-Mailgun-Sending-Ip: 166.78.69.170 X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Received: from github.com (Unknown [192.30.252.34]) by mxa.mailgun.org with ESMTP id 5971c2fb.7f6a993f3f00-smtp-out-n02; Fri, 21 Jul 2017 09:01:47 -0000 (UTC) Date: Fri, 21 Jul 2017 02:01:47 -0700 From: Dirk Balfanz Reply-To: Dirk Balfanz To: unbearable@ietf.org Message-ID: <5971c2fb29c6d_70243ff2c6f37c289749d@hookshot-fe2-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_5971c2fb298e1_70243ff2c6f37c28973e1"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] 41a159: Adding a missing author to tokbind-https X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 09:01:50 -0000 ----==_mimepart_5971c2fb298e1_70243ff2c6f37c28973e1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: 41a159c22bb7534d01290bcec5c9e92a94da22f0 https://github.com/TokenBinding/Internet-Drafts/commit/41a159c22bb7534d01290bcec5c9e92a94da22f0 Author: Dirk Balfanz Date: 2017-07-21 (Fri, 21 Jul 2017) Changed paths: M README.md R draft-ietf-tokbind-https-09.xml A draft-ietf-tokbind-https-10.xml Log Message: ----------- Adding a missing author to tokbind-https ----==_mimepart_5971c2fb298e1_70243ff2c6f37c28973e1-- From nobody Fri Jul 21 02:06:46 2017 Return-Path: X-Original-To: unbearable@ietf.org Delivered-To: unbearable@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF69129AA0; Fri, 21 Jul 2017 02:06:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: unbearable@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150062800542.11311.4823917490193775849@ietfa.amsl.com> Date: Fri, 21 Jul 2017 02:06:45 -0700 Archived-At: Subject: [Unbearable] I-D Action: draft-ietf-tokbind-https-10.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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 Jul 2017 09:06:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding WG of the IETF. Title : Token Binding over HTTP Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Nick Harper Jeff Hodges Filename : draft-ietf-tokbind-https-10.txt Pages : 22 Date : 2017-07-21 Abstract: This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections. We describe both first-party and federated scenarios. In a first- party scenario, an HTTP server is able to cryptographically bind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server. Such bound security tokens are protected from misuse since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections. Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token. This Internet-Draft is a companion document to The Token Binding Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tokbind-https-10 https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-https-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-https-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 21 02:21:24 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8176B126557 for ; Fri, 21 Jul 2017 02:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-Eu6Huy0xOl for ; Fri, 21 Jul 2017 02:21:21 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26571126D46 for ; Fri, 21 Jul 2017 02:21:21 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 3BBB17803A5 for ; Fri, 21 Jul 2017 11:21:18 +0200 (CEST) To: unbearable@ietf.org References: <150062800542.11311.4823917490193775849@ietfa.amsl.com> From: Denis Message-ID: <6029f39a-ea91-a5ae-60cf-d52d0aeeb718@free.fr> Date: Fri, 21 Jul 2017 11:21:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <150062800542.11311.4823917490193775849@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-https-10.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 09:21:23 -0000 This ID is still lacking to indicate that this mechanism will be ineffective in case of a collusion between clients. This should be clearly indicated in the Security Considerations section. Denis > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Token Binding WG of the IETF. > > Title : Token Binding over HTTP > Authors : Andrei Popov > Magnus Nyström > Dirk Balfanz > Adam Langley > Nick Harper > Jeff Hodges > Filename : draft-ietf-tokbind-https-10.txt > Pages : 22 > Date : 2017-07-21 > > Abstract: > This document describes a collection of mechanisms that allow HTTP > servers to cryptographically bind security tokens (such as cookies > and OAuth tokens) to TLS connections. > > We describe both first-party and federated scenarios. In a first- > party scenario, an HTTP server is able to cryptographically bind the > security tokens it issues to a client, and which the client > subsequently returns to the server, to the TLS connection between the > client and server. Such bound security tokens are protected from > misuse since the server can generally detect if they are replayed > inappropriately, e.g., over other TLS connections. > > Federated token bindings, on the other hand, allow servers to > cryptographically bind security tokens to a TLS connection that the > client has with a different server than the one issuing the token. > > This Internet-Draft is a companion document to The Token Binding > Protocol. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tokbind-https-10 > https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-https-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-https-10 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Fri Jul 21 02:31:15 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E7E129AA0 for ; Fri, 21 Jul 2017 02:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L607XD8veTEH for ; Fri, 21 Jul 2017 02:31:12 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 CEC98127869 for ; Fri, 21 Jul 2017 02:31:11 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id y15so21215013lfd.5 for ; Fri, 21 Jul 2017 02:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=A7Z08KSmfkPcPsySuCwBaS1VxMc9vCACFDg6ORrzxsI=; b=gsFjffLGnRMJNX7vfXNXQ1IYZboMFT0/fxKTaMHIBnnR9Anspw5VAUruErnKTFMRZ2 JFcsq7EzXFdhVKAC/WwVXFOvK/ogj2+bTB0Vzk68Swvt/iaICa1jPFYv9ikprnxisJfi 52KihPM4eqyqwsd0T699VsuHbgN10GruVZXL9lO0KaDRDvgyLm9AmZEyp+AlcW+pvUP+ NPk5MVgoz56AQUCvagOcryiaRXCTy5VVgMJSXpDvbMc+ap8ndIGLV+sO/3+ZYLMkiwI4 RKAHVFniBsJkvprxo3HPWbGqk0TAsOc5Nrdb3y09vJtTCNpvOPggPv1hNOOdMfz6PNzp xdxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=A7Z08KSmfkPcPsySuCwBaS1VxMc9vCACFDg6ORrzxsI=; b=T5BqCUJo44IHYV4n0AqQWDvIKiRwbu6OJ/opa9Pc5gzTlRNMCjZFZDU/3TaQG2e79A Kc+50f+h1k2s0t1S/XCdgTknTR0/aoJhJ2OrsekgTZmVr74xJOjKoBa2BCTcTDglyHJq R1H3KlpHndTDOsU1HdsLn0LK3Mjv1vUvlKrP8Kwhrrihs5LGnZBjVSd+Xg9UZRzUuMsS ekMnhDeuKnMc2jp41cZfpH0QzZ0PH/eLfy37e8zULUqC/v3WqiMoAm9MFo6uSyLwIj2Z /dz8jyZnT46E+bRttZVByqF6qPfSV45ubLGgyu4O8TEghW95OosxCh6xwqOb1ndtIqff As/Q== X-Gm-Message-State: AIVw1130RV3Y+9d/kTgJ9P2DbBiDUp80my9T+4v8odxFENKJ1ImKVILb nu/zI9laGKqKR/hPY/iy5F9dsJ9EPuGZ X-Received: by 10.46.0.163 with SMTP id e35mr2089320lji.20.1500629469968; Fri, 21 Jul 2017 02:31:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.44.73 with HTTP; Fri, 21 Jul 2017 02:30:49 -0700 (PDT) In-Reply-To: <6029f39a-ea91-a5ae-60cf-d52d0aeeb718@free.fr> References: <150062800542.11311.4823917490193775849@ietfa.amsl.com> <6029f39a-ea91-a5ae-60cf-d52d0aeeb718@free.fr> From: Nick Harper Date: Fri, 21 Jul 2017 02:30:49 -0700 Message-ID: To: Denis Cc: IETF Tokbind WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-https-10.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 09:31:14 -0000 draft-ietf-tokbind-protocol-15 already has language which says "The Token Binding protocol does not prevent cooperating clients from sharing a bound token. A client could intentionally export a bound token with the corresponding Token Binding private key, or perform signatures using this key on behalf of another client." I don't think we need any additional language in this draft regarding client collusion. That clients could collude is a property of the Token Binding protocol, so it doesn't need to be repeated in this application profile for using Token Binding. On Fri, Jul 21, 2017 at 2:21 AM, Denis wrote: > This ID is still lacking to indicate that this mechanism will be > ineffective in case of a collusion between clients. > > This should be clearly indicated in the Security Considerations section. > > Denis > > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Token Binding WG of the IETF. >> >> Title : Token Binding over HTTP >> Authors : Andrei Popov >> Magnus Nystr=C3=B6m >> Dirk Balfanz >> Adam Langley >> Nick Harper >> Jeff Hodges >> Filename : draft-ietf-tokbind-https-10.txt >> Pages : 22 >> Date : 2017-07-21 >> >> Abstract: >> This document describes a collection of mechanisms that allow HTTP >> servers to cryptographically bind security tokens (such as cookies >> and OAuth tokens) to TLS connections. >> >> We describe both first-party and federated scenarios. In a first- >> party scenario, an HTTP server is able to cryptographically bind the >> security tokens it issues to a client, and which the client >> subsequently returns to the server, to the TLS connection between th= e >> client and server. Such bound security tokens are protected from >> misuse since the server can generally detect if they are replayed >> inappropriately, e.g., over other TLS connections. >> >> Federated token bindings, on the other hand, allow servers to >> cryptographically bind security tokens to a TLS connection that the >> client has with a different server than the one issuing the token. >> >> This Internet-Draft is a companion document to The Token Binding >> Protocol. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tokbind-https-10 >> https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-https-10 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tokbind-https-10 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Fri Jul 21 02:40:17 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739D3129B40 for ; Fri, 21 Jul 2017 02:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReOgKDxcar9W for ; Fri, 21 Jul 2017 02:40:13 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE6F127869 for ; Fri, 21 Jul 2017 02:40:13 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id A4A5F7803A9; Fri, 21 Jul 2017 11:40:11 +0200 (CEST) To: Nick Harper References: <150062800542.11311.4823917490193775849@ietfa.amsl.com> <6029f39a-ea91-a5ae-60cf-d52d0aeeb718@free.fr> From: Denis Cc: IETF Tokbind WG Message-ID: <733401bb-4204-ebfb-1e4d-49c70eec2604@free.fr> Date: Fri, 21 Jul 2017 11:40:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------39799C4715F5C184202EC647" Content-Language: en-US Archived-At: Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-https-10.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 09:40:15 -0000 This is a multi-part message in MIME format. --------------39799C4715F5C184202EC647 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Nick, A person reading draft-ietf-tokbind-https will not necessarily also read draft-ietf-tokbind-protocol. So, I believe it is necessary to warn again the reader in the Security Considerations section. Duplication of the text you quoted in that section would address my concern. You said that the fact that clients could collude is a*property *of the Token Binding protocol. I would rather say that it is a *limitation *or a *deficiency *of the Token Binding protocol. Denis > draft-ietf-tokbind-protocol-15 already has language which says "The > Token Binding protocol does not prevent cooperating clients from > sharing a bound token. A client could intentionally export a bound > token with the corresponding Token Binding private key, or perform > signatures using this key on behalf of another client." I don't think > we need any additional language in this draft regarding client > collusion. That clients could collude is a property of the Token > Binding protocol, so it doesn't need to be repeated in this > application profile for using Token Binding. > > On Fri, Jul 21, 2017 at 2:21 AM, Denis wrote: >> This ID is still lacking to indicate that this mechanism will be >> ineffective in case of a collusion between clients. >> >> This should be clearly indicated in the Security Considerations section. >> >> Denis >> >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Token Binding WG of the IETF. >>> >>> Title : Token Binding over HTTP >>> Authors : Andrei Popov >>> Magnus Nyström >>> Dirk Balfanz >>> Adam Langley >>> Nick Harper >>> Jeff Hodges >>> Filename : draft-ietf-tokbind-https-10.txt >>> Pages : 22 >>> Date : 2017-07-21 >>> >>> Abstract: >>> This document describes a collection of mechanisms that allow HTTP >>> servers to cryptographically bind security tokens (such as cookies >>> and OAuth tokens) to TLS connections. >>> >>> We describe both first-party and federated scenarios. In a first- >>> party scenario, an HTTP server is able to cryptographically bind the >>> security tokens it issues to a client, and which the client >>> subsequently returns to the server, to the TLS connection between the >>> client and server. Such bound security tokens are protected from >>> misuse since the server can generally detect if they are replayed >>> inappropriately, e.g., over other TLS connections. >>> >>> Federated token bindings, on the other hand, allow servers to >>> cryptographically bind security tokens to a TLS connection that the >>> client has with a different server than the one issuing the token. >>> >>> This Internet-Draft is a companion document to The Token Binding >>> Protocol. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-tokbind-https-10 >>> https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-https-10 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-https-10 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 --------------39799C4715F5C184202EC647 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Nick,

A person reading draft-ietf-tokbind-https will not necessarily also read draft-ietf-tokbind-protocol.

So, I believe it is necessary to warn again the reader in the Security Considerations section.
Duplication of the text you quoted in that section would address my concern.

You said that the fact that clients could collude is a property of the Token Binding protocol.
I would rather say that it is a limitation or a deficiency of the Token Binding protocol.

Denis

draft-ietf-tokbind-protocol-15 already has language which says "The
Token Binding protocol does not prevent cooperating clients from
sharing a bound token.  A client could intentionally export a bound
token with the corresponding Token Binding private key, or perform
signatures using this key on behalf of another client." I don't think
we need any additional language in this draft regarding client
collusion. That clients could collude is a property of the Token
Binding protocol, so it doesn't need to be repeated in this
application profile for using Token Binding.

On Fri, Jul 21, 2017 at 2:21 AM, Denis <denis.ietf@free.fr> wrote:

This ID is still lacking to indicate that  this mechanism will be
ineffective in case of a collusion between clients.

This should be clearly indicated in the Security Considerations section.

Denis



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Token Binding WG of the IETF.

         Title           : Token Binding over HTTP
         Authors         : Andrei Popov
                           Magnus Nyström
                           Dirk Balfanz
                           Adam Langley
                           Nick Harper
                           Jeff Hodges
        Filename        : draft-ietf-tokbind-https-10.txt
        Pages           : 22
        Date            : 2017-07-21

Abstract:
    This document describes a collection of mechanisms that allow HTTP
    servers to cryptographically bind security tokens (such as cookies
    and OAuth tokens) to TLS connections.

    We describe both first-party and federated scenarios.  In a first-
    party scenario, an HTTP server is able to cryptographically bind the
    security tokens it issues to a client, and which the client
    subsequently returns to the server, to the TLS connection between the
    client and server.  Such bound security tokens are protected from
    misuse since the server can generally detect if they are replayed
    inappropriately, e.g., over other TLS connections.

    Federated token bindings, on the other hand, allow servers to
    cryptographically bind security tokens to a TLS connection that the
    client has with a different server than the one issuing the token.

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


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tokbind-https-10
https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-https-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-https-10


Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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


--------------39799C4715F5C184202EC647-- From nobody Fri Jul 21 03:04:13 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F49129B40 for ; Fri, 21 Jul 2017 03:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSKNpF-MS5ky for ; Fri, 21 Jul 2017 03:04:10 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::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 57F7F129B3A for ; Fri, 21 Jul 2017 03:04:10 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id v105so50276577wrb.0 for ; Fri, 21 Jul 2017 03:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=FhJW4vQ0L/vYg7XCAIHcg75MSflg7k/Cn/Qv82SqhxE=; b=zQ4aq2mc3cbzjEroweIkhabbqxDyEsVmVtf+X++ztTJG3/teXTioLalnhE4fiuu5Mb 3DU9PHVUUNiMi3NyaOHF8x+6k2LKtEoTwhJdB9W76K8Loc6f21wxthEQZs39TVnqYGrU 4A7blTY/SyPkMYWdvhCmPBbXoDejbY+lxVV5ZnruOulE5bwsAQX/fMkzjOI12LUCN8+1 BamrDlIzwbBtkT9esOQph4DM2eZIOX9rQC9A72ZUjkPRUuo6Va3/6uT7swB4EXeO40Ff Eg6GYQUAEwh/kGc3T1ijQFKuKBeo+YIykZK/ZpFEJnF7VSbqJMyCn1+S2jb0CcUY0OXJ xqXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FhJW4vQ0L/vYg7XCAIHcg75MSflg7k/Cn/Qv82SqhxE=; b=GdJNPh//WHTDQptgVwIb6hRoEjteWBgKiOPUoc7oatj0aT9EB2H9ic8n/uo/bioBeu /YGVMatodS0o/hOv74Lt5e23WShSZowCPXD5ChD2Tb63cYapZ9AN51jwZspKBOXLy+4h jK9DDcXgGSWORDhvM9cA6z7hMxFh/G+pdxn2nKp8ehegvVWZGocp9siIgNVCekvl2ERi K8byvy5I3I2RStGP+0i9h+VlPTY92DGlYeWIs01DNfbtZRU1xA8XzHgJl1Zu8/ouy4wb ucc7kUfdNbuNw2KviCm4572G4KbXyymf2kvd2+ZLqslJgsMoDX1HJ/cMd//1IN17ErZ3 /uxw== X-Gm-Message-State: AIVw111XZYeV5OkZxrLNA3Wy4Z1brDUPmU1gaSA9pHP5Kej1kGDVujMz N68CZBm5GH/OMz48qmkh5g== X-Received: by 10.223.136.178 with SMTP id f47mr6291482wrf.250.1500631448725; Fri, 21 Jul 2017 03:04:08 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:9490:a0c5:8deb:dc85? ([2001:67c:370:128:9490:a0c5:8deb:dc85]) by smtp.gmail.com with ESMTPSA id 189sm1380253wmh.0.2017.07.21.03.04.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jul 2017 03:04:05 -0700 (PDT) To: unbearable@ietf.org References: <150062800542.11311.4823917490193775849@ietfa.amsl.com> <6029f39a-ea91-a5ae-60cf-d52d0aeeb718@free.fr> <733401bb-4204-ebfb-1e4d-49c70eec2604@free.fr> From: Leif Johansson Message-ID: Date: Fri, 21 Jul 2017 12:04:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <733401bb-4204-ebfb-1e4d-49c70eec2604@free.fr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-https-10.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 10:04:12 -0000 On 2017-07-21 11:40, Denis wrote: > Nick, > > A person reading draft-ietf-tokbind-https will not necessarily also read > draft-ietf-tokbind-protocol. Since there is text in draft-ietf-tokbind-https with normative references to draft-ietf-tokbind-protocol I don't believe that is a reasonable assumption. Cheers Leif From nobody Fri Jul 21 04:03:16 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA8412EB2B for ; Fri, 21 Jul 2017 04:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrOISbmL6S2J for ; Fri, 21 Jul 2017 04:03:08 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A6F129B7A for ; Fri, 21 Jul 2017 04:03:08 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 83A1C7802B2; Fri, 21 Jul 2017 13:03:06 +0200 (CEST) To: Leif Johansson , unbearable@ietf.org References: <150062800542.11311.4823917490193775849@ietfa.amsl.com> <6029f39a-ea91-a5ae-60cf-d52d0aeeb718@free.fr> <733401bb-4204-ebfb-1e4d-49c70eec2604@free.fr> From: Denis Message-ID: <727870d8-4bb0-b465-9fe5-005073d6c4f1@free.fr> Date: Fri, 21 Jul 2017 13:03:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------18870F998F957F45BB8FEB21" Content-Language: en-US Archived-At: Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-https-10.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:03:10 -0000 This is a multi-part message in MIME format. --------------18870F998F957F45BB8FEB21 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Leif, The text that was quoted is in the Security Considerations section under section "7.1. Security Token Replay" from draft-ietf-tokbind-protocol. I already said on the list that the text does not fit under section 7.1 since it is not a security token *replay* in any sense, since the legitimate client is not playing anything, so it cant' be a replay. It should be under a specific section called, e.g.: Client collusion. It is particularly important that readers realize that this protection is not effective under some circumstances. Is there any harm to warn the user in both documents ? Denis > > On 2017-07-21 11:40, Denis wrote: >> Nick, >> >> A person reading draft-ietf-tokbind-https will not necessarily also read >> draft-ietf-tokbind-protocol. > Since there is text in draft-ietf-tokbind-https with normative > references to draft-ietf-tokbind-protocol I don't believe that > is a reasonable assumption. > > Cheers Leif > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --------------18870F998F957F45BB8FEB21 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Leif,

The text that was quoted is in the Security Considerations section under section "7.1.  Security Token Replay"
from draft-ietf-tokbind-protocol.

I already said on the list that the text does not fit under section 7.1 since it is not a security token replay in any sense,
since the legitimate client is not playing anything, so it cant' be a replay.

It should be under a specific section called, e.g.: Client collusion.
 
It is particularly important that readers realize that this protection is not effective under some circumstances.

Is there any harm to warn the user in both documents  ?

Denis


On 2017-07-21 11:40, Denis wrote:

Nick,

A person reading draft-ietf-tokbind-https will not necessarily also read
draft-ietf-tokbind-protocol.

Since there is text in draft-ietf-tokbind-https with normative
references to draft-ietf-tokbind-protocol I don't believe that
is a reasonable assumption.

	Cheers Leif

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


--------------18870F998F957F45BB8FEB21-- From nobody Fri Jul 21 04:26:23 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94C81317BB for ; Fri, 21 Jul 2017 04:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvM5rmYUmV68 for ; Fri, 21 Jul 2017 04:26:15 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B562131935 for ; Fri, 21 Jul 2017 04:26:13 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id w191so11374587wmw.1 for ; Fri, 21 Jul 2017 04:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xUw/vdzQTzporWiV5sIgZwRHgJXEFeMSeK+LN6LJ+xQ=; b=rgx3896UjyxvOq4auJdhKxT+WyQS2I6ivA5yc+zrfhAwKX7InHqy0rFTMaE0MzoSnn CLUPos5htaf27fyAKZudrWtXpCm1jm42Zz3/58169XwDmw7XxkrktuML19bSgwwYIcEh n/pmVyFy070jQdziW3f+GeUhxfQ7FNXU96ZaqKi6jGZALwfUwF2+rpDxxiskshwm1I+m sv8m5wZtNfLMWsF1aTa/SxZoYvMvKViN865uj469zr7s+WpQhjjkc1ki8Dmo38N3oB9y gnBpuN3VmO5Z3IfNt75e1xdMVFAv06I/clL4XaKxAlqeWL0jSxFeALiA8I1kdWO5b4SE f8Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xUw/vdzQTzporWiV5sIgZwRHgJXEFeMSeK+LN6LJ+xQ=; b=GfBVYT6n/ILozwEtL+HtTEehpqJP8Ok1/Pz6fXKcUVAJKKduM2H6IAzAABV6cBl8ra T9DSIzQXU+kr/4rkm5VK6qhLd4iOgxz+imr8z3hHRmKz7FW0Uzo9wpysmTIOtXpAMAP3 bn/E//49nU81Rs8dJe+z7sq73fj1zc2SPuQf8iWuPQKE4gKW9aT1CMkacwUFwkDeiHy0 qTQ6j9NCJsX5bKMJOo9uIoAQVlc0kUkminFudelx+WOlKuiUAi3YFixe/N/FuZbn+Hc4 j2MfKmU0fRiJ9e4nit3WrrbIDp/BMsZEB47fXVj2fDhPbiEvLAT5Q2aZ2E/WdxSx1BG+ mN2Q== X-Gm-Message-State: AIVw113lnOblKvvXcForJ4wNENquDP1UHRHW8LyhKzV0sMIoPEBTqOGf k4hDdBhpYVbBwMxekzac+g== X-Received: by 10.28.13.138 with SMTP id 132mr4614519wmn.23.1500636369994; Fri, 21 Jul 2017 04:26:09 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:d8dd:5a18:f264:f33f? ([2001:67c:1232:144:d8dd:5a18:f264:f33f]) by smtp.gmail.com with ESMTPSA id 39sm7449458wrc.84.2017.07.21.04.26.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jul 2017 04:26:09 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-D4D7D733-C8D3-4BFC-83E7-0681C962A28F Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (14F89) In-Reply-To: <727870d8-4bb0-b465-9fe5-005073d6c4f1@free.fr> Date: Fri, 21 Jul 2017 13:26:08 +0200 Cc: unbearable@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <150062800542.11311.4823917490193775849@ietfa.amsl.com> <6029f39a-ea91-a5ae-60cf-d52d0aeeb718@free.fr> <733401bb-4204-ebfb-1e4d-49c70eec2604@free.fr> <727870d8-4bb0-b465-9fe5-005073d6c4f1@free.fr> To: Denis Archived-At: Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-https-10.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 11:26:18 -0000 --Apple-Mail-D4D7D733-C8D3-4BFC-83E7-0681C962A28F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Skickat fr=C3=A5n min iPhone > 21 juli 2017 kl. 13:03 skrev Denis : >=20 > Leif, >=20 > The text that was quoted is in the Security Considerations section under s= ection "7.1. Security Token Replay"=20 > from draft-ietf-tokbind-protocol. I was not responding to that but to your claim that it is not reasonable to e= xpect implementors to read the full set of specs. It is. >=20 > I already said on the list that the text does not fit under section 7.1 si= nce it is not a security token replay in any sense,=20 > since the legitimate client is not playing anything, so it cant' be a repl= ay. >=20 > It should be under a specific section called, e.g.: Client collusion. > =20 > It is particularly important that readers realize that this protection is n= ot effective under some circumstances. >=20 > Is there any harm to warn the user in both documents ? >=20 > Denis >=20 >>> On 2017-07-21 11:40, Denis wrote: >>> Nick, >>>=20 >>> A person reading draft-ietf-tokbind-https will not necessarily also read= >>> draft-ietf-tokbind-protocol. >> Since there is text in draft-ietf-tokbind-https with normative >> references to draft-ietf-tokbind-protocol I don't believe that >> is a reasonable assumption. >>=20 >> Cheers Leif >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >=20 --Apple-Mail-D4D7D733-C8D3-4BFC-83E7-0681C962A28F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Skickat fr=C3=A5n min iPhone

21 juli 2017 kl. 13:03 skrev Denis <denis.ietf@free.fr>:

=20 =20 =20
Leif,

The text that was quoted is in the Security Considerations section under section "7.1.  Security Token Replay"
from draft-ietf-tokbind-protocol.
I was not responding to that but to your claim that it is not re= asonable to expect implementors to read the full set of specs. It is.
<= br>

I already said on the list that the text does not fit under section 7.1 since it is not a security token replay in any sense,
since the legitimate client is not playing anything, so it cant' be a replay.

It should be under a specific section called, e.g.: Client collusion.
 
It is particularly important that readers realize that this protection is not effective under some circumstances.

Is there any harm to warn the user in both documents  ?

Denis

On 2017-07-21 11:40, Denis wrote:

Nick,

A person reading draft-ietf-tokbind-https will not necessarily also read
draft-ietf-tokbind-protocol.

Since there is text in draft-ietf-tokbind-https with no=
rmative
references to draft-ietf-tokbind-protocol I don't believe that
is a reasonable assumption.

	Cheers Leif

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


=20
= --Apple-Mail-D4D7D733-C8D3-4BFC-83E7-0681C962A28F-- From nobody Fri Jul 21 08:17:38 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C69129B10 for ; Fri, 21 Jul 2017 08:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHrij8Yr1v6D for ; Fri, 21 Jul 2017 08:17:36 -0700 (PDT) Received: from treenet.co.nz (unknown [121.99.228.82]) by ietfa.amsl.com (Postfix) with ESMTP id 99E0B131761 for ; Fri, 21 Jul 2017 08:17:33 -0700 (PDT) Received: from [192.168.137.92] (unknown [121.98.43.66]) by treenet.co.nz (Postfix) with ESMTPA id 966C066001E for ; Sat, 22 Jul 2017 03:17:31 +1200 (NZST) To: unbearable@ietf.org References: <150062800542.11311.4823917490193775849@ietfa.amsl.com> <6029f39a-ea91-a5ae-60cf-d52d0aeeb718@free.fr> <733401bb-4204-ebfb-1e4d-49c70eec2604@free.fr> <727870d8-4bb0-b465-9fe5-005073d6c4f1@free.fr> From: Amos Jeffries Message-ID: <30205e60-624f-af43-e2af-e1f7c9bd29d9@treenet.co.nz> Date: Sat, 22 Jul 2017 03:17:31 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-https-10.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 15:17:38 -0000 On 21/07/17 23:26, Leif Johansson wrote: > > Skickat från min iPhone > > 21 juli 2017 kl. 13:03 skrev Denis: > >> Leif, >> >> The text that was quoted is in the Security Considerations section >> under section "7.1. Security Token Replay" >> from draft-ietf-tokbind-protocol. > > I was not responding to that but to your claim that it is not reasonable > to expect implementors to read the full set of specs. It is. > >> >> I already said on the list that the text does not fit under section >> 7.1 since it is not a security token *replay* in any sense, >> since the legitimate client is not playing anything, so it cant' be a >> replay. >> >> It should be under a specific section called, e.g.: Client collusion. >> >> It is particularly important that readers realize that this protection >> is not effective under some circumstances. >> >> Is there any harm to warn the user in both documents ? It is perhapse best to be aware that HTTP itself is stateless. This document focus is on how tokens are embeded into a single HTTP message, and what manipulations occur to that embedding during transfer. Not the content/values of those tokens, nor the content/values of the things bound with the token. There is no need to consider this collusion attack because in HTTP context there is only ever *one* client for a given message. There is no possibility of multiple clients sending a single message - that would be multiple messages in HTTP terms, even if they had identical headers and tokens. Each of those messages sent by the colluding clients MUST be interpreted through the draft-ietf-tokbind-protocol procedures independent of all other messages (even those really from the same client). Whether those procedures are relevant to the attack is a detail for that other document to address. Amos From nobody Sat Jul 22 01:25:20 2017 Return-Path: X-Original-To: unbearable@ietf.org Delivered-To: unbearable@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 509D9131C80; Sat, 22 Jul 2017 01:25:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: unbearable@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150071191927.20510.15815606577278545099@ietfa.amsl.com> Date: Sat, 22 Jul 2017 01:25:19 -0700 Archived-At: Subject: [Unbearable] I-D Action: draft-ietf-tokbind-ttrp-00.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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, 22 Jul 2017 08:25:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding WG of the IETF. Title : HTTPS Token Binding with TLS Terminating Reverse Proxies Author : Brian Campbell Filename : draft-ietf-tokbind-ttrp-00.txt Pages : 10 Date : 2017-07-21 Abstract: This document defines common HTTP header fields that enable a TLS terminating reverse proxy to convey information about the validated Token Binding Message sent by the client to a backend server, which enables that backend server to bind, or verify the binding of, cookies and other security tokens to the client's Token Binding key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-00 https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-ttrp-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 22 02:34:19 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1746C131D71 for ; Sat, 22 Jul 2017 02:34:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWWYOYIqQxpx for ; Sat, 22 Jul 2017 02:34:16 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E55131A7C for ; Sat, 22 Jul 2017 02:34:16 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id 123so37928295pgj.1 for ; Sat, 22 Jul 2017 02:34:16 -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=EpaMxukSTUX4ii+EfaNKyyQIOpIFn8H1pZqV3VR99Io=; b=AgAaF0quikisAgmt/n4+wx/EbILhNKA3fkCGfXokeOOR8VNFMmYTa9ofPqSZZVvyCl nRklKQvc7NWO2ueIDbIXP3jB8xK6jcKNm3vsMB8UynNNCl5DCySpCRTmQlRONSAq6RNZ urUD4hVwXZCY4oYuq35QcZjcMbaPPuLOeWoGA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EpaMxukSTUX4ii+EfaNKyyQIOpIFn8H1pZqV3VR99Io=; b=hxJk0YBCIMJrpCIvqEoqq688nJCzVxGgmIthQjnOQ+ZgLl8pcyXC0/R84wcKfMIMvH 9w9vXsNuylapgEAkS3PdHwx3qVg7AKFsbOAi8vBID00oCkYz/ai+c6mI+wcNvViQy1rI Uq2P5mKFiYI+Yw0RDxjQZgpy9yFnK4rqH8h29EPuKEBYemYtfre0hZ1IMjqK0POeJSVm EGvVLhsMhd1Y2t5a4mcdTu4/MryWwNBErDGijxI2lOux+nz/w3G4il6YbCc9xaW020Un jn8v82qGC5sz1DhERtW1fq2He7+YTYj32lw+guglSSz/rENMx+l74lnfCBEuSsM10ShE C3sQ== X-Gm-Message-State: AIVw112rpaiiOL8DC0jvWnDlYJ+nuiWpg49wtXtkjN8HvlKgdPlalRLW +1eKSIkNLhfhvVHDSkX9ohfQ4QBotAMfDloi3viJjUA1lR8N3gzuZ5aIS1PCZ2cMtsFkfFUnF4u gx3Q95lVinIU= X-Received: by 10.84.167.230 with SMTP id i35mr11020115plg.181.1500716055523; Sat, 22 Jul 2017 02:34:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Sat, 22 Jul 2017 02:34:14 -0700 (PDT) Received: by 10.100.145.87 with HTTP; Sat, 22 Jul 2017 02:34:14 -0700 (PDT) In-Reply-To: <0d7c3fcd-9140-6b0e-752b-81978d331869@sunet.se> References: <853ba12d-5859-1545-611d-74f0b1fbf533@sunet.se> <0d7c3fcd-9140-6b0e-752b-81978d331869@sunet.se> From: Brian Campbell Date: Sat, 22 Jul 2017 11:34:14 +0200 Message-ID: To: Leif Johansson Cc: IETF Tokbind WG Content-Type: multipart/alternative; boundary="94eb2c145cd66611cd0554e4af04" Archived-At: Subject: Re: [Unbearable] WG adoption of draft-campbell-tokbind-ttrp-00 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 09:34:18 -0000 --94eb2c145cd66611cd0554e4af04 Content-Type: text/plain; charset="UTF-8" Thanks Leif, The draft has been published: https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-00 On Jul 21, 2017 9:28 AM, "Leif Johansson" wrote: On 2017-07-17 17:50, Leif Johansson wrote: > > In the f2f meeting in Prague there was clear consensus to adopt > draft-campbell-tokbind-ttrp-00 as draft-ietf-tokbind-ttrp-00 > making this a WG document. > > If anyone on the list disagrees, now is the time to speak up. > > Cheers Leif & John > I think we can deal with Tonys concerns in the WG and given the strong support for adopting the document in the WG meeting I'm calling rough consensus on this. Brian: go ahead and publish draft-ietf-tokbind-ttrp-00 at your convenience. Cheers Leif _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --94eb2c145cd66611cd0554e4af04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Leif,=C2=A0

=
The draft has been published: https://tools.ietf.org/html/draft-i= etf-tokbind-ttrp-00

On Jul 21, 2017 9:28 AM, "Leif Johansson" = <leifj@sunet.se> wrote:
On 201= 7-07-17 17:50, Leif Johansson wrote:
>
> In the f2f meeting in Prague there was clear consensus to adopt
> draft-campbell-tokbind-ttrp-00 as draft-ietf-tokbind-ttrp-00
> making this a WG document.
>
> If anyone on the list disagrees, now is the time to speak up.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Cheers Leif & John
>

I think we can deal with Tonys concerns in the WG and given the
strong support for adopting the document in the WG meeting I'm
calling rough consensus on this.

Brian: go ahead and publish draft-ietf-tokbind-ttrp-00 at your
convenience.

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

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


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c145cd66611cd0554e4af04-- From nobody Fri Jul 28 10:39:57 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA81B131CF0 for ; Fri, 28 Jul 2017 10:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOWcwR-3VDsL for ; Fri, 28 Jul 2017 10:39:54 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4F91322EC for ; Fri, 28 Jul 2017 10:39:53 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id y15so94006467lfd.5 for ; Fri, 28 Jul 2017 10:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=IsWO8mhR711PlAMk3iGY1YvLAqqBNjPIyMKwNybGFaM=; b=btpSiftfMHT5J3hwpb+Vr/SeQbFM4ueK9PVwF7Uf2kqD3QVkeKdtDi81i890MnsCvD gfhDQnBqBSGZaomh984nlxr6RPoMjkxF0IVubp0hXKCC7dFT8LgDmSbO2PcV8O2xPq5a 6u+CIFzz2M1NJux5m4ZmDcJDmMqQxzMiWiy0aICsAu1il4ztL7FnMqdfuU6bwLFdIeja SAfkBT5viErUrLiPQ+RtPT1QnIAB4FUcMdF4mWkd/XglZzxTPtwkT6aSdeCpIk47gAOW MW+DNWmQ2pzbw2DvqixSuNp4ejsvxHCBVW8DLHy8flurxSabpBgySGzKH+PcX64Sh+UT 4hrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IsWO8mhR711PlAMk3iGY1YvLAqqBNjPIyMKwNybGFaM=; b=URSAkjZCAoL7p0V0ov/oiyzf47Ac3GBFqQYloX8m9nn7fldT8wZAQXHrEBpDYVDR6T B7Y+zXMUpHE9MTeNFXPpG647bp1zx2meWnRA/bLVk2k02P++eBKx1CP2EnS3s3CngYsQ WxNiE3U94D6/jWZqK/zTXQSAjfVX1KjQtPLqEH1fwexMOmyFcX3bsB+xK+QFaCKpJsMl xnfbzq6N6Ko7Cb3odSaJJ/MEx+E1UeDqw9Iv2BqtrN43DITRQtkHQNbRQWmFTI+iuy3s 3T4X5IXcwQTI6CBSglG+3DjtJXU7xMHxv8iti21EHI7W1J1G30IJ+WqUwOqh8n7UIeC1 Ao5A== X-Gm-Message-State: AIVw110jhCmO7wsZ9tG422qB5qad1jh7oJp6hBQGn2xERwpucKQydykt 3RbW1KD3jE8hN0I6nXd3g9gsUKq3/FzEljFDHQ== X-Received: by 10.46.14.9 with SMTP id 9mr3456675ljo.26.1501263591404; Fri, 28 Jul 2017 10:39:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.76.69 with HTTP; Fri, 28 Jul 2017 10:39:30 -0700 (PDT) From: Nick Harper Date: Fri, 28 Jul 2017 10:39:30 -0700 Message-ID: To: IETF Tokbind WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Unbearable] Token Binding for (1-RTT) TLS 1.3 draft X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 17:39:56 -0000 >From the discussion in Prague of wanting to define TB for TLS 1.3 (for 1-RTT connections) separately from draft-ietf-tokbind-tls13-0rtt, I wrote and uploaded https://datatracker.ietf.org/doc/draft-nharper-tokbind-tls13/ to provide a short and simple description of how to use TB with 1-RTT TLS 1.3. Is the working group interested in adopting this draft? From nobody Fri Jul 28 13:56:30 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05A0131473 for ; Fri, 28 Jul 2017 13:56:28 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvcJeGgFuEhG for ; Fri, 28 Jul 2017 13:56:26 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 AB96F12EC51 for ; Fri, 28 Jul 2017 13:56:26 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id q85so99798882pfq.1 for ; Fri, 28 Jul 2017 13:56:26 -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=OrLY2kTD1RvCPMgBGSq3pXBHyYB2POsfMaVO9WObQHY=; b=jDvRxmA0206EWLAzvisNrSQwFhFtdi7uukO+fuAPC2KF+ESvvQ7z/s9Ri5oOZ7ZfqP sZlX7veoHOffBtuUSeQ+0Y1dqW3byTHFD8vPWihY0T/VKecZtnk+bHCocqjQmHMRUNP7 9KOsVfgB3lo7jtc1WqQndLCutfnt1/aKVpxyg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OrLY2kTD1RvCPMgBGSq3pXBHyYB2POsfMaVO9WObQHY=; b=XU+1qHpe7ThgWbRA3Ts1eyPo745dpFoNzk3xpkW6JVcvrw+sytLCOQN8HpSyjyh0Hy ynP53UvDElKJLWBBKN/9cWX8xiaAMKoGCTFc/UORx7FdOYFi6LcUyMUbhCpu7ML+zvGU S5bMlo0bH0owd4AO0nOru1tcW94oSLTpux+UgjCaEfUxBHbaF39ukasWX3v15kTrDtYI 8ETcIEvL91DZtdOGlyODMHfDMazcurt3+QojXh5JVQR580xUbLQYZsQSDakLYK8XOTxr c/65fkzxegKwX9/C0BZQHWJ9wA3acry1EWeO39B8/kNbBOaxMAUH3xwe0UXNH2p//Ouh vtuw== X-Gm-Message-State: AIVw113rCoPVoqlYo/E5un8hNgHaKZVceMZXp+y9CCL7hmDLIHpzriXw crwiLkngfF+bYRad/mtzm0H7xcwhDf1QTFV187r6vB4mpdt53ByVCjWDCA7BmJkJiUP2C/1fapY o3pJ4qi/em6k= X-Received: by 10.84.212.1 with SMTP id d1mr9246017pli.17.1501275386318; Fri, 28 Jul 2017 13:56:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Fri, 28 Jul 2017 13:55:55 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Fri, 28 Jul 2017 14:55:55 -0600 Message-ID: To: Nick Harper Cc: IETF Tokbind WG Content-Type: multipart/alternative; boundary="f403045d1f5e1cb446055566eaf5" Archived-At: Subject: Re: [Unbearable] Token Binding for (1-RTT) TLS 1.3 draft X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 20:56:29 -0000 --f403045d1f5e1cb446055566eaf5 Content-Type: text/plain; charset="UTF-8" I was in the apparent minority in thinking that maybe it'd be better to have all the TB for TLS 1.3 stuff in one document. But, one doc or two, it seems like this needs to be defined somewhere so I support the WG considering adoption of draft-nharper-tokbind-tls13. On Fri, Jul 28, 2017 at 11:39 AM, Nick Harper wrote: > >From the discussion in Prague of wanting to define TB for TLS 1.3 (for > 1-RTT connections) separately from draft-ietf-tokbind-tls13-0rtt, I > wrote and uploaded > https://datatracker.ietf.org/doc/draft-nharper-tokbind-tls13/ to > provide a short and simple description of how to use TB with 1-RTT TLS > 1.3. Is the working group interested in adopting this draft? > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --f403045d1f5e1cb446055566eaf5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was in the apparent minority in thinking that maybe it&#= 39;d be better to have all the TB for TLS 1.3 stuff in one document. But, o= ne doc or two, it seems like this needs to be defined somewhere so I suppor= t the WG considering adoption of draft-nharper-tokbind-tls13.


<= /div>

On Fri, Jul = 28, 2017 at 11:39 AM, Nick Harper <nharper@google.com> wrot= e:
>From the discussion in Prague of w= anting to define TB for TLS 1.3 (for
1-RTT connections) separately from draft-ietf-tokbind-tls13-0rtt, I
wrote and uploaded
https://datatracker.ietf.org/doc/d= raft-nharper-tokbind-tls13/ to
provide a short and simple description of how to use TB with 1-RTT TLS
1.3. Is the working group interested in adopting this draft?

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


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --f403045d1f5e1cb446055566eaf5-- From nobody Fri Jul 28 14:15:26 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E58D132186 for ; Fri, 28 Jul 2017 14:15:25 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1LsuUPMuk_5 for ; Fri, 28 Jul 2017 14:15:23 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e: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 D15D9132185 for ; Fri, 28 Jul 2017 14:15:23 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id u185so9787042pgb.1 for ; Fri, 28 Jul 2017 14:15:23 -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; bh=b5hpBWw0z1qs8jWPZaOIT26sM/x1g/oFmQxnh7T16Bg=; b=W9ZZ1HsltDEBMLPB8bjY0A28ItjdAJz+0it+MIUg8hxZic7zUaTILoeEl3spGpjsjm FXpxO6QyrU5rmMTXs3WSGWvWhqssLC8QkGbgSJFVfTMVgannJFheHwhpoJFcDoX0MU8o Qb31/sNUt6t9l5ygeHNPqa66uowt4+rLkDKIk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=b5hpBWw0z1qs8jWPZaOIT26sM/x1g/oFmQxnh7T16Bg=; b=QD1a/TDyhXgb++HkbUUGuL/fxKxaiYxbvhcxkRiIPLAG8vur9xE97rvnsV8e7QnJpS tpY3absXhCl7eNa4E9AwqUHdUmgSi9aVJgPZRE3VM/f3qiJsgxMNE2SWzmtPIjK0rE1/ gh1QWBaSp7bOr3E3wfLpXNVKFDMkAXkDHXckQJfKJ6G7UMLBtYvfKsfgD68jJ3wnoE6R B40qAecsRSVDZ9OP2JI0uAOAys94r0NU3EIAGfSj9PHXS4yTGPSfWDdUm4grf5lbxAgL ZFGSRgbGNWwUdT/jL2Cg4+87JioBBHkutdP/1EVPpkIX8HoaN0cFe89YTh2yTB64Tl4J huAw== X-Gm-Message-State: AIVw110rN2nw9hROdtXr73WS56ZHG1xxvWL0v/zgkpS6MxS63/X3Nq5I PgHv5xcwi4cvgGBtZhf3rykRp9SCOGx3mYmuOfOSw+ovm90k9f67uaG6Cv3CzFDPH9cZS2QIUEA N1CB+emrLBWgNhg== X-Received: by 10.84.210.203 with SMTP id a69mr9062063pli.395.1501276523215; Fri, 28 Jul 2017 14:15:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Fri, 28 Jul 2017 14:14:52 -0700 (PDT) From: Brian Campbell Date: Fri, 28 Jul 2017 15:14:52 -0600 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary="94eb2c09614ce05cf50555672d14" Archived-At: Subject: [Unbearable] Sec- prefixing the TTRP headers X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 21:15:25 -0000 --94eb2c09614ce05cf50555672d14 Content-Type: text/plain; charset="UTF-8" My sense in the Prague meeting was that the was pretty good consensus that the Sec- prefix should be used for the headers defined in -tokbind-ttrp. That make them "Sec-Provided-Token-Binding-ID" and "Sec-Referred-Token-Binding-ID". So, unless there's feedback on the list here that there's not consensus for it, I'll make that change in the next revision. -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --94eb2c09614ce05cf50555672d14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My sense in the Prague meeting was that the was pretty goo= d consensus that the Sec- prefix should be used for the headers defined in = -tokbind-ttrp. That make them "Sec-Provided-Token-Binding-ID" and= "Sec-Referred-Token-Binding-ID". So, unless there's feedback= on the list here that there's not consensus for it, I'll make that= change in the next revision.

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c09614ce05cf50555672d14-- From nobody Fri Jul 28 14:21:54 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126E712EC11 for ; Fri, 28 Jul 2017 14:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfjslVx1aMdT for ; Fri, 28 Jul 2017 14:21:51 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 DDC21132186 for ; Fri, 28 Jul 2017 14:21:50 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id y15so95737575lfd.5 for ; Fri, 28 Jul 2017 14:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=23WSnXkO92vBtgPOIyz2yiSEfv8+GGMvAE0tcM2/iLs=; b=Zz6FieE+updhIxdcEhnjaJyZJpOUbhigN9ktJ3Rj7gRwNw5c2PWxALW1yGnSGkuoHr bGnTDyBecpYVCM/vvQoHJH7JRSB0p+EBJfJQ6WYTFpjndB5U2XyXUdgK7IuX3es/AfH3 LCJxz3RrBbgGK0dCSnJcY+X9HsSJxy9b4QDi2RJUdWM5TR9Jc0x13SJob9YbA0urB43a 3pIuCdwjhk4y0eNfzIeLbgUOY3/l9LbJok1uPm63n111ZijC3OAHkiiC+vsh9tp7/MjV s1/7bdv/uQByb3x9qnMDFySxXZf0wp46jLXF2CLaNN3DHwNEqW1od2Dq1VXnGwlUkDdv 7Wlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=23WSnXkO92vBtgPOIyz2yiSEfv8+GGMvAE0tcM2/iLs=; b=O4ljFkJMXsPU6fUBNP1mN5c4j6BHsyOZhviCh0gUoRi7f3yE+STh9/T0DgbFN9BSZh tiuihjnNHZ17mCAOa9uL4gKSd6Zpph4P/N2ycxPtAkL2jkBfWQdQoKLH+g1NH3L7wPNM 611xuaBksVGa4ONzzCCNfmiNN7iDZxA8PytGaGdXHJrqGvI6QrXsheAlG/eMkxd+/gqH irpQMquCTwM1CHBxpX7TwS6D3FX0ZTPq4p8pMzhWCT+HkKbEOQzGThRzsrEENiAhjKFL 5n9culA7CZkcR+o2u+75nTqxy4r5jzf/mZIlCYjZjxln4YmyoqiGrXuBi54d5ql/0GTH ju0Q== X-Gm-Message-State: AIVw113+p6UX3nr4ainsBT8fi4+yj8iQ5clLb1kAZheR8YszTuwyKaZq 1eenDIcYV6gxjslCAEVK71lItZxZLTXY X-Received: by 10.46.71.198 with SMTP id u189mr3550815lja.110.1501276908883; Fri, 28 Jul 2017 14:21:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.76.69 with HTTP; Fri, 28 Jul 2017 14:21:28 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Fri, 28 Jul 2017 14:21:28 -0700 Message-ID: To: Brian Campbell Cc: IETF Tokbind WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Unbearable] Sec- prefixing the TTRP headers X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 21:21:53 -0000 That sounds like a good idea to add the Sec- prefix. On Fri, Jul 28, 2017 at 2:14 PM, Brian Campbell wrote: > My sense in the Prague meeting was that the was pretty good consensus that > the Sec- prefix should be used for the headers defined in -tokbind-ttrp. > That make them "Sec-Provided-Token-Binding-ID" and > "Sec-Referred-Token-Binding-ID". So, unless there's feedback on the list > here that there's not consensus for it, I'll make that change in the next > revision. > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you. > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable >