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

[=JeffH <[e-mail]>]

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