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.
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. 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.
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  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.
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.
Figure 19.3 shows a schematic of the initial Kerberos authentication.
What is this ticket granting ticket? It is a block of data that contains two pieces of information:
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.
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.
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 File Server Service was able to establish the user's identity because:
After authentication takes place, the workstation uses the network service as usual.
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.
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.
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.
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 :
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.
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 .
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.
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.
Although Kerberos is an excellent solution to a difficult problem, it has several shortcomings:
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.