Kerberos on Wall Street

ABSTRACT

Morgan Stanley, an international financial services firm, has a significant investment in Kerberos. We have been using Kerberos 4 since 1993, and began a transition to Kerberos 5 in 1995. Kerberos has helped us progress towards solving the classic security problems of cleartext passwords and single sign-on. However, because of Morgan Stanley's specialized requirements, and a lack of support for Kerberos among operating system and application vendors, we have faced a number of practical integration problems not faced by the research community. This paper discusses those problems, the tools we have built to solve them, and the areas in which we feel vendors must provide better support for Kerberos.

1. Introduction

Morgan Stanley is an international financial services firm with 37 offices in 22 countries. Since 1993, Morgan Stanley has used Kerberos for initial login authentication by 3500 UNIX accounts (75% of total) on 4000 UNIX machines (80% of total) spread over a large WAN over 20 sites on 3 continents. Several Kerberized applications were also deployed: those originally supplied by MIT (rsh/rlogin/rcp), as well as a handful of proprietary Morgan Stanley Kerberized client-server applications. Kerberos has solved the classic security problems caused by cleartext passwords traveling over networks, and has spurred development of authenticated client-server business applications. It has also helped us take a big step towards providing single sign-on access to all computing platforms in the Firm.

While the theory and implementation of the Kerberos protocol is of great interest to corporate Information Technology (IT) departments, a host of practical integration problems exist that were not generally faced by its designers and implements. This paper discusses the use of Kerberos at Morgan Stanley, some of the problems encountered during Kerberos 5 deployment and solutions we chose.

2. Transitioning to Kerberos 5

Our initial Kerberos deployment was based on the stock Version 4 distribution from MIT, to which we added functionality such as incremental hierarchical database propagation and a rudimentary authorization server. Unfortunately, some of the added functionality was incompatible with the basic Kerberos 4 protocol and some of the Kerberized applications distributed by MIT. Because of these incompatibilities, well-known limitations of the Kerberos 4 protocol [Bellovin & Merrit, 1990], as well as the ongoing cost of supporting in-house code, Morgan Stanley decided in 1995 to deploy to a Kerberos 5 implementation purchased from an outside vendor. The aim of the Kerberos 5 deployment was to replace the current Kerberos 4 infrastructure, extend Kerberos to all platforms used by the Firm, including PCs, and leverage the new Kerberos 5 functionality.

2.1 Transition Planning

Deploying any software into corporate production environments requires careful planning, thorough testing, and coordination with many groups in IT and other business units. New software must be rolled out in a series of small, reversible steps to minimize the impact on the production environment in case of unforeseen problems. In addition to these requirements, we had to meet the following goals to effect a smooth transition to Kerberos 5:

1. Backwards compatibility: Existing production software should continue to work unchanged to the greatest extent possible.

2. Transparency: A business user should not need to know or care if a system is a Kerberos 4 or a Kerberos 5 client.

2.2 Deployment Strategy

Kerberos 4 and Kerberos 5 servers coexist during the transition period. The contents of the databases are kept synchronized using a database propagation gateway described later. Therefore, all principals have equivalent entries on both servers. As each set of client machines is upgraded to Kerberos 5, the krb.conf file is updated to point to a Kerberos 5 server.

Our deployment strategy for Kerberos 5 in Morgan Stanley's UNIX environments consisted of two parallel tracks:

1. For machines which had never been Kerberized, we proceeded on a site-by-site basis to convert machines and modify individual user /etc/passwd entries.

2. Conversion of machines fully integrated into our Kerberos 4 environment was substantially more complex. Batch (cron) jobs requiring Kerberos credentials required minor, but necessary modifications. We chose to convert desktop workstations first, on a site-by-site basis, since batch processing occurs primarily on servers. Servers were converted only after verification of batch processing by responsible development teams.

Great care was taken to ensure that programs like rsh worked seamlessly between hosts that had been converted to Kerberos 5 and those that had not yet been converted. Most of our production applications depend on rsh.

3. User Transparency

To make the transition to Kerberos as transparent as possible for users on both Kerberized and non-Kerberized machines, we enhanced some standard programs and developed some new tools. We were also forced to wrap many standard programs, such as the Berkeley rsh client, to provide different Kerberos related behavior via the same file system path.

3.1. Integrated Login

In many Kerberos environments, users enter two passwords: one to authenticate with a standard crypt() based login, and another to obtain Kerberos credentials via kinit. One of the enhancements added by Morgan Stanley to Kerberos 4 was to integrate Kerberos into login. Login checks the second field of a user's /etc/passwd entry; if it contains a '*' in place of an encrypted password, the user is Kerberized and the password is authenticated against Kerberos. This supplies the user with valid Kerberos credentials for the session.

The deployment of Kerberos 5 required additional modifications to login to obtain Kerberos 5 credentials. However, our login still obtains Kerberos 4 credentials for backward compatibility, as we expect to have Kerberos 4 dependent applications for the foreseeable future.

We use the MIT krb524 package to allow login to convert Kerberos 5 tickets to Kerberos 4 tickets. Our vendor's Kerberos 5 KDC also services requests for Kerberos 4 authentication. However, production applications have come to rely upon non-standard, legacy modifications made to our in-house Kerberos 4 KDC to provide support for long-lived tickets and multi-homed hosts. We therefore could not use our vendor's KDC for Kerberos 4 authentication in login directly, and decided to use the krb524 package instead.

Login now also obtains AFS (Andrew File System) credentials for the user. Login requests a Kerberos 5 AFS service ticket, which is converted to version 4 service ticket using krb524 and then transformed into AFS kernel tokens. (The Kerberos 5 AFS ticket cannot be utilized directly because AFS uses the Kerberos 4 protocol.) This feature is vital because Morgan Stanley relies heavily upon AFS; AFS contains most user home directories as well as major firm-wide software distributions [Gittler et al. 1995].

We similarly modified other basic system entry points, such as in.ftpd, in.rexecd, xlock, and xdm. The result is that typical users never have to use kinit to obtain or refresh their credentials on their desktop workstations.

Though Kerberos distributions now include integrated login programs, we chose to base our modifications on operating system vendor source code. Though additional support costs were incurred, we were not comfortable with semantic differences between the operating system vendor’s programs and the Kerberos vendor’s replacement programs.

3.2. Ak5log

In addition to integrating AFS authentication into system entry points, we implemented a standalone AFS authentication program, ak5log, which obtains AFS credentials with a user’s TGT. ak5log is used to obtain AFS credentials when a user forwards tickets to a remote system, as is possible with the Kerberos 5 versions of rsh, rlogin, and telnet.

We modeled ak5log after the publicly available Kerberos 4 based aklog program and patches suggested by Engert [Engert 1994; Engert 1995]. Our implementation, however, is somewhat different. The AFS authentication code is isolated into a library used by ak5log, login, and other programs that authenticate users. In addition, ak5log by default obtains tokens for every cell known to the kernel. This is important to preserve transparency for business users, who frequently access files in different cells.

The issue of credential lifetimes is problematic when integrating Kerberos 5, Kerberos 4 and AFS logins. For both Kerberos 4 and AFS, the ticket lifetime is contained in one byte; However, this byte is interpreted differently. Under Kerberos 4, each increment of the lifetime byte corresponds to 5 minutes. Under AFS, lifetimes from 0 to 128 are interpreted as 5 minute increments, but lifetimes between 129 and 191 correspond to fixed values in a table in the AFS libraries that are roughly exponentially increasing. A lifetime of 191 (0xBF) corresponds to 1 month.

Because of these differing interpretations of credential lifetimes, the lifetime of a Kerberos 4 AFS service ticket and the length of time the AFS server will allow file system access do not precisely correspond. Although Kerberos 5 tickets support longer lifetimes, this problem is still extant in ak5log because the Kerberos 5 AFS service ticket must be converted to a Kerberos 4 AFS service ticket via krb524. We avoid the problem by simply obtaining AFS tokens valid for a month, thus ensuring that business users will never be denied access to the AFS file system during their login session.

3.3. Trojan Horse Screen Lock

A goal of the Kerberos 5 deployment was to Kerberize the remaining 25% of the Firm's UNIX accounts. These accounts had been administered by a separate technology department within Morgan Stanley prior to 1994. They had not deployed Kerberos 4 and thus were still using the crypt() based login supplied with their operating system.

In order to conveniently convert these accounts, we implemented a special method for Kerberizing users en masse. The standard method for setting Kerberos passwords for new users - assigning the user a known password which they are forced to change immediately upon login - was not feasible due to inconvenience to users and support staff.

The solution we chose was a special version of our screen lock program that would add a new principal to the Kerberos database when an non-Kerberized user unlocked their screen. The new principal's password would be set to the password the user had just entered. An admin password encoded into the binary was used to authenticate to the kadmind server in order to effect the addition. Syslog messages generated during such an event were used to notify sysadmin staff to update the user's /etc/passwd entry (i.e. replace the encrypted password with a '*').

Such programs present security risks. Users who reverse-engineer the admin password out of the executable program could effectively gain access to any UNIX account in the Firm. To reduce this danger, the admin password is not present in the executable in cleartext; rather, it is obscured by encrypting it with a known key. In addition, the program is deployed for a very short time. These measures, and the fact that most Morgan Stanley users lack the technical expertise to 'crack' this simple encryption scheme, made the Trojan horse screen lock approach an acceptable compromise between security and practicality.

3.4. Incremental Gateway

In worldwide production environments, it is unacceptable to force a business user to have to wait until the next batch database dump before using a new Kerberized account. Therefore, Morgan Stanley added a hierarchical incremental Kerberos database propagation mechanism to Kerberos 4. This allowed multiple redundant Kerberos servers, to each have a continuously synchronized database. It also obviated the need for batch database replication across WAN links, freeing up bandwidth for vital market data flows.

We have more than 50 Kerberos servers in 4 continents, with two servers for each major geographical area. All the servers support our one worldwide domain. We desired to have database consistency such that any change would be replicated worldwide within seconds. Hierarchical propagation allows data to flow to intermediate servers which then distribute data to other servers in the continent.

Morgan Stanley required similar incremental propagation software from the Kerberos 5 vendor. Our user transparency requirement dictated constant robust synchronization between the Kerberos 4 and Kerberos 5 databases. We built a gateway that incrementally propagates Kerberos 4 database changes to the Kerberos 5 propagation tree. The gateway does not propagate Kerberos 5 database changes back to the Kerberos 4 world. Therefore, during the transition period from Kerberos 4 to Kerberos 5, users are limited to the Kerberos 4 variants of database update utilities (kpasswd, kadmin), preventing changes to the Kerberos 5 databases. These utilities will be replaced by their Kerberos 5 equivalents at the completion of the deployment. Thus, during the transition, the Kerberos 4 master is the global master KDC.

4. Kerberized Tools

4.1 Kerberized Underuser Utility

Many UNIX professionals are familiar with sudo, a publicly available utility that delegates higher privileges to specific users. Prior to the introduction of Kerberos, Morgan Stanley implemented a conceptually similar program called 'uu' (underuser), which allowed administrators to grant limited superuser privileges to certain users. This was used, for example, to give support personnel the ability to change the passwords or kill the screen lock of only those users they supported, or to give developers the ability to run network snooping utilities on some machines.

With Kerberos 5, we extended 'uu' to allow privileged users access to the Kerberos and AFS credentials of other users. The Kerberized underuser program, 'kuu', is quite flexible: users can be restricted to acquiring the Kerberos credentials of others to only perform specific tasks. This is in contrast to ksu, the Kerberized su utility, which only supports complete access to a target user's account, or no access at all. Also, when kuu requires a password, the password entered is the user's own password, not the target user's password as in ksu. kuu privileges are controlled by a centrally maintained authorization file, which contains lines with the following information:

key:domains:hosts:underusers:subject:runas:ticketas:passreq:command with args

The key specifies the kuu function to be performed; each field thereafter further restricts the ability of an underuser to perform this function. domains are the NIS domains in which these underusers can perform this function. The hosts field lists the hosts on which these underusers can perform this function. underusers lists the users allowed to perform this function. subjects are the users upon which the function may act. runas is the user which the command specified in the following field will be run as. ticketas specifies the principal for which a ticket will be forwarded. passreq defines whether the underuser must reenter their password to run the command. command with args is the actual command to be executed.

A few examples demonstrate the flexibility of the configuration file:

etherfind:*:machine1,machine2:tannoc,hollande:*:root:{}:*:/usr/etc/etherfind $*

The etherfind rule allows users tannoc and hollande to execute etherfind as root on hosts machine1 and machine2. The '{}' in the ticketas field simply indicates that no Kerberos tickets are passed back to the kuu client, as none are required for etherfind. The '$*' in the command field indicates that whatever command line arguments are specified when invoking kuu are passed on to etherfind.

afsdist:*:*:hollande:*:afsadmin:afsadmin:*:/usr/local/bin/vms dist $*

The afsdist rule allows user hollande to distribute volumes in the AFS file system using vms, our internal Kerberized client-server volume management system, with superuser (system:administrators) AFS credentials.

newpass:*:*:tannoc:+netgroup1:root:{}:*:/usr/local/etc/newpass {s}

The newpass rule allows user tannoc to change the password of any member of the netgroup1 netgroup. The '{s}' in the command field is replaced with the subject of the kuu command.

Kuu is a client-server program. The kuu client, invoked as 'kuu subject key args', uses the user's Kerberos 5 credentials to mutually authenticate to the kuud server. Thereafter, all communications between the kuu client and kuud server use KRB_PRIV encrypted messages. The kuu client sends its command line arguments, as well as the machine and NIS domain on which it was invoked, to the kuud server. The kuud server uses this information with the configuration file to verify the clients authorization to perform the requested action. Successful authorization is communicated back to the kuu client, which executes the requested action on behalf of the user. If the requested action requires the valid Kerberos credentials of another user, the kuud server extracts the secret key of that user from the Kerberos database, obtains a Kerberos ticket for that user, and forwards it to the kuu client. The kuu client uses the forwarded ticket to obtain AFS credentials.

4.2. Automatic Srvtab Installation

A driving force behind the design of Morgan Stanley's UNIX environment has been the need to reduce support costs and ease system administration. Most UNIX machines are completely configured via network boot. Should a financial trader's workstation fail due to suspected hardware problems, support staff can immediately swap the machine with a spare and execute a network boot command to quickly partition disks and load an operating system. Network booting also simplifies installation of new machines: the necessary configuration can be done centrally by senior system administration staff; local support personnel need only connect the computer's cables and execute a network boot command. Finally, system administrators use network booting to quickly rebuild large groups of machines during non-business hours with new or upgraded operating systems and configurations.

In this model, minimal manual intervention is required to rebuild a machine. However, secure installation of Kerberos 5 srvtab files becomes very difficult. Normally, administrators authenticate themselves on the local machine and execute certain kadmin commands to extract the srvtab. Srvtab files can theoretically be made available over the network; however, they would clearly be open to compromise.

Morgan Stanley's approach was to build a client server program, dst (download srvtab). dst contacts a daemon running on a Kerberos 5 server that constructs the appropriate srvtab and forwards it back to the client for installation. While the dst client cannot rigorously authenticate itself to in.dstd, and cannot therefore protect the srvtab file in transit over the network, the server does check that the client has bound to a reserved port, indicating that it is running with superuser privileges, and only provides the srvtab corresponding to the IP address of the client.

The automated srvtab installation issue is a subset of the larger issue of workstation authentication in distributed systems. In order to authenticate itself, a workstation must possess some secret by which it can prove its identity, or have an administrator vouch for the identity of the machine. Lampson et. al. describe a method by which a such a secret could be stored in nonvolatile memory [Lampson et. al. 1992]. Such a system would for a large scale implementation likely be quite expensive, hard to administer, and would still be unsatisfactory, as secrets would still need to be installed on new machines shipped from the hardware vendor. Having administrators authenticate themselves on the local machine to extract the srvtab is equivalent to having that administrator vouch for the identity of the machine, but this is also unacceptable in our environment. Since these alternatives are not possible, we have settled on dst as an adequate compromise between security and operational convenience.

4.3. Kerberized Cron Utilities

Many cron jobs at Morgan Stanley require access to Kerberos credentials in order to execute Kerberized utilities such as rsh/rlogin/rcp, or to access protected directories in the AFS filesystem. In our Kerberos 4 environment, such cron jobs execute kinit with a password stored in a file. Such password files are difficult to protect using standard operating system file security. Whenever employees with knowledge of these passwords leave the Firm, the passwords must be changed and the files updated, an operational headache. Finally, our vendor's Kerberos 5 kinit program does not accept non-tty input (a desirable security feature), making this password-store-in-file approach infeasible as well as unwise.

To avoid these difficulties, Morgan Stanley implemented a more secure, scaleable solution for Kerberized cron jobs. Cron jobs use Kerberos 5 tickets stored in a special location (/var/spool/tickets) on the local workstation that have short actual lifetime (typically one week) but are renewable for up to a year. A generic wrapper for cron jobs, kcron, obtains Kerberos 4 credentials and AFS tokens via krb524, sets the KRB5CCNAME environment variable, and then executes the cron job. Because the tickets in /var/spool/tickets are also forwardable, cron jobs that also execute commands on remote machines (via rsh, for example) can forward them as necessary.

Consider the following crontab entry for user sysmon, which runs a Kerberized program to monitor system health.

# Execute the sysmon script at 4:00 AM with Kerberos credentials.

0 4 * * * /usr/local/bin/kcron /usr/local/scripts/sysmon host > /dev/null 2>&1

4.3.1 Renewing Tickets

Because tickets stored in /var/spool/tickets have a short actual lifetime, they must be renewed on a regular basis to prevent expiration. We accomplish this by having a simple script that uses kinit to renew all tickets in /var/spool/tickets. This script runs, as root, weekly on every UNIX machine at Morgan Stanley as part of our overall system maintenance processes. This ensures that Kerberos tickets used by kcron processes remain valid from week to week and reduces the risk of critical batch streams failing due to expired tickets.

4.3.2 Ticket Installation

As described in section 5.1, most UNIX machines at Morgan Stanley can be completely configured via network boot. This presents a problem for kcron tickets, as newly scrubbed machines will not have the necessary tickets installed in /var/spool/tickets, causing kcron jobs to fail. To solve this problem, we have implemented a client-server program, run as part of the network boot procedure, that installs the necessary kcron tickets in /var/spool/tickets. This program is also used to install new tickets on a machine; since the Kerberos principals corresponding to production ids have a random secret key not derived from any password, kinit cannot be used to install tickets.

Ticket installation is performed by the krbtk client, which contacts the in.krbtkd server running on Kerberos 5 database servers. The in.krbtkd server consults a central registry to determine which tickets should be installed on the client machine. It extracts the secret keys for all these principals from the Kerberos 5 database, and returns them to the client. The client then obtains Kerberos tickets for all principals and stores them in /var/spool/tickets. The krbtk client, which must run as root, authenticates to the in.krbtkd server using the local machine's host principal; all messages passed between client and server are encrypted in KRB_PRIV messages.

4.3.3 Design Alternatives

We faced a few design alternatives when building kcron. One alternative was simply to have cron jobs that require Kerberos credentials authenticate via a key stored in a keytab file. While this approach is appealing due to its simplicity (no infrastructure for ticket renewal is necessary), it is little better than passwords stored in files - the srvtabs must sill be updated when the secret key for a principal is updated.

Another alternative was to simply issue tickets with long actual lifetimes (a year). This would also obviate the need for weekly ticket renewal. This solution forgoes the security advantage of renewable tickets, namely that, should a ticket be reported stolen, the KDC may refuse to renew tickets, thereby thwarting their continued use [Neuman & Kohl 1993]. However, this is of doubtful practical value. In an environment of 4000 UNIX machines, with frequent and ubiquitous use of Kerberos, simply detecting a single stolen Kerberos ticket is a daunting challenge. In addition, our vendor-supplied KDC does not allow administrators to deactivate ticket renewal for a particular principal (short of deleting the principal in question from the Kerberos database), nor, to our knowledge, does the MIT KDC.

4.3.4 A Comparison to lat

Rubin and Honeyman [Rubin & Honeyman 1993] describe a system for long running jobs in an authenticated environment. While lat and kcron are quite different in implementation, they operate on the same principle: some type of credential is left around on the local machine that authenticates the job. In the case of lat, it is a session key encrypted with a random key; in kcron, it is a renewable ticket. While a ticket is a more dangerous credential to leave on an unattended machine, this danger is mitigated, at least in theory, by the limited actual lifetime of the tickets. The lat client and latd server communicate to renew tickets if the batch job is to run for more than the lifetime of the ticket granting ticket (TGT); with Kerberos 5 this feature is inherent and kcron makes use of it directly. Finally, while lat seems applicable only to at-style jobs, kcron can be used for both cron jobs and at jobs, although using postdated tickets may be more appropriate for at jobs in a Kerberos 5 environment. The use of postdated tickets for at has not been investigated because of the limited use of at jobs at Morgan Stanley.

5. Kerberized Application Tools

Kerberizing infrastructure tools allow application developers to build secure applications. We developed and internally published a security API that provided functionality typically needed by our developers. We considered using GSSAPI [Linn 1993], but rejected it because it was complicated and it did not support ticket forwarding at that time.

We have a Kerberized RPC mechanism that facilitates data transfer between mainframe databases and client applications on UNIX workstations. Numerous critical applications use this facility to securely access the mainframe. This facility currently uses Kerberos 4, but we plan to migrate this code to use Kerberos 5 in the near future.

Our internal broadcast data distribution system is Kerberized. This allows us to limit access to market data as well as internal business data to authorized users. Applications built on top of this distribution system inherit the security built into it.

Kerberos also allows us to build a single signon solution for our Sybase servers. We have a Kerberized Sybase "password server" that stores Sybase passwords for users that are authorized to use a database. The Sybase client program securely retrieves this password using Kerberos based authentication and logs into Sybase before transferring control to the regular SQL program. Unfortunately, this mechanism is cumbersome and not useful for all applications.

6. Future Plans

We intend to extend our single sign-on capability to our mainframes as well using a feature known as 'passtickets'. During user authentication, the mainframe security system can be configured to accept a one time passticket instead of the regular user password. Such passtickets can be generated by a passticket server program running on a UNIX host. The mainframe terminal emulator program will be modified to use Kerberos to securely obtain a passticket, and then send it to the mainframe. The user will be automatically logged in by virtue of having a Kerberos ticket.

One of the criteria for selecting our vendor was the availability of Kerberos software on PCs. This should allow us to Kerberize our client-server applications that run on PCs. Kerberizing some PC desktop machines require a different strategy than was used for UNIX desktops. Many of our PCs are docking stations or laptops that often run disconnected from the network. It is not practical to Kerberize the screenlock on these PCs, because the KDC may not be online to verify the password.

Another goal is to make Kerberized HTTP available within the firm for use by internal applications. This would allow us to control access to sensitive data on our internal web servers using the existing Kerberos authentication infrastructure. Much of this work has been done but unfortunately is not available on the web browsers and servers that we use.

7. Conclusions

For Kerberos to succeed in mission-critical production environments, vendors need to think on a large scale. Tools appropriate for smaller environments are not always appropriate in environments where failure of a batch process could cost millions of dollars. Automation is crucial: we created tools to automate srvtab installation and to monitor the health of all Kerberos processes. Special attention was paid to incremental propagation stability. We also developed our own Kerberized cron mechanism. We integrated Kerberos seamlessly into the environment to minimize any user inconvenience. Finally, we changed the default maximum credential lifetime in the Kerberos database, as the default value was too short to be useful. These are some examples of enhancements we felt were essential in integrating vendor Kerberos products into Morgan Stanley's distributed computing infrastructure. We learned to make effective compromises between security, usability and administrability.

Crypto-based authentication systems should be well integrated into all aspects of modern operating systems, messaging systems, and distributed applications. Operating systems should ship with hooks in basic authentication programs and easy-to-use libraries for application use. Operating system vendors should design a general, highly configurable scheme to provide for alternate authentication mechanisms, such as Kerberos, SecureID, S/Key, etc. Our solution of defining '*' to mean a Kerberized user is not general enough. The Pluggable Authentication Module specification from Sun appears to be gaining industry acceptance; however, more work remains to be done in developing general and configurable authentication subsystems. The same applies to application vendors who supply mail agents, databases, groupware, and other applications. All should be provided with hooks or exits at critical points for customer provided authentication or authorization checks.

We spent approximately 2 person years to adequately integrate the vendor provided software into our environment. Many companies may be reluctant to devote this much effort to solve the authentication problem in a world of rapidly changing technology. However, Morgan Stanley’s strong commitment to open distributed systems, in balance with proper information security controls, justified this effort.

8. Acknowledgments

We thank James Anderson, David Bauer, Benjamin Fried, Douglas Kingston, and W. Phillip Moore for their helpful comments and suggestions during the course of this work.

9. References

1. M. Bellovin and M. Merritt, Limitations of the Kerberos Authentication System, in USENIX Conference Proceedings, pages 253-267 (Dallas, TX; Winter 1991).

2. D. Engert, Aklog and Kerberos 5, message to the info-afs@transarc.com mailinglist, 11/7/94

3. D. Engert, Aklog for Kerberos 5, message to the info-afs@transarc.com mailinglist, 1/17/95

4. X. Gittler, W. P. Moore, and J. Rambhasker, Morgan Stanley's Aurora System: Designing a Next Generation Global Production UNIX Environment, in Proceedings of the Ninth System Administration Conference (LISA ‘95) (September, 1995).

5. B. Lampson, M. Abadi, M. Burrows, and E. Wobber, Authentication in Distributed Systems: Theory and Practice, ACM Transactions on Computer Systems 10(4) (November, 1992)

6. J. Linn, Generic Security Service Application Program Interface, Internet RFC 1508, September, 1993

7. C. Neuman and J. Kohl, The Kerberos Network Authentication Service (V5), Internet RFC 1510, September 1993

8. A. D. Rubin and P. Honeyman, Long Running Jobs in an Authenticated Environment, Proc. 4^th USENIX UNIX Security Symposium, Santa Clara (October 1993)