Kerberos

What is Kerberos?

Kerberos is a protocol for authenticating service requests between trusted hosts across an untrusted network, such as the internet. Kerberos support is built in to all major computer operating systems, including Microsoft Windows, Apple macOS, FreeBSD and Linux.

Since Windows 2000, Microsoft has used the Kerberos protocol as the default authentication method in Windows, and it is an integral part of the Windows Active Directory (AD) service. Broadband service providers also use the protocol to authenticate cable modems and set-top boxes accessing their networks.

Kerberos was developed for Project Athena at the Massachusetts Institute of Technology (MIT). The name was taken from Greek mythology; Kerberos (Cerberus) was a three-headed dog who guarded the gates of Hades. The three heads of the Kerberos protocol represent the following:

1. the client or principal;
2. the network resource, which is the application server that provides access to the network resource; and
3. a key distribution center (KDC), which acts as Kerberos' trusted third-party authentication service.

Users, systems and services using Kerberos need only trust the KDC. It runs as a single process and provides two services: an authentication service and a ticket granting service (TGS).

KDC "tickets" provide mutual authentication, allowing nodes to prove their identity to one another in a secure manner. Kerberos authentication uses conventional shared secret cryptography to prevent packets traveling across the network from being read or changed. It also protects messages from eavesdropping and replay attacks.

Work on Kerberos began in the late 1980s. Version 5 of the protocol -- the current version -- was first published in 1993. The MIT Kerberos Consortium was founded in September 2007 to further the development of the technology. In 2005, the Internet Engineering Task Force published the Kerberos protocol as a Proposed Standard in Request for Comments 4120. In 2013, the consortium was expanded and renamed the MIT Kerberos and Internet Trust Consortium.

What does the Kerberos authentication protocol do?

The original objective of Kerberos was to provide a way for users of the MIT network to securely authenticate themselves to the systems they needed to use. It also enabled those users to be authorized to access those systems.

At that time, networked systems typically authenticated users with a user ID and password combination. Systems routinely transmitted passwords "in the clear," meaning unencrypted. Attackers with access to the network could easily eavesdrop on network transmissions, intercept user IDs and passwords, and then attempt to access systems for which they were not authorized.

Kerberos developers set out to provide a network authentication protocol that could be used to authenticate trusted hosts communicating over untrusted networks. In particular, they intended to provide system administrators a mechanism for authenticating access to systems over an open network -- the internet.

Kerberos was initially designed as the "Kerberos Authentication and Authorization System" in a paper with the same name written by S.P. Miller, B.C. Neuman, J.I. Schiller and J.H. Saltzer. The designers aimed to provide a foundation for ensuring that only authorized users can get access to specific networked resources. They intended Kerberos' authentication as a means for supporting authorization. While a user can be authenticated as having some access rights to some network resources, authorization tools enable more finely grained access to specific resources, like storage and databases.

Kerberos was also designed to interface with secure accounting systems. This provided the third "A" of the authentication, authorization and accounting (AAA) triad.

Kerberos objectives, concepts and terms

Goals for the Kerberos system are spelled out in a tutorial written by Fulvio Ricciardi of the National Institute of Nuclear Physics in Lecce, Italy. They include the following:

• Passwords must never be transmitted over the network.
• Passwords must never be stored on client systems and must always be discarded immediately after they are used.
• Passwords are never stored in plaintext, even on the authentication servers.
• A password is entered only once each session. This is an early form of single sign-on (SSO) authentication, and it means that users can authenticate themselves just once but still access any systems for which they are authorized.
• All authentication information is maintained in a centralized authentication server. The application servers themselves do not store any authentication information. This enables the following features:
  • An administrator can disable authorization for a user to use any application server from the centralized authentication server. Access to individual servers is not necessary to revoke authorization.
  • A single user password is enough to access all Kerberos-authenticated services. A user can reset their password just once, no matter how many services they are authenticated to use.
  • Protecting user information is simplified since all user authentication information is stored on one centralized authentication server rather than on all the individual servers the user is authorized to use.
• All parties -- users, as well as application servers -- must authenticate themselves when prompted. Users authenticate when they sign in. Application services may be required to authenticate themselves to the client.
• Kerberos provides a mechanism for clients and servers to set up an encrypted circuit so that networked communications are private.

Three different sets of entities use Kerberos:

1. Kerberos principals. Any unique identity that Kerberos can assign a ticket to. For most users, a principal is the same as a user ID. It also includes hosts and services that can be assigned Kerberos tickets. Individual clients are one type of Kerberos principal. The service principal is an identity assigned to an application service that is accessed through Kerberos. A principal is uniquely identified with at least three pieces of information:
   1. For users, the principal primary is a username. For hosts, the primary is the word host. For services, the primary name is the service's name.
   2. An optional identifier of the principal usually specifies the host name of the system the primary is associated with.
   3. Kerberos servers operate in a limited network region, called a realm. Realms are identified by domain name system named domains. A principal's realm is the domain name in which the Kerberos server operates.
2. Kerberos application servers. Any system providing access to resources that need client authentication through Kerberos. For example, application servers can include file and print services, terminal emulation, remote computing and email.
3. Kerberos KDC. The Kerberos authentication process depends on the following KDC components:
   1. Kerberos database. This maintains a record for each principal in the realm. This is the centralized repository for Kerberos authentication information. It includes identifying information of the principal and the systems and services for which that principal can be authenticated to use.
   2. Kerberos authentication service. Network clients use this Kerberos service to authenticate themselves to get a ticket granting ticket (TGT), also known as an authentication ticket.
   3. Kerberos ticket granting service. This Kerberos service accepts the TGT so that clients can access their application servers.

Authentication with Kerberos is based on the use of authentication tickets. An authentication ticket indicates that the user is authenticated through the Kerberos authentication service. After it has been granted, the user can request other tickets to access specific application services.

How does the Kerberos authentication protocol work?

A simplified description of how Kerberos works follows; the actual process is more complicated and may vary from one implementation to another:

1. Authentication server request. To start the Kerberos client authentication process, the initiating client sends an authentication request to the Kerberos KDC authentication server. The initial authentication request is sent as plaintext because no sensitive information is included in the request. The authentication server verifies that the client is in the KDC database and retrieves the initiating client's private key.
2. Authentication server response. If the initiating client's username isn't found in the KDC database, the client cannot be authenticated, and the authentication process stops. Otherwise, the authentication server sends the client a TGT and a session key.
3. Service ticket request. Once authenticated by the authentication server, the client asks for a service ticket from the TGS. This request must be accompanied by the TGT sent by the KDC authentication server.
4. Service ticket response. If the TGS can authenticate the client, it sends credentials and a ticket to access the requested service. This transmission is encrypted with a session key specific to the user and service being accessed. This proof of identity is used to access the requested "Kerberized" service. That service validates the original request and then confirms its identity to the requesting system.
5. Application server request. The client sends a request to access the application server. This request includes the service ticket received in step 4. If the application server can authenticate this request, the client can access the server.
6. Application server response. In cases where the client requests the application server to authenticate itself, this response is required. The client has already authenticated itself, and the application server response includes Kerberos authentication of the server.

The service ticket sent by the TGS enables the client to access the service. The service ticket is timestamped, so a single ticket can be used for a specific period without having to be reauthenticated.

Making the ticket valid for a limited time reduces the possibility that someone else will be able to use it later. The maximum lifetime can be set to 0, in which case service tickets will not expire. Microsoft recommends a maximum lifetime of 600 minutes for service tickets; this is the default value in Windows Server implementations of Kerberos.

What is Kerberos used for?

Kerberos is used to authenticate entities requesting access to network resources, especially in large networks to support SSO. The protocol is used by default in many widely used networking systems. Some systems in which Kerberos support is incorporated or available include the following:

• Amazon Web Services
• Apple macOS
• Google Cloud
• Hewlett Packard Unix
• IBM Advanced Interactive eXecutive
• Microsoft Azure
• Microsoft Windows Server and AD
• Oracle Solaris
• Red Hat Linux
• FreeBSD
• OpenBSD

Kerberos vs. other network authentication protocols

Kerberos is not the only authentication protocol in general use, but it is probably the most widely used one. Kerberos has been proven to be a secure protocol, capable of coping with unexpected input or errors during execution and widely implemented.

Kerberos vs. Microsoft New Technology LAN Manager (NTLM)

Microsoft NTLM is an outdated authentication protocol that can still be used to provide SSO services in AD domains. It was first made available in Windows NT in 1993; Microsoft deprecated NTLM for authentication, replacing it with Kerberos starting in Windows 2000. Kerberos is currently the preferred authentication protocol for Windows.

Unlike Kerberos, NTLM depends on a challenge-response protocol for authentication.

Kerberos vs. Lightweight Directory Access Protocol (LDAP)

LDAP offers a method for maintaining and accessing authoritative information about user accounts. It is widely used for authorizing user access to accounts on networked services. LDAP and Kerberos are often used together, with LDAP providing authorization services and Kerberos providing authentication services for large networks.

Kerberos vs. Remote Authentication Dial-In User Service (RADIUS)

The RADIUS protocol was designed to provide an authentication service for dial-in users to remotely access internet service providers or corporate networks over direct connections, like dial-up phone lines. RADIUS can be used for authorization and accounting of network services. It can also be integrated with Kerberos to provide stronger authentication.

Is Kerberos secure?

The Kerberos protocol is considered secure. It has been widely implemented for decades, and it is considered a mature and safe mechanism for authenticating users. Kerberos uses strong cryptography, including secret-key encryption, to protect sensitive data.

Security researchers have been investigating Kerberos since it was first published. Weaknesses have been found in specific Kerberos implementations, as well as in the protocol itself. Those weaknesses have been addressed, and Kerberos remains fundamental for authentication in the internet.

Some of the historic weaknesses in Kerberos as used in Windows networks were summarized in a 2015 blog post by security researcher Elmar Nabigaev. They included the following:

• Pass-the-key attack. This is a form of pass-the-hash attack in which attackers impersonate authorized users by replaying their credentials.
• Pass-the-ticket attack. Attackers intercept and reuse tickets sent to or from an authenticated user to impersonate them and reuse their service tickets.
• Golden ticket attack. This is an attack that uses access to the Windows domain controller to create credentials that give unlimited access to application services.

To keep Kerberos secure, you should stay up to date with Kerberos security vulnerabilities and stay current with software updates that mitigate or remediate flaws, such as the "Kerberoasting" attack used in the SolarWinds supply chain attacks in 2020.