KERBEROS

 Kerberos draws its name from Greek mythology where a three headed dog safeguards the
entry of a gate.
 In similar lines, the Kerberos service is supposed to have three components namely
authentication, accounting and audit. It is intended to protect the network gate of an
organization.
 Out of three components only the authentication is primarily implemented and hence,
Kerberos is mainly treated as authentication service.
 Kerberos is developed at MIT (as part of project Athena).
 In Kerberos, an Authentication Server (AS) authenticates users and servers. Thus, users
upon authentication by AS can utilize the services of server or server can provide services
to authenticated users.
 Kerberos, though a complex protocol, relies on symmetric encryption instead of
asymmetric encryption.
 It treats user and system used by user (PC or work station or client machine) differently.
A user authentication is considered not system authentication because of the following:
 A user may pretend as another user while functioning from a system.
 Impersonation of system is possible by changing network or MAC address.
 Eavesdropping of messages exchanged between system and server is a possibility.
 Kerberos considers distributed client/server environment where users prove their identity
to server by entering correct password and then invokes desired service.
 Servers in turn also prove their identity to communicating clients.
 Authentication service in Kerberos is provided by capable Kerberos servers.
 Kerberos imposes following requirements:
 It should be secure enough such that finding information for impersonation or any
other potential weakness is not possible.
 Kerberos system should be highly reliable such that upon failure of Kerberos server,
another backup server may be used.
 A user should not bother about the authentication complexities. He should only enter
the password on client system.
 The Kerberos system should be highly scalable and hence, large number of clients and
servers can participate.
 The following points are worth mentioning:
 Kerberos is based upon Needham and Schroeder protocol.
 Both client and server trust Kerberos for mutual authentication.
 The trusted authentication service will be secure provided Kerberos server remains
physically secure.
 Kerberos is also used as Key Distribution Centre (KDC) for distributing keys securely
to users.
 Kerberos is available in two versions i.e. version 4 and version 5.
 In this text Kerberos version 4 is initially discussed (as it is most popular version like
IPv4) to build basic understanding and then specifics of version 5 are presented.
 Version 4 utilizes DES as the underlying symmetric encryption protocol.
 Before understanding the message exchanges under Kerberos, let us first understand some
of the elements and concepts in Kerberos.
 Key Distribution Centre (KDC): trusted third party who shares secret key with all
users (Fig 1). This helps in reducing the number of shared keys. Otherwise, for N user
communication, keys required are of the O(N2) i.e., for 6 users (6(6-1)/2)=15 shared
keys are required whereas using KDC only 6 keys are required.
 Ram KTinu Tinu
KRam

KAli KMegha
Ali SERVER Megha

KSameer
(KDC) KAmir

Sameer Total Symmetric Keys = 6

Amir

Figure 1 Sharing of secret key by KDC with all users

 Session Key: KDC shares secret keys with all users. For communication between any
two users, KDC uses their shared keys to authenticate each and to derive a new key
(session key) to be used for securing communication between the two users (Figure
2). The session key is used for a particular session between the two users and becomes
unusable after session expiry.
 Servers: The following three servers are used in Kerberos:
a) Authentication Server (AS):
AS plays the role of KDC. All the users register with AS who keep a database of
user identities and corresponding passwords. Main functionality of AS is to verify
the users via their passwords and to provide them session key to be used ahead
between user and Ticket-Granting Server. AS also gives ticket granting tickets to
the user.
b) Ticket Granting Server (TGS):
TGS issues service-granting tickets and session key to the users upon request.
Service-granting tickets are used to request service from real server while session
key is used to protect session between user and real server. In case user wants to
contact more than one server for different services, he has to contact TGS more
than once for different tickets for different services.
c) Real Server:
Real server provides actual services like Print, FTP, File etc. to the users.

For enhancing clarity, the user is named as Jai while real server is named as Veeru
[4]. Entire process involving user (Jai), AS, TGS, and Server (Veeru) is shown in
Figure 3 [1][2].

 Tickets:
Kerberos offer two kinds of tickets-
(1) Ticket-granting ticket:
Provided by AS to user (Jai) for request and authentication at TGS.
(2) Service–granting ticket:
Provided by TGS to user for request and authentication at real server.
 KDC
(User key shared KJai KVeeru (User key shared
with KDC) with KDC)

Jai Veeru
KJai-Veeru (Session key for communication
between Jai & Veeru)
Figure 2 Sharing and evolving session key between two users (Jai and Veeru) via
KDC

A, B, C, D, E, F processing steps 1, 2, 3, 4, 5, 6 messages exchanged

KDC (Kerberos) Server (Veeru)
Once per unit logon session

Once per User (Jai)

AS TGS
type of
service

(A) (1) Jai request AS for TGS-ticket

(2) AS provides session key (KJai-TGS)

(B)
and TGS ticket

(C) (3) Jai requests ticket for Veeru (server)

(4) TGS provides session key (KJai-Veeru) (D)

and Veeru (server) ticket

(E)
(5) Provides Veeru (server) ticket and asks
for access
(F)
Once per (6) Veeru verifies and grant access
service session

(A) User logs on and request service

(B) (i) AS verifies the user request via database.
(ii) It creates session key (KJai-TGS) and ticket granting ticket.
(iii) Derives the encryption key using password and use the key for encrypting data in (ii).
(C) (i) Client system prompts user for password.
(ii) Derives the decryption key from password & decrypts (2).
(iii) Creates (3) containing ticket-granting ticket & authenticator.
(iv) Sends (3) to TGS
(D) (i) TGS verifies ticket-granting ticket and authenticator.
(ii) Provides service-granting ticket in reply.
(E) Client system extracts service granting ticket and sends it to server in (5) along with
authenticator.
(F) (i) Server (Veeru) verifies service-granting ticket and authenticator and accordingly grants
access to user.
(ii) In case user (Jai) also requires server authentication, server creates and sends an authenticator.

Figure 3 Overview of Kerberos

  Kerberos realm:
Kerberos environment lying under single administrative domain having a Kerberos server
(containing Kerberos database), client systems and service providing servers. Thus, all
nodes in a realm share the Kerberos database. A copy of read only database exists on
backup Kerberos server. A Kerberos principal with proper privileges is able to make
changes or manage the Kerberos database. Nodes under different administrative control
(organizations) form different realms. Kerberos provides inter-realm authentication i.e.
authenticated users in one realm may demand for service by servers lying in other realm
or vice-versa.
Figure 4 Message Exchanges in Kerberos
User (Jai) AS TGS Server (Veeru)

Kerberos Server

(1) IDJ || IDTGS || TS1

(2) (KJ-TGS || IDTGS || TS2 || Lifetime2 || TicketTGS)

TicketTGS = (KJ-TGS || IDJ || AddrJ || IDTGS || TS2 || Lifetime2)

(3) IDV || TicketTGS || AuthenticatorJ

AuthenticatorJ = (IDJ || AddrJ || TS3)

(4) (KJ-V || IDV || TS4 || TicketV)

TicketV = (KJ-V || IDJ || AddrJ || IDV || TS4 || Lifetime4)

(5) TicketV || AuthenticatorJ

AuthenticatorJ = (IDJ || AddrJ || TS5)

(6) (TS5+1) (for mutual authentication)

The functioning of Kerberos protocol is shown in Figure 4. The messages exchanged are
elaborated in sequence as:

(1) User (Jai) requests AS by putting his ID and TGS server ID in the request. This means
that session key between this user and TGS server needs to be generated. A time stamp
(TS1) is also provided to AS for synchronizing the user clock (Jai’s clock) and to prevent
replays by attacker.

(2) AS performs following tasks:

i. Verifies user and then searches his password followed by generating a secret key (KJ)
based upon this password.
ii. Generates a session key between user and TGS server (KJ-TGS).
iii. Creates a ticket (TicketTGS) for accessing the ticket granting server.
 iv. Encrypts the message (2) using KJ. Message contains session key (KJ-TGS), ID of TGS
server, a fresh time stamp, a fresh lifetime and Ticket (TicketTGS). TicketTGS is already
encrypted by KTGS and hence can only be decrypted by TGS server. It contains session
key for TGS server (KJ-TGS), ID & address of Jai, ID of TGS server, timestamp when
ticket was created (TS2) and lifetime indicating validity period of this ticket.

(3) Jai (client) extracts TicketTGS and sends it along with ID (of server) and an authenticator.
The authenticator is evaluated by encrypting ID of Jai, his address and a timestamp (TS3)
using session key KJ-TGS. IDV (ID of Server) is kept so that TGS can issue a certificate to
access service of the real server (Veeru).

(4) TGS server first decrypts ticket using key (KTGS) and validity of ticket is checked via
timestamp (TS2) and lifetime (lifetime2). From the decrypted contents following is
assured:
a. The communicating peer/user identity. This confirms that this ticket is send by Jai.
b. TGS ID presence confirms that the ticket was issued for TGS server.
c. Extracted symmetric session key (KJ-TGS) is used further to decrypt the Jai’s
authenticator.

TGS server decrypts the authenticator using KJ-TGS and extracts IDJ, AddrJ and timestamp
(TS3). A match between this extracted ID (IDJ) and ID extracted from ticket at (a) above
means that the ticket is indeed send by Jai to whom the ticket (Ticket TGS) was issued, not
by an attacker.

After verification, TGS server generates service granting ticket (TicketV) for the user (Jai).
The TicketV is encrypted using real server key (KV) and it contains session key between
Jai and real server (KJ-V), ID & address of Jai (IDJ & AddrJ), ID of real server (for whom
TicketV is generated), fresh TGS server timestamp (TS4) and lifetime (lifetime4) for ticket
validity. TGS keeps same KJ-V, IDV, TS4 along with service-granting ticket (TicketV) in
message (4). The message (4) is then encrypted using session key (KJ-TGS).

(5) Jai decrypts using session key (KJ-TGS), verifies IDV and timestamp (TS4), extracts ticket
(TicketV) and creates message (5) containing TicketV and authenticator. Message (5) is
send to real server (Veeru). The authenticator is evaluated using session key (KJ-V). Upon
receipt of message (5), real server (V) authenticates user (Jai) and also ensures that ticket
is indeed send by Jai in a similar manner as done by TGS (at (4) above).

(6) Veeru (server) increments timestamp (TS5) by one and sends it to Jai (Client) for mutual
authentication. The incremented timestamp (TS5) is encrypted using session key (KJ-V).
Upon receipt of message (6), Jai easily authenticates server (Veeru).

Justification/Rationale for various IDS used:

The role and use of various IDS used in Kerberos for each message (1-5) is explained in Figure
5
 User (Jai) AS TGS Server (Veeru)

IDJ: for user identification at AS

IDTGS: for requesting TGS access by Jai
(1)

IDTGS: for indicating Veeru that the ticket is issued for TGS
IDJ (Inside Ticket): for confirming TGS that Jai is issued ticket after authentication at AS
IDTGS (Inside Ticket): for confirming TGS that ticket is meant for him
(2)

IDV: for requesting TGS that Jai wants services of server (Veeru)
IDJ (Inside authenticator): for proving that ticket was indeed issued to Jai
(3)

IDV: for indicating Jai that the ticket granting ticket is issued for server (Veeru)
IDJ (Inside Ticket): for confirming server (Veeru) that Jai is issued ticket after
authentication at TGS
IDV (Inside Ticket): for confirming server (Veeru) that ticket is meant for him
(4)

IDJ (Inside Authenticator): for proving that service ticket was indeed issued to Jai
(5)

Fig 5 Role/Use of various IDs used in Kerberos

Justification/Rationale for various timestamps and lifetimes
The role and use of various timestamps and lifetimes used in Kerberos for each message (1-6)
is explained in Figure 6

User (Jai) AS TGS Server (Veeru)

TS1: for clock synchronization of Jai with AS

(1)

TS2: for indicating time of issue of ticket

Lifetime2: for indicating validity of ticket issued
(2)

TS3: for indicating that authenticator is recently evaluated and is not an old one
(3)

TS4: for indicating time of issue of ticket to Jai and later to Veeru
(4)

TS5: for indicating that authenticator is recently evaluated and is not an old one
(5)

TS5+1 (Increment TS5): for indicating that server (Veeru) has received &
processed the previous message successfully and this reply is not a replayed one
(6)

Fig 6 Role/Use of various Timestamps and lifetimes used in Kerberos

Justification/Rationale for various tickets and authenticators

The role and use of various tickets and authenticators used in Kerberos for each message (1-4)
is explained in Figure 7
 User (Jai) AS TGS Server (Veeru)

TicketTGS: Ticket granting ticket issued to Jai after authentication at AS

(1)

TicketTGS: Ticket granting ticket forwarded to TGS for requesting service

granting ticket for server (Veeru)
AuthenticatorJ: Created by Jai to validate the TicketTGS at TGS
(2)

TicketV: Service granting ticket issued to Jai after authentication at TGS

(3)

TicketV: Service granting ticket forwarded to server (Veeru) for requesting service
AuthenticatorJ: Created by Jai to validate the TicketV at server (Veeru)
(4)

Fig 7 Role/Use of various tickets and authenticators used in Kerberos

Justification/Rationale for various keys used:

The role and use of various keys used in Kerberos for each message (1-5) is explained in Figure
8

(1) KJ: derived using Jai’s password and used to protect message (2) send to Jai.
(2) KJ-TGS: session key generated by AS and transferred to Jai in message (2) and
to TGS via message (3) (TicketTGS). Thus, KJ-TGS is used to protect message (3
& 4) exchanges between Jai & TGS without requiring a permanent shared
secret key.
(3) KTGS: secret key of TGS kept at AS used for securing TicketTGS.
(4) KJ-V: session key generated by TGS and transferred to Jai in message (4) and
to server (Veeru) via message (5) (TicketV). Thus, KJ-V is used to protect
message exchanges (5 & 6) between Jai & server (Veeru) without requiring a
permanent shared secret key.
(5) KV: secret key of server (Veeru) kept at TGS used for securing TicketV

Fig 8 Various keys used in Kerberos

Full service Kerberos environment for inter-realm authentication

The following are the requirements for full service Kerberos environment for inter-realm
authentication:
(1) All users are registered and their ID and hashed passwords are maintained in the database
at the Kerberos server.
(2) All servers are registered and their shared symmetric secret keys are kept both at the
Kerberos server and at themselves.
 (3) For supporting inter-realm authentication, the servers lying in different realm are
registered with each other and hence share symmetric keys i.e., they both trust each other
for authenticating users lying in each other’s realm.

The process when a user in one realm tries to access services in other realm is shown in Figure 9.
The entire process is divided into 4 steps:

1. User in realm A contact AS server for authentication who in turn issues ticket-granting
ticket for local TGS server (message 1 & 2).
2. User contacts local TGS server and gets ticket-granting ticket for remote TGS server
(message 3 & 4).
3. User contacts remote TGS server who in turn issues service-granting ticket for remote real
server (message 5 & 6).
4. User requests remote server using service-granting ticket issued by remote TGS server
(message 7).

Kerberos Realm A Client

(1)
AS
(2)

TGS (3)
(4)

(7)

Kerberos (6)
(5)
AS

TGS

Realm B Server

(1) Client requests local TGS ticket from Authentication server of Realm A
(2) Authentication server provides local TGS ticket to client
(3) Client requests remote TGS ticket from local TGS server of Realm A
(4) Local TGS server provides remote TGS ticket
(5) Client requests service granting ticket for remote server from TGS server of
Realm B
(6) TGS server of Realm B provides service granting ticket for remote server
(7) Client requests remote service using service granting ticket

Fig 9 Full service Kerberos environment for inter-realm authentication

Till now Kerberos version 4 is considered, the following subsection highlights features of version
5. Some of the major shortcomings in version 4 are:

(i) Version 4 makes DES as compulsory element whereas version 5 facilitates use of any
encryption method.
(ii) IPv4 addresses are used in version 4 other address types are not supported. In version 5,
this constraint is lifted and hence, any network addresses type can be used.
(iii) In version 4, byte ordering method (little endian or big endian) is left to the choice of
sender. In version 5, unambiguous byte ordering method like Abstract Syntax Notation
One (ASN.1) and Basic Encoding Rules (BER) is used.
(iv) Version 4 has 8 bit lifetime field in unit of 5 minutes which means maximum lifetime can
be around 28×5=1280 minutes (>21 hours). In version 5, variable lifetime is possible by
explicit inclusion of start time and end time.
(v) Forwarding of credentials of one client to other clients is not done in version 4 whereas it
is done in version 5.
(vi) In version 4, for maintaining interoperability among N realms, N2 key exchanges are
required where as it is less in version 5.
(vii) Tickets conveyed to users are encrypted twice, first time with secret key of other verifying
server and second with user’s secret key. This waste computation time.

(1) Jai → AS Options║IDJai║RealmJai║IDtgs║Times║Nonce1

(2) AS→Jai RealmJai║IDJai║Tickettgs║𝐸𝐾 𝐽𝑎𝑖 (KJai,tgs║Times║Nonce1║Realmtgs║IDtgs)
Tickettgs = (Flags║KJai,tgs║RealmJai║IDJai║ADJai║Times)

(a) Authentication Server message interactions for ticket-granting ticket

(3) Jai → TGS Options║IDVeeru║Times║Nonce2║Tickettgs║AuthenticatorJai

(4) TGS→Jai RealmJai║IDJai║TicketVeeru║ (KJai,Veeru║Times║Nonce2
║RealmVeeru║IDVeeru)
Tickettgs = (Flags║KJai,tgs║RealmJai║IDJai║ADJai║Times)
Ticketv = (Flags║KJai,Veeru║RealmJai║IDJai║ADJai║Times)
AuthenticatorJai = (IDJai║RealmJai║TS1)

(b) Ticket-Granting Server message interactions for service-granting ticket

(5) Jai → Veeru Options║Ticketv║AuthenticatorJai

(6) Veeru→Jai
Ticketv = (Flags║KJai,Veeru║RealmJai║IDJai║ADJai║Times)
AuthenticatorJai = (IDJai║RealmJai║TS2║Subkey║Seqno)

(c) Client/Server Authentication message interactions regarding service

Fig 10 Kerberos Version 5

Kerberos authentication (Version 5)

(1) Message (1) (Figure 10) is used by user to request AS for ticket granting ticket. Some new
elements are added in the message (1) in Kerberos version 5, these are:
(i) Realm for indicating the user’s realm.
(ii) A method for setting flags (options) in the returned ticket.
(iii) Times- It is combination of following three and is used by client in the request so
that ticket issued contains them.
(a) from – start time (ticket)
(b) till - expiration time (ticket)
(c) rtime – renew time (ticket)
(iv) Nonce – A random value, kept in message for countering replay attacks and
indicating that the message is fresh.
(2) The AS ‘reply’ after authenticating user is send as message (2). Message (2) contains
some unencrypted information, some encrypted information and a ticket. The ticket in
version 5 is encrypted only once and it contains additional information as compared with
version 4 i.e., Flags, realm and times. Flags depend upon status of ticket and request
options set by user.
(3) Message (3) is similar to that of version 4 (Message (3)), in addition it has- options, nonce
and times field, with each having same functionality as message (1) above.
(4) Message (4) is same as message (2) with exception that key used for encrypting user
information is session key i.e., KJai-TGS.
(5) The addition in message (5) (version 5) are
(i) Option whether mutual authentication is required or not. If required, message (6)
is returned.
(ii) Sub key in authenticator for indicating choice of encryption key.
(iii) Sequence numbers put by server to protect against replays.
(6) In message (6) unlike version 4, incrementing of time stamp is not done rather sub key &
sequence numbers are used. As attacker does not know the encryption key, he cannot forge
message (6).

Detailing of few flags used in version 5

(i) In version 5, AS can directly issue the service-granting ticket. Hence, flag INITIAL is
used to indicate the fact that the ticket was issued by AS not by TGS using ticket-granting
ticket.
(ii) PRE-AUTHENT flag implies authentication of client by Kerberos server before issuing
ticket e.g., encrypted timestamp based pre authentication.
(iii) HW-AUTHENT flag require hardware processing by user e.g., continually changing
password method used for pre authentication by client for smart card based system.
(iv) RENEWABLE flag in a ticket means that this ticket can be renewed with a new session
time and expiration time.
(v) A user may have tickets marked as POSTDATED and INVALID. He may request the
validation of such tickets by setting the flag MAY-POSTDATE. This method is useful for
tasks that needs server for longer times and hence requires tickets periodically.
(vi) A server can act as proxy for client provided PROXIABLE flag is set by client in request.
Under this mechanism the tickets issued by TGS contains different network address and
PROXY flag set.
In same lines as in (vi) proxy method, FORWARDABLE flag can be set by client in request
such that ticket issued contains different network address and FORWARDED flag set. Thus, a
user may present such tickets directly to a remote TGS server without requiring key sharing
between different TGS servers lying in different realm.