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

[John Bradley <[e-mail]>]

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 <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> 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.
> 
> 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 <[e-mail] <mailto:[e-mail]>> 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
>> 
>> 
>> 
>> ---------- Forwarded message ----------
>> From: <[e-mail] <mailto:[e-mail]>>
>> 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 <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:
>>    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 <http://tools.ietf.org/>.
>> 
>> The IETF Secretariat
>> 
>> 
>> 
>> _______________________________________________
>> Unbearable mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
> 
>