Each time you add a new user service to your computing environment, the password burden on your organization grows exponentially.
Kerberos greatly simplifies password management, but understanding it is anything but simple. Most people find themselves dragged into depths of detail that leaves their heads spinning.
This article will help you understand the Kerberos protocol from the 10,000-foot level, just enough to help you debug Kerberos authentication problems without causing undue brain drain.
We’ll start with some of the design goals of the Kerberos protocol as well as a few useful definitions, then move to a high-level overview of the part of the protocol used by a client to authenticate a user to an interface running on a remote system.
Design Goals and Definitions
Goal 1: Authentication Protocol for Distributed Computing Network
Kerberos was created by MIT as an authentication protocol for distributed computing networks. We don’t use that term very much anymore, but that’s exactly what our networks are today. Back in the early 80’s when MIT was creating Kerberos, they thought of remote interfaces that authenticated users (e.g. login, FTP, printer servers, application server programs, etc.) as “services” provided to those users. The Kerberos architecture was designed to accommodate the fact that the same service might be provided by more than one system or TCP/IP address (e.g. print server A and print server B).
Goal 2: Password Elimination
MIT realized that using the userID/password authentication protocol causes the cost to manage passwords for each new service to increase by the total number of users accessing that service. This would be a significant hit in terms of cost and productivity. Therefore, another design goal of Kerberos was to allow services to authenticate users without users having to first create/share their passwords on/with each service they might use.
To do this, Kerberos implements something called a “third-party trust” model. Third-party trust is based on the idea of transitive trust; i.e. if (A trusts B) AND (B trusts C), then A trusts C.
It’s easiest to explain this with an example. Consider a service represented by ServiceA, a trusted third party, known as a Kerberos-B, and a person represented by UserC. Both UserC and ServiceA trust Kerberos-B and Kerberos-B trusts both of them. ServiceA needs to establish trust in UserC before it allows UserC to access the service.
Given the concept of transitive trust, we can assume that even though mutual trust has not been established directly between ServiceA and UserC, that ServiceA can trust UserC. There exists one caveat to this statement. ServiceA trusts UserC IF — and only if — UserC can prove to ServiceA that it is trusted by Kerberos-B.
In order to meet the objectives of the Kerberos protocol, userIDs are assigned not only to entities that need to be authenticated; entities that authenticate other entities are also assigned userIDs. Kerberos userIDs that represent entities that are authenticated are called “Kerberos principals” or just principals. Kerberos userIDs that represent entities that authenticate principals are referred to as “service principals.” Both principals and service principals also have passwords associated with them.
Kerberos principals have the form: <principal-name>@<realm-name>.
Kerberos service principals have the form <service-name/location>@<realm-name>.
Since the same service may be provided by more than one system, service principals include the “location” of the desired service in the form of a TCP/IP hostname or address.
Kerberos realm names are similar to Windows domain names. A realm/domain represents a collection of users that are known to and trusted by a particular set of systems that comprise a network. Realm names are often the same name as the TCP/IP domain name or the Windows domain name. This isn’t required, but is done by convention. Windows domains and Kerberos realms are kinds of “user registries.”
High-Level Overview of Client Authentication in the Kerberos Protocol
Now I’m going to skip over a bunch of details about the protocol that aren’t necessary to understand, in general, how trust is established between the client and the remote service.
The passwords for all principals and service principals are stored by the Kerberos Key Distribution Center (KDC) (hashed/encrypted). I often refer to the KDC as the “Kerberos Server” (This would be disdained by technical folks in the know about Kerberos). In a Windows domain, the Windows Domain Controller is the KDC. Active Directory is where the passwords are stored.
The KDC uses these passwords to generate encryption keys which are used to encrypt “tickets”. A user makes a request to the KDC to generate a ticket that will authenticate them to a specific service principal. The KDC validates the request and generates a ticket that is returned to the user. Tickets generated by the KDC contain two halves. Essentially, each half contains the same information; however, one half is encrypted with the principal’s password. The other half is encrypted with the service principal’s password.
Among other pieces of information in the ticket are the name of the principal that is trusted by the KDC (e.g. userC@myrealm.com), the service principal name for which the ticket is intended (e.g. serviceA/system1.myrealm.com@myrealm.com), and a “nonce” value. A nonce value is just a pseudo random number. A nonce is generated by the KDC, used only once and stored in both halves of the ticket. Its specific value is meaningless.
When a program running on user’s behalf wants to use a remote service, it sends a request to the KDC. Among other important security things that are passed to the KDC on this request, the request includes the service principal name of the service to which the program wants to connect. After the KDB returns the ticket to the program, the program decrypts the part of the ticket encrypted with user’s password and retrieves the nonce value. Now the program sends the ticket and the nonce value to the remote service for authentication.
The remote service needs to prove a few facts in order to trust that the information contained in the ticket it received is, indeed, from the user defined in the ticket:
- Mutual trust has been established between the user and KDC
- Mutual trust has been established between the service and KDC
- The entity that requested the ticket is, in fact, the entity represented by the ticket.
- The ticket was intended for this specific service
All of these must be proved before the service can fully trust that the entity trying to connect to the service actually IS who the ticket says it is.
Verifying Fact 1 – Mutual trust exists between the user and the KDC
Remember that third-party trust requires the user and the service to both have established mutual trust with the KDC. The user establishes trust with the KDC when the user verifies and retrieves the nonce value from the ticket received from the KDC. The only way this can happen is if the user can successfully decrypt the ticket since, other than the user, only the KDC should know user’s password. Therefore, if the ticket can be decrypted with the user’s password, then it must have been the KDC that generated the ticket.
The KDC can trust the user because if the entity that made the request was an imposter, it would not be able to decrypt the ticket and retrieve the correct nonce value.
Verifying Fact 2 – Mutual trust exists between the service and the KDC
Similarly, the service can prove that the ticket was generated by the realm’s KDC (and not an imposter) by successfully verifying and extracting the nonce value, among other information. Again this proves the fact because, other than service, only the KDC knows the service’s service principal password.
Conversely, the KDC establishes trust that the only that specific service that can use the information in the ticket is the service whose password is associated with that service’s service principal. This is because the only way that service can even access the information is by decrypting the ticket with the service principal’s password.
Verifying Fact 3 – The entity that requested the ticket is, in fact, the entity represented by the ticket
This is where the nonce value comes in. The user proves to the remote service that it is not an impostor by sending the nonce it extracted from the ticket along with the ticket to the remote service. The service verifies the ticket and extracts the nonce value from it by decrypting it with its password. It compares the nonce value extracted from its half of the ticket with the nonce value sent with the ticket by the user. If the values match then this fact is verified.
Verifying Fact 4 – The ticket was intended for this specific service
The ticket includes the service principal name of the intended service. Service principal names include the location of the service in the form of a hostname or IP address. If the service principal name or the location doesn’t match this specific service, then the ticket must not have been intended for this service. Note that this allows duplicate services in different locations to share the same password.
Once these facts are established, the remote service has successfully established trust in the user (i.e. authenticated the user).
Perfect for Single Sign-On
Beware….Kerberos is NOT necessarily the whole single sign-on solution, but it often plays a critical role in implementing single sign-on. If you’d like to learn more about how Kerberos can support single sign-on, take a look at my white paper A Guide to Practical SSO. Kerberos also forms the cornerstone of our SSO stat! service.
Summary
While this all seems very complicated — and it is a bit complicated – the Kerberos protocol avoids the need for each user to manage a separate userID and password for every service in the network — and for all services that may be added in the future. From the organization’s point of view, this leads to an exponential expansion of the number of passwords as well as the cost of managing and protecting them.
For the cost of managing one password for each service in the network, the organization avoids another userID and password for each user for each service. I’d say that’s a pretty good tradeoff!
