Updated: Sep 27, 2022
What's in the name?
We will discuss Kerberos. Kerberos got its name from Cerberus in Greek mythology, a three-headed creature. The primary job of Cerberus in Greek mythology was as a watchdog for the underworld.
Before we get started intent here is to understand conceptually how the Kerberos protocol works and establishes trust between the Client and Server.
What is Kerberos?
Kerberos was designed to provide secure authentication to services over an insecure network. It is based on the concept of authenticator and tickets. Some of the fundamental mechanisms used in Kerberos are
It uses client server-based model
Root of trust is a trusted third party (KDC)
Messages are encrypted using secret symmetric keys or Session keys
No passwords are sent over the network
Protocol supports mutual authentication which means user and server can authenticate each other.
History
Initially developed at MIT as an internal project, Kerberos-4 was officially published in the 1980s. However, its export was restricted due to cryptographic algorithms used by it. After the US government lifted export restrictions, MIT made it available under a BSD license in early 2000. Microsoft made it its default authentication method in the windows 2000 server. Kerberos later evolved under IETF (Internet Engineering Task Force) and was supported by significant tech vendors such as Oracle, Apple, Microsoft, and Google.
The Protocol
Critical stakeholders in the whole process are:
Client - Which acts on behalf of the user
KDC-We have combined Authenticator, Key Granting Server and a database as a key Distribution Centre (KDC). It acts as the central trust authority in workflow. Its purpose is to authenticate user and issues Tickets, which is the basis for other services to trust a user.
Server-Server is resource that the user wants to access
Complete protocol flow depends on encryption using secret key (typically symmetric keys)
Client/user: Hash derived from the User’s password
TGS secret key: Hash of the password employed in determining the TGS
Server secret key: Hash of the password used to determine the Server providing the service.
Additionally, the session keys issued by KDC are used to encrypt data from the Client to KDC/Server.
Authentication
Before accessing the Server, the User must request authentication by sending credentials like NetID, name of service requested, and IP address from the Key Distribution Centre (KDC).
Upon receiving the request, KDC will check to ensure that the User exists in its database. After validating the User, KDC creates cryptographic keys for the session. The KDC will then send back two messages.
TGT message is encrypted by TGS secret, and the User will not have access to it.
A message containing TGS ID, Timestamp and TGS Session key. This message is encrypted using a secret key derived from the user password hash.
The Client uses the password to generate a secret user key which is not a simple hash but multiple iterations of the hash of the password. This secret is used to decrypt the message, and the Client gets access to the session key, allowing the User to move to the next step.
Though the Client has the TGT, it cannot decrypt it since it is encrypted using the KDC’s secret key. The Client will send two requests to the KDC asking for access to the Server.
Ticket Granting Ticket (TGT)
A request contains the User’s NetID and timestamp. This request is encrypted by the Session key obtained from the previous step
The Ticket Granting Server
KDC will decrypt the TGT message, and this TGT message also has the Session key originally supplied by KDC, which will allow KDC to resolve the user authentication message once KDC completes the verification of credentials. It issues two messages.
Service Ticket, which is encrypted using Server secret key
A message containing the Service Session key. This message is encrypted using the TGS session key
On receiving the messages, the Client uses the TGS session key to obtain the Service Session key and sends two messages to Server.
Service Ticket received from KDC
An authenticator with the User’s NetID and Timestamp
The second message is encrypted using the Service Session key.
Service Request
The Server will decrypt the ticket using its secret key to retrieve the Service Session key. Service decrypts the authenticator and compares the User’s NetID from the Service Ticket message. If they match, the service sends the following message to the Client to confirm the service’s identity:
A message containing the time stamp is sent as part of the authenticator message. This message is encrypted using the service session key
The Client will decrypt the confirmation message and will check its timestamp. If it is correct, the Client can trust the service, and the User can begin using it.
Summary
Security practitioners worldwide consider Kerberos to be secure. It has strong encryption to secure data. However, no security measure is 100% impregnable, and Kerberos is no exception. Since it’s been around for so long, hackers have had the opportunity to find ways around it, usually by forging tickets and making repeated attempts to guess passwords (brute force/credential stuffing). Hackers getting access to the privileged account can cause havoc using Kerberos.