Kerberos is a network authentication protocol/key distribution service intended for Intranet usage through a three-tier system that uses encrypted service tickets instead of the traditional username and password. Kerberos service tickets are created using the Kerberos Key Distribution Center, or KDC, and have a limited time to be used before the credentials become invalid. The KDC assigns key pairs to both the client and application server within an environment, so that it requires three systems to authenticate a transaction on the network.

Service tickets not only have a limited time of use but are also unique to the client and server that they are being used to authenticate; this means that an intercepted service ticket on the network is of little use to an attacker since they would need to be able to authenticate as a user against the server. These benefits allow a single-sign-on system to be used through Kerberos, authenticating a workstation that a user is logged in to access all the resources allowed within a Kerberos realm (domain).

Some things to consider before implementing Kerberos authentication in an environment are that all connected systems will need to be within the same realm or a trusted realm. At that time, servers will need to be coordinated with all devices on a network, since Kerberos allows no more than five minutes of skewed time before authentication will fail. Active Directory is yet another means of authentication and can be integrated with Kerberos for single sign-on use with non-Windows systems. Active Directory essentially allows for single sign-on within a domain, to enable profiles and resources to be accessed from any system that is on the domain; this means that users without an account will not be able to access these resources and that user accounts and other objects can be centrally managed from a domain controller on a network, allowing resources to be allocated depending on organizational units, locations, and other unique identifiers assigned to each user.

There are two versions of Kerberos in use, Version 4 and 5. Version 4 still exists; however, Version 5 is currently replacing it due to its many improvements. While Version 4 requires DES, Version 5 utilizes ciphertext, which is tagged with an identifier (encryption type); this allows the use of any encryption technique. Version 5 also allows for any network address type to be used, whereas Version 4 is restricted to IP addresses. Furthermore, Version 5 offers Abstract Syntax Notation One (ASN.1), arbitrary ticket lifetime (instead of Version 4’s 1280-minute maximum), authentication forwarding, and inter-realm authentication (Stallings, 2017).

While Kerberos is quite sophisticated, it can be explained a little simpler. Kerberos, the three-headed guard of Hades in Greek mythology, has its name due to being able to authenticate (using a third-party KDC) between a host machine, service, or client. Kerberos works with three interactions that take place between the user, the Authentication Server (AS), Ticket Granting Server, and service/host machine the user is trying to access; each of these interactions will send two messages to the user, one they can decrypt and one they cannot. The KDC will store all secret keys in their database, which itself is encrypted with a master key.

Let’s say a user wishes to access an HTTP service. First, the user must say hello to the authentication server; this is achieved by a plaintext request for a Ticket Granting Ticket (TGT), which contains the user’s name/ID, name of requested service (Ticket Granting Server), network address, and requested lifetime of the TGT. The information is then sent to the Authentication Server to check if the user is in the KDC database. While not checking credentials, if the user is not found, a session key will be generated. Next, the authentication server will send two messages to the user, a Ticket Granting Server Session Key and a Ticket Granting Ticket. Once the user enters their password, if it is valid, the Ticket Granting Server Session Key will unlock the user’s Secret Key. In a plaintext request, the HTTP Service ID, as well as its lifetime, is sent from the user to the Ticket Granting Server via an Authenticator (Timestamp, ID) and a Ticket Granting Ticket (ID, HTTP Service ID, IP address, lifetime, TGS Session Key, and timestamp) (Root, 2013).

The Ticket Granting Server will check the KDC database to see if the HTTP service exists; if it does, the TGS will decrypt the TGT with its secret key, then decrypt the Authenticator the user sent. Next, the TGS sends the user an HTTP Service Session Key and a Ticket for HTTP Service. The HTTP Service Session Key will decrypt the Ticket Granting Server Session Key, but the Ticket for HTTP Service will not be decoded due to lacking the HTTP Service Secret Key. Now, the user must communicate with the HTTP service via a Ticket for HTTP Service and an Authenticator; both of these will be decrypted using the HTTP Service Session Key. Next, the HTTP service sends an Authenticator message (ID, timestamp) to the user to confirm its identity to the user, which is then decrypted with the cached HTTP Service Session Key. Finally, the user has been authenticated to use the HTTP Service (Root, 2013).


Stallings, W. (2017). Network Security Essentials: Applications and Standards (Sixth). Pearson.

Kerberos: The Network Authentication Protocol. (2018). Retrieved from

What Is Kerberos Login and Authentication? (2018). Retrieved from

Root, L. (2013, April 2). Explain like I’m 5: Kerberos. Retrieved March 31, 2020, from

Categories: Security

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s