Only one method to Token Bind AT rather than two?

[Nat Sakimura]

https://tools.ietf.org/html/draft-ietf-oauth-token-binding-01 supports two ways to token bind the access token. The standard way, and the alternative way:

the client to generate a Token Binding key to use for the protected
resource, use the Token Binding ID for that key, and then later use
that key when the TLS connection to the protected resource is
established. 
(Source) Last Para of Section 3 of draft-ietf-oauth-token-binding-01

The question here is that should we support this alternative way or do we just requrie the standard way?

[Sascha Preibisch]

Adoption of FAPI may be hindered due to technical limitations vendors may have. With that I support alternative ways.

[Dave Tonge]

I agree - lets just refer to the token binding spec and accept both options.

[Nat Sakimura]

Should just refer to TB spec and MTLS spec allowing options there.

[Tom Jones]

Has any one any experience with token binding in a production environment? It is my understanding that several large sites have off-loaded the TLS connection to machines that only perform TLS. In that case the TLS information is not available to any end-point.

I think that token binding is not practical in large installations and needs to be removed.

[Nat Sakimura]

I believe many of Google's cookies are actually token bound. Otherwise, I have not heard too much experience on it. It is for the future. Maybe John B. as the chair of TB WG can chime in.

What is expected in reality is that those TLS terminating boxes to put the TBIDs in the forwarding http headers in one way or another. The same kind of things happens in the Client TLS authentication, too, which btw is widely supported of course.

In IETF, I have proposed a purely JWS based one which does not require any intermediation by the middlebox and achieve end-to-end security. However, it has not yet been taken up, although, in the last meeting, I had a support from Tony that he has a use case for it.

[Tom Jones]

I would like to hear more about Google's approach. My fear is you have created an architecture that cannot be decomposed for efficiency.

[John Bradley]

Token binding is as easily decoupled from the app as mutual TLS.

The working group is working on a standard for communicating between the reverse proxy and the app, this is something that is not standardised for mutual TLS and each vender has a different format.

Google has added token binding to there front end TLS terminators. NginX has added a module for token binding https://github.com/google/ngx_token_binding

Facebook and Microsoft are in the process of adding it.

For server to server mtls is OK but for mobile and browsers token binding is required to scale.

John B.

[Tom Jones]

I am guessing this solution is for clients running in devices.

What purpose, ie what threat is mitigated, by token binding for confidential clients?

[John Bradley]

Securing the access tokens.

[Tom Jones]

against what threat?

[John Bradley]

Token interception and replay by the RS.

There are attacks where a client can be tricked into giving a access token to the wrong RS.

[Tom Jones]

So then what you are looking for is just a mac = message authentication code?

..Tom's phone

[Tom Jones]

i have always worried about mixing levels. So I think your approach sounds better. ..tom

[Tom Jones]

I should have added. Client (Mutual) TLS may be supported by browsers, etc. But AFAIK it is not used in general commerce because getting a cert for a user is so cumbersome. ..tom

[Tom Jones]

need to document (or describe where the documentation exists) to rebuild a broken tls session that does not impact operations of a confidential client

[Nat Sakimura]

The introduction of The Token Binding Protocol Version 1.0 draft 13 states:

Token Bindings are long-lived, i.e., they encompass multiple TLS connections and TLS sessions between a given client and server.

What happens for TB is:

1. The client creates a key pair (for RSA or EC) per eTLD+1 and saves it.
2. The client then creates Token Binding ID (TBID) from the public key.
3. The client creates Token Binding Message (TBM) by signing EKM using the private key created in step 1 and combining it with TBID.
4. The client sends TBM in Sec-Token-Binding HTTP header to the server with other HTTP payloads.
5. The server validates the TBM in the Sec-Token-Binding header by using EKM that it got from the TLS.

An article by Lepidum documents this well but it is in Japanese.

[Tom Jones]

Right - my question above is confusing. I do not question the value of token binding for a public client. My concern has always been the private client. Is this discussion limited to the removal of the phrase "then later use that key when the TLS connection to the protected resource is established"? That I support.

[Nat Sakimura]

So, as the discussion above, the "later" mode should be allowed and thus we keep the text as is. I am closing the ticket as the reporter.