Kerberos

1. KERBEROS

2. KERBEROS
 Authentication service designed for use in a
distributed environment.
 Developed as part of project Athena at MIT.

3. ATTACKS ON OPEN DISTRIBUTED
ENVIRONMENT
 Impersonation
 Altering of address of workstation
 Entrance into the network

4. FUNDAMENTAL REQUIREMENT IN AN
AUTHENTICATION SERVICE
 Secure
 Reliable
 Transparent
 Scalable

5. TWO VERSIONS OF KERBEROS
 Kerberos v4 (developed in 1988) is still in common use
 Kerberos v5 (1994) corrects some security deficiencies of
version 4 and has been issued a draft internet standard
(RFC 1510)

6. KERBEROS 4
 It uses DES
 An authentication server (AS) is used which
stores the passwords of all users and also shares
a unique secret key with each user.

7. SIMPLE AUTHENTICATION DIALOGUE
1. C → AS: IDC|| PC || IDV
2. AS→ C: Ticket
3. C→V : IDC || Ticket
Ticket = E(Kv,[IDC|| ADC || IDV])
C = Client
AS = authentication server
V = server
IDC = identifier of user on C
IDV = identifier of V
PC = password of user on C
ADC = network address of C
KV= secret encryption key shared by AS and V

8. DRAWBACKS
 Users password is unprotected.
 User has to login every time he request for
service.
These can be removed by using a more secure
scheme. It uses a new server TGS.

9. TICKET GRANTING SERVER
 Issues ticket to users authenticated to AS.
 Ticket granting ticket is issued by AS.
 Each time the user require access to a new
service, the client applies to the TGS, using the
ticket.
 Then TGS grants a ticket for a particular service.

10. A MORE SECURE AUTHENTICATION DIALOGUE
Once per service session:
(1) C → AS: IDC || IDtgs
(2) AS→ C:E(KC,[Tickettgs])
Once per type of service:
(3) C→TGS: IDC || ID´V || Tickettgs
(4) TGS→C: TicketV
Once per service session:
(5) C→V: TicketV || ID´C
Tickettgs = E(Ktgs ,[IDC|| ADC || IDtgs || TS1 ||
Lifetime1 ])
TicketV = E(Kv, [IDC|| ADC || IDV || TS2 ||
Lifetime2 ])

11. THE VERSION 4 AUTHENTICATION
DIALOGUE:
 Two additional problems remain in the second scenario:
1. Lifetime associated with the ticket-granting ticket:
Short Lifetime: User is repeatedly asked for password
Long Lifetime: Greater opportunity for replay
2. Requirement for servers to authenticate themselves to
users

12. ELEMENTS OF KERBEROS VERSION 4
PROTOCOL

13. 1. Authentication Service Exchange: to obtain ticket-
granting ticket
2. Ticket-Granting Service Exchange: to obtain service-
granting ticket
3. Client/Server Authentication Exchange: to obtain
service

14. AUTHENTICATION SERVICE EXCHANGE
1. C → AS IDc||IDtgs||TS1
Client requests ticket-granting ticket
2. AS → C E(Kc,[Kc,tgs||IDtgs||TS2||Lifetime2||Tickettgs])
Ticket tgs=E(Ktgs, [Kc,tgs||IDc||ADc||IDtgs||TS2||Lifetime2])
AS returns ticket-granting ticket

15. TICKET-GRANTING SERVICE EXCHANGE
3. C → TGS IDv||Tickettgs||Authenticatorc
Authenticatorc=E(Kc,tgs,[IDc||ADc||TS3])
Client requests service-granting ticket
4. TGS → C E(Kc,tgs, [Kc,v||IDv||TS4||Ticketv])
Ticketv= E(Kv,[Kc,v||IDc||ADc||IDv||TS4||Lifetime4])
TGS returns service-granting ticket

16. CLIENT/SERVER AUTHENTICATION
EXCHANGE
5. C → V Ticketv||Authenticatorc
Ticketv=E(Kv,[Kc,v||IDc||ADc||IDv||TS4||Lifetime4])
Authenticatorc=E(Kc,v,[IDc||ADc||TS5])
Client requests service
6. V → C E(Kc,v,[TS5+1])
Optional authentication of server to client

17. KERBEROS REALMS
 Requirements of a full-service Kerberos environment:
All users registered with the Kerberos server
All servers registered with the Kerberos server
The two Kerberos servers registered with each other (to support
interrealm authentication)

18. REQUEST FOR SERVICE IN ANOTHER REALM

19. 1. Request ticket for local TGS
C → AS IDc||IDtgs||TS1
2. Ticket for local TGS
AS → C E(Kc,[Kc,tgs||IDtgs||TS2||Lifetime2||Tickettgs])
3. Request ticket for remote TGS
C → TGS IDtgsrem||Tickettgs||Authenticatorc
4. Ticket for remote TGS
TGS → C E(Kc,tgs,[Kc,tgsrem||IDtgsrem||TS4||Tickettgsrem])

20. 5. Request ticket for remote server
C → TGSrem IDvrem||Tickettgsrem||Authenticatorc
6. Ticket for remote server
TGSrem → C E(Kc,tgsrem,[Kc,vrem||IDvrem||TS6||Ticketvrem])
7. Request remote service
C → Vrem Ticketvrem||Authenticatorc
 However, this approach does not scale well to many realms. For N realms,
there must be N(N-1)/2 secure key exchanges between realms

21. KERBEROS V5
 General purpose authentication service
 Specified in RFC-4120
 Overcome the shortcomings of v4

22. SHORTCOMING OF V4
 Environmental Shortcomings
-Related to the architecture of network
 Technical Shortcomings :
- Deficiencies in the v4 itself

23. KERBEROS V4 ENVIRONMENTAL
SHORTCOMINGS
 Encryption System Dependence
 Internet Protocol Dependence
 Message by ordering
 Ticket Lifetime
 Authentication Forwarding
 Inter-realm Authentication

24. KERBEROS V4 TECHNICAL
SHORTCOMINGS
 Double Encryption
 Propagation Cipher Block Chaining Encryption
 Session Keys
 Password Attacks

25. KERBEROS V5 EXCHANGES

26. KERBEROS V5 FLAGS

27. CONCLUSION
 Version 5 of Kerberos is a step toward the design
of an authentication system that is widely
applicable.
 We believe the framework is flexible enough to
accommodate future requirements like
1. Smart Cards
2. Remote Administration