Kerberos: An Authentication Service for Open Network Systems Jennifer G. Steiner Clifford Neuman Jeffrey I. Schiller

Kerberos is a commonly used authentication scheme for open networks. Developed by MIT's Project Athena, Kerberos is named for the three-headed dog who, according to Greek mythology, guards the entrance of Hades. What is KERBEROS?

A distributed system project established in 1983 for support educational and research computing at MIT. Led to many developments in operating systems and networking computing. Ended in June The Athena system was taken over by Information Systems and incorporated with the present MIT computing infrastructure.

Authentication and Authorization Authentication is the process of determining whether someone of something is, in fact what it is declared to be. Authorization is the process of granting or denying access to a network resource.

In a network of users requiring services from many computers, there are three approaches one can take to access control: Do nothing (rely on the machine) ; Require the host to prove its identity (trust the host’s word); Require the user to prove her/his identity whenever requires a service. Authors took the third approach

Requirements of an identification mechanism Secure (obviously) Reliable Transparent Scalable

KERBEROS Designed to provide strong authentication for client/server applications by using secret key cryptography. Lets a user request an encrypted “ticket” from an authentication process that can be used to request a particular service from a server. Provides three distinct levels of protection

Kerberos software components Kerberos applications library - Routines for creating or reading authentication requests Encryption library - Routines for encryption based on DES Database library and database administration programs - Routines for management and administration of database Administration server - Read – write interface to the database

Kerberos software components (2) Authentication server - Read only operations on the Kerberos database DB propagation software - Manages replication of the Kerberos database User programs - Changing passwords, displaying tickets.

Kerberos Names A name consists of a primary name an instance, and a realm, expressed as The primary name is the name of the user or the service The instance is used to distinguish among variations on the primary name. The realm is the name of an administrative entity that maintains authentication data. Example: Consider the user RLSmith who desires authentication through the LCS.MIT.EDU realm using a system management instance. That user might log in as follows:

Kerberos authentication There are three phases to authentication through kerberos: 1.The user obtains credentials to be used to access to other services. 2.The user requests authentication for a specific service. 3.The user presents those credentials to the end server.

Credentials Tickets and authenticators Ticket Is used to securely pass the identity of the person to whom the ticket was issue between the authentication server and the end server. {s, c, addr, timestamp, life, K s,c } K s Authenticator Contains 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 {c, addr, timestamp}K s,c

Authentication Scenarios Getting the Initial Ticket User enter her/his username. A request is sent to the authentication server containing the user’s name and the name of a special service called ticket granting service. Authentication server checks that it know about the client and generates a random session key. Authentication server creates a ticket for the ticket granting server. Authentication server sends the ticket along with a copy of the random session key back to the client. 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 are stored; user’s password and DES key are erased.

Authentication Scenarios Requesting a service The application builds an authenticator containing the client’s name and IP address, and the current time. The client sends the authenticator along with the ticket to the server in a manner defined by the individual application. Once the authenticator and the ticket have been received by the server, the server processes all the information to see if everything matches. If everything matches it allows the request to proceed. If the client specifies that it wants the server to prove its identity too, the server adds one to the timestamp and sends the result back to the client.

Authentication Scenarios Getting Server Tickets When a program request a ticket it sends a request to the ticket granting server. The request contains the name of the server for which the ticket is requested, along with the ticket granting ticket and and authenticator. The ticket granted server then checks the authenticator and ticket granting ticket. 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. The ticket granting server then sends the ticket back to the client.

Kerberos authentication protocols Kerberos User/ Client Server TGS 1.Request for a TGS ticket 2.Ticket for TGS 3.Request for a Server Ticket 4.Ticket for Server 5.Request for service

The Kerberos Database Write access to the database is perform by the administration service called the Kerberos Database Management Service (KDBM). The KDBM handles request from users to change their passwords. It also accept requests from Kerberos administrators.

The KDBM Server The KDBM server accepts requests to add principals to the database or change the password for existing principals. The ticket granting service will not issue tickets for it. All requests to the KDBM program are logged. Kadmin or kpasswd programs are used to add principals and change passwords

Database Replication Each Kerberos realm has a master Kerberos machine, which houses a master copy of the authentication database. Master Slave kprop kpropd

Interaction with other kerberi Kerberos support multiple administrative domains. The specification of names includes a field called the realm. This field contains the name of the administrative domain within the user is to be authenticated. In order to perform cross-realm authentication, it is necessary that the administrators of each pair of realms select a key to be shared between their realms.

Issues and Open Problems Decide the correct lifetime for a ticket. How to allow proxies. How to guarantee workstation integrity.

S.P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, Section E.2.!: Kerberos Authentication and Authorization System, M.I.T Project Athena, Cambridge, Massachusetts (December 21, 1987) A. D. Mihalik, Project Athena: MIT’s computing environment has grown from an experiment to an impressive, ubiquitous network. Retrieved from tech.mit.edu/V119/N19/history _of_athe.19f.html on november 12, tech.mit.edu/V119/N19/history _of_athe.19f.html References