Only one method to Token Bind AT rather than two?

Issue #60 closed
Nat Sakimura created an issue 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
(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 (20)

  1. Sascha Preibisch

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

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

  3. Nat Sakimura 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.

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

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

    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.

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

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

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

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

  10. Nat Sakimura 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:

    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.

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

  12. Nat Sakimura reporter

    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.

  13. Log in to comment