Subject: Fwd: Protocol Action: 'Token Binding over HTTP' to Proposed Standard (draft-ietf-tokbind-https-18.txt)

From: Mark Nottingham <[email-masked]>
Date: Sat, 14 Jul 2018 12:28:48 -0400

FYI. Has anyone reviewed this from an HTTP perspective?

> Begin forwarded message:
> 
> From: The IESG <[email-masked]>
> Subject: Protocol Action: 'Token Binding over HTTP' to Proposed Standard (draft-ietf-tokbind-https-18.txt)
> Date: 11 July 2018 at 10:29:07 am GMT-4
> To: "IETF-Announce" <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], The IESG <[email-masked]>
> Reply-To: [email-masked]
> Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-announce/WvTXIDDHIHw5qn5MHX7fTpesrjM>
> 
> 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. 
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 15 Jul 2018 18:21:57 +1200

> FYI. Has anyone reviewed this from an HTTP perspective?

I have done some irregular reviews vis-a-vis the RFC 723x and 7541
requirements, and loosely following the Unbearable WG discussions.

There are some necessary ambiguities since HTTP has a number of
use-cases which are incompatible with bound tokens. But overall
implementations compliant with HTTP should handle messages containing
bound tokens safely, and binding implementations compliant with that
document should be sane HTTP participants.

AYJ