Kerberos: How Does the Other Guy Know Who I Am?
A portion of the text below was copied with permission from An Inessential Guide to Athena (5th edition) published by the MIT Student Information Processing Board.
MIT's Athena Project developed a system known as Kerberos to provide for security on a physically insecure network. A complete description of the mechanisms used by Kerberos to provide this security is beyond the scope of this document. This section describes why Kerberos is necessary in a distributed computing environment, the theory behind Kerberos (with pointers to further information), and the user commands which interface to Kerberos. It also gives hints for using Kerberos more effectively.
Why Kerberos is needed. Most moderately-sized to large computer systems use some form of password protection scheme to authenticate users; that is, they require a user who wishes to log in to give both his name and a secret password which only he and the computer system know. Anyone who happens to know the password can claim to be that user. It is therefore desirable to prevent people from listening in on the conversation between the computer and the user's terminal or workstation.
This is relatively easy in the case of terminals directly connected to the machine, since each terminal has its own cable. In a local-area network, several (typically between 10 and 200) computers share one cable, and any computer can listen in on any network traffic. With the advent of network monitoring packages for IBM PC's and similar machines, it is relatively easy for a determined user to set up a program to listen in on a network for any and all passwords being sent over. This would allow an intruder to masquerade as someone else, violating their privacy and perhaps stealing information (academic or otherwise). Note that THE ELECTRONIC COMMUNICATIONS PRIVACY ACT of 1986 makes this a Federal crime punishable by lots of nasty stuff (ask your lawyer for details).
In addition, since Athena (like the Internet) uses a workstation-based model of computation, with most operations taking place on a single-user workstation with occasional requests (for files, etc.) going to other "server" machines, Athena needed to set up some way to allow users to prove their identity to such server machines.
A few definitions. Knowledge of the following terms is not essential for use of Kerberos but is helpful in understanding what is going on:
user:A human being who wishes to use a computer system. A user, through his workstation, may make a series of requests to several servers in the course of a session, and would like to avoid (due to sheer laziness, among other things) having to type his password to each machine in question.
service:A program or set of programs running on a computer which is accessible over the network. The service would like to know with certainty that the workstation to which it is providing the service is really being used by the user who claims to be logged in on the workstation. Note that workstations are not services, and thus one may not use Kerberos to log into them over the network.
principal:An entity which can both prove its identity and verify the identities of other principals who wish to communicate with it; each user and each service registered with Kerberos is thus a principal.
ticket: A block of data which, when given to a user, enables her to prove her identity to a service. Tickets are stored in RAM in an area of memory reserved by the Kerberos cache. They are automatically erased when the computer is rebooted or when the user issues the destroy tickets command from Leash. They may also be destroyed from a Command Prompt by executing the command: kdestroy. Tickets contain information which must be considered private to the user, and thus should be protected. As they contain a time stamp, they cease to be valid after a limited time. One ticket is needed for each service; tickets are used to build authenticators, which are sent over the network to the service.
authenticator: A block of data which a user's workstation sends over the network to a specific service to prove that the workstation really is in use by that user. An authenticator expires after five minutes. One authenticator is typically built per session of use of a service; once the service decodes the authenticator, it generally permits the user to operate for as long as she wants. This behavior is not in any way mandated by the Kerberos suite of programs and libraries (it is just a detail of the implementation), but it is convenient and considered secure enough for most environments.
How It Works...
Kerberos uses a standard encryption-based authentication technique with a few variations designed to increase ease of use across administrative entities and reduce the number of possible "attacks" on the system. The system uses cryptographically sealed tickets and authenticators} which may be passed over the network and decrypted only by a user or machine which knows the appropriate encryption/decryption key.
Using Kerberos...
After obtaining your initial ticket getting ticket either by logging
onto your workstation or by utilizing a Kerberos Ticket Manager (e.g.,
Leash), Kerberos aware applications will generate authenticators and
obtain service tickets without further end user interaction.
Examples of programs which utilize Kerberos authentication include
e-mail, distributed file systems, remote login tools, and browsers.
Registering with Kerberos...
To use Kerberos you must have an account registered in a REALM
associated with the service(s) you wish to access. Contact your
network administrator to determine the registration procedures for your
organization.
Once registered with Kerberos, tickets are obtained by the login
program every time you log onto a workstation. You can also manually
obtain new tickets (which you usually do only if your old ones have
expired, 10 hours after you log in) by running the program kinit
.
It prompts for a username, requests an initial ticket from Kerberos,
and then asks for your password. If you are not registered with
Kerberos, it will print Principal unknown (Kerberos)
.
Unless you mistype your username, this should not happen. To correct
this, or any other errors, contact the appropriate Help Desk personnel
for your organization.