[Chapter 19] 19.6 Kerberos

19.6 Kerberos

In 1983 the Massachusetts Institute of Technology, working with IBM and Digital Equipment Corporation, embarked on an eight-year project designed to integrate computers into the university's undergraduate curriculum. The project was called Project Athena.

Athena began operation with nearly 50 traditional time-sharing minicomputers: Digital Equipment Corporation's VAX 11/750 systems running Berkeley 4.2 UNIX . Each VAX had a few terminals; when a student or faculty member wanted to use a computer, he or she sat down at one of its terminals.

Within a few years, Athena began moving away from the 750s. The project received hundreds of high-performance workstations with big screens, fast computers, small disks, and Ethernet interfaces. The project's goal was to allow any user to sit down at any computer and enjoy full access to his files and to the network.

Of course there were problems. As soon as the workstations were deployed, the problems of network eavesdropping became painfully obvious; with the network accessible from all over campus, nothing prevented students (or outside intruders) from running network spy programs. It was nearly impossible to prevent the students from learning the superuser password of the workstations or simply rebooting them in single-user mode. To further complicate matters, many of the computers on the network were IBM PC/ATS that didn't have even rudimentary internal computer security. Something had to be done to protect student files in the networked environment to the same degree that they were protected in the time-sharing environment.

Athena's ultimate solution to this security problem was Kerberos, an authentication system that uses DES cryptography to protect sensitive information such as passwords on an open network. When the user logs in to a workstation running Kerberos, that user is issued a ticket from the Kerberos Server. The user's ticket can only be decrypted with the user's password; it contains information necessary to obtain additional tickets. From that point on, whenever the user wishes to access a network service, an appropriate ticket for that service must be presented. As all of the information in the Kerberos tickets is encrypted before it is sent over the network, the information is not susceptible to eavesdropping or misappropriation.

19.6.1 Kerberos Authentication

Kerberos authentication is based entirely on the knowledge of passwords that are stored on the Kerberos Server. Unlike UNIX passwords, which are encrypted with a one-way algorithm that cannot be reversed, Kerberos passwords are stored on the server encrypted with a conventional encryption algorithm - in this case, DES - so that they can be decrypted by the server when needed. A user proves her identity to the Kerberos Server by demonstrating knowledge of her key.

The fact that the Kerberos Server has access to the user's decrypted password is a result of the fact that Kerberos does not use public key cryptography. It is a serious disadvantage of the Kerberos system. It means that the Kerberos Server must be both physically secure and "computationally secure." The server must be physically secure to prevent an attacker from stealing the Kerberos Server and learning all of the users' passwords. The server must also be immune to login attacks: if an attacker could log onto the server and become root, that attacker could, once again, steal all of the passwords.

Kerberos was designed so that the server can be stateless.[14] The Kerberos Server simply answers requests from users and issues tickets (when appropriate). This design makes it relatively simple to create replicated, secondary servers that can handle authentication requests when the primary server is down or otherwise unavailable. Unfortunately, these secondary servers need complete copies of the entire Kerberos database, which means that they must also be physically and computationally secure.

[14] The server actually has a lot of permanent, sensitive state - the user passwords - but this is kept on the hard disk, rather than in RAM, and does not need to be updated during the course of Kerberos transactions.

19.6.1.1 Initial login

Logging into a UNIX workstation that is using Kerberos looks the same to a user as logging into a regular UNIX time-sharing computer. Sitting at the workstation, you see the traditional login: and password: prompts. You type your username and password, and if they are correct, you get logged in. Accessing files, electronic mail, printers, and other resources all work as expected.

What happens behind the scenes, however, is far more complicated, and actually differs between the two different versions of Kerberos that are commonly available: Kerberos version 4 and Kerberos version 5.

With Kerberos 4, the workstation sends a message to the Kerberos Authentication Server [15] after you type your username. This message contains your username and indicates that you are trying to log in. The Kerberos Server checks its database and, if you are a valid user, sends back a ticket granting ticket that is encrypted with your password. The workstation then asks you to type in your password and finally attempts to decrypt the encrypted ticket using the password that you've supplied. If the decryption is successful, the workstation then forgets your password, and uses the ticket granting ticket exclusively. If the decryption fails, the workstation knows that you supplied the wrong password and it gives you a chance to try again.[16]

[15] According to the Kerberos papers and documentation, there are two Kerberos Servers: the Authentication Server and the Ticket Granting Service. Some commentators think that this is disingenuous, because all Kerberos systems simply have a single server, the Kerberos Server or Key Server.

[16] Actually, the initial ticket that the Kerberos Server sends your workstation is encrypted with a 56-bit number that is derived from your password using a one-way cryptographic function.

With Kerberos 5, the workstation waits until after you have typed your password before contacting the server. It then sends the Kerberos Authentication Server a message consisting of your username and the current time encrypted with your password. The Authentication Server server looks up your username, determines your password, and attempts to decrypt the encrypted time. If the server can decrypt the current time, it then creates a ticket granting ticket, encrypts it with your password, and sends to you.[17]

[17] Why the change in protocol between Kerberos 4 and Kerberos 5? Under Kerberos 4, the objective of the designer was to minimize the amount of time that the user's password was stored on the workstation. Unfortunately, this made Kerberos 4 susceptible to offline password-guessing attacks. An attacker could simply ask a Kerberos Authentication Server for a ticket granting ticket for a particular user, then try to decrypt that ticket with every word in the dictionary. With Kerberos 5, the workstation must demonstrate to the Kerberos Authentication Server that the user knows the correct password. This is a more secure system, although the user's encrypted ticket granting ticket can still be intercepted as it is sent from the server to the workstation by an attacker and attacked with an exhaustive key search.

Figure 19.3 shows a schematic of the initial Kerberos authentication.

Figure 19.3: Initial Kerberos authentication

What is this ticket granting ticket? It is a block of data that contains two pieces of information:

The session key: Kses
A ticket for the Kerberos Ticket Granting Service, encrypted with both the session key and the Ticket Granting Service's key: EKtgsEKses{Ttgs}

The user's workstation can now contact the Kerberos Ticket Granting Service to obtain tickets for any principal within the Kerberos realm - that is, the set of servers and users who are known to the Kerberos Server.

Note that:

Passwords are stored on the Kerberos Server, not on the individual workstations.
The user's password is never transmitted on the network--encrypted or otherwise.
The Kerberos Authentication Server is able to authenticate the user's identity, because the user knows the user's password.
The user is able to authenticate the Kerberos Server's identity, because the Kerberos Authentication Server knows the user's password.
An eavesdropper who intercepts the ticket sent to you from the Kerberos Server will get no benefit from the message, because it is encrypted using a key (your password) that the eavesdropper doesn't know. Likewise, an eavesdropper who intercepts the ticket sent from the Kerberos Server to the Ticket Granting Service will not be able to make use of the ticket because it is encrypted with the Ticket Granting Service's password.

19.6.1.2 Using the ticket granting ticket

Once you have obtained a ticket granting ticket, you are likely to want to do something that requires the use of an authenticated service. For example, you probably want to read the files in your home directory.

Under Sun Microsystems' regular version of NFS , once a file server exports its filesystem to a workstation, the server implicitly trusts whatever the workstation wants to do. If george is logged into the workstation, the server lets george access the files in his home directory. But if george becomes the superuser on his workstation, changes his UID to be that of bill , and starts accessing bill' s files, the vanilla NFS server has no mechanism to detect this charlatanry or take evasive action.

The scenario is very different when the NFS has been modified to use Kerberos.

When the user first tries to access his files from a Kerberos workstation, system software on the workstation contacts the Ticket Granting Service and asks for a ticket for the File Server Service. The Ticket Granting Service sends the user back a ticket for the File Server Service, This ticket contains another ticket, encrypted with the File Server Service's password, that the user's workstation can present to the File Server Service to request files. The contained ticket includes the user's authenticated name, the expiration time, and the Internet address of the user's workstation. The user's workstation then presents this ticket to the File Server Service. The File Server Service decrypts the ticket using its own password, then builds a mapping between the ( UID ,IP address) of the user's workstation and a UID on the file server.

As before, all of the requests and tickets exchanged between the workstation and the Ticket Granting Service are encrypted, protecting them from eavesdroppers.

Figure 19.4: Workstation/file server/TGS communication

The Ticket Granting Service was able to establish the user's identity when the user asked for a ticket for the File Service, because:

The user's File Service Ticket request was encrypted using the session key, Ktgs
The only way the user could have learned the session key was by decrypting the original Ticket Granting Ticket that the user received from the Kerberos Authentication Server.
To decrypt that original ticket, the user's workstation had to know the user's password. (Note again that this password was never transmitted over the network.)

The File Server Service was able to establish the user's identity because:

The ticket that it receives requesting service from the user is encrypted with the File Server Service's own key.
Inside that ticket is the IP address and username of the user.
The only way for that information to have gotten inside the ticket was for the Ticket Granting Service to have put it there.
Therefore, the Ticket Granting Service is sure of the user's identity.
And that's good enough for the File Server Service.

After authentication takes place, the workstation uses the network service as usual.

NOTE: Kerberos puts the time of day in the request to prevent an eavesdropper from intercepting the Request For Service request and retransmitting it from the same host at a later time. This sort of attack is called a playback or replay attack .

19.6.1.3 Authentication, data integrity, and secrecy

Kerberos is a general-purpose system for sharing secret keys between principals on the network. Normally, Kerberos is used solely for authentication. However, the ability to exchange keys can also be used to ensure data integrity and secrecy.

If eavesdropping is an ongoing concern, all information transmitted between the workstation and the service can be encrypted using a key that is exchanged between the two principals. Unfortunately, encryption carries a performance penalty. At MIT 's Project Athena, encryption is used for transmitting highly sensitive information such as passwords, but is not used for most data transfer, such as files and electronic mail.

NOTE: For single-user workstations, Kerberos provides significant additional security beyond that of regular passwords. If two people are logged into the workstation at the same time, then the workstation will be authenticated for both users. These users can then pose as each other. This threat is so significant that at MIT 's Project Athena, network services such as rlogind and telnetd are disabled on workstations to prevent an attacker from logging in while a legitimate user is authenticated. It is also possible for someone to subvert the local software to capture the user's password as it is typed (as with a regular system).

In early 1996, graduate students with the COAST Laboratory at Purdue University discovered a long-standing weakness in the key generation for Kerberos 4. The weakness allows an attacker to guess session keys in a matter of seconds. A patch has been widely distributed; be sure to install it if you are using Kerberos 4.

19.6.1.4 Kerberos 4 vs. Kerberos 5

Kerberos has gone through 5 major revisions during its history to date. Currently, as we've mentioned, there are two versions of Kerberos in use in the marketplace.

Kerberos 4 is more efficient than Kerberos 5, but more limited. For example, Kerberos 4 can only work over TCP/IP networks. Kerberos 4 has a large installed base, but there is increasing support for Kerberos 5.

Kerberos 5 fixes minor problems with the Kerberos protocol, making it more resistant to determined attacks over the network. Kerberos 5 is also more flexible: it can work with different kinds of networks. Kerberos 5 also has provisions for working with encryption schemes other than DES , although there are (as of this writing) no implementations that use alternative encryption algorithms.

Finally, Kerberos 5 supports delegation of authentication, ticket expirations longer than 21 hours, renewable tickets, tickets that will work sometime in the future, and many more options.

19.6.2 Kerberos vs. Secure RPC

Kerberos is an authentication system, not an RPC system. Kerberos can be used with a variety of RPC schemes: versions of Kerberos are available for Sun RPC and for the X Window System (which has its own RPC specifically designed for network window systems). But Kerberos can also be used simply for exchanging keys. For example, there is a version of the telnet command that uses Kerberos to exchange a cryptographic key. MIT also modified the NFS protocol to work with Kerberos; the modification was a simple kernel patch to the NFS server that maintained a mapping between authenticated users on discrete hosts and UIDS on the NFS server.

There are other important differences between Kerberos and Secure RPC :

Secure RPC passwords are based on public key cryptography, not secret key cryptography. When the user wishes to prove her identity to the NIS server, she encrypts an authenticator and sends it to the Secure RPC server, which then decrypts her authenticator using the user's widely available public key. With Kerberos, identity is provided by knowing the secret key.
Secure RPC stores both the user's secret key and public key on the NIS server. The secret key is encrypted with the user's password and made available to the network, but the network does not have the ability to decrypt it. Thus, with Secure RPC , there is no need for a specially secured "authentication server" to establish the identity of users on the network.
Secure RPC is built into Sun's RPC system. While Kerberos requires that each application be specifically tailored. Secure RPC is a transparent modification to Sun's low-level RPC that works with any RPC -based service. Any application can use it simply by requesting AUTH_DES authentication.[18]

[18] If you are using recent versions of Sun's Solaris operating system, you can specify Kerberos authentication by requesting AUTH_KERB.

Kerberos is an add-on system that can be used with any existing network protocol. Project Athena uses Kerberos with NFS , remote login, password changing, and electronic mail. Sun Microsystems has added compatibility with Kerberos to its RPC system. Other software vendors, including the Open Software Foundation and IBM , have used the ideas pioneered by Kerberos as the basis of their own network security offerings.

19.6.3 Installing Kerberos

Installing Kerberos is a complicated process that depends on the version of Kerberos you have, the kind of computer, and the version of your computer's operating system. It's a difficult task that requires that you either have the source code for your computer system, or that you have source code for replacement programs. It is not a task to be undertaken lightly.

Fortunately, increasingly you don't have to. Kerberos or Kerberos-like security systems are now available from several companies, as well as being a standard part of several operating systems. These days, there is no reason to be running anything but secure network services.

The Kerberos source code is available for the cost of reproduction from MIT ; the address and ordering information are provided in Appendix E, Electronic Resources . Alternatively, you may use FTP to transfer the files over the Internet from the computer athena-dist.mit.edu .[19]

[19] Because of export restrictions, only U.S. and Canadian citizens may do so legally.

As the changes required to your system's software are substantial and subject to change, the actual installation process will not be described here. See the documentation provided with Kerberos for details.

19.6.4 Using Kerberos

Using a workstation equipped with Kerberos is only slightly different from using an ordinary workstation. In the Project Athena environment, all of the special Kerberos housekeeping functions are performed automatically: when the user logs in, the password typed is used to acquire a Kerberos ticket, which in turn grants access to the services on the network. Additional tickets are automatically requested as they are needed. Tickets for services are automatically cached in the /tmp directory. All of a user's tickets are automatically destroyed when the user logs out.

But Kerberos isn't entirely transparent. If you are logged into a Kerberos workstation for more than eight hours, something odd happens: network services suddenly stop working properly. The reason for this is that tickets issued by Kerberos expire after eight hours, a technique designed to prevent a "replay" attack. (In such an attack: somebody capturing one of your tickets would then sit down at your workstation after you leave, using the captured ticket to gain access to your files.) Thus, after eight hours, you must run the kinit program, and provide your username and password for a second time, to be issued a new ticket for the Kerberos Ticket Granting Service.

19.6.5 Kerberos Limitations

Although Kerberos is an excellent solution to a difficult problem, it has several shortcomings:

Every network service must be individually modified for use with Kerberos. Because of the Kerberos design, every program that uses Kerberos must be modified. The process of performing these modifications is often called "Kerberizing" the application. The amount of work that this entails depends entirely on the application program. Of course, to Kerberize an application, you must have the application's source code.
Kerberos doesn't work well in a time-sharing environment. Kerberos is designed for an environment in which there is one user per workstation. Because of the difficulty of sharing data between different processes running on the same UNIX computer, Kerberos keeps tickets in the /tmp directory. If a user is sharing the computer with several other people, it is possible that the user's tickets can be stolen, that is, copied by an attacker. Stolen tickets can then be used to obtain fraudulent service.
Kerberos requires a secure Kerberos Server. By design, Kerberos requires that there be a secure central server that maintains the master password database. To ensure security, a site should use the Kerberos Server for absolutely nothing beyond running the Kerberos Server program. The Kerberos Server must be kept under lock and key, in a physically secure area. In some environments, maintaining such a server is an administrative and/or financial burden.
Kerberos requires a continuously available Kerberos Server. If the Kerberos Server goes down, the Kerberos network is unusable.
Kerberos stores all passwords encrypted with a single key . Adding to the difficulty of running a secure server is the fact that the Kerberos Server stores all passwords encrypted with the server's master key, which happens to be located on the same hard disk as the encrypted passwords. This means that, in the event the Kerberos Server is compromised, all user passwords must be changed.
Kerberos does not protect against modifications to system software ( Trojan horses) . Kerberos does not have the computer authenticate itself to the user - that is, there is no way for a user sitting at a computer to determine whether the computer has been compromised. This failing is easily exploited by a knowledgeable attacker.[20]

[20] In fact, Trojan horses were a continuing problem at MIT's Project Athena.

An intruder, for example, can modify the workstation's system software so every username/password combination typed is recorded automatically or sent electronically to another machine controlled by the attacker. Alternatively, a malicious attacker can simply modify the workstation's software to spuriously delete the user's files after the user has logged in and authenticated himself to the File Server Service. Both of these problems are consequences of the fact that, even in a networked environment, many workstations (including Project Athena's) contain local copies of the programs that they run.
Kerberos may result in a cascading loss of trust. Another problem with Kerberos is that if a server password or a user password is broken or otherwise disclosed, it is possible for an eavesdropper to use that password to decrypt other tickets and use this information to spoof servers and users.

Kerberos is a workable system for network security, and it is still widely used. But more importantly, the principles behind Kerberos are increasingly available in network security systems that are available directly from vendors.