Kerberos Network Design Manual The Kerberos Protocol Kerberos is designed to prove a user's identity. Unlike conventional authentication systems which challenge a user for a user ID and password, Kerberos issues authentication tickets, which allow users to access services unchallenged. Built on a model of trust, Kerberos centers around the Kerberos server, or KDC (Key Distribution Center). Every server on the network has an implicit trust of the Kerberos KDC, as they share a secret. Users gain access to network resources by presenting tickets with encrypted information from the KDC, which the server can verify. As the KDC is the only place that knows every encryption key, it can share secrets with users and servers throughout the network to verify their authenticity. This way, as each principal trusts the KDC, the entire network is secure as long as the Kerberos server is secure. The Kerberos KDC is simply a database of all us ers and services in the Kerberos realm (or administrative domain). Each entry in this database is called a principal, and includes an associated encryption key. For users, this encryption key is derived from the user's password. Kerberos includes a simple notation to locate users, instances and realms. (user@REALM.com). Like an e-mail address, it reads from right to left. To the left of the "@" sign is the realm name. This is commonly the same as the DNS (Domain Name System) but is not restricted to DNS. (Note: Kerberos clients manually map DNS domain names to Kerberos realm names). An instance is simply an additional entry for the same user. For example, most Kerberos implementations require administrative users to use an administrative instance while editing the Kerberos database, such as user/instance@REALM.com. By default, most users only see a "null" instance of user@REALM.COM. Every instance, although conveniently associated with the same user name, is actually a separate database entry, each with its own key and password. Users who want make administrative changes must enter their admin instance password as opposed to their standard password. In addition to user principals, each service on the network has its own principal. For instance, when installing a Unix server into a Kerberos realm, it requires a host principal in the following form: host/hostname.domain.com@REALM.COM. This service principal is used when users access the server through Kerberos authentication. The above notation is correct only in Kerberos version 5. Version 4 separates user and instance names with a dot instead of a slash resulting in the following notation: user.instance@REALM.COM. Due to extensive changes in the ticket structure and the protocol itself, Kerberos 5 is not directly compatible with previous versions. In fact, Kerberos 5 KDCs use different TCP or UDP ports (port 88 as opposed to port 751) than previous versions. However, most Kerberos 5 implementations also include a daemon for issuing Kerber os 4 tickets, enabling older clients and servers to access the new Kerberos realm. To make things more complicated, every encryption key is encrypted. The Kerberos security model relies on protecting encryption keys under layers of encryption. Much like a secret wrapped in enigma, the only way to access these keys is to decrypt the previous encryption. In fact, the entire Kerberos database on the Kerberos server is encrypted using a single key. This master key is the most important password of the realm and should be guarded carefully. As most Kerberos administration is done using admin instance accounts, this master password is only used when installing the realm and for other major maintenance efforts. Used to unlock the Kerberos database every time the Kerberos server starts, most KDCs cache an encoded version of this password in a protected stash file on their hard drives. (This is one of the major reasons for jealously guarding a Kerberos server). Print This Page E-mail this URL