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

From: =JeffH <[email-masked]>
Date: Tue, 7 Feb 2017 14:15:06 -0800

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>

[2] <https://tools.ietf.org/html/rfc7230#section-6.1>

[3] <https://tools.ietf.org/html/draft-campbell-tokbind-tls-term>

---

From: Andrei Popov <[email-masked]>
Date: Tue, 7 Feb 2017 22:38:54 +0000

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:[email-masked]] On Behalf Of =JeffH
Sent: Tuesday, February 7, 2017 2:15 PM
To: IETF TokBind WG <[email-masked]>
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..

   6.1.  Connection

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

   [...]

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?

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

---

From: John Bradley <[email-masked]>
Date: Tue, 7 Feb 2017 19:38:29 -0300

The other option might be to go back to having the reverse proxy validate the token binding and allow the client to list the Sec-Token-Binding header.

That would be hop by hop semantic.    

We should at-least document why we think that is a bad idea so we have something to point to if the issue comes up.

John B.

> On Feb 7, 2017, at 7:15 PM, =JeffH <[email-masked]> wrote:
> 
> 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.
>

---

From: John Bradley <[email-masked]>
Date: Tue, 7 Feb 2017 19:56:03 -0300

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 <[email-masked]> wrote:
>

---

From: Dirk Balfanz <[email-masked]>
Date: Wed, 08 Feb 2017 03:52:56 +0000

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 <[email-masked]> 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) is doing that sort of
> transparent mapping on the server side for session cookies.
>
> 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.
> We could also explicitly prohibit listing TB headers in the Connection
> header, if folks would like to see this clarification.
> From: Unbearable [mailto:[email-masked]
> <[email-masked]>] On Behalf Of =JeffH
> 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
>
> ..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.
>
> 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.
>
> 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?
>

---

From: John Bradley <[email-masked]>
Date: Wed, 8 Feb 2017 11:44:00 -0300

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>> On Feb 7, 2017, at 7:38 PM, Andrei Popov <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> From: Unbearable [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of =JeffH
>> To: IETF TokBind WG <[email-masked] <mailto:[email-masked]>>
>> [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>>
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
> 
> [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: Wed, 8 Feb 2017 17:20:51 +0000

Ø  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".
…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.

Ø  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.
This sounds reasonable to me.

Cheers,

Andrei

From: John Bradley [mailto:[email-masked]]
Sent: Wednesday, February 8, 2017 6:44 AM
To: Dirk Balfanz <[email-masked]>
Cc: Andrei Popov <[email-masked]>; IETF TokBind WG <[email-masked]>; =JeffH Hodges <[email-masked]>
Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field?

John B.

On Feb 8, 2017, at 12:52 AM, Dirk Balfanz <[email-masked]<mailto:[email-masked]>> wrote:

Dirk.

On Tue, Feb 7, 2017 at 2:56 PM John Bradley <[email-masked]<mailto:[email-masked]>> 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 think the NGNX token binding module (https://github.com/google/ngx_token_binding) is doing that sort of transparent mapping on the server side for session cookies.

John B.

On Feb 7, 2017, at 7:38 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of =JeffH
Sent: Tuesday, February 7, 2017 2:15 PM
To: IETF TokBind WG <[email-masked]<mailto:[email-masked]>>
Subject: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field?

=JeffH

  6.1.  Connection

  [...]

thoughts?

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

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

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

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 10 Feb 2017 08:14:01 +1300

On 9/02/2017 6:20 a.m., Andrei Popov wrote:
> Ø  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". …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.
> 

The Connection header is not particularly about proxies. It is simply
about distinguishing hop-by-hop things from end-to-end so any naive/old
HTTP recipient can keep the relevant data secure in a fail-closed way.

Since the TLS is hop-by-hop the preferred behaviour ought to be a
MUST/SHOULD for listing in Connection header to meet the RFC 7230
conditions.

If the recipient happens to be TB-aware and non-validating (for any
reason, not just TTRPs). Then RFC 7230 grants the ability to forward on
both the Sec-Token-Binding and Connection:Sec-Token-Binding headers as
being relevant to the next-hop it is using.

ie. the "(or replace it with the intermediary's own connection options
for the forwarded message)" clause is what applies to non-validating
recipients.

However the non-validating case should be an exception rather than the
norm. Specifically called out as such for TTRPs etc.

HTH
Amos

---

From: John Bradley <[email-masked]>
Date: Thu, 9 Feb 2017 16:24:42 -0300

So it is valid in hop by hop for the proxy to pass on the original header information as its own for the next hop if that is the correct thing to do?

I suppose that is largely what happens with keep-alive.

To Andre’s point I understand that existing proxies wouldn't negotiate token binding but we need to cover creative future development.  
If we lever it open for a proxy to negotiate token binding on one side and pall along the header someone will do it and blame the spec as being unclear.

We would clearly never recommend that but won’t have direct control over developers.

John B.

> On Feb 9, 2017, at 4:14 PM, Amos Jeffries <[email-masked]> wrote:
>

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 10 Feb 2017 08:48:55 +1300

On 10/02/2017 8:24 a.m., John Bradley wrote:
> So it is valid in hop by hop for the proxy to pass on the original
> header information as its own for the next hop if that is the correct
> thing to do?
> 

Yes.

The other parallel is the various Proxy-Auth* headers from RFC 7235.
Which are defined explicitly as point-to-point (not quite hop-by-hop, so
Connection entry is optional) then section 4.4 explicitly calls out the
exception case:
"
   ... When multiple proxies are used in a chain,
   the Proxy-Authorization header field is consumed by the first inbound
   proxy that was expecting to receive credentials.  A proxy MAY relay
   the credentials from the client request to the next proxy if that is
   the mechanism by which the proxies cooperatively authenticate a given
   request.
"

This is almost exactly the same as the intended behaviour for the
non-validating TTRP use case with Sec-Token-Binding.

Amos

---

From: Andrei Popov <[email-masked]>
Date: Thu, 9 Feb 2017 22:02:36 +0000

Hi Amos,

> The Connection header is not particularly about proxies. It is simply about distinguishing hop-by-hop things from end-to-end so any naive/old HTTP recipient can keep the relevant data secure in a fail-closed way.
...and TB can be handled hop-by-hop or passed on for subsequent validation; both are valid use-cases.

It would be a concern if the backend servers were to assume that any TB header (and the contained TB message) floating around is always valid. Instead what the specs currently say is that if you receive a TB message, you've got to validate it before accepting a bound token. If validation fails, the bound token is rejected. 

It seems therefore that stripping TB headers does not "fail closed", but simply eliminates the possibility that the contained TB message may get verified further down the line.

It is true that a proxy could forward Sec-Token-Binding's contents as a custom header, possibly specified in another document. This is a valid design; I'm just not convinced that this should be the only possible design.

Cheers,

Andrei