Subject: [Unbearable] Fwd: New Version Notification for draft-campbell-tokbind-tls-term-00.txt

From: Brian Campbell <[email-masked]>
Date: Wed, 11 Jan 2017 14:00:54 -0700

Hi Unbearable Folks,

I've uploaded the below individual draft, which is an initial attempt at
describing how Token Binding would work with HTTP applications behind TLS
terminating reverse proxies. This is the document that at end of the
meeting in Seoul I said I was going to work on. But despite it taking me a
long time to write, it isn't very long so should be an easy and quick read.
Feedback is of course welcome.

Thanks,
Brian

---------- Forwarded message ----------
From: <[email-masked]>
Date: Wed, Jan 11, 2017 at 1:26 PM
Subject: New Version Notification for draft-campbell-tokbind-tls-term-00.txt

A new version of I-D, draft-campbell-tokbind-tls-term-00.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:           draft-campbell-tokbind-tls-term
Revision:       00
Title:          HTTPS Token Binding and TLS Terminating Reverse Proxies
Document date:  2017-01-11
Group:          Individual Submission
Pages:          7
URL:            https://www.ietf.org/internet-drafts/draft-campbell-tokbind-
tls-term-00.txt
Status:         https://datatracker.ietf.org/doc/draft-campbell-tokbind-tls
-term/
Htmlized:       https://tools.ietf.org/html/draft-campbell-tokbind-tls-term
-00

Abstract:
   This document defines an HTTP header field that enables a TLS
   terminating reverse proxy to convey the information a backend server
   needs in order for it to process and validate a Token Binding Message
   sent by the client.

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: John Bradley <[email-masked]>
Date: Wed, 11 Jan 2017 19:19:50 -0300

Thanks Brian,

Perhaps you can explain why you chose to pass along the EKM and additional parameters to the server and have it validate the token binding vs having the reverse proxy validate it and pass along the validated token binding ID.

I would like to capture that to the list as it will be asked.

After some discussion we can decide if the WG wants to adopt this draft as a WG document.

John B.

> On Jan 11, 2017, at 6:00 PM, Brian Campbell <[email-masked]> wrote:
> 
> Hi Unbearable Folks,
> 
> I've uploaded the below individual draft, which is an initial attempt at describing how Token Binding would work with HTTP applications behind TLS terminating reverse proxies. This is the document that at end of the meeting in Seoul I said I was going to work on. But despite it taking me a long time to write, it isn't very long so should be an easy and quick read. Feedback is of course welcome. 
> 
> Thanks,
> Brian
> 
> 
> 
> From: <[email-masked] <mailto:[email-masked]>>
> URL:            https://www.ietf.org/internet-drafts/draft-campbell-tokbind-tls-term-00.txt <https://www.ietf.org/internet-drafts/draft-campbell-tokbind-tls-term-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-campbell-tokbind-tls-term/ <https://datatracker.ietf.org/doc/draft-campbell-tokbind-tls-term/>
> Htmlized:       https://tools.ietf.org/html/draft-campbell-tokbind-tls-term-00 <https://tools.ietf.org/html/draft-campbell-tokbind-tls-term-00>
> 
> 
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> 
> 
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable

---

From: Brian Campbell <[email-masked]>
Date: Wed, 11 Jan 2017 16:39:19 -0700

I wavered back and forth on it, to be honest. The change in
TBPROTO-11/HTTPSTB-07 to application specific handling of rejected Token
Bindings rather than terminating the connection tilted me in this
direction. My sense of the room in Seoul was also that there was some
preference for this approach (some said so explicitly but my general
feeling about the room seemed to be such). It lets the TLS terminator be as
dumb as possible with respect to token binding, which I suspect will be
desirable in many cases. It feels (to me anyway) like the more logical
separation of duties where the TLS terminator/reverse proxy does the
negotiation and connection and then provides just enough info from the TLS
layer to the upstream application that will do the message/token processing
and validation. That's some of my thinking on it anyway.

On Wed, Jan 11, 2017 at 3:19 PM, John Bradley <[email-masked]> wrote:

> Thanks Brian,
>
> Perhaps you can explain why you chose to pass along the EKM and additional
> parameters to the server and have it validate the token binding vs having
> the reverse proxy validate it and pass along the validated token binding ID.
>
> URL:            https://www.ietf.org/internet-
> drafts/draft-campbell-tokbind-tls-term-00.txt
> Status:         https://datatracker.ietf.org/
> doc/draft-campbell-tokbind-tls-term/
> Htmlized:       https://tools.ietf.org/html/d
> raft-campbell-tokbind-tls-term-00
>
>
> Abstract:

---

From: John Bradley <[email-masked]>
Date: Wed, 11 Jan 2017 20:50:17 -0300

The application specific handling of rejected token bindings is probably simplest if handled at the server. 

The other option would be to add error codes about why it failed.

This proposal would let the application layer do all of the token binding processing without modifying TLS on the server.

The other consumers of something like this would be a cloud Access Security Broker, that is auditing (Snooping) on connections.  
That might have TLS on both sides as it could be in the cloud.   I don’t think there would be any issue with re-wrappoing this in another mutual TLS connection.

John B.

> On Jan 11, 2017, at 8:39 PM, Brian Campbell <[email-masked]> wrote:
> 
> I wavered back and forth on it, to be honest. The change in TBPROTO-11/HTTPSTB-07 to application specific handling of rejected Token Bindings rather than terminating the connection tilted me in this direction. My sense of the room in Seoul was also that there was some preference for this approach (some said so explicitly but my general feeling about the room seemed to be such). It lets the TLS terminator be as dumb as possible with respect to token binding, which I suspect will be desirable in many cases. It feels (to me anyway) like the more logical separation of duties where the TLS terminator/reverse proxy does the negotiation and connection and then provides just enough info from the TLS layer to the upstream application that will do the message/token processing and validation. That's some of my thinking on it anyway. 
> 
> On Wed, Jan 11, 2017 at 3:19 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> Thanks Brian,
> 
>> On Jan 11, 2017, at 6:00 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Unbearable Folks,
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
> 
>