Kerberos

1
Kerberos
KERBEROS the fierce watchdog of Haides, depicted
as a three-headed dog with a serpent's tail, a
mane of snakes, and a lion's claws. "And
before them a dreaded hound, on watch, who has no
pity, but a vile stratagem as people go in he
fawns on all, with actions of his tail and both
ears, but he will not let them go back out, but
lies in wait for them and eats them up, when he
catches any going back through the gates."
-Theogony 769-774
2
Kerberos
"Herakles asked Pluto for Kerberos, and was told
to take the hound if he could overpower it
without using any of the weapons he had brought
with him. He found Kerberos at the gates of
Akheron, and there, pressed inside his armour and
totally covered by the lion's skin, he threw his
arms round its head and hung on, despite bites
from the serpent-tail, until he convinced the
beast with his choke-hold. Then, with it in tow,
he made his ascent through Troizen. After showing
Kerberos to Eurystheus, he took it back to Hades'
realm." -Apollodorus 2.1225-126
3
Kerberos
"When you have crossed the river and have
advanced a little further, some aged women
weaving at the loom will beg you to lend a hand
for a short time. But you are not permitted to
touch that either, for all these and many other
distractions are part of the ambush which Venus
will set to induce you to release one of the
cakes from your hands. Do not imagine that the
loss of a mere barley cake is a trivial matter,
for if you relinquish either of them, the
daylight of this world above will be totally
denied you. Posted there is a massive hound with
a huge, triple-formed head. This monstrous,
fearsome brute confronts the dead with thunderous
barking, though his menaces are futile since he
can do them no harm. He keeps constant guard
before the very threshold and the dark hall of
Proserpina, protecting that deserted abode of
Dis. You must disarm him by offering him a cake
as his spoils. Then you can easily pass him, and
gain immediate access to Proserpina herself
When you have obtained what she gives you, you
must make your way back, using the remaining cake
to neutralize the dogs savagery.
4
Kerberos (Modern Times)
Distributed authentication service Allows a
process (a client) running on behalf of a
principal (a user) to prove its identity to a
verifier (an application server, or just server)
without sending data across the network that
might allow an attacker or the verifier to
subsequently impersonate the principal.
Optionally provides integrity and
confidentiality for data sent between the client
and server. Developed in the mid-'80s as part
of MIT's Project Athena. As its use spread to
other environments, changes were needed to
support new policies and patterns of use. To
address these needs, design of Version 5 of
Kerberos began in 1989. Though V4 still runs at
many sites, V5 is considered to be standard
Kerberos.
5
Kerberos
Built upon the assumption that the network is
"unsafe". Example data sent over the
network can be eavesdropped and altered,
and addresses can also be faked. Therefore they
cannot be used for authentication
purposes. Trusted third-party service the
kerberos server is trusted by all the
entities on the network (users and services,
usually called principals). All
principals share a secret password (or key) with
the kerberos server and this enables principals
to verify that the messages from the kerberos
server are authentic. Thus trusting the
kerberos server, users and services can
authenticate each other.
6
Kerberos
C - Client V - Server C_at_addr - address of
client K_at_C - Secret Key of client known to
Authenticating Server K_at_V - Secret Key of
server known to Authenticating Server K_at_C,V -
Session Key for secure client/server
communication Ticket_at_C,V - Ticket issued for
client to send to server contains session
key, timestamp, lifetime, client address
7
Kerberos
Principals use tickets to prove that they are who
they claim to be. Example Client C wishes to
use service V. 1. C sends a ticket
request to the Authentication Server AS 2.
Ticket_at_C,V(K_at_C,V, time, lifetime, C_at_addr)
To C Ticket_at_C,VK_at_V, V, time, K_at_C,V,
lifetimeK_at_C
8
Kerberos
3. Before sending a message to V, C creates an
authenticator consisting of C's name, C's
address, the current time, and a "nonce"
chosen by C, all encrypted with the secret
session key
C, C_at_addr, time, nonceK_at_C,V.
Authenticator sent together with ticket to V.
V decrypts the ticket using V's secret key.
V gets session key from ticket. V uses
session key to decrypt authenticator. V
compares contents of ticket with that of
authenticator. V compares the timestamp
and nonce to prevent a replay attack. If
everything matches, V considers C to be properly
authenticated
9
Kerberos
4. Mutual Autentication (Optional) Server
extracts C's time from authenticator of 3.
Returns it to C encrypted with session key
timeK_at_C,V (Server was able to decrypt
authenticator - so if Kerberos Server is OK
Server must be OK since its secret key was used
to decrypt the authenticator)
10
Kerberos
Obtaining additional tickets Protocol
allows client with knowledge of user's password
to obtain ticket and session key for and to
prove its identity to any server registered
with the authentication server. User's
password must be presented each time the user
performs authentication with a new server.
Cumbersome instead, system should support
single sign-on, where
the user logs in to the system once, providing
the password at that time, and with
subsequent authentication
occurring automatically. Obvious way
to support this cache user's password on the
workstation (dangerous) - ticket and key
valid for short time, but
user's password can be used to obtain tickets,
and to impersonate the user until the
password is changed.
11
Kerberos
Obtaining additional tickets Better approach
cache only tickets and encryption keys
(collectively called credentials) that will work
for a limited period (typically on the order
of 8 hours). This is how Kerberos does
it. When user first logs in, an
authentication request is issued and a ticket
and session key for the ticket granting service
is returned by the authentication server.
This ticket, called a ticket granting
ticket, has a relatively short life (8
hours). The response is decrypted, the ticket and
session key saved, and the user's password
forgotten.

12
Kerberos
Obtaining additional tickets Subsequently,
when user wishes to prove its identity to a new
server, a new ticket is requested from the
authentication server using the ticket
granting exchange. The ticket granting
exchange is identical to the authentication
exchange except that the ticket granting request
has embedded within it an application
request, authenticating the client to the
authentication server, and the ticket granting
response is encrypted using the session key
from the ticket granting ticket, rather
than the user's password.

13
Kerberos
1. C, TGS, time, nonce - 1 and 2. Only on
first login 2. K_at_C,TGS, TGS, time,
nonceK_at_C, Ticket_at_C,TGSK_at_TGS 3. C,
C_at_addr, time, nonceK_at_C,TGS, Ticket_at_C,TGSK_at_
TGS, V, time, nonce 4. K_at_C,V, V,
time, nonceK_at_C,TGS, Ticket_at_C,VK_at_V 5.
time, nonce, KsubsessionK_at_C,V,
Ticket_at_C,VK_at_V 6. timeK_at_C,V (optional
mutual authentication)

14
Kerberos
Assume interorganizational communication Users
will not be registered with same authentication
server Realm authentication server with
registered users Cross Realm Authentication a
principal of one realm proves identity to an
authentication server of another realm Client
gets cross realm ticket to another TGS

15
Kerberos
TSV
ASV
TSV
TSV
ASV
ASV
TSV
TSC
ASV
ASC

1. Request for ticket to V_at_addr
V
C
16
Kerberos
TSV
ASV
TSV
TSV
ASV
ASV
2. Is V_at_addr in your domain?
TSV
TSC
ASV
ASC

V
C
17
Kerberos
TSV
ASV
3. Is V_at_addr in your domain?
TSV
TSV
ASV
ASV
TSV
TSC
ASV
ASC

V
C
18
Kerberos
TSV
ASV
4. Looking for V_at_addr Auth. Server
TSV
TSV
ASV
ASV
TSV
TSC
ASV
ASC

V
C
19
Kerberos
TSV
ASV
TSV
TSV
ASV
ASV
5. Looking for V_at_addr Auth. Server
TSV
TSC
ASV
ASC

V
C
20
Kerberos
TSV
ASV
TSV
TSV
ASV
ASV
6. Send a session key for TSv
TSV
TSC
ASV
ASC

V
C
21
Kerberos
...

22
Kerberos
TSV
ASV
TSV
TSV
ASV
ASV
9. Send a session key for TSv
TSV
TSC
ASV
ASC

V
C
23
Kerberos
TSV
ASV
TSV
TSV
ASV
ASV
TSV
TSC
ASV
ASC

10. Send a session key for TSv
V
C
24
Kerberos
TSV
ASV
TSV
TSV
ASV
ASV
TSV
TSC
ASV
ASC

11. Request ticket to V from TSv
V
C
25
Kerberos
Limitations Kerberos must be integrated with
other parts of the system. Does not protect
all messages sent between two computers only
protects the messages from software that has been
written or modified to use it. While it
may be used to exchange encryption keys when
establishing link encryption and network
level security services, this would require
changes to the network software of the hosts
involved. Kerberos does not itself provide
authorization, but V5 Kerberos passes
authorization information generated by other
services. In this manner, Kerberos can be
used as a base for building separate
distributed authorization services
26
Kerberos
Attacks Password Guessing Not
effective against password guessing attacks if a
user chooses a poor password, then an
attacker guessing that password can
impersonate the user. Post Password Theft
Kerberos requires a trusted path through
which passwords are entered. If the user
enters a password to a program that has already
been modified by an attacker (a Trojan
horse), or if the path between the user and
the initial authentication program can be
monitored, then an attacker may obtain sufficient
information to impersonate the user.
27
Kerberos
Attacks Impersonating A An impostor, C
could steal the authenticator and the ticket as
it is transmitted across the network, and use
them to impersonate A. The address in
the ticket and the authenticator was added to
make it more difficult to perform this attack.
To succeed C will have to either use the
same machine as A or fake the source
addresses of the packets. By including the time
stamp in the authenticator, C does not have
much time in which to mount the
attack. Impersonating B C can masquerade
B's network address, and when A sends its
credentials, C just pretends to verify them. C
can't be sure that it is talking to A.
28
Kerberos
Defenses Replay Cache (in Kerberos v.5)
Save the authenticators sent during the last
few minutes, so that B can detect when
someone is trying to retransmit an already used
message. Somewhat impractical (mostly
regarding efficiency). Mutual Authentication
To authenticate B, A requests B send something
back that proves B has access to the
session key. Example checksum that A sent
as part of authenticator plus 1. Message
Integrity and Confidentiality Session key
used to add cryptographic checksums to the
messages sent between A and B. Encryption
can also be added. This is probably the
best approach in all cases.
29
Public Key Infrastructure
Components necessary to securely distribute
public keys 1. Certificates (from a CA)
2. Repository for retreiving certificates 3.
Method of evaluating a chain of certificates from
public keys that are known and trusted
from trust anchors Trust Models Monopoly
model One organization is trusted by all
others to issue certificates. All
software contains PK of that CA. Monopoly
Registration Authorities Use other
organizations to check identities
and vouch for public keys Delegated CAs
Trust anchor issues certificates to other CAs.
Users can get a certificate from one
of the other CAs. Oligarchy Many trust
anchors, certificate from one is sufficient
Anarchy (PGP) Each user responsible for
configuring TAs.
30
Public Key Infrastructure
Monopoly There is no one universally trusted
organization Infeasible to change the key in
all software if it is compromised CA could
charge whatever it wants to issue
certificates Monopoly RAs More convenient
than above Delegated CAs Does recipient see
one certificate or a chain of them? Oligarchy
Worse than monopoly since any of trust anchors
could be comp. Trust anchors may be trusted by
vendor but not user! It is easy to trick a
naive user into accepting a bogus trust anchor
Users do not understand what's up ex use of
public terminal Unlikely a user will check
trust anchor list to see if it's
tampered Anarchy Could become unworkable on
large scale
31
Public Key Infrastructure
Name Constraints Assume CA trusted to issue
certs for only some users or domains Top-Down
with Name Constraints Tree of CAs, each can
only issue certs in their domain. Bottom-Up with
Name Constraints Each org creates its own PKI
and links to the WWW of PKIs
B/Y/Z
A
A/C
B/Y/Z/A
A/B
B/Y/Z/C
A/C/Y
A/B/K
A/B/X
B/Y/Z/A/C
32
Public Key Infrastructure
Bottom-Up with Name Constraints 1. Easy to
determine whether path exists 2. Hierarchy
corresponding to the name of the principal is
intuitive 3. PKI can be deployed in any org,
no need to pay someone to do it Can have
a PKI in your org even if lots of other orgs do
not 4. Damage due to compromised CA is one
level deep 5. Configuration is easy all CAs
can be reached beginning with your key
pair - new employee gets a key just like a badge
33
Public Key Infrastructure
Relative Names If an entire subtree of names
has to be moved, no certificates need to be
reissued Do not use name A/B/C/D but only D
on certificates from A/B/C - then if that
moves to H/Y, say, only certificates between
H/Y and ancestors need be reissued. Name
Constraints in Certificates Field in
certificate stating names that issuer allows to
be certified Can also disallow names. In
Bottom-Up model a parent CA is issued cert with
"allow any names except myself and below"
34
Public Key Infrastructure
Policies in Certificates Statement of how
carefully the identity of requestor is checked.
If not obeyed, no certificate is issued.
Can deny certificates to users not at high level
of security.
35
Public Key Infrastructure
Expiration and Revocation If certificates of
web service providers expire or are revoked,
then new ones have to be issued - thus,
down time So, browsers typically do not check
certificates Verisign demands are so high,
people do not get new certificates from
them - depending on browsers not to check
Hence, security is down the tubes.