Effectively using Kerberos on your network requires you to install a Kerberos password server (more commonly called a key distribution center, or KDC ) and add both client and server software that uses the KDC for authentication (these are often called Kerberized applications ). Understanding the basics of the Kerberos protocols, including the interactions between these elements, is important for effective use of Kerberos on a network. This section therefore presents the basic principles of the protocol's operation, including information on various Kerberos products and requirements for a KDC.
Basic Principles of Kerberos Operation
Described in a single sentence , Kerberos is a centralized user authentication protocol that uses encryption to protect against various forms of attack. This description, however, is incomplete; Kerberos's encryption system is fairly complex so that it can meet various specific design goals. The structure of a Kerberos network also involves certain features that require some discussion.
Kerberos Network Elements
As already described, a Kerberos network is built around a KDC. This KDC is responsible for authenticating machines in a Kerberos realm. Typically, a realm corresponds to an Internet domain or subdomain. For instance, the threeroomco.com domain might contain a single Kerberos realm, which would probably be called THREEROOMCO.COM . Kerberos realm names are case-sensitive, unlike Internet domain names . The convention is to use all-uppercase letters for Kerberos realms simply to distinguish in writing between the functions of a realm and a domain, although the two may consist of the same set of computers. It's possible for a Kerberos realm to span less than an entire domain, or to include computers in multiple domains. If you want to use two separate Kerberos realms in a single domain, the common practice is to add a separate element to the start of the Kerberos realm names, such as REALM1.THREEROOMCO.COM and REALM2.THREEROOMCO.COM .
Kerberos works by assigning tickets for various services. Like an airline or movie theater ticket, a Kerberos ticket grants the holder access to something. As described shortly, there are two main types of ticket.
A Kerberos server is, as you might expect, a computer that runs the Kerberos server software, or the server software itselfin other words, the KDC. A Kerberos client is a computer or program that obtains a service ticket from the Kerberos server. Normally, this system is associated with a user who initiates a request to obtain service. The name for a computer that the Kerberos client is ultimately trying to use (say, a print server) is the application server.
Kerberos assigns tickets to principals, which as a first approximation are similar to users or server programs. Principals are described as three components : a primary, an instance, and a realm. These three components are expressed as primary/instance@realm . The primary is a username, in the case of a user requesting a ticket. If it's a computer that requests the ticket, the primary is the word host . A principal can also be associated with a specific server, in which case the primary is usually the server name, such as ftp . The instance is optional, and is used to create separate entries for a single primary for different purposes. For instance, the user fluffy might have a regular principal for ordinary use, but another principal that uses the admin instance for administering the realm. If the realm is THREEROOMCO.COM , these two principals would be expressed as fluffy@THREEROOMCO.COM and fluffy/admin@THREEROOMCO.COM .
Kerberos Design Goals and Operation
In order to better understand why Kerberos does things the way it does, it's helpful to look at the Kerberos design goals. These include the following:
Kerberos was also designed to meet various technical requirements that are partly dependent upon design details of the system, but the preceding three are the main requirements from a user's or administrator's point of view. To achieve these goals, Kerberos relies upon its tickets. The process works something like this:
From here, the data transfer proceeds more-or-less as it would without Kerberos in the picture, although some Kerberized applications support data encryption features that are unavailable to their non-Kerberized counterparts. Eventually, the TGT and server tickets will expire, but the expiration times are set to long enough values (several hours) that this seldom poses a problem for individual users. If a ticket does expire, it can be renewed.
Requirements for the Kerberos Server
This design has several consequences. Most importantly, the KDC is an extremely sensitive system, from a network security point of view. The KDC should run as few other network servers as possible (normally only those required to administer it ideally none), it should have no ordinary users except for its administrators, you should pay particular care to keeping its software up to date, and it should be physically secure. Because use of many network services depends upon the KDC, you should be prepared with contingency plans in case it fails. Keep backups of the KDC's data and have backup hardware ready in case of failure. You might even want to maintain a slave or backup KDC, which pulls its configuration from the master KDC, so that the slave can take over KDC functions in case of a failure of the master KDC.
The hardware requirements of the KDC depend upon the size of your network, both in terms of the number of computers and the number of users. A KDC for a small network of a few dozen systems might require what is by today's standards a very low-end computerafter all, such a system would need to field only a few requests every hour . A system with a low-end Pentium CPU, 32MB of RAM, and a hard disk of a few hundred megabytes should be more than sufficient. A KDC for a network with hundreds or thousands of computers might require more computing power, particularly in terms of CPU power and network connectivity. In any event, you should ensure that the KDC is placed somewhere on your network topology that ensures maximum reliability and minimum data transit times. If your network is large enough and segmented in such a way as to make it likely that sections of it may become isolated from each other, you may want to place slave KDCs in each segment to minimize disruption in case of a break in network routing.
Kerberos Versions and Variants
The main Kerberos package is available from http://web.mit.edu/kerberos/www/. This site hosts Kerberos source code and binary releases for a few platforms, but not for Linux as of Kerberos V5 Release 1.2.1. You can also obtain the older Kerberos V4 from this official site and versions of the software for Windows and MacOS (both the older MacOS Classic and the newer MacOS X). All other things being equal, Kerberos V5 is superior to Kerberos V4; V5 adds a few features and fixes bugs in V4.
The Kerberos license is similar to that of X, and so various open source and commercial variants of the original MIT code have emerged. One of these is distributed by the Royal Institute of Technology in Sweden, and is available from their Web page, http://www.pdc.kth.se/kth-krb/. This variant is known as eBones, but package filenames typically begin with the string krb4 . The eBones Web site officially distributes only source code, but the FTP site includes a binaries subdirectory with some contributed binary packages, including directories for Linux. These may be out of date, though. Indeed, eBones itself is based on the Kerberos V4 release, at least as of eBones version 1.1.
The Center for Parallel Computers has developed a Kerberos implementation known as Heimdal, headquartered at http://www.pdc.kth.se/heimdal/. This variant is based on MIT's Kerberos V5. You can obtain both source code and compiled Linux executables from the Web site, including RPMs for Red Hat, although the binary versions may lag behind the latest (currently 0.4e).
Some Linux distributions now ship with Kerberos support. In particular, Debian 2.2 ships with both eBones and Heimdal, Mandrake 8.1 ships with Kerberos V5, Red Hat 7.2 ships with Kerberos V5, and SuSE 7.3 ships with Heimdal. Caldera 3.1, Slackware 8.0, and TurboLinux 7.0 do not ship with Kerberos support, but you can add packages by compiling the source, or possibly by installing a package intended for another distribution.