Kerberos: The Definitive Guide

Content preview·Buy reprint rights for this chapter

Who are you? It's a question with an obvious response, at least for people. Humans have the ability to distinguish one another through several senses; most commonly, we use our sense of vision to recognize people we have met before. We also can tell one another apart through other means, such as body language, speech patterns and accents, and shared secrets between people. It has even been shown that newborn babies can discern between their mother and other females solely through their scent. Our ability to recognize patterns in our surroundings provides us with this ability to determine the identity of, or authenticate , people we know.

However, when you bring a computer into the picture, the situation changes dramatically. Computers (at least today's computers) don't have eyes, ears, or noses. Even if they did, the current state-of-the-art in pattern recognition is still woefully inaccurate for widespread use. While there is a lot of research in this area, the most common method by far for authenticating people to computers is through passwords. A password, also known as a shared secret , is the one critical piece of information that determines whether the person behind the keyboard really is whom they claim to be. While humans sometimes use this shared secret method—for example, a secret handshake, or perhaps the knowledge of obscure trivia—computers almost exclusively use shared secrets to authenticate people.

There are two issues with passwords as used today for authentication. The first is a human problem. We don't like to remember a long, complex string of numbers, letters, and maybe even symbols that make up a secure password. If left to our own devices, we use simple dictionary words or maybe even our spouses' name or birthdate as passwords. Unfortunately, a "shared secret" that really isn't a secret (such as your spouse's name) is easily guessable by an attacker who wishes to impersonate you to the computer. This problem is exacerbated by the fact that, even within a company network, there are literally dozens of machines a person has access to, each of which requires its own password. As a general rule, as the number of passwords goes up, the quality of each password decreases.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The word Kerberos originates from Greek mythology, which contains the legend of Cerberus. Cerberus guarded the realm of the underworld, ruled by Hades and his wife, Persephone. What Cerberus looked like depends on whom you ask; Hesiod claims that Cerberus has fifty heads, while Apollodorus describes him as a strange mixture of creatures with three dog-shaped heads, a serpent as a tail, and heads of snakes over his back. Cerberus is most often pictured as a creature with three heads. Either way, Cerberus was a vicious creature that few dared to challenge.

The Greeks believed that when a person dies, his soul is sent to Hades to spend eternity. While all souls were sent to Hades, those people who had led a good life would be spared the eternal punishment that those who had not would have to endure. Cerberus, as the gatekeeper to Hades, ensured that only the souls of the dead entered Hades, and he ensured that souls could not escape once inside.

As the gatekeeper to Hades, Cerberus authenticated those who attempted to enter (to determine whether they were dead or alive) and used that authentication to determine whether to allow access or not. Just like the ancient Cerberus, the modern Kerberos authenticates those users who attempt to access network resources.

Like every other great figure in mythology, Cerberus had a fatal flaw that enabled some clever people to pass through Cerberus to Hades. We'll revisit the legend and discuss one such story and its modern counterparts in Chapter 6.

Finally, if the ancient mythological character was named Cerberus, why is the modern authentication system called Kerberos? Simply put, they are just different spellings of the same word. In order to provide a distinction between the ancient mythology and the present-day software system, we will refer to the mythological character as Cerberus and the modern software system as Kerberos.

The modern-day origins of the Kerberos network authentication system are a bit more mundane than the ancient mythology of Cerberus. Kerberos began as a research project at the Massachusetts Institute for Technology (MIT) in the early 1980s. The MIT faculty at the time recognized that the explosion of widely available, inexpensive computers would transform the computing industry.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The full definition of what Kerberos provides is a secure, single-sign-on, trusted, third-party mutual authentication service. What does that mean? Let's break that definition down into its parts and quickly describe each one.

Secure: Kerberos is securesince it never transmits passwords over the network in the clear. Kerberos is unique in its use of tickets , time-limited cryptographic messages that prove a user's identity to a given server without sending passwords over the network or caching passwords on the local user's hard disk.
Single-sign-on: Single-sign-on means that end users only need to log in once to access all network resources that support Kerberos. Once a user has authenticated to Kerberos at the start of her login session, her credentials are transparently passed to every other resource she accesses during the day.
Trusted third-party: Trusted third-party refers to the fact that Kerberos works through a centralized authentication server that all systems in the network inherently trust. All authentication requests are routed through the centralized Kerberos server.
Mutual authentication: Mutual authentication ensures that not only is the person behind the keyboard who he claims to be, but also proves that the server he is communicating with is who it claims to be. Mutual authentication protects the confidentiality of sensitive information by ensuring that the service the user is communicating with is genuine.

These three concepts describe the basis of the Kerberos network authentication service. We'll take a closer look at these concepts and the surrounding terminology in the following chapter.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The Kerberos system has several goals. It strives to improve security and convenience at the same time. First is the goal of centralizing authentication into one server (or set of servers). The Kerberos system operates through a set of centralized Key Distribution Centers , or KDCs. Each KDC on your network contains a database of usernames and passwords for both users and Kerberos-enabled services. Centralizing this information eases the burden on administrators, as they now only need to maintain this single username/password database. In addition, it provides an advantage to security administrators, who now only have a small set of machines on which usernames and passwords are stored, and can specially harden and protect these machines accordingly.

Kerberos provides a secure means of authentication over insecure networks. Instead of sending plain-text passwords over the network in the clear, Kerberos uses encrypted tickets to prove the identity of both end users and network servers. These tickets are generated by the centralized Key Distribution Centers on behalf of users who wish to authenticate to the network. When using Kerberos, user passwords are never sent over the network in the clear.

In addition, implementing the other two elements of the "three A's" (authorization and auditing—authentication, of course, is the third A) are made easier using Kerberos. While Kerberos does not directly provide authorization or auditing services, Kerberos' ability to accurately identify both users and services allows programmers and administrators to provide authorization and auditing to further enhance the security of their network. We'll talk more about what exactly authorization and auditing are in the next chapter.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The modern Kerberos protocol has gone through several major revisions since it was first conceived as part of Project Athena. During each revision, major improvements have been made in usability, extensibility, and security.

The early versions of Kerberos (pre-Version 4) were created and used internally at MIT for testing purposes. These implementations contained significant limitations and were only useful to examine new ideas and observe the practical issues that arose during development and testing.

The first version of Kerberos distributed outside of MIT was Kerberos 4. First released to the public on January 24, 1989, Kerberos 4 was adopted by several vendors, who included it in their operating systems. In addition, other, large distributed software projects such as the Andrew File System adopted the concepts behind Kerberos 4 for their own authentication mechanisms.

The basics of what was to become the Kerberos 4 protocol are documented in the Athena Technical Plan. Ultimately, the details of the protocol were documented through the source code in the reference implementation published by MIT.

However, due to export control restrictions on encryption software imposed by the U.S. government, Kerberos 4 could not be exported outside of the United States. Since Kerberos 4 uses DES encryption, organizations outside of the U.S. could not legally download the Kerberos 4 software as-is from MIT. In response, the MIT development team stripped all of the encryption code from Kerberos 4 to create a specialized, exportable version. Eric Young, at Bond University of Australia, took this stripped version of Kerberos 4 and added his own implementation of DES to create "eBones." Since eBones contained encryption software developed outside of the United States, it was unencumbered by the U.S. encryption export controls, and could be legally used anywhere in the world.

Today, several implementations of Kerberos 4 still exist. The original MIT Kerberos 4 implementation is now in a maintenance mode and officially considered "dead." The kth-krb distribution, developed in Sweden, is still actively developed but it is highly recommended that new installations use the superior Kerberos 5 instead. In this book, coverage of Kerberos 4 is restricted to a discussion of the protocol in Chapter 3. Most of the book covers the next version of Kerberos, Kerberos 5.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Many other products have been developed that either directly implement the Kerberos protocols or borrow concepts from Kerberos to implement similar authentication systems. We'll take a brief look at these alternative systems, and discuss the relationship between these systems and Kerberos.

The Distributed Computing Environment , or DCE, is a set of libraries and services that enable organizations to build cross-platform, integrated computing environments. It includes components that enable applications to communicate across a diverse set of platforms and securely locate and access information, whether it's in the same room on a local network or across the globe over the Internet. DCE provides many services to make this possible, including directory services, remote procedure calls, and time-synchronization. Most notable to our discussion, it provides a security service, which just happens to be based on Kerberos 5.

Work on DCE began in 1989, and was developed through a committee of vendors who have submitted various bits and pieces. The work was coordinated by The Open Group, an organization that is most widely known for the Motif widget set. Unfortunately, while the concepts that underlie DCE were revolutionary and ahead of their time, DCE was difficult to install and administer, and early versions were riddled with bugs. Today, DCE itself is not in wide use, but the concepts behind it have been integrated in most modern operating systems today, including Windows 2000 and above.

In 1997, The Open Group released the source code to the latest version of DCE, 1.2.2, to download for free from their web site. More information on DCE, including information on how to download Free DCE, can be found at http://www.opengroup.org/dce/.

The Globus Security Infrastructure is part of a larger project, the Globus Toolkit. The goal of the Globus Toolkit is to develop services that enable

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

In the previous chapter, we examined the ideas and history behind the Kerberos network authentication system. Now we'll begin to discover how Kerberos works. Instead of introducing these concepts as they're needed in the next chapter, I feel that it is easier to understand the nitty-gritty details of Kerberos when you have a working background in the surrounding terminology. To emphasize the importance of a solid understanding in these concepts, I have set aside this chapter to introduce you to the essential concepts and terminology that surround the use and administration of a Kerberos authentication system. While you may be familiar with some of these concepts, we're going to examine each one in turn and describe how it relates to Kerberos.

Kerberos is a complex system, with many parts. It requires the proper functioning of many separate software components, and with each comes a set of terms and concepts that underlie the entire system. A complete introduction to all of these concepts is critical to the understanding of the whole.

After all of these terms have been introduced, we'll finish off by putting all of the pieces together and set the stage for the detailed description of the Kerberos protocols in Chapter 3. For those who simply wish to implement a Kerberos realm and not worry about the low-level details of the protocol, this chapter will prepare you to skip directly to Chapter 4.

We'll start out our discussion with a topic that many network professionals deal with on a daily basis, the three As. Authentication, authorization, and auditing are a crucial part of any network security scheme, yet the distinction between them is often unclear. Each one of these components serves a separate, distinct purpose in a network security scheme. In particular, we will focus on authentication and authorization, and how they relate to each other.

Simply put, authentication is the process of verifying the identity of a particular user. To authenticate a user, the user is asked for information that would prove his identity. This information can fall into one or more of three categories: what he knows, what he has, or what he is. These categories are referred to as

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

We'll start out our discussion with a topic that many network professionals deal with on a daily basis, the three As. Authentication, authorization, and auditing are a crucial part of any network security scheme, yet the distinction between them is often unclear. Each one of these components serves a separate, distinct purpose in a network security scheme. In particular, we will focus on authentication and authorization, and how they relate to each other.

Simply put, authentication is the process of verifying the identity of a particular user. To authenticate a user, the user is asked for information that would prove his identity. This information can fall into one or more of three categories: what he knows, what he has, or what he is. These categories are referred to as factors .

The first factor, what he knows, is the most common factor used in authentication today. A secret password is generated when the user is granted access to a machine or network. That secret can either be generated by the user himself, by choosing his own password and giving it to the system administrator when he grants the user access, or automatically through some process that generates random passwords.

The second factor, what he has, is a less common but more secure alternative. An example of this type of authentication is the widely deployed RSA SecurID token. The SecurID token is a small electronic device that has an embedded encryption key and an LCD display. Every minute, an algorithm runs inside the device and updates the LCD display with a new six-digit combination. Only the person who possesses the device can tell what the correct password is. Other systems, such as smart card systems, operate on similar principles.

The third factor, what he is, enters into the realm of biometrics. Since all humans have distinguishing characteristics, biometrics measures the physical properties of some portion of our body and uses that information to authenticate users. Current biometric systems include fingerprint scanning, retina scanning, voiceprint recognition, and face recognition. Biometrics does not yet enjoy a wide market for several reasons: products are still immature for widespread use, some are very expensive (such as retina scanning), and, perhaps the most important reason of all, there is currently little software support for these devices.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

A common misconception surrounding Kerberos and other authentication technologies is that they somehow replace directories, such as the Unix /etc/passwd file, NIS, NetInfo, or LDAP. Along the same lines, another common misconception is that directories make good authentication systems by themselves. Therefore, a distinction needs to be made between authentication, authorization, and directories. For a real-life analogy of what roles each of these components play, see the sidebar Confusing Authentication, Authorization, and Directories.

Directories contain data describing resources, such as computers, printers, and user accounts that are contained within a particular network. Directories can be as simple as a text file, such as the /etc/passwd and /etc/group files on traditional Unix systems, which list the active user accounts and their group permissions. Or a directory can be a complex LDAP directory structure, such as Microsoft's Active Directory.

Directories can contain authentication data. Authenticating "against" a directory takes two forms: a client machine can contact a directory, obtain the hashed version of the user's password, hash the password given by the user, and compare the two. This method is used by NIS, for example. The other form, employed by most LDAP authentication mechanisms, is to attempt to bind to the LDAP directory using the credentials that the user provided. If the user is granted access to the directory, the authentication is successful. The pam_ldap PAM module uses this latter method to authenticate against an LDAP directory.

Using Kerberos to handle authentication is superior to these methods for several reasons:

Using Kerberos tickets, users can be granted single-sign-on access to all network resources without requiring the client machine to cache the user's password. Kerberos tickets are cryptographic messages that are only valid for a relatively short period of time, typically 8-24 hours. The compromise of a user's password, on the other hand, provides an attacker the ability to masquerade as the legitimate user for a much longer period of time—specifically, until the password is changed or expires.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Next, we'll review some concepts that are integral to keeping communications on computer networks secure. In particular, we will discuss the roles of encryption and message-integrity algorithms. The distinction between encryption and message-integrity is important, as we'll see later in the discussion of Kerberos encryption types. Those familiar with encryption and message integrity can skip to the next section, which describes the Kerberos-specific terminology.

The modern word cryptography is derived from two ancient Greek words, cryptos, which means hidden or secret, and graphein, or writing. Kerberos uses cryptography to provide encryption and decryption of its messages over the network. Therefore, encryption refers to the process of converting a message, or plaintext, into gibberish, which if intercepted, does not reveal the contents of the original message. Governments and corporations have long employed encryption to keep their information secure from prying eyes. The emergence of the Internet, where any network administrator can monitor and read traffic on her network and any traffic passing through her network, has forced software makers to build encryption into every day software programs. Kerberos uses encryption not only to protect the authentication exchanges it sends and receives from snoopers, but also to prevent hackers from creating fake messages.

There are many different ways of encrypting data. These methods are referred to as encryption algorithms, or in Kerberos-speak, encryption types. There are several different encryption types that are supported in Kerberos 5 implementations. The most widely supported encryption type is DES, but work is underway to replace it with Triple DES and the new Advanced Encryption Standard (AES). Another widely used encryption type is the RC4 algorithm, which is used primarily in Microsoft's implementation of Kerberos.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Now we'll begin to examine terminology that is specific to the Kerberos authentication system. There are many parts to Kerberos, and each has a name that will be defined here and used throughout the rest of the book. The descriptions that follow suffice for implementing a Kerberos realm, but the details of how these work are covered in the next chapter, where we will examine the protocols in detail.

Every entity contained within a Kerberos installation, including individual users, computers, and services running on servers, has a principal associated with it. Each principal is associated with a long-term key. This key can be, for example, a password or passphrase. Principals are globally unique names. To accomplish this, the principal is divided into a hierarchical structure.

Every principal starts with a username or service name. The username or service name is then followed by an optional instance. The instance is used in two situations: for service principals (which we'll discuss later), and in order to create special principals for administrative use. For example, administrators can have two principals: one for day-to-day usage, and another (an "admin" principal) to use only when the administrator needs elevated privileges.

The username and optional instance, taken together, form a unique identity within a given realm . Each Kerberos installation defines an administrative realm of control that is distinct from every other Kerberos installation. Kerberos defines this as the realm name . By convention, the Kerberos realm for a given DNS domain is the domain converted to uppercase. So, for example, Wedgie International, which owns the domain name wedgie.org, would create a Kerberos realm for its users named WEDGIE.ORG.

While it is the convention to make the realm name equivalent to the DNS domain name, it is not necessary to do so. It certainly makes configuration easier, as we'll see later on, but it is perfectly legal to have a realm name of, say, MYREALM.BOGUS when your domain name is

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Now that we've covered the basic topics that you'll need to understand Kerberos, let's begin to put all of these pieces together by examining the credential cache above.

Inside the credential cache, I have obtained an initial Ticket Granting Ticket through the Authentication Server (this is the first ticket out of three). By logging into this system, the system created this credential cache and obtained a TGT for me. During my log in session, I also logged into a host called cfs.wedgie.org, which has a Kerberized telnet daemon running on it. Because I was using Kerberos authentication, I was able to log into cfs without typing a password; instead, my telnet client obtained a service principal from the Ticket Granting Server, and used that ticket to contact the Kerberized telnet on cfs. Later, I did the same, except this time I logged into web.wedgie.org.

During this time, after logging in to three machines (including my initial authentication to Kerberos), I have only typed in my password once. The Kerberos software requested, generated, and sent tickets on my behalf as necessary to transparently authenticate me to the other machines as I accessed them. As a user, all of this happens behind the scenes. Now we'll peel back the curtain, and uncover the magic that occurs behind the scenes.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The previous two chapters introduced the major concepts that underlie the Kerberos authentication system, and presented a short, high-level discussion of how Kerberos performs its magic. This chapter continues that discussion by drilling down into the nitty-gritty of the Kerberos protocol and presenting it on a fundamental level.

Creating a protocol that verifies the identity of two endpoints on a network given an underlying network that provides no security is a daunting task. Kerberos was designed under the assumption that attackers can read, copy, and create network traffic at will.

As you now know, there are two versions of Kerberos that are currently in wide usage: Kerberos 4 and Kerberos 5. This chapter covers the protocol details of both. While the concepts and protocol design of both Kerberos 4 and 5 are very similar, there are major differences between their byte-level protocol and implementation.

The original Kerberos 4 protocol was never published apart from the Kerberos 4 source distribution. As such, the Kerberos 4 source code from MIT is the only official documentation of the Kerberos 4 protocol. On the other hand, the newer Kerberos 5 protocol is extensively documented in RFC 1510, and also through a series of documents that are collectively known as the Kerberos Clarifications.

The basic operation of Kerberos is based on a paper published in 1978 by Needham and Schroeder. Since the Needham-Schroeder protocol is the basis upon which Kerberos is built, we will begin our discussion there.

Roger Needham and Michael Schroeder of the Xerox Palo Alto Research Center published a paper in December of 1978 describing their framework for designing a secure network authentication system. The paper, entitled "Using Encryption for Authentication in Large Networks of Computers," described two different protocols that could be implemented to provide a reliable, secure authentication service for a distributed network of computers. The first protocol described in the paper uses private key encryption, and it is this protocol that forms the basis of the Kerberos network authentication protocol.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Roger Needham and Michael Schroeder of the Xerox Palo Alto Research Center published a paper in December of 1978 describing their framework for designing a secure network authentication system. The paper, entitled "Using Encryption for Authentication in Large Networks of Computers," described two different protocols that could be implemented to provide a reliable, secure authentication service for a distributed network of computers. The first protocol described in the paper uses private key encryption, and it is this protocol that forms the basis of the Kerberos network authentication protocol.

Needham and Schroeder outlined several assumptions around which they designed their protocol. One assumption, the ability for a malicious attacker to capture packets in-transit on the network, modify them, and send packets of his own design, was described by the authors as an "extreme view," yet now is regarded as a routine requirement for any secure network protocol. Designing a protocol that is resistant to these types of attacks is difficult, and I'll point out the specific design decisions that were made to thwart them as I discuss the protocol.

Other assumptions made by the authors, however, did not hold up as well in practice as they did on paper. The assumption that users' secret keys are not readily available through an exhaustive search has not held up in the hostile environments in which Kerberos operates. No matter how much education you provide users, users will continue to choose poor passwords. The Needham-Schroeder protocol, and consequently the basic Kerberos protocol, provides no protection against an offline brute force or dictionary attack against a user's secret key, as we'll see in Chapter 6.

The Needham-Schroeder protocol defines three participants in the protocol exchange: a client machine, a server that the client wishes to access, and an authentication server. The client is any machine that requests authentication; usually, it's a user's personal desktop. The server is any application server, say a mail server, which provides a service the client wishes to contact. Finally, the authentication server is a dedicated server that holds a copy of the encryption keys for all users and servers on the network (the "trusted third-party"). This should sound familiar; these are the same three players involved with the Kerberos protocol.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The Kerberos 4 protocol is largely based on the Needham-Schroeder protocol, with two major changes.

The hosts involved in the Kerberos 4 protocol exchanges map directly to the principals involved in the Needham-Schroeder protocol. The authentication client is a Kerberos 4 user workstation, and the authentication server maps to a Kerberos 4 Key Distribution Center.

The first change to the Needham-Schroeder protocol reduced the amount of network messages sent between the client and the authentication server. The original Needham-Schroeder protocol did not have a dependence on a network time source, but the cost was an extra two message exchanges. The last two message exchanges in the Needham-Schroeder protocol establish that there is no man in the middle posing as the authentication server, and that the session key is not a replay. In the Kerberos 4 protocol, replay is thwarted through an authenticator message that is constructed of the local time of the client encrypted with the newly-negotiated session key of the connection. While this requires time synchronization between all hosts involved, it does reduce the number of network messages required per authentication exchange.

The second, more significant, change to the basic protocol creates the concept of a Ticket Granting Ticket, which allows users to authenticate to multiple application servers while entering their authentication secret only once. If the original Needham-Schroeder protocol were implemented as-is, a user would need to enter her password every time that she wishes to log into an application server. One of the major design goals for Kerberos was to create a single-sign-on system in which users only need to enter their credentials once per day, and all future authentication requests are handled transparently, without user intervention.

As a result, the Kerberos 4 protocol is split into two logical components: the Authentication Server and the Ticket Granting Server. Note that there is an unfortunate clash in terminology here. The Kerberos Authentication Server should not be confused with the Needham-Schroeder authentication server; the former performs a subset of the services of the latter, as we'll see in a bit. To keep the distinction clear, references to the Kerberos Authentication Server and Ticket Granting Server will be capitalized or abbreviated as AS or TGS, respectively. While these components are usually implemented as a single program that runs on the KDC, they are logically separate processes.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

If you look strictly at the feature set, Kerberos 5 is an evolution of Kerberos 4. The Kerberos 5 protocol contains all of the functionality present in the Kerberos 4 protocol, but with many extensions. However, from an implementation perspective, Kerberos 5 is a completely new protocol, and looks nothing like Kerberos 4 on the inside. In this section, we'll examine the new features present in Kerberos 5 as well as the new infrastructure provided by the protocol to make these features work.

The Kerberos 4 protocol had its share of shortcomings: it had a rather obtuse structure (for example, instead of standardizing on one byte order, it had a flag to specify which byte order was used to send a particular message) and it wasn't expandable, since many of its fields had fixed sizes. This limitation led to other problems, most notably the dependence on single-DES encryption keys. At the time that Kerberos 4 was developed, a brute-force attack against DES was still prohibitively expensive in terms of both resources and time. As computer speed continues to grow exponentially, it is now within the realm of well-funded adversaries to mount a brute-force attack against DES. Therefore, a more secure encryption algorithm with a longer encryption key size is needed. Unfortunately, since all of the fields in Kerberos 4 are fixed size, there is no way to retrofit Kerberos 4 with another encryption algorithm.

Another feature that users and administrators alike demanded from a new version of Kerberos was support for credential forwarding and delegation. Credential forwarding enables users to transfer their tickets to a remote server once they are authenticated to it. For example, take a user who has just logged in remotely to an application server via Kerberized telnet. Using Kerberos 4, if the user wishes to authenticate to, say, a file server, from the application server, she's essentially stuck. She must re-login to Kerberos from the remote server through kinit to acquire a new Ticket Granting Ticket on the remote server. This introduces security problems, since in order to re-authenticate to Kerberos, the user must retype her password, which in the case of telnet, is probably being sent in clear text over the network. In addition, the system no longer provides single-sign-on.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Finally, there are several protocols that, while strictly speaking are not directly related to Kerberos, will be encountered when implementing a Kerberos authentication system.

The Generic Security Services API, as the name implies, is not specific to any authentication technique. Therefore, its mention in a book on Kerberos may seem a bit out of place. However, GSSAPI is widely used by protocol implementers as a means to implement Kerberos 5 support in their applications. By using GSSAPI, a protocol gains the ability to use other strong authentication methods "for free," and the GSSAPI layer also shields implementers from the complexities of the raw Kerberos 5 API.

GSSAPI is geared toward developers of client/server applications who wish to add strong authentication support to their protocols. It provides a generic interface and message format that can encapsulate authentication exchanges from any authentication method that has a GSSAPI-compliant library. GSSAPI insulates application programmers from the specific programming interface for particular authentication methods. GSSAPI also provides a standard message format so that protocols can support many different authentication methods without changing the protocol itself. GSSAPI does not define a protocol, authentication, or security mechanism itself; it instead makes it easier for application programmers to support multiple authentication mechanisms by providing a uniform, generic API for security services.

Most Kerberos 5 implementations also include a GSSAPI library. This means that all applications that support GSSAPI also support Kerberos 5. The notable exception is the Windows Kerberos implementation, which does not include GSSAPI support but instead includes a Microsoft-specific API, the Security Support Provider Interface (SSPI). SSPI is not API-compatible with GSSAPI; that is, programs written for GSSAPI will not compile with SSPI. Instead, applications written for SSPI can be made to be wire-compatible with GSSAPI applications. Therefore, an SSPI client can communicate with a GSSAPI server. Microsoft provides some example code that demonstrates how to achieve this network message-level interoperability.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The previous chapters discussed the concepts and theory that form the basis of the Kerberos authentication system. Now, armed with a solid background, we're ready to tackle the actual implementation of a Kerberos authentication system from start to finish. This chapter prepares you to install the Kerberos KDCs in your network and also the Kerberos libraries on servers and client machines. We will continue the process in Chapter 7 by detailing installation processes for Kerberized application software.

We'll begin by outlining the steps for establishing a Kerberos realm. During this chapter, we'll follow these steps to create a sample Kerberos realm:

Plan your installation.
Install the KDC software.
Establish the Kerberos realm and create an administrative user principal.
Add user principals to your realm.
Install Kerberized server software, and install service principals for the server software as necessary.

Your Kerberos implementation will be an important part of your network. As such, the Kerberos service needs to be always available, responsive, and in the event of failure, easily restored from backup. Therefore, integrating Kerberos authentication into your network calls for some planning.

The first consideration is what exactly you'll be using Kerberos for. The answer to this question depends on whether you'll need compatibility with Kerberos 4 clients/services or not. We'll handle the simple case where you have no need to service Kerberos 4 clients or services first.

In this case, you'll be able to implement a Kerberos 5-based solution with no need for backwards compatibility with Kerberos 4-based systems. All of the KDCs we'll cover here will be able to handle Kerberos 5 clients, and there will be no need to enable any optional Kerberos 4 compatibility.

On the other hand, if you have to support Kerberos 4 services or clients, you'll need to plan a bit more carefully to integrate those legacy components into your Kerberos implementation. Typically, in this situation, you'll want to stick with a Unix-based KDC, since these have built-in support for the older Kerberos 4 protocol.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

We'll begin by outlining the steps for establishing a Kerberos realm. During this chapter, we'll follow these steps to create a sample Kerberos realm:

Plan your installation.
Install the KDC software.
Establish the Kerberos realm and create an administrative user principal.
Add user principals to your realm.
Install Kerberized server software, and install service principals for the server software as necessary.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Your Kerberos implementation will be an important part of your network. As such, the Kerberos service needs to be always available, responsive, and in the event of failure, easily restored from backup. Therefore, integrating Kerberos authentication into your network calls for some planning.

The first consideration is what exactly you'll be using Kerberos for. The answer to this question depends on whether you'll need compatibility with Kerberos 4 clients/services or not. We'll handle the simple case where you have no need to service Kerberos 4 clients or services first.

In this case, you'll be able to implement a Kerberos 5-based solution with no need for backwards compatibility with Kerberos 4-based systems. All of the KDCs we'll cover here will be able to handle Kerberos 5 clients, and there will be no need to enable any optional Kerberos 4 compatibility.

On the other hand, if you have to support Kerberos 4 services or clients, you'll need to plan a bit more carefully to integrate those legacy components into your Kerberos implementation. Typically, in this situation, you'll want to stick with a Unix-based KDC, since these have built-in support for the older Kerberos 4 protocol.

Your only option when dealing with Kerberos 4 client machines (machines which will be authenticating end users) is to use a KDC with direct support for Kerberos 4. This limits you to Unix-based KDCs. However, if you are supporting a Kerberos 4-based service (such as AFS), you can get away with a mixture of a Windows domain controller (or another KDC that supports only Kerberos 5 directly) and a machine that is running the Kerberos 5-to-4 ticket translator daemon (known as krb524) that is included with both MIT and Heimdal. We'll talk about this option in more detail in Chapter 8.

You'll want to determine the number of KDCs you'll deploy in your network. Since authentication requests to the KDC can be easily handled with today's overpowered processors, a single or dual processor machine should suffice for thousands of clients. Note that this applies to Unix-based system running only a KDC; Windows domain controllers function as much more than just a Kerberos KDC and therefore may have a higher server-to-client ratio than a dedicated Unix KDC. I won't go into detail about Active Directory planning here; readers interested in more detailed discussion about Active Directory should refer to

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Kerberos requires the proper functioning of several external services. Notably, the clocks on all machines participating in your realm must be synchronized to within a few minutes, and a working DNS domain should be established with forward and reverse mappings to at least the Kerberos KDC and application servers you intend to Kerberize.

First, NTP (the Network Time Protocol, official home page at http://www.ntp.org/ ) should be installed on every server and KDC in your network. NTP will synchronize the clocks of these machines to a central source, which can be either a local time source (such as a GPS unit receiving time signals from the GPS satellites, or a Cesium time source, if you happen to have an atomic clock available at your site) or a remote Internet-accessible time server. While it is possible to set up all of your machines to synchronize over the network to an external, publicly available time server, site administrators are strongly encouraged to set up a centralized time source for their network, and set up other machines on the network to synchronize to that server. The time server machine can then synchronize to an accurate time source, such as a public time server.

The details of setting up NTP are beyond the scope of this book, and online references and software are readily available from the above URL. Clients will need to be synchronized also, but hand synchronization is sufficient unless you have enough control over the client systems to install NTP on them as well. While Kerberos does require synchronized clocks, Kerberos implementations typically provide for a plus-or-minus five-minute error when comparing times. Even with this built in time slack, poorly synchronized clocks are the root of many problems that are encountered when using Kerberos. Therefore, investing time up front to ensure accurate clocks on all machines on your network is time well spent.

Windows machines that are part of an Active Directory domain automatically synchronize their clocks to the domain controller's clock through the Windows Time Service. Unix systems typically do not have NTP installed and configured out of the box, so manual configuration is required to keep these systems' clocks in sync.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

With the boring planning out of the way, we're ready to get down to the nitty-gritty of installing a KDC. We'll cover each implementation in turn, and I'll take you through building the software, all the way to setting up test users and distributing the Kerberos database among a network of slave KDCs.

This section covers the topics required to set up the KDC software. It does not cover related topics, such as security of the underlying operating system; these security-related topics can be found in Chapter 6.

Since the MIT Kerberos distribution is available as open source, there are two ways to install it: building it from source, or obtaining a binary distribution from your Unix vendor. As for Linux, many of the popular Linux distributions have pre-built binary packages of MIT Kerberos 5.

We'll cover building MIT Kerberos from source for several reasons. One, many people feel more comfortable building security-sensitive applications directly from source. Also, some Unix distributions do not offer a pre-built MIT Kerberos distribution. Finally, by building from scratch, we can establish a common path structure and feature set that's independent of any tweaks individual vendors have decided to include in their pre-built versions. If you prefer to install from pre-built packages, such as RedHat RPMS, feel free to skip over this section and continue on to the next section, Section 4.4.1.2.

The MIT distribution is available for users in the U.S. and Canada at the MIT Kerberos home page, located at http://web.mit.edu/network/kerberos-form.html. Users in other countries should visit the Cryptography Publishing Project's MIT Kerberos download page at http://www.crypto-publish.org/mit-kerberos5/index.html. The MIT Kerberos 5 source distribution is available at both sites, and the source code tarball available at both are bit-by-bit identical.

The source code distribution is signed with the PGP key of Tom Yu, a member of the MIT Kerberos development team. It is recommended that you verify the distribution you've downloaded against this signature, to ensure that the file has not been tampered with. If you obtained the source distribution from MIT, the signature is located within the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

A properly functioning DNS server for your domain and functioning DNS resolvers on machines participating in your Kerberos realm is essential for the proper operation of your realm.

Traditional Unix Kerberos 5 implementations use the flat file /etc/krb5.conf file for hostname-to-Kerberos realm mapping, much like /etc/hosts can be used for name-to-IP mapping. The Kerberos configuration file contains two major pieces of information: the DNS domain name to Kerberos realm mappings, and a list of KDCs for each Kerberos realm. Obviously, this method does not scale, so just as DNS now serves the purpose of the old /etc/hosts file, DNS can also be used to provide Kerberos configuration.

Kerberos can use DNS as a service location protocol, by using the DNS SRV record as defined in RFC 2052. In addition, Kerberos can use a TXT record to locate the appropriate realm for a given host or domain name. These DNS entries are not required to run a Kerberos realm, but they do eliminate the need for manual configuration of clients. With these DNS records, Kerberos clients can find the appropriate KDCs without the use of a configuration file. Windows will establish the necessary SRV records automatically when an Active Directory domain is created. Those using Unix for their KDCs can create these DNS entries manually in their zone files as a convenience to clients.

Note that while Windows will use DNS to locate KDCs, it will not use DNS to locate any KDCs for any non-Windows Kerberos realms. Configuration information for non-Windows Kerberos realms must be entered manually using the ksetup tool. More information on this tool and enabling interoperability between Windows and other Kerberos implementations can be found in Chapter 8.

In order to use KDC discovery over DNS, the following records should be placed in the zone file corresponding to the Kerberos realm. In most cases, since the Kerberos realm name is simply an uppercase version of the DNS domain owned by the organization, these DNS entries are placed into the organization's existing DNS zone file. However, if the Kerberos realm and DNS domain differ, then a new zone must be created with the name of the Kerberos realm.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Before a client machine or Kerberized application server can use Kerberos authentication, it must have the proper libraries, configuration files, and in some cases, service and host principals added to a local keytab file. We will limit the discussion (for now) to using the same Kerberos implementation both on the KDC and the clients. Most of the setup information below can be used to interface with a different vendor's KDC, but we will take a closer look at interoperability later in Chapter 8.

There are three major steps to setting up a Unix-based Kerberos client or Kerberized application server: compiling the distribution, installing configuration files, and creating host and service principals if necessary. The first step, compiling the distribution, has already been discussed in the "Building the distribution" sections (under the appropriate heading for your chosen Kerberos implementation); follow the directions to build and install the client libraries.

Next, we'll create configuration files on each of the clients. Both MIT and Heimdal use a configuration file located in /etc/krb5.conf. This configuration file contains the name and addresses of all KDCs that the client can communicate with. Alternatively, this information can be placed in DNS, as discussed in Section 4.5. Since most Kerberos installations are still using configuration files, we'll discuss them.

We saw a simple krb5.conf file earlier, when we set up the MIT KDC above. That template still applies for clients, and in fact, the /etc/krb5.conf configuration file can be copied straight from the KDC to all of the clients. If you want to tweak the configuration file anyway, there are three stanzas that are important for client configuration: libdefaults, realms, and domain_realm.

Let's start with a sample configuration file. It should look familiar; it is the same one presented in the KDC installation section (Section 4.4):

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Working with Kerberos can seem like an exercise in futility. The combination of complex software, interoperation between Kerberos implementations and diverse operating systems, and terse (at best) error messages tend to bring premature balding to the administrators responsible for the smooth operation of their systems. However, working with Kerberos does not have to be this frustrating.

To provide a systematic approach to solving problems in Kerberos, this chapter begins with a discussion of the various debugging tools and techniques, including a sample decision tree to follow when facing a new problem. Becoming familiar with these tools and techniques before disaster strikes will be helpful when the inevitable problem occurs. The second section will use those tools and techniques to diagnose some typical problems that occur in a Kerberos system. It will describe the symptoms of these common problems and then show possible solutions to solve them.

So you're having a problem with your Kerberos installation. The first step to solving this problem, like debugging any other issue, is to narrow down the root cause. We'll determine if the problem falls into three distinct categories, and continue our analysis from there.

An easy way to categorize an error involving Kerberos authentication is through what tickets the client can acquire for a service. Let's look at the three top-level categories:

Client can't get an initial Ticket Granting Ticket. This is most likely a client-specific problem, especially if logging in with the user principal and password works on other clients. Of course, it could also mean that the password entered for the user principal is incorrect.
The most likely culprits include time-synchronization problems and issues reaching the Kerberos server due to misconfiguration of the client. It is also possible that the client does not share a compatible encryption type for the users' secret key with the KDC. This can happen, for example, when attempting to interoperate between a Unix client and a Windows domain controller. By default, Windows domain controllers create user entries with an RC4-HMAC encryption type, which most Unix Kerberos implementations do not understand. Newer versions of Heimdal and MIT Kerberos 5 will support this encryption type.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

So you're having a problem with your Kerberos installation. The first step to solving this problem, like debugging any other issue, is to narrow down the root cause. We'll determine if the problem falls into three distinct categories, and continue our analysis from there.

An easy way to categorize an error involving Kerberos authentication is through what tickets the client can acquire for a service. Let's look at the three top-level categories:

Client can't get an initial Ticket Granting Ticket. This is most likely a client-specific problem, especially if logging in with the user principal and password works on other clients. Of course, it could also mean that the password entered for the user principal is incorrect.
The most likely culprits include time-synchronization problems and issues reaching the Kerberos server due to misconfiguration of the client. It is also possible that the client does not share a compatible encryption type for the users' secret key with the KDC. This can happen, for example, when attempting to interoperate between a Unix client and a Windows domain controller. By default, Windows domain controllers create user entries with an RC4-HMAC encryption type, which most Unix Kerberos implementations do not understand. Newer versions of Heimdal and MIT Kerberos 5 will support this encryption type.
Client has valid TGT but gets error before a service ticket is acquired. Once again, this is most likely a problem with the client. The usual suspects in this scenario include Kerberos misconfiguration on the client, which we'll cover in a subsequent section.
Another possibility is that the service principal that the client requested simply does not exist. Examining the KDC log files is a good way to determine if the client is reaching the KDC, and if so, if it is attempting to acquire tickets for a principal that does not exist, or is in a different realm.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The MIT Kerberos distribution includes a small sample Kerberized client/server application. These example applications are located in the src/appl/sample subdirectory of the MIT Kerberos 5 distribution.

Just like any other Kerberized server, the sample server requires a service principal and access to the secret key associated with that principal through a keytab file. By default, the sample server uses a principal name of "sample," with an instance of the hostname that it is running on. If you're having trouble with a particular service principal, the sample server and client can use any principal name to communicate with each other, given the sample server has read access to the service's keytab file.

The command-line arguments accepted by the sample server are:

> ./sserver -h
usage: ./sserver [-p port] [-s service] [-S keytab]

The -p argument specifies what TCP port that the server will listen on for client requests. If this argument isn't specified, then sserver will immediately exit. The -s option can be used to specify a particular service principal (instead of the default, "sample"). For example, the host principal can be specified by

-s
      host

. Finally, the -S option specifies a keytab file in which the server can find the secret key for the service principal. By default, sserver will use /etc/krb5.keytab.

Ensure that a valid keytab entry for the principal you're using to test exists in a keytab file and is readable by the user you're starting sserver as. Note that the server won't test for the readability of the keytab until a client connects to it, and your client will report "Permission denied".

The command-line arguments that the client accepts are similar:

> ./sclient 
usage: ./sclient <hostname> [port] [service]

A successful exchange looks like the following, assuming that you have shells open on both of the hosts freebsd and slave, and their prompts are freebsd> and slave> respectively:

freebsd> ./sserver -p 8888 -s sample -S /tmp/sample.keytab
slave> ./sclient freebsd 8888 sample
sendauth succeeded, reply is:
reply len 27, contents:
You are jgarman@WEDGIE.ORG

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

With the debugging tools presented above, we'll run through a few problem scenarios, from the initial symptoms of a problem through to its solution.

Several errors can occur when attempting to obtain an initial Ticket Granting Ticket from a Kerberos KDC. Since there are many ways to obtain a TGT, such as through integrated login with a PAM Kerberos module, the best way to narrow down problems is by using the Unix kinit program manually. This will work even if your KDC is a Windows domain controller, given that the principal you're testing has been set up for DES encryption (see Chapter 8).

Let's go through a few examples:

> kinit
Password for jgarman@WEDGIE.ORG:
kinit(v5): Preauthentication failed while

Table of Contents