Kerberos

Kerberos
Trusted key server system from MIT
Based on Needham-Shroeder
Signifies multi-headed dog in Greek
mythology (keep outsiders away)
provides centralised private-key third-party
authentication in a distributed network
 allows users access to services distributed

through network
 without needing to trust all workstations

 rather all trust a central authentication

server
two versions in use: 4 & 5
 Kerberos Requirements
first published report identified its
requirements as:

security
 reliability
 transparency
 scalability
implemented using an authentication
protocol based on Needham-Schroeder
 Kerberos Realms
a Kerberos environment consists of:
 a Kerberos server
 a number of clients, all registered with
server
 application servers, sharing keys with
server
this is termed a realm

typically a single administrative domain
if have multiple realms, their Kerberos
servers must share keys and trust
 Kerberos 4 Overview
a basic third-party authentication scheme
have an Authentication Server (AS)
 users initially negotiate with AS to identify self
 AS provides a non-corruptible authentication
credential (ticket granting ticket TGT)
have a Ticket Granting server (TGS)
 users subsequently request access to other
services from TGS on basis of users TGT
Tickets and Ticket-Granting Tickets
users, resources: principal share
master key with KDC
KDC sends to A: KA{KAB}
Bob ; ticket: KB{KAB} + other
information (name of Alice)
Alice tickets expire in 21 hours
thus: knowledge of KAB proves identity
+ use for encryption
credentials: KAB and ticket
Alice logs in with uid and passwd
password generates master key
workstation asks for session key SA on
behalf of Alice (time-limited)
KDC sends SA to workstation
ticket-granting ticket (TGT) KDC{SA ….}
master key

workstation uses Alice’s master key to

decrypt SA
Then workstation forgets master key, uses
TGT
KDC: authentication server (AS) + ticket-
granting server (TGS)
 Configuration
KDC master key encrypts KDC database,
TGT – Kerberos server
DES-based
principals need to remember password
(humans) or key (machines)
KDC  database of names of all
principals for which it is responsible
 How does Kerberos Work
Four parties involved
 Alice : client workstation
 Authentication Server (AS) : Verifies the
user during login ; shares unique passwd
with every user

Ticket Granting Server (TGS) : Issues
tickets to certify proof of identity

Bob : server offerings services such as
network printing, file sharing or an
application program
Step 1
•Alice on public workstation enter the name
•Workstation sends plain text name to AS
•AS performs several actions
•Creates package of username & random session
key(KS) encrypted with the key shared between AS and
TGS  TGT
•(TGT and KS ) encrypted using symmetric key derived
from the passwd of Alice(KA)

Alice AS
Login
Id = Alice
•AS sends back encrypted session key and TGT to
Alice

Alice Output*
AS

Session key
Alice (KS)

Symmetric key shared with the

Ticket Granting Server (TGS) Encrypt

Session key TGT

AS computes the output as shown (KS)
below and sends it to Alice in response
to her login request.
KS+TGT

Symmetric key derived from

Alice’s password (KA) Encrypt

Output*
•Step 2 : Alice sends a request for SGT to the TGS
•Contains TGT, id of server (Bob)& current timestamp
encrypted with session key

Alice TGS
Request for a SGT

Output*

Timestamp

Encrypt Session key (KS)

AS computes the output as shown below
and sends it to the TGS.
Encrypted
Timestamp TGT Bob
(ET)

Output*
 •TGS sends response back to Alice

Alic Output*
TGS
e

Alice KAB

B’s secret key Encrypt

Bob KAB

Session Key (KS) Encrypt

Output*
•Step 3
•User contacts Bob for accessing the server
•Alice sends KAB securely to Bob

Alic SendingSending
KABKAB Bob
e
Output*

Timestamp

Alice had received this

Secret key to be shared
Encrypt from the TGS in the
by Alice and Bob (KAB)
previous step
Encrypted
(Alice + KAB) encrypted with
Timestamp
Bob’s secret key
(ET)

Output*
 •Bob acknowledges the receipt of KAB

Acknowledging KAB
Alic Bob
e
Encrypted Timestamp
(ET)*

Timestamp sent by Alice.

First add 1 to it.

Secret key shared

Encrypt
by Alice and Bob
(KAB)
Encrypted
Timestamp
(ET)*
Kerberos 4 Overview
 Replicated KDCs
KDC: single PoF (in addition to NFS. . . )
replication with master copy (multiple KDC)
One site holds the master copy updates
can be done (still POF) but KDC is normally
read only
performance scaling: service location
protocol?
exchange master database in clear,
protected by secure hash
Avoid bottleneck
 Realms
can’t have single (replicated) KDC: need to limit
trust
limit compromise
Principals are divided into realms each having a KDC
each realm carries others as principals
principal: name (service), instance (host, human
role), realm
no chaining of realms: prevent rogue KDC
impersonating everybody
V4: DNS names
 Interrealm Authentication
N realms
The principals in one realm need to
authenticate one in others.
Supported by Kerberos
The KDC in realm B can be registered as
a principal in realm A
V4 does not support chaining of KDC’s
 Interrealm Authentication
TGS_REQ(“alice@Wonderland”,

Wonderland KDC
Oz@wonderland

Credentials to Oz

Oz KDC

Dorothy
Alice

TGS_REQ(“alice@Wonderland”,Dorothy@Oz

Credentials to Dorothy

AP _ REQ
 Key Version Numbers
allow unsynchronized changes of master
keys
remember several versions of past keys
replication  new passwords may fail
 Kerberos Version 5
developed in mid 1990’s
provides improvements over v4
 addresses environmental shortcomings
encryption algo, network protocol, byte order, ticket
lifetime, authentication forwarding, interrealm auth
 and technical deficiencies
double encryption, non-std mode of use, session keys,
password attacks
specified as Internet standard RFC 1510
 Names
Kerberos V4 client is named by three
fields

Name, instance, realm
V%  2 components
 Realm and name
 Delegation of Rights
transfer rights to object, for limited time & scope
can’t delegate: contain network address of
requestor
V5: ask for TGT for different node or any node
(audit!)
may grant TGT or ticket to specific service
Forwardable: exchange for TGT with different
address
may ask for TGT that can again be forwarded
Proxy tickets
 Ticket Lifetimes
unlimited lifetime instead of 21 hours
– start time (may be postdated into the
future)
– end time (may be adjusted)
– authorization time (initial TGT)
– renew-till = upper bound on renewal
– postdating may require revalidation à
revocation
renewable ticket
can’t renew expired ticket
 Key Protection
single password in all realms à same
masterkey
compromise one KDC à compromise all
solution: master key depends on realm
 Cryptographic Algorithms

V4: DES only  export-controlled, limited

security
 V5: algorithm indication, but not negotiation
 only as secure as weakest algorithm
accepted
 should use MD (secret / message)
 Hierarchy of Realms
V4: each realm must be registered in “origin” realm
V5: allow chaining  e.g., Alice in A talk to Carol in
C; C not registered in A
B registered in A, C in B
allows realm B to impersonate anybody
list transit domains (reject if KDC named doesn’t
match key)
trust: transit or for principals
realm tree: share key with parents, children
allow only shortest path through tree (lowest
common ancestor)
identify tree based on names (domain hierarchy)
cross links as shortcuts