Session 20

Network Security

P C Gupta

1
 Contents

 Kerberos
• Centralized authentication service
• Kerberos
• Kerberos realms

P C Gupta 2
 Centralized Authentication Service

A1 AS C : Client
A : Application server
C A2 C A1
AS: Authentication server
A3 A2
A3

• Authentication using password has limitations, when

there are several application servers & number of users.
a) Each server maintains passwords of all the users.
b) Any change in password would require changing the
password in every server.
• Centralized authentication service is advantageous.
a) It is available to the users for all the application servers.
b) Application servers are relieved of authentication function.
c) Users need to update their password once in the
authentication server.

P C Gupta 3
 Centralized Authentication Service

Basic Scheme User AS A1

AS (a)
C A1 (b)
C : Client
(c)
A : Application server
A2
AS : Authentication server A3
(d) Verifies ticket &
grants access

a) Client sends request to authentication server (AS) for

access to application server (say A1).
 He produces his authentication data (e.g. password).
b) AS verifies the client and gives him a ‘ticket’ for the
application server A1.
c) Client sends ‘ticket’ to the application server A1.
d) Application server A1 verifies the ‘ticket’ and grants
access to the client.

P C Gupta 4
 Centralized Authentication Service

• Basic scheme has one limitation: AS

C A1
Every instance of access to an application
server requires re-authentication and A3
A2
a new ‘ticket’ from AS.
• Therefore a user may require re-authentication and a
new ticket several times in a day. E.g.
a) On every instance of accessing the mail server.
b) On every instance of availing different application service
e.g. print server.
• These issues are addressed by
a) making a ticket reusable within its lifetime (say 8 hours).
b) separating ‘authentication’ and ‘ticketing’ functions by
introducing an additional server ‘ticket-granting server’
(TGS).

P C Gupta 5
 Centralized Authentication Service

AS C : Client
A : Application server
C TGS AS : Authentication server
TGS : Ticket-granting server
A1
A2

a) Client sends request to authentication server (AS) for

access to a TGS. Client sends its authentication data.
b) AS authenticates the client and gives a reusable ‘ticket-
granting ticket’* for the TGS.
c) Client sends the ‘ticket-granting ticket’ to TGS for access
to an application server.
d) TGS verifies ‘ticket-granting ticket’ and issues a reusable
‘service ticket’* for the desired application server.
e) Client sends the ‘service ticket’ to the application server.

* Both the tickets have defined lifetime to avoid misuse.

P C Gupta 6
 Kerberos
Application server (A) AS : Authentication server
Client TGS: Ticket granting server
User KDC AS KDC
TGS

• Kerberos* is an authentication protocol for availing

application services. It combines centralized
a) Authentication service &
b) Session key-distribution service of KDC.
• Key Distribution Centre (KDC) that implements
Kerberos has
– Authentication server (AS)
– Ticket Granting Server (TGS)
– Data base containing user credential/authorization
information.
* Kerberos is the name of a three headed watch dog in Greek mythology.
P C Gupta 7
 Kerberos

KDC Client
User 1 AS KDC
Client 2
3 TGS
4 AS : Authentication server
User Application
5 A TGS: Ticket granting server
server (A) 6 A : Application server

1. User inputs his registered identity.

Client  AS Request for access to TGS.
 IdC  IdTGS TSC

IdC : User Id
IdTGS : TGS Id
TSC : Time stamp. It is used by the client to match its requests and
responses from AS.

P C Gupta 8
 Kerberos
Client
User 1 AS KDC
2 AS : Authentication server
3 TGS TGS: Ticket granting server
4 A : Application server
5 A
6

2. AS verifies user’s authorization.

AS  Client Encrypted session key KC-TGS & ‘ticket’ ( )
for the TGS.
 E(KC, {KC-TGS  IdTGS TSC LT, })
 contains
E(KAS-TGS, {KC-TGS IdC IdTGS IPC TST LT})

LT : Life time of ticket IPC : IP address of the client

KC-TGS : Session key KAS-TGS : Key between AS & TGS
TST : Time stamp when ticket is generated
KC : Client-key derived from registered password of the user

P C Gupta 9
 Kerberos
Client
User 1 AS KDC
2
3 TGS
4 AS : Authentication server
5 A TGS: Ticket granting server
6
A : Application server

3. Client asks user for password to derive KC. It verifies TSC &
retrieves key session key KC-TGS.
Client  TGS Service request for accessing server A.
 IdA   Authenticator1
 Authenticator1 consists of
E(KC-TGS, {IdC, IPC, TSC})

TSC (Client’s time stamp) allows the client to match its

request to response from TGS.

P C Gupta 10
 Kerberos

Client
User 1 AS KDC
2
3
4 TGS AS : Authentication server
5 A TGS: Ticket granting server
6 A : Application server

4. TGS decrypts the ticket ( ) using KAS-TGS & retrieves

session key KC-TGS. It verifies user’s authenticator and user’s
authorization from the database.
TGS  Client Encrypted service ticket ( ) & session
key KC-A for application server A.
 E(KC-TGS, {IDA KC-A TSC  })
 contains
E(KA, {KC-A IdC IdA IPC TST LT})

P C Gupta 11
 Kerberos

KDC Client
User 1 AS KDC
Client 2
3 TGS
4 AS : Authentication server
User Application
5 A TGS: Ticket granting server
server (A) 6 A : Application server

5. Client verifies TSC, & forwards ticket to the application

server A with Authenticator2.
Client  A Encrypted service ticket, Authenticator2.
 Authenticator2 

 Authenticator2 contains
E(KC-A, {IdC, IPC, TSC})

TSC (Client’s time stamp) allows the client to authenticate

response from application server A

P C Gupta 12
 Kerberos
KDC Client
User 1 AS KDC
Client 2
3 TGS
4 AS : Authentication server
User Application
5 A TGS: Ticket granting server
server (A) 6 A : Application server
6. Application server (A)
– opens ( ) using key KA & extracts session key KC-A.
– uses KC-A to decrypt & verify Authenticator2.
– verifies time stamp TSC to ensure that it is not a replay.
A  Client A’s authenticator for the client.
 E(KC-A, {TSC+1})

By returning TSC+1, server A confirms its credentials to the

client.

P C Gupta 13
 Attack Vulnerabilities

1. Client  AS IdC  IdTGS TSC

 Can attacker pose as the user and generate this message?
2. AS  Client E(KC, {KC-TGS  IdTGS TSC LT, })
E(KAS-TGS, {KC-TGS IdC IdTGS IPC TST LT})
 Can attacker pose as AS and respond to the client?
 Can attacker capture this response and use it?
3. Client  TGS IdA   Authenticator1
Authenticator1 : E(KC-TGS, {IdC, IPC, TSC})
 Can attacker generate authenticator or replay this
message?
4. TGS  Client E(KC-TGS, {IDA KC-A TSC  })
E(KA, {KC-A IdC IdA IPC TST LT})
 Can attacker pose as TGS and generate this response?

P C Gupta 14
 Attack Vulnerabilities
5. Client  A Authenticator2 
Authenticator2 : E(KC-A, {IdC, IPC, TSC})
E(KA, {KC-A IdC IdA IPC TST LT})
 Can attacker pose as client & generate this request?
6. A  Client E(KC-A, {TSC+1})
 Can attacker pose as application server and generate this
reply?

P C Gupta 15
 Kerberos Realms

• The term ‘Realm’ refers to administrative domain of a

Kerberos implementation.
– Each user and each application server of a realm share a
secret (password/key) with the KDC of that realm.
• There can be multiple realms. A user of Realm A may
want to access resources in Realm B.
• Kerberos supports inter-realm authentication service.
– This is achieved by inter-realm registration of the
Kerberos servers.

Realm A User Realm B

AS AS
Client

TGS TGS

P C Gupta 16
 Kerberos Realms

Realm A User Realm B

AS 1 AS

Client
2
3 5 TGS
TGS 4 6
7 P
8

1. Request for ticket to TGS.

2. TGS ticket, session key.
3. Request for ticket for the remote TGS, authenticator.
4. Remote TGS ticket, session key.
5. Request for service ticket for server P, authenticator.
6. Service ticket, session key.
7. Service ticket, authenticator.
8. Authenticator.

P C Gupta 17