2. An Overview of a Kerberos Infrastructure

2.1. An Introduction to Kerberos

Kerberos is a system of authentication developed at MIT as part of the Athena project. Kerberos uses encryption technology and a trusted third party, an arbitrator, to perform secure authentication on an open network. Specifically, Kerberos uses cryptographic tickets in order to avoid transmitting plain text passwords over the wire. Kerberos was based upon the Needham-Schroeder protocol.

There are two versions of Kerberos currently in use, version 4 and version 5. Kerberos versions 1 through 3 were internal development versions and never released. Kerberos version 4 has a number of known weaknesses and should no long be used. This document deals only with Kerberos 5. Kerberos 5 is defined in RFC1510.

The term Kerberos Infrastructure refers to the software, servers, and client configurations that will allow an administrator to use the Kerberos protocol to perform authentication on their network. Specifically, Kerberos Infrastructure consists of the Kerberos software itself, secured redundant authentication servers, a centralized account and password store, and systems configured to authenticate through the Kerberos protocol. This document will take you through the steps to install, configure, and deploy such an infrastructure.

2.2. The Benefits of Kerberos

For individuals unfamiliar with the Kerberos protocol, the benefits of deploying it in their network may not be clear. However, all administrators are familiar with the problems Kerberos was designed to mitigate. Those problems include, password sniffing, password filename/database stealing, and the high level of effort necessary to maintain a large number of account databases.

A properly deployed Kerberos Infrastructure will help you address these problems. It will make your enterprise more secure. Use of Kerberos will prevent plaintext passwords from being transmitted over the network. The Kerberos system will also centralize your username and password information which will make it easier to maintain and manage this data. Finally, Kerberos will also prevent you from having to store password information locally on a machine, whether it is a workstation or server, thereby reducing the likelihood that a single machine compromise will result in additional compromises.

To summarize, in a large enterprise, the benefits of Kerberos will translate into reduced administration costs through easier account and password management and through improved network security. In a smaller environment, scalable authentication infrastructure and improved network security are the clear benefits.

2.3. How Kerberos Works

Kerberos is an authentication protocol which uses a shared secret and a trusted third party arbitrator in order to validate the identity of clients. In Kerberos, clients may be users, servers, or pieces of software. The trusted third party arbitrator is a server known as a Key Distribution Center (KDC) which runs the Kerberos daemons. The shared secret is the users password transformed into a cryptographic key. In the case of servers or software systems, a random key is generated.

In Kerberos, users are known as principals. The KDC has a database of principals and their secret keys which is uses to perform authentication. In Kerberos knowledge of the secret key is considered sufficient for proof of identity. Since knowledge of a secret key translates into proof of identity in Kerberos, the Kerberos server can be trusted to authenticate any client to any other client. Authentication is Kerberos is done with out sending any clear text passwords across the wire. Below I'll explain how the Kerberos protocol maps to the GNU/Linux Kerberos software.

The KDC runs two important Kerberos daemons. These daemons are kadmind and krb5kdc. While GNU/Linux daemon naming conventions suggests that processes which have names starting with "k" are Kernel related or Kernel space processes, this is not true in the case of krb5kdc and kadmind. These two daemons are run as root in user space.

kadmind is the administrative daemon for the Kerberos server. kadmind is used by a program named kadmin to maintain the database of principals and policy configuration. If you choose to disallow any remote logins via ssh on your Kerberos hardware, kadmin will allow you to remotely administer the Kerberos components of the server.

krb5kdc is the workhorse of the Kerberos server. It is responsible for performing the role of the trusted third party arbitrator in Kerberos authentication. When a user wants to authenticate himself to a system or service, the user requests a ticket from the KDC. A ticket is a datagram consisting of the client's identity, a session key, a timestamp, and some other information. The datagram is encrypted with the server's secret key.

In detail that process works as follows, first the request for authentication is sent to the krb5kdc daemon. When the daemon received this request, it looks up the client, the principal, trying to authenticate in the principal database. It reads the clients secret key from this database and encrypts a special ticket called a Ticket Granting Ticket (TGT) which it then sends back the client. The client receives this encrypted TGT which contains a session key. If the client knows the password (the secret key stored in the principal database) and can successfully decrypt the TGT, it can present the ticket encrypted with the enclosed session key to a Ticket Granting Service (TGS). The TGS will then issue a subsequent ticket which will provide the client with the authentication they need to use a specific system or service.

Through the use of encrypted tickets which can only be decrypted if the client knows the secret key, secure authentication takes place. Time stamp information is included in the tickets to prevent replay attacks. A replay attack would be the fraudulent representation of a previously issued ticket in order to gain unauthorized access.

2.4. Compromise of Kerberos Infrastructure

The primary way in which an attacker will attempt to compromise a Kerberos Infrastructure would be to attack the Kerberos servers. If an attacker can gain root access to a KDC, the attacker will have access to the database of encrypted passwords of the principals. The attacker will also have access to the Kerberos software and configuration files both of which they can then modify to make the system perform authentications which should not be successful.

Other methods of attacking Kerberos infrastructure include replay attacks and password-guessing attacks. A replay attack would involve intercepting or otherwise acquiring a Kerberos ticket and then fraudulently representing that ticket in an attempt to gain authentication. Password guessing in a Kerberos system could be done by intercepting Kerberos tickets from the network and then making a brute force attempt to decrypt the intercepted tickets.

An attacker may exploit outdated software in the infrastructure. For example, there are many problems with Kerberos version 4. Most importantly, Kerberos version 4 has a basic protocol weakness in the encryption used. The design of Kerberos 4 included the use of DES in standard mode which allows attackers to intercept and modify the ciphertext of Kerberos tickets in an undetectable way. In order to prevent these attacks, Kerberos 5 has been modified to use triple DES in Cipher Block Chaining (CBC) mode.

When discussing the strength of Kerberos 4, it is also important to note that many implementations of Kerberos version 4 have buffer overflow vulnerabilities. While the reference implementations of version 5 fixed the buffer overflow weaknesses in version 4, distributions of Kerberos 5 usually ship with software to provide backward compatibility to support legacy Kerberos 4 applications. Some of the backward compatibility code for version 4 support in Kerberos version 5 releases is still believed to be vulnerable to buffer overflow attacks.

Therefore, due to the protocol weaknesses in version 4 and the potential for buffer overflow attacks with version 4 implementations and version 4 backward compatibility code, it is best not to support or use Kerberos version 4.

In summary, from this description on how a Kerberos infrastructure can be compromised, we realize that we must give great priority to the security of the Kerberos servers themselves, run up to date Kerberos software, and remain vigilant in picking good passwords and in setting good password policy.