Kerberos
Kerberos is a stateless authentication protocol based on tickets. It effectively decouples a user's credentials from their requests to consumable resources, ensuring their password is not transmitted over the network. It is a Zero-knowledge proof]protocol as the KDC (Key Distribution Center does not record previous transactions; instead, the Kerberos Ticket Granting Service (TGS) relies on a valid Ticket Granting Ticket (TGT) and assumes that if a user has a valid TGT, they must have proven their identity.
This is an overview of the events that occur when user interacts with a resource through the Kerberos protocol:
A user proves its identity and receives a TGT
The TGT will be provided when accessing a service, proving that the user provided some kind of identification prior to the interaction - if the ID of the ticket is valid the KDC will give the user a temporary ticket containing all the user's information: a Ticket Granting Service or TGS
The target resource will get the temporary ticket and grant the user access to its services
The Kerberos authentication process consists in 3 main components:
The user that wants to authenticate into a resource
The service provided by the resource the user wants to access
The Key Distribution Center
Tickets
To satisfy the need to centralize authentication without sending a password over the network, Kerberos uses secret keys and tickets: as mentioned before, the user will first request a ticket from the KDC (TGT) and present it back to the KDC every time they need access to a resource - at that point the KDC will validate the TGT and return the user a TGS for that particular service; the TGS can now be used to access the resource and its services.
Both the TGT and TGS contain a lot of information about the user that requested them - to protect these details, whenever a TGT is created, the KDC encrypts it with its secret key and whenever a TGS is created it gets encrypted with the service secret key. This configuration doesn't allow the user cannot modify the information contained in the tickets but reserves access to the information to the service and KDC.
AS-REQ & AS-REP
AS-REQ is the name associated with the request sent by the user to the KDC whenever a TGT is requested.
In the request, the user will send an Authenticator: the timestamp of the request encrypted with the user's secret key which is known to both the user and KDC + the plaintext username of the user. The KDC will retrieve the username, look for the associated key in its directory, and attempt to decrypt the authenticator. If it succeeds, it means that the user has used the same key as the one registered in its database, so they are authenticated. Otherwise, the authentication attempt fails.
This step, called pre-authentication and is not mandatory, but all accounts have it enabled by default. In case it gets disabled, the client no longer needs to send an authenticator and the KDC will send the TGT no matter what happens.
The response to a AS-REQ is called AS-REP: in the response the KDC generates a temporary session key and use it to encrypt further communications with the user to avoid using the user's key. The generated TGT is signed with the KDC's key and contains a copy of the temporary session key, then the session key is sent after being encrypted with the user's key.
It's worth noting that the temporary session key created by the KDC is both sent over in the TGT encrypted with the KDC key and in the response encrypted with the user's key.
TGS-REQ & TGS-REP
Now that the user has a valid TGT protected by the KDC's key and a temporary session key protected by the user's key it can request a TGS with e TGS request (TGS-REQ). To perform the request the user will have to provide the service they wish to access as a SPN (Service Principal Name), the valid TGT and an authenticator.
The TGS-REP, the response to the user, requires the KDC to verity that the TGS request is valid - this is where the copy of the temporary session key stored inside the TGT comes into play: the KDC will decrypt the TGT, check its authenticity and extract the session key. With this session key, it will be able to verify the authenticator's validity. If all goes well the KDC will send the TGS-REP with a new session key stored in the TGS to encrypt the future interactions between the user and the requested service.
AP-REQ & AP-REP
The user can decrypt the TGS-REP with its session key and extract the valid TGS which is now left encrypted with the service's key - this completely secures the TGS and its attributes from being modified until the very end of the authentication process.
The user will only transmit this TGS ticket to the service along with an authenticator encrypted with the user/service session key just extracted from the TGT-REP.
The service finally receives the TGS ticket and an authenticator encrypted with the user / service session key generated by the KDC. This TGS ticket is protected with the service's key so that it can decrypt it. Now the service can extract the copy of the user / service session key and check the validity of the authenticator. Now the service can freely read the user's information and its access level and can send a AP-REP message with the current timestamp encrypted with the session key.
As a last step, the client can then verify that this message is coming from the service and can start issuing service requests.
Last updated