Introduction to Kerberos
Tags: security, todayilearned, kerberos, authentication
Published: 2020-08-16 19:07:06

This post is for those(like me) who have heard the term Kerberos being used a lot of times but have never really understood what it is or what it is used for. I do not claim myself to be an expert on this topic, and please point out my mistakes if any, I’ll immediately update my post.

First things first…

# What is Kerberos? 

According to Wikipedia, 
*Kerberos is a computer-network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner.*  

Simply put, this means that Kerberos is a network security protocol, that authenticates service requests between hosts over an unsecure network( like the internet). It uses strong cryptographic principles to help clients proved their identity to the server(and vice versa)
This prevents malicious attackers from trying to steal client identities. We’ll how this is done in the next sections.

Kerberos derives its name from Cerberus, a three headed dog in greek mythology. Similar, to the three headed dog, Kerberos has 3 important parts present in Key Distribution Center:-
* Kerberos Database
* Ticket Granting Service
* Authenticating Service

I’ll be explaining each component in detail.

# Terminology

Lets start with same basic terms you’ll see when dealing with Kerberos

1. **Tickets** - Tickets(Kerberos tickets/Kerberos Credentials) are a set of electronic information that can be used to verify your identity. Just like you need tickets to enter a train or a bus, you need kerberos tickets to get access to certain services secured by Kerberos.

2. **Principals** - Principals are unique entities to which tickets can be assigned.

3. **Key Distribution Center** - This is the central server responsible for authentication. It is split into 3 important parts -
    * **Kerberos Database** - The kerberos database is the database which stores information about each principal, its passwords and its administrative information.
    * **Authentication Server** - The server used for authentication clients and principals. This is the server responsible for handling the initial authentication request from clients. This issues a ticket called the Ticket Granting Ticket(TGT) which acts as a proof that the client is authenticated.
    * **Ticket Granting Server** - This is the server used for issuing service tickets to authenticated clients.


# Lifetime of a request

Let us now look at how authentication takes place using Kerberos. Say a User Alice wants to access a service, say a SQL Database. Following are the steps that take place

**Step 1**: Alice sends a request to the **AS**(Authentication Server). This request contains the credentials for Alice along with some other details required for authentication. The password is not actually sent over the network(It is never safe to send passwords over the network), but all this data is encrypted using Alice’s password and this encrypted data is transmitted to the AS.

**Step 2**: The **AS**(Authentication Server) decrypts Alice’s data. This is possible as the Authentication Server has access to passwords of all users(through the Kerberos Database). After decrypting it checks if the data is valid and untampered(to prevent attacks like the replay attack). If it is able to decrypt the data, and it finds the data is untampered, the **AS** sends her a **TGT**(Ticket Granting Ticket) back. The **TGT** is a ticket that, as its name suggests, is used to ask for tickets to other services. The TGT contains a **session key**(you’ll understand its importance soon) along with some other data. This **TGT** is encrypted using a Kerberos admin password(which can be assumed to be impossible to crack) and the encrypted data is sent to Alice. The **AS** server also sends the session key separately(outside the TGT), but this time the key is encrypted using the user’s(Alice’s) password. So, the session key is sent to Alice, encrypted in 2 ways - using the admin password, and using Alice’s password. 

**Step 3**: Now Alice receives 2 pieces of data - The first is the **TGT**, that it cannot decrypt and read(since it is encrypted using the admin password, and Alice doesn’t have access to it), and the second is the **session key**, which was encrypted using her password, and so can be accessed and read by her. Once Alice has the **session key**, she sends a request to the **TGS**(Ticket Granting Server). This request contains the (encrypted)TGT she received from AS along with her username, the service name she wants to access(SQL), the current timestamp, and other data encrypted using the session key.

**Step 4**: The **TGS** now receives the **TGT**. It decodes the TGT to get the session key. It uses this **session key** to decrypt the user data, that was sent along with the **TGT**. After decrypting this data, the Ticket Granting Server now can be assured that it was Alice who was making the requests, and she wants to access the SQL server. The Ticket Granting Service then sends Alice a **Service Ticket**(encrypted using the service password) and a new session key. This is similar to Step 2, only this time a service password is used instead of an admin password.
(An important point to note here, is that the TGS is not responsible for checking if Alice has the proper rights to access the SQL, which is to be decided by the target server(SQL). The TGS only verifies whether the user(Alice) is the one who claims she is and not an imposter)

**Step 5**: Again, this step is similar to step 3, Alice is unable to decrypt the Service Ticket, but she can obtain the new **session key** by decrypting the second part of the request using her password. Using this session key, she encrypts the data to be sent to the target server(SQL) and sends this data with the Service Ticket

**Step 6**: The **Target Server**(SQL Server) decrypts the Service Ticket. It can do this because the ticket was encrypted by TGS using its password. It gets the session key after decryption and uses this to decrypt user request that was sent. It can then act on this request accordingly.

In this way Kerberos ensures authentication of a user in a complex system.


# Problems with Kerberos

Kerberos, like any other system, is not impenetrable. Here are some attacks possible. I’ll leave the details about the attacks for you to explore.
* Golden Ticket Attack
* Silver Ticket Attack
* Brute Force Attack

Please feel to reach out if you have any doubts, or to correct me about this article.

# References

https://www.youtube.com/watch?v=snGeZlDQL2Q
https://www.simplilearn.com/what-is-kerberos-article
https://web.mit.edu/kerberos/