Only one method to Token Bind AT rather than two?
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?
Comments (23)
-
-
I agree - lets just refer to the token binding spec and accept both options.
-
reporter Should just refer to TB spec and MTLS spec allowing options there.
-
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.
-
reporter 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.
-
reporter - changed status to open
-
I would like to hear more about Google's approach. My fear is you have created an architecture that cannot be decomposed for efficiency.
-
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.
-
I am guessing this solution is for clients running in devices.
What purpose, ie what threat is mitigated, by token binding for confidential clients?
-
Securing the access tokens.
-
against what threat?
-
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.
-
So then what you are looking for is just a mac = message authentication code?
..Tom's phone
-
i have always worried about mixing levels. So I think your approach sounds better. ..tom
-
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
-
reporter - marked as critical
-
need to document (or describe where the documentation exists) to rebuild a broken tls session that does not impact operations of a confidential client
-
reporter 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:
- The client creates a key pair (for RSA or EC) per eTLD+1 and saves it.
- The client then creates Token Binding ID (TBID) from the public key.
- The client creates Token Binding Message (TBM) by signing EKM using the private key created in step 1 and combining it with TBID.
- The client sends TBM in Sec-Token-Binding HTTP header to the server with other HTTP payloads.
- 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.
-
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.
-
reporter - changed status to closed
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.
-
reporter - changed component to Part 2: Advanced
-
reporter - changed component to FAPI 1 – Part 2: Advanced
-
reporter - changed component to FAPI 1: Advanced
- Log in to comment
Adoption of FAPI may be hindered due to technical limitations vendors may have. With that I support alternative ways.