Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field?

From: =JeffH <[email-masked]>
Date: Thu, 9 Feb 2017 07:55:51 -0800

Dirk wrote:
 >
 > [...]
 > - If the proxy has some sort of arrangement with the downstream
 > server that it's supposed to communicate the Token Binding
 > information (like a TTRP would), it has a two options:
 >
 > * verify the Token Binding information and forward just the Token
 > Binding ID to the downstream server (using some mechanism proprietary
 > to the proxy and downstream server).
 >
 > * forward the Sec-Token-Binding header, and (using some mechanism
 > proprietary to the proxy and downstream server) the EKM information,
 > to the downstream server.
 >
 > If the proxy has qualms about violating the spec by forwarding the
 > Sec-Token-Binding header despite its being listed in the Connect
 > header, it can always just use a different header name, like
 > "Private-Forwarded-Token-Binding", or whatever - some  mechanism
 > proprietary to the proxy and downstream server.
 > [...]

Andrei wrote:
 >
 > …but in the case of the Sec-Token-Binding header, the client does not 
know whether it makes
 > sense to forward or not.
 >
 > The client, generally, does not know whether the proxy or TLS
 > terminator validates bindings, passes them along for the application
 > server to validate, or strips them altogether.

johnB wrote:
 >
 > I suspect the only place we really run into a conflict is in Brian's
 > draft by re using/maintaining the Sec-Token-Binding header.
 >
 > As Dirk points out that draft could move the info in the
 > Sec-Token-Binding header to a different header if it is listed in the
 > Connect header, or always just use a different header name.

Yep.

 > That can be debated as part of the reverse proxy spec.

Agreed.  This cleanly separates things.

Dirk also wrote:
 >
 > to me it seems that listing it in the Connect header is the
 > right answer

I agree with this for security considerations reasons -- we want the 
Sec-Token-Binding header to be hop-by-hop in sync with the underlying 
TLS connection and not be "leaked" downstream unless it is a conscious 
decision, e.g., in the tls terminating reverse proxy (TTRP) case.

I will update PR #94 accordingly 
<https://github.com/TokenBinding/Internet-Drafts/pull/94>

there's also another issue with PR #94 that's being discussed in the PR 
that I'll bring here to the list in a subsequent msg.

=JeffH

---

From: Brian Campbell <[email-masked]>
Date: Thu, 9 Feb 2017 10:37:40 -0600

On Thu, Feb 9, 2017 at 9:55 AM, =JeffH <[email-masked]>
wrote:

> Sec-Token-Binding header to be hop-by-hop in sync with the underlying TLS
> connection and not be "leaked" downstream unless it is a conscious
But the client is only making a connection to a server and client does not
know whether it makes sense for that server to forward or not. And it
shouldn't know that.  Sec-Token-Binding shouldn't be listed in Connection
header field by a client.

---

From: Andrei Popov <[email-masked]>
Date: Thu, 9 Feb 2017 18:25:40 +0000

Exactly, I agree with Brian. The proxy/terminator is better positioned to know how/where TB headers are handled in a particular datacenter. And a proxy/terminator that knows nothing about TB headers should forward them on.

From: Unbearable [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Thursday, February 9, 2017 8:38 AM
To: =JeffH <[email-masked]>
Cc: IETF TokBind WG <[email-masked]>
Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field?

On Thu, Feb 9, 2017 at 9:55 AM, =JeffH <[email-masked]<mailto:[email-masked]>> wrote:

I agree with this for security considerations reasons -- we want the Sec-Token-Binding header to be hop-by-hop in sync with the underlying TLS connection and not be "leaked" downstream unless it is a conscious decision, e.g., in the tls terminating reverse proxy (TTRP) case.

But the client is only making a connection to a server and client does not know whether it makes sense for that server to forward or not. And it shouldn't know that.  Sec-Token-Binding shouldn't be listed in Connection header field by a client.

---

From: John Bradley <[email-masked]>
Date: Thu, 9 Feb 2017 15:40:37 -0300

That may be the rub.

From a header perspective we are talking about any proxy forward and reverse.

I dont know that a proxy that doesn’t understand token binding should forward the header especially in the forward case.

What if the forward proxy is negotiating it’s own token binding  to the server?  (should a forward proxy proxy do that is perhaps another question)

I understand the desire to pass the header on in the reverse proxy case as it may make server code easier.

However I take Jeff’s point that token binding is by its nature hop by hop and if we mess with that we may get some unintended side effects.

If Brian had proposed sticking everything in one or two  new headers and removing the existing one then this would be much less controversial.

I always thought that we could use the same header on the inside of the proxy, but can see why that might mess up some other expectations.

So is token binding hop by hop?

John B.

> On Feb 9, 2017, at 3:25 PM, Andrei Popov <[email-masked]> wrote:
> 
> On Thu, Feb 9, 2017 at 9:55 AM, =JeffH <[email-masked] <mailto:[email-masked]>> wrote:
> 
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable

---

From: Andrei Popov <[email-masked]>
Date: Thu, 9 Feb 2017 18:48:54 +0000

Ø  I dont know that a proxy that doesn’t understand token binding should forward the header especially in the forward case.

Ø

Ø  What if the forward proxy is negotiating it’s own token binding  to the server?  (should a forward proxy proxy do that is perhaps another question)

Would you agree that if a proxy is negotiating its own TB to the server, then this proxy is TB-aware, and knows what to do about the client’s TB header?

From: John Bradley [mailto:[email-masked]]
Sent: Thursday, February 9, 2017 10:41 AM
To: Andrei Popov <[email-masked]>
Cc: Brian Campbell <[email-masked]>; =JeffH Hodges <[email-masked]>; IETF TokBind WG <[email-masked]>
Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field?

That may be the rub.

John B.

On Feb 9, 2017, at 3:25 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

From: Unbearable [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Thursday, February 9, 2017 8:38 AM
To: =JeffH <[email-masked]<mailto:[email-masked]>>
Cc: IETF TokBind WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field?

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable

---

From: John Bradley <[email-masked]>
Date: Thu, 9 Feb 2017 15:57:38 -0300

If it is negotiating token binding with the server then it can’t pass along the original token binding in the same header without significant confusion I suspect.

The bigger short term question is what should a proxy that doesn’t understand token binding do.  If token binding is signalled from the user agent as hop by hop then it should drop the header.

I think it is better for the server to get no token binding header than one from a client that thinks it has negotiated token binding but it cant validate.

The Include-Referred-Token-Binding-ID header should be end to end and not removed by proxies.

John B.

> On Feb 9, 2017, at 3:48 PM, Andrei Popov <[email-masked]> wrote:
> 
> On Feb 9, 2017, at 3:25 PM, Andrei Popov <[email-masked] <mailto:[email-masked]>> wrote:
>  
> From: Unbearable [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Brian Campbell
> To: =JeffH <[email-masked] <mailto:[email-masked]>>
> Cc: IETF TokBind WG <[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>

---

From: Andrei Popov <[email-masked]>
Date: Thu, 9 Feb 2017 19:10:10 +0000

Ø  If it is negotiating token binding with the server then it can’t pass along the original token binding in the same header without significant confusion I suspect.
My argument is that a TB-aware proxy understands this and does the right thing, which may be validating the client’s TB and generating a new TB for the back-end server, or something else.

Ø  The bigger short term question is what should a proxy that doesn’t understand token binding do.  If token binding is signalled from the user agent as hop by hop then it should drop the header.
A proxy that does not understand TB, but terminates TLS, does not negotiate TB with the client and does not receive the TB header.

Ø  I think it is better for the server to get no token binding header than one from a client that thinks it has negotiated token binding but it cant validate.
The client only sends the TB header if TB was negotiated. This means the proxy and/or back-end server are configured by the admin to handle TB.
The client does not know whether the proxy or the back-end server handle TB, so can’t make a header forwarding decision for them.