Subject: [Unbearable] TTRPs supporting TB on both upstream and downstream sides?

From: =JeffH <[email-masked]>
Date: Fri, 10 Feb 2017 17:29:11 -0800

Do TLS Terminating Reverse Proxies (TTRPs) have any need to negotiate 
Token Binding (TB) between themselves and backend origin servers (this 
scenario assumes TLS comms between a TTRP and origin servers)?

I.E.:

TB-wielding                 TB-wielding                   TB-wielding
client   <--------------->  TTRP     <--------------->  Origin Server
             [TLS W/TB]                   [TLS W/TB]

..where the client negotiates TB with the TTRP, and the TTRP in turn 
negotiates TB with the Origin server.  This implies that there may be 
security tokens that the TTRP itself uses with the origin server.

Should we be anticipating this scenario as a use case?

Note: this question is orthogonal to whether the TTRP is also forwarding 
the client's Sec-Token-Binding header to the origin server or not.

Thanks,

=JeffH

---

From: Brian Campbell <[email-masked]>
Date: Sat, 11 Feb 2017 06:54:00 -0700

In short, I don't think it's a use case with sufficient validity that we
should complicate things trying to support.

The primary value of Token Binding is preventing replay of exported/stolen
security tokens that are dynamically issued to end user applications
(potentially huge numbers of such applications). Web browsers and binding
of cookies being the canonical example. Things certainly need to be secured
between a TTRP and origin server and TLS may well be used between the two.
But the dynamic nature of Token Binding seems ill-suited for use between
pieces of infrastructure where existing authentication mechanisms, like TLS
client auth for example, would be more appropriate.

On Fri, Feb 10, 2017 at 6:29 PM, =JeffH <[email-masked]>
wrote:

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

---

From: John Bradley <[email-masked]>
Date: Sat, 11 Feb 2017 11:56:50 -0300

In general for the reverse proxy case I agree with Brian.   I suspect it is more likely for the proxy to be at a network boundary and not do tls inside, or to be in the “cloud” and do mutual TLS back to the servers.

John B.

> On Feb 11, 2017, at 10:54 AM, Brian Campbell <[email-masked]> wrote:
> 
> In short, I don't think it's a use case with sufficient validity that we should complicate things trying to support.
> 
> The primary value of Token Binding is preventing replay of exported/stolen security tokens that are dynamically issued to end user applications (potentially huge numbers of such applications). Web browsers and binding of cookies being the canonical example. Things certainly need to be secured between a TTRP and origin server and TLS may well be used between the two. But the dynamic nature of Token Binding seems ill-suited for use between pieces of infrastructure where existing authentication mechanisms, like TLS client auth for example, would be more appropriate. 
> 
> On Fri, Feb 10, 2017 at 6:29 PM, =JeffH <[email-masked] <mailto:[email-masked]>> wrote:
> Do TLS Terminating Reverse Proxies (TTRPs) have any need to negotiate Token Binding (TB) between themselves and backend origin servers (this scenario assumes TLS comms between a TTRP and origin servers)?
> 
> I.E.:
> 
> ..where the client negotiates TB with the TTRP, and the TTRP in turn negotiates TB with the Origin server.  This implies that there may be security tokens that the TTRP itself uses with the origin server.
> 
> Note: this question is orthogonal to whether the TTRP is also forwarding the client's Sec-Token-Binding header to the origin server or not.
> 
> Thanks,
> 
> =JeffH
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
>