Kerberos: An Authentication Service for Computer Networks

Notes by Ralph Benzinger, 1999.  Cut and pasted some funny symbols from notes by Kevin LoGuidice, 1998.

Authentication

• au·then·ti·cate (&-'then-ti-"kAt): v. to prove sth to be valid or genuine or true (Middle English autentik, from Middle French autentique, from Late Latin authenticus, from Greek authentikos)
• Authentication in distributed computing environments: the process of assuring the identity of a principal (user) to a verifier (server)
• Workstations should not be trusted to identify users correctly to network services (authentication by assertion: BSD rhosts, Xauth, ...)
• Passwords may be intercepted by eavesdroppers and can be used to impersonate legitimate users

Kerberos

• Cerberus (kerberos), in Greek mythology, a three-headed, dragon-tailed dog that guarded the entrance to the lower world, or Hades. The monster permitted all spirits to enter Hades, but would allow none to leave.
• Kerberos is a trusted third-party authentication service for mutual authentication between a client and a server
• Part of Athena project; design goals: security, reliability, transparency, scalability
• Does not make any assumptions about workstations, but concentrates trust into authentication server
• Principal and authentication server share secret key, access to network services is granted through tickets and authenticators
• Timestamps are used to detect replay attacks

The Kerberos Protocol

Names

• AS = authentication service,  TGS = ticket granting service
• c = client name,  s = server name (denoted v in paper)
• T_c,s = ticket,  A_c = authenticator,  t_s = timestamp,  t_exp = expiration time
• K_c = client private key,  K_s = server private key,  K_c,s = session key,  K_c,_tgs = TGS session key
• {x}K = x encrypted with key K

Credentials

• Name:  name.instance@realm
• Ticket:  T_c,s = {c, s, t_s, t_exp, K_c,s}K_s
• Authenticator:  A_c = {c, t_s}K_c,s

Basic Authentication Protocol

1. Client -> AS: c, s
2. AS -> Client: {K_c,s, s}K_c, {T_c,s}K_s
3. Client -> Server: {A_c}K_c,s, {T_c,s}K_s
4. Server -> Client: {t_s+1}K_c,s (optional)

Complete Authentication Protocol

1. Client -> AS: c, tgs
2. AS -> Client: {K_c,tgs, tgs}K_c, {T_c,tgs}K_tgs
3. Client -> TGS: {t_s}K_c,tgs, {T_c,tgs}K_tgs, s
4. TGS -> Client: {K_c,s, s}K_c,tgs, {T_c,s}K_s
5. Client -> Server: {A_c}K_c,s, {T_c,s}K_s
6. Server -> Client: {t_s+1}K_c,s (optional)

Cross-Realm Authentication Protocol

• Ticket granting services share private keys for cross-realm authentication; hierarchical structure reduces the number of keys required
• Client obtains ticket for remote TGS from its local TGS using its ticket granting ticket
• Client obtains ticket for remote server from remote TGS using remote ticket granting ticket

Limitations

• Authentication server database is system's Achilles heel
• Slack in ticket lifetime does not eradicate replay attacks
• Susceptible to password guessing and Trojan horse attacks
• Proxies and rights forwarding unclear
• Requires Kerberized software

Questions

1. Who were the Greeks who escaped from Hades, and what did they use to get past Cerberus?
2. How does Kerberos compare to PGP?
3. Are there better ways to repel replay attacks?
4. Is password-based security still state of the art?