Kerberos is a passwordless computer network security authentication protocol that was created by MIT to help solve network security problems. Used for single-sign on (SSO) by many organizations today, it securely transmits user identity data to applications and has two important functions: authentication and security.
Instead of using traditional passwords, Kerberos employs strong, time-limited secret-key cryptography, multiple secret keys, and a third-party service to authenticate client-server applications and user identities. In creating Kerberos, MIT developers wanted to support both authentication and authorization so that once a user is authenticated, they’re also authorized.
Kerberos is a complex process on the backend but offers the user an almost frictionless experience on the front end. This article will discuss what Kerberos looks like to the user, describe why it’s important, and take a very high-level look at how it works.
What It Looks Like to the User
Today’s distributed workforce uses multiple devices (laptops, smartphones, tablets) and requires anytime-and-anywhere access to their organization’s systems and third-party apps. Since each resource requires users to verify their identity, it could be very time-consuming if employees had to sign into each one. When Kerberos is used, employees are automatically authenticated to access all network resources and many third-party systems with SSO. This means that once they can sign onto a device, they can access multiple resources from the same device without authenticating again (unless their location or some other factor has changed).
Josh sits down at his desk exactly at 9 a.m. He’s concerned about being late for his 9 a.m. Zoom call, so he quickly logs onto his computer.
Because his company uses Kerberos, he doesn’t have to sign into Zoom. He can just click on the Zoom link, and he is automatically authenticated and can enter the meeting.
During the meeting, Josh needs to access his project management software to present some information. He clicks on the application, and it opens instantly without making the other meeting guests wait while he signs in.
After the meeting, he has to access sensitive information in a secure database. When he clicks on the link to enter, he is immediately authenticated through Kerberos and does not have to enter separate credentials.
Josh’s experience with Kerberos is similar to flipping a light switch: He knows it turns the light on, but he doesn’t need to know how it works to reap the benefits of the light. With Kerberos, Josh doesn't need to know what’s going on behind the scenes; he just needs to know that his identity is securely shared across different systems on his network. He appreciates the time he saves by not having to sign in to each application.
Why Is It Important?
As stated above, MIT created Kerberos to solve the business problem of providing safe and secure 24/7 access to company resources from any approved device. Kerberos is secure because passwords are never shared across the network. Instead, encrypted private keys are used. Behind the scenes, all devices and systems automatically authenticate each other upon request by exchanging multiple encrypted private keys with the Kerberos protocol. During the process, encryption keys are never exchanged between the client and the service, which makes it a highly secure process. Future queries are handled quickly because Kerberos simply replays the previous login process, as the token is kept in the browser’s cache or device’s memory.
How Does It Work?
The time-limited token used in Kerberos is like a movie ticket. When a person buys a movie ticket, they buy it for a particular movie, at a particular time, on a particular day. The same is true for an authentication token: It can only be used for a certain resource, for a certain period of time, on a certain day. When the original token expires, a refresh token is sent in its place to maintain SSO.
The Three Main Parts of Kerberos
Key distribution center (KDC)
Authentication server (AS)
Ticket-granting server (TGS)
How Entities Communicate Within Kerberos
In the illustration below, communication flows between the following entities: user/client and AS (green arrows); user/client and TGS (yellow arrows); and user/client and application/server (orange arrows). Some messages are sent in plain text, some are encrypted with a symmetric key, and some contain both.
Client/User and Authentication Server (AS)
Query: An access request is sent from the user via a secret key to the authentication server (AS) in the key distribution center (KDC).
Response: The AS uses the secret key to authenticate the user (by comparing their credentials in the database). Once authenticated, the AS sends its own secret key along with a time-limited token back to the user. The user accepts the key and the time-limited token from the AS.
Client/User and Ticket-granting Service (TGS)
Query: The user takes the key and time-limited token received from the AS and sends them to the TGS along with a request to access the application.
Response: When the TGS gets the request, it decrypts it with the secret key that was shared with the AS and issues the client a token, which is encrypted with another secret key.
Client/User and Application/Server
Query: The client takes the token they got from the TGS and sends it with a secret key to the application they want to access. (Note: Once the client possesses the token from the TGS, the other services can be assured that the client is authenticated.
Response: When the application receives the request, it encrypts the token with a secret key and shares it back to the client and the TGS.
Access Granted to User: The application allows the user access for a certain period of time according to the limitations of the token.