The Kerberos Authentication System for Single Sign-On (SSO)

When working with authentication protocols the technique commonly used in the past was known as authentication by assertion. In this scheme a user logs in to their machine which authenticates their request to a remote server. Once the authentication is completed the user can further 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, but rather tedious solution is for the user to repeatedly provide their password each time they wish to use a service. However, this requires the user to send their password over the network in plain text, which can 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 once on their local machine, hence the name, Single-Sign On or SSO. Their 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 first paper describing the Kerberos Authentication System was published in 1988. The main motivation behind Kerberos is 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 passwords. This has 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.

Note: Kerberos is the default authentication system used by the Windows Operating System.

Before explaining how this protocol works, let’s go over the terminology used in Kerberos. In Kerberos a client and user are referred to as a “process” and “principal”, respectively. Apart from this it also provides a name for the entity used for authentication, which consists of a 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 a particular 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 by checking 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 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 a 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 a timestamp after which the key will expire.

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

The Kerberos Database Management Service (KDMS)

The KDMS is responsible for performing write operations to the 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: In case a user is registered with a single realm, it is not necessary to specify it with the kpasswd command.

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

Authentication process for kpasswd and kadmin

Kerberos database replication

To achieve better performance and high availability, the Kerberos clients posses an exact replica of the Kerberos server database. However, 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 (every 1 hours) creates a dump of the database and sends it to the client.

Database replication in Kerberos

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. Otherwise, the principal can manually login using the kinit tool, as shown below:

$ 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 can be infected by a malware.

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

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