7.2 Services and Keytabs

Remember that Kerberos provides a service that verifies the identity of two connection endpoints, identified by unique names, or principals. It is rather obvious so far that each user is associated with a principal name that is stored in the Kerberos database, since all authentication schemes by their very nature require that all users be uniquely identified with an associated secret. However, the concept that all services that users contact through Kerberos also require a principal and secret key is a new one to most administrators.

On Windows hosts, service keys are automatically created as needed when Kerberized services are installed. Unix-based Kerberos realms require a bit more manual configuration, and this section discusses the issues that Kerberos administrators have to work with when installing Kerberized services.

As we saw in Chapter 2, a service principal has three major components: the service name, the hostname of the machine that provides the service, and the Kerberos realm to which the machine belongs. Here's a sample service principal:

imap/freebsd.wedgie.org@WEDGIE.ORG

In this example, the service name is "imap", the host that this service is running on is "freebsd.wedgie.org", and the realm that this machine belongs to is "WEDGIE.ORG".

Of course, a secret key is associated with every principal, and so there is an encryption key or keys (possibly more than one, with different key version numbers, encryption types, and salts) associated with a given service principal. On Unix hosts, service keys are stored on the server providing the service, in a special file called the keytab. There can be, and for security reasons, should be, one keytab file per service offered.

Since keytab files contain highly sensitive information, notably encryption keys, it is imperative to ensure proper access controls to these files. Each Kerberized service should run as a different, unique username, and the keytab file for that service should be readable only by that username. As discussed in Chapter 6, the compromise of a service's key allows an attacker to masquerade as any authorized principal when communicating to that service, and also allows an attacker to read any conversation between clients and the compromised service.

The default keytab file—for most Unix-based Kerberos implementations—is /etc/krb5.keytab. By convention, this keytab contains the encryption keys associated with the host principal. While generating a host keytab for every machine in your realm is optional, it is highly recommended for those machines that run a Kerberized telnet or SSH daemon, or use Kerberos passwords to determine access to the local machine.

The process of exporting encryption keys from a Kerberos KDC to a keytab varies from one implementation to the next. The process for some common implementations is covered in Chapter 4. When extracting keytabs, ensure that they are protected during transport over the network from eavesdroppers. This can be accomplished by either running kadmin on the host you're extracting a keytab to, or using an encrypted file transfer protocol such as SSH's scp command to transfer the keytab to the target host.