This is my first blog about what I have been doing for past months.I know most of you are not familiar with this word combination and this is related to security (stuffs 😜).TB(Token Binding) is a new concept to this field and still it’s official documents are in draft version(which means implementations are not finalized).So through this article, we will see the basic idea behind this concept.Let’s get into the business…
INTRODUCTION TO TB
The idea of Token Binding is to prevent such attacks by cryptographically binding application security tokens to the underlying TLS [RFC5246] layer.
These are the exact words in token binding spec to define Token binding.So what does it mean or why we need to do this?
Normally security tokens/cookies are bearer tokens/types which means anyone who intercepts them can use it.If the channel is compromised while transferring security tokens then the attacker can exploit the token for his will.(Mostly in this article we will consider about security tokens rather than cookies)
WHY TOKEN BINDING?
Now some of you may suggest that using TLS (Transport layer security) we can avoid this.
Let’s have a glance at TLS?
TLS layer sits on top of the Transport layer and it is a way of encrypting the channel between two entities.Normally after TCP handshake TLS handshake will be done.Example In the HTTP world making HTTP into HTTPS is what mean by TLS.
TLS may seem secure but there are varies vulnerabilities in the TLS like heart bleed, logjam, poodle, freak.Second thing, TLS is a point to point transaction not end to end ( I know for some it seems I am introducing an another jargon)
Basically, we just send the data through TLS and the TLS channel will do the encryption ie from one point to another point data is encrypted.In simple situation like fig1, there is no problem
But when another entity comes like fig 2
In this scenario, A to B is not secure since there is a middle party who can get the data. So what we do in end to end is encrypt the data and send it over a channel then decrypt in the other end.Now A can send any message and can be sure that only B can understand in this is called end-to-end
So what we are going to is a combination of both ie encrypt the data and send it over TLS and decrypt in the other end ( 😜 this not the actual idea but close to this).But to protect privacy, Token Binding IDs are never conveyed over insecure connections and can be reset by the user at any time, e.g., when clearing browser cookies
One can say TB is an extension of TLS( this is true guys) and TB will span over many TLS connections ie live longer than a TLS connection.If TLS connection cannot be made then we cannot make TB between those two parties.
In simple words, we can say “TB add more security TLS connection”.It makes the security token unusable outside the TLS connection ie it solve the bearer token problem while interception.
HOW TB CAN BE DONE
We can comprise TB in following stages
- TB negotiation: where TB parameters are negotiated between two parties.Normally this happens as an extension to TLS handshake.Even if this fails normal TLS connection will happen.If the parameters negotiated in this phase have not adhered then TB will fail.
- key generation: The user will generate asymmetric key pair and send the public key as TB id to the next party along with signed EKM (by private key)from the TLS handshake.
- proof of possession: receiver(token issuer) will check the EKM with the TB id (public key). If the verification success then TB will proceed otherwise the connection will fail.
- Binding: After validation of the user, the token issuer will use the TB id to bind the security token.(what is mean by binding here is, putting an instance of TB id(maybe hash value) into the token or saving it in the database).After binding it will issue the token to the user.
fig 3 is the basic flow of How token request will be passed through two entities and token binding can be happened.whenever a TLS connection is made between two parties, a unique TB connection(ie if many clients try to access the server each client will establish a TLS connection with distinct TB id) will be established.After negation is happened client will generate a key pair and send the public key as token binding id.Token issuer will bind the security token to the token binding id.Later if the client try to use the token it can be validated by the binding.Here token id will be sent through the TB message.
Even if someone captures the bound token when he tries to use that within his connection(which will have a different token binding id ), the respected party will validate the bound token against the channel token binding id and reject it.
There are two types of token binding
- Provided token binding:
Used when the token exchange happens directly between 2 parties.
Here the token binding happens between A(Client) and B(Token Provider).Later B use that token binding id to bind the tokens and send them to A, on its request.When A tries to use the token it must send it through the connection with the TB ID that used to bind the token.So B can always make sure that token is coming from A(to whom it issued the token).
2. Referred token binding:
Used when requested tokens are intended to be presented to a different party.
Unlike above scenario here, there is a third party C(Token Consumer).Here A(Client) & C create a token binding connection and A uses that connection ID to make a token request to B(Token Provider).B uses the TB ID between A & C to bind the security token.(Of course, there will be TB connection between C & B but here TB connection between A &C is important).
Whenever A tries to use the token, C can make sure that A is the one who requested the token from B(ie A is the owner of the token).In order to do this, C may have to contact B(like introspection).Since connection id between A & C is used C can easily validate token upon receiving some binding parameters from B.
So depends on the situation you have to choose between provided token and referred token.Always better to bind the token with the ID between the target(resource) server and the client.Then only the respected (target) server can validate the token.As example to these in oauth2.0 for refresh token grant type you can use provided token binding and for authorization grant type you may use referred token binding.
Let’s assume you are clear up to this point(😉), definitely you will be confused from the word “binding parameters”.So let’s see what is really mean by binding in token binding.As I already said binding refers to the idea of putting the instance of the token binding ID inside the token/cookie which you are going to issue.
In order to do that you can follow two ways(basically )
- Stateful way: Here the token issuer should maintain a database to save the token binding ids respective to the tokens.Whenever a token is used issuer can lookup his table and find the token binding id to which he has issued the token.
- Stateless way: Here token issuer will create the token by having entire the token binding id or the hash value of the id inside it.Whenever the token is used the issuer can extract the token binding id from token and validate it. Here the over head of using database is gone but if the token issued used frequently he always has to perform the extraction.
Both the binding methods have there own pros and cons.So choose them wisely.
The next thing we should Know about is token binding message.Usually, this message is used to prove that client owns this much of token binding channels/IDs.(ie prove the possession of private keys of those channels).This message should be sent after client and server negotiated the token binding.For each different implementation of token binding, you can have specif ways of representing the token binding message. Eg token binding over HTTP has its own specification.
Normally the Token Binding message consists of a series of Token Binding structures, each containing the type of the token binding(ie provided or referred ), the Token Binding ID, a signature using the Token Binding key, optionally followed by Extension structures.
WHERE TB CAN BE USED
“The goal of the Token Binding protocol is to prevent attackers from exporting and replaying security tokens, thereby impersonating legitimate users and gaining access to protected resources”
This is how they define the token binding goal in the spec.So token binding adds an extra layer of security to bearer tokens and cookies and we can use token binding wherever we have this issue.Now, let’s take some real scenarios and see how token binding can fit into it.
Token binding can be used in the OAuth2.0 protocol.Since most of the tokens used here are bearer tokens it increases vulnerability in the protocol.Even if TLS layer is used still it has the same issue.So using token binding will secure the whole flow and avoid any token misuses.There is specification regarding how this can be done for OAuth2.0.Basically, this happens between trusted parties.
In Open id connect also we can use token binding. Same as OAuth2.0, openid connect deals with bearer tokens and can use token binding to avoid the security issue.The specification for Token binding for open id connect describes how that can be done.
If a company wants to man-in-the-middles all their employees, it is possible to use token binding. Normally the man-in-the-middle attacks occurring in the first visit can’t be detectable.So this feature can be used in the companies. However, if an employee takes their laptop home to a network without a man-in-the-middle attacker, the identifier will change and the user will be logged out. Token binding doesn’t work well with intermittent man-in-the-middle attacks.
Using token binding it is possible to track down the user.(which sometimes needs to be controlled.)So token binding can be used in DRM(Digital Rights Management).Somehow it not desirable since it has some issues in generating and copying keys for use.So it cannot be used that much in this context.
These are just some different ideas or context where you can use token binding but you can use token binding where ever you need protection for bearer security tokens.
In order to token binding is to work, the whole network should support token binding otherwise it can be easily compromised at that point.In token binding for oauth2.0, token binding won’t happen if any participating entity cannot support token binding.
Whenever the negotiated parameters are not adhered the token binding will fail. Even if the client and server can support token binding but cannot decide on a specific token binding protocol version token binding will fail.If the network cannot support token binding in the negotiation phase it is not a problem still the network can run in the normal TLS connections but after token binding negotiation they failed, it will lead in connection or grant type failures. (serious failures)
In some cases, token binding can be used to track the user(client) details as the user is specifically addressed(ie user can be easily differentiated ).It can arouse privacy issues in the future.So it is better to define the scope of token binding before getting it to the operational level. Especially validity time should be engineered correctly.
Another thing is, as I already mentioned this spec is still under construction, so there is no clear east or west. Implementing it can be little difficult or can change in the future.So far token binding is only been implemented in browsers like chrome and edge.Server wise Apache httpd server and Nginx can support token binding.If you want, you can join communities dedicated to token binding and get support from them.To my knowledge, there is mailing thread as unbearable in IETF.If you want there is a test case in Apache httpd token binding module in which you can test for token binding over HTTP.
TB is a bleeding edge in the security field and in few years of time, it will dominate the field.If you are really in this field, it is better to give a glance in this matter and see how you can adapt your system to a more secure network.Most of the things I explained are based on my understanding of token binding and actual meaning can be little different.So it always better to read about them through specs and other official materials.
This is just a rough idea about token binding and explanation of some terms in token binding specification.Based on the context you are going to work (OIDC or Oauth)token binding implementation can vary but the basic concepts will be same for everything.
Since most of the specs are in draft version always follow the latest issue.
- The Token Binding Protocol Version 1.0
- Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation
- Token Binding over HTTP
- OAuth 2.0 Token Binding specification
- HTTPS Token Binding with TLS Terminating Reverse Proxies
- Oauth2.0 Token Binding by prabath siriwardena’s Blog:
- Prevent session hijacking with token binding by Sjoerd Langkemper