Subject: [Unbearable] Fwd: New Version Notification for draft-ietf-tokbind-https-02.txt

From: Dirk Balfanz <[email-masked]>
Date: Fri, 16 Oct 2015 03:15:09 +0000

Dear fellow Unbearables,

I uploaded a new version of draft-ietf-tokbind-https.

Highlights of changes:

- removed the Sec- prefix from the header name again.
- Provided rationalization for why the header should not be settable by a
DOM API, as well as why we have _two_ TokenBinding proofs in federated
scenarios, in the Security Considerations section.

Dirk.

---------- Forwarded message ---------
From: <[email-masked]>
Date: Thu, Oct 15, 2015 at 8:12 PM
Subject: New Version Notification for draft-ietf-tokbind-https-02.txt
To: Adam Langley <[email-masked]>, Dirk Balfanz <[email-masked]>,
Andrei Popov <[email-masked]>, "Magnus Nyström" <
[email-masked]>

A new version of I-D, draft-ietf-tokbind-https-02.txt
has been successfully submitted by Dirk Balfanz and posted to the
IETF repository.

Name:           draft-ietf-tokbind-https
Revision:       02
Title:          Token Binding over HTTP
Document date:  2015-10-15
Group:          tokbind
Pages:          13
URL:
https://www.ietf.org/internet-drafts/draft-ietf-tokbind-https-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/
Htmlized:       https://tools.ietf.org/html/draft-ietf-tokbind-https-02
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-https-02

Abstract:
   This document describes a collection of mechanisms that allow HTTP
   servers to cryptographically bind authentication tokens (such as
   cookies and OAuth tokens) to a TLS [RFC5246] connection.

   We describe both _first-party_ as well as _federated_ scenarios.  In
   a first-party scenario, an HTTP server issues a security token (such
   as a cookie) to a client, and expects the client to send the security
   token back to the server at a later time in order to authenticate.
   Binding the token to the TLS connection between client and server
   protects the security token from theft, and ensures that the security
   token can only be used by the client that it was issued to.

   Federated token bindings, on the other hand, allow servers to
   cryptographically bind security tokens to a TLS [RFC5246] 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 [TBPROTO]

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.

The IETF Secretariat

---

From: Leif Johansson <[email-masked]>
Date: Fri, 16 Oct 2015 13:56:27 +0200

On 2015-10-16 05:15, Dirk Balfanz wrote:
> - Provided rationalization for why the header should not be settable by
> a DOM API, as well as why we have _two_ TokenBinding proofs in federated

Folks,

Can I get some volunteer reviews of this version? I'm hoping can come
into the F2F in Tokyo with a clear view of the light at the end of the
tunnel!

	Cheers Leif