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

[John Bradley <[e-mail]>]

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.

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

I am not really getting the sense that we need to mention the connect header if we are happy with the default behaviour and can account for it in specs using token binding.

What do people think we should do to close this?

John B.


> On Feb 8, 2017, at 12:52 AM, Dirk Balfanz <[e-mail]> wrote:
> 
> I don't feel strongly about this - I'm fine either way, but would suggest the following:
> 
> - The Connect header is for the client to tell a proxy "this header really doesn't make sense to forward, please drop it on the next hop".
> - Clients usually aren't aware that they're talking to a TTRP, so I agree with John that that's probably not a use case that the Connect header was meant for.
> - If the client *is* aware that it's talking to a proxy, listing Sec-Token-Binding in the Connect header (thus indicating that it shouldn't be forwarded) makes sense to me.
> - 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.
> - Either way, the proxy will have to know what the Sec-Token-Binding header means and use some sort of proprietary mechanism between itself and the downstream server to pass on the information that the downstream server needs.
> - For a proxy that *doesn't* know what the Sec-Token-Binding header means, it's probably best to just drop it, thus saving the downstream server some work verifying a header that we know won't verify.
> 
> So to me it seems that listing it in the Connect header is the right answer, but like I said I don't feel strongly about it.
> 
> Dirk.
> 
> 
> On Tue, Feb 7, 2017 at 2:56 PM John Bradley <[e-mail] <mailto:[e-mail]>> wrote:
> Are connection headers normally used in the reverse proxy use case?   Generally the user agent wouldn't know that it was talking to a proxy.
> 
> I thought that they were more for the forward proxy use case where the browser is configured to talk to a specific proxy or is transparently intercepted (man/enterprise in the middle) 
> 
> I could hypothetically see a enterprise proxy creating token binding Id’s for the connections to servers and mapping those to token binding ID from the browser. 
> 
> I think the NGNX token binding module (https://github.com/google/ngx_token_binding <https://github.com/google/ngx_token_binding>) is doing that sort of transparent mapping on the server side for session cookies. 
> 
> We probably don't want the same behaviour for both forward and reverse proxies.
> 
> John B.
> 
> 
>> On Feb 7, 2017, at 7:38 PM, Andrei Popov <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> When we discussed this early on, there was a strong distaste for connection headers in the HTTP community, so we've defined TB headers as per-request.
>> " clients MUST include the Sec-Token-
>>   Binding header field in their HTTP requests."
>> We could also explicitly prohibit listing TB headers in the Connection header, if folks would like to see this clarification. 
>> There are many reasons to keep TB headers per-request; it's not just about the proxies and terminators.
>> 
>> Cheers,
>> 
>> Andrei
>> 
>> -----Original Message-----
>> From: Unbearable [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of =JeffH
>> Sent: Tuesday, February 7, 2017 2:15 PM
>> To: IETF TokBind WG <[e-mail] <mailto:[e-mail]>>
>> Subject: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field?
>> 
>> the below is kind of long (read it anyway :)  The summary is we need to make a conscious decision regarding the Connection HTTP request header field and whether we provide guidance regarding it and the Sec-Token-Binding header (and what guidance if so), or not. This seems to have ramifications for the nascent draft-campbell-tokbind-tls-term draft, unless I'm misunderstanding things.
>> 
>> =JeffH
>> 
>> In working through the list of "Considerations for New Header Fields" at the end of rfc7231 section 8.3.1 [1], there are these two items..
>> 
>>    o  Whether it is appropriate to list the field-name in the Connection
>>       header field (i.e., if the header field is to be hop-by-hop; see
>>       Section 6.1 of [RFC7230]).
>> 
>>    o  Under what conditions intermediaries are allowed to insert,
>>       delete, or modify the field's value.
>> 
>> Given the specifics in [RFC7230] Section 6.1 [2]..
>> 
>>   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.
>> 
>>    When a header field aside from Connection is used to supply control
>>    information for or about the current connection, the sender MUST list
>>    the corresponding field-name within the Connection header field.  A
>>    proxy or gateway MUST parse a received Connection header field before
>>    a message is forwarded and, for each connection-option in this field,
>>    remove any header field(s) from the message with the same name as the
>>    connection-option, and then remove the Connection header field itself
>>    (or replace it with the intermediary's own connection options for the
>>    forwarded message).
>> 
>>    Hence, the Connection header field provides a declarative way of
>>    distinguishing header fields that are only intended for the immediate
>>    recipient ("hop-by-hop") from those fields that are intended for all
>>    recipients on the chain ("end-to-end"), enabling the message to be
>>    self-descriptive and allowing future connection-specific extensions
>>    to be deployed without fear that they will be blindly forwarded by
>>    older intermediaries.
>> 
>> ..it offhand seems that one would want to list "Sec-Token-Binding" in the Connection header field because Sec-Token-Binding is ostensibly about the connection and is hop-by-hop because TLS is hop-by-hop.
>> 
>> However, given our current thinking wrt TB and TLS Terminating Reverse Proxies [3], where we are contemplating one approach where such "TTRPs" 
>> pass-through the Sec-Token-Binding header field and add a corresponding Token-Binding-Context header, one would not want to list Sec-Token-Binding in the Connection header (because a TTRP would then strip it off). However there are implementation and security considerations with this.
>> 
>> As one proposal, we could say in HTTPSTB something along the lines of..
>> 
>>   [...]
>>   Clients SHOULD NOT list the Sec-Token-Binding header field as
>>   a connection option in the Connection header field (Section 6.1
>>   of [RFC7230]) in order to generally enable Sec-Token-Binding
>>   header field pass-through by intermediaries, e.g., by TLS
>>   terminating reverse proxies (TTRP). Intermediaries MUST NOT
>>   modify the Sec-Token-Binding header field's value. See also the
>>   security considerations section.
>>   [...]
>>   Security Considerations
>>   [...]
>>   Not listing Sec-Token-Binding in the Connection header: this
>>   enables TTRPs to transparently convey the Sec-Token-Binding header
>>   field, containing a Token Binding Message, to the next tier ("backend
>>   servers"), e.g., where security tokens containing Token Binding IDs
>>   may be minted and validated. The communication between a TTRP and
>>   backend servers needs to be secured against eavesdropping and
>>   modification by unintended parties. The Token Binding Message itself
>>   may be validated by the TTRP or by a backend server. Though, in the
>>   latter case, the data necessary to perform such validation (i.e., the
>>   EKM, etc.) needs to be conveyed to the entity performing it. Such
>>   conveyance is out of scope for this specification.
>> 
>>   Listing Sec-Token-Binding in the Connection header: if done, this
>>   may help in ensuring that Token Binding IDs are not inadvertently
>>   revealed to unintended parties, though may cause difficulties with
>>   web sites employing TTRPs.
>>   [...]
>> 
>> Or, we could just say "clients SHOULD list the Sec-Token-Binding header field as a connection option in the Connection header field", but that will create problems for TTRPs [3].
>> 
>> Or, we can just not mention the Connection header and see if anyone raises questions about it during further WG and IETF-wide review.
>> 
>> thoughts?
>> 
>> [1] <https://tools.ietf.org/html/rfc7231#section-8.3.1 <https://tools.ietf.org/html/rfc7231#section-8.3.1>>
>> 
>> [2] <https://tools.ietf.org/html/rfc7230#section-6.1 <https://tools.ietf.org/html/rfc7230#section-6.1>>
>> 
>> [3] <https://tools.ietf.org/html/draft-campbell-tokbind-tls-term <https://tools.ietf.org/html/draft-campbell-tokbind-tls-term>>
>> 
>> 
>> _______________________________________________
>> Unbearable mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
>> 
>> _______________________________________________
>> Unbearable mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
> 
> _______________________________________________
> Unbearable mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>