Implementing Kerberos

David Smith

Kerberos is the mythical three-headed dog guarding the gates of the underworld. It has long been a symbol of unceasing vigilance and was therefore selected as the name of the authentication service for MIT’s Project Athena (a collaboration among IBM, DEC, and MIT to develop a ubiquitous networking service for undergraduates at MIT). Project Athena included such innovations as the X Window system, a Directory service named Hesiod, and a messaging service named Zephyr, but only X and Kerberos have become prevalent outside MIT.

Kerberos was designed for an environment with insecure workstations, an insecure network, and moderately secure servers. These assumptions are paralleled in the current Internet, making Kerberos an effective authentication service in modern distributed environments. It is not, however, a complete security service: Kerberos provides for authentication, not authorization or accounting, and is not easily extensible to multi-domain environments. The latter issue is being addressed by current work incorporating PKI support into Kerberos, but at present cross-realm authentication needs to be performed by explicitly extending trust between two Key Distribution Centers (KDC).

Enhancements in Kerberos V allow hierarchical cross-realm trust using transitive trust between different domains. With this architecture, a KDC in realm PLEAIDES.TAURUS.TEST can have a cross-realm trust extended to TAURUS.TEST and will inherit trust to other subdomains of TAURUS.TEST.

In this article, I will demonstrate how to implement Kerberos on multiple operating systems and discuss some of the issues that arise when using “kerberized” applications. I will begin with a discussion of the terminology and roles involved in a Kerberos system, following with the network design for the test domain and the actual implementation steps.