The KDC, Application Servers, and Their Clients

As explained earlier in this chapter, the KDC, kerberized application servers, and their clients must be protected so that their operation cannot be unduly influenced. The KDC must be physically secure and must not allow any non-Kerberos network activity. For example, allowing the KDC to run a network protocol that is a known security risk (e.g., UNIX Trivial File Transfer Protocol (TFTP) or UNIX sendmail mailer) is an invitation to disaster. In general, the only application that should run on the KDC (and its slave servers) is Kerberos.

Both servers and clients must be protected from compromise. Although they are less critical than the KDC and its slaves, if a server or a client is compromised, their roles in the Kerberos authentication process can no longer be trusted. Although it may seem odd that the principals that Kerberos is authenticating need to be protected, consider that all security is built on a foundation of basics such as good control over both physical and logical access to the computing environment. If physical and logical access to Kerberos principals is not properly managed, client and server identities can be spoofed. Additionally, if users do not properly manage their Kerberos passwords (or it is not properly managed for them with a smart card or token device), their identity can be spoofed.

Kerberos Administration

Kerberos administration must be coordinated with other administrative tasks. For example, many organizations maintain their user community controls in a data base that is updated periodically, with changes propagated to individual systems and applications (e.g., individual LA authorization data bases). When an employee leaves the company, among the access privileges needing to be revoked is that user’s Kerberos access. It should also be recognized that in preparing for the initial implementation of Kerberos, new passwords must be distributed to a large number of users — not a trivial task.

Kerberos Performance and Network Topology

Kerberos overhead is small, and generally a small amount of additional overhead on signon is considered acceptable. Individual transactions can be authenticated quickly, because Kerberos uses a fast message digest hash for an integrity check and DES for privacy. After the initial Kerberos ticket granting ticket (TGT) is processed, all such operations take place in memory (of both the client and server principals) so there is little additional overhead involved. However, the specific requirements for each implementation should be carefully evaluated.

Special requirements for Kerberos performance and availability can be met by deploying secondary (slave) KDCs to network segments where they can be accessed directly, and where they can be available during periods when the main KDC is unavailable. Updates are made to the main KDC’s data base, and the data base is then replicated periodically to the read-only, slave KDCs.

In order to ensure that an organization does not end up with a plethora of different authentication techniques, any new mechanism must be compatible with existing and planned efforts. Compatibility must exist among applications, internal organizational standards, standards in the organization’s industry and, of course, international standards in the network and computer industry. Adopting authentication as a part of an overall strategy for security provides a solid foundation. However, the decision should be guided by emerging standards for such services.

The GSSAPI, the emerging standard for Internet security services, is a logical choice as an insulator between the suppliers of security services (such as Kerberos authentication) and security service consumers (such as application programs). Because it is an application program interface, the GSSAPI does not provide interoperability between different security mechanisms in and of itself. Interoperability requires a common mechanism between cooperating players using the mechanism. Widespread interoperability among disparate authentication mechanisms requires that they all communicate with one another. The GSSAPI can hide the complications of this interoperability from the programs that use it to access security services.

What the GSSAPI does provide is insulation from change — it is possible to replace the underlying authentication mechanisms easily and without changes to applications written to use the GSSAPI. A decision to adopt the GSSAPI, with Kerberos as its mechanism, allows weaker, more problematic authentication mechanisms in existing applications to be economically replaced. That is, the initial investment in recoding programs to use the GSSAPI would not be wasted because the underlying authentication mechanism can be changed at will without having to recode the entire application each time security technology advances.

Because current Kerberos implementations support only TCP/IP, shops that run DECnet or SNA may not be able to use Kerberos to authenticate in these environments. In the same vein, Kerberos support for older operating systems may be needed. These environments require special treatment to move Kerberos into them. In the worst case, such environments cannot be changed directly. For example, an older application that is not easily modified to add Kerberos can be frontended with a mechanism that isolates it and provides the desired Kerberos services.