From nobody Tue Jul 3 09:08:49 2018 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 003DD1310EF; Tue, 3 Jul 2018 09:00:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: unbearable@ietf.org, ekr@rtfm.com X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063363192.4893.15989185324617008565.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:31 -0700 Archived-At: Subject: [Unbearable] tokbind - Requested session has been scheduled for IETF 102 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.26 List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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, 03 Jul 2018 16:00:42 -0000 Dear Leif Johansson, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tokbind Session 1 (1:30 requested) Friday, 20 July 2018, Afternoon Session I 1150-1320 Room Name: Centre Ville size: 200 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/tokbind.ics Request Information: --------------------------------------------------------- Working Group Name: Token Binding Area Name: Security Area Session Requester: Leif Johansson Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: ace tls oauth secevent People who must be present: Eric Rescorla Stephen Farrell Leif Johansson Dirk Balfanz John Bradley Andrey Popov Mike Jones Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jul 11 06:20:04 2018 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 0998A130DF9; Wed, 11 Jul 2018 06:20:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-tokbind-https@ietf.org, John Bradley , tokbind-chairs@ietf.org, ve7jtb@ve7jtb.com, unbearable@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153131520203.21655.3932420474208253938.idtracker@ietfa.amsl.com> Date: Wed, 11 Jul 2018 06:20:02 -0700 Archived-At: Subject: [Unbearable] Alissa Cooper's No Objection on draft-ietf-tokbind-https-18: (with COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.27 List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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, 11 Jul 2018 13:20:02 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-tokbind-https-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS. From nobody Wed Jul 11 07:20:19 2018 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 0F1F0130E8D for ; Wed, 11 Jul 2018 07:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0Zc6VXgLNMg for ; Wed, 11 Jul 2018 07:20:08 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B2B130E78 for ; Wed, 11 Jul 2018 07:20:08 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id h4-v6so21244616qtj.7 for ; Wed, 11 Jul 2018 07:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=mA2uhiPoYxcEcvaMZB59mNFJEuK/Q1m62uarSPTlyOs=; b=1XSeFuKADvJolmGiI7MBdwqRNwyolLnaKGb94vdqln+A/PWuL50NvtfjgJ6WxJEbK2 /xt25IvkZ0FAwGFaTVnTgMoaFFMXzPlpu4rId0HJ8COODX4FGznlsG/lN7Jlp6GlBHzx 63rkOxclUykHlTYry+rxUcu5I2dVXdHqW5hjkuh7WAiHaAwaOAV8OU73+jHHoz5fvZDs o3uO6Q7Vi+hd+8oneznkZT2rx3+DBEWtX/DcuvGMz/MOaCaB+lSpPwY5ujAogxaR3cEU if6aTOCke5Ti0x8SUtDSlr2HE1oiBmv+H5mgpzMR78NQCCDa/lWbsD5vYKVHYd8QdIoM 15TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=mA2uhiPoYxcEcvaMZB59mNFJEuK/Q1m62uarSPTlyOs=; b=rmX09VVwWtvx7FrowyxkHdRA/7GUO2UllEbh1nc21Duvhwwf3dO60+EVNlSyWm0ATX RLP0SUzhAtw1sdKwDpRGmz06uoGEJFwv4g6ggMKs+DGP0KGylMvEt/ZG6RrHsH28/M4P LJMk4QEYK4zA9yystrChB222Pv52JXjACeo65wEpZDCWQU45Ber5dYIEQ8Q+fpyaimwx cHmo5V32UFxG/sk50C5ihsk8HkjT3uxjpNHpWTGYTbo8SI9bb0Znw+0BY28bpgS39kXz RMeMBDmlsWgWZ+hBhsZDKsURXhitLAjwdmPzyWcNwVSJvnkxXIfzciK7cHsq7pzI6b1J HAIg== X-Gm-Message-State: APt69E1NDcQiOHjE0RV7X8N2MTr8CSQOtveDTiL+zo/qd0bRbPUK5ZSz 14nbYq1Z3j1uA57qa4IyL4FwWw== X-Google-Smtp-Source: AAOMgpcDQkKpVuw7h0TTR8SeXqPeraaC1O8NpF7cOteoL4GQeGCcgMc6LKjeejsa5i0NBD4Rs8egvg== X-Received: by 2002:ac8:174a:: with SMTP id u10-v6mr28272429qtk.367.1531318806978; Wed, 11 Jul 2018 07:20:06 -0700 (PDT) Received: from ?IPv6:::ffff:192.168.8.101? ([191.126.172.31]) by smtp.gmail.com with ESMTPSA id b3-v6sm9983006qtg.20.2018.07.11.07.20.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 07:20:05 -0700 (PDT) Message-ID: <5b461215.1c69fb81.930e2.0726@mx.google.com> MIME-Version: 1.0 To: Ben Campbell , The IESG Cc: "draft-ietf-tokbind-https@ietf.org" , "tokbind-chairs@ietf.org" , "unbearable@ietf.org" From: John Bradley Date: Wed, 11 Jul 2018 10:20:05 -0400 Importance: normal X-Priority: 3 In-Reply-To: <153003857719.18839.13626712531775084980.idtracker@ietfa.amsl.com> References: <153003857719.18839.13626712531775084980.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="_F199F463-E244-49AA-BD7C-7C3655F25511_" Archived-At: Subject: Re: [Unbearable] Ben Campbell's Yes on draft-ietf-tokbind-https-17: (with COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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, 11 Jul 2018 14:20:13 -0000 --_F199F463-E244-49AA-BD7C-7C3655F25511_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Thanks Ben, I have gone over 6 again, and think I see the confusion. The point of section 6 is to remind platforms that provide native HTTP API = to also expose token binding to the applications using them. An example native app such as a OAuth client on a phone is not using redire= cts from the resource server to the Authorization Server, it is making a di= rect HTTP request to the AS Token Endpoint. If that app wants to include = the tokenbindingID from the connection to the Resource server as the referr= ed token binding in the HTTP POST to the token endpoint it needs some way i= n the HTTP API to signal sending the referred token binding for the other c= onnection. =20 IETF specs slip into a grey area when we start talking about API. The wor= k group participants wanted to keep this goal oriented rather than having a= ny wording that might impact there intended API implementations. In the third paragraph it is true that native API should only convey the re= ferred token binding to servers if signaled to do so by an application. It is also true in a general sense both for redirect and JS browser apps as= well. I think that while true the third paragraph may have morphed into more of a= general privacy concern, using redirect as an example. Would it work for you if we refocus the third paragraph to focus specifical= ly on native apps. Eg. Native API MUST only convey referred token binding information if sign= aled by an application. Then leave the rest to the Privacy Considerations reference. That or just dropping the third paragraph. Let me know and we can update in the final version=20 Regards John B. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS and substantive comments in pre-submission text. I did not check editorial comments. I have one remaining (non-blocking) question on section 6: Are the =E2=80=9Capplications=E2=80=9D from paragraph 3 the same as those from para= graph 2? It seems like paragraph 2 is talking more about local APIs (at least, I see that was mentioned in the text in version 17 but not in 18), but paragraph 3 uses an example of a signal from a server. (I can accept that the difference in con= trol may be weak enough for web applications that the distinction does not matte= r.) --_F199F463-E244-49AA-BD7C-7C3655F25511_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Thanks Ben,

=  

I have gone over 6 again, and thi= nk I see the confusion.

 

The point of section 6 is to remind platforms that provide n= ative HTTP API to also expose token binding to the applications using them.=

 

An examp= le native app such as a OAuth client on a phone is not using redirects from= the resource server to the Authorization Server, it is making a direct HTT= P request to the AS Token Endpoint.=C2=A0=C2=A0 If that app wants to includ= e the tokenbindingID from the connection to the Resource server as the refe= rred token binding in the HTTP POST to the token endpoint it needs some way= in the HTTP API to signal sending the referred token binding for the other= connection.=C2=A0 =C2=A0

 

IETF specs slip into a grey area when we start talking abo= ut API.=C2=A0=C2=A0 The work group participants wanted to keep this goal or= iented rather than having any wording that might impact there intended API = implementations.

 

In the third paragraph it is true that native API should only conve= y the referred token binding to servers if signaled to do so by an applicat= ion.

 

It i= s also true in a general sense both for redirect and JS browser apps as wel= l.

I think that while true the third paragraph may = have morphed into more of a general privacy concern, using redirect as an e= xample.

 

W= ould it work for you if we refocus the third paragraph to focus specificall= y =C2=A0on native apps.

 

Eg.=C2=A0 Native API MUST only convey referred token binding= information if signaled by an application.

&n= bsp;

Then leave the rest to the Privacy Consi= derations reference.

 

That or just dropping the third paragraph.

 

Let me know and we can updat= e in the final version

 

Regards

John B.

 

 

 

 

 

 =

 

 

 

The document, along with other ballot positions, can be found here:<= /p>

https://datatracker.ietf.org/doc/draft-ietf-tokbind= -https/

 

<= o:p> 

 

-------------------------------------------------------------------= ---

COMMENT:

--------------= --------------------------------------------------------

 

Thanks for addressing my DI= SCUSS and substantive comments in pre-submission

te= xt. I did not check editorial comments.

 =

I have one remaining (non-blocking) question= on section 6: Are the

=E2=80=9Capplications=E2=80= =9D from paragraph 3 the same as those from paragraph 2? It seems

like paragraph 2 is talking more about local APIs (at least,= I see that was

mentioned in the text in version 17= but not in 18), but paragraph 3 uses an

example of= a signal from a server. (I can accept that the difference in control

may be weak enough for web applications that the distinc= tion does not matter.)

 

 

 

= --_F199F463-E244-49AA-BD7C-7C3655F25511_-- From nobody Wed Jul 11 07:29:10 2018 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 EF5E71277BB; Wed, 11 Jul 2018 07:29:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , ekr@rtfm.com, John Bradley , draft-ietf-tokbind-https@ietf.org, unbearable@ietf.org, tokbind-chairs@ietf.org, ve7jtb@ve7jtb.com, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <153131934797.22195.16559250960445926514.idtracker@ietfa.amsl.com> Date: Wed, 11 Jul 2018 07:29:07 -0700 Archived-At: Subject: [Unbearable] Protocol Action: 'Token Binding over HTTP' to Proposed Standard (draft-ietf-tokbind-https-18.txt) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.27 List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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, 11 Jul 2018 14:29:09 -0000 The IESG has approved the following document: - 'Token Binding over HTTP' (draft-ietf-tokbind-https-18.txt) as Proposed Standard This document is the product of the Token Binding Working Group. The IESG contact persons are Benjamin Kaduk and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ Technical Summary 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. Working Group Summary This document achieved WG consensus and had no objections. Document Quality Multiple Implementations of Token Binding exist and have undergone informal interoperability testing. Google has token binding behind a feature flag in Chrome that is currently defaulted off. They have also implemented it in their reverse proxy infrastructure. They have also added support to the Boringssl open source project. Microsoft added support in Windows 10 RS2 at the beginning of 2017 (later back ported to RS1) . Edge and IE use that platform support. It is also available to other applications via system API. There is also support in ADFS. https://docs.microsoft.com/en-us/windows-server/security/token-binding/introducing-token-binding NGINX has an open source module https://github.com/google/ngx_token_binding Token Binding support for Apache https://github.com/google/ngx_token_binding Openssl patches in opensource https://github.com/google/token_bind Ping Identity has tested patches to Java and set up a test environment. https://www.ietf.org/mail-archive/web/unbearable/current/msg01332.html A useful slide share overview https://www.slideshare.net/Identiverse/beyond-bearer-token-binding-as-the-foundation-for-a-more-secure-web-cis-2017 Drafts using token binding exist in the OAuth work group and for OpenID Connect. Personnel John Bradley is the document shepherd and the responsible area director is Eric Rescorla. From nobody Wed Jul 11 09:34:44 2018 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 D996A130F58; Wed, 11 Jul 2018 09:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxnWMmw3oauw; Wed, 11 Jul 2018 09:34:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E38FC130F4A; Wed, 11 Jul 2018 09:34:28 -0700 (PDT) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6BGYLg0041058 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Jul 2018 11:34:22 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] Content-Type: multipart/signed; boundary="Apple-Mail=_5C00D37B-3A9F-4B05-A671-7D0C994A2DAE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Ben Campbell X-Priority: 3 In-Reply-To: <5b461215.1c69fb81.930e2.0726@mx.google.com> Date: Wed, 11 Jul 2018 11:34:19 -0500 Cc: The IESG , "draft-ietf-tokbind-https@ietf.org" , "tokbind-chairs@ietf.org" , "unbearable@ietf.org" Message-Id: References: <153003857719.18839.13626712531775084980.idtracker@ietfa.amsl.com> <5b461215.1c69fb81.930e2.0726@mx.google.com> To: John Bradley X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Unbearable] Ben Campbell's Yes on draft-ietf-tokbind-https-17: (with COMMENT) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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, 11 Jul 2018 16:34:31 -0000 --Apple-Mail=_5C00D37B-3A9F-4B05-A671-7D0C994A2DAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi John, Now that you see my confusion, I will leave it to you to decide how best = to fix it, if at all. Thanks! Ben. > On Jul 11, 2018, at 9:20 AM, John Bradley wrote: >=20 > Thanks Ben, >=20 > I have gone over 6 again, and think I see the confusion. >=20 > The point of section 6 is to remind platforms that provide native HTTP = API to also expose token binding to the applications using them. >=20 > An example native app such as a OAuth client on a phone is not using = redirects from the resource server to the Authorization Server, it is = making a direct HTTP request to the AS Token Endpoint. If that app = wants to include the tokenbindingID from the connection to the Resource = server as the referred token binding in the HTTP POST to the token = endpoint it needs some way in the HTTP API to signal sending the = referred token binding for the other connection. >=20 > IETF specs slip into a grey area when we start talking about API. = The work group participants wanted to keep this goal oriented rather = than having any wording that might impact there intended API = implementations. >=20 > In the third paragraph it is true that native API should only convey = the referred token binding to servers if signaled to do so by an = application. >=20 > It is also true in a general sense both for redirect and JS browser = apps as well. > I think that while true the third paragraph may have morphed into more = of a general privacy concern, using redirect as an example. >=20 > Would it work for you if we refocus the third paragraph to focus = specifically on native apps. >=20 > Eg. Native API MUST only convey referred token binding information if = signaled by an application. >=20 > Then leave the rest to the Privacy Considerations reference. >=20 > That or just dropping the third paragraph. >=20 > Let me know and we can update in the final version >=20 > Regards > John B. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for addressing my DISCUSS and substantive comments in = pre-submission > text. I did not check editorial comments. >=20 > I have one remaining (non-blocking) question on section 6: Are the > =E2=80=9Capplications=E2=80=9D from paragraph 3 the same as those from = paragraph 2? It seems > like paragraph 2 is talking more about local APIs (at least, I see = that was > mentioned in the text in version 17 but not in 18), but paragraph 3 = uses an > example of a signal from a server. (I can accept that the difference = in control > may be weak enough for web applications that the distinction does not = matter.) --Apple-Mail=_5C00D37B-3A9F-4B05-A671-7D0C994A2DAE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAltGMYsACgkQgFZKbJXz 1A2Y9hAAuL/C5L2Om4X/L/T4RUnkyn+qf+n3lqzs/sQ6I0XgtLXQ/xU7fRbFv1Gb eHTLOXGKEECxjNRUM1tKdFoxfzMmnQWxppK+9R/uliqIuJ7PCu2QtDmVoohluSF7 FXjOLrIehNpadGezwDTFRdVDsLkh9sWtRDoZukCHbEdVKyThJFI3ktQC+TrvSJp3 hgZWD3xYYwEQ8BXmmt+CaRDHM96rDd95HbILLP4RLwh0rWXrGfBlQn0v2xatVHC7 cRS1x3anjnvIRPZsjpe8FLROjAX6GftVFSJ2Sg/Jj1jyMhvvYtvdC/y8jWwP/DbR ceaBOtfgrsPa+0Sei8z5GlWLs/qqGyug8gC2lFar66ZUYmh++wdCXBT568enuvvK 1qt4zf+tJAFTexgeUutZAlWMxW91TelC+GSZTGj4cuRWhF9TiKGKEkEdmHHGAzbr iGgyD7drdgRXzDP8l15ktuWX+Lt0GMFxkcLdfSfDyR8CeSRXAG2yA1OaFG+6a2I6 /JGEINRbHUd+NMgRsVUL5+irM6EBSXinbJHyWaftVr6T0OSuOdzpIfdAYR6zhpid tln0t2uqOUFiACnfrfcAGjlC4dLl4+RlSLNHsHJRnFcZ2U+vxtf+X7skVfqAsh8b NCtQ+jsPf27VmG6AZRGLNEoYow76VY9QAn2XdqeE3N9N7iKDR+I= =fS1M -----END PGP SIGNATURE----- --Apple-Mail=_5C00D37B-3A9F-4B05-A671-7D0C994A2DAE-- From nobody Tue Jul 17 14:02:38 2018 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 9539C130DEB for ; Tue, 17 Jul 2018 14:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 oI90rrGbHFuq for ; Tue, 17 Jul 2018 14:02:32 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0251213104D for ; Tue, 17 Jul 2018 14:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1531861351; x=1563397351; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=1OVXQMI/JPyxkYySxdM1bmTTR1MbDu70qNfP3tjVVEI=; b=n90R/D8Ws4Nvl0v2aEcgQuvFHo8P+AG4ltsrKBxdWsUB0d8uV26H7rkf c7P7mwKtiCwYAuomj7Ufd+a9BD3nJhWXDzDj6qpBImf9iU3FcLwWzx0kb i7ios8vh/FPZWg9Kgb6QgOVFYWFCsoVx7udcd88pZEC3TAyK6dgJ/0UeS g=; X-IronPort-AV: E=Sophos;i="5.51,367,1526367600"; d="scan'208";a="350151116" Received: from unknown (HELO ironmsg02-sd.qualcomm.com) ([10.53.140.142]) by wolverine01.qualcomm.com with ESMTP; 17 Jul 2018 14:02:31 -0700 Received: from nasanexm01h.na.qualcomm.com ([10.85.0.34]) by ironmsg02-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 17 Jul 2018 14:02:22 -0700 Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01H.na.qualcomm.com (10.85.0.34) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 17 Jul 2018 14:02:01 -0700 Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1365.000; Tue, 17 Jul 2018 14:02:01 -0700 From: Giridhar Mandyam To: "unbearable@ietf.org" Thread-Topic: New version of Attested TLS Token Binding Thread-Index: AdQeCA4vaugyxA+3Q+uESV6F+H/I7A== Date: Tue, 17 Jul 2018 21:02:00 +0000 Message-ID: <7d26fe5e053944e48f5c35c2ba57f8f3@NASANEXM01C.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.80.80.8] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Unbearable] New version of Attested TLS Token Binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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, 17 Jul 2018 21:02:38 -0000 SGVsbG8gQWxsLA0KDQpJIGhvcGUgdG8gZGlzY3VzcyB0aGlzIGR1cmluZyBGcmlkYXkncyBtZWV0 aW5nLiAgU29tZSBvZiB0aGUgbWFqb3IgY2hhbmdlcyBzaW5jZSB2ZXIuIDAuNCBhbmQgdmVyLiAw LjM6DQoNCmEpIFByb3Bvc2FsIG9mIG5ldyBUTFMgZXh0ZW5zaW9ucyBjb2RlcG9pbnQgZm9yIHRv a2JpbmQgc2Vzc2lvbnMgdGhhdCB3aWxsIGludm9sdmUgdG9rYmluZC5leHRlbnNpb25zDQpiKSBQ cm9wb3NhbCBmb3IgbmVnb3RpYXRpbmcgdXNlIG9mIGV4dGVuc2lvbnMgIGFzIHBhcnQgb2YgVExT IGhhbmRzaGFrZQ0KYykgQWRkaXRpb24gb2YgdHdvIGJhc2UgYXR0ZXN0YXRpb24gdHlwZXM6ICBB bmRyb2lkIEtleXN0b3JlIGFuZCBUUE12MiwgYWxvbmcgd2l0aCB2ZXJpZmljYXRpb24gcHJvY2Vk dXJlcyAoaGVhdmlseSBsZXZlcmFnZWQgZnJvbSBXZWJhdXRobikuDQpkKSBQcm9wb3NhbCBvZiBl c3RhYmxpc2htZW50IG9mIHRva2JpbmQgYXR0ZXN0YXRpb24gcmVnaXN0cnkuDQoNClRoZXJlIGFy ZSBzb21lIG90aGVyIGlzc3VlcyB0aGF0IEkgd291bGQgbGlrZSB0byBnZXQgZ3VpZGFuY2UgZnJv bSB0aGUgZ3JvdXAgb24gdGhlIHRvcGljIG9mIHRva2JpbmQuZXh0ZW5zaW9ucywgaW5jbHVkaW5n Og0KDQphKSBTaG91bGQgY2xpZW50cyBhZHZlcnRpc2Ugc3VwcG9ydGVkIGV4dGVuc2lvbnM/IA0K YikgU2hvdWxkIHNlcnZlcnMgc2VsZWN0IGV4dGVuc2lvbnMgdGhhdCB0aGV5IGFyZSBpbnRlcmVz dGVkIGluLCBhbmQgaGF2ZSB0aGUgY2xpZW50IHN1cHByZXNzIG90aGVyIGV4dGVuc2lvbnM/ICAN CmMpIFNob3VsZCBjbGllbnRzIGp1c3Qgc2VuZCBhbGwgZXh0ZW5zaW9ucyB0aGF0IHRoZXkgc3Vw cG9ydD8gIElmIHNvLCBjYW4gc2VydmVycyBqdXN0IGlnbm9yZSBleHRlbnNpb25zIGluIHdoaWNo IHRoZXkgaGF2ZSBubyBpbnRlcmVzdD8NCg0KQW5kIHNwZWNpZmljIHRvIHRoZSBhdHRlc3RhdGlv biBleHRlbnNpb24sDQoNCmQpIFNob3VsZCBjbGllbnRzIGFkdmVydGlzZSB0aGUgYXR0ZXN0YXRp b24gdHlwZXMgdGhleSBzdXBwb3J0ICh3aGljaCBtYXkgZXhwb3NlIHNvbWUgZmluZ2VycHJpbnRp bmcgc3VyZmFjZSk/ICBTaG91bGQgc2VydmVycyBjb21tdW5pY2F0ZSB0aGUgYXR0ZXN0YXRpb24g cm9vdHMgdGhhdCB0aGV5IHN1cHBvcnQ/DQoNCi1HaXJpIE1hbmR5YW0NCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyA8aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPiANClNlbnQ6IFR1ZXNkYXksIEp1bHkgMTcsIDIwMTggMTI6NTIgUE0N ClRvOiBHaXJpZGhhciBNYW5keWFtIDxtYW5keWFtQHF0aS5xdWFsY29tbS5jb20+OyBKb24gQXpl biA8amF6ZW5AcXRpLnF1YWxjb21tLmNvbT47IExhdXJlbmNlIEx1bmRibGFkZSA8bGx1bmRibGFA cXRpLnF1YWxjb21tLmNvbT4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtbWFuZHlhbS10b2tiaW5kLWF0dGVzdC0wNS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtbWFuZHlhbS10b2tiaW5kLWF0dGVzdC0wNS50eHQNCmhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgR2lyaWRoYXIgTWFuZHlhbSBhbmQgcG9zdGVkIHRvIHRoZSBJ RVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1tYW5keWFtLXRva2JpbmQtYXR0ZXN0DQpS ZXZpc2lvbjoJMDUNClRpdGxlOgkJQXR0ZXN0ZWQgVExTIFRva2VuIEJpbmRpbmcNCkRvY3VtZW50 IGRhdGU6CTIwMTgtMDctMTcNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJ CTEwDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LW1hbmR5YW0tdG9rYmluZC1hdHRlc3QtMDUudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWFuZHlhbS10b2tiaW5kLWF0dGVz dC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFu ZHlhbS10b2tiaW5kLWF0dGVzdC0wNQ0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbWFuZHlhbS10b2tiaW5kLWF0dGVzdA0KRGlmZjog ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1tYW5keWFt LXRva2JpbmQtYXR0ZXN0LTA1DQoNCkFic3RyYWN0Og0KICAgVG9rZW4gYmluZGluZyBhbGxvd3Mg SFRUUCBzZXJ2ZXJzIHRvIGJpbmQgYmVhcmVyIHRva2VucyB0byBUTFMNCiAgIGNvbm5lY3Rpb25z LiAgSW4gb3JkZXIgdG8gZG8gdGhpcywgY2xpZW50cyBvciB1c2VyIGFnZW50cyBtdXN0IHByb3Zl DQogICBwb3NzZXNzaW9uIG9mIGEgcHJpdmF0ZSBrZXkuICBIb3dldmVyLCBwcm9vZi1vZi1wb3Nz ZXNzaW9uIG9mIGENCiAgIHByaXZhdGUga2V5IGJlY29tZXMgdHJ1bHkgbWVhbmluZ2Z1bCB0byBh IHNlcnZlciB3aGVuIGFjY29tcGFuaWVkIGJ5DQogICBhbiBhdHRlc3RhdGlvbiBzdGF0ZW1lbnQu ICBUaGlzIHNwZWNpZmljYXRpb24gZGVzY3JpYmVzIGV4dGVuc2lvbnMgdG8NCiAgIHRoZSBleGlz dGluZyB0b2tlbiBiaW5kaW5nIHByb3RvY29sIHRvIGFsbG93IGZvciBhdHRlc3RhdGlvbg0KICAg c3RhdGVtZW50cyB0byBiZSBzZW50IGFsb25nIHdpdGggdGhlIHJlbGF0ZWQgdG9rZW4gYmluZGlu ZyBtZXNzYWdlcy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Fri Jul 20 05:52:25 2018 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 D6452130E90; Fri, 20 Jul 2018 05:52:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , ekr@rtfm.com, John Bradley , unbearable@ietf.org, tokbind-chairs@ietf.org, ve7jtb@ve7jtb.com, draft-ietf-tokbind-negotiation@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <153209114386.4387.8718891452946186976.idtracker@ietfa.amsl.com> Date: Fri, 20 Jul 2018 05:52:23 -0700 Archived-At: Subject: [Unbearable] Protocol Action: 'Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation' to Proposed Standard (draft-ietf-tokbind-negotiation-14.txt) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.27 List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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, 20 Jul 2018 12:52:24 -0000 The IESG has approved the following document: - 'Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation' (draft-ietf-tokbind-negotiation-14.txt) as Proposed Standard This document is the product of the Token Binding Working Group. The IESG contact persons are Benjamin Kaduk and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-negotiation/ Technical Summary In order to use the Token Binding protocol [I-D.ietf-tokbind-protocol], the client and server need to agree on the Token Binding protocol version and the parameters (signature algorithm, length) of the Token Binding key. This document specifies a new TLS [RFC5246] extension to accomplish this negotiation without introducing additional network round-trips in TLS 1.2 and earlier versions. The negotiation of the Token Binding protocol and key parameters in combination with TLS 1.3 and later versions is beyond the scope of this document. Working Group Summary This document achieved WG consensus and had no objections. Document Quality Multiple Implementations of Token Binding exist and have undergone informal interoperability testing. Google has token binding behind a feature flag in Chrome that is currently defaulted off. They have also implemented it in their reverse proxy infrastructure. They have also added support to the Boringssl open source project. Microsoft added support in Windows 10 RS2 at the beginning of 2017 (later back ported to RS1) . Edge and IE use that platform support. It is also available to other applications via system API. There is also support in ADFS. https://docs.microsoft.com/en-us/windows-server/security/token-binding/introducing-token-binding NGINX has an open source module https://github.com/google/ngx_token_binding Token Binding support for Apache https://github.com/google/ngx_token_binding Openssl patches in opensource https://github.com/google/token_bind Ping Identity has tested patches to Java and set up a test environment. https://www.ietf.org/mail-archive/web/unbearable/current/msg01332.html A useful slide share overview https://www.slideshare.net/Identiverse/beyond-bearer-token-binding-as-the-foundation-for-a-more-secure-web-cis-2017 Drafts using token binding exist in the OAuth work group and for OpenID Connect. Personnel John Bradley is the document shepherd and the responsible area director is Eric Rescorla. From nobody Fri Jul 20 09:33:18 2018 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 ECD381311D3; Fri, 20 Jul 2018 09:33:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , ekr@rtfm.com, John Bradley , unbearable@ietf.org, draft-ietf-tokbind-protocol@ietf.org, ve7jtb@ve7jtb.com, rfc-editor@rfc-editor.org, tokbind-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <153210439096.4382.14503309199781949614.idtracker@ietfa.amsl.com> Date: Fri, 20 Jul 2018 09:33:10 -0700 Archived-At: Subject: [Unbearable] Protocol Action: 'The Token Binding Protocol Version 1.0' to Proposed Standard (draft-ietf-tokbind-protocol-19.txt) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.27 List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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, 20 Jul 2018 16:33:11 -0000 The IESG has approved the following document: - 'The Token Binding Protocol Version 1.0' (draft-ietf-tokbind-protocol-19.txt) as Proposed Standard This document is the product of the Token Binding Working Group. The IESG contact persons are Benjamin Kaduk and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-protocol/ Technical Summary 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. Working Group Summary This document achieved WG consensus and had one objection. Document Quality Multiple Implementations of Token Binding exist and have undergone informal interoperability testing. Google has token binding behind a feature flag in Chrome that is currently defaulted off. They have also implemented it in their reverse proxy infrastructure. They have also added support to the boringssl open source project. Microsoft added support in Windows 10 RS2 at the beginning of 2017 (later back ported to RS1) . Edge and IE use that platform support. It is also available to other applications via system API. There is also support in ADFS. https://docs.microsoft.com/en-us/windows-server/security/token-binding/introducing-token-binding NGINX has an open source module https://github.com/google/ngx_token_binding Token Binding support for Apache https://github.com/google/ngx_token_binding Openssl patches in opensource https://github.com/google/token_bind Ping Identity has tested patches to Java and set up a test environment. https://www.ietf.org/mail-archive/web/unbearable/current/msg01332.html A useful slide share overview https://www.slideshare.net/Identiverse/beyond-bearer-token-binding-as-the-foundation-for-a-more-secure-web-cis-2017 Drafts using token binding exist in the OAuth work group and for OpenID Connect. Personnel John Bradley is the document shepherd and the responsible area director is Eric Rescorla. From nobody Fri Jul 20 10:21:08 2018 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 ACC6113117E for ; Fri, 20 Jul 2018 10:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXKkwn220LTF for ; Fri, 20 Jul 2018 10:20:56 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC1D130FB7 for ; Fri, 20 Jul 2018 10:20:56 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id 13-v6so22667367ois.1 for ; Fri, 20 Jul 2018 10:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ZJprd3cr5BwvbSZ1oZ0CHMmy2wbd8sW81WP/wGfHLSQ=; b=Rsii+PIrd2fQOAC4XmDcr5JopbvqYTb3dwg1lr3gY+OgnqSSUYX9MUIjZxWE8ZAOPo UOUAiMR8lS7fnu8iQfTxyd4LZA6nVzU7XbYbhivOxH5ldObgDdruOi4l7+HstZUmgH+S 2iyIhF9z8YKYKNC1nTVQatuY/IzW8C46AGMLwTUEq8no+JLKVPEkzFPdAnw/T8YrxHZF lenIcjM2RLZNBZjlbpgpIArJibYnLwK2GQ5GVS7hJzPlrhnC+zhZbEjHiszeVejxGPnD AhkGreqibAlIR0NYfYPz8ldM7webB6dEZspgI91xrCBwd2TzSMhuiXmi+WlL7OX1RlIt cxyA== 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=ZJprd3cr5BwvbSZ1oZ0CHMmy2wbd8sW81WP/wGfHLSQ=; b=V5bTox6+qMKn/QELNF8T8o/oYNiL3A4Z0ZSSXjBmCc/rnebi8QFD09UrcMH30GkPFZ NmMNujGxNN+P7XYohY+kQlV2YJ6OW5fKZCAWp+iDnodz5CPxqKGuXhqxZEtAF8fCoGEn 99M0EBGFyR8LI8h6gaVVMtzlkPCwqEBpt+SimWJX1+rF3ypbr+di+4hOJNEeu3Lvp4xi 2Vi4vUeEce0y0VgcodVh6srFk6wHKxhsYtmr1mMu1Y10xemisoF2x0W34l1YU0pw1qhZ loRe1kU/WKsJcaRgYb7jGAFrn6Gctry/limMBtkmxYJUZACOd7WcdcaJ06kA82bMGD8p tkwA== X-Gm-Message-State: AOUpUlE/LTbY3frfvkgu/7PtqJ6Fhapkmuj3VFiCDDyDhTDaJohDDF3G i8Pa59Lilrj/CDb0pkamuOfRLkjWVgUYGrMZ1NWWSu9Q X-Google-Smtp-Source: AAOMgpcMHX0PWmyCp9+V3BK+Qq1XUkX29+B1sFjEprpKF8YkrjQ0BS2uhu1HYT/bj6uQYxSoE8c0aLWRyI4HCtMNHpg= X-Received: by 2002:aca:b208:: with SMTP id b8-v6mr2868520oif.144.1532107255256; Fri, 20 Jul 2018 10:20:55 -0700 (PDT) MIME-Version: 1.0 From: Martin Thomson Date: Fri, 20 Jul 2018 13:20:45 -0400 Message-ID: To: IETF Tokbind WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Unbearable] Suggestions for TTRP X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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, 20 Jul 2018 17:21:05 -0000 My comments about authentication were misguided because I somehow missed that the section entitled "HTTP Headers" was in fact about authentication. My suggestion: move the TLS versions section to a new top-level section and make the contents of the HTTP Headers section the entirety of the security considerations. The TLS versions text isn't really a security consideration and having a more targetted security considerations section would be clearer. (Also, it avoids having an empty top-level section). From nobody Fri Jul 20 10:32:52 2018 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 61ACB1311FA for ; Fri, 20 Jul 2018 10:32:37 -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 nye56erZ8YPm for ; Fri, 20 Jul 2018 10:32:35 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 E5110131116 for ; Fri, 20 Jul 2018 10:32:34 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id p4-v6so15687886itf.2 for ; Fri, 20 Jul 2018 10:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6+TjsvvmMf9hZ7MIn3SrTge4Us3M7qf2mEKHi9WO8IA=; b=RZtc8vH9DtgoOqFPq6yG+Cl0Ujw6VqkYKSu3ph17QzDMXh5+m/VQCiM63QBaRHH9UR RARXHSCSQPuN8vudzTuegYhut7bnDx0kzcgbM6jXvBM60PGbt8fkBsBFAOcv85yLYqUD zSydagWJQycTlIRUnHqFQ19OEblpTKYygMqpw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6+TjsvvmMf9hZ7MIn3SrTge4Us3M7qf2mEKHi9WO8IA=; b=KD/dYYvZ2c9QT2bBreS5t/qIM9ZCvb1o2Ti0oXH+R8b806TWF2o3aUhsYGc3TMahb6 V3+p4OrPb57O7VBZOmQpbJKhHPNcKIERRacKU46vroaxOVeEvm9tX864sWph8usAihgB hkNtKMKHWga2I4CSQ2aobu3uqs5ABfbbT0gSTG84TVMTBOtJRnahBxe4Pxp3UJfgH1Qh iSusLIJR1NsOLlshu7vQTJ7ScRcY7AMZ+wdJKC2yZytE354NMuAtCPaORUlQnJIsdhEs cFrUlhCoaqWzYa8O4Cej3roFbVmYnp3+3lbfp+Py/CrUJn8nKG7E9sAnqeiqMfgXl202 Ucqw== X-Gm-Message-State: AOUpUlE2pHy7Ag0qDy2OrWjEezGafFUQRHPBZpxTNxmcKDdMVfaN4T5s kbXp5sUsOxwiAbPvSPzEBwyyMx3VrFEgPsF55IXHI+eO3hcUqndLV9V0tkn4IT8G22eI8K0F6w0 95Y/5UUZekK22i5fWdse/ X-Google-Smtp-Source: AAOMgpdiyeHG8ZsVkhkPZEzWMx38VWzJet9C4LBfUZv/B2anjItfsSIZhbgLmEQVSM76AKfiHBgYCuc8SOfzs75xH8U= X-Received: by 2002:a24:67d5:: with SMTP id u204-v6mr2668072itc.37.1532107954165; Fri, 20 Jul 2018 10:32:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Fri, 20 Jul 2018 13:32:22 -0400 Message-ID: To: Martin Thomson Cc: IETF Tokbind WG Content-Type: multipart/alternative; boundary="0000000000005dd8be057171ae8a" Archived-At: Subject: Re: [Unbearable] Suggestions for TTRP X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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, 20 Jul 2018 17:32:43 -0000 --0000000000005dd8be057171ae8a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the suggestion, Martin, I'll make that change in the next revision. On Fri, Jul 20, 2018, 1:21 PM Martin Thomson wrote: > My comments about authentication were misguided because I somehow > missed that the section entitled "HTTP Headers" was in fact about > authentication. > > My suggestion: move the TLS versions section to a new top-level > section and make the contents of the HTTP Headers section the entirety > of the security considerations. The TLS versions text isn't really a > security consideration and having a more targetted security > considerations section would be clearer. (Also, it avoids having an > empty top-level section). > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000005dd8be057171ae8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the suggestion, Martin, I'll make that cha= nge in the next revision.

On Fri, Jul 20, 2018, 1:21 PM Martin Thomson <martin.thomson@gmail.com> wrote:
My comments about authentication were misguided = because I somehow
missed that the section entitled "HTTP Headers" was in fact about=
authentication.

My suggestion: move the TLS versions section to a new top-level
section and make the contents of the HTTP Headers section the entirety
of the security considerations.=C2=A0 The TLS versions text isn't reall= y a
security consideration and having a more targetted security
considerations section would be clearer.=C2=A0 (Also, it avoids having an empty top-level section).

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

<= 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. --0000000000005dd8be057171ae8a-- From nobody Fri Jul 20 11:55:22 2018 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 893AD130F72 for ; Fri, 20 Jul 2018 11:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpByAgqL6LDW for ; Fri, 20 Jul 2018 11:55:15 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-co1nam05on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe50::723]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E69130EFA for ; Fri, 20 Jul 2018 11:55:15 -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:X-MS-Exchange-SenderADCheck; bh=zE1Vz6TRnbSHjKjpUAjEx/7IOiX0OkrqbYx4csWC10M=; b=ei33WjCl5oHa40PfFPQ2qaT4yzQ0JpncpTg8Vp0N0v6GrFFQa2ipO2oHIziKch8FYlIDd5mfFbHarK+MbqKz1GAWT55HxKVFs6dc4HbseA8pcjHp/PO1KtjmdZQOdttlF7q+V1x/TP5PyKe2zZnVOBR9L03UavnaEXQidTAOBnU= Received: from CY4PR21MB0774.namprd21.prod.outlook.com (10.173.192.20) by CY4PR21MB0183.namprd21.prod.outlook.com (10.173.193.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.995.1; Fri, 20 Jul 2018 18:55:14 +0000 Received: from CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::c1b7:ab2b:2d0a:ee27]) by CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::c1b7:ab2b:2d0a:ee27%6]) with mapi id 15.20.1017.000; Fri, 20 Jul 2018 18:55:14 +0000 From: Andrei Popov To: Giridhar Mandyam , "unbearable@ietf.org" Thread-Topic: New version of Attested TLS Token Binding Thread-Index: AdQeCA4vaugyxA+3Q+uESV6F+H/I7ACUkLjA Date: Fri, 20 Jul 2018 18:55:14 +0000 Message-ID: References: <7d26fe5e053944e48f5c35c2ba57f8f3@NASANEXM01C.na.qualcomm.com> In-Reply-To: <7d26fe5e053944e48f5c35c2ba57f8f3@NASANEXM01C.na.qualcomm.com> 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_Owner=andreipo@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-07-20T18:55:12.6935784Z; 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 x-originating-ip: [2001:67c:1232:144:9588:ba3e:2810:4148] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0183; 6:thD2AGEhIPIriztK4bvtFKc6TuzR0+GeOlSMh401liWq8EtUYqOkuifoI992Xsv2mpq7/4Ebtb6ClguSl+fVtuTnswZ3Q0/vSCWe1Macb2cy6PunoRzKZhuG2mmbo9Gu+c+Yds5YPHojVz9EPmuH+GavgVppqzjG8haTzxw67qX44nR3S6cts+UXLxLpmCMVDFCTqENi2mxCsXVE3Cs7hWdvOILrTCz36cQy2JGUBgXwxH6L/Bk0kU55ujGkl/lS7L2Mo9zR/De98bFHHhpJYfWuShSUU+dycJY5Njsa1VRKQFCzyArdKT8b6k+oK6JZkt4drUhx3CvGw1O3YgnP4gMftqTJbbSJVvT0XReMpnkDpBLoM5nwhrzvuWk6D1jEoZrcM8EMpvmV+Am62NZNSZUJIcnREFG4U2yeqraLj4Zxs1WoL6LQlHwEF8e9nEb1PoPykkR4z70PybWLeVBH8Q==; 5:qrsfHMhdJmgVl7ktkMJxmLfIQO+ASTBQIOos9RQK3Eagu+YE+gi48GwU/cuS3dBysadmhiFNOTvgkoSIhkHu8SSBHaOM7z4v5Hqw5BMkJMeFJ+1C+RSVqorW97LOekMKcq0q64M2BwPvq1HCJ10cD1Du9ilVOUYW7dU2L46+6pY=; 7:eMLnvUtmQG8ESjeWvR98yVWqpGbgve2k43T+dMeUw70AHbiJ8A64ndSpAP6wlAzQjbCf3se9NXFUhnq1dOtDMeMI2cfOIxC3ZCsVVVwSa701HEBL8FjNKZhydP+gr1iN1kSTgIJjJ91/eE218MY5Ozov27fpXF5sYmvTDY/37ekokVMgSPJcOF00RCLpwOHXFa6Jc5Gy836xc6L0KHjUhwpv9b51GbozR8N5E6sRXc5wWN89VSd1ZiYXkBOdlXid x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0fcfd878-d7ca-44fa-eb1a-08d5ee7253c8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600067)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:CY4PR21MB0183; x-ms-traffictypediagnostic: CY4PR21MB0183: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(189930954265078)(219752817060721); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(2018427008)(3002001)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:CY4PR21MB0183; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0183; x-forefront-prvs: 073966E86B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(136003)(366004)(396003)(199004)(189003)(53754006)(13464003)(10090500001)(8990500004)(110136005)(6116002)(14454004)(256004)(14444005)(6246003)(476003)(2906002)(81156014)(6306002)(9686003)(8676002)(81166006)(486006)(8936002)(2900100001)(5660300001)(305945005)(561944003)(55016002)(7736002)(966005)(106356001)(86362001)(575784001)(10290500003)(74316002)(97736004)(99286004)(478600001)(6436002)(186003)(68736007)(105586002)(53936002)(446003)(11346002)(2501003)(72206003)(46003)(5250100002)(316002)(86612001)(7696005)(53546011)(229853002)(22452003)(76176011)(6506007)(25786009)(102836004)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0183; H:CY4PR21MB0774.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9uaaPVZqCAecwxNo+vBoGY1rL4sfHzxPMBt6FypmyD0+HSlGwzcVAOOe0NEatbudQq7ebImxerow2oyD+AMyR5PIsGX1gbRG+BXEY+SgGBPPGB13DJ/7ZWnwlduumVFOK8hMVBeBZY7MFsK/Sd4duSFQwPpMPG0GuNGeZQoLCV0qvS6sgRkSIBnwFY1lh99IbmTgG2edS0Iyq+/vvzDzEIVquvgjFwmVQRpfmdlGUNG63nWTOj2lh6y1HMUuu8ccjL46n3Mfdpi8H06wMdKQ64un8735PxGFO6ogYTnCvSYpxftbiCfKi0L+KYXLvbOnyC5pPOkPg/YBlyQuxh6KmrCGQl/+R/lots7CR51I+vc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0fcfd878-d7ca-44fa-eb1a-08d5ee7253c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2018 18:55:14.1091 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0183 Archived-At: Subject: Re: [Unbearable] New version of Attested TLS Token Binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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, 20 Jul 2018 18:55:21 -0000 In addition to the more fundamental issues we discussed: - What are we attesting?=20 - Should EKM be involved?=20 - Should the extension be signed?=20 - What needs to be negotiated and how? here are some editorial issues I found while reading the spec: > ...whereby servers can leverage cryptographically- > bound authentication tokens to verify TLS connections. I'm not sure we can say that TB or bound tokens help verify TLS connections= . TB relies on TLS for negotiation and nonce. > This is useful for prevention of man-in-the-middle attacks on TLS session= s,... TB does not prevent MITM attacks on TLS, because a MITM can either prevent = parties from negotiating TB or mint bound tokens of its own. > 2.1. Token Binding Attestation Registry This belongs in the IANA section, so that it can be easily found. Cheers, Andrei -----Original Message----- From: Unbearable On Behalf Of Giridhar Mandya= m Sent: Tuesday, July 17, 2018 5:02 PM To: unbearable@ietf.org Subject: [Unbearable] New version of Attested TLS Token Binding Hello All, I hope to discuss this during Friday's meeting. Some of the major changes = since ver. 0.4 and ver. 0.3: a) Proposal of new TLS extensions codepoint for tokbind sessions that will = involve tokbind.extensions b) Proposal for negotiating use of extensions as part of TLS handshake c) Addition of two base attestation types: Android Keystore and TPMv2, alo= ng with verification procedures (heavily leveraged from Webauthn). d) Proposal of establishment of tokbind attestation registry. There are some other issues that I would like to get guidance from the grou= p on the topic of tokbind.extensions, including: a) Should clients advertise supported extensions?=20 b) Should servers select extensions that they are interested in, and have t= he client suppress other extensions? =20 c) Should clients just send all extensions that they support? If so, can s= ervers just ignore extensions in which they have no interest? And specific to the attestation extension, d) Should clients advertise the attestation types they support (which may e= xpose some fingerprinting surface)? Should servers communicate the attesta= tion roots that they support? -Giri Mandyam -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Tuesday, July 17, 2018 12:52 PM To: Giridhar Mandyam ; Jon Azen ; Laurence Lundblade Subject: New Version Notification for draft-mandyam-tokbind-attest-05.txt A new version of I-D, draft-mandyam-tokbind-attest-05.txt has been successfully submitted by Giridhar Mandyam and posted to the IETF = repository. Name: draft-mandyam-tokbind-attest Revision: 05 Title: Attested TLS Token Binding Document date: 2018-07-17 Group: Individual Submission Pages: 10 URL: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-mandyam-tokbind-attest-05.tx= t&data=3D02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a0784445098300= 8d5ec28a4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439= &sdata=3D7iVbWDGYoGe7LqpC9IdqMl0hEtoBHjB97frVvHEX2Bk%3D&reserved=3D= 0 Status: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mandyam-tokbind-attest%2F&da= ta=3D02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5ec28a= 4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439&sda= ta=3DhWksFyxxMjGhq%2Fe57IEGyiiHpFKmUOxLGzm02eewpXU%3D&reserved=3D0 Htmlized: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-mandyam-tokbind-attest-05&data=3D= 02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5ec28a4a2%7= C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439&sdata=3D= iR6RZq8MUwiyePBEgNhQi0MF3BQF92TKns8Ip255Gsc%3D&reserved=3D0 Htmlized: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mandyam-tokbind-attest&am= p;data=3D02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5e= c28a4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439&= ;sdata=3Dpr0ccS%2FMllsV5Cvrixl3oFJidNs%2BXs0ekRkoNFE0kBY%3D&reserved=3D= 0 Diff: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-mandyam-tokbind-attest-05&= ;data=3D02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5ec= 28a4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439&= sdata=3DCSRP9cMlllw1Xfn%2BAJI%2B9tfzm02hbvDctRNve3lb9Bs%3D&reserved=3D0 Abstract: Token binding allows HTTP servers to bind bearer tokens to TLS connections. In order to do this, clients or user agents must prove possession of a private key. However, proof-of-possession of a private key becomes truly meaningful to a server when accompanied by an attestation statement. This specification describes extensions to the existing token binding protocol to allow for attestation statements to be sent along with the related token binding messages. = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ 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%7CAndrei.Popov%40= microsoft.com%7C19470c8a07844450983008d5ec28a4a2%7C72f988bf86f141af91ab2d7c= d011db47%7C1%7C0%7C636674581665040447&sdata=3DoZPtCiwLy%2FctRkV4PmG6cS7= SaiCG5PYWAnLFjTU5fVs%3D&reserved=3D0 From nobody Tue Jul 24 12:13:08 2018 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 5472D130DCA for ; Tue, 24 Jul 2018 12:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgA_Gc8LS33w for ; Tue, 24 Jul 2018 12:13:04 -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 BDFC4130DE9 for ; Tue, 24 Jul 2018 12:13:04 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1532459584; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=/emBkpYId6ykhFTxipmnx470/PLFAHZrJ9qAmMa7Owo=; b=fqIjhhvW2gES6/HNjl043ryl0rqw5qSEHCckcpGEFTpkRfD4wK972VslOpon2uG7z7f9jY9+ /A4LIkZD/wqDMNbC8l7LWZVQU19gKHcukYDT4IUDfrPxtup2YSz7QZUyCdhAhiv28875fwBv h2OS5VlnzpjFFL5YO5kuIbp4EEY= X-Mailgun-Sending-Ip: 166.78.69.170 X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Sender: andreipo=microsoft.com@github.com Received: from github.com (Unknown [192.30.252.39]) by mxa.mailgun.org with ESMTP id 5b577a3f.7f9ab42d6ed0-smtp-out-n03; Tue, 24 Jul 2018 19:13:03 -0000 (UTC) Date: Tue, 24 Jul 2018 12:13:03 -0700 From: Andrei Popov Reply-To: Andrei Popov To: unbearable@ietf.org Message-ID: <5b577a3fcc26f_2d8b2ae0b27acf8452630@hookshot-fe-31feec6.cp1-iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_5b577a3fcbc34_2d8b2ae0b27acf8452586"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] 15884f: More editorial updates per EKR's comments. X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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, 24 Jul 2018 19:13:06 -0000 ----==_mimepart_5b577a3fcbc34_2d8b2ae0b27acf8452586 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: 15884f2c0fbddcf8b5d988d08296f359196966cc https://github.com/TokenBinding/Internet-Drafts/commit/15884f2c0fbddcf8b5d988d08296f359196966cc Author: Andrei Popov Date: 2018-07-24 (Tue, 24 Jul 2018) Changed paths: M draft-ietf-tokbind-https-18.xml M draft-ietf-tokbind-negotiation-14.xml M draft-ietf-tokbind-protocol-19.xml Log Message: ----------- More editorial updates per EKR's comments. **NOTE:** This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/ Functionality will be removed from GitHub.com on January 31st, 2019. ----==_mimepart_5b577a3fcbc34_2d8b2ae0b27acf8452586-- From nobody Tue Jul 24 16:03:18 2018 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 AA72E131217 for ; Tue, 24 Jul 2018 16:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 uvehzMfSOyO4 for ; Tue, 24 Jul 2018 16:03:13 -0700 (PDT) Received: from alexa-out-sd-02.qualcomm.com (alexa-out-sd-02.qualcomm.com [199.106.114.39]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69EDE1292F1 for ; Tue, 24 Jul 2018 16:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1532473393; x=1564009393; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=wdTJuGkX0adh4vJmYxykJ/QGDducoiMO+33u93ykFRU=; b=ap/5Wsv3hAJEK7Grtd4Cfj8Fi+M7mXhxZ1x9xTSP+8UGxbU3CChGcItK yCLp1vszxzLhCg7QPtNvNQ3WpIjXhqkkEm5vPulyX0aZqaj9OZDhXCwA/ WsNumJC8IJnGmprkh4mEZIuZGkZ88F5JHKCmO7ZhEV/wavLsCTmlp81P4 s=; X-IronPort-AV: E=Sophos;i="5.51,399,1526367600"; d="scan'208";a="7191665" Received: from unknown (HELO ironmsg03-sd.qualcomm.com) ([10.53.140.143]) by alexa-out-sd-02.qualcomm.com with ESMTP; 24 Jul 2018 16:03:12 -0700 X-IronPort-AV: E=McAfee;i="5900,7806,8964"; a="198778124" Received: from nasanexm01b.na.qualcomm.com ([10.85.0.82]) by ironmsg03-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 24 Jul 2018 16:03:12 -0700 Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01B.na.qualcomm.com (10.85.0.82) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 24 Jul 2018 16:03:11 -0700 Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1365.000; Tue, 24 Jul 2018 16:03:11 -0700 From: Giridhar Mandyam To: "unbearable@ietf.org" Thread-Topic: New version of Attested TLS Token Binding Thread-Index: AdQeCA4vaugyxA+3Q+uESV6F+H/I7ACUkLjAAM4+NkA= Date: Tue, 24 Jul 2018 23:03:11 +0000 Message-ID: <8644251f8fad4456b13c2b1bca1c315e@NASANEXM01C.na.qualcomm.com> References: <7d26fe5e053944e48f5c35c2ba57f8f3@NASANEXM01C.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.80.80.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Unbearable] New version of Attested TLS Token Binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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, 24 Jul 2018 23:03:17 -0000 Hi Andrei and others, Thanks for the feedback and the good discussion in Montreal. As per new version (-06). >- What are we attesting? Provenance of the tokbind keypair. >- Should EKM be involved? Latest version requires a signature over the hash of the tokbind public key= , as was suggested in Montreal. Replay protections for attestation are the= same as for the tokbind message (sec 3.3 of draft-ietf-tokbind-protocol). = The attestation therefore needs to only be generated once during the lifet= ime of the tokbind keypair.=20 >-Should the extension be signed? This is dependent on the type of attestation. The attestation types descri= bed in the document require signatures. There are others that are for secu= rity purposes the equivalent of unsigned attestations (e.g. 'Self Attestati= on' in https://w3c.github.io/webauthn/#sctn-attestation-types). An unsigne= d attestation could be added to the tokbind.extensions registry. >- What needs to be negotiated and how? Current draft keeps the proposed TLS handshake and new TLS extension codepo= int as previous version (-05). Current draft registers a new tokbind.exten= sion value for each attestation type. In other words, each attestation typ= e is a new tokbind.extension. There is only an octet provided for identifi= cation of tokbind extensions, but there seems to be only one use case ident= ified for tokbind.extensions as per Sec. 6.3 of draft-ietf-tokbind-protocol= . I don't expect that there will be 255 extension types added to the regis= try, but if the value field of tokbind.extension needs to accommodate 256 o= r more extensions then there are ways to extend the tokbind.extension valu= e field. >> ...whereby servers can leverage cryptographically-bound authentication t= okens to verify TLS connections. > I'm not sure we can say that TB or bound tokens help verify TLS connectio= ns. TB relies on TLS for negotiation and nonce. As per draft-ietf-tokbind-protocol, " The Token Binding protocol allows cli= ent/server applications to create long-lived, uniquely identifiable TLS bin= dings spanning multiple TLS sessions and connections." A TLS connection ca= n be verified by leveraging these 'long-lived, uniquely identifiable TLS bi= ndings'. You are correct however that it is more than just TB and bound to= kens that are required for this, but it was not my intention to state that = TB and bound tokens alone can be used for verification of a TLS connection. >>This is useful for prevention of man-in-the-middle attacks on TLS session= s,... > TB does not prevent MITM attacks on TLS, because a MITM can either preven= t parties from negotiating TB or mint bound tokens of its own. It was not my intention to say that TB prevents MITM. It is just one of ma= ny potential ways to detect MITM and apply countermeasures. This was a (ra= ther poor) paraphrasing of https://tools.ietf.org/html/draft-ietf-tokbind-h= ttps-08#section-7.4, which provided a more detailed overview of the role in= detection of MITM's (and I do realize that the latest version of this I.-D= . has moved this discussion to Sec. 7.3). In the latest draft, I have remo= ved this text. >>2.1. Token Binding Attestation Registry > This belongs in the IANA section, so that it can be easily found. Agreed. See latest version. -Giri Mandyam -----Original Message----- From: Andrei Popov =20 Sent: Friday, July 20, 2018 11:55 AM To: Giridhar Mandyam ; unbearable@ietf.org Subject: RE: New version of Attested TLS Token Binding In addition to the more fundamental issues we discussed: - What are we attesting?=20 - Should EKM be involved?=20 - Should the extension be signed?=20 - What needs to be negotiated and how? here are some editorial issues I found while reading the spec: > ...whereby servers can leverage cryptographically- > bound authentication tokens to verify TLS connections. I'm not sure we can say that TB or bound tokens help verify TLS connections= . TB relies on TLS for negotiation and nonce. > This is useful for prevention of man-in-the-middle attacks on TLS session= s,... TB does not prevent MITM attacks on TLS, because a MITM can either prevent = parties from negotiating TB or mint bound tokens of its own. > 2.1. Token Binding Attestation Registry This belongs in the IANA section, so that it can be easily found. Cheers, Andrei -----Original Message----- From: Unbearable On Behalf Of Giridhar Mandya= m Sent: Tuesday, July 17, 2018 5:02 PM To: unbearable@ietf.org Subject: [Unbearable] New version of Attested TLS Token Binding Hello All, I hope to discuss this during Friday's meeting. Some of the major changes = since ver. 0.4 and ver. 0.3: a) Proposal of new TLS extensions codepoint for tokbind sessions that will = involve tokbind.extensions b) Proposal for negotiating use of extensions as part of TLS handshake c) Addition of two base attestation types: Android Keystore and TPMv2, alo= ng with verification procedures (heavily leveraged from Webauthn). d) Proposal of establishment of tokbind attestation registry. There are some other issues that I would like to get guidance from the grou= p on the topic of tokbind.extensions, including: a) Should clients advertise supported extensions?=20 b) Should servers select extensions that they are interested in, and have t= he client suppress other extensions? =20 c) Should clients just send all extensions that they support? If so, can s= ervers just ignore extensions in which they have no interest? And specific to the attestation extension, d) Should clients advertise the attestation types they support (which may e= xpose some fingerprinting surface)? Should servers communicate the attesta= tion roots that they support? -Giri Mandyam -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Tuesday, July 17, 2018 12:52 PM To: Giridhar Mandyam ; Jon Azen ; Laurence Lundblade Subject: New Version Notification for draft-mandyam-tokbind-attest-05.txt A new version of I-D, draft-mandyam-tokbind-attest-05.txt has been successfully submitted by Giridhar Mandyam and posted to the IETF = repository. Name: draft-mandyam-tokbind-attest Revision: 05 Title: Attested TLS Token Binding Document date: 2018-07-17 Group: Individual Submission Pages: 10 URL: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-mandyam-tokbind-attest-05.tx= t&data=3D02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a0784445098300= 8d5ec28a4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439= &sdata=3D7iVbWDGYoGe7LqpC9IdqMl0hEtoBHjB97frVvHEX2Bk%3D&reserved=3D= 0 Status: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mandyam-tokbind-attest%2F&da= ta=3D02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5ec28a= 4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439&sda= ta=3DhWksFyxxMjGhq%2Fe57IEGyiiHpFKmUOxLGzm02eewpXU%3D&reserved=3D0 Htmlized: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-mandyam-tokbind-attest-05&data=3D= 02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5ec28a4a2%7= C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439&sdata=3D= iR6RZq8MUwiyePBEgNhQi0MF3BQF92TKns8Ip255Gsc%3D&reserved=3D0 Htmlized: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mandyam-tokbind-attest&am= p;data=3D02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5e= c28a4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439&= ;sdata=3Dpr0ccS%2FMllsV5Cvrixl3oFJidNs%2BXs0ekRkoNFE0kBY%3D&reserved=3D= 0 Diff: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-mandyam-tokbind-attest-05&= ;data=3D02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5ec= 28a4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439&= sdata=3DCSRP9cMlllw1Xfn%2BAJI%2B9tfzm02hbvDctRNve3lb9Bs%3D&reserved=3D0 Abstract: Token binding allows HTTP servers to bind bearer tokens to TLS connections. In order to do this, clients or user agents must prove possession of a private key. However, proof-of-possession of a private key becomes truly meaningful to a server when accompanied by an attestation statement. This specification describes extensions to the existing token binding protocol to allow for attestation statements to be sent along with the related token binding messages. = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ 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%7CAndrei.Popov%40= microsoft.com%7C19470c8a07844450983008d5ec28a4a2%7C72f988bf86f141af91ab2d7c= d011db47%7C1%7C0%7C636674581665040447&sdata=3DoZPtCiwLy%2FctRkV4PmG6cS7= SaiCG5PYWAnLFjTU5fVs%3D&reserved=3D0 From nobody Tue Jul 24 16:04:54 2018 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 D494C131218 for ; Tue, 24 Jul 2018 16:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 GNA6t7MrU_lH for ; Tue, 24 Jul 2018 16:04:49 -0700 (PDT) Received: from alexa-out-sd-02.qualcomm.com (alexa-out-sd-02.qualcomm.com [199.106.114.39]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C431292F1 for ; Tue, 24 Jul 2018 16:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1532473489; x=1564009489; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=9Amc+B3WqFQoDnKPnQbiNW4pV7E++tQcqnpKUkMRXgI=; b=IB7+h+MY6CsIoOMqLXBpuYy6xvK+cc+MCMNqoEnITh26/fCWUbUr6OSV 0BEPvEnXKfqXkpaBZvh3T9ukZfSnwDxCTy0NVA4MdK+pP9Ryp3IFs2F3N 9nOii0544GNrbpb5xZdCCNGCb6oGrcfnoLRxstRaI1ZdM9JPTr1o5su8U 0=; X-IronPort-AV: E=Sophos;i="5.51,399,1526367600"; d="scan'208";a="7191676" Received: from unknown (HELO ironmsg05-sd.qualcomm.com) ([10.53.140.145]) by alexa-out-sd-02.qualcomm.com with ESMTP; 24 Jul 2018 16:04:49 -0700 X-IronPort-AV: E=McAfee;i="5900,7806,8964"; a="122340435" Received: from nasanexm01h.na.qualcomm.com ([10.85.0.34]) by ironmsg05-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 24 Jul 2018 16:04:49 -0700 Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01H.na.qualcomm.com (10.85.0.34) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 24 Jul 2018 16:02:15 -0700 Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1365.000; Tue, 24 Jul 2018 16:02:15 -0700 From: Giridhar Mandyam To: "unbearable@ietf.org" Thread-Topic: New Version Notification for draft-mandyam-tokbind-attest (ver -06) Thread-Index: AdQjmi2dpy5I3GwiQhCzjQgVPBwEzA== Date: Tue, 24 Jul 2018 23:02:14 +0000 Message-ID: <2874af6cb12d4608b92663f534124954@NASANEXM01C.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.80.80.8] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Unbearable] New Version Notification for draft-mandyam-tokbind-attest (ver -06) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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, 24 Jul 2018 23:04:52 -0000 QXMgcGVyIHJlY29tbWVuZGF0aW9uIG9mIHRoZSBjaGFpcnMgYXQgbGFzdCB3ZWVrJ3MgbWVldGlu ZyBpbiBNb250cmVhbCwgYSBuZXcgdmVyc2lvbiBvZiB0aGlzIGRvYyBoYXMgYmVlbiB1cGxvYWRl ZC4gIFN1bW1hcnkgb2YgY2hhbmdlczoNCg0KYSkgRWFjaCBhdHRlc3RhdGlvbiB0eXBlIG5vdyBo YXMgaXRzIG93biB0b2tiaW5kLmV4dGVuc2lvbiB2YWx1ZS4gIFRoaXMgYWxsb3dlZCBmb3IgYSBz aW1wbGVyIGFkdmVydGlzZW1lbnQgb2Ygc3VwcG9ydGVkIGF0dGVzdGF0aW9uIHR5cGVzIGR1cmlu ZyB0aGUgVExTIGhhbmRzaGFrZSwgYXMgZWFjaCBlbmRwb2ludCBjYW4ganVzdCBzZW5kIGEgbGlz dCBvZiBzdXBwb3J0ZWQgZXh0ZW5zaW9ucy4gIFRoaXMgYWxzbyBhdm9pZHMgaGF2aW5nIHRvIGNy ZWF0ZSBhbiBhZGRpdGlvbmFsIHJlZ2lzdHJ5IGZvciBhdHRlc3RhdGlvbiB0eXBlcy4NCglUaGF0 IGJlaW5nIHNhaWQsIEkgcmVhbGl6ZSB0aGF0IHRoZXJlIGlzIG9ubHkgYW4gb2N0ZXQgZm9yIGlk ZW50aWZ5aW5nIHRva2JpbmQgZXh0ZW5zaW9ucy4gICBJdCBtYXkgYmUgc29tZXRoaW5nIGZvciB0 aGUgZ3JvdXAgdG8gY29uc2lkZXIgd2hldGhlciB0aGlzIGlzIHN1ZmZpY2llbnQuDQpiKSBUaGVy ZSBhcmUgdGhyZWUgSUFOQSByZWdpc3RyYXRpb25zIHByb3Bvc2VkOiAgb25lIGZvciB0aGUgbmV3 IFRMUyBleHRlbnNpb24gY29kZXBvaW50LCBhbmQgdHdvIGZvciB0aGUgcHJvcG9zZWQgYXR0ZXN0 YXRpb24gdHlwZXMgYXMgc2VwYXJhdGUgdG9rYmluZCBleHRlbnNpb25zLg0KYykgVGhlIGF0dGVz dGF0aW9uIHNpZ25hdHVyZSBmb3IgYm90aCB0eXBlcyAoQW5kcm9pZCBLZXlzdG9yZSBhbmQgVFBN KSBhcmUgbm93IGNyZWF0ZWQgb3ZlciBhIGhhc2ggb2YgdGhlIHRva2JpbmQgcHVibGljIGtleSAo YXMgc3VnZ2VzdGVkIGluIE1vbnRyZWFsKS4gIEluIHRoZSBwcmV2aW91cyB2ZXJzaW9uLCBpdCB3 YXMgb3ZlciBFS00uICBNb3Jlb3ZlciwgdGhlIHRva2JpbmQgY2xpZW50IG9ubHkgaGFzIHRvIHNl bmQgdGhlIGF0dGVzdGF0aW9uIG9uY2UgZHVyaW5nIHRoZSBsaWZldGltZSBvZiB0aGUgdG9rYmlu ZCBrZXlwYWlyLiAgDQoNClRoYW5rcywNCi1HaXJpIE1BbmR5YW0NCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyA8aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPiANClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjQsIDIwMTggMzowMiBQTQ0KVG86 IEdpcmlkaGFyIE1hbmR5YW0gPG1hbmR5YW1AcXRpLnF1YWxjb21tLmNvbT47IEpvbiBBemVuIDxq YXplbkBxdGkucXVhbGNvbW0uY29tPjsgTGF1cmVuY2UgTHVuZGJsYWRlIDxsbHVuZGJsYUBxdGku cXVhbGNvbW0uY29tPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1tYW5keWFtLXRva2JpbmQtYXR0ZXN0LTA2LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1tYW5keWFtLXRva2JpbmQtYXR0ZXN0LTA2LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBHaXJpZGhhciBNYW5keWFtIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYg cmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LW1hbmR5YW0tdG9rYmluZC1hdHRlc3QNClJldmlz aW9uOgkwNg0KVGl0bGU6CQlBdHRlc3RlZCBUTFMgVG9rZW4gQmluZGluZw0KRG9jdW1lbnQgZGF0 ZToJMjAxOC0wNy0yNA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTEN ClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtbWFuZHlhbS10b2tiaW5kLWF0dGVzdC0wNi50eHQNClN0YXR1czogICAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tYW5keWFtLXRva2JpbmQtYXR0ZXN0Lw0K SHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYW5keWFt LXRva2JpbmQtYXR0ZXN0LTA2DQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tYW5keWFtLXRva2JpbmQtYXR0ZXN0DQpEaWZmOiAgICAg ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1hbmR5YW0tdG9r YmluZC1hdHRlc3QtMDYNCg0KQWJzdHJhY3Q6DQogICBUb2tlbiBiaW5kaW5nIGFsbG93cyBIVFRQ IHNlcnZlcnMgdG8gYmluZCBiZWFyZXIgdG9rZW5zIHRvIFRMUw0KICAgY29ubmVjdGlvbnMuICBJ biBvcmRlciB0byBkbyB0aGlzLCBjbGllbnRzIG9yIHVzZXIgYWdlbnRzIG11c3QgcHJvdmUNCiAg IHBvc3Nlc3Npb24gb2YgYSBwcml2YXRlIGtleS4gIEhvd2V2ZXIsIHByb29mLW9mLXBvc3Nlc3Np b24gb2YgYQ0KICAgcHJpdmF0ZSBrZXkgYmVjb21lcyB0cnVseSBtZWFuaW5nZnVsIHRvIGEgc2Vy dmVyIHdoZW4gYWNjb21wYW5pZWQgYnkNCiAgIGFuIGF0dGVzdGF0aW9uIHN0YXRlbWVudC4gIFRo aXMgc3BlY2lmaWNhdGlvbiBkZXNjcmliZXMgZXh0ZW5zaW9ucyB0bw0KICAgdGhlIGV4aXN0aW5n IHRva2VuIGJpbmRpbmcgcHJvdG9jb2wgdG8gYWxsb3cgZm9yIGF0dGVzdGF0aW9uDQogICBzdGF0 ZW1lbnRzIHRvIGJlIHNlbnQgYWxvbmcgd2l0aCB0aGUgcmVsYXRlZCB0b2tlbiBiaW5kaW5nIG1l c3NhZ2VzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Fri Jul 27 08:31:33 2018 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 034DC130F8D for ; Fri, 27 Jul 2018 08:31:32 -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, RCVD_IN_MSPIKE_H2=-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 j5Y6bNV63rQS for ; Fri, 27 Jul 2018 08:31:30 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 852C6130F8A for ; Fri, 27 Jul 2018 08:31:30 -0700 (PDT) Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id B56E71421BB for ; Fri, 27 Jul 2018 09:14:41 -0600 (MDT) Received: from box514.bluehost.com ([74.220.219.114]) by cmsmtp with ESMTP id j4S1f3FNej0soj4S1fAGKr; Fri, 27 Jul 2018 09:14:41 -0600 X-Authority-Reason: nr=8 Received: from c-67-188-157-169.hsd1.ca.comcast.net ([67.188.157.169]:59832 helo=[10.0.0.71]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1fj4S1-004Ful-B2; Fri, 27 Jul 2018 09:14:41 -0600 To: IETF TokBind WG From: =JeffH Cc: Vinod Anupam , Nick Harper , Jeffrey Yasskin Message-ID: Date: Fri, 27 Jul 2018 08:14:40 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 67.188.157.169 X-Source-L: No X-Exim-ID: 1fj4S1-004Ful-B2 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-67-188-157-169.hsd1.ca.comcast.net ([10.0.0.71]) [67.188.157.169]:59832 X-Source-Auth: jeff.hodges@kingsmountain.com X-Email-Count: 1 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [Unbearable] wrt token binding and Fetch X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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, 27 Jul 2018 15:31:32 -0000 Current open PR: Update Fetch to support Token Binding https://github.com/whatwg/fetch/pull/715 (the above obsoletes the original PR ) reviewed: Summary: seems close to land-able in terms of addressing first-order integration with Fetch, although it does not seem to address second-order needs for other browser-internal functionality (eg WebAuthn) to be able to access connection token binding status and information. cf. https://github.com/w3c/webauthn/issues/360 HTH, =JeffH From nobody Fri Jul 27 08:49:22 2018 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 489BC130F8D; Fri, 27 Jul 2018 08:49:16 -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.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: unbearable@ietf.org Message-ID: <153270655627.32639.1936281630499401633@ietfa.amsl.com> Date: Fri, 27 Jul 2018 08:49:16 -0700 Archived-At: Subject: [Unbearable] I-D Action: draft-ietf-tokbind-ttrp-06.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.27 List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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, 27 Jul 2018 15:49:16 -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-06.txt Pages : 14 Date : 2018-07-27 Abstract: This document defines HTTP header fields that enable a TLS terminating reverse proxy to convey information to a backend server about the validated Token Binding Message received from a client, which enables that backend server to bind, or verify the binding of, cookies and other security tokens to the client's Token Binding key. This facilitates the reverse proxy and backend server functioning together as though they are a single logical server side deployment of HTTPS Token Binding. 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-ttrp-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-ttrp-06 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 27 08:56:48 2018 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 2D414130EA8 for ; Fri, 27 Jul 2018 08:56:47 -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 zR2WFi7uccpA for ; Fri, 27 Jul 2018 08:56:45 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 E3BD4130DE9 for ; Fri, 27 Jul 2018 08:56:44 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id q20-v6so8025607ith.0 for ; Fri, 27 Jul 2018 08:56:44 -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=hJ9zS2gqrK8QbCeVXt1lsRwKA4hqLc2yGSbejYPqShQ=; b=CDXCIIeMHWV+v+lIbwLnu4/fr68vHjXtYtr1AQSYyqwQtkhhGvq0By2u/R0cAx479z AzwSVtj4lnBpBexEJNJQH2Gbxuv0z+lIpem1CfJYORYj5HEzMWK8cK/KXDRzEP7MQNXi ScgGGMYIV51THN6THrAFxM4lEllob2waDVaSw= 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=hJ9zS2gqrK8QbCeVXt1lsRwKA4hqLc2yGSbejYPqShQ=; b=WOas7ToOihwc04CyzQqrqIn8WW3jHJTUpJHdeCFBrnpcAppUb4SmVqsUzXNdV0w2dM nIbmrqGiPNUdfQsh0q5AE2GxzeYnlw2mVrZT9MzcNFCIuVkTLvi5g6TVL0vQurKZKlEv LMrZEvcjtogzxVfIhK7HsD6vFGnMJt7WzjgycGXF9zJzV3fJbNlctAfKcA/03uyLypm0 HmCeNHxm2V2ohaO/odAWqNxxUcQPSCAnCmeBTJRrYtw9l5Uvg6mopLoo6XWDNey/BfGH sEKkuExDUGhxcp61ZvcGseBJj2mdsusKRGMhJQkaeHhuEcfxo4FQAc0Vyb+KTerUdCqY H9hg== X-Gm-Message-State: AOUpUlFs+IZR+ViE1gDCqEa+7ry5iBLTX1wS+rXs/invqo/3FBLMLcdo DOVeiZArj3kvOVNnx0toQLetetAz8RkIrBIu1XOwvVQx2hgNweTUjV/Vag7EC29ay5xEjxoE95O sV4/XbWRHi6w5I3IfvO486Zv0ew== X-Google-Smtp-Source: AAOMgpcmDNGy5+xMmh5nhFgyBhqa4g9y3K3hqz2w8na2Fv5WrLSiFS41lerfIpbHdeWOnz/Tsq3/hrCuJP7a2TzS9GM= X-Received: by 2002:a24:67d5:: with SMTP id u204-v6mr6074162itc.37.1532707004110; Fri, 27 Jul 2018 08:56:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:6d18:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 08:56:13 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Fri, 27 Jul 2018 09:56:13 -0600 Message-ID: To: Martin Thomson Cc: IETF Tokbind WG Content-Type: multipart/alternative; boundary="0000000000008675820571fd288a" Archived-At: Subject: Re: [Unbearable] Suggestions for TTRP X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. 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, 27 Jul 2018 15:56:47 -0000 --0000000000008675820571fd288a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Done in the just published -06 On Fri, Jul 20, 2018 at 11:32 AM, Brian Campbell wrote: > Thanks for the suggestion, Martin, I'll make that change in the next > revision. > > On Fri, Jul 20, 2018, 1:21 PM Martin Thomson > wrote: > >> My comments about authentication were misguided because I somehow >> missed that the section entitled "HTTP Headers" was in fact about >> authentication. >> >> My suggestion: move the TLS versions section to a new top-level >> section and make the contents of the HTTP Headers section the entirety >> of the security considerations. The TLS versions text isn't really a >> security consideration and having a more targetted security >> considerations section would be clearer. (Also, it avoids having an >> empty top-level section). >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >> > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000008675820571fd288a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Done in the just published -06

On Fri, Jul 20, 2018 at 11:32 AM, = Brian Campbell <bcampbell@pingidentity.com> wrote:<= br>
Thanks for the suggesti= on, Martin, I'll make that change in the next revision.

On Fri, Jul 20, 2018, 1:21 PM Martin Thomson <martin.thomson@gmail.com> wro= te:
My comments about authenticatio= n were misguided because I somehow
missed that the section entitled "HTTP Headers" was in fact about=
authentication.

My suggestion: move the TLS versions section to a new top-level
section and make the contents of the HTTP Headers section the entirety
of the security considerations.=C2=A0 The TLS versions text isn't reall= y a
security consideration and having a more targetted security
considerations section would be clearer.=C2=A0 (Also, it avoids having an empty top-level section).

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


<= 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. --0000000000008675820571fd288a--