Understanding Kerberos Operation

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 [e-mail] and fluffy/[e-mail] .

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:

• Provide network authentication Servers must be able to authenticate the identities of users attempting to use their services to prevent unauthorized access to servers. As important in many environments, but less obvious, the clients must be able to verify the identifies of the servers they use to prevent one system from pretending to be a server and thus intercepting print jobs, e-mail, or other potentially sensitive data. This is Kerberos's raison d'etre.

• Protect passwords Many services, as described in various chapters of this book, use unencrypted passwords by default. This is a security liability, because these passwords can be intercepted, thus compromising the network's security. Some protocols encrypt passwords to avoid this problem, but Kerberos uses an unusual approach: Rather than send passwords in an encrypted form, it uses the password as an encryption key for transmitting data required for Kerberos's operation. Thus, the password isn't transmitted, but only a user with the correct password can use the data.

• Allow single-login operation Kerberos allows users to enter passwords once, when they log in to their computers. Subsequent transfers using Kerberized applications don't require password entry. For instance, you need not reenter your password when you retrieve e-mail using a Kerberized pull mail server or log in to another computer using a Kerberized remote login server. (Of course, if you access a system outside of your local Kerberos network, this benefit won't extend to the remote systems.) The tickets you get when you enter a password are time-limited, though, so you may need to periodically reenter your password if you use the system for a long time. You won't need to reenter the password when you use new servers or reuse old ones within the lifetime of the tickets.

NOTE

Many applications that use passwords to access remote servers provide the user with the option of saving the password. This is common in pull mail clients, for instance. (Chapter 11, Pull Mail Protocols: POP and IMAP, covers these protocols.) When a password is saved in this way, the user doesn't need to reenter it; however, saving the password to disk is a security risk in the event of a break-in of the workstation. Furthermore, if the user changes a password, it may have to be changed in several programs, which can be a nuisance. Kerberos eliminates both problems.

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:

1. A user at a workstation wants to use a service, and so enters a username and password.

2. The workstation (a Kerberos client) sends the username to the KDC with a request to obtain a ticket-granting ticket (TGT). This request is processed by a particular Kerberos subset known as the ticket-granting service (TGS).

3. The KDC checks for the username in its database. If the username is present, the KDC responds with a TGT. This ticket includes information such as the username for which the TGT is useful, the time the TGT was issued, and the time span over which the TGT is valid. The KDC uses the password in the username database to encrypt the TGT, and sends it back to the client.

4. The client receives the TGT, and attempts to decrypt the TGT with the password the user entered. If this process is successful, the client holds onto the ticket, transparent to the user.

5. The client sends a request to obtain a ticket for a specific server to the KDC, using data extracted from the TGT. The KDC recognizes this data as valid (because it's been successfully decrypted and then reencrypted) and replies by sending a ticket for the server. This ticket is encrypted with the target server's password (which is known only to the server and the KDC), and includes information such as the username of the person making the request, the name of the service being requested , a time stamp, a time period for which the ticket is valid, and a session key, which is another password created by the KDC and shared with the server and client. This ticket's lifetime is short to reduce the risk of its being intercepted and abused.

6. The client receives the service ticket, which it holds, transparent to the user. (The client doesn't attempt to decrypt this ticket.)

7. The client sends the service ticket to the server in question, requesting a data transfer session.

8. The server decrypts the ticket with its password; this will work properly if and only if the ticket was properly encrypted by the KDC. If the request is in order (it decrypted properly, it's from a valid user, and so on), the server uses the session key to encrypt a reply to the client.

9. The client receives the server's reply. If and only if this reply is valid, the client can assume that the server is authentic , so the client completes the connection and begins its data transfer only if it receives the correct reply from the server.

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.

WARNING

The preceding procedure uses time stamps in several exchanges. If computers' clocks are set to different times, these time stamps may cause a transaction to fail, or may reduce the security on the network. It's therefore extremely important that all computers on a Kerberos network be set to the same time. You can accomplish this goal by running a Network Time Protocol (NTP) server on all computers, as described in Chapter 10, Maintaining Consistent Time: Time Servers.

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.

NOTE

Subsequent sections of this chapter describe MIT's Kerberos V5. Kerberos V4 differs in some important configuration details, and even V5 derivatives like Heimdal may not work precisely as described here. In writing this chapter, I used both Red Hat's Kerberos V5 packages and builds of the original MIT source code as references.