PROJECT ATHENA TECHNICAL PLAN Section E.2.1 Kerberos Authentication and Authorization System by S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer ________ _ ___ _____ ___ __ @g; also spelled Cerberus. "n. The watch dog of _____ _____ ____ __ ___ __ _____ ___ ________ _______ ____ __ Hades, whose duty it was to guard the entrance--against whom or ____ ____ ___ _______ ______ __ _____ __ ____ ___ _____ what does not clearly appear; . . . is known to have had three _____ heads. . ." ___ ________ _____ _ __________ -Ambrose Bierce, The Enlarged Devil's Dictionary This document describes the assumptions, short and long term goals, and system model for a network authentication system, named Kerberos, for the Athena environment. An appendix specifies the detailed design and 1 protocols to support these goals, and a set of UNIX manual pages, not included here, describes an implementation for Berkeley 4.3 UNIX of both user interface commands and also library interfaces for clients and servers. The next section of the technical plan, E.2.2, describes a set of network applications that use Kerberos for authentication. ___________ DEFINITIONS Accounting Measuring resource usage attributable to a particular client. Authentication Verifying the claimed identity of a client or service. _______________ 1 UNIX is a trademark of AT&T Bell Laboratories. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 Copyright (C) 1985, 1986, 1987 by the Massachusetts Institute of Technology ______ _________ ____ _______ _ _ _ ____ _ Athena Technical Plan Section E.2.1, page 2 Authorization Allowing an authenticated client to use a particular service. Client A program that makes use of a network service, on behalf of a user. KDBM Kerberos Data Base Manager, a system that maintains and provides an interface for update of authoritative Kerberos data consisting of principal identifiers and private keys for both clients and services. Kerberos Aside from the 3-headed dog guarding Hades, the name given to the Athena authentication service, the protocol used by that service, and the libraries used to invoke the authentication and authorization services. KKDS Kerberos Key Distribution Service, a network service that supplies tickets and temporary session keys; or Kerberos Key Distribution Server, an instance of that service. Principal A uniquely named client or server instance that participates in a network communication. Principal identifier The name used to uniquely identify each different client and server. Private key An encryption key between a principal and the KKDS, distributed outside the system, with a long lifetime; Seal To encipher a record containing several fields, in such a way that the fields cannot be individually replaced without either knowledge of the key or leaving evidence of tampering. Session key A temporary encryption key used between two principals, with a lifetime limited to the duration of a single communications "session". Ticket A record that authenticates a client to a service; it contains the client's identity, a session key, and a timestamp, all of which is sealed by encryption using the service's private key. ___ ____ _________ _____ ________ ______ __ ________ ____ ___ ____ The term "principal," being somewhat formal, is replaced with the word ____ __ ____ ________ ________ ___ _______ _______ ____ _____ _______ "user" in this document wherever the context permits that usage without _________ confusion. 1. Introduction to Kerberos ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ _ Athena Technical Plan Section E.2.1, page 3 _______ __ ____ ____ PURPOSE OF THIS PLAN Most conventional time-sharing systems require a prospective user to identify him or herself and to authenticate that identity before using its services. In an environment consisting of a network that connects prospective clients with services, a network service has a corresponding need to identify and authenticate its clients. When the client is a user of a time-sharing system, one approach is for the service to trust the authentication that was performed by the time-sharing system. For example, ___ ___ the network applications lpr and rcp provided with Berkeley 4.3 UNIX trust the user's time-sharing system to reliably authenticate its clients. In contrast with the time-sharing system, in which a protection wall separates the operating system from its users, a workstation is under the complete control of its user, to the extent that the user can run a private version of the operating system, or even replace the machine itself. As a result, a network service cannot rely on the integrity of the workstation operating system when it (the network service) performs authentication. This plan extends the conventional notions of authentication, authorization, and accounting to the network environment with untrusted workstations. It establishes a trusted third-party service named Kerberos that can perform authentication to the mutual satisfaction of both clients and services. The authentication approach allows for integration with authorization and accounting facilities. The resulting design is also applicable to a mixed time-sharing/network environment in which a network service is not willing to rely on the authentication performed by the client's time-sharing system. _____ __ ________ GOALS OF KERBEROS ______________ Authentication Authentication is not an end in itself, but rather a tool to support both integrity and authorization. Its basic purpose is to prevent fraudulent connection requests. The goal of Kerberos is to support both one-way and mutual authentication of principals, to the granularity of at least an individual user and specific service instance. _____________ Authorization Authentication can imply a coarse-grained authorization-for example, some services may allow anyone who can be reliably authenticated by the local Kerberos to use the service. In cases where more selective authorization is needed, the goal of Kerberos is to allow different services to implement different authorization models, and to allow those authorization models to assume that authentication of user identities is reliable. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ _ Athena Technical Plan Section E.2.1, page 4 __________ Accounting Given an authenticated client, the goal of accounting is to support either quotas charged against the client (to limit consumption), e.g. disk quota, and/or charges based on consumption, e.g. $.01 per page printed. The goal of Kerberos is to permit modular attachment of an integrated, secure, reliable accounting system. ___________ ________ REQUIREMENT EXAMPLES Some examples of network services best illustrate the requirements of user authentication and authorization: - Printing-Only members of a certain group may use a printer that belongs to that group, an expensive and relatively scarce shared resource. On a more public printer, users may be billed for printing, and may have a priori limits on their use. - Remote File Access-Only designated users may perform operations on a given remote file system or virtual disk. Different users may have different permissions allowed, e.g. only the owner may write, while others may read. ______ - Remote Login-Only authorized users may rlogin to centrally- managed hosts, or to a private workstation. - Window system-The user of a network-driven display may want to limit the ability of others to create or manipulate windows on that display. - Mail-Only the addressee should be able to pick up his or her own mail at the Post Office. - Service Management service-Users may be authorized to create, modify, or destroy records that control various services. For example, system administrators may have unlimited privileges, while the teaching assistant for a subject may only be allowed to authorize use of the libraries belonging to the subject. A user may be able to add or delete his or her own name on a public mailing list, but not to affect any other user's record in that list. _____ ____________ _______ __ ___ ______ Other_Requirements_Assumed_by_the_Design - The authentication requirement is two-way. That is, the service learns with confidence who the client is, and the client, if it wishes, can be certain that the correct service is being used. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ _ Athena Technical Plan Section E.2.1, page 5 - No cleartext passwords should be transmitted over the net; - No cleartext passwords should be stored on servers; - At clients, cleartext passwords should be handled for the shortest possible time and then destroyed. - The design should confine any authentication compromises to the current session or the current user. - Authentication has a limited lifetime, of the order of a single login session, but may be re-used within that lifetime; - Network authentication should go on largely unnoticed in normal cases; the traditional model of password-mediated login should be the only point that the user notices that authentication is occurring. - The design should minimize the effort needed to modify network services that previously used other means of authentication. ______ ___________ _____________ Future_requirement_possibilities The following are not currently considered essential, but may be re-evaluated as experience increases: - Forwarding of authentications, so that one service can do part of a job, then invoke another service to complete it, under the credentials of the original client. ______ - Revocation of authentication or authorization within a login session. 2. Assumptions Surrounding Authentication _______ ________ ___ ___________ ________ ___________ ASSUMED PHYSICAL AND OPERATIONAL SECURITY ENVIRONMENT From a security perspective, the environment will include: - both public and private workstations. Public workstations are in areas with minimal physical security; private workstations are under physical and administrative control of individuals with no responsibility to central network administration. - a campus network without link encryption, composed of local nets of varying types linked by gateways to a backbone net; the local ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ _ Athena Technical Plan Section E.2.1, page 6 nets are widely dispersed physically and thus are very vulnerable to security attacks; the backbone and gateways are in locked closets and therefore are moderately secure. - centrally-operated servers in locked rooms, assumed to operate under moderate physical security with known legitimate software; - a small number of centrally-operated servers, such as the Kerberos authentication server, that operate under considerable physical security. ________ _______ ___ _____ RELEVANT THREATS AND RISKS The environment is not appropriate for sensitive data or high risk operations, such as bank transactions, classified government data, student grades, controlling dangerous experiments, and such. The risks are primarily uncontrolled use of resources by unauthorized parties, violations of the integrity of either the system's or user's resources, and wholesale violations of privacy such as casual browsing through personal files. The primary security threats result from the potential of a workstation user to forge the identity of another user in order to gain unauthorized access to data and/or resources. Since a workstation, including its operating system and network interface, is under the complete control of the user, the user can attempt to masquerade as another user or even as another host. In lieu of the authentication provided by a centrally ______________ _______ administered time sharing system, an authentication service is required to counter such attempts. Privacy of data being transported across the network is currently a low priority, except where it is necessary to prevent subsequent violations of integrity, e.g. the transmission of passwords. When the cost of providing communications privacy can be significantly reduced, it will attain higher priority. Traffic analysis and covert channels are not an issue. ___________ _____ __________ ASSUMPTIONS ABOUT ENCRYPTION The private-key Data Encryption Standard (DES), when used in single-encryption mode, is assumed to provide enough security for campus applications that cryptanalysis is not a significant threat. DES implementations are available in both hardware and software. Because system-integrated hardware implementations are not yet sufficiently low in cost, it is assumed that software implementations will be used for Kerberos except optionally at a small number of sites (Key Distribution Servers) that do a lot of encryption. DES implementations may not be exported from the U.S. without special license. For this reason, the Kerberos design makes the cryptosystem a ___ _______ ______________ __ ________ __ _____ modular, replaceable unit. The initial implementation of Kerberos is based __ ___ on DES. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ _ Athena Technical Plan Section E.2.1, page 7 ______ _____ ____________ GLOBAL CLOCK AVAILABILITY The design of Kerberos assumes that system clocks are loosely synchronized-within a few minutes-on all machines that run Kerberos- ______ ____ authenticated services, and that this global time is similarly available to all workstations that use Kerberos. We do not assume that all workstations correctly maintain the time, but in order to request authentication tickets, a workstation is required to maintain its clock within the ___________ allowable margin. Timeservers provide the official time, and other systems synchronize periodically, for example, at system boot time. _______ __________ ______ SERVICE MANAGEMENT SYSTEM This plan connects with the Athena Service Management System in a several ways. The Athena Service Management System provides authoritative information for Kerberos as well as the related naming system. 3. Naming This plan assumes a means for numbering network hosts and service ports so that clients may request connection to services, including Kerberos itself. If a naming system for services is also available, it is important that the service names can be congruent with Kerberos principal identifiers (defined in the next paragraph) that are used to authenticate services. In addition, Kerberos clients can make use of such a name service to locate Kerberos service itself. The design of Kerberos is modular; it can operate (somewhat less conveniently) in the absence of name services, and it does _ _______ _______ ____ not require that the name service itself be secure. A general network name _______ ______ __ ____ __ ______ ___________ _________ __ _______ service, Hesiod, is also an Athena development, described in another _________ ____ _______ Technical Plan section. In addition to such network host and service name spaces, Kerberos itself defines a name space of authenticated users and services. For use in authentication the following simple naming model applies. ________ _____ Unifying_Names There isn't much difference between a client and a service. In fact, a service that wants to use an authorization server must be able to authenticate itself to the authorization server in the same manner a client would authenticate itself to a service. For this reason both client and service names share the same structure so that they can be interchanged as necessary. _________ __________ A principal identifier consists of three components: _________ ____ - a principal name ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ _ Athena Technical Plan Section E.2.1, page 8 ________ ____ - an instance name _____ ____ - a realm name all three of which are strings of upper and lower case letters and numbers. Each different client and service has a unique principal name, assigned by negotiation with the manager of Kerberos. The instance name is a label that permits the possibility that the same client or service may exist in several forms that require distinct authentication; it is useful for both clients and services. In the case of services, an instance may specify the host that provides the service. For ______ ________ ______ example, the rlogin service on host menelaus is distinct from the rlogin ________ service on host tartaros. For client principals the instance can be useful when one wishes to have different identifiers for different privileges. _______ _____ _____________ For example, JLSmith operating as a class-administrator may have different _______ privileges from JLSmith operating as a normal user. The usual case is that users operate using a name with the null instance. To allow independently administered sites, such as Athena, the M.I.T. administrative services, and the M.I.T. Laboratory for Computer Science, to _____ inter-operate using Kerberos, a realm name is defined to identify each such _________ ____ ________ ____ independent Kerberos site. Thus a {principal name, instance name } is _____ ____ qualified by the realm name to which it belongs, and is unique only within that realm. Kerberos does not specify any constraints on the form of the realm name; it can be defined to be an ARPA internet domain name which is itself a qualified hierarchical name. That choice makes it possible to use the ARPA internet domain name resolution system to locate the Kerberos authentication service for the realm. As described below, authentication is accomplished by giving out tickets. Tickets are labeled with the name of the realm for the service for which they are issued. Principal identifiers included in tickets include a non-null realm only if it is different from the realm for which the ticket was issued. Workstations and service hosts have network names and network addresses, for example those specified by the ARPA internet domain name system. Each application protocol using the authentication service binds Kerberos ____ ________ {name, instance} tuples for services to addresses using whatever means its ________ ______ ____ _______ chooses. It may use, for example, the internet domain name service or the Hesiod service and cluster location system. __________ _____ Specifying_names The primary interface where the user will have to be concerned with names is when "logging in" to a workstation. Normally the user would simply enter his or her principal name, which might be the user's last name. Optionally, the user might specify an instance; if not specified, a null instance would be used as default. The realm is normally supplied by the workstation as a default, but the user might override that default, in effect requesting authentication by a different Kerberos server. The principal name and the instance name are separated by a period ("."). If no "." is included in the name, it is assumed that the instance is null. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ _ Athena Technical Plan Section E.2.1, page 9 In order to include a "." as part of the principal name or the instance name, it must be quoted with a backslash. In order to specify authentication in a realm different from the default for this workstation, a user must specify the realm preceded by an at-sign ("@"). The realm itself may contain periods without the use of a backslash. As an example, consider the user who desires authentication through the LCS.MIT.EDU realm using a system management instance. That user might log in as follows: Kerberos login: RLSmith.sysadmin@LCS.MIT.EDU _____ _____ Local_Names The namespace used for Kerberos authentication and authorization is independent of any particular host's means of referring to users or services, and any operating system specified conventions. Each host may translate the Kerberos principal identifiers to its own local user names as required. Local translation provides a convenient means of supporting _______ _____ proxies-for example, Kerberos name {RLSmith,""} might translate to guest on _______ ________ ____ ____________ a host where RLSmith does not have an account. Berkeley Unix applications ____ ___ ________ __ ___ ________ ______________ _________ _______ ____ ___ that are modified to use Kerberos authentication generally support only the ________ _______ ____ _ ________ _________ __________ __ ___ ____ ____ identity mapping from a Kerberos principal identifier to the same Unix _____ ____ login name. 4. The Kerberos Authentication Model In response to the requirements and assumptions sketched above, this section describes the Athena Kerberos model for authentication and authorization, with provision for accounting. This model is based on the Needham and Schroeder key distribution protocols, modified with the addition of timestamps. Their paper (listed in the References section) describes the basic protocol; a tutorial paper by Voydock and Kent provides a broader introduction to the topic and explains the timestamp modifications. The basic approach for Kerberos authentication is the following: to use a ______ service, a client must supply a ticket previously obtained from Kerberos. A ticket for a service is a string of bits with the property that it has been enciphered using the private key for that service. That private key is known only to the service itself and to Kerberos. As a result of that property, the service can be confident that any information found inside the ticket originated from Kerberos. As will be seen, Kerberos will have placed the identity of the client inside the ticket, so the service that receives a ticket has a Kerberos-authenticated opinion of the identity of the client. To help ensure that one user does not steal and reuse another user's tickets, the client accompanies the ticket with an authenticator, explained later. (In addition, tickets expire after a specified lifetime, which is usually on the order of several hours.) The client obtains a ticket by sending a message to Kerberos naming the principal identifier of the desired service, the principal identifier of ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 10 the (alleged) client, and mentioning the current time of day. Anyone could send such a message or intercept its response; that response, however, is usable only to the client named in the original request, because Kerberos seals the response by enciphering it in the private key of that client. The response contains three parts: the ticket (which itself is further sealed in the private key of the service), a newly-minted key for use in this client-server session, and a timestamp issued by the Kerberos server. A legitimate user will be able to unseal this message, obtain the ticket and session key, and verify that the timestamp is current (thereby preventing replays of old responses). No other user, without the named user's private key, can correctly decrypt the reply to produce the sealed tickets and corresponding session key. Once a client obtains a ticket and sends it to a service, and the service has identified the client, further use of the fact of authentication is specific to the protocol of the service. One application might use the session key (Kerberos seals a copy in the ticket) for secure end-to-end encryption, while at the other extreme, another application might throw everything but the source network address away and assume that all further requests coming on the connection from this particular network address are from the same user. _____________ The authenticator mentioned above is a simple mechanism designed to discourage attempts at unauthorized reuse ("replay") of tickets by someone who notices a ticket going by on the network and makes a copy. The authenticator consists of, among other things, the client's principal identifier, network address, and the current time of day all sealed with the key that Kerberos minted for this session. After the service decrypts the ticket, it uses the session key found in that ticket to decrypt the authenticator. If the principal identifier of the authenticator matches the one in the ticket, the network address in the authenticator is the same as the one that sent the packet, and the time in the authenticator is within the last few minutes, the authenticator is probably not a replay, and the service accepts the associated ticket. It is because authenticators expire in a short time that all the clients and servers in a Kerberos realm need to have their clocks loosely synchronized. If a private key is compromised, another party may successfully pose as the principal until the private key is changed and all tickets previously issued under it expire. If a session key is compromised, another party may successfully pose as the principal until the previously issued tickets expire. One more mechanism rounds out the complete Kerberos scenario. If a client uses several services, a distinct ticket is needed for each. Not all the services to be used may be known at the beginning of a login session, but that is when the user provides the password used as a private key to decrypt tickets. To avoid storing the private key in the workstation memory for the entire duration of the session, at login time the user obtains a single ticket, useful only for a service provided by Kerberos itself, the ticket-granting service. Whenever the client goes back to Kerberos for an additional, service-specific ticket, the response is actually enciphered in the session key of the ticket-granting service. Thus the private key is needed only for the initial ticket, and the workstation software can immediately destroy its copy of that private key after that single use. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 11 ______________ _________ AUTHENTICATION SCENARIOS Here, at the next level of detail, are more complete scenarios of authentication using Kerberos. These scenarios omit several options described in the next section. The reader not interested in security protocols can skip this and the next section without missing anything needed later. The reader interested in full detail will also want to consult the complete protocol specification (in the Appendix to this section), which includes provision for errors, key versions, and protocol versions, and which manipulates timestamps in ways not apparent in this simplified description. ________ __ _______ ___ _____ _______ Scenario_I._Getting_the_First_Ticket. 1. The user establishes a principal name N and a private client key, K , through some channel outside the system, for client example, by walking up to the system administrator, and presenting his or her identification card. The private key K becomes the authenticator between the user and the client Kerberos Key Distribution Server. The Kerberos Authentication Server stores the user's private key encrypted under its own master key, K . For the purpose of campus security, a master one-way encrypted 8-character secret password serves as the user's private key. (One-way encryption of the original password serves the function of assuring that if the user's Kerberos key is somehow compromised it does not reveal the original password, which the user may also be using on other systems.) _____ 2. The user initiates a workstation session by invoking a login command, giving as one argument the principal name of the client, N . client User -> WS N client The workstation knows the name of its default realm, R. The login command makes a request to the Kerberos Key Distribution Server for realm R, asking for a session key and a ticket for the Kerberos ticket-granting service. WS -> KKDS {N @R, N , T } R client tgs current where N is the name of the ticket-granting service, and tgs ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 12 T is the current date and time. current This request crosses the network in cleartext to the KKDS for realm R. 3. The KKDS looks up N and N , finding private keys client tgs K and K . It creates a new temporary session key, client tgs K , for use in this session, and prepares a ticket for temporary tgs the ticket-granting service: Ticket : {K , N , tgs temporary client tgs K N ,T , WS, Lifetime} tgs tgs current K where the notation {X} y means that message X is enciphered using encryption key K . The value WS is the network address of the y requesting workstation. The value Lifetime is the ticket lifetime chosen by the KKDS. An explanation of the rules for the ticket lifetime appears in the next section. 4. The KKDS sends a response packet: KKDS -> WS {K , N , Lifetime, R temporary tgs tgs K T , Ticket } client current tgs Note that authentication has not yet occurred-a sealed response containing a further sealed ticket comes back even if the user has misrepresented his or her identity. 5. At this point, the workstation asks the user for the password. User -> WS and the workstation runs the password through the one-way encryption algorithm to produce K . It immediately destroys client ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 13 its copy of the password. 6. The workstation decrypts the response from KKDS using K R client and checks its authenticity by comparing T and N in the current tgs response with the corresponding values in the initial request. If the response passes this test, the user knows for certain that the response was prepared by the Kerberos Key Distribution Service, because that is the only other entity in the universe that knows K . The response is current rather than a replay client of a response from yesterday, because it contains T . A current fraudulent user finds that the response (including the sealed ticket) is a worthless set of random bits because it is enciphered with the unknown private key of the legitimate user. The legitimate user stashes away K and Ticket for temporary tgs tgs later use. The workstation destroys its copy of the user's private key K , because it will not be needed again during client this login session. ________ ___ _____ _ _________________ _______ Scenario_II.__Using_a_Kerberos-Mediated_Service To use a service S, the user must have a ticket Ticket and the service corresponding temporary session key for that service, K . temporary service Scenario I traced the acquisition of one such ticket. Assume for the moment that the client now has a ticket and temporary session key for service S. (Scenario III, later, demonstrates how the client can get additional tickets without having to again present the user's password.) 1. To use service S, the client first prepares an authenticator. Authenticator : service K {N , T , WS} temporary client current service ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 14 where WS is the workstation's network address, T is a current current timestamp, and K is the temporary key temporary service that came with ticket Ticket . service Now the workstation begins the protocol for the target service S. The protocol has one difference from the corresponding, non-Kerberos protocol for the same service: it is prefaced with the authenticator and the ticket. WS -> Service {Authenticator , Ticket } service service 2. When the target service receives this request, it first decrypts the ticket using its private key, K . Since the service only two entities in the universe that know K are the service service itself and Kerberos, the service can be confident that if the ticket deciphers properly it must have been originally prepared by Kerberos. The test of whether or not the ticket deciphered properly is whether or not the next step works. A correct ticket decipherment exposes the temporary session key, the client's name, and the timestamp. The temporary session key allows the service to decrypt the authenticator, exposing its data. If the client's name and network address in the ticket and authenticator match, the ticket's timestamp has not expired, the network address in the authenticator matches that in the incoming packet, and the authenticator timestamp is sufficiently recent, then the request is taken as legitimate. The service knows for certain the identity of the requesting client and the service and the client now share a temporary secret key. This authentication remains valid for the lifetime of the client-service connection. 3. Finally, the application protocol begins, typically by transferring an application request from the client to the server, perhaps at the end of the packet that contained the ticket. If a client has a ticket for some service, that client may reuse the ticket as often as desired, until it expires. Each reuse requires constructing a new authenticator, one that contains a current time stamp. ________ ____ _______ __________ _______ Scenario_III.__Getting_Additional_Tickets If a client wants to use a service for which a ticket wasn't obtained as part of the initial encounter with Kerberos, the client invokes the ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 15 Kerberos Ticket-Granting Service. The Kerberos Ticket-Granting Service is simply another protocol for talking to the Kerberos Authentication Service, one that makes use of the ticket-granting ticket passed in the initial encounter, rather than the user's private key, to establish authenticity. 1. The client first prepares an authenticator exactly as before, though with a current timestamp and using the temporary session key that came with the ticket-granting ticket. Authenticator : tgs K {N , T , WS} temporary client current tgs Now the workstation sends the authenticator, the previously obtained ticket for the ticket-granting service, and the name of the service for which a ticket is wanted to the ticket granting service. WS -> KTGS R {Authenticator , Ticket , N @R} tgs tgs service 2. The ticket-granting service goes through the same procedure as does any other Kerberos-mediated service, first decrypting the ticket with its private key, and using the temporary session key found inside to decrypt the authenticator. If all the authenticity checks verify correctly, the ticket-granting service knows for certain the identity of the requesting client. In addition, it has recovered the temporary session key which is known only to it and the client; this session key can be used to securely return a ticket to the client. KTGS looks up the service name N in its database and finds the private key, service K , for that service. It now prepares a ticket: service Ticket : service {K , N , T , temporary client current service K Lifetime} service ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 16 where K is a new temporary session key for use temporary service between this client and the service; it then sends the response: KTGS -> WS R {K , N , T , temporary service current service K Ticket } temporary service tgs Note that the form of this response is identical to the form of the original response of the KKDS when it returned the ticket granting ticket. 3. The client, knowing the value of K , decrypts the temporary tgs response, verifies its authenticity as before, and stashes away the ticket for the target service. Scenario III emphasizes that the ticket-granting service is simply another example of a Kerberos-mediated network service. The form of the messages in step one of scenarios II and III is identical, once one realizes that the last field in the second message of scenario III is the application request mentioned in step three of Scenario II. ____ _______ SOME OPTIONS As mentioned, the three scenarios above follow what is expected to be the most common form of use of Kerberos authentication. There are several optional possibilities available for applications that use Kerberos: - The examples specified no values for the instance name of either the client or the service; those values are optional and default to the null instance. - An application client may include in the sealed authenticator an application authenticator, such as a checksum of data to be sent. Calculating that checksum is, of course, feasible only if all the data to be transmitted is known at connect time. As an alternative, an application could devise a commit message that appears at the end of the protocol, and that includes a checksum ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 17 sealed with the session key. - If the application requires mutual authentication, it sets an option in its service request, and places no application protocol information in the initial packet. The application server responds by adding one to the workstation's request timestamp, encrypting the result using the session key, and sending the encrypted result back to the client. Once the client receives and decrypts this handshake response, it can be certain that the server is authentic, and the application protocol may safely begin. - The application server may retain state (timestamps) about previous use to aid detecting replay attempts. - The application may use the application authenticator and the session key to continue a session in which every message is both completely encrypted and authenticated. - An application may request a ticket with a specified lifetime; if the requested lifetime is less than the default ticket lifetime and less than that specified in the Kerberos database for the service, Kerberos issues a ticket with the shorter lifetime. ___________ ___ ____ _________ APPLICATION AND USER INTERFACE For the most part, Kerberos is designed to operate under the covers, without separate actions by the user. For network applications that make use of Kerberos authentication there is a library of Kerberos functions that simplify the obtaining of authentication. The primary interface consists of three generic user commands and two generic subroutines that are used by applications. _____ - User command kinit: This command asks the user for a password, obtains a ticket-granting ticket, and destroys the password as soon as it has stored the ticket-granting ticket and associated session key. Note that the function of this command may be _____ combined with the login command. _____ - User command klist: Displays the list of tickets obtained so far in this login session. ________ - User command kdestroy: Destroys all tickets. The function of ______ this command may be combined with the logout command. ____ ___________ _______ - Subroutine make_application_request(): Used by an application to get a copy of, or if necessary obtain, a ticket and session key for a named service, to prepare an authenticator, and return the result to the application for inclusion in the initial service request. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 18 ____ ___________ _______ - Subroutine read_application_request: Used by an application server to validate a presented ticket and authenticator. It returns the identity found in the ticket and a judgement about the authenticity of that identity. Note that the actual names, arguments, and parameters of these generic commands and subroutines are implementation-dependent. The Kerberos library implemented for UNIX, for example, shortens some names, combines kinit and kdestroy with login and logout, contains about a dozen additional supporting subroutines for the convenience of applications that are using optional features, and includes conventions about where to store tickets in the UNIX environment. ______ REALMS Kerberos provides for partitioning authentication information according to administrative divisions. All users need not be registered with a single organization. In addition, organizations that share authentication need not trust one another. A realm is an authentication domain. It is that part of the namespace of authenticable users and services that relies on a separately administered authentication server (or set of servers sharing the same database) for their authenticity. A service can accept credentials produced by an authentication server only for a realm of which it is a member. Both users and services may belong to multiple realms. Realm names within a network need to be unique. The earlier-mentioned convention of naming realms with ARPA Internet domain names has the side effect of guaranteeing uniqueness. Realms can be either independent or semi-independent. ___________ ______ Independent_Realms Some users will want to access services from realms with which they aren't registered. Some services will be willing to provide services to users from other realms. These two requirements lead to a mechanism to authenticate users across realms. This mechanism is provided through the cooperation of the administrators of the two realms involved. The Kerberos for each such realm is a client of the Kerberos in the other, and shares a secret key for a cross-realm ticket-granting service. This mutual client relationship between the Kerberos services allows a client of the Kerberos in one realm to authenticate itself to the Kerberos in the other realm even though no information is shared between the client and the other Kerberos service. Once a client has authenticated itself to the Kerberos in the new realm, that client can request tickets for services issued by that Kerberos. As an example, consider a user in the LCS realm who wants to access a server in the Athena realm. The user must first authenticate with the LCS Kerberos using the initial authentication protocol. Once this authentication is done, the user can request a ticket for the Athena ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 19 Kerberos. The user presents this ticket to the Athena Kerberos which accepts the user's identity since the Athena Kerberos is a client of the LCS Kerberos. The user can then request a ticket for an Athena service and the Athena Kerberos will comply. However, the ticket that the Athena Kerberos issues indicates that the user is from the LCS realm. Thus, all the ticket says is that the Athena Kerberos acknowledges that the user has been authenticated by the LCS Kerberos. The client then presents the new ticket to the end service which decides whether or not to accept it, based on its own authorization policy. ________________ ______ Semi-independent_Realms The realm mechanism can also be used to provide authentication services for off-campus independent living groups. The problem is that the ILGs must have a way of authenticating users to local services even when their connection to the campus-based facilities fails. Yet, at the same time, there cannot be a copy of the Kerberos for the Athena realm in the ILG since there would be no guarantee of its security. Instead, each ILG has its own realm. Local services accept authentication by either realm. Most services on campus, however, accept authentication only from the Athena realm. When communication with the campus network is operational, ILG users authenticate themselves to the Athena Kerberos, then use the protocol described above to authenticate themselves to the ILG Kerberos. In this way ILG users have to provide only one password (the one required by the Athena Kerberos) to use both local and campus services. Users on campus who want to use services located at the ILG will also be able to use this mechanism. If the connection between the ILG and main campus ceases to function, ILG users authenticate themselves directly to the ILG Kerberos and are thus be able to use local services. This local authentication does not allow them to use all the services on campus, but since they are disconnected it doesn't matter. It is suggested that users choose different keys for the Athena Kerberos and the ILG Kerberos since the ILG Kerberos may be much easier to compromise. We do not plan to enforce such a suggestion, however. ____ _______ _____ _____________ More_Complex_Realm_Relationships The realm mechanism of Kerberos is not fully developed. In particular, the protocol does not provide the target service with detailed information about the provenance of tickets that have been authenticated in other realms. More work is required on security implications of cross-realm authentication, so that a service examining a ticket can know exactly whom it is trusting for authentication. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 20 5. Management of Kerberos Data The database underlying Kerberos contains a record for each user identity and for each service (that is, for each principal) known within that Kerberos realm. In order to allow security of the data to be the primary consideration when making operational tradeoffs about management of a Kerberos service, the information that Kerberos stores is the minimum required to accomplish and manage authentication. Thus, although a Kerberos record is a kind of per-user record, it does not contain information such as telephone number and office address, which are not used by Kerberos for authentication. Nevertheless, if there are a large number of users, the Kerberos database can still be quite large and it requires some tools for its management. The data management interface of Kerberos is designed to be used in two ways: - By a set of manual tools manually from a system manager's workstation. This approach is suitable for management of a Kerberos realm that has a small number of users. - By an automated Service Management System. This approach is intended for managing a system with thousands of users. In both cases, the management of the Kerberos service is accomplished remotely via the network, using Kerberos-authenticated secure connections. The information stored for each principal that Kerberos is prepared to authenticate is the following: - The principal identifier, including instance identifier. - The private key (password) for this principal. - The expiration date for this identity. - The date that this record was last modified. - Identity of the principal who last modified this record. - Maximum lifetime of tickets to be given to this principal. - Attributes (unused). - Implementation data, not visible externally: * Key version and master key version. * Pointer to old values of this record. One piece of information in each record, the private key, must remain ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 21 secret. Kerberos reversibly enciphers the private key fields, using a master key for this Key Distribution Service. Encipherment of the private key fields allows a manager to remove copies of the database from the machine and it also allows the Kerberos master to send copies over the network to slave servers without going to extraordinary lengths to protect the privacy of those copies. Kerberos does not store the master key in the database; it manages that one key separately. ________ ________ ___________ KERBEROS DATABASE REPLICATION The Kerberos database for a realm is managed and updated by a single Kerberos Database Management server (the KDBM); authentication requests are handled by one or more Kerberos Key Distribution Servers (KKDS's), each of which contains an identical complete copy of the Kerberos database. Since all KKDS's have identical data any KKDS can handle any authentication request; a client uses a name service to obtain a list of KKDS's, and chooses the one that is nearest in terms of network topology. The separation of responsibility between KDBM and KKDS's does not imply that several distinct host computers are required; in the simplest deployment, one host can run both a KDBM server and a KKDS. The purpose of separation is to simplify update of the database while permitting replicated KKDS's for improved availability and performance. (Since many other network services may depend on it, continuous availability of Key Distribution Service is essential; continuous availability of update service is not nearly so important.) With respect to the Kerberos database, all operations done by a KKDS are "read-only," so the only coordination among KKDS's and the KDBM is for the KKDS's to receive updates of the information when changes are made at the KDBM. Again for simplicity, the KDBM issues KKDS updates occasionally (e.g., a few times per day) and by copying the entire database. Complete copying eliminates the need for considerably more complex update procedures that would maintain update queues at the KDBM and recovery procedures at the KKDS's. Because updates occur on a batch basis, the KKDS's may have data that is slightly stale; update delay of a few hours is acceptable for this application. The KDBM copies its database to the KKDS's using a Kerberos-protected protocol. First, using the Kerberos mutual authentication protocol, a secure encryption key is exchanged between the KDBM site and a given KKDS site. The KDBM creates a checkpoint of the data to be transferred, and calculates its (strong) checksum, seeding the checksum with the session key. Then it transfers the actual data using a conventional file transfer protocol. Recall that the data does not include any cleartext passwords or other particularly sensitive information. However, its integrity must be assured. The receiving KKDS temporarily stores all the transferred data, then recalculates the checksum of the received data using the secret session key. It then compares the calculated checksum with the original checksum, which was separately transmitted using the secure Kerberos protocol. If and only if the two checksums match, the newly received data updates the KKDS database. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 22 _______ __ ___ ________ ____ ____ UPDATES TO THE KERBEROS DATA BASE Updates are done by an update protocol that runs between any authenticated client at a workstation and the KDBM. If the KDBM is not accessible, updates are temporarily not allowed. There are several routine updates made to the Kerberos database. 1. adding a new user 2. a user changes a password 3. system manager changes a forgotten or compromised password 4. deactivating an old user 5. removing old user identities In emergencies, a system manager can also tinker directly with raw Kerberos data for repair and other extraordinary maintenance operations. Such tinkering must be done by logging in directly on the host that runs the master Kerberos service. ______ _ ___ ____ ADDING A NEW USER Adding a new user to the Kerberos database is accomplished by invoking the add-user message type of the Kerberos protocol, which requires that the user doing the addition be a previously-added user of the system whose identity appears in an add-user access control list maintained by the Kerberos master system. If an SMS is in use, a different approach is taken that is more suitable for mass production. The intent of this different approach is that a user can choose a principal identifier and register the chosen principal identifier and associated password without actually involving a system manager. Each fall, the SMS is primed with a list of potential new users (obtained from a list of all registered students) including for each user a full name and a student identification number. A prospective user walks up to an Athena workstation, logs in as an unauthenticated user (the user identity "register", with publicly-known password "athena", is used for this purpose) and interacts with a user registration program that obtains from the user his or her full name, student identification number, proposed principal identifier and proposed password. The user registration program first connects to SMS to verify that this user's full name and student identification number match one in the list of as-yet-unregistered users. If so, it informs SMS of the principal identifier that the user has chosen, and in turn receives an add-user session key from SMS. The user registration program then opens an encrypted connection with the master Kerberos service using the add-user session key. It supplies the user's chosen principal identifier and password to Kerberos, which checks to see ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 23 that the principal identifier is not one already on record (rejecting the request if it is) and then records it and the password. If the transaction with Kerberos is successful, the user registration program confirms the success with SMS, which then commits this registration transaction. This unsupervised registration scenario is a compromise that is only weakly secure, because any one who knows another person's name and student identification number can register as that person. There is some protection against such an attack, however, because when the authentic person with that identity attempts to register, the fraud will be discovered when both SMS and Kerberos reject the second registration attempt. The legitimate user can then appeal to a real system administrator, who can sort things out by forcing into the Kerberos database a new password known only to the legitimate user. ____ _________ ________ ______ USER-INITIATED PASSWORD CHANGE The basic scenario for changing a password is that the user does it him or herself by invoking the password-changing program at a workstation. This program demands the old and new passwords, uses the old password to create a completely encrypted session with the master Kerberos server, and sends the new password on the encrypted connection. If the user has reason to believe that the old password is so badly compromised that it is not safe to send the new password this way, the user may appeal to the system manager to install a new password. ______ _______ _________ ________ ______ SYSTEM-MANAGER-INITIATED PASSWORD CHANGE Kerberos maintains an access control list, which consists of a list of Kerberos principal identifiers of individuals who are authorized to act as system manager. When a user reports that a password is forgotten or compromised, the system manager opens an encrypted connection from the manager's workstation to the Kerberos master server and runs a password-installation protocol. This protocol requires that the invoker appear in the system manager access control list. ____ ____________ USER DEACTIVATION Kerberos maintains an expiration date and an activation flag for every principal identity that it is prepared to authenticate. Kerberos always rejects attempts to authenticate expired or inactive users, with an appropriate error response. The purpose of deactivation is to provide a simple means of avoiding accidental reuse of principal identifiers, which may continue to appear in access control lists for some time after a user departs from the scene. There is a secure protocol message type by which the system manager can deactivate or reactivate a principal identifier, or change its expiration date. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 24 ________ ___ ____ __________ REMOVING OLD USER IDENTITIES Kerberos maintains a last-modified-date as part of each record of a principal identity. Deactivation updates this date. One use of this date is to allow a system manager to identify old identities that have not been in use for a sufficient period (e.g., one year) that it is safe to remove them. A secure protocol message allows an authorized system manager to remove any specific inactive identity, and to remove all inactive identities that have not been changed since a specified date. This operation is designed under the assumption that it occurs rarely, perhaps two or three times a year, so the only record of identities removed is in the Kerberos log. _______ ____________ ____ ___ KEEPING SYNCHRONIZED WITH SMS If a Service Management System is in use, it maintains its own records of registered and prospective users; those records are correlated with the records of Kerberos by principal identifer. Since the principal identifier is the only piece of duplicate information maintained, the only synchronization problem is to insure that every principal identifier that appears in an SMS record also appears in some Kerberos record, and vice-versa. User registration, as described above, is the normal way of creating principal identifiers, and if a user registration operation completes normally, both records will match. Failures, or hand-tinkering, may unsynchronize these two sets of records. No special tools are provided to deal with this problem; the system manager, if trouble is suspected, may extract from Kerberos a list of principal identifers to sort and compare with the corresponding list from SMS. ________ ______ ___ ______ DATABASE BACKUP AND RELOAD The Kerberos database is backed up by running a special backup program on the master Kerberos server, which should be equipped with a private tape drive. The Kerberos master key is not stored on the backup tape. A special reload program is also available, although if the system is completely reset the Kerberos master key must be reinstalled by hand. Reload of slave servers is done by invoking the usual Master-Slave update procedure, which transfers a complete copy of the database. 6. Authorization Model The Kerberos authentication model provides only a certification of the identity of a requesting client; by itself it provides no information as to whether or not that client is actually authorized to use the service. There are three forms in which authorization could be integrated with the Kerberos authentication model: ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 25 - The Kerberos database could also contain authorization information for each service, and issue service tickets only to authorized users of each service. - A separate authorization service could maintain authorization information by keeping access lists for each service and allowing the client to obtain sealed certification of list membership. The client would present that certification, rather than a Kerberos ticket, to the ultimate service. - Each service could maintain its own authorization information, with the optional help of a service that stores shared public lists and provides certification of public list membership. The first of these alternatives places the large, dynamically updated authorization database in the midst of the small, slowly changing, high-security encryption key database. Operational parameters such as primary and secondary memory size, degree of replication, nature of backup, and physical security must be chosen as a compromise between the requirements of the two services. It also locks in one particular authorization model for all applications. The second alternative separates the authorization database from the authentication database, thereby improving separation of administration and making the authentication service simpler and smaller, which should make it more reliable and easier to secure. But this alternative leads to an extraordinarily complex (and therefore potentially fragile) collection of interacting protocols among the client and the authentication, authorization, and target services. It also creates a rendezvous problem, in that the client must know which membership certification to request from the authorization server. The Kerberos authorization model is based on the principle that each service knows best who its users should be and what form of authorization is appropriate, so it adopts the third of these alternatives. This choice has several advantages: - Many services will have short, private lists of authorized users. For example, the display server on a private workstation may have as its list of authorized users only one entryMthe current user of the workstationMand that user's identity is already known by the workstation. (In addition, the identity of the user allowed to use the display on a public workstation changes as often as someone logs in.) By far the simplest way to manage that information is to place it in the server. Completely private services (e.g., a dating service exported from a private workstation) thus require no central registration, yet can take advantage of Kerberos-quality authentication and implement access control. - Services that maintain their own lists (e.g., the display server) or that do not require an access control list (e.g., a public library) do not depend on availability of and network continuity ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 26 to an authorization service. - Rendezvous is limited to getting the client together with the service; the client does not need to figure out what kind of authorization to request for this particular service. - No one authorization model applies to all services; by making authorization the responsibility of the server, the designer of the service has the option of using a standard library authorization model, or creating a different model that is better adapted to the particular service it is offering. - Since the amount of information storage required for authorization information is proportional to the number of services offered, storing and managing the authorization information at the service scales up well. This scaling advantage is of particular interest when one realizes that every workstation exports at least its display service, and may export others. It is also administratively preferable to have each service provide its own authorization list storage, rather than burdening a public storehouse with this responsibility. - Administrative authority to set and change the authorization information for a service tends to be automatically delegated to the appropriate entityMthe administration of the service itself. There is one significant disadvantage to requiring the service to do its own authorization: Services that cannot depend on other network services (for example, because they are single-threaded and should not block waiting for a network reply) cannot make use of shared public access control lists. _____________ _________ AUTHORIZATION MECHANICS A standard authorization model based on access control lists is provided, and an authorization library package is available for incorporation into any service that finds the standard model useful. Under this standard model, the service takes the (known, authenticated) identity of the client and inquires whether or not that client is a member of a named list. The access list library package maintains any number of named lists in the local storage of the server. A list may contain three kinds of names: 1. Kerberos-authenticable principal identifiers, 2. names of other local lists, and 3. names of shared, public access control lists. The access list library undertakes a search of the named list, local ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 27 sublists stored at the service host, and shared, public lists. If the client's identity is found in this search, the operation is authorized. Rather than associating operation-specific permissions with access list entries, the service maintains distinct, named access lists for each different kind of operation. The lists are maintained as simple ASCII text string files in a special access list directory that is protected from modification except by administrators of the target service. Their format allows, in simple cases, maintenance by use of standard text editors, or in more complex cases, automatic maintenance by the Athena Service Management System. ___ ______ ____ ______ THE PUBLIC LIST SERVER A public list server provides Kerberos-quality certifications that principal identifier A is (or is not) in list B. The ability to use remote servers for such a certification allows the possibility of shared, centrally managed lists. The ability to use local lists allows the possibility of lists whose contents are unknown to any central authority. The architecture allows that these two possibilities can be mixed and matched in any way desired by the implementer or manager of the host that offers the service. (The detailed design of a public list service has not yet been undertaken. Issues such as what action to take in the face of a cycle in a list, and management of very large lists, have not yet been addressed.) ______________ _____________ ________ ____ ____ _______ AUTHENTICATION/AUTHORIZATION SCENARIO WITH NAME SERVICE A complete scenario for integrating name service, Kerberos, and authorization is as follows (there are a lot of services flying around in this discussionMthe one the client really wants to invoke is called the "desired service"): 1. Assume for starters that each client (and service) knows the internet address of a name service and the name of Kerberos. As part of its initialization, the client invokes the name service to determine the internet address of Kerberos. It also performs an initial transaction with Kerberos to obtain a ticket-granting ticket. Each service that cares about authorization has done the same thing as part of its initialization. 2. The person exporting the desired service has previously registered the name of that service with the name service. If this step hasn't happened, it doesn't prevent use of the desired service, but it does mean that the client has to invoke it by discovering and using a host name and port number, rather than by name. 3. The user learns the name of a desired service. Learning may ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 28 happen one of any number of ways. Here are a few examples: - A prospective user reads the name on a bulletin board. - The user copies a program from a public place; the program has the name buried in it. - The name is embedded in a system-provided library program. - The name is embedded in a class-provided library program. - The user learns about the service name from a system staff member. 4. The client invokes the Kerberos ticket-granting service, requesting a ticket for the desired service name. If Kerberos has never heard of the desired service, that doesn't cause the scenario to abort; it may simply be that the desired service doesn't require authentication. 5. The client invokes the name service to learn the host name and port of the desired service. The client can cache this information at its own risk, to allow future invocations of the desired service without using the name service again. The name service provides a time-to-live value for the information that gives the client a hint about how long it is safe to cache it. 6. The client invokes the name service again, to transform the host name of the desired service into an internet address. 7. The client invokes the desired service, presenting its Kerberos ticket (if by now it has one) certifying the client's identity. 8. The desired service decides whether or not it wishes to deal with this client. To decide, it may invoke the access list library, giving the name of the client and the name of an access control list. The access list library performs a recursive descent through that list and any lists, local or remote, named in that list, trying to verify list membership of the client. Because the desired service is depending on the authenticity of the certifications of the list membership service, each connection with a remote list membership service must be initiated via Kerberos and the responses from the service need to be integrity-assured. Integrity assurance is provided by having the remote list membership service return a copy of the original request, with a yes or no bit added, enciphered in the session key that the invoker obtained at initial connection with the list membership service. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 29 _______________ ACKNOWLEDGMENTS Many people have provided ideas, or have been involved with the implementation of this design. In addition to the authors of this document, they include: John Ostlund, Mark Colan, Bob Baldwin, Dan Geer, Stan Zanarotti, Bill Sommerfeld, John Kohl, Jim Aspnes, Chris Reed, and Brian Murphy. The name "Kerberos" was suggested by Bill Bryant. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 30 7. AppendixMDesign Specifications This section contains detailed design specifications for the current implementation of Kerberos. It is of interest primarily to implementers. 7.1. Design 7.1.1. Conventions The following conventions apply: 2 - encryption or decryption implies DES private key in a modified cipher-block-chaining mode - "{data}K " means that "data" is encrypted using "x"s DES key; x - all data to be encrypted is padded with trailing 0 bytes to an integral multiple of 8 bytes; _______ ___ - all references to session key imply a distinct random session key valid only for that particular session; - bit 0 refers to the least significant bit; - all field sizes are expressed in numbers of 8-bit bytes, unless otherwise stated, and whether or not the value is signed (s), unsigned (u) or only printable ASCII, null terminated (a); - strings are sequences of printable ASCII bytes, null terminated; - all messages are self-framing, that is, do not depend on packet boundaries to determine their extent; ____ _____ - where not otherwise stated, name implies the local realm; _____ similarly, a null realm implies the local one; _ - principal, indicated in the protocols by either subscript p or _________ principal, refers to the subject requesting authentication and/or ____ ________ authorization, i.e either a user's or service's {name, instance} pair. _______________ 2 Modified to provide forward error propagation of a single bit error in the ciphertext thru to the end of the resulting cleartext. Refer to Voydock and Kent [14]. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 31 _ - service, indicated in the protocols by either a subscript s or _______ service refers to the end service, object, or other user for which authentication/authorization was requested. This is most ____ ________ often a service's {name, instance} pair, but could also be any user's to allow secure key distribution between two users. ______ ______ ____ __ ________ Common_fields_used_in_messages _____ ____ _ _ _ ___________ field size u,s,a description --------------------------------------------------------------------------- version 1 u Protocol version number; auth_msg_type 1 u Protocol message type and byte order; = m_type << 1 + byte_order ; m_type 7bits u Protocol message type; byte_order 1bit u Byte order of sender; name >=0 a Athena principal name (user or service); instance >=0 a Athena principal instance (user or service); realm >=0 a Authentication realm name; group >=0 a Athena group name; time_sec 4 u UTC timestamp, sec since 0000 GMT 1/1/70; may also have direction encoded in msbit; time_5ms 1 u rest of UTC timestamp, 5ms units; lifetime 1 u valid ticket lifetime, 5 minute units; key 8 u 64 bit encryption key; kvno 1 u key version number; n 1 u count of service entries; address 4 Internet host address, IP format and order; length 1 u length of a field, 0 - 255, bytes; length_2 2 u length of a field, 0 - 65535, bytes; length_4 4 u length of a field, 0 - 4,294,967,295, bytes; exp_date 4 u UTC expiration date, sec since 0000 GMT 1/1/1970; direction 1bit u within an association, zero if sending {addr, port } < receiving {addr,port}, else one; multiplex into msb of time_sec; app_data n application specific data, arbitrary length; checksum_4 4 u 4 byte checksum; checksum_16 16 u 16 byte checksum; flags 1 u bit-flags within ticket, set by Kerberos; err_code 4 s Kerberos error code; err_text >=0 a description of Kerberos error; ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 32 _______ _______________ Network_Representations ____ ___ ____ byte ordering The least significant bit of auth_msg_type will encode the byte ordering for the transmitting host. LSB_FIRST, one, implies least signigicant byte in lowest address, e.g. VAX and IBM PC's. MSB_FIRST, zero, implies most significant byte in lowest address, e.g. Sun 68000 and IBM RT's. The transmitter of a message always transmits in natural host ____ ___ ____ order, and marks its byte ordering in auth_msg_type. The receiver, if necessary, converts fields to its own byte ordering. alignment to avoid possible incompatibilities between compiler alignment rules, all protocol messages must be defined without use of structures. All protocol messages have no holes for alignment. Each field begins on the next byte boundary. ________ _______ _______ Protocol_Message_pattern { version, auth_msg_type, name , instance , realm , time_sec, cleartext, p p p ciphertext } where unneeded parts are omitted. The protocol message specifications should be read in increasing byte order within the message as you read from left to right, with no holes. 7.1.2. KKDS 7.1.2.1. Protocol. All the Kerberos protocols described are layered on a UDP datagram between the client and the KKDS. The client interface may retransmit a request up to times if a response is not received within time interval . All protocol messages between a client and the KKDS must be idempotent. To minimize retransmissions, all requests should generate a response, either an ____ _____ ___ _____ auth_reply or an err_reply, even if the response only implies failure. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 33 auth_request = { version, auth_msg_type, name , instance , realm , p p p time_sec , ws lifetime , name , instance } s s s where auth_msg_type = The service requested is local to the realm managed by the Kerberos receiving the request. auth_reply = { version, auth_msg_type, name , instance , realm , p p p time_sec , ws exp_date , kvno , length_2, {cipher}K } p p p kvno where auth_msg_type = ____ ________ length_2 = length of cipher; zero if {name , instance } is _ _ p p unknown; cipher = {K , name , instance , realm , lifetime , kvno , session s s s s s {ticket }K , s s kvno time_sec } kkds where ticket = { flags, name , instance , realm , address , p p p p K , lifetime, time_sec , name , instance } session kkds s s note: ________ the lifetime returned is the minimum of the principal's, server's, and the lifetime requested. err_reply = { version, auth_msg_type, name , instance , realm , p p p time_sec , err_code, err_text } ws where ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 34 auth_msg_type = , ____ _ err_code = Kerberos error code, defined in prot.h , err_text = text string describing error. 7.1.2.2. Protocol Vulnerability. - replay -- The timestamp serves to prevent replay attempts by ___ limiting the lifetime of the key. If the server retains all the still valid timestamps for previous associations for the user, all replay attempts can be prevented. The latter requires stable store across process and machine crashes. __________ ____ - modification -- The timestamps and name can serve as effective integrity checks to detect modification to the packet. If the ciphertext was changed or forged, with extremely high probability _________ ____ the timestamp would no longer be valid, and the name in the _____________ ticket and in the authenticator would not match. 7.1.2.3. Administrative Protocol. A set of protocols is required for interaction between administrators, users, and the Kerberos Database Manager, for example to create new principals and to change keys. These protocols are not yet specified. _____ 7.1.2.4. Authentication Database. Each Kerberos realm maintains an independent set of databases. The following are represented: - Private keys of clients and services; estimate 10,000 users + <= 15000 services x 1 record; tag each key with an index number 3 noting which KKDS master key was used to store it. record = {name, instance, kvno, {key }K , kvno KKDS KKDS-kvno KKDS-kvno, exp_date, max_life, last_modified_by_name, last_modified_by_instance, last_modified_date} - Audit trail -- A management audit trail of selected database 4 operations, not yet specified, will be maintained . _______________ 3 In case the KKDS master key needs to be changed, this allows a more orderly transition to a new master key. 4 Probably as a side effect of journaling the database. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 35 - Statistics - To be specified. 7.1.2.5. Database management. Kerberos is built on a database management layer with a very simple set of lookup operations that can be implemented using any available database system. The initial implementation of that layer uses Ingres as the supporting database system; a second implementation uses the UNIX dbm package. Slave servers use the second implementation. The master server can use either implementation; the advantage of the Ingres implementation is that administration of a large number of users (e.g., producing a list of all users whose accounts will expire in the next six months) can be done with more potent tools. 7.1.2.6. User interface. An implementation of a user interface to obtain, list, and destroy Kerberos tickets for Berkeley 4.3 UNIX is ___ ________ _ _____ _ _____ _ described in a set of UNIX man pages named kerberos(1), kinit(1), klist(1), ________ _ and kdestroy(1). A command to change a user's Kerberos password is _______ _ described in kpasswd(1), and the Kerberos database administrator's program, used for registering new Kerberos principals and setting or changing ______ _ passwords, is explained in the kadmin(8) manual page. 7.1.3. Application Authentication Protocols 7.1.3.1. Request Interface. The changes involved in using a service ___ ___ should be as transparent as possible. When a user uses lpr, lpr should automatically include the authenticator in its request without the user having to do anything extra. In the event that the ticket for a service has not been obtained, or has expired, the service should obtain a ticket on the user's behalf using the ticket granting ticket obtained when the ______ __ user logged in. 7.1.3.2. Client Request. The following KKDS block normally would be transmitted from the client to the server before any user data as the first packet sent, though this need not be first. It serves to identify the requestor, present his or her ticket, and authenticate the request. By appropriately decrypting and checking the integrity, the service may proceed to offer or deny the requested service. appl_request { version, auth_msg_type , kvno , realm , length_2, s s {ticket}K , {authenticator}K } s session kvno where auth_msg_type = i.e. one-way authentication, or i.e. mutual (two-way) authentication request length_2 = length of ticket, then length of authenticator ticket = { flags, name , instance , realm , address , p p p p ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 36 K , lifetime , time_sec , name , instance } session s kkds s s authenticator = {name , instance , realm , checksum_4, p p p time_5ms , time_sec } ws_now ws_now checksum_4 = optional data checksum to be used by service, checksum algorithm selected by service. 7.1.3.3. Server Verification and Response. The server decrypts request, ____ ________ _____ _______ ____ ___ checking name, instance, realm, address, and time_sec, and optionally ______ ________ _______ checks for a recent playback attempt. If the authentication is invalid, the ____ ___ client's request is denied, and an appl_err message is returned. Otherwise, the service may then request the client's authorizations from the authorization service, if need be. It then performs the requested operation within the bounds of the authorizations granted. ____ ___ ____ If auth_msg_type requests mutual authentication (two-way), the server replies with the message noted below. If the client is satisfied with the server's response, it then begins the normal operation. appl_reply { version, auth_msg_type, {svc_authent}K } session where auth_msg_type = svc_authent = { time_sec +1 } ws_now appl_err = { version, auth_msg_type, err_code, err_text } where auth_msg_type = , ____ _ err_code = Kerberos error code, defined in prot.h , err_text = text string describing error. 7.1.3.4. Secure Conversations. The authentication protocols described previously create a secure session key exchange and authenticate the principals. This is sufficient for many purposes, but other services, such _____________ _______ ____ _______ as the authorization service and the KDBM service require protection for every message exchanged, not just for initial "connections". Such protection may take two alternate forms: - message authentication -- guarantee that a given message has not been modified, forged, replayed, or made out of sequence; the message is still readable on the network; - message secrecy -- in addition to offering message authentication, providing message secrecy by encrypting the contents of the message. Two additional protocol message envelopes are provided for these ____ ___ _______ ___ purposes; safe_msg provides message authentication, and private_msg ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 37 ___ ____ provides both message authentication and privacy. The app_data field is application specific data. Each application determines the pattern of _______ ___ ____ ___ ____ ___ message types needed -- private_msg, safe_msg, appl_err, and application specific messages. ____ ___ A safe_msg provides strong means to detect any modification attempts, forgery, or replays, but does not provide privacy. safe_msg = { version, auth_msg_type, safe_data, checksum_16(K , safe_data) } session where auth_msg_type = length_4 = length of safe_data, safe_data = { length_4 , app_data, time_5ms , safe_data ws_now address , direction, time_sec } source ws_now ____ ____ checksum_16 is a function of both K and safe_data, session using the quad_cksum() algorithm. _______ ___ A private_msg provides strong means to detect any modification attempts, forgery, or replays, and in addition provides privacy. However, to provide the privacy, it incurs significant additional run-time overhead for encryption. Since the lifetime of a session key may be greater than that of a process, timestamps are used instead of sequence numbers. private_msg = { version, auth_msg_type, length_4 , cipher } cipher where auth_msg_type = length_4 = length of the encrypted portion of the cipher message, cipher ={ private_data } K session private_data = { length_4 , app_data, time_5ms , app ws_now address , direction, time_sec } source ws_now ___ ____ length_4 = length of app_data, app app_data = application specific data, _____ ___ ____ ___ ___ _______ ___ Rules for safe_msg and private_msg: - Both sides discard messages with duplicate timestamps and messages with the wrong direction (replay attempts); - Both sides retain state of both the transmitted and the received ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 38 timestamps; messages with out of order timestamps are discarded (limited pipelining is possible if one were ambitious); - Messages with invalid checksums are discarded; - (Discarded messages cause a security log entry to be made either locally or sent to a security audit trail log process ???). 7.1.4. Library Routines Kerberos uses two major libraries. The first is a general purpose DES encryption library, and the second is a Kerberos-specific library to help interface to the Kerberos protocols. 7.1.4.1. DES Encryption Library. The DES encryption library created for Kerberos is a software only implementation of the DES algorithm, certain modes of operation, and related utilities. It may be used independently of Kerberos, or may be replaced (for example, for export) by any other 64-bit block cipher algorithms which maintain a compatible interface. _ 5 ___ ____ ___ ____ ____ ____ The routines supported include ecb mode, cbc mode, and pcbc mode ___ ________ ____ _________ ________ ____ encryption and decryption, a cbc checksum mode, a quadratic checksum mode, ______ ___ ______ (not DES), a DES random key generator, a routine to prompt and read a password without echoing, a routine to one-way-encrypt an arbitrary string into a DES key, and a routine to create a DES key schedule from a DES key. The implementation for Berkeley 4.3 UNIX is described in a UNIX man page ___ _____ _ labelled des_crypt(3). 7.1.4.2. Kerberos Protocol Library. A Kerberos Protocol Library provides a callable interface to the protocol described earlier. The implementation for Berkeley 4.3 UNIX is described in a UNIX man page ________ _ labelled kerberos(3). 7.2. Issues Master key management for the servers is a yet unresolved operational problem. To maintain security during maintenance operation it is preferable not to store the master key on disk on the server, yet it is an operational headache to manually enter the master key at each server every time it is restarted. One possible solution is to build a simple hardware box that supplies the master key from a set of thumbwheels, over a serial port. This box could remain plugged in to the KKDS in case a power loss causes it to reboot, yet it could be unplugged (or the thumbwheels set to zero) when it is necessary to turn the machine over to a field service _______________ 5 pcbc is a modified cbc mode to provide indefinite error propagation on decryption. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 39 engineer for maintenance. A related requirement is to completely clear all copies of the master key, including any that may be in virtual memory swap areas on the disk, when sanitizing the KKDS for service. Key management for user keys also presents some problems. In order to make this authentication mechanism as familiar and transparent to the user as possible, keys are based on a password of the user's choice. Because of this, Kerberos suffers from some of the same problems as passwords. In particular, users may choose keys which are easy to guess, or they may record them where others can find them. ______________ Servers may require stable storage for the recently used authenticators, in order to eliminate replay attempts that cross system boot or process restart boundaries. Whether this is needed depends on the difference between the expected maximum downtime for the service and the size of the 6 service's timestamp window. The KKDS workload needs to be estimated and measured, since it (they) can easily become a bottleneck. We will then need to determine how to tune the KKDS's, and how many are needed where. The server's private key is needed to decrypt the ticket for every application request. This subjects it to potential exposure much more than is desirable for a private key. In the future, a means to automatically change the server's private key on a daily basis, using a higher level key, is desirable. Also, a hardware implementation of DES supporting write-only master keys is highly desirable for the Kerberos servers. Another problem that is not easily dealt with at the moment is authenticating the workstation to the user. How does a user know that an adversary hasn't modified the software on the machine he or she is using so that it will store the secret key? One approach to this problem is to have ____ ____ the user carry around a boot disk. The user would then boot the machine off that disk, and upon logging in, the authentication would be taken care of by software on that disk. The problem with this approach though, is that it requires the user to carry something extra around. Another approach, although not practical at the moment, is the use of _____ _____ smart cards that would do the encryption for initial authentication internally. With this approach, the key never leaves the card, thus, there's nothing for a spoofer to store except the session key (which has a limited lifetime). The representation of names as entered by the user is somewhat awkward. The timestamp granularity for requests -- 5 ms. -- is more than sufficient for software encryption, 4.3BSD, and current processors, but may be too large for systems 5 years from now. (The granularity will have to be reduced and the fields extended, and the systems will have to provide higher resolution timestamps than the 10ms currently provided by 4.3BSD UNIX.) The timestamp base used in the protocols is based on the Berkeley UNIX _______________ 6 The service's timestamp window is the valid range for time_sec for ws_now which the service will honor a request. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 40 clock standard rather than the ARPA internet clock standard used elsewhere in TCP/IP protocol family; the IP standard should be used instead. 7.3. Well Known Services All Kerberos installations should adhere to the following conventions: - The following literals are reserved Kerberos principal names: _ _ ______ ________ _______ {K,M}, krbtgt, changepw, default. - The Kerberos service is accessible at a well known UDP port, 750. The Kerberos administration protocol is carried on via UDP port 7 ________ 751. In UNIX implementations, these ports are named kerberos and ________ ______ kerberos_master, respectively. 7.4. Revision History 7.4.1. Revision 7 --> Release v1.1 Revision 7 represents the definitive specification for the August 1986 Athena staff release of Kerberos. - Protocol changed to only allow one ticket request up front. This was done to decrease the complexity of the protocol, and to allow implementations that are forced to limit the number of tickets returned to interact with others. This change was made after reliability problems resulted from the complextity of the old protocol, and network limitations. For a while, both the old protocol (V3) and the new protocol (V4) will be supported. 7.4.2. Revision 6 --> Release v1.0 Revision 6 represents the definitive specification for the May 1986 Athena staff release of Kerberos. Major changes: - Moved the design proposals for authorization into a new document, entitled "Project Athena Technical Plan -- Authorization _______________ 7 These two port assignments are not official ones. An official assignment is needed. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 41 Proposals". ___ _____ ____ ___ - Added Kerberos err_reply message type and an appl_err, the latter ____ ___ _______ ___ message for use with safe_msg and private_msg. - Disallowed wildcard lookups for ticket requests (either via an authentication request or ticket-granting-ticket request); ____ ________ ________ removed the cleartext service {name,instance} and lifetime from the corresponding reply messages. _____ - Added a flags field to the beginning of the ticket, to include the byte order of the system granting the ticket. ___ ___ ___ ___ _____ - Changed the name of the des_set_key routine to key_sched. ____ ___ _______ ___ - Modified the safe_msg and private_msg protocols to streamline ___ ____ ________ them, removed the app_code, and replaced the sequence number with timestamps. ___ ____ - Added the cleartext exp_date of the requesting principal to the ____ _____ auth_reply message. 7.4.3. Rev 5 Major changes: - Split authentication and authorization into two independent services; removed authorization information from the ___ __ authentication protocols. Redefined the term KDC/AS to be the Key Distribution Center/Authentication Server. - Changed the naming of users and services to a single, unified ____ ________ _____ name model of {name, instance}, with an optional realm specified. Modified protocols to reflect the new naming model. - Added a discussion of replication for the authentication database. - Added more discussion of realms. - Added protocols for secure conversations. ______ ___ - Deleted most references to the existing athena_reg Athena Unix login database. 7.4.4. Rev 4 Major changes: ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 42 _____ - Added an authentication realm realm to qualify all uses of the ____ ________ authentication name {name,instance}. This allowed future enhancements to support authentication across administratively independent Kerberos services, for example between Athena's Kerberos and one at LCS. (This is similar to the Internet domains, but not necessarily equivalent.) ____ ________ ________ - Added the cleartext service {name,instance} and lifetime to the ____ _____ authentication reply message, auth_reply. This supported the use of wildcard requests by returning to the requestor a readable version of the specific servers and instances selected. - Specified byte ordering in the least significant bit of the ____ ___ ____ auth_msg_type. The transmitter of each message sends in its natural byte order, while the receiver converts the byte order as needed. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987 ______ _________ ____ _______ _ _ _ ____ __ Athena Technical Plan Section E.2.1, page 43 __________ REFERENCES _ 1. Bauer, R.K., Berson, A., and Feiertag, R.J. "A Key Distribution ___ ____________ __ ________ _______ _ Protocol Using Event Markers". ACM Transactions on Computer Systems 1, 3 (August 1983), 249-255. _ 2. Birrell, Andrew D. et. al. "Grapevine: An Exercise in Distributed ____ __ Computing". CACM 25, 4 (April 1982), 260-274. _ 3. Birrell, A.D. "Secure Communication Using Remote Procedure Calls". ___ ____________ __ ________ _______ _ ACM Transactions on Computer Systems 3, 1 (February 1985), 1-14. _ 4. Denning, Dorothy E. and Sacco, Giovanni Maria. "Timestamps in Key ____ __ Distribution Protocols". CACM 24, 8 (August 1981), 533-536. _ 5. Gifford, D.K. "Cryptographic Sealing for Information Secrecy and ____ __ Authentication". CACM 25, 4 (April 1982), 274-286. _ ______________ ___ ______________ __ ________ ________ 6. Girling, C. G. Representation and Authentication on Computer Networks. Ph.D. Th., University of Cambridge, April 1983. Technical report 37. _ 7. Jaeger, Eric. Protocol for Trusted Third Party Access Control. Bachelor Thesis, Massachusetts Institute of Technology, February 1985. _ 8. Kent, Steven T. Encryption-Based Protection Protocols for Interactive User-Computer Communications. Master Th., Massachusetts Institute of Technology,May 1976. MIT-LCS Tech Report TR-162. _ 9. Miller, Steven P. Security for Local Area Networks. Tech. Rept. TR-227, Digital Equipment Corporation, August, 1983. __ _____________ ________ _______ 10. Needham, R.M. and Herbert, A.J.. International Computer Science ______ ___ _________ ___________ _________ ______ Series. Volume ??:The Cambridge Distributed Computing System. Addison-Wesley, London, 1982. __ 11. Needham, R. M. and Schroeder M. D. "Using Encryption for ____ __ Authentication in Large Networks of Computers". CACM 21, 12 (Dec 78), 993-999. __ 12. Neuman, Barry Clifford. Sentry, A Discretionary Access Control Server. Bachelor Thesis, Massachusetts Institute of Technology, May 1985. __ 13. Popek, Gerald J. and Kline, Charles S. "Encryption and Secure _________ _______ __ Computer Networks". Computing Surveys 11, 4 (December 1979), 331-356. __ 14. Voydock, Victor L., and Kent, Stephen T. "Security Mechanisms in _________ _______ __ High-Level Network Protocols". Computing Surveys 15, 2 (June 1983), 135-171. ________ ______________ ___ _____________ ______ __ ___ ____ Kerberos Authentication and Authorization System 21 Dec 1987