10.4 Kerberos Referrals

As originally implemented in MIT Kerberos 5, each Kerberos client requires detailed configuration information about all realms the client participates in. With Unix clients, the information is coded in the /etc/krb5.conf file. This file must be kept up to date and distributed to all clients, which, in large and complex network environments, can quickly become an unwieldy and unmanageable task. Furthermore, machines that are not centrally managed or mobile machines such as laptops are even more problematic, as distributing changes to the Kerberos configuration files to these machines is nearly impossible.

Microsoft recognized the need for a new method for handling this configuration information in a centralized place when it implemented Kerberos in its Windows 2000 operating system, and created a system by which the KDC can provide clients correct replies, even when queries are misdirected or malformed. Through this mechanism, clients only require minimal configuration, enough to find their local Kerberos realm, and all queries are directed to the local KDC, even cross-realm queries destined for a foreign Kerberos realm. The Kerberos support in Microsoft's Windows 2000 and later operating systems includes support for—and, indeed, depends on—the functioning of Kerberos referrals for Windows domain operations.

There are three classes of information that the Microsoft implementation of Kerberos referrals handles for Kerberos clients: user and service principal name canonicalization through the AS and TGS exchanges respectively, and cross-realm trust relationships. Extensions to the Kerberos protocol are used to provide this capability and retain backwards compatibility with implementations that do not understand Kerberos referrals.

But first, what is name canonicalization? Both people and hosts can be known by several names, such as in the case of hostname aliases or multihomed hosts. Each user can have several names associated with him as well, such as his email address or his Kerberos principal name. Since Kerberos associates a single principal with a single key, it is required that these names be changed into a normalized format and name, so that there is a single Kerberos principal that refers uniquely to a given user or host. For example, a host with several IP addresses and several hostnames must be assigned a single "official" hostname. This hostname is referred to as the host's canonical hostname. Kerberos referrals move the burden of name canonicalization from the client and DNS to the KDC.

10.4.1 User Principal Canonicalization

KDC-side user principal canonicalization provides for both user and administrator convenience. Similar to passwords, users want to remember only one identifying principal. For example, a user's email address may be different than his Kerberos principal name. Furthermore, the Kerberos principal name associated with the user may change if he moves between departments, while his email address stays the same.

Therefore, Kerberos referrals provide a new field in the AS exchange for clients to send an alternative name when acquiring the initial TGT. When the KDC receives an AS request with this field filled in, the KDC will search a directory to map the user name given to a principal that exists in the local Kerberos database. If the user does not exist in the local realm, the KDC may instead use the cross-realm referral mechanism, described below, to refer the client to the correct realm.

10.4.2 Service Principal Canonicalization

Service name canonicalization is a hard problem to solve on the client side. There are several solutions that are commonly used for service name canonicalization in current implementations. The first technique employed is to simply take the network name given by the user verbatim, and shift it to lowercase. The service name and the lowercased hostname are concatenated to form the service principal that the client requests from the KDC. This method has a major drawback: many users may use a short hostname or host alias when entering in host names, when the service principal is generated using the fully qualified domain name of the host name. When these names are used in the TGS request to the KDC, then the KDC may not be able to find the service principal, as the hostname given by the user may not be the same as the hostname component of the service principal in the Kerberos database.

The second canonicalization technique uses the DNS. The Kerberos libraries take the hostname given by the user, perform a DNS lookup to get the host's IP address, and perform a reverse lookup on the IP address to get the host's primary DNS fully-qualified domain name. This technique solves the problem of a host that has several DNS aliases, but does not solve the problem of a multihomed host that has several IP addresses, each with a different hostname. While this behavior of assigning multiple hostnames to the different interfaces of a multihomed machine is discouraged in the Host Requirements RFC, it is still common in many network layouts. Furthermore, DNS lookups are not secure, and it is possible that a user may acquire tickets for a service he did not intend to communicate with. The Kerberos Clarifications require that future Kerberos implementations not use the DNS for service name canonicalization for this reason.

KDC-side service principal canonicalization can solve these problems. The KDC maintains a mapping between the host aliases and the canonical hostname used in the Kerberos service principals for that host. When Kerberos clients request a service principal through the TGS exchange, the client sets a canonicalize bit in the TGS request, signaling the KDC that it is permitted to return a ticket for a service name other than the one requested. The KDC looks up the service name in its Kerberos database, and returns a different principal name than the one requested if it recognizes that the client has requested a principal with a hostname other than the canonical hostname.

10.4.3 Cross-Realm Referrals

All of the above also ties into the cross-realm referral capability provided by Kerberos referrals. Traditionally, clients are required to track the mapping of DNS domain names to Kerberos realm names as well as the certification and trust relationships between multiple realms. These mappings exist in the domain_realm and capaths stanzas of the MIT and Heimdal krb5.conf configuration file. The client is responsible for determining the realm that each service it requests a ticket for belongs to, and if necessary, requesting all of the required tickets along the certification path between the client and the service the client wishes to reach. In the case that both client and service are located in the same realm, this is a trivial task since the client can ask its KDC directly for tickets for the service. However, when client and service are located in different realms, the client must request cross-realm tickets from all intermediary Kerberos realms between itself and the destination service.

With Kerberos referrals, the client simply asks its local KDC for tickets to all services, regardless of whether the service is in the local realm or in a remote realm. When the KDC receives a ticket request, the KDC checks to see if the service exists in the local realm. If so, it returns a ticket as usual; if it does not find the service, it will instead return a cross-realm ticket to the next realm in the certification path. The client will then use this cross-realm ticket and contact the KDC in the next realm in the path, asking for the target service. This process repeats until either the client receives a ticket for the target service from a KDC serving the service's realm, or an error is returned because either there is no path to the target realm, or the target realm doesn't have an entry in its Kerberos database for the target service.