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

FYI. Has anyone reviewed this from an HTTP perspective?


> Begin forwarded message:
> 
> From: The IESG <iesg-secretary@ietf.org>
> 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" <ietf-announce@ietf.org>
> Cc: ekr@rtfm.com, draft-ietf-tokbind-https@ietf.org, unbearable@ietf.org, tokbind-chairs@ietf.org, ve7jtb@ve7jtb.com, rfc-editor@rfc-editor.org, The IESG <iesg@ietf.org>
> Reply-To: ietf@ietf.org
> 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/