Chapter 9
Kerberos

A conventional time-sharing system requires a prospective user to provide an identity, and to authenticate that identity before using its services. A network that connects prospective clients with services has a corresponding need to identify and authenticate its clients. One approach is for the service to trust the authentication performed by the client system. The Unix network applications lpr and rcp, for example, trust the user’s workstation to reliably authenticate its clients.

Unfortunately, a workstation is under the complete control of its user. The user can replace the operating system, or even replace the machine itself. A secure network service cannot rely on the integrity of the workstation to perform a reliable authentication.

Kerberos is a network authentication system developed at MIT to address this problem. It enables users communicating over networks to prove their identity to each other while optionally preventing eavesdropping or replay attacks. It provides data secrecy using encryption. Kerberos provides real-time authentication in an insecure distributed environment.

---

Note:  Kerberos is a North American technology; because of export restrictions it is not available outside of North America. To solve the same problems and to provide European companies with a compatible product, another project has been started in Europe. Their product is called SESAME, and is fully compatible with Kerberos Version 5.

---

How Kerberos Works

The Kerberos model is based on a trusted third-party authentication protocol. The original design and implementation of Kerberos was the work of MIT Project Athena staff members. Kerberos is publicly available and has seen wide use.

Kerberos works by providing users or services with “tickets” that they can use to identify themselves, and secret, cryptographic keys for secure communication with network resources. A ticket, which is a sequence of a few hundred bytes, can be embedded in virtually any network protocol. This enables the processes implementing that protocol to be sure about the identity of the principals involved. Although most implementations of Kerberos use TCP/IP, some implementations use other protocols.

Practically speaking, Kerberos usually is used in application-level protocols, such as Telnet or FTP, to provide user-to-host security. Data stream mechanisms, such as SOCK_STREAM or RPC, can also use it as the implicit authentication system. At a lower level, Kerberos also can be used for host-to-host security in protocols such as IP, UDP, or TCP—although such implementations are rare.

Kerberos is only a part of a security implementation. A full security implementation requires identification, authentication, assurance, access control, audit, security policy, and documentation. Kerberos provides services in the first two areas:

•  It provides identification, mutual authentication, and secure communication between principals on an open network.

•  It manufactures secret keys for any requester and provides a mechanism for these secret keys to be safely propagated through the network.

Using Kerberos on time-sharing machines greatly weakens its protections. A user’s tickets are only as secure as the “root” account. Dumb terminals and most X terminals do not understand the Kerberos protocol. Using Kerberos to authenticate to the local workstation is easily circumvented.

In a Kerberos system, a designated site on the network, called the Kerberos authentication server, performs centralized key management and administrative functions. The server maintains a database that contains all users’ secret keys. It generates session keys whenever two users want to communicate securely and authenticates the identity of a user who requests secured network services.

Like other secret-key systems, Kerberos requires trust in a third party—the Kerberos authentication server in this case. If the server is compromised, the integrity of the whole system fails.

The Kerberos Network

Kerberos divides the network into security domains, called realms. Each realm has its own authentication server, and implements its own security policy. This enables organizations implementing Kerberos to have different levels of security for different information classes within the organization. A realm can accept authentications from other realms or not accept them without a re-authentication if the information security policy requires re-authentication.

Realms are hierarchical. That is, each realm may have child realms, and each realm may have a parent. This structure enables realms that have no direct contact to share authentication information. If an organization has a corporate-wide user naming policy, for example, it is possible for a user authenticating in one Kerberos realm to connect to a computer in another realm without requiring re-authentication. This is true even if logically there is no direct connection between the two realms. Specifically, if an organization ABC.COM has installed Kerberos, it may have created departmental realms PAYROLL and RESEARCH (see fig. 9.1). If a user authenticates to the realm RESEARCH.ABC.COM and wants to use information from PAYROLL.ABC.COM, there is no need to re-authenticate. The user identity is passed between the realms by way of the parent realm ABC.COM. Because both realms are part of the same organization, they can trust each other.

Figure 9.1  Kerberos realm hierarchy.

On the other hand, if a user authenticates to DEF.COM and wants to use information from RESEARCH.ABC.COM, Kerberos can require the user to re-authenticate to an authentication server within ABC.COM before sharing information. Because Kerberos provides secure authentication and encryption, this communication can take place securely over the Internet, a public, hostile network. If the two companies want to accept each other’s authentication, the two root Kerberos servers ABC.COM and DEF.COM need to share an encryption key. Because the Kerberos naming convention supports Internet domain names, a Kerberos user at DEF.COM can authenticate as a user to ABC.COM even if the two Kerberoses cannot directly share authentications.

RFCs

An RFC is a request for comment. This is a mechanism used to distribute ideas for standards in the internetworking industry. The RFC describes the protocol or standard the issuer would like to see adopted. Earlier versions of Kerberos were not described in RFCs. RFC 1510, however, describes version 5 of Kerberos.