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

Hi Jeff,

If you agree that the client, generally, does not know whether the proxy/TLS terminator validates TB or passes it on to the back-end server, then why do you argue that the client should require the proxy to drop TB headers? I believe the client should not interfere with this and let datacenter infrastructure figure out how/where to handle TB headers.

> ..which is what we want by default for security considerations reasons, I think.
Sorry, what security considerations reasons are you referring to?

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of =JeffH
Sent: Thursday, February 9, 2017 9:05 AM
To: IETF TokBind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field?

 >> 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.

correct, agreed.

 > Sec-Token-Binding shouldn't be listed in Connection header field by  > a client.

listing Sec-Token-Binding in the Connection header means ([RFC7230] Section 6.1)..

    6.1.  Connection

     The "Connection" header field allows the sender to indicate desired
     control options for the current connection.  In order to avoid
     confusing downstream recipients, a proxy or gateway MUST remove or
     replace any received connection options before forwarding the
     message.

..which is what we want by default for security considerations reasons, I think.

As Dirk noted:
  >
  > 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.

Thus, a comment on
<https://tools.ietf.org/html/draft-campbell-tokbind-tls-term> (which i'll endeavor to write up more fully anon) is that it should either define another header field for conveyance of the EncodedTokenBindingMessage (along with the header field it already
defines) or have the header field it already defines convey both the EncodedTokenBindingMessage and the EKM et al.

=JeffH

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable