There are 3 entities when a user wants to access a service: the user, the service, and the authentication server, also known as the Key Distribution Center, or KDC.


The KDC is the entity that knows all accounts' credentials.



Why Kerberos?

On the one hand, it is used to centralize authentication to avoid all services having to know every user's credentials. This is extremely practical in a context where users are regularly updated, whether because of a password change, the addition of a new user, or the deactivation or deletion of a user. If all services had to know the status of all users, this would create immense complexity. Instead, only one entity, the KDC, must have an up-to-date list of existing users.


On the other hand, this protocol allows users to authenticate against services without sending a password over the network. This is an excellent security measure to protect against man-in-the-middle (also known as on-path) attacks.



High-level overview

Tickets

To meet both needs, Kerberos uses secret keys and a ticketing mechanism. The secret keys are, in practice, in an Active Directory environment, the passwords of the different accounts (or at least a hash of these passwords).


  1. To start, the user will request the first ticket from the key server (the KDC), proving they are who they claim to be. This is when the client authenticates to the KDC. This ticket, called a TGT (Ticket Granting Ticket), is the user's identity card. It contains all the information about the user, such as name, date of account creation, security information about the user, the groups to which the user belongs, etc. This identity card, the TGT, is limited to a few hours by default. This ticket is presented for all other requests to the KDC.
  2. Once this TGT has been obtained, the user will present it to the KDC each time they need to access a service. The KDC will then verify that the submitted TGT is valid and that the user did not forge it, and if so, it will return a Ticket Granting Service (TGS) ticket or Service Ticket (ST) to the user. A copy of the user's information in the TGT is included in the TGS ticket.
  3. Now that the user has a TGS ticket for a particular service, they will present this TGS ticket to the service to use it. The service will then check the validity of this ticket, and if all is well, it will read the content of the user's information to determine if the user is entitled to use the requested service. It is, therefore, the service that checks the user's access rights.


Ticket Protection

However, as explained above, the TGT and TGS ticket contain all the information related to the user. The service uses this information to verify the user's access rights.


This information provided by the KDC must be protected. The user must not be able to forge it. This is where encryption keys come into play.


Each account has a password or secret, which acts as an encryption and decryption key. The KDC knows the keys of all users. To protect the tickets, here is how these keys are used.

  1. The TGT sent by the KDC to the user is encrypted using the secret key of the KDC, which only the KDC knows. Thus, the user cannot read or modify the information about themself. The KDC itself protects it.
  2. The TGS ticket sent by the KDC to the user is encrypted using the service's secret key. In the same way, as the user does not know the service key, they cannot modify the information in the TGS ticket. On the other hand, when they send this TGS ticket to the service, the latter can decrypt the ticket's content and read the user's information.



Technical Details

We will now go into detail to understand how the authentication process fits all together and the protection mechanisms it utilizes against numerous attacks. We have seen that access to a service is carried out in three phases. These phases are named as follows:

  1. TGT request: Authentication Service (AS)
  2. TGS request: Ticket-Granting Service (TGS)
  3. Service request: Application Request (AP)

The client sends a request in each phase, and the server responds. We will describe how these three exchanges work, how the tickets are protected, and with what key.