| Prepared by
Adam M. Costello
Last modified: 1997-Sep-26-Fri 08:16:25 GMT |
by Jennifer G. Steiner, Clifford Neuman, and Jeffrey
I. Schiller
summarized by Adam M. Costello
When users use services on machines that are strictly controlled by an administrative authority, the machines can prevent unauthorized access. When some machines on the network are outside the control of the authority, but all service requests come from controlled machines, the machines must be authenticated. But when requests can originate on uncontrolled machines, individual users must be authenticated.
Kerberos is an authentication service that must be trusted by every principal (client or server) in the realm (administrative domain). Each principal has a private key known only to it and to the Kerberos server, which runs on a physically secure machine. A user's private key is a function of his/her password. The Kerberos system includes application libraries for use by clients and servers, an encryption library based on DES, database tools for accessing and administering the key database, and a few end-user programs for logging in, changing passwords, and managing tickets.
Each principal has a name of the form primaryName[.instance]@realm. The optional instance is used to distinguish among different roles of a single person (e.g. john.admin versus regular john) or between identical servers running on different hosts (e.g. rlogin.priam [though another paper uses the form priam.rlogin]).
In order for a user to use a service, his/her client program must obtain a session key (technically a multi-session key) from the Kerberos server, which is to be used only by that particular user to talk to a particular server from a particular host, for a bounded amount of time. The session key, user name, server name, host address, timestamp, and time bound are packaged into a ticket, which is encrypted with the server's private key, and passed to the client. The session key is also passed to the client, encrypted with the user's private key. Henceforth, the client can authenticate itself to the server by sending a copy of the ticket plus an authenticator, which consists of the user name, host address, and a timestamp, all encrypted using the session key. The ticket proves that the session key was issued by Kerberos to allow the user to use the service from the host, and the authenticator proves that the client does indeed know the session key (assuming that the authenticator always reaches the server before an evesdropper has a chance to replay it, and that the server ignores any authenticator with a timestamp not strictly greater than the previous one). If necessary, the server can authenticate itself to the client by returning one plus the timestamp from the authenticator, encrypted using the session key. Because session keys are stored on the workstation, and the user's password is typed into the workstation, Kerberos is suited only for single-user workstations.
To avoid requiring the user to type a password every time a ticket
is obtained from the Kerberos server, a level of indirection is
used. There is one special service, the ticket-granting
service, with access to the key database, which grants
tickets to users for other services. Therefore, users need to type
their passwords on only two occasions. Usually, it is at login
time, to obtain a ticket for the ticket-granting server; a modified
login program handles this transparently. Also, after the
ticket-granting ticket expires (typically after 8 hours), a new ticket
can be obtained using kinit.
The KDBM server allows users to change their passwords (via
kpasswd, and administrators to modify the key database
via kadmin. KDBM authenticates users just like the
ticket-granting server does; hence a password must be entered every time
it is used.
There may be multiple Kerberos servers. All but the master have read-only copies of the key database.
Kerberos was developed as part of MIT's Project Athena, which
allows users to log in to any of a large number of single-user public
workstations and access their files, mail, printers, etc. Modified
rlogin and rsh programs are provided which use
Kerberos for authentication. A modified NFS server also uses Kerberos
authentication, although it compromises some security for performance:
NFS requests with forged source addresses can fool the server, but only
while the real user is logged in and using that file server.
Problems: If a ticket and its associated session key are somehow stolen (e.g. if the user forgets to log out of a public workstation), they can be used to impersonate the user for the lifetime of the ticket. There is no way for a user to grant a server the ability to use other services on his/her behalf. Public workstations might be running login spoofs, which appear like regular login prompts but actually record the password. See also Limitations of the Kerberos Protocol
|