Kerberizing Applications, Their Servers, and Clients

In order to add Kerberos-based authentication to an application, it must be broken down into a client part and a server part (if it is not already so divided). This is done in order to separate the parts of the application that participate in Kerberos authentication — the client part is authenticated to the server part (or possibly mutual authentication is performed). This division is necessary even if the application does not have a true client/server architecture. For those client-server applications, the division usually follows the application’s existing client-server structure. The fundamental questions are:

•  What client-server structure most accurately represents the components of the application?

•  How is the client-server structure to be imposed on the application?

These are very broad questions with implications for an application’s utility and security. Implementation of the answers also has a major effect on the cost of kerberizing an application.

Although it may ultimately be desirable to reimplement all applications as kerberized client-server, this is not always feasible. An example is a terminal-based application on a timesharing system. Such applications implicitly assume that the transmission path between the terminal and the host is secure. But this may not hold true when terminals and hosts are separated by a network. The client-server answer to this problem is typically to eliminate the terminal and replace it with a client (running a GUI-based front end), and replace the host application with a back-end server. Kerberizing both client and server parts of the application then make the application’s security independent of the intervening network. Suffice it to say that each client/server architecture and each class of network device must be kerberized in a way that takes into consideration its idiosyncrasies.

COST FACTORS

The design, planning, and implementations for widespread authentication is expensive. Planning for authentication may raise basic security-related questions that will also need to be addressed.

Software Costs

The least expensive approach is to use the public domain version of Kerberos. However, this alternative leaves the user with no support and all the idiosyncrasies of this version. (It is possible to purchase support for the public domain version.) It should be noted that many organizations do not allow the widespread deployment of public domain software.

Commercial versions of Kerberos are available with service and support. The vendors can provide trained security professionals and can offer a variety of security services to assist organizations secure their systems.

Cost of Securing the KDC

An additional cost that is often overlooked is the cost of securing the KDC and the slave KDC servers required for redundancy. The KDC requires special treatment, and the network’s topology may require more than one slave. Separate machines and physical housings for these KDCs are often required. Fortunately both primary and secondary KDCs can run on small machines. For example, MIT’s Project Athena runs 3 DEC station model 2100s as KDCs (one primary and two secondary) for over 1300 workstations and more than 100 servers. These systems are small, easy to operate, and relatively inexpensive. (Each is configured with 12 MB of memory and 332 MB of disk space.)

Personnel Costs

Merely installing the KDCs is not sufficient; people must be properly trained in the administration and operation of these systems. In addition, a complete Kerberos implementation team must be organized and trained.

VULNERABILITIES

As does any authentication scheme, Kerberos has certain weaknesses. The problem for Kerberos implementors is to learn how to deal with these weaknesses.

The Kerberos design assumes that server principals are kept in moderately secure areas, that the key distribution center is in a secure area, and that the key distribution center runs only trusted software. Remember that Kerberos comes out of MIT’s Project Athena. At MIT, care is taken to ensure that a minimum amount of trust is placed in client workstations. This includes provisions for trusted booting from trusted servers and no system or applications software on the workstations’ local disks. In an ideal environment, local disks are wiped clean between boots to ensure that the after-effects of infected software do not remain to haunt users.

Still, a question remains: Has the workstation been compromised in a way that would allow an attacker to set aside these protections, install a covert channel, and collect a user’s Kerberos password as it was typed on the workstation? Although such an attack is not simple, it is possible. Accordingly, workstations in such environments should be kept under the lock and key of controlled physical access and inspected periodically to ensure that they have not been tampered with.

Moving from a closely controlled environment to one in which workstations boot and run from local disks, several new concerns arise. Besides having to carefully control physical access to such workstations, the security of these machines must be managed very carefully to ensure that local software has not been compromised. This is usually done by means of regular technical inspections, backed up by more rigorous periodic assessments.

For instance, in a workstation environment that uses UNIX systems, each workstation might be inspected nightly by automated tools that report their findings to a central security management facility. The hope is that these inspections will detect any security problems so that they can be expediently resolved. Authentication schemes such as Kerberos cannot solve fundamental problems such as dishonest employees, people that pick bad passwords, or lack of adequate network or host security management.

Finally, because the Kerberos key distribution center contains all of the shared secrets as well as provides security services, it must be very carefully protected and managed. Although client workstations may be in relatively public areas and run software that is not entirely trusted, the KDC must be trustworthy. This means that the access to the KDC must be carefully controlled and monitored.