Re: [Unbearable] Comments on draft-campbell-tokbind-tls-term

[Brian Campbell <[e-mail]>]

Hi Piotr,

Thanks for the review and comments/questions. Attempted replies are inline
below.

I hope to discuss much of this stuff in more detail tomorrow from 9am-10am
in Lugano during the ad hoc meeting I requested/announced on the list at
https://www.ietf.org/mail-archive/web/unbearable/current/msg01338.html.
Feel free to join the discussion, if you are still in Chicago and available.


On Mon, Mar 27, 2017 at 2:36 PM, Piotr Sikora <[e-mail]>
wrote:

> Hey,
> I'm a bit late to the party, so apologies if this was already discussed.
>
> >   A backend server that receives a request from a trusted reverse proxy
> >   containing the "Token-Binding-Context" and "Sec-Token-Binding"
> >   headers decodes the Token Binding Context Message and uses its
> >   content to validate the encoded Token Binding Message as described in
> >   Section 2 of Token Binding over HTTP [I-D.ietf-tokbind-https] in
> >   place of information that otherwise would have come from the TLS
> >   connection.
>
> What's the value of sending both to the backend server instead of
> validating the Token Binding Message at the reverse proxy and passing
> only Token Binding ID (in one form or another) to the backend server?
>

The intended value of this approach is to keep the reverse proxy as light
as possible. I got the sense that that was a desirable property from what
seemed like a majority of the room during the last meeting in Seoul. If we
stay with the approach, I'll add some explanation of the rational to the
document. But this might not be the 'right' approach or the preferred one.
I'm hoping to get more input and a better sense of the goals and
preferences of people tomorrow.



> Especially, since the Token Binding Message must (should?) be
> validated by the TLS terminating reverse proxy anyway.
>

The server as a logical entity must validate the Token Binding Message. But
that doesn't mean the front end necessarily has to do it. The approach in
this -00 document enables a back end component of the server as a whole to
do the Token Binding Message validation. But the server as a logical entity
is still validating the TB message.


>
> Also, re-using "Sec-Token-Binding" header doesn't allow Token Binding
> to be established between reverse proxy and backend server...
>

That's true. But I think it is okay because establishing Token Binding
between infrastructure components under the same operational control
doesn't really add much value. Token Binding is good for the logical
endpoints of the client and server in a connection.


> Actually, it doesn't allow TLS between reverse proxy and backend
> server, since backend server should reject such connection, if Token
> Binding protocol wasn't negotiated during TLS handshake.
>

Treating the different components of the server as a single logical entity
with respect to Token Binding does allow LS between reverse proxy and
backend
server.


>
> >   The Token Binding Context Message is a byte sequence that contains
> >   the concatenation of the negotiated Token Binding Protocol Version
> >   and Key Parameters as well as the exported keying material (EKM) from
> >   the TLS connection between the client and reverse proxy.  The first
> >   two bytes are the ProtocolVersion, as defined in Section 2 of
> >   [I-D.ietf-tokbind-negotiation], that the reverse proxy negotiated
> >   with the client.  The third byte is the negotiated
> >   TokenBindingKeyParameters (also defined in Section 2 of
> >   [I-D.ietf-tokbind-negotiation]).  The remaining 32 or more bytes are
> >   the EKM from the TLS connection between the client and the reverse
> >   proxy, as defined in Section 3.3 of [I-D.ietf-tokbind-protocol].
>
> Following from the previous comment, why all this information needs to
> be passed to the backend server? Wouldn't base64url-encoded Token
> Binding ID (or SHA256 hash of it) be good enough?
>

Something along those lines is an alternative approach at a solution.



> Best regards,
> Piotr Sikora
>