Currently, a few operating system vendors include Kerberos in the software that they ship. Third-party Kerberos suppliers provide Kerberos libraries and modify or rewrite standard operating system utilities to “kerberize” them. The convention in such operating systems as UNIX is that kerberized programs simply replace standard utilities, and users see no difference in the commands that they type. In some implementations for such operating systems as VMS, the standard commands are modified to include instructions that specify Kerberos (e.g., telnet/authorization = Kerberos). In other Kerberos implementations, the standard operating system utilities are actually replaced with appropriately named kerberized counterparts such as ktelnet. Finally, in such operating system implementations as Kerberos for Microsoft Windows, Macintosh, and Next’s NextStep, programs may actually have their own graphical user interfaces, just as would any other program in that environment. In these cases, a user just clicks on the appropriate icon.

For example, in a typical kerberized Windows environment, a user would simply click on the desired application icon to activate it after the user’s Kerberos password had been entered. From there on, the application program handles the authentication in cooperation with Kerberos behind the scenes. An environment in which users only need to enter their passwords once has fostered the idea that Kerberos is a single-sign-on system. However, Kerberos can only provide this seemless access to kerberized applications. If workstation users must use many different nonkerberized applications that require them to log on with individual passwords, the addition of Kerberos to their workstation environment alone will not change things. Again, each application must be kerberized.

TECHNICAL ISSUES

The success of a Kerberos implementation depends on how carefully it is designed and how completely it is planned. Lack of these two critical elements is the major reason that the implementation of any security scheme fails. A detailed consideration of the authentication mechanism itself (e.g., what it is, how it works, how to use it, how to apply it, and its weaknesses) is important. A number of details may need to be addressed. These include: the topology of the network; the placement of authentication in the protocol stack; the use and availability of network services (such as time and naming); and the relative security of the basic network infrastructure. Understanding these details is a prerequisite to proper operation, performance, and administration of Kerberos.

Protocol Placement

In Exhibit 4, network segments A (which connects the primary KDC management capability to the KDC), and B (which connects other mission critical applications) may be more critical than network segments D and E (which connect relatively less important applications). Therefore, network segments A and B need to be carefully engineered, perhaps more so than network segments D and E. (As a reminder, Kerberos is an application level protocol. While most Kerberos implementations use TCP/IP, Kerberos itself is an authentication protocol that is independent of the underlying transport protocol.)

Exhibit 4.  Network Topology and Authentication Protocol

Using the Kerberos authentication protocol across a security firewall may make the firewall’s design, implementation, and operation more complicated. Many such firewalls use filtering or proxy agents that operate at the application layer in the protocol stack. Because the security firewall exists to protect the rest of the network from network segments D and E (including systems C and D, and whatever else they are connected to), the security firewall needs to understand how to deal with Kerberos traffic. Of course, the firewall may also need to deal with application server traffic from system D if its application is in use elsewhere in the network.

Time Services and Network Naming

Although Kerberos was designed to bring authentication to a network that generally lacks security-related services, the degree to which Kerberos can be trusted largely depends on how carefully it is implemented and the robustness of its supporting network services.

Kerberos requires trusted, loosely synchronized clocks in the network. Dorothy Denning and Giovanni Sacco’s work on the use of time stamps in key distribution protocols shows that enforcing limited lifetimes for authentication credentials based on time stamps can minimize the threat of replaced credentials. This can only be guaranteed through the use of trusted, or authenticated, network time services.

Kerberos authenticates to the names of its principals. Principals must have a secure way to determine the names of other principals that they are willing to communicate with. However, IP network addresses and network name services (e.g., TCP/IP Domain Name Service, DNS) can be spoofed. There are several ways to ensure that principal names can be trusted. For example, a principal name might be placed in an access control list of an application server. Alternatively, local knowledge of a designated application server might be hard coded into an application client. Finally, use of a name service can provide some measure of assurance, because answers from the name server must be authentic.

Within the limits of the encryption and key exchange protocol technology that Kerberos uses, its authentication is held together by trust. The KDC and principals must trust one another to be who they represent themselves to be. This keystone is held in place by trusted time services and robust means for principals to identify one another. Kerberos provides a mechanism for securely authenticating principals. However, in the real world, it is also necessary to secure the information about which principal one is willing to talk to.