This page was last modified on 8 June 2016, at 14:17.
Kerberos is a trusted third-party authentication service based on the model presented by Needham and Schroeder. 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 Kent. 
- 1 General Provisions
- 2 How It Works
- 3 The Kerberos Database
- 4 Kerberos From the Outside Looking In
- 5 References
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 determines 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 connection, 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 sending passwords over the network.
How It Works
This section describes the Kerberos authentication protocols. The following abbreviations are used in the figures.
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.
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 identity of the person to whom the ticket was issued between the authentication server and the end server. A ticket also passes information that can be used to make sure that the person using the ticket is the same person to which it was issued. The authenticator contains the additional information which, when compared against that in the ticket proves that the client presenting the ticket is the same one to which the ticket was issued.
A ticket is good for a single server and a single client. It contains the name of the server, the name of the client, the Internet address of the client, a timestamp, a lifetime, and a random session key. This information is encrypted using the key of the server for which the ticket will be used. Once the ticket has been issued, it may be used multiple times by the named client to gain access to the named server, until the ticket expires. Note that because the ticket is encrypted in the key of the server, it is safe to allow the user to pass the ticket on to the server without having to worry about the user modifying the ticket (see Figure 3).
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).
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 password will be compromised, while at the same time not allowing a user to properly authenticate her/himself without knowledge of that password. The process of logging in appears to the user to be the same as logging in to a timesharing system. Behind the scenes, though, it is quite different (see Figure 5).
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.
The authentication server checks that it knows about the client. If so, it generates a random session key which will later be used between the client and the ticket-granting server. It then creates a ticket for the ticket-granting server which contains the client’s name, the name of the ticket-granting server, the current time, a lifetime for the ticket, the client’s IP address, and the random 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 tampered with, no information exists that will allow someone else to impersonate the user beyond the life of the ticket.
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 information in the ticket with that in the authenticator, the IP address from which the request was received, and the present time. If everything matches, it allows the request to proceed (see Figure 6).
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 discarded.
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 authenticator, encrypts the result in the session key, and sends the result back to the client (see Figure 7).
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 key which no one else knows, and can safely assume that a reasonably recent message encrypted in that key originated with the other party.
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.
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 service.
The ticket-granting server then sends the ticket, along with the session key and other information, back to the client. This time, however, the reply is encrypted in the session key that was part of the ticket-granting ticket. This way, there is no need for the user to enter her/his password again. Figure 9 summarizes the authentication protocols.
The Kerberos Database
Up to this point, we have discussed operations 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).
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 Management Service (KDBM). The current implementation 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).
Note that, while authentication can still occur (on slaves), administration requests cannot be serviced if the master machine is down. In our experience, this has not presented a problem, as administration requests are infrequent.
The KDBM handles requests from users to change their passwords. The client side of this program, which sends requests to the KDBM over the network, is the kpasswd program. The KDBM also accepts requests from Kerberos administrators, who may add principals to the database, as well as change passwords for existing principals. The client side of the administration program, which also sends requests to the KDBM over the network, is the kadmin program.
The KDBM Server
The KDBM server accepts requests to add principals to the database or change the passwords for existing principals. This service is unique in that the ticket-granting service will not issue tickets for it. Instead, the authentication service 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 system.
When the KDBM server receives a request, it authorizes it by comparing the authenticated principal name of the requester of the change to the principal name of the target of the request. If they are the same, the request is 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 principal name is found in this file, the request is permitted, otherwise it is denied.
By convention, names with a NULL instance (the default instance) do not appear in the access control list file; instead, an admin instance is used. Therefore, for a user to become an administrator of 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 Kerberos administration then s/he would use for normal login.
All requests to the KDBM program, whether permitted or denied, are logged.
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).
Users may change their Kerberos passwords 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.
Each Kerberos realm has a master Kerberos 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 advantages of having multiple copies of the database are those usually cited for replication: higher availability and better performance. If the master machine is down, authentication can still be achieved on one of the slave machines. The ability to perform 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 program, 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 master 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 calculates a checksum of the data it has received, and if it matches the checksum sent by the master, the new information is used to update the slave’s database.
All passwords in the Kerberos database are encrypted in the master database key Therefore, the information passed from master to slave over the network is not useful to an eavesdropper. However, it is essential that only information from the master host be accepted by the slaves, and that tampering of data be detected, thus the checksum.
Kerberos From the Outside Looking In
The section will describe Kerberos from the practical point of view, first as seen by the user, then from the application programmer’s viewpoint, and finally, through the tasks of the Kerberos administrator.
User’s Eye View
If all goes well, the user will hardly notice that Kerberos is present. In our UNIX implementation, the ticket-granting ticket is obtained from Kerberos as part of the login process. The changing of a user’s Kerberos password is part of the passwd program. And Kerberos tickets are automatically destroyed when a user logs out.
If the user’s login session lasts longer than the lifetime of the ticket-granting ticket (currently 8 hours), the user will notice Kerberos’ presence because the next time a Kerberos-authenticated application is executed, it will fail. The Kerberos ticket for it will have expired. At that point, the user can run the kinit program to obtain a new ticket for the ticket-granting server. As when logging in, a password must be provided in order to get it. A user executing the klist command out of curiosity may be surprised at all the tickets which have silently been obtained on her/his behalf for services which require Kerberos authentication.
From the Programmer’s Viewpoint
A programmer writing a Kerberos application will often be adding authentication to an already existing network application consisting of a client and server side. We call this process ‘ ‘Kerberizing’ ’ a program. Kerberizing usually involves making a call to the Kerberos library in order to perform authentication at the initial request for service. It may also involve calls to the DES library to encrypt messages and data which are subsequently sent between application client and application server.
The most commonly used library functions are krb_mk_req on the client side, and krb_rd_req on the server side. The krb_mk_req routine takes as parameters the name, instance, and realm of the target server, which will be requested, and possibly a checksum of the data to be sent. The client then sends the message returned by the krb_mk_req call over the network to the server side of the application. When the server receives this message, it makes a call to the library routine krb_rd_req. The routine returns a judgement about the authenticity of the sender’s alleged identity.
If the application requires that messages sent between client and server be secret, then library calls can be made to krb_mk_priv (krb_rd_priv) to encrypt (decrypt) messages in the session key which both sides now share.
The Kerberos Administrator’s Job
The Kerberos administrator’s job begins with running a program to initialize the database. Another program must be run to register essential principals in the database, such as the Kerberos administrator’s name with an admin instance. The Kerberos authentication server and the administration server must be started up. If there are slave databases, the administrator must arrange that the programs to propagate database updates from master to slaves be kicked off periodically.
After these initial steps have been taken, the administrator manipulates the database over the network, using the kadmin program. Through that program, new principals can be added, and passwords can be changed.
In particular, when a new Kerberos application is added to the system, the Kerberos administrator must take a few steps to get it working. The server must be registered in the database, and assigned a private key (usually this is an automatically generated random key). Then, some data (including the server’s key) must be extracted from the database and installed in a file on the server’s machine. The default file is /etc/srvtab . The krb_rd_req library routine called by the server (see the previous section) uses the information in that file to decrypt messages sent encrypted in the server’s private key. The /etc/srvtab file authenticates the server as a password typed at a terminal authenticates the user.
The Kerberos administrator must also ensure that Kerberos machines are physically secure, and would also be wise to maintain back-ups of the Master database.
- R. M. Needham and M. D. Schroeder, ‘‘Using Encryption for Authentication in Large Networks of Computers,’’ Communications of the ACM 21(12), pp.993-999 (December, 1978)
- Jennifer G. Steiner, Clifford Neuman, and Jeffrey I. Jennifer G. Steiner, Clifford Neuman, and Jeffrey I, 1988
- W. J. Bryant, Kerberos Programmer’s Tutorial, M.I.T. Project Athena (In preparation)
- W. J. Bryant, Kerberos Administrator’s Manual, M.I.T. Project Athena (In preparation)