When working with authentication protocols the commonly used technique in the past was known as authentication by assertion. In this scheme a user logs in to their machine which then authenticates their request to a remote server. Once the authentication is finished the user can then communicate with other services. This provides a very low level of security, which has led to numerous vulnerabilities in the early versions of the rlogin Unix login utility.

An alternative solution is for the user to repeatedly provide their password each time they wish to use a service. This however requires the user to send their plain text password over the network, which could potentially be intercepted by a third-party user and can get compromised.

Kerberos aims to solve this issue by introducing a mechanism where a user only logs-in to their local machine once, also known as Single-Sign On or SSO. The user’s information is transferred securely over the network (and is deprived of plaintext passwords). This removes the risk of user’s password being sniffed by an eavesdropper as the protocol only uses secret keys for communicating with the outside service.

The Kerberos Authentication System

The Kerberos Authentication System was first introduced in 1988 (paper). Its motivation was to authenticate a client to a server without sharing the user’s password across a network. Normal authentication protocols are prone to outside attackers who can sniff the network traffic and potentially gain access to user credentials.

This led Kerberos to gain popularity during the past few decades and it is now being used in various organisations as their main authentication system, including CERN. Kerberos is also the default authentication system used by the Windows Operating System.

Before explaining how this protocol works, let’s review the terminology used in Kerberos. In Kerberos the client and user are referred to as a “process” and a “principal”, respectively. Apart from this it also has a naming convention for the entity used for authentication, which consists of its primary name, the instance, and a realm, and is expressed as name.instance@realm. The primary name is the name of the user, and the instance allows the system to distinguish variations among the primary name. A realm refers to the administrative entity, for example, CERN.CH.

Kerberos exchanges a series of encrypted messages with the verifier (server) to prove that the process is running on behalf of the intended user. These messages include an encryption key, which is unique to each user, and is derived from their password. When an application communicates with the server it encrypts the data using this key and the server verifies its confidentiality through its checksum.

Note: Although Kerberos ensures that the user’s password is not shared with the service, there is still a risk of the user’s machine being compromised, for example, through a Trojan horse malware.

Obtaining the encryption key

Before a client sends an authentication request to the server, the authentication key is only known by the server, which it regenerates each time the client tries to authenticate itself. Kerberos then issues a certificate which is encrypted with the newly generated key and distributes it to the client. This certificate includes, among other information, a session key along with its TTL timestamp (after which the key will expire).

The encryption algorithm used by Kerberos is called DES or Data Encryption Scheme.

The Kerberos Database Management Service (KDMS)

The KDMS is responsible for performing write operations to the Kerberos database. The current version of Kerberos states that the management service should only run on the server node, as shown in the figure below.

KDMS utilities

The client side of Kerberos provides two utilities for communicating with the server. The first utility, kpasswd, allows the principal to update their password. The second utility, kadmin, allows the administrator to access the Kerberos database. It provides numerous commands for modifying, updating, and deleting a principal. As an example, the password for the principal user can be updated by:

$ kpasswd adeel
Password for adeel@CERN.CH: <current password>
Enter new password: <new password>
Enter it again: <new password>

Note: It is not necessary to specify the username in the above command if that user is only registered with a single realm.

An important point to note here is that KDMS does not rely on the standard ticket-granting service, but rather requires the principal (user) to use the authentication service each time they interact with the database. Because of this feature, a logged-in user is not at risk of getting their password modified by a malicious user if their workstation is left unattended.

Kerberos database replication

To achieve better performance and high availability, Kerberos clients posses an exact replica of the Kerberos server database. The database needs to be in sync with the server and must contain the latest changes. For this, Kerberos provides two tools called kprop and kpropd. The kprop tool runs on the server side and periodically creates a dump of the database (every 1 hour by default) and sends it to the client.

Note: Some additional steps are not mentioned here for brevity. These include the database checksum, which is used for verifying the data authenticity.

Kerberos in practice

In some implementations of Kerberos the ticket is obtained as part of the system login process. Thus the user is often oblivious that Kerberos is running in the background.

In other cases the user can manually login using the kinit tool:

$ kinit adeel
Password for adeel@CERN.CH: <password>

Limitations of Kerberos

Although Kerberos takes away much of the hassle involved in the authentication process, it nevertheless has some limitations entailed with it. Firstly, if the user has chosen a weak password, it is relatively easy for an attacker to impersonate themselves as the real user. Secondly, the ticket expiration time is always a trade-off between security and convenience. A longer expiration time raises the risk of the session key being stolen and thus allowing an attacker to gain authority over the services, and a short expiration time requires the user to regularly re-enter their plaintext password into the shell, which could be infected by a malware.

Kerberos also does not support multifactor authentication by default, which is nowadays becoming the norm for most modern-day applications.

Disclaimer: The images in this blog post are taken from the Kerberos MIT paper.