--
`
`--
`
`Kerberos: An Authentication Service for Open Network Systems
`
`Jennifer G. Steiner
`
`Project Athena
`Massachusetts Institute of Technology
`Cambridge, MA 02139
`steiner@ATHENA.MIT.EDU
`
`Clifford Neuman†
`
`Department of Computer Science, FR-35
`University of Washington
`Seattle, WA 98195
`bcn@CS.WASHINGTON.EDU
`
`Jeffrey I. Schiller
`
`Project Athena
`Massachusetts Institute of Technology
`Cambridge, MA 02139
`jis@ATHENA.MIT.EDU
`
`Introduction
`This paper gives an overview of Kerberos,
`an authentication system designed by Miller and
`Neuman1 for open network computing environ-
`ments, and describes our experience using it at
`MIT’s Project Athena.2 In the first section of the
`paper, we explain why a new authentication
`model is needed for open networks, and what its
`requirements are. The second section lists the
`components of
`the Kerberos
`software
`and
`describes how they interact
`in providing the
`authentication service. In Section 3, we describe
`the Kerberos naming scheme.
`Section 4 presents the building blocks of
`Kerberos authentication − the ticket and the
`authenticator. This leads to a discussion of the
`two authentication protocols: the initial authenti-
`cation of a user
`to Kerberos
`(analogous to
`(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)
`† Clifford Neuman was a member of the Project Athena staff during the design and initial implementation phase of Ker-
`beros.
`
`logging in), and the protocol for mutual authenti-
`cation of a potential consumer and a potential
`producer of a network service.
`Kerberos requires a database of informa-
`tion about its clients; Section 5 describes the data-
`base, its management, and the protocol for its
`modification. Section 6 describes the Kerberos
`interface to its users, applications programmers,
`and administrators.
`In Section 7, we describe
`how the Project Athena Kerberos fits into the rest
`of the Athena environment. We also describe the
`interaction of different Kerberos authentication
`domains, or realms;
`in our case,
`the relation
`between the Project Athena Kerberos and the
`Kerberos running at MIT’s Laboratory for Com-
`puter Science.
`In Section 8, we mention open issues and
`problems as yet unsolved. The last section gives
`
`January 12, 1988
`
`Petitioner Apple Inc. - Ex. 1045, p. 1
`
`

`
`--
`
`--
`
`- 2 -
`
`the current status of Kerberos at Project Athena.
`In the appendix, we describe in detail how Ker-
`beros is applied to a network file service to
`authenticate users who wish to gain access to
`remote file systems.
`Conventions. Throughout
`this paper we
`use terms that may be ambiguous, new to the
`reader, or used differently elsewhere. Below we
`state our use of those terms.
`User, Client, Server. By user, we mean a
`human being who uses a program or service. A
`client also uses something, but is not necessarily
`a person; it can be a program. Often network
`applications consist of two parts; one program
`which runs on one machine and requests a remote
`service, and another program which runs on the
`remote machine and performs that service. We
`call those the client side and server side of the
`application, respectively. Often, a client will
`contact a server on behalf of a user.
`Each entity that uses the Kerberos system,
`be it a user or a network server, is in one sense a
`client, since it uses the Kerberos service. So to
`distinguish Kerberos clients from clients of other
`services, we use the term principal
`to indicate
`such an entity. Note that a Kerberos principal
`can be either a user or a server. (We describe the
`naming of Kerberos principals in a later section.)
`Service vs. Server. We use service as an
`abstract specification of some actions to be per-
`formed. A process which performs those actions
`is called a server. At a given time, there may be
`several servers
`(usually running on different
`machines) performing a given service. For exam-
`ple, at Athena there is one BSD UNIX rlogin
`server
`running on each of our
`timesharing
`machines.
`Key, Private Key, Password. Kerberos
`uses private key encryption. Each Kerberos prin-
`cipal is assigned a large number, its private key,
`known only to that principal and Kerberos.
`In
`the case of a user, the private key is the result of a
`one-way function applied to the user’s password.
`We use key as shorthand for private key.
`Credentials. Unfortunately, this word has a
`special meaning for both the Sun Network File
`System and the Kerberos system. We explicitly
`state whether we mean NFS credentials or Ker-
`beros credentials, otherwise the term is used in
`the normal English language sense.
`Master and Slave. It is possible to run Ker-
`beros authentication software on more than one
`
`there is always only one
`machine. However,
`definitive copy of the Kerberos database. The
`machine which houses this database is called the
`master machine, or
`just
`the master. Other
`machines may possess read-only copies of the
`Kerberos database, and these are called slaves.
`
`1. Motivation
`In a non-networked personal computing
`environment, resources and information can be
`protected by physically securing the personal
`computer.
`In a timesharing computing environ-
`ment, the operating system protects users from
`one another and controls resources.
`In order to
`determine what each user is able to read or
`modify, it is necessary for the timesharing system
`to identify each user. This is accomplished when
`the user logs in.
`In a network of users requiring services
`from many separate computers, there are three
`approaches one can take to access control: One
`can do nothing, relying on the machine to which
`the user is logged in to prevent unauthorized
`access; one can require the host to prove its iden-
`tity, but trust the host’s word as to who the user
`is; or one can require the user to prove her/his
`identity for each required service.
`the
`In a closed environment where all
`machines are under strict control, one can use the
`first approach. When the organization controls
`all the hosts communicating over the network,
`this is a reasonable approach.
`In a more open environment, one might
`selectively trust only those hosts under organiza-
`tional control.
`In this case, each host must be
`required to prove its identity. The rlogin and rsh
`programs use this approach.
`In those protocols,
`authentication is done by checking the Internet
`address from which a connection has been esta-
`blished.
`In the Athena environment, we must be
`able to honor requests from hosts that are not
`under organizational control. Users have com-
`plete control of their workstations:
`they can
`reboot them, bring them up standalone, or even
`boot off their own tapes. As such,
`the third
`approach must be taken;
`the user must prove
`her/his identity for each desired service. The
`server must also prove its identity. It is not suffi-
`cient to physically secure the host running a net-
`work server; someone elsewhere on the network
`may be masquerading as the given server.
`Our
`environment
`places
`
`several
`
`January 12, 1988
`
`Petitioner Apple Inc. - Ex. 1045, p. 2
`
`

`
`--
`
`--
`
`- 3 -
`
`Kent.4
`
`2.1. What Does It Do?
`Kerberos keeps a database of its clients and
`their private keys. The private key is a large
`number known only to Kerberos and the client it
`belongs to. In the case that the client is a user, it
`is an encrypted password. Network services
`requiring authentication register with Kerberos,
`as do clients wishing to use those services. The
`private keys are negotiated at registration.
`Because Kerberos knows these private
`keys, it can create messages which convince one
`client that another is really who it claims to be.
`Kerberos also generates temporary private keys,
`called session keys, which are given to two
`clients and no one else. A session key can be
`used to encrypt messages between two parties.
`Kerberos provides three distinct levels of
`protection. The application programmer deter-
`mines which is appropriate, according to the
`requirements of the application. For example,
`some applications require only that authenticity
`be established at the initiation of a network con-
`nection, and can assume that further messages
`from a given network address originate from the
`authenticated party. Our authenticated network
`file system uses this level of security.
`Other applications require authentication of
`each message, but do not care whether the content
`of the message is disclosed or not. For these,
`Kerberos provides safe messages. Yet a higher
`level of security is provided by private messages,
`where each message is not only authenticated, but
`also encrypted. Private messages are used, for
`example, by the Kerberos server itself for send-
`ing passwords over the network.
`
`2.2. Software Components
`The Athena
`implementation comprises
`several modules (see Figure 1). The Kerberos
`applications library provides an interface for
`application clients and application servers.
`It
`contains, among others, routines for creating or
`reading authentication requests, and the routines
`for creating safe or private messages.
`
`requirements on an identification mechanism.
`First, it must be secure. Circumventing it must be
`difficult enough that a potential attacker does not
`find the authentication mechanism to be the weak
`link. Someone watching the network should not
`be able to obtain the information necessary to
`impersonate another user. Second, it must be reli-
`able. Access to many services will depend on the
`authentication service.
`If it is not reliable, the
`system of services as a whole will not be. Third,
`it should be transparent. Ideally, the user should
`not be aware of authentication taking place.
`Finally, it should be scalable. Many systems can
`communicate with Athena hosts. Not all of these
`will support our mechanism, but software should
`not break if they did.
`Kerberos is the result of our work to satisfy
`the above requirements. When a user walks up to
`a workstation s/he ‘‘logs in’’. As far as the user
`can tell, this initial identification is sufficient to
`prove her/his identity to all the required network
`servers for the duration of the login session. The
`security of Kerberos relies on the security of
`several authentication servers, but not on the sys-
`tem from which users log in, nor on the security
`of the end servers that will be used. The authenti-
`cation server provides a properly authenticated
`user with a way to prove her/his identity to
`servers scattered across the network.
`Authentication is a fundamental building
`block for a secure networked environment. If, for
`example, a server knows for certain the identity
`of a client, it can decide whether to provide the
`service, whether the user should be given special
`privileges, who should receive the bill for the ser-
`vice, and so forth. In other words, authorization
`and accounting schemes can be built on top of the
`authentication that Kerberos provides, resulting
`in equivalent security to the lone personal com-
`puter or the timesharing system.
`
`2. What is Kerberos?
`Kerberos is a trusted third-party authentica-
`tion service based on the model presented by
`Needham and Schroeder.3 It
`is trusted in the
`sense that each of its clients believes Kerberos’
`judgement as to the identity of each of its other
`clients
`to be
`accurate. Timestamps
`(large
`numbers representing the current date and time)
`have been added to the original model to aid in
`the detection of replay. Replay occurs when a
`message is stolen off the network and resent later.
`For a more complete description of replay, and
`other issues of authentication, see Voydock and
`
`January 12, 1988
`
`Petitioner Apple Inc. - Ex. 1045, p. 3
`
`

`
`--
`
`--
`
`- 4 -
`
`(cid:1) Kerberos applications library
`(cid:1) encryption library
`(cid:1) database library
`(cid:1) database administration programs
`(cid:1) administration server
`(cid:1) authentication server
`(cid:1) db propagation software
`(cid:1) user programs
`(cid:1) applications
`
`Figure 1. Kerberos Software Components.
`
`Encryption in Kerberos is based on DES,
`the Data Encryption Standard.5 The encryption
`library
`implements
`those
`routines.
`Several
`methods of encryption are provided, with trade-
`offs between speed and security. An extension to
`the DES Cypher Block Chaining (CBC) mode,
`called the Propagating CBC mode, is also pro-
`vided.
`In CBC, an error
`is propagated only
`through the current block of the cipher, whereas
`in PCBC, the error is propagated throughout the
`message. This renders the entire message useless
`if an error occurs, rather than just a portion of it.
`The encryption library is an independent module,
`and may be replaced with other DES implementa-
`tions or a different encryption library.
`Another replaceable module is the database
`management system. The current Athena imple-
`mentation of the database library uses ndbm,
`although Ingres was originally used. Other data-
`base management libraries could be used as well.
`The Kerberos database needs are straight-
`forward; a record is held for each principal, con-
`taining the name, private key, and expiration date
`of the principal, along with some administrative
`information. (The expiration date is the date after
`which an entry is no longer valid. It is usually set
`to a few years into the future at registration.)
`Other user information, such as real name,
`phone number, and so forth, is kept by another
`server, the Hesiod nameserver.6 This way, sensi-
`tive information, namely passwords, can be han-
`dled by Kerberos, using fairly high security
`measures; while the non-sensitive information
`kept by Hesiod is dealt with differently; it can,
`for example, be sent unencrypted over the net-
`work.
`
`servers use the database
`The Kerberos
`library, as do the tools for administering the data-
`base.
`
`(or KDBM
`The administration server
`server) provides a read-write network interface to
`
`the database. The client side of the program may
`be run on any machine on the network. The
`server side, however, must run on the machine
`housing the Kerberos database in order to make
`changes to the database.
`The authentication server (or Kerberos
`server), on the other hand, performs read-only
`operations on the Kerberos database, namely, the
`authentication of principals, and generation of
`session keys. Since this server does not modify
`the Kerberos database, it may run on a machine
`housing a read-only copy of the master Kerberos
`database.
`Database propagation software manages
`replication of the Kerberos database. It is possi-
`ble to have copies of the database on several dif-
`ferent machines, with a copy of the authentication
`server running on each machine. Each of these
`slave machines receives an update of the Ker-
`beros database from the master machine at given
`intervals.
`there are end-user programs for
`Finally,
`logging in to Kerberos, changing a Kerberos
`password, and displaying or destroying Kerberos
`tickets (tickets are explained later on).
`
`3. Kerberos Names
`Part of authenticating an entity is naming it.
`The process of authentication is the verification
`that the client is the one named in a request.
`What does a name consist of? In Kerberos, both
`users and servers are named. As far as the
`authentication server
`is concerned,
`they are
`equivalent. A name consists of a primary name,
`an
`instance,
`and
`a
`realm,
`expressed
`as
`name.instance@realm (see Figure 2).
`
`bcn
`treese.root
`jis@LCS.MIT.EDU
`rlogin.priam@ATHENA.MIT.EDU
`
`Figure 2. Kerberos Names.
`
`The primary name is the name of the user
`or the service. The instance is used to distinguish
`among variations on the primary name. For
`users, an instance may entail special privileges,
`such as the ‘‘root’’ or ‘‘admin’’ instances. For
`services in the Athena environment, the instance
`is usually the name of the machine on which the
`server runs. For example, the rlogin service has
`different
`instances
`on
`different
`hosts:
`
`January 12, 1988
`
`Petitioner Apple Inc. - Ex. 1045, p. 4
`
`

`
`--
`
`--
`
`- 5 -
`
`rlogin.priam is the rlogin server on the host
`named priam. A Kerberos ticket is only good for
`a single named server. As such, a separate ticket
`is required to gain access to different instances of
`the same service. The realm is the name of an
`administrative entity that maintains authentication
`data. For example, different
`institutions may
`each have their own Kerberos machine, housing a
`different database. They have different Kerberos
`realms. (Realms are discussed further in section
`8.2.)
`
`4. How It Works
`This section describes the Kerberos authen-
`tication protocols. The following abbreviations
`are used in the figures.
`
`c
`s
`addr
`life
`tgs, TGS
`Kerberos
`KDBM
`Kx
`Kx,y
`{abc}Kx
`Tx,y
`Ax
`WS
`
`->
`->
`->
`->
`->
`->
`->
`->
`->
`->
`->
`->
`->
`
`client
`server
`client’s network address
`lifetime of ticket
`ticket-granting server
`authentication server
`administration server
`x’s private key
`session key for x and y
`abc encrypted in x’s key
`x’s ticket to use y
`authenticator for x
`workstation
`
`As mentioned above, the Kerberos authentication
`model is based on the Needham and Schroeder
`key distribution protocol. When a user requests a
`service, her/his identity must be established. To
`do this, a ticket is presented to the server, along
`with proof that the ticket was originally issued to
`the user, not stolen. There are three phases to
`authentication through Kerberos.
`In the first
`phase, the user obtains credentials to be used to
`request access to other services.
`In the second
`phase,
`the user
`requests authentication for a
`specific service.
`In the final phase,
`the user
`presents those credentials to the end server.
`
`4.1. Credentials
`There are two types of credentials used in
`the Kerberos authentication model: tickets and
`authenticators. Both are based on private key
`encryption, but they are encrypted using different
`keys. A ticket is used to securely pass the iden-
`tity of the person to whom the ticket was issued
`between the authentication server and the end
`
`server. A ticket also passes information that can
`be used to make sure that the person using the
`ticket is the same person to which it was issued.
`The authenticator contains the additional informa-
`tion which, when compared against that in the
`ticket proves that the client presenting the ticket is
`the same one to which the ticket was issued.
`A ticket is good for a single server and a
`single client. It contains the name of the server,
`the name of the client, the Internet address of the
`client, a timestamp, a lifetime, and a random ses-
`sion key. This information is encrypted using the
`key of the server for which the ticket will be used.
`Once the ticket has been issued, it may be used
`multiple times by the named client to gain access
`to the named server, until the ticket expires. Note
`that because the ticket is encrypted in the key of
`the server, it is safe to allow the user to pass the
`ticket on to the server without having to worry
`about the user modifying the ticket (see Figure 3).
`
`{s, c, addr, timestamp, life, Ks,c}Ks
`
`Figure 3. A Kerberos Ticket.
`
`Unlike the ticket, the authenticator can only
`be used once. A new one must be generated each
`time a client wants to use a service. This does not
`present a problem because the client is able to
`build the authenticator itself. An authenticator
`contains the name of the client, the workstation’s
`IP address, and the current workstation time. The
`authenticator is encrypted in the session key that
`is part of the ticket (see Figure 4).
`
`{c, addr, timestamp}Ks,c
`
`Figure 4. A Kerberos Authenticator.
`
`4.2. Getting the Initial Ticket
`When the user walks up to a workstation,
`only one piece of information can prove her/his
`identity:
`the
`user’s
`password.
`The
`initial
`exchange with the
`authentication server
`is
`designed to minimize the chance that the pass-
`word will be compromised, while at the same
`time not allowing a user to properly authenticate
`her/himself without knowledge of that password.
`The process of logging in appears to the user to
`be the same as logging in to a timesharing system.
`Behind the scenes, though, it is quite different
`(see Figure 5).
`
`January 12, 1988
`
`Petitioner Apple Inc. - Ex. 1045, p. 5
`
`

`
`--
`
`--
`
`Client
`
`c, tgs
`(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0) Kerberos
`
`Client
`
`(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0) Kerberos
`{Kc,tgs,{Tc,tgs} Ktgs}Kc
`
`Figure 5. Getting the Initial Ticket.
`
`The user is prompted for her/his username.
`Once it has been entered, a request is sent to the
`authentication server containing the user’s name
`and the name of a special service known as the
`ticket-granting service.
`it
`The authentication server checks that
`knows about the client. If so, it generates a ran-
`dom session key which will later be used between
`the client and the ticket-granting server.
`It then
`creates a ticket for the ticket-granting server
`which contains the client’s name, the name of the
`ticket-granting server, the current time, a lifetime
`for the ticket, the client’s IP address, and the ran-
`dom session key just created. This
`is all
`encrypted in a key known only to the ticket-
`granting server and the authentication server.
`The authentication server then sends the
`ticket, along with a copy of the random session
`key and some additional information, back to the
`client. This response is encrypted in the client’s
`private key, known only to Kerberos and the
`client, which is derived from the user’s password.
`Once the response has been received by the
`client, the user is asked for her/his password. The
`password is converted to a DES key and used to
`decrypt
`the response from the authentication
`server. The ticket and the session key, along with
`some of the other information, are stored for
`future use, and the user’s password and DES key
`are erased from memory.
`Once the exchange has been completed, the
`workstation possesses information that it can use
`to prove the identity of its user for the lifetime of
`the ticket-granting ticket. As long as the software
`on the workstation had not been previously tam-
`pered with, no information exists that will allow
`someone else to impersonate the user beyond the
`life of the ticket.
`
`- 6 -
`
`4.3. Requesting a Service
`For the moment, let us pretend that the user
`already has a ticket for the desired server.
`In
`order to gain access to the server, the application
`builds an authenticator containing the client’s
`name and IP address, and the current time. The
`authenticator is then encrypted in the session key
`that was received with the ticket for the server.
`The client then sends the authenticator along with
`the ticket to the server in a manner defined by the
`individual application.
`Once the authenticator and ticket have been
`received by the server, the server decrypts the
`ticket, uses the session key included in the ticket
`to decrypt the authenticator, compares the infor-
`mation in the ticket with that in the authenticator,
`the IP address from which the request was
`received, and the present
`time.
`If everything
`matches, it allows the request to proceed (see Fig-
`ure 6).
`
`Client
`
`{Ac}Kc,s, {Tc,s}Ks
`(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0) Server
`
`Figure 6. Requesting a Service.
`
`It is assumed that clocks are synchronized
`to within several minutes.
`If the time in the
`request is too far in the future or the past, the
`server treats the request as an attempt to replay a
`previous request. The server is also allowed to
`keep track of all past requests with timestamps
`that are still valid. In order to further foil replay
`attacks, a request received with the same ticket
`and timestamp as one already received can be dis-
`carded.
`Finally, if the client specifies that it wants
`the server to prove its identity too, the server adds
`one to the timestamp the client sent in the authen-
`ticator, encrypts the result in the session key, and
`sends the result back to the client (see Figure 7).
`
`Client
`
`(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0) Server
`{timestamp + 1} Kc,s
`
`Figure 7. Mutual Authentication.
`
`At the end of this exchange, the server is
`certain that, according to Kerberos, the client is
`who it says it is. If mutual authentication occurs,
`the client
`is also convinced that the server is
`authentic. Moreover, the client and server share a
`
`January 12, 1988
`
`Petitioner Apple Inc. - Ex. 1045, p. 6
`
`

`
`--
`
`--
`
`- 7 -
`
`key which no one else knows, and can safely
`assume
`that
`a
`reasonably
`recent message
`encrypted in that key originated with the other
`party.
`
`4.4. Getting Server Tickets
`Recall that a ticket is only good for a single
`server. As such,
`it
`is necessary to obtain a
`separate ticket for each service the client wants to
`use. Tickets
`for
`individual
`servers can be
`obtained from the ticket-granting service. Since
`the ticket-granting service is itself a service, it
`makes use of
`the
`service
`access protocol
`described in the previous section.
`When a program requires a ticket that has
`not already been requested, it sends a request to
`the ticket-granting server (see Figure 8). The
`request contains the name of the server for which
`a ticket
`is requested, along with the ticket-
`granting ticket and an authenticator built as
`described in the previous section.
`
`Client
`
`s,{Tc,tgs}Ktgs,{Ac}Kc,tgs
`(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0) TGS
`
`Client
`
`(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0) TGS
`{{Tc,s}Ks,Kc,s}Kc,tgs
`
`Figure 8. Getting a Server Ticket.
`
`The ticket-granting server then checks the
`authenticator
`and
`ticket-granting
`ticket
`as
`described above.
`If valid,
`the ticket-granting
`server generates a new random session key to be
`used between the client and the new server.
`It
`then builds a ticket for the new server containing
`the client’s name, the server name, the current
`time, the client’s IP address and the new session
`key it just generated. The lifetime of the new
`ticket is the minimum of the remaining life for the
`ticket-granting ticket and the default for the ser-
`vice.
`
`The ticket-granting server then sends the
`ticket, along with the session key and other infor-
`mation, back to the client. This time, however,
`the reply is encrypted in the session key that was
`part of the ticket-granting ticket. This way, there
`is no need for the user to enter her/his password
`again. Figure 9 summarizes the authentication
`protocols.
`
`Kerberos
`
`TGS
`
`2
`
`3
`
`4
`
`1
`
`User/
`Client
`
`5
`(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)
`
`Server
`
`1. Request for TGS ticket
`2. Ticket for TGS
`3. Request for Server ticket
`4. Ticket for Server
`5. Request for service
`
`Figure 9. Kerberos Authentication Protocols.
`
`5. The Kerberos Database
`Up to this point, we have discussed opera-
`tions requiring read-only access to the Kerberos
`database. These operations are performed by the
`authentication service, which can run on both
`master and slave machines (see Figure 10).
`
`WS
`
`WS
`
`WS
`
`Slave
`
`Master
`
`Figure 10. Authentication Requests.
`
`In this section, we discuss operations that
`require write access to the database. These
`operations are performed by the administration
`service, called the Kerberos Database Manage-
`ment Service (KDBM). The current implementa-
`tion stipulates that changes may only be made to
`the master Kerberos database; slave copies are
`read-only. Therefore,
`the KDBM server may
`only run on the master Kerberos machine (see
`Figure 11).
`
`January 12, 1988
`
`Petitioner Apple Inc. - Ex. 1045, p. 7
`
`

`
`--
`
`--
`
`- 8 -
`
`WS
`
`WS
`
`WS
`
`Slave
`
`Master
`
`Figure 11. Administration Requests.
`
`Note that, while authentication can still occur (on
`slaves), administration requests cannot be ser-
`viced if the master machine is down.
`In our
`experience, this has not presented a problem, as
`administration requests are infrequent.
`The KDBM handles requests from users to
`change their passwords. The client side of this
`program, which sends requests to the KDBM over
`the network,
`is the kpasswd program. The
`KDBM also accepts requests from Kerberos
`administrators, who may add principals to the
`database, as well as change passwords for exist-
`ing principals. The client side of the administra-
`tion program, which also sends requests to the
`KDBM over the network, is the kadmin program.
`
`5.1. The KDBM Server
`The KDBM server accepts requests to add
`principals to the database or change the pass-
`words for existing principals. This service is
`unique in that the ticket-granting service will not
`issue tickets for it. Instead, the authentication ser-
`vice itself must be used (the same service that is
`used to get a ticket-granting ticket). The purpose
`of this is to require the user to enter a password.
`If this were not so, then if a user left her/his
`workstation unattended, a passerby could walk up
`and change her/his password for them, something
`which should be prevented. Likewise,
`if an
`administrator left her/his workstation unguarded,
`a passerby could change any password in the sys-
`tem.
`
`When the KDBM server receives a request,
`it authorizes it by comparing the authenticated
`principal name of the requester of the change to
`the principal name of the target of the request. If
`they are the same, the request is permitted.
`If
`they are not the same, the KDBM server consults
`an access control
`list (stored in a file on the
`
`master Kerberos system). If the requester’s prin-
`cipal name is found in this file, the request is per-
`mitted, otherwise it is denied.
`By convention, names with a NULL
`instance (the default instance) do not appear in
`instead, an admin
`the access control
`list file;
`instance is used. Therefore, for a user to become
`an administrator of Kerberos an admin instance
`for that username must be created, and added to
`the access control list. This convention allows an
`administrator to use a different password for Ker-
`beros administration then s/he would use for nor-
`mal login.
`to the KDBM program,
`requests
`All
`whether permitted or denied, are logged.
`
`5.2. The kadmin and kpasswd Programs
`Administrators of Kerberos use the kadmin
`program to add principals to the database, or
`change the passwords of existing principals. An
`administrator is required to enter the password for
`their admin instance name when they invoke the
`kadmin program. This password is used to fetch a
`ticket for the KDBM server (see Figure 12).
`
`Kerberos
`
`KDBM
`
`2
`
`3
`
`1
`
`User/
`Admin
`
`1. Request for KDBM ticket
`2. Ticket for KDBM
`3. kadmin or kpasswd request
`
`Figure 12. Kerberos Administration Protocol.
`
`Users may change their Kerberos pass-
`words using the kpasswd program. They are
`required to enter their old password when they
`invoke the program. This password is used to
`fetch a ticket for the KDBM server.
`
`5.3. Database Replication
`Each Kerberos realm has a master Ker-
`beros machine, which houses the master copy of
`the
`authentication database.
`It
`is possible
`(although not necessary)
`to have additional,
`read-only copies of
`the database on slave
`machines
`elsewhere
`in
`the
`system.
`The
`
`January 12, 1988
`
`Petitioner Apple Inc. - Ex. 1045, p. 8
`
`

`
`--
`
`--
`
`- 9 -
`
`advantages of having multiple copies of the data-
`base are those usually cited for
`replication:
`higher availability and better performance. If the
`master machine is down, authentication can still
`be achieved on one of the slave machines. The
`ability to perform authentication on any one of
`several machines reduces the probability of a
`bottleneck at the master machine.
`Keeping multiple copies of the database
`introduces the problem of data consistency. We
`have found that very simple methods suffice for
`dealing with inconsistency. The master database
`is dumped every hour. The database is sent, in its
`entirety, to the slave machines, which then update
`their own databases. A program on the master
`host, called kprop, sends the update to a peer pro-
`gram, called kpropd, running on each of the slave
`machines (see Figure 13). First kprop sends a
`checksum of the new database it is about to send.
`The checksum is encrypted in the Kerberos mas-
`ter database key, which both the master and slave
`Kerberos machines possess. The data is then
`transferred over the network to the kpropd on the
`slave machine. The slave propagation server cal-
`culates a checksum of the data it has received,
`and if it matches the checksum sent by the master,
`the new information is used to update the slave’s
`database.
`
`Master
`(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)
`
`kprop
`(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)
`
`(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)
`kpropd
`
`(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)(cid:0)
`Slave
`
`(cid:0)(cid:0)(cid:0)(c