_K_e_r_b_e_r_o_s: An Authentication Service for Open Network Systems Jennifer G. Steiner Project Athena Massachusetts Institute of Technology Cambridge, MA 02139 steiner@ATHENA.MIT.EDU Clifford Neuman|- Department of Computer Science, FR-35 University of Washington Seattle, WA 98195 bcn@CS.WASHINGTON.EDU Jeffrey I. Schiller Project Athena Massachusetts Institute of Technology Cambridge, MA 02139 jis@ATHENA.MIT.EDU _A_B_S_T_R_A_C_T In an open network computing environment, a workstation cannot be trusted to identify its users correctly to network services. _K_e_r_b_e_r_o_s provides an alternative approach whereby a trusted third-party authentication service is used to ver- ify users' identities. This paper gives an over- view of the _K_e_r_b_e_r_o_s authentication model as implemented for MIT's Project Athena. It describes the protocols used by clients, servers, and _K_e_r_b_e_r_o_s to achieve authentication. It also describes the management and replication of the database required. The views of _K_e_r_b_e_r_o_s as seen by the user, programmer, and administrator are described. Finally, the role of _K_e_r_b_e_r_o_s in the larger Athena picture is given, along with a list __________________________ |- Clifford Neuman was a member of the Project Athena staff during the design and initial implementation phase of _K_e_r_b_e_r_o_s. March 30, 1988 - 2 - of applications that presently use _K_e_r_b_e_r_o_s for user authentication. We describe the addition of _K_e_r_b_e_r_o_s authentication to the Sun Network File System as a case study for integrating _K_e_r_b_e_r_o_s with an existing application. _I_n_t_r_o_d_u_c_t_i_o_n This paper gives an overview of _K_e_r_b_e_r_o_s, an authenti- cation system designed by Miller and Neuman[1] for open net- work computing environments, and describes our experience using it at MIT's Project Athena.[2] In the first section of the paper, we explain why a new authentication model is needed for open networks, and what its requirements are. The second section lists the components of the _K_e_r_b_e_r_o_s software and describes how they interact in providing the authentication service. In Section 3, we describe the _K_e_r_- _b_e_r_o_s naming scheme. Section 4 presents the building blocks of _K_e_r_b_e_r_o_s authentication - the _t_i_c_k_e_t and the _a_u_t_h_e_n_t_i_c_a_t_o_r. This leads to a discussion of the two authentication protocols: the initial authentication of a user to _K_e_r_b_e_r_o_s (analogous to logging in), and the protocol for mutual authentication of a potential consumer and a potential producer of a net- work service. _K_e_r_b_e_r_o_s requires a database of information about its clients; Section 5 describes the database, its management, and the protocol for its modification. Section 6 describes the _K_e_r_b_e_r_o_s interface to its users, applications program- mers, and administrators. In Section 7, we describe how the Project Athena _K_e_r_b_e_r_o_s fits into the rest of the Athena environment. We also describe the interaction of different _K_e_r_b_e_r_o_s authentication domains, or _r_e_a_l_m_s; in our case, the relation between the Project Athena _K_e_r_b_e_r_o_s and the _K_e_r_- _b_e_r_o_s running at MIT's Laboratory for Computer Science. In Section 8, we mention open issues and problems as yet unsolved. The last section gives the current status of _K_e_r_b_e_r_o_s at Project Athena. In the appendix, we describe in detail how _K_e_r_b_e_r_o_s is applied to a network file service to authenticate users who wish to gain access to remote file systems. _C_o_n_v_e_n_t_i_o_n_s. Throughout this paper we use terms that may be ambiguous, new to the reader, or used differently elsewhere. Below we state our use of those terms. _U_s_e_r, _C_l_i_e_n_t, _S_e_r_v_e_r. By _u_s_e_r, we mean a human being who uses a program or service. A _c_l_i_e_n_t also uses March 30, 1988 - 3 - something, but is not necessarily a person; it can be a pro- gram. Often network applications consist of two parts; one program which runs on one machine and requests a remote ser- vice, and another program which runs on the remote machine and performs that service. We call those the _c_l_i_e_n_t side and _s_e_r_v_e_r side of the application, respectively. Often, a _c_l_i_e_n_t will contact a _s_e_r_v_e_r on behalf of a _u_s_e_r. Each entity that uses the _K_e_r_b_e_r_o_s system, be it a user or a network server, is in one sense a client, since it uses the _K_e_r_b_e_r_o_s service. So to distinguish _K_e_r_b_e_r_o_s clients from clients of other services, we use the term _p_r_i_n_c_i_p_a_l to indicate such an entity. Note that a _K_e_r_b_e_r_o_s principal can be either a user or a server. (We describe the naming of _K_e_r_b_e_r_o_s principals in a later section.) _S_e_r_v_i_c_e _v_s. _S_e_r_v_e_r. We use _s_e_r_v_i_c_e as an abstract specification of some actions to be performed. A process which performs those actions is called a _s_e_r_v_e_r. At a given time, there may be several _s_e_r_v_e_r_s (usually running on dif- ferent machines) performing a given _s_e_r_v_i_c_e. For example, at Athena there is one BSD UNIX _r_l_o_g_i_n server running on each of our timesharing machines. _K_e_y, _P_r_i_v_a_t_e _K_e_y, _P_a_s_s_w_o_r_d. _K_e_r_b_e_r_o_s uses private key encryption. Each _K_e_r_b_e_r_o_s principal is assigned a large number, its private key, known only to that principal and _K_e_r_b_e_r_o_s. In the case of a user, the private key is the result of a one-way function applied to the user's _p_a_s_s_w_o_r_d. We use _k_e_y as shorthand for _p_r_i_v_a_t_e _k_e_y. _C_r_e_d_e_n_t_i_a_l_s. Unfortunately, this word has a special meaning for both the Sun Network File System and the _K_e_r_- _b_e_r_o_s system. We explicitly state whether we mean NFS credentials or _K_e_r_b_e_r_o_s credentials, otherwise the term is used in the normal English language sense. _M_a_s_t_e_r _a_n_d _S_l_a_v_e. It is possible to run _K_e_r_b_e_r_o_s authentication software on more than one machine. However, there is always only one definitive copy of the _K_e_r_b_e_r_o_s database. The machine which houses this database is called the _m_a_s_t_e_r machine, or just the _m_a_s_t_e_r. Other machines may possess read-only copies of the _K_e_r_b_e_r_o_s database, and these are called _s_l_a_v_e_s. _1. _M_o_t_i_v_a_t_i_o_n In a non-networked personal computing environment, resources and information can be protected by physically securing the personal computer. In a timesharing computing environment, the operating system protects users from one another and controls resources. In order to determine what each user is able to read or modify, it is necessary for the timesharing system to identify each user. This is March 30, 1988 - 4 - accomplished when the user logs in. In a network of users requiring services from many separate computers, there are three approaches one can take to access control: One can do nothing, relying on the machine to which the user is logged in to prevent unauthor- ized access; one can require the host to prove its identity, but trust the host's word as to who the user is; or one can require the user to prove her/his identity for each required service. In a closed environment where all the machines are under strict control, one can use the first approach. When the organization controls all the hosts communicating over the network, this is a reasonable approach. In a more open environment, one might selectively trust only those hosts under organizational control. In this case, each host must be required to prove its identity. The _r_l_o_g_i_n and _r_s_h programs use this approach. In those proto- cols, authentication is done by checking the Internet address from which a connection has been established. In the Athena environment, we must be able to honor requests from hosts that are not under organizational con- trol. Users have complete control of their workstations: they can reboot them, bring them up standalone, or even boot off their own tapes. As such, the third approach must be taken; the user must prove her/his identity for each desired service. The server must also prove its identity. It is not sufficient to physically secure the host running a net- work server; someone elsewhere on the network may be masquerading as the given server. Our environment places several requirements on an iden- tification mechanism. First, it must be secure. Circum- venting it must be difficult enough that a potential attacker does not find the authentication mechanism to be the weak link. Someone watching the network should not be able to obtain the information necessary to impersonate another user. Second, it must be reliable. Access to many services will depend on the authentication service. If it is not reliable, the system of services as a whole will not be. Third, it should be transparent. Ideally, the user should not be aware of authentication taking place. Finally, it should be scalable. Many systems can communi- cate with Athena hosts. Not all of these will support our mechanism, but software should not break if they did. _K_e_r_b_e_r_o_s is the result of our work to satisfy the above requirements. When a user walks up to a workstation s/he ``logs in''. As far as the user can tell, this initial identification is sufficient to prove her/his identity to all the required network servers for the duration of the March 30, 1988 - 5 - login session. The security of _K_e_r_b_e_r_o_s relies on the secu- rity of several authentication servers, but not on the sys- tem from which users log in, nor on the security of the end servers that will be used. The authentication server pro- vides a properly authenticated user with a way to prove her/his identity to servers scattered across the network. Authentication is a fundamental building block for a secure networked environment. If, for example, a server knows for certain the identity of a client, it can decide whether to provide the service, whether the user should be given special privileges, who should receive the bill for the service, and so forth. In other words, authorization and accounting schemes can be built on top of the authenti- cation that _K_e_r_b_e_r_o_s provides, resulting in equivalent secu- rity to the lone personal computer or the timesharing sys- tem. _2. _W_h_a_t _i_s _K_e_r_b_e_r_o_s? _K_e_r_b_e_r_o_s is a trusted third-party authentication ser- vice based on the model presented by Needham and Schroeder.[3] It is trusted in the sense that each of its clients believes _K_e_r_b_e_r_o_s' judgement as to the identity of each of its other clients to be accurate. Timestamps (large numbers representing the current date and time) have been added to the original model to aid in the detection of _r_e_p_l_a_y. Replay occurs when a message is stolen off the net- work and resent later. For a more complete description of replay, and other issues of authentication, see Voydock and Kent.[4] _2._1. _W_h_a_t _D_o_e_s _I_t _D_o? _K_e_r_b_e_r_o_s keeps a database of its clients and their _p_r_i_v_a_t_e _k_e_y_s. The private key is a large number known only to _K_e_r_b_e_r_o_s and the client it belongs to. In the case that the client is a user, it is an encrypted password. Network services requiring authentication register with _K_e_r_b_e_r_o_s, as do clients wishing to use those services. The private keys are negotiated at registration. Because _K_e_r_b_e_r_o_s knows these private keys, it can create messages which convince one client that another is really who it claims to be. _K_e_r_b_e_r_o_s also generates tem- porary private keys, called _s_e_s_s_i_o_n _k_e_y_s, which are given to two clients and no one else. A session key can be used to encrypt messages between two parties. _K_e_r_b_e_r_o_s provides three distinct levels of protection. The application programmer determines which is appropriate, according to the requirements of the application. For exam- ple, some applications require only that authenticity be established at the initiation of a network connection, and March 30, 1988 - 6 - can assume that further messages from a given network address originate from the authenticated party. Our authen- ticated network file system uses this level of security. Other applications require authentication of each mes- sage, but do not care whether the content of the message is disclosed or not. For these, _K_e_r_b_e_r_o_s provides _s_a_f_e _m_e_s_- _s_a_g_e_s. Yet a higher level of security is provided by _p_r_i_v_a_t_e _m_e_s_s_a_g_e_s, where each message is not only authenti- cated, but also encrypted. Private messages are used, for example, by the _K_e_r_b_e_r_o_s server itself for sending passwords over the network. _2._2. _S_o_f_t_w_a_r_e _C_o_m_p_o_n_e_n_t_s The Athena implementation comprises several modules (see Figure 1). The _K_e_r_b_e_r_o_s applications library provides an interface for application clients and application servers. It contains, among others, routines for creating or reading authentication requests, and the routines for creating safe or private messages. o+ _K_e_r_b_e_r_o_s applications library o+ encryption library o+ database library o+ database administration programs o+ administration server o+ authentication server o+ db propagation software o+ user programs o+ applications Figure 1. _K_e_r_b_e_r_o_s Software Components. Encryption in _K_e_r_b_e_r_o_s is based on DES, the Data Encryption Standard.[5] The encryption library implements those routines. Several methods of encryption are provided, with tradeoffs between speed and security. An extension to the DES Cypher Block Chaining (CBC) mode, called the Pro- pagating CBC mode, is also provided. In CBC, an error is propagated only through the current block of the cipher, whereas in PCBC, the error is propagated throughout the mes- sage. This renders the entire message useless if an error occurs, rather than just a portion of it. The encryption library is an independent module, and may be replaced with other DES implementations or a different encryption library. Another replaceable module is the database management system. The current Athena implementation of the database library uses _n_d_b_m, although Ingres was originally used. Other database management libraries could be used as well. March 30, 1988 - 7 - The _K_e_r_b_e_r_o_s database needs are straightforward; a record is held for each principal, containing the name, private key, and expiration date of the principal, along with some administrative information. (The expiration date is the date after which an entry is no longer valid. It is usually set to a few years into the future at registration.) Other user information, such as real name, phone number, and so forth, is kept by another server, the _H_e_s_i_o_d nameserver.[6] This way, sensitive information, namely pass- words, can be handled by _K_e_r_b_e_r_o_s, using fairly high secu- rity measures; while the non-sensitive information kept by _H_e_s_i_o_d is dealt with differently; it can, for example, be sent unencrypted over the network. The _K_e_r_b_e_r_o_s servers use the database library, as do the tools for administering the database. The _a_d_m_i_n_i_s_t_r_a_t_i_o_n _s_e_r_v_e_r (or KDBM server) provides a read-write network interface to the database. The client side of the program may be run on any machine on the net- work. The server side, however, must run on the machine housing the _K_e_r_b_e_r_o_s database in order to make changes to the database. The _a_u_t_h_e_n_t_i_c_a_t_i_o_n _s_e_r_v_e_r (or _K_e_r_b_e_r_o_s server), on the other hand, performs read-only operations on the _K_e_r_b_e_r_o_s database, namely, the authentication of principals, and gen- eration of session keys. Since this server does not modify the _K_e_r_b_e_r_o_s database, it may run on a machine housing a read-only copy of the master _K_e_r_b_e_r_o_s database. Database propagation software manages replication of the _K_e_r_b_e_r_o_s database. It is possible to have copies of the database on several different machines, with a copy of the authentication server running on each machine. Each of these _s_l_a_v_e machines receives an update of the _K_e_r_b_e_r_o_s database from the _m_a_s_t_e_r machine at given intervals. Finally, there are end-user programs for logging in to _K_e_r_b_e_r_o_s, changing a _K_e_r_b_e_r_o_s password, and displaying or destroying _K_e_r_b_e_r_o_s _t_i_c_k_e_t_s (tickets are explained later on). _3. _K_e_r_b_e_r_o_s Names Part of authenticating an entity is naming it. The process of authentication is the verification that the client is the one named in a request. What does a name con- sist of? In _K_e_r_b_e_r_o_s, both users and servers are named. As far as the authentication server is concerned, they are equivalent. A name consists of a primary name, an instance, and a realm, expressed as _n_a_m_e._i_n_s_t_a_n_c_e@_r_e_a_l_m (see Figure 2). March 30, 1988 - 8 - bcn treese.root jis@LCS.MIT.EDU rlogin.priam@ATHENA.MIT.EDU Figure 2. _K_e_r_b_e_r_o_s Names. The _p_r_i_m_a_r_y _n_a_m_e is the name of the user or the ser- vice. The _i_n_s_t_a_n_c_e is used to distinguish among variations on the primary name. For users, an instance may entail spe- cial privileges, such as the ``root'' or ``admin'' instances. For services in the Athena environment, the instance is usually the name of the machine on which the server runs. For example, the _r_l_o_g_i_n service has different instances on different hosts: _r_l_o_g_i_n._p_r_i_a_m is the _r_l_o_g_i_n server on the host named priam. A _K_e_r_b_e_r_o_s ticket is only good for a single named server. As such, a separate ticket is required to gain access to different instances of the same service. The _r_e_a_l_m is the name of an administrative entity that maintains authentication data. For example, different institutions may each have their own _K_e_r_b_e_r_o_s machine, housing a different database. They have different _K_e_r_b_e_r_o_s realms. (Realms are discussed further in section 8.2.) _4. _H_o_w _I_t _W_o_r_k_s This section describes the _K_e_r_b_e_r_o_s authentication pro- tocols. The following abbreviations are used in the fig- ures. c -> client s -> server addr -> client's network address life -> lifetime of ticket tgs, TGS -> ticket-granting server Kerberos -> authentication server KDBM -> administration server Kx -> x's private key Kx,y -> session key for x and y {abc}Kx -> abc encrypted in x's key Tx,y -> x's ticket to use y Ax -> authenticator for x WS -> workstation As mentioned above, the _K_e_r_b_e_r_o_s authentication model is based on the Needham and Schroeder key distribution proto- col. When a user requests a service, her/his identity must March 30, 1988 - 9 - be established. To do this, a ticket is presented to the server, along with proof that the ticket was originally issued to the user, not stolen. There are three phases to authentication through _K_e_r_b_e_r_o_s. In the first phase, the user obtains credentials to be used to request access to other services. In the second phase, the user requests authentication for a specific service. In the final phase, the user presents those credentials to the end server. _4._1. _C_r_e_d_e_n_t_i_a_l_s There are two types of credentials used in the _K_e_r_b_e_r_o_s authentication model: _t_i_c_k_e_t_s and _a_u_t_h_e_n_t_i_c_a_t_o_r_s. Both are based on private key encryption, but they are encrypted using different keys. A ticket is used to securely pass the identity of the person to whom the ticket was issued between the authentication server and the end server. A ticket also passes information that can be used to make sure that the person using the ticket is the same person to which it was issued. The authenticator contains the additional informa- tion which, when compared against that in the ticket proves that the client presenting the ticket is the same one to which the ticket was issued. A ticket is good for a single server and a single client. It contains the name of the server, the name of the client, the Internet address of the client, a timestamp, a lifetime, and a random session key. This information is encrypted using the key of the server for which the ticket will be used. Once the ticket has been issued, it may be used multiple times by the named client to gain access to the named server, until the ticket expires. Note that because the ticket is encrypted in the key of the server, it is safe to allow the user to pass the ticket on to the server without having to worry about the user modifying the ticket (see Figure 3). {s, c, addr, timestamp, life, Ks,c}Ks Figure 3. A _K_e_r_b_e_r_o_s Ticket. Unlike the ticket, the authenticator can only be used once. A new one must be generated each time a client wants to use a service. This does not present a problem because the client is able to build the authenticator itself. An authenticator contains the name of the client, the workstation's IP address, and the current workstation time. The authenticator is encrypted in the session key that is part of the ticket (see Figure 4). March 30, 1988 - 10 - {c, addr, timestamp}Ks,c Figure 4. A _K_e_r_b_e_r_o_s Authenticator. _4._2. _G_e_t_t_i_n_g _t_h_e _I_n_i_t_i_a_l _T_i_c_k_e_t When the user walks up to a workstation, only one piece of information can prove her/his identity: the user's pass- word. The initial exchange with the authentication server is designed to minimize the chance that the password will be compromised, while at the same time not allowing a user to properly authenticate her/himself without knowledge of that password. The process of logging in appears to the user to be the same as logging in to a timesharing system. Behind the scenes, though, it is quite different (see Figure 5). linewid = 1.5i ellipsewid = .7i ellipse "Client" arrow "c, tgs" "" ellipse "Kerberos" linewid = 1.5i ellipsewid = .7i ellipse "Client" line <- "" "{Kc,tgs,{Tc,tgs} Ktgs}Kc" ellipse "Kerberos" Figure 5. Getting the Initial Ticket. The user is prompted for her/his username. Once it has been entered, a request is sent to the authentication server containing the user's name and the name of a special service known as the _t_i_c_k_e_t-_g_r_a_n_t_i_n_g _s_e_r_v_i_c_e. The authentication server checks that it knows about the client. If so, it generates a random session key which will later be used between the client and the ticket- granting server. It then creates a ticket for the ticket- granting server which contains the client's name, the name of the ticket-granting server, the current time, a lifetime for the ticket, the client's IP address, and the random ses- sion key just created. This is all encrypted in a key known only to the ticket-granting server and the authentication server. The authentication server then sends the ticket, along with a copy of the random session key and some additional information, back to the client. This response is encrypted in the client's private key, known only to _K_e_r_b_e_r_o_s and the client, which is derived from the user's password. March 30, 1988 - 11 - Once the response has been received by the client, the user is asked for her/his password. The password is con- verted to a DES key and used to decrypt the response from the authentication server. The ticket and the session key, along with some of the other information, are stored for future use, and the user's password and DES key are erased from memory. Once the exchange has been completed, the workstation possesses information that it can use to prove the identity of its user for the lifetime of the ticket-granting ticket. As long as the software on the workstation had not been pre- viously tampered with, no information exists that will allow someone else to impersonate the user beyond the life of the ticket. _4._3. _R_e_q_u_e_s_t_i_n_g _a _S_e_r_v_i_c_e For the moment, let us pretend that the user already has a ticket for the desired server. In order to gain access to the server, the application builds an authentica- tor containing the client's name and IP address, and the current time. The authenticator is then encrypted in the session key that was received with the ticket for the server. The client then sends the authenticator along with the ticket to the server in a manner defined by the indivi- dual application. Once the authenticator and ticket have been received by the server, the server decrypts the ticket, uses the session key included in the ticket to decrypt the authenticator, compares the information in the ticket with that in the authenticator, the IP address from which the request was received, and the present time. If everything matches, it allows the request to proceed (see Figure 6). linewid = 1.5i ellipsewid = .7i ellipse "Client" arrow "{Ac}Kc,s, {Tc,s}Ks" "" ellipse "Server" Figure 6. Requesting a Service. It is assumed that clocks are synchronized to within several minutes. If the time in the request is too far in the future or the past, the server treats the request as an attempt to replay a previous request. The server is also allowed to keep track of all past requests with timestamps that are still valid. In order to further foil replay attacks, a request received with the same ticket and time- stamp as one already received can be discarded. Finally, if the client specifies that it wants the March 30, 1988 - 12 - server to prove its identity too, the server adds one to the timestamp the client sent in the authenticator, encrypts the result in the session key, and sends the result back to the client (see Figure 7). linewid = 1.5i ellipsewid = .7i ellipse "Client" line <- "" "{timestamp + 1} Kc,s" ellipse "Server" Figure 7. Mutual Authentication. At the end of this exchange, the server is certain that, according to _K_e_r_b_e_r_o_s, the client is who it says it is. If mutual authentication occurs, the client is also convinced that the server is authentic. Moreover, the client and server share a key which no one else knows, and can safely assume that a reasonably recent message encrypted in that key originated with the other party. _4._4. _G_e_t_t_i_n_g _S_e_r_v_e_r _T_i_c_k_e_t_s Recall that a ticket is only good for a single server. As such, it is necessary to obtain a separate ticket for each service the client wants to use. Tickets for indivi- dual servers can be obtained from the ticket-granting ser- vice. Since the ticket-granting service is itself a ser- vice, it makes use of the service access protocol described in the previous section. When a program requires a ticket that has not already been requested, it sends a request to the ticket-granting server (see Figure 8). The request contains the name of the server for which a ticket is requested, along with the ticket-granting ticket and an authenticator built as described in the previous section. linewid = 1.7i ellipsewid = .7i ellipse "Client" arrow "s,{Tc,tgs}Ktgs,{Ac}Kc,tgs" "" ellipse "TGS" linewid = 1.7i ellipsewid = .7i ellipse "Client" line <- "" "{{Tc,s}Ks,Kc,s}Kc,tgs" ellipse "TGS" Figure 8. Getting a Server Ticket. The ticket-granting server then checks the authentica- tor and ticket-granting ticket as described above. If March 30, 1988 - 13 - valid, the ticket-granting server generates a new random session key to be used between the client and the new server. It then builds a ticket for the new server contain- ing the client's name, the server name, the current time, the client's IP address and the new session key it just gen- erated. The lifetime of the new ticket is the minimum of the remaining life for the ticket-granting ticket and the default for the service. The ticket-granting server then sends the ticket, along with the session key and other information, back to the client. This time, however, the reply is encrypted in the session key that was part of the ticket-granting ticket. This way, there is no need for the user to enter her/his password again. Figure 9 summarizes the authentication pro- tocols. circlerad = .32i Kerbie: circle at -1,1 "Kerberos" Client: circle at 0,0 "User/" "Client" TGS: circle at 1,1 "TGS" Server: circle at 1.75,0 "Server" arrow from Client.w to Kerbie.s "1 " below arrow from Kerbie.e to Client.n " 2" above arrow from Client.n to TGS.w "3" above arrow from TGS.s to Client.e "4" above arrow from Client.e to Server.w "5" above 1. Request for TGS ticket 2. Ticket for TGS 3. Request for Server ticket 4. Ticket for Server 5. Request for service Figure 9. Kerberos Authentication Protocols. _5. _T_h_e _K_e_r_b_e_r_o_s Database Up to this point, we have discussed operations requir- ing read-only access to the _K_e_r_b_e_r_o_s database. These opera- tions are performed by the authentication service, which can run on both master and slave machines (see Figure 10). March 30, 1988 - 14 - boxwid = .5i WS1: box move right WS2: box move right WS3: box move right Box1: box invis with .n at WS1.s-(0,.5i) Slave: box move right Master: box Titles: "WS" at WS1.n above "WS" at WS2.n above "WS" at WS3.n above "Slave" at Slave.s below "Master" at Master.s below Arrows: arrow from WS1.s to Slave.n arrow from WS2.s to Slave.n arrow from WS3.s to Slave.n arrow from WS1.s to Master.n arrow from WS2.s to Master.n arrow from WS3.s to Master.n Figure 10. Authentication Requests. In this section, we discuss operations that require write access to the database. These operations are per- formed by the administration service, called the _K_e_r_b_e_r_o_s Database Management Service (_K_D_B_M). The current implementa- tion stipulates that changes may only be made to the master _K_e_r_b_e_r_o_s database; slave copies are read-only. Therefore, the KDBM server may only run on the master _K_e_r_b_e_r_o_s machine (see Figure 11). March 30, 1988 - 15 - boxwid = .5i WS1: box move right WS2: box move right WS3: box move right Box1: box invis with .n at WS1.s-(0,.5i) Slave: box dashed move right Master: box Titles: "WS" at WS1.n above "WS" at WS2.n above "WS" at WS3.n above "Slave" at Slave.s below "Master" at Master.s below Arrows: arrow from WS1.s to Master.n arrow from WS2.s to Master.n arrow from WS3.s to Master.n Figure 11. Administration Requests. Note that, while authentication can still occur (on slaves), administration requests cannot be serviced if the master machine is down. In our experience, this has not presented a problem, as administration requests are infrequent. The KDBM handles requests from users to change their passwords. The client side of this program, which sends requests to the KDBM over the network, is the _k_p_a_s_s_w_d pro- gram. The KDBM also accepts requests from _K_e_r_b_e_r_o_s adminis- trators, who may add principals to the database, as well as change passwords for existing principals. The client side of the administration program, which also sends requests to the KDBM over the network, is the _k_a_d_m_i_n program. _5._1. _T_h_e _K_D_B_M _S_e_r_v_e_r The KDBM server accepts requests to add principals to the database or change the passwords for existing princi- pals. This service is unique in that the ticket-granting service will not issue tickets for it. Instead, the authen- tication service itself must be used (the same service that March 30, 1988 - 16 - is used to get a ticket-granting ticket). The purpose of this is to require the user to enter a password. If this were not so, then if a user left her/his workstation unat- tended, a passerby could walk up and change her/his password for them, something which should be prevented. Likewise, if an administrator left her/his workstation unguarded, a passerby could change any password in the system. When the KDBM server receives a request, it authorizes it by comparing the authenticated principal name of the requester of the change to the principal name of the target of the request. If they are the same, the request is per- mitted. If they are not the same, the KDBM server consults an access control list (stored in a file on the master _K_e_r_- _b_e_r_o_s system). If the requester's principal name is found in this file, the request is permitted, otherwise it is denied. By convention, names with a _N_U_L_L instance (the default instance) do not appear in the access control list file; instead, an admin instance is used. Therefore, for a user to become an administrator of _K_e_r_b_e_r_o_s an admin instance for that username must be created, and added to the access con- trol list. This convention allows an administrator to use a different password for _K_e_r_b_e_r_o_s administration then s/he would use for normal login. All requests to the KDBM program, whether permitted or denied, are logged. _5._2. _T_h_e _k_a_d_m_i_n and _k_p_a_s_s_w_d Programs Administrators of _K_e_r_b_e_r_o_s use the _k_a_d_m_i_n program to add principals to the database, or change the passwords of existing principals. An administrator is required to enter the password for their _a_d_m_i_n instance name when they invoke the _k_a_d_m_i_n program. This password is used to fetch a ticket for the KDBM server (see Figure 12). Kerbie: circle at -1,1 "Kerberos" Client: circle at 0,0 "User/" "Admin" KDBM: circle at 1,1 "KDBM" arrow from Client.w to Kerbie.s "1 " below arrow from Kerbie.e to Client.n " 2" above arrow from Client.ne to KDBM.sw "3" above 1. Request for KDBM ticket 2. Ticket for KDBM 3. _k_a_d_m_i_n or _k_p_a_s_s_w_d request Figure 12. Kerberos Administration Protocol. March 30, 1988 - 17 - Users may change their _K_e_r_b_e_r_o_s passwords using the _k_p_a_s_s_w_d program. They are required to enter their old pass- word when they invoke the program. This password is used to fetch a ticket for the KDBM server. _5._3. _D_a_t_a_b_a_s_e _R_e_p_l_i_c_a_t_i_o_n Each _K_e_r_b_e_r_o_s realm has a _m_a_s_t_e_r _K_e_r_b_e_r_o_s machine, which houses the master copy of the authentication database. It is possible (although not necessary) to have additional, read-only copies of the database on _s_l_a_v_e machines elsewhere in the system. The advantages of having multiple copies of the database are those usually cited for replication: higher availability and better performance. If the master machine is down, authentication can still be achieved on one of the slave machines. The ability to perform authentica- tion on any one of several machines reduces the probability of a bottleneck at the master machine. Keeping multiple copies of the database introduces the problem of data consistency. We have found that very simple methods suffice for dealing with inconsistency. The master database is dumped every hour. The database is sent, in its entirety, to the slave machines, which then update their own databases. A program on the master host, called _k_p_r_o_p, sends the update to a peer program, called _k_p_r_o_p_d, running on each of the slave machines (see Figure 13). First _k_p_r_o_p sends a checksum of the new database it is about to send. The checksum is encrypted in the _K_e_r_b_e_r_o_s master database key, which both the master and slave _K_e_r_b_e_r_o_s machines pos- sess. The data is then transferred over the network to the _k_p_r_o_p_d on the slave machine. The slave propagation server calculates a checksum of the data it has received, and if it matches the checksum sent by the master, the new information is used to update the slave's database. March 30, 1988 - 18 - boxwid = .75i Box1: box invis move right Master: box "" "kprop" move right Box3: box invis Slave1: box "kpropd" "" with .nw at Box1.sw-(0,.5i) move right Slave2: box "kpropd" "" move right Slave3: box "kpropd" "" Titles: "Master" at Master.n above "Slave" at Slave1.s below "Slave" at Slave2.s below "Slave" at Slave3.s below Arrows: arrow from Master.s to Slave1.n arrow from Master.s to Slave2.n arrow from Master.s to Slave3.n Figure 13. Database Propagation. All passwords in the _K_e_r_b_e_r_o_s database are encrypted in the master database key Therefore, the information passed from master to slave over the network is not useful to an eavesdropper. However, it is essential that only informa- tion from the master host be accepted by the slaves, and that tampering of data be detected, thus the checksum. _6. _K_e_r_b_e_r_o_s From the Outside Looking In The section will describe _K_e_r_b_e_r_o_s from the practical point of view, first as seen by the user, then from the application programmer's viewpoint, and finally, through the tasks of the _K_e_r_b_e_r_o_s administrator. _6._1. _U_s_e_r'_s _E_y_e _V_i_e_w If all goes well, the user will hardly notice that _K_e_r_- _b_e_r_o_s is present. In our UNIX implementation, the ticket- granting ticket is obtained from _K_e_r_b_e_r_o_s as part of the _l_o_g_i_n process. The changing of a user's _K_e_r_b_e_r_o_s password is part of the _p_a_s_s_w_d program. And _K_e_r_b_e_r_o_s tickets are March 30, 1988 - 19 - automatically destroyed when a user logs out. If the user's login session lasts longer than the life- time of the ticket-granting ticket (currently 8 hours), the user will notice _K_e_r_b_e_r_o_s' presence because the next time a _K_e_r_b_e_r_o_s-authenticated application is executed, it will fail. The _K_e_r_b_e_r_o_s ticket for it will have expired. At that point, the user can run the _k_i_n_i_t program to obtain a new ticket for the ticket-granting server. As when logging in, a password must be provided in order to get it. A user executing the _k_l_i_s_t command out of curiosity may be surprised at all the tickets which have silently been obtained on her/his behalf for services which require _K_e_r_- _b_e_r_o_s authentication. _6._2. _F_r_o_m _t_h_e _P_r_o_g_r_a_m_m_e_r'_s _V_i_e_w_p_o_i_n_t A programmer writing a _K_e_r_b_e_r_o_s application will often be adding authentication to an already existing network application consisting of a client and server side. We call this process ``Kerberizing'' a program. Kerberizing usually involves making a call to the _K_e_r_b_e_r_o_s library in order to perform authentication at the initial request for service. It may also involve calls to the DES library to encrypt mes- sages and data which are subsequently sent between applica- tion client and application server. The most commonly used library functions are _k_r_b__m_k__r_e_q on the client side, and _k_r_b__r_d__r_e_q on the server side. The _k_r_b__m_k__r_e_q routine takes as parameters the name, instance, and realm of the target server, which will be requested, and possibly a checksum of the data to be sent. The client then sends the message returned by the _k_r_b__m_k__r_e_q call over the network to the server side of the application. When the server receives this message, it makes a call to the library routine _k_r_b__r_d__r_e_q. The routine returns a judgement about the authenticity of the sender's alleged identity. If the application requires that messages sent between client and server be secret, then library calls can be made to _k_r_b__m_k__p_r_i_v (_k_r_b__r_d__p_r_i_v) to encrypt (decrypt) messages in the session key which both sides now share.[7] _6._3. _T_h_e _K_e_r_b_e_r_o_s Administrator's Job The _K_e_r_b_e_r_o_s administrator's job begins with running a program to initialize the database. Another program must be run to register essential principals in the database, such as the _K_e_r_b_e_r_o_s administrator's name with an _a_d_m_i_n instance. The _K_e_r_b_e_r_o_s authentication server and the administration server must be started up. If there are slave databases, the administrator must arrange that the programs to pro- pagate database updates from master to slaves be kicked off periodically. March 30, 1988 - 20 - After these initial steps have been taken, the adminis- trator manipulates the database over the network, using the _k_a_d_m_i_n program. Through that program, new principals can be added, and passwords can be changed. In particular, when a new _K_e_r_b_e_r_o_s application is added to the system, the _K_e_r_b_e_r_o_s administrator must take a few steps to get it working. The server must be registered in the database, and assigned a private key (usually this is an automatically generated random key). Then, some data (including the server's key) must be extracted from the database and installed in a file on the server's machine. The default file is /_e_t_c/_s_r_v_t_a_b. The _k_r_b__r_d__r_e_q library routine called by the server (see the previous section) uses the information in that file to decrypt messages sent encrypted in the server's private key. The /_e_t_c/_s_r_v_t_a_b file authenticates the server as a password typed at a terminal authenticates the user. The _K_e_r_b_e_r_o_s administrator must also ensure that _K_e_r_- _b_e_r_o_s machines are physically secure, and would also be wise to maintain backups of the Master database.[8] _7. _T_h_e _B_i_g_g_e_r _P_i_c_t_u_r_e In this section, we describe how _K_e_r_b_e_r_o_s fits into the Athena environment, including its use by other network ser- vices and applications, and how it interacts with remote _K_e_r_b_e_r_o_s realms. For a more complete description of the Athena environment, please see G. W. Treese.[9] _7._1. _O_t_h_e_r _N_e_t_w_o_r_k _S_e_r_v_i_c_e_s' _U_s_e _o_f _K_e_r_b_e_r_o_s Several network applications have been modified to use _K_e_r_b_e_r_o_s. The _r_l_o_g_i_n and _r_s_h commands first try to authen- ticate using _K_e_r_b_e_r_o_s. A user with valid _K_e_r_b_e_r_o_s tickets can rlogin to another Athena machine without having to set up ._r_h_o_s_t_s files. If the _K_e_r_b_e_r_o_s authentication fails, the programs fall back on their usual methods of authorization, in this case, the ._r_h_o_s_t_s files. We have modified the Post Office Protocol to use _K_e_r_- _b_e_r_o_s for authenticating users who wish to retrieve their electronic mail from the ``post office''. A message delivery program, called _Z_e_p_h_y_r, has been recently developed at Athena, and it uses _K_e_r_b_e_r_o_s for authentication as well.[10] The program for signing up new users, called _r_e_g_i_s_t_e_r, uses both the Service Management System (SMS)[11] and _K_e_r_- _b_e_r_o_s. From SMS, it determines whether the information entered by the would-be new Athena user, such as name and MIT identification number, is valid. It then checks with _K_e_r_b_e_r_o_s to see if the requested username is unique. If all March 30, 1988 - 21 - goes well, a new entry is made to the _K_e_r_b_e_r_o_s database, containing the username and password. For a detailed discussion of the use of _K_e_r_b_e_r_o_s to secure Sun's Network File System, please refer to the appen- dix. _7._2. _I_n_t_e_r_a_c_t_i_o_n _w_i_t_h _O_t_h_e_r _K_e_r_b_e_r_i It is expected that different administrative organiza- tions will want to use _K_e_r_b_e_r_o_s for user authentication. It is also expected that in many cases, users in one organiza- tion will want to use services in another. _K_e_r_b_e_r_o_s sup- ports multiple administrative domains. The specification of names in _K_e_r_b_e_r_o_s includes a field called the _r_e_a_l_m. This field contains the name of the administrative domain within which the user is to be authenticated. Services are usually registered in a single realm and will only accept credentials issued by an authentication server for that realm. A user is usually registered in a single realm (the local realm), but it is possible for her/him to obtain credentials issued by another realm (the remote realm), on the strength of the authentication pro- vided by the local realm. Credentials valid in a remote realm indicate the realm in which the user was originally authenticated. Services in the remote realm can choose whether to honor those credentials, depending on the degree of security required and the level of trust in the realm that initially authenticated the user. In order to perform cross-realm authentication, it is necessary that the administrators of each pair of realms select a key to be shared between their realms. A user in the local realm can then request a ticket-granting ticket from the local authentication server for the ticket-granting server in the remote realm. When that ticket is used, the remote ticket-granting server recognizes that the request is not from its own realm, and it uses the previously exchanged key to decrypt the ticket-granting ticket. It then issues a ticket as it normally would, except that the realm field for the client contains the name of the realm in which the client was originally authenticated. This approach could be extended to allow one to authen- ticate oneself through a series of realms until reaching the realm with the desired service. In order to do this, though, it would be necessary to record the entire path that was taken, and not just the name of the initial realm in which the user was authenticated. In such a situation, all that is known by the server is that A says that B says that C says that the user is so-and-so. This statement can only be trusted if everyone along the path is also trusted. March 30, 1988 - 22 - _8. _I_s_s_u_e_s _a_n_d _O_p_e_n _P_r_o_b_l_e_m_s There are a number of issues and open problems associ- ated with the _K_e_r_b_e_r_o_s authentication mechanism. Among the issues are how to decide the correct lifetime for a ticket, how to allow proxies, and how to guarantee workstation integrity. The ticket lifetime problem is a matter of choosing the proper tradeoff between security and convenience. If the life of a ticket is long, then if a ticket and its associ- ated session key are stolen or misplaced, they can be used for a longer period of time. Such information can be stolen if a user forgets to log out of a public workstation. Alternatively, if a user has been authenticated on a system that allows multiple users, another user with access to root might be able to find the information needed to use stolen tickets. The problem with giving a ticket a short lifetime, however, is that when it expires, the user will have to obtain a new one which requires the user to enter the pass- word again. An open problem is the proxy problem. How can an authenticated user allow a server to acquire other network services on her/his behalf? An example where this would be important is the use of a service that will gain access to protected files directly from a fileserver. Another example of this problem is what we call _a_u_t_h_e_n_t_i_c_a_t_i_o_n _f_o_r_w_a_r_d_i_n_g. If a user is logged into a workstation and logs in to a remote host, it would be nice if the user had access to the same services available locally, while running a program on the remote host. What makes this difficult is that the user might not trust the remote host, thus authentication for- warding is not desirable in all cases. We do not presently have a solution to this problem. Another problem, and one that is important in the Athena environment, is how to guarantee the integrity of the software running on a workstation. This is not so much of a problem on private workstations since the user that will be using it has control over it. On public workstations, how- ever, someone might have come along and modified the _l_o_g_i_n program to save the user's password. The only solution presently available in our environment is to make it diffi- cult for people to modify software running on the public workstations. A better solution would require that the user's key never leave a system that the user knows can be trusted. One way this could be done would be if the user possessed a _s_m_a_r_t_c_a_r_d capable of doing the encryptions required in the authentication protocol. March 30, 1988 - 23 - _9. _S_t_a_t_u_s A prototype version of _K_e_r_b_e_r_o_s went into production in September of 1986. Since January of 1987, _K_e_r_b_e_r_o_s has been Project Athena's sole means of authenticating its 5,000 users, 650 workstations, and 65 servers. In addition, _K_e_r_- _b_e_r_o_s is now being used in place of ._r_h_o_s_t_s files for con- trolling access in several of Athena's timesharing systems. _1_0. _A_c_k_n_o_w_l_e_d_g_e_m_e_n_t_s _K_e_r_b_e_r_o_s was initially designed by Steve Miller and Clifford Neuman with suggestions from Jeff Schiller and Jerry Saltzer. Since that time, numerous other people have been involved with the project. Among them are Jim Aspnes, Bob Baldwin, John Barba, Richard Basch, Jim Bloom, Bill Bryant, Mark Colan, Rob French, Dan Geer, John Kohl, John Kubiatowicz, Bob Mckie, Brian Murphy, John Ostlund Ken Rae- burn, Chris Reed, Jon Rochlis, Mike Shanzer, Bill Sommer- feld, Ted T'so, Win Treese, and Stan Zanarotti. We are grateful to Dan Geer, Kathy Lieben, Josh Lubarr, Ken Raeburn, Jerry Saltzer, Ed Steiner, Robbert van Renesse, and Win Treese whose suggestions much improved earlier drafts of this paper. The illustration on the title page is by Betsy Bruem- mer. March 30, 1988 - 24 - _A_p_p_e_n_d_i_x _K_e_r_b_e_r_o_s Application to SUN's Network File System (NFS) A key component of the Project Athena workstation sys- tem is the interposing of the network between the user's workstation and her/his private file storage (home direc- tory). All private storage resides on a set of computers (currently VAX 11/750s) that are dedicated to this purpose. This allows us to offer services on publicly available UNIX workstations. When a user logs in to one of these publicly available workstations, rather then validate her/his name and password against a locally resident password file, we use _K_e_r_b_e_r_o_s to determine her/his authenticity. The _l_o_g_i_n program prompts for a username (as on any UNIX system). This username is used to fetch a _K_e_r_b_e_r_o_s ticket-granting ticket. The _l_o_g_i_n program uses the password to generate a DES key for decrypting the ticket. If decryption is suc- cessful, the user's home directory is located by consulting the _H_e_s_i_o_d naming service and mounted through NFS. The _l_o_g_i_n program then turns control over to the user's shell, which then can run the traditional per-user customization files because the home directory is now ``attached'' to the workstation. The _H_e_s_i_o_d service is also used to construct an entry in the local password file. (This is for the bene- fit of programs that look up information in /_e_t_c/_p_a_s_s_w_d.) From several options for delivery of remote file ser- vice, we chose SUN's Network File System. However this sys- tem fails to mesh with our needs in a crucial way. NFS assumes that all workstations fall into two categories (as viewed from a file server's point of view): trusted and untrusted. Untrusted systems cannot access any files at all, trusted can. Trusted systems are completely trusted. It is assumed that a trusted system is managed by friendly management. Specifically, it is possible from a trusted workstation to masquerade as any valid user of the file ser- vice system and thus gain access to just about every file on the system. (Only files owned by ``root'' are exempted.) In our environment, the management of a workstation (in the traditional sense of UNIX system management) is in the hands of the user currently using it. We make no secret of the root password on our workstations, as we realize that a truly unfriendly user can break in by the very fact that s/he is sitting in the same physical location as the machine and has access to all console functions. Therefore we can- not truly trust our workstations in the NFS interpretation of trust. To allow proper access controls in our environ- ment we had to make some modifications to the base NFS March 30, 1988 software, and integrate _K_e_r_b_e_r_o_s into the scheme. - 25 - _U_n_m_o_d_i_f_i_e_d _N_F_S In the implementation of NFS that we started with (from the University of Wisconsin), authentication was provided in the form of a piece of data included in each NFS request (called a ``credential'' in NFS terminology). This creden- tial contains information about the unique user identifier (UID) of the requester and a list of the group identifiers (GIDs) of the requester's membership. This information is then used by the NFS server for access checking. The difference between a trusted and a non-trusted workstation is whether or not its credentials are accepted by the NFS server.[12] _M_o_d_i_f_i_e_d _N_F_S In our environment, NFS servers must accept credentials from a workstation if and only if the credentials indicate the UID of the workstation's user, and no other. One obvious solution would be to change the nature of credentials from mere indicators of UID and GIDs to full blown _K_e_r_b_e_r_o_s authenticated data. However a significant performance penalty would be paid if this solution were adopted. Credentials are exchanged on every NFS operation including all disk read and write activities. Including a _K_e_r_b_e_r_o_s authentication on each disk transaction would add a fair number of full-blown encryptions (done in software) per transaction and, according to our envelope calculations, would have delivered unacceptable performance. (It would also have required placing the _K_e_r_b_e_r_o_s library routines in the kernel address space.) We needed a hybrid approach, described below. The basic idea is to have the NFS server map credentials received from client workstations, to a valid (and possibly different) credential on the server system. This mapping is performed in the server's kernel on each NFS transaction and is setup at ``mount'' time by a user-level process that engages in _K_e_r_b_e_r_o_s- moderated authentication prior to establishing a valid kernel credential mapping. To implement this we added a new system call to the kernel (required only on server systems, not on client sys- tems) that provides for the control of the mapping function that maps incoming credentials from client workstations to credentials valid for use on the server (if any). The basic mapping function maps the tuple: to a valid NFS credential on the server system. The CLIENT-IP-ADDRESS is extracted from the NFS request packet and the UID-ON-CLIENT is extracted from the credential March 30, 1988 supplied by the client system. Note: all information in the client-generated credential except the UID-ON-CLIENT is dis- carded. - 26 - If no mapping exists, the server reacts in one of two ways, depending it is configured. In our friendly confi- guration we default the unmappable requests into the creden- tials for the user ``nobody'' who has no privileged access and has a unique UID. Unfriendly servers return an NFS access error when no valid mapping can be found for an incoming NFS credential. Our new system call is used to add and delete entries from the kernel resident map. It also provides the ability to flush all entries that map to a specific UID on the server system, or flush all entries from a given CLIENT-IP-ADDRESS. We modified the mount daemon (which handles NFS mount requests on server systems) to accept a new transaction type, the _K_e_r_b_e_r_o_s authentication mapping request. Basi- cally, as part of the mounting process, the client system provides a _K_e_r_b_e_r_o_s authenticator along with an indication of her/his UID-ON-CLIENT (encrypted in the _K_e_r_b_e_r_o_s authen- ticator) on the workstation. The server's mount daemon con- verts the _K_e_r_b_e_r_o_s principal name into a local username. This username is then looked up in a special file to yield the user's UID and GIDs list. For efficiency, this file is a _n_d_b_m database file with the username as the key. From this information, an NFS credential is constructed and handed to the kernel as the valid mapping of the tuple for this request. At unmount time a request is sent to the mount daemon to remove the previously added mapping from the kernel. It is also possible to send a request at logout time to invali- date all mapping for the current user on the server in ques- tion, thus cleaning up any remaining mappings that exist (though they shouldn't) before the workstation is made available for the next user. _S_e_c_u_r_i_t_y _I_m_p_l_i_c_a_t_i_o_n_s _o_f _t_h_e _M_o_d_i_f_i_e_d _N_F_S This implementation is not completely secure. For starters, user data is still sent across the network in an unencrypted, and therefore interceptable, form. The low- level, per-transaction authentication is based on a pair provided unencrypted in the request packet. This information could be forged and thus security compromised. However, it should be noted that only while a user is actively using her/his files (i.e., while logged in) are valid mappings in place and therefore this form of attack is limited to when the user in question is logged in. When a user is not logged in, no amount of IP address forgery will permit unauthorized access to her/his files. March 30, 1988 _R_e_f_e_r_e_n_c_e_s - 27 - 1. S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, _S_e_c_t_i_o_n _E._2._1: _K_e_r_b_e_r_o_s _A_u_t_h_e_n_t_i_c_a_t_i_o_n _a_n_d _A_u_t_h_o_r_i_z_a_t_i_o_n _S_y_s_t_e_m, M.I.T. Project Athena, Cambridge, Massachusetts (December 21, 1987). 2. E. Balkovich, S. R. Lerman, and R. P. Parmelee, "Com- puting in Higher Education: The Athena Experience," _C_o_m_m_u_n_i_c_a_t_i_o_n_s _o_f _t_h_e _A_C_M, Vol. 28(11), pp. 1214-1224, ACM (November, 1985). 3. R. M. Needham and M. D. Schroeder, "Using Encryption for Authentication in Large Networks of Computers," _C_o_m_m_u_n_i_c_a_t_i_o_n_s _o_f _t_h_e _A_C_M, Vol. 21(12), pp. 993-999 (December, 1978). 4. V. L. Voydock and S. T. Kent, "Security Mechanisms in High-Level Network Protocols," _C_o_m_p_u_t_i_n_g _S_u_r_v_e_y_s, Vol. 15(2), ACM (June 1983). 5. National Bureau of Standards, "Data Encryption Stan- dard," Federal Information Processing Standards Publi- cation 46, Government Printing Office, Washington, D.C. (1977). 6. S. P. Dyer, "Hesiod," in _U_s_e_n_i_x _C_o_n_f_e_r_e_n_c_e _P_r_o_c_e_e_d_i_n_g_s (Winter, 1988). 7. W. J. Bryant, _K_e_r_b_e_r_o_s _P_r_o_g_r_a_m_m_e_r'_s _T_u_t_o_r_i_a_l, M.I.T. Project Athena (In preparation). 8. W. J. Bryant, _K_e_r_b_e_r_o_s _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _M_a_n_u_a_l, M.I.T. Project Athena (In preparation). 9. G. W. Treese, "Berkeley Unix on 1000 Workstations: Athena Changes to 4.3BSD," in _U_s_e_n_i_x _C_o_n_f_e_r_e_n_c_e _P_r_o_c_e_e_d_i_n_g_s (Winter, 1988). 10. C. A. DellaFera, M. W. Eichin, R. S. French, D. C. Jed- linsky, J. T. Kohl, and W. E. Sommerfeld, "The Zephyr Notification System," in _U_s_e_n_i_x _C_o_n_f_e_r_e_n_c_e _P_r_o_c_e_e_d_i_n_g_s (Winter, 1988). 11. M. A. Rosenstein, D. E. Geer, and P. J. Levine, in _U_s_e_n_i_x _C_o_n_f_e_r_e_n_c_e _P_r_o_c_e_e_d_i_n_g_s (Winter, 1988). 12. R. Sandberg, D. Goldberg, S. Kleiman, D. Walsh, and B. Lyon, "Design and Implementation of the Sun Network Filesystem," in _U_s_e_n_i_x _C_o_n_f_e_r_e_n_c_e _P_r_o_c_e_e_d_i_n_g_s (Summer, 1985). March 30, 1988