Kerberos: An Authentication Service for Open Network Systems
Steiner, Neuman, Schiller
One-line summary:
Describe the Kerberos authentication model as
implemented for MIT's Project Athena.
Three approaches to access control in a network of users requiring services
from many separate computers:
- Rely on machine to which user is logged on.
- Require the host to prove the user's identity.
- Require the user to prove it's identity for each service.
Requirements of the authentication mechanism:
- Reliable so the services can be also
- Secure from intruder
- Transparent to the user
- Scalable in the sense that the software would not break if systems without
Kerberos communicate to Athena hosts.
What is Kerberos?
- A third-party authentication service. Its security relies on the security
on several authentication servers, but not on the machines where the users log
in, nor the end servers providing services.
- Kerberos provides 3 levels of protection:
- Basic level: requires only that authenticity be established at the
initiation of a network connection, and can assume that further messages
from a given network address originate from the authenticated party.
- Safe messages: needs authentication of each message.
- Private messages: each message is authenticated and also encrypted.
- Components in the Athena implementation:
- Database (replicated with master and slaves) which contains name of each
principal, its private key, and other administrative info.
- Administration server (KDBM server) which makes changes to the database
- Authentication server (Kerberos server) which carries out the
authentication of principal, etc.
- Users and applications: log-on, change password, etc
How does it work?
- User obtain credentials to be used to request access to other services
-> user requests authentication for a specific service -> user presents
credentials to the end server providing the service specific services
- Credentials:
- Ticket: used to securely pass identity of the user between
authentication server and the end server.
{ s, c, addr, timestamp, life,
Ks,c } Ks
- Authenticator: proves the person holding the ticket is really the same
person the ticket was issued to.
{ c, addr, timestamp } Ks,c
- The Protocol:
- Request for TGS ticket: when user login, before typing in the password.
Client -> c, tgs -> Kerberos
- Getting the TGS ticket: user uses its password to decrypt the TGS
ticket.
Client <- { Kc,tgs , {Tc,tgs} Ktgs } Kc <- Kerberos
- Request for Server ticket: user uses the session key and the ticket
(from above) to request for a service ticket from TGS. Since TGS is also a
service, works like requesting a service.
Client -> s, { Tc,tgs }
Ktgs, { Ac } Kc,tgs -> TGS
- Getting the Server ticket: Client <- { { Tc,s } Ks, Kc,s } Kc,tgs
<- TGS
- Request for service: Client -> { Ac } Kc,s , { Tc,s } Ks
Issues and Problems:
- Lifetime for tickets: if too long the protocol can become weak, if too
short become transparent to user too quickly.
- Proxy: how can an authenticated user allow a server to acquire other
network services on its behalf?
- The protocol depends on user's workstation software being uncorrupted.