2.4 Kerberos Terminology and Concepts

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.

2.4.1 Realms, Principals, and Instances

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 wedgie.org. Also note that realms are case-sensitive (unlike domain names), so the realm MyRealm.BOGUS is different from MYREALM.BOGUS.

Now let's examine a Kerberos principal that has been assigned to John Doe, who works in the IT department of Wedgie International:

jdoe@IT.WEDGIE.ORG

This is the simplest form a principal can take, and is a valid principal under both Kerberos 4 and Kerberos 5. This principal represents the username jdoe, with no instance, and a realm of IT.WEDGIE.ORG.

2.4.1.1 Service and host principals

Users aren't the only ones assigned principals in a Kerberos realm; hosts and servers offering Kerberos services also have principals. Since, in Kerberos, each endpoint of a connection can request mutual authentication, both endpoints require an identity and a key. Therefore, every service and host that a user can connect to through Kerberos authentication requires a service principal.

Services principals are slightly different than user principals. The username component in a service principal is the name of the service that the principal represents. In the case of a host principal, the username is "host." To distinguish service principals for the same service but on different hostnames, the instance component contains the hostname of the machine the service principal is located on. Services that use Kerberos authentication are said to be Kerberized.

In addition to host and service principals, the Kerberos system itself contains several principals. The most important of these "special" principals is the krbtgt principal. We'll see examples of service and host principals in the next two sections, which discuss what Kerberos 4 and 5 principals look like. While the syntax is similar, there are some notable differences. We'll take a look at the Kerberos 4 principal format first.

2.4.1.2 Kerberos 4 principals

Kerberos 4 principals are made up of three components: the username, an optional instance, and the realm. The username and instance are separated by a period, and the username and instance are separated from the realm by an at symbol (@). Let's take a look at an example Kerberos 4 principal:

jdoe.admin@IT.WEDGIE.ORG

This example is similar to the one above, with the exception that this principal contains an instance—in this case, admin.

Kerberos 4 service principals contain only the hostname of the server the principal is assigned to. There is no domain component, since the separator for domain names is the same as the separator between username and instance (the dot). So an example host principal for the host unixsvr.it.doesystems.com in the IT.WEDGIE.ORG realm would be:

host.unixsvr@IT.WEDGIE.ORG

This is one of the shortfalls of Kerberos 4, as it dictates that you cannot have more than one machine with the same hostname in your realm, even if they have different domain names. A hostname of unixsvr.it.wedgie.org that is also a member of the IT.WEDGIE.ORG Kerberos realm would map to the same service principal as the example hostname above, unixsvr.it.doesystems.com.

In general, the forms that a Kerberos 4 principal can take are:

user[.instance]@REALM
service.hostanem@REALM

2.4.1.3 Kerberos 5 principals

Kerberos 5 principals contain the same basic components as a Kerberos 4 principal. Instead of a single instance component, however, Kerberos 5 principals can contain several sub-instance components. Also, instead of using a dot to separate the username and instance components, Kerberos 5 uses a forward slash.

Let's take a look at an example Kerberos 5 user principal:

jdoe/admin@IT.WEDGIE.ORG

This example is equivalent to the first Kerberos 4 example, showing the format of John Doe's principal with an admin instance.

Kerberos 5 host and service principals include the fully qualified domain name (FQDN) of the host that the service is installed on. By embedding the FQDN in the principal, Kerberos 5 allows administrators to have more than one host with the same hostname, but with different domain components located in the same realm. Here is an example of a Kerberos 5 host principal:

host/unixsvr.it.wedgie.org@IT.WEDGIE.ORG

Generically, Kerberos 5 principals have the following format:

component[/component][/component]...@REALM

In this format, there is one required component, followed by any number of optional components, separated by forward slashes. Following the components is the realm name, which is separated from the components with an at sign (@), just as in Kerberos 4. Practically speaking, there are two types of Kerberos 5 principals that you'll see in use, just as in Kerberos 4, shown below:

username[/instance]@REALM
service/fully-qualified-domain-name@REALM

2.4.2 Keys, Salts, and Passwords

Many different terms are used to discuss encryption in Kerberos. They are all related to each other, but there are a few important Kerberos-specific concepts that require discussion.

First, all secret keys are shared between at least two parties, the end user or service and the Key Distribution Center. However, a method is needed to change an alphanumeric password that people can remember into a binary encryption key that the computer can use to encrypt and decrypt messages. A function called string2key is used to convert a user's password into an encryption key. This function applies several transformations to each user's password to turn a character-based password into a series of numbers that make up an encryption key.

The most important part of this transformation is known as the salt. Generally speaking, salt is a sequence of characters that is added to a password before hashing it to make it more unique. For Kerberos 5, the default salt is the realm name. By adding the realm name to the username, two different encryption keys are generated if a user uses the same password in two different realms. This means that if a user uses the same password in two realms, and his key is compromised in one of them, it does not automatically compromise his key in the other.

2.4.3 The Key Distribution Center

The Kerberos Key Distribution Center, or KDC for short, is an integral part of the Kerberos system. The KDC consists of three logical components: a database of all principals and their associated encryption keys, the Authentication Server, and the Ticket Granting Server. While each of these components are logically separate, they are usually implemented in a single program and run together in a single process space.

In a given Kerberos realm, there must be at least one KDC. While the resources required to run a KDC on a machine are small, it is strongly recommended that each KDC be a separate physical machine. Since all of the crucial data, including the secrets for every principal in your realm, is located on every KDC in the network, it is critical that those servers be as secure as possible. In addition, in order for users to successfully authenticate to Kerberos-enabled services, at least one KDC must be functioning at all times.

Each Key Distribution Center contains a database of all of the principals contained in the realm, as well as their associated secrets. Most KDC software also stores additional information for each principal in this database, such as password lifetimes, last password change, and more. Windows 2000 and 2003 keep this database in the Active Directory, its LDAP store. Open source implementations, including MIT and Heimdal, keep this database in a specialized, lightweight database file on the KDC's filesystem.

Since a Kerberos realm can contain multiple KDC machines, the database on each KDC must be kept in synchronization to ensure unified authentication. If a server has stale data, then legitimate attempts to authenticate against that server may fail, since it does not have an up-to-date copy of the Kerberos database. No standard method of synchronization is specified by the Kerberos protocol, so vendors have created their own replication protocols.

2.4.3.1 The Authentication Server

The Authentication Server (AS) issues an encrypted Ticket Granting Ticket (also known as a TGT) to clients who wish to "log in" to the Kerberos realm. The client does not have to prove its identity to the KDC; instead, the TGT that is sent back to the client is encrypted in the user's password. Since only the user and the KDC know the user's password, when the login process attempts to decrypt the ticket using the password supplied by the user, only the correct password will correctly decrypt the ticket. If an incorrect password is used, the ticket will decrypt into garbage, and the user is prompted to try again.

The TGT returned by the Authentication Server can then be used, once decrypted by the client, to request individual service tickets. The TGT is the crucial piece that eliminates the requirement for a user to retype their password for each subsequent service they contact.

2.4.3.2 The Ticket Granting Server

Not to be confused with the Ticket Granting Ticket that we briefly discussed in the last section, the Ticket Granting Server (TGS) issues individual service tickets to clients as they request them. The Ticket Granting Server takes in two pieces of data from the client: a ticket request that includes the principal name representing the service the client wishes to contact, and a Ticket Granting Ticket that has been issued by the Authentication Server. The TGS verifies the TGT is valid by checking to ensure that it is encrypted with the Kerberos server's TGT key, and then issues the user the service ticket he requested.

2.4.4 Tickets

Kerberos introduces the concept of tickets. Conceptually, a Kerberos ticket is an encrypted data structure issued by the Key Distribution Center that includes a shared encryption key that is unique for each session, and ticket flags that indicate, for example, if the ticket can be forwarded to another service, along with other fields. Tickets serve two purposes: to confirm identity of the end participants and to establish a short-lived encryption key that both parties can share for secure communication (called the session key).

The best way to think about tickets is as a license (issued by the KDC) that confirms your identity. Just like a license in the real world, each ticket issued by Kerberos includes data about you, how long the license (or ticket) is valid, and restrictions on its use. The major fields that Kerberos includes in every ticket are:

• The requesting principal name (the user's principal)

• The service's principal name

• When the ticket becomes valid, and when the ticket expires

• A list of IP addresses the ticket can be used from

• A shared secret encryption key ("session" key) for user/application communication

Some of these fields are filled in by the KDC; for example, the KDC enforces a maximum ticket lifetime, and the KDC generates a unique session key each time it issues a ticket. The other fields are filled in by the client and passed to the KDC when it makes a ticket request. When a ticket is generated by the KDC, it is encrypted to ensure that attackers cannot take a valid ticket and modify it; for example, to increase its lifetime or the validated client principal name.

Tickets are relatively short-lived. A typical maximum lifetime for a Kerberos ticket is 10-24 hours. This relatively short lifetime balances the convenience of single-sign-on with the security threat of an attacker stealing credentials and using them for a long period of time. By limiting the lifetime of Kerberos tickets, the damage of a stolen ticket is minimized, while the user still enjoys the convenience of single-sign-on during the working day.

2.4.4.1 The ticket (or credential) cache

Now that we have all of these tickets, where do we put them? Well, unfortunately, the answer is: it depends. The original Kerberos implementation written by MIT uses a file-based credential cache. That is, when you log into Kerberos, and as you are issued tickets for Kerberized services, all of the tickets are stored in a file. This method was chosen because it is the most portable; every platform has a filesystem, and it is easy to read and write to files. However, this method is inflexible and insecure. Therefore, other ports of the MIT Kerberos code, as well as independent implementations from other vendors, include other methods of storing tickets. Both the Microsoft and Apple implementations of Kerberos include a memory-based credential cache that ensures that credentials are kept in memory and destroyed upon the termination of the login session.

Since the default credential cache is a file-based credential cache, we'll take a look at what one looks like. No matter where the credential cache is stored, it still contains the same information: a user principal, and a set of service tickets that the user has obtained throughout their login session. A sample credential cache is shown below:

$ klist
Ticket cache: FILE:/tmp/krb5cc_502_auJKaJ
Default principal: jgarman@WEDGIE.ORG

Valid starting     Expires            Service principal
09/10/02 01:48:12  09/10/02 11:48:12  krbtgt/WEDGIE.ORG@WEDGIE.ORG
09/10/02 01:48:14  09/10/02 11:48:12  host/cfs.wedgie.org@WEDGIE.ORG
09/10/02 04:20:42  09/10/02 11:48:12  host/web.wedgie.org@WEDGIE.ORG

In this example, the credential cache for the user principal of jgarman@WEDGIE.ORG is stored in the file /tmp/krb5cc_502_auJKaJ. Credential caches can only be associated with one user principal at a time; if I wanted to access services with a principal of jgarman/admin@WEDGIE.ORG instead, I would have to destroy my current tickets and re-login to Kerberos as jgarman/admin@WEDGIE.ORG.