Kerberos

8 minute read

UCL Course COMP0133: Distributed Systems and Security LEC-13

Goal

Authentication of diverse entities for diverse services

Authentication in “open environment”

Users may be superuser on their own workstations & Hardware not centrally controlled

\( \implies \) services can be accessed by anyone over network without authentication
Same user population may use many machines and services

As drop-in replacement of passwords for pre-existing protocols (i.e., talnet) to be convenient

Central Authority & Principals

A central database server (trusted by all principals) stores

names: human readable followed by naming rules
keys: 56-bit DES symmetric key

for all principals

Users (can have instances)
Machines
Services
Realm (Site Name)

all machines in one administrative domain share one central Kerberos database (in same realm)

e.g., name.instance@realm

Protocol

Goal: mutually authenticated communication

Two principals wish to communicate
Principals know each other by name in central database
Kerberos establishes shared secret between the two principals
Can use shared secret to encrypt or MAC subsequent communication

Actually in assigned paper, few “Kerberized” services encrypt, and none “Kerberized” services MAC

Approach: leverage keys shared with central database

Kerberos Credentials

There are some significant concepts in Kerberos Credentials

Session Keys

\[K_{c,s}\]

which are randomly generated by central database when client \( c \) want to talk to server \( s \)

Tickets

\[T = \{s, \ c, \ addr_c, \ \textit{timestamp}, \ \textit{lifetime}, \ K_{c,s}\}_{K_s}\]

where

\( K_s \) is the key server \( s \) shared with central database

\( \quad \implies \) the ticket is encrypted by \( K_s \) and only servers can decrypt tickets

\( \textit{timestamp} \) is the real time when the ticket is created

\( \textit{lifetime} \) is the duration that the ticket is valid after \( \textit{timestamp} \)

Tickets are not designed for defending replay attacks since tickets can be used mutiple times

Authenticator

\[A = \{c, \ addr_c, \ \textit{timestamp} \}_{K_{c,s}}\]

which is created by clients (clients must know \( K_{c,s} \)) to replace password

Authenticator can be only used once which is designed for defending replay attacks

Step 1: Getting the Initial Ticket

\( \quad \) User still needs to log in at console with username and password

\( \quad \) where username is the corresponding Kerberos principal name
\( \quad \) Kerberos login program gets the initial ticket for the user by
\( \quad \) Client sends the following information to Kerberos central database on authentication server
\[c, \textit{tgs}\]
\( \quad \) where

\( \quad \) \( c \) is the Kerberos principal name of the client

\( \quad \) \( \textit{tgs} \) is the Kerberos principal name of ticket granting service
\( \quad \) Authentication server reponds the following information to client
\[\{K_{c,\textit{tgs}}, \ \{T_{c,\textit{tgs}}\}_{K_{\textit{tgs}}} \ \}_{K_c}\]
\( \quad \) where

\( \quad \) \( K_c = H(password_c) \)

\( \quad \) \( \{T_{c,\textit{tgs}}\}_{K_{\textit{tgs}}} = \{\textit{tgs}, \ c, \ addr_c, \ \textit{timestamp}, \ \textit{lifetime}, \ K_{c,\textit{tgs}}\}_{K_{\textit{tgs}}} \)
\( \quad \) Client decrypts the reponse to get the following information by its password

\( \quad \) \( K_{c,\textit{tgs}} \) - session key between client and ticket granting service

\( \quad \) \( T_{c,\textit{tgs}} \) - ticket between client and ticket granting service encrypted by \( K_{\textit{tgs}} \) (client cannot decrypt tickets)

Step 2: Getting Service Tickets of Server \( s \)

\( \quad \) Client sends the following information to ticket granting service:
\[s, \{T_{c,\textit{tgs}}\}_{K_\textit{tgs}} \ , \{A_c\}_{K_{c,\textit{tgs}}}\]
\( \quad \) Ticket granting service replies the following information to client with ticket for service on server \( s \)
\[\{\{T_{c,s}\}_{K_s},K_{c,s}\}_{K_{c,\textit{tgs}}}\]
\( \quad \) where

\( \quad \) \( K_{c,s} \) is a new and randomly generated session key between client \( c \) and server \( s \)

Step 3: Requesting Service on Server \( s \)

\( \quad \) Client sends the following information to server \( s \):
\[\textit{service_name}, \{T_{c,s}\}_{K_s}, \{A_c\}_{K_{c,s}}\]
\( \quad \) Server \( s \) checks the following information

\( \quad \) For ticket

\( \quad \) \( \bullet \ \) The private key \( K_s \) of server \( s \) matches?

\( \quad \) \( \bullet \ \) The Kerberos principal names of \( s \) and \( c \) matches?

\( \quad \) \( \bullet \ \) The IP address \( addr_c \) of \( c \) matches?

\( \quad \) \( \bullet \ \) The ticket is still valid (not expired) by \( \textit{timestamp} \) and \( \textit{lifetime} \) ?

\( \quad \) If all matched, server \( s \) takes session key \( K_{c,s} \) from ticket \( \{T_{c,s}\}_{K_s} \)

\( \quad \) For authenticator

\( \quad \) \( \bullet \ \) The session key \( K_{c,s} \) matches?

\( \quad \) \( \bullet \ \) The Kerberos principal name of \( c \) matches?

\( \quad \) \( \bullet \ \) The IP address \( addr_c \) of \( c \) matches?

\( \quad \) \( \bullet \ \) Check \( \textit{timestamp} \) is recent to defend replay attacks

\( \quad \) If all matched, server \( s \) will provide the corresponding service to client \( c \)

What kind of \( \textit{timestamp} \) is recent

Each server can enforce a expiration for authenticators (even currently there is no definition)

If \( \textit{timestamp} \) is in the past compared with time in server:

If \( \textit{timestamp} \) is within the enforced expiration, it will be accepted
If \( \textit{timestamp} \) is outside the enforced expiration, it will be rejected

If \( \textit{timestamp} \) is in the future compared with time in server:

It will be rejected

How to defend replay attacks using \( \textit{timestamp} \)

Each server will remember (store) the authenticator whose \( \textit{timestamp} \) is recent

For example,

if the enforced expiration of one server is set to 5 minutes,

all authenticators whose \( \textit{timestamp} \) within 5 minutes before the current time of the server will be stored
When server receives a stored (used) authenticator,

it will be regarded as a replay attack, then be rejected
Each server will forget (delete) the stored authenticator whose \( \textit{timestamp} \) is not recent any more

Ticket Lifetime

Convenience

longer ticket-granting ticket lifetime \( \implies \) user must type password less often

Performance

longer service ticket lifetime \( \implies \) client must request new service ticket less often

Risk

longer ticket lifetime lengthens period \( \implies \) more possibility ticket can be stolen, abused

Example

MIT Athena implementation destroys ticket-granting ticket when user logs out

Security Weakness

Replay Attacks

Kerberos version in the assigned paper does not cache the recent authenticators

therefore, replay attacks for recent authenticators in the enforced expiration are possible

where the time windonw for 5 minutes by default
Reliance on synchronized clocks across nodes

which needs clock synchronizing protocols which may not be secure (might be the weakest point)
Storage of tickets on workstations
No way to change compromised password securely
Key database focal point for attack
Hard to upgrade key database (relied on by all nodes in system)

User Inconvenience

Large (e.g., university-wide) Administrative Realms

University-wide admins often on critical path
Departments can’t add users or set up new servers
Cannot develop new services without central admins
Cannot upgrade software/protocols without central admins
Central admins have monopoly servers/services (cannot set up your own without a principal)

Rigid

what if user from realm A wants to authenticate himself to host at realm B?

Ticket Expirations

Must renew tickets every 12-23 hours
How to create long-running background jobs?

Endong Liu