This article originally appeared on my blog
Kerberos is an authentication protocol that can be used for single sign-on (SSO). The idea behind SSO is simple, we want to login just once and be able to use any service that we are entitled to, without having to login on each of those services.
The Wikipedia page is pretty good, but even after reading the Explain like I’m 5: Kerberos, I ended up having to draw myself some diagrams.
The puzzle
So imagine the objective is for a user to talk to an FTP service and for the FTP service to be sure that the user is who they claim to be, given that there are wrongdoers who will try to to intercept any message sent between actors and attempt to make use of it.
To solve this puzzle, imagine the actors are allowed to make use of coloured keys and chests, as many as are needed, subject to the following rules:
- Chests can only be opened by a key of the same colour.
- Keys can be used to create chests of the same colour.
- Anyone can create a new colour key, as long as the colour doesn't exist already.
How would you do it?
The setup
Here are the actors and the initial game setup:
The Dark user, who has a black key.
The FTP service, who has a blue key.
The TGS has a green key, plus he knows that the FTP server has a blue key and has a copy of it.
Other services would have keys of other colours.
The AS, who knows and has a copy of TGS's green key the user's black key. Other users would have keys of other colours.
The play
Lets explain the initial interactions to make it more clear.
- The user starts by sending his name in plain sight to the AS.
- The AS forges a new red key.
- The AS sends a black chest (created with AS's copy of the black key). It contains a copy of red key.
- The AS also sends a green chest with another copy of the red key plus the name of the user.
The user cannot open the green chest as he just has the black key, but he can open the black one, from which he obtains the red key. From now on he can create red chests.
And so on... You hopefully get the gist of it.
Eavesdropping wrongdoers
With the diagram is easy to check some scenarios when some of the actors are impersonated or the messages are captured or modified.
For example, lets see what happens when an evil guy tries to impersonate the user:
As the evil guy doesn't have the black key, he cannot obtain the red key, so the best he can do is to forge a new key, purple in this case, and use it to create a purple chest.
Note that even if the green chest is a good and valid one, and the TGS is able to open the green chest as before, the TGS is not able to open the purple chest as he just has the red key.
Of course the evil guy cannot just send the name of the user in plain as the TGS expects a chest (ClassCastException!).
I would recommend trying other scenarios, like impersonating the TGS or the evil guy capturing some chests. It is fun!
But what does this have to do with Kerberos?
Unsurprisingly, the diagram above represents how the Kerberos protocol works.
In Kerberos parlance, AS is the Authentication Service and TGS is the Ticket Granting Service. In practice, both services are usually the same server.
Chests are either tickets or authenticators. See the legend at the end of the post for the translation.
The first interesting thing in the protocol is that the user password (the black key) is never sent over the wire, which avoids a whole bunch of possible security issues.
One security issue found is that anybody can obtain the black chest and do an offline brute force or dictionary attack, so Kerberos 5 comes with optional pre-authentication and it can use asymmetric keys for it, so the initial message from the user is slightly different from the one shown in the diagram.
It is also interesting to note that the FTP server never talks with the AS or TGS services to verify the identity of the user, which should have the benefit of a more scalable system.
Not shown in the diagram, but all chests are timestamped and such timestamp is checked by the servers. This helps to avoid replay attacks and with session invalidation.
The last empty yellow chest is used by the user to validate that is talking with the correct server and it actually contains a timestamp.
The first two rules of the puzzle comes from the fact that Kerberos uses symmetric key cryptography.
I hope this has helped you to understand Kerberos. Drop me an email/tweet if something is not clear (or wrong!).
Legend
In Kerberos parlance (and you have the diagram below for easier referral):
- AS: Authentication Server.
- TGS: Ticket Granting Service.
- FTP: The service the user wants to access.
- Black key: user hashed password.
- Green key: TGS Secret Key.
- Red key: Client/TGS Session Key.
- Green chest: Ticket-Granting-Ticket.
- Yellow key: Client/Server Session Key.
- Blue chest: Client-to-server ticket.
- Create a chest: Encrypt a message.
- Open a chest: Decrypt a message.
Top comments (3)
See also: web.mit.edu/kerberos/dialogue.html
I like this post but was lost when the acronyms TGS and AS appeared in the first drawing without being introduced. On a phone I can't see that there's a legend at the bottom so I had to scroll and was lucky to find the legend (thanks). May I suggest linking to named anchors for the first few uses so that we can focus on the fine diagram?
Or you could move the "parlance" paragraph above the first diagram? Or you could avoid TGS and AS by using some generic "first validating server" hand wave and specifying it later?
My take away is that each point returns a "verified identity chest" and a "forwardable or endorsed identity" and that's an ELIFifteen moment! :)
Regardless I got a much better grasp from this article. Thanks!
Hi Steven,
It only took me 8 months but I finally got around fixing this. I did not want to move the legend as I think it will break the narrative with unnecessary detail at that point. Maybe I am right, maybe I am wrong, but yesterday it dawned to me that I can just copy the diagram below the legend, so that when you want to look at the detail, you dont need to be scrolling around.
Huge thanks for the suggestion and let me know if there is anything else that can be improved.
Cheers,
Dan