Kerberos overview: Introducing network authentication

The Kerberos security protocol has become a staple of modern cyber security. It's so well integrated, in fact, that most users or even developers forget it's there at all. This behind-the-scenes status can make information about what Kerberos is and how it works difficult to come by, especially with all the different forms this protocol takes today.

In this article, we'll answer what Kerberos is, how it works, and explore common attacks Kerberos security engineers must overcome day-to-day.

By the end, you'll have a newfound appreciation for modern network security and, hopefully, a peaked interest in cyber security!

Here’s what we’ll learn today:

• What is Kerberos?
• Core components of Kerberos
• How does Kerberos work?
• Kerberos process breakdown
• Is Kerberos hackable?
• What to learn next

What is Kerberos?

Kerberos is a computer-network authentication protocol designed to simplify and secure authentication.

The central idea of Kerberos revolves around using a local form of personal identification called tickets that are granted by the authentication server. Each ticket belongs to certain realms that determine what services the ticket grants access to. These tickets are encrypted and require multiple levels of decryption to use. This ticket system ensures that sensitive information like passwords is never sent over the network.

Kerberos has become well-established since its creation at MIT in the 1980s. Now, it is built into countless security-dependent implementations across the web, with nearly all companies interacting daily with at least one Kerberos system.

The most well-known use of Kerberos is for Microsoft's Active Directory, a default directory service included in Windows 2000 and onward to control domains and authenticate users.

Other prominent uses are by Apple, NASA, Google, the US Department of Defense, and universities across the United States.

Benefits of Kerberos

Kerberos is so widely used because of its ease and unmatched data security. Here are just a few of its benefits:

• Secure: Kerberos never transmits passwords over the network. Instead, Kerberos proves user identity by sending time-bound cryptographic messages that become invalid after a set period. Even if the messages were intercepted and decrypted, they'd be useless in a matter of minutes!

• Single-Sign-On: Kerberos only requires the user to type their password once when first authenticating the client. From then on, the user has access across all kerberized services within a Kerberos realm without needing to re-enter their password. Single Sign-on simplifies working with multiple services by removing the hassle of multiple login requirements.

Trusted third-party: Kerberos uses a centralized authentication server known as the Key Distribution Center (KDC) that all other devices in the network trust by default. All authentication requests, such as cryptographic messages, are routed through this server. This outsourcing ensures that sensitive information is not stored on a local machine.

• Mutual authentication: In Kerberos, both ends of communication must be authenticated before the communication is permitted. Mutual authentication drastically reduces the ability of fraudulent actors to trick systems into sending confidential information.

An example of mutual authentication:

A user in a network using Kerberos can authenticate to a mail server to prove they are who they claim to be. On the other end, the mail server must also authenticate that it is truly the mail server and not some other service in the network pretending to be the mail server. If both sides are authenticated, the connection is established.

Core components of Kerberos

Key Distribution Center

The Key Distribution Center (KDC) is the central process of Kerberos, containing the Authentication Server (AS) and the Ticket Granting Service (TGS). Its main function is to be a mediator between these two, relaying messages from the AS, granting a ticket-granting ticket (TGT), then passing that to be encrypted by the TGS. After this pass-off, the KDC has little influence in the authentication process.

Ticket-Granting Ticket

This ticket is granted by the KDC after the client is successfully authenticated. The TGT is encrypted and contains permissions on what services the client can access, how long access is granted, and also a session key used to communicate with the client.

Clients cannot decrypt the TGT, as they do not have the TGS key. They must, therefore, blindly present the TGT to desired services (which can access the TGS) and allow the services to decide if the client can access it.

By hiding the TGT from the client, Kerberos prevents permissions from being copied or altered fraudulently by the client.

Authentication Server

The Authentication Server is the first stop in getting authenticated with Kerberos. The client first must authenticate themself to the AS using a username and password login.

Once this is complete, the AS forwards the username to the KDC, that in turn grants a TGT. Without completing this first step, the client cannot interact with any other part of the Kerberos system.

Ticket Granting Service

The Ticket Granting Service acts as the gatekeeper between TGT-holding clients and the various services on the network. When a client wants to access a service, they must present their TGT to the TGS.

The TGS then authenticates the TGT and establishes a session key shared by the server and client. If the TGS confirms that the client TGT includes access to the desired service, the client is granted access to request the service.

How does Kerberos work?

Kerberos authentication works in 4 phases differentiated by which components are interacting:

• User/Client Login: This phase's interactions are between the User and the Client. The user enters their username and password information into the client. The client then transforms that password into a cipher key stored locally. If this completes correctly, the client can begin authentication with the AS.
• Client/AS Authentication: In this phase, the client and Authentication Server connect to authenticate the user's username and ensure that they're part of the system. The AS then checks that the username is already documented in the system. If so, the Client and AS exchange encrypted verification messages to verify each other. By the end, both are authenticated, a connection is established, and the client may move to authentication with the service.
• Client/Service Authentication: In this phase, the client and server must authenticate each other, keeping in line with the mutual authentication practice. The client and server exchange encrypted verification messages, similar to the previous phase. If these all pass, the client and service are authenticated and the client is cleared to request their service.
• Client/Service Request: Finally, the client can request a named service from the service server. The service server then verifies that it has the requested service available. If yes, the service server grants the service to the client. As the client has been authenticated through all steps of this process, they may continue to use the service until their permissions expire.

Example of the Kerberos process

Each of these phases takes several steps, but in real-time, the process is very quick. To put what we learned above into context, let's look at a real-life example.

At the start of your workday, you enter your password into your client. The password is authenticated by the AS, and you are then granted a TGT by the KDC. This ticket has a set of keys to the dataScience realm.

The TGT is then cached on your computer for later use. This access allows you to use any services within the dataScience realm, such as access to customer buying behavior.

You could then access this service whenever you want without the need to authenticate your permissions each time.
However, if you tried to access any of the services from the finances realm, you would be declined because your TGT does not have the keys to that realm.

At the end of your workday, your TGT expires and you cannot access these services again until you get a new ticket when logging in the following day.

Kerberos process breakdown (16 steps)

Now we'll break down each step of the process to give you a better understanding of what's going on behind the scenes:

1. Login

The user enters their username and password. The Kerberos-enabled client will then transform that password into a client secret key.

2. Client Requests for Ticket Granting Server

The client then sends a plaintext message to the authentication server containing:

• The entered username
• The name of the requested service
• The network address of the user
• How long they've been requesting access for

3. Server Verifies the Username

The username is checked against verified usernames stored in the KDC. If the username is familiar, the program will proceed.

4. Ticket Granting Ticket Returned to the Client

The authentication server sends back two encrypted messages to the client:

• Message A can be decrypted with the client secret key created in step 1. It contains the TGS name, a timestamp, a ticket lifetime, and a newly granted Ticket Granting Server Session key.
• Message B is the Ticket Granting Ticket and can only be decrypted by the TGS secret key held. This contains your username, the TGS name, a timestamp, your network address, ticket lifetime, and the same TGS Session key.

5. Client Obtains the TGS session key

The client now decrypts message A using the client secret key, giving the client access to the TGS Session key. Message B is stored locally in its encrypted state.

6. Client Requests Service Access From Server

The client now sends back two messages:

• Message C is an unencrypted message containing the name of the requested service, the lifetime, and the still encrypted message B.
• Message D is an authenticator encrypted with the TGS Session key and contains your name and a timestamp

7. Server Verifies the service

The TGS then checks that the requested service exists in the KDC. If it does, the program proceeds.

8. Server Obtains TGS Session Key

The server now pulls the still encrypted message B sent in message C. Message B (the TGT) is then decrypted using the server's TGS secret key, giving the server the TGS session key.

Using this TGS Session key, the server can now decrypt message D.

Now the server has the timestamp and name from both message B and message D (the authenticator message). The server makes sure the names and timestamps are the same to prevent fraudulent messages. It also checks the timestamp against the lifetime of the ticket to ensure it has not timed out.

9. Server Generates Service Session Key

The server then generates a random service session key and two more messages.

• Message E is encrypted with the service secret key and contains your name, the requested service name, a timestamp, your network address, the ticket lifetime, and the service session key.
• Message F is encrypted with the TGS session key held by both client and server. This message contains all of the same information from message E except your username and network address.

10. Client Obtains Service Session Key

Using the TGS session key cached from step 5, the client decrypts message F to obtain the service session key.

11. Client Contacts the Service

The client now sends two more messages, this time to the service:

• Message G is another authenticator message, this time encrypted with the service session key. It contains your name and timestamp.
• Message H is a copy of message E, which is still encrypted with the service secret key.

12. Service Decrypts Message G

The service then decrypted message H with its service secret key to obtain the service session key from within. Using this key, the service decrypts message G.

13. Service Verifies the Request

The service then verifies the request by comparing the usernames, timestamps, and lifetimes from messages G and H.

14. Service is Authenticated to the Client

The service then sends message I encrypted with the service session key held by both service and client. Message I is an authenticator containing the ID of the service and a timestamp.

15. Client Verifies the Service

Then, the client decrypts message I using the service session key cached from step 10. The client then checks the ID and timestamps contained within. If both match the expected results, the service is deemed safe.

16. Client and Service Communicate Freely

Confident that both client and service are mutually authenticated, Kerberos allows the client to communicate with the service.

Is Kerberos hackable?

While still the most secure protocol, Kerberos is hackable like any other. Kerberos acting as an industry-standard protocol for so long, has given hackers ample time to overcome the system.

There are 5 major ways hackers have found to beat the Kerberos system, hinging on targeting vulnerable system setups, weak passwords, or spreading harmful malware. Let's look at each of the 5 types of attacks:

• Pass-the-ticket: This method creates a false session key by forging a false TGT. The hacker can then present the TGT to the service as a valid credential. Having the session key allows this forgery to bypass all of the Kerberos verification steps that precede the session key granting step.
• Golden Ticket: This method forges a ticket with administrator status. The hacker has unlimited access to the entire domain while using this ticket; individual devices, servers, data, and settings are all accessible. Hackers can only create a "golden ticket" if they have access to an administrator's machine, usually through installed malware.
• Silver Ticket: Similar to a Golden Ticket Attack, silver tickets are forged service authentication tickets that grant access to a service. This method grants less access than the Golden Ticket Attack but is also harder to detect. All interactions at this stage are client/service interactions, allowing the hacker to avoid security measures in place in the KDC.
• Brute force: The most obvious method, brute forcing involves using an automated password guesser to input thousands of passwords until a correct one is found. Brute-forcing doesn't require stolen credentials but can be easily detected due to their unhuman entry behavior.
• Backdoor Skeleton Key Malware: In this method, hackers plant a hidden backdoor access skeleton key in the system to allow them to log in as any user at any time in the future. This method requires a previously successful Golden Ticket Attack, as these skeleton keys can only be planted with administrative access. These are some of the hardest attacks to detect because the breach and attack could happen years apart.

What to learn next

Congratulations! Today, you learned what Kerberos is, why it's used, and what steps it takes to authenticate activities.

With more companies adopting Kerberos security protocols than ever before, this understanding will open doors to new career paths and job opportunities. The next steps in your journey are:

• Managing message integrity
• Public key encryptions
• Attack prevention techniques
• Attack response measures

To help you learn these advanced concepts, Educative offers a course to take you from a Kerberos beginner to an expert. Check out Kerberos for Beginners: Intro to Network Authentication Protocol to continue on this journey. By the end, you'll be able to counter cyber-attacks all on your own!

Happy learning!

Continue learning about cybersecurity on Educative

• What is ethical hacking and penetration testing? Get paid to hack
• Guide to Cyber Security: learn how to defend your systems
• 6 reasons why Java is more secure than other languages

Start a discussion

Why does (or doesn't) cybersecurity pique your interest more than other subjects in technology? Was this article helpful? Let us know in the comments below!