Client Server Mutual Authentication Application - Kerberos

1. KERBEROS – CLIENT SERVER
MUTUAL AUTHENTICATION
APPLICATION
1
~ S. Janani, AP/CSE, KCET

2. Authentication Applications
2
 will consider authentication functions
 developed to support application-level
authentication & digital signatures
 will consider Kerberos – a private-key
authentication service
 then X.509 directory authentication service

3. Kerberos
3
 trusted key server system from MIT
 provides centralised private-key third-party
authentication in a distributed network
 allows users access to services distributed
through out the network
 without needing to trust all workstations
 rather all trust a central authentication server
 two versions in use: 4 & 5

4. Kerberos Requirements
4
 first published report identified its requirements
as:
 security
 reliability
 transparency
 scalability
 implemented using an authentication protocol
based on Needham-Schroeder

5. Kerberos 4 Overview
5
 a basic third-party authentication scheme
 have an Authentication Server (AS)
 users initially negotiate with AS to identify
themselves
 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

6. A Simple Authentication
Dialogue
6
 (1) C -> AS : IDC || PC || IDV
 C = client
 AS = authentication server
 IDC = identifier of user on C
 PC = password of user on C
 IDV = identifier of server V
 C asks user for the password
 AS checks that user supplied the right password

7. Message 2
7
 (2) AS -> C : Ticket
 Ticket = E K(V) [IDC || ADC || IDV]
 K(V) = secret encryption key shared by AS and V
 ADC = network address of C
 Ticket cannot be altered by C or an adversary

8. Message 3
8
 (3) C -> V: IDC || Ticket
 Server V decrypts the ticket and checks various
fields
 ADC in the ticket binds the ticket to the network
address of C
 However this authentication scheme has
problems

9. Problems
9
 Each time a user needs to access a different
service he/she needs to enter their password
 Read email several times
 Print, mail, or file server
 Assume that each ticket can be used only once
(otherwise open to replay attacks)
 Password sent in the clear

10. Authentication Dialogue II
10
 Once per user logon session
 (1) C -> AS: IDC || IDTGS
 (2) AS -> C: E K(C) [TicketTGS]
 TicketTGS is equal to
 E K(TGS) [IDC || ADC || IDTGS
|| TS1 || Lifetime1 ]

11. Explaining the fields
11
 TGS = Ticket-granting server
 IDTGS = Identifier of the TGS
 TicketTGS = Ticket-granting ticket or TGT
 TS1 = timestamp
 Lifetime1 = lifetime for the TGT
 K (C) = key derived from user’s password

12. Messages (3) and (4)
12
 Once per type of service
 (3) C -> TGS: IDC || IDV || TicketTGS
 (4) TGS -> C : TicketV
 TicketV is equal to
 E K(V) [ IDC || ADC || IDV ||
TS2 || Lifetime2 ]
K(V): key shared between V and TGS
Is called the service-granting ticket (SGT)

13. Message 5
13
 Once per service session
 (5) C -> V: IDC || TicketV
 C says to V “I am IDC and have a ticket from
the TGS” . Let me in!
 Seems secure, but..
 There are problems

14. Problems
14
 Lifetime of the TGT
 Short : user is repeatedly asked for their
password
 Long : open to replay attack
 Oscar captures TGT and waits for the user to
logoff
 Sends message (3) with network address IDC
(network address is easy to forge)
 Same problem with SGT

15. What should we do?
15
 A network service (TGS or server) should be able
to verify that
 person using the ticket is the same as the person that the
ticket was issued to
 Remedy : use an authenticator
 Server should also authenticate to user
 Otherwise can setup a “fake” server
 A “fake” tuition payment server and capture the student’s
credit card
 Remedy : use a challenge-response protocol

16. Kerberos Version 4
 Uses DES, in a rather elaborate protocol, to
provide authentication
 Uses an Authentication Server (AS)
 Knows all user passwords, and stores in a DB
 Shares a unique secret key with each server
 Send an encrypted ticket granting ticket
 TGT contains a lifetime and timestamp

17. Kerberos Version 4
 Uses a Ticket Granting Server (TGS)
 Issues tickets to users authenticated by AS
 Encrypted with a key only known by AS and TGS
 Returns a service granting ticket
 Service granting ticket contains timestamp and
lifetime

18. 18

20. Kerberos Realms
20
 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

21. Kerberos Version 5
21
 developed in mid 1990’s
 provides improvements over v4
 addresses environmental shortcomings
 encryption algorithm, network protocol, byte order,
ticket lifetime, authentication forwarding, inter-realm
authentication
 and technical deficiencies
 double encryption, non-standard mode of use, session
keys, password attacks
 specified as Internet standard RFC 1510