Presentation of Kerberos as per ECE scheme

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: ID
C|| P
C|| ID
V
2.AS→C: Ticket
3.C→V : ID
C || Ticket
Ticket = E(Kv,[ID
C
|| AD
C|| ID
V])
C = Client
AS = authentication server
V = server
ID
C= identifier of user on C
ID
V= identifier of V
P
C= password of user on C
AD
C= network address of C
K
V= 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: ID
C || ID
tgs
(2) AS→C:E(K
C,[Ticket
tgs])
Once per type of service:
(3) C→TGS: ID
C || ID
´V || Ticket
tgs
(4) TGS→C: Ticket
V
Once per service session:
(5) C→V:Ticket
V || ID
´C
Ticket
tgs= E(Ktgs,[ID
C|| AD
C|| ID
tgs || TS
1 ||
Lifetime
1])
Ticket
V= E(Kv, [ID
C|| AD
C|| ID
V || TS
2 ||
Lifetime
2])

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 ID
c||ID
tgs||TS
1
Client requests ticket-granting ticket
2. AS → C E(K
c,[K
c,tgs||ID
tgs||TS
2||Lifetime
2||Ticket
tgs])
Ticket
tgs=E(K
tgs, [K
c,tgs||ID
c||AD
c||ID
tgs||TS
2||Lifetime
2])
AS returns ticket-granting ticket

15. TICKET-GRANTING SERVICE EXCHANGE
3. C → TGS ID
v||Ticket
tgs||Authenticator
c
Authenticator
c=E(K
c,tgs,[ID
c||AD
c||TS
3])
Client requests service-granting ticket
4. TGS → C E(K
c,tgs, [K
c,v||ID
v||TS
4||Ticket
v])
Ticket
v= E(K
v,[K
c,v||ID
c||AD
c||ID
v||TS
4||Lifetime
4])
TGS returns service-granting ticket

16. CLIENT/SERVER AUTHENTICATION
EXCHANGE
5. C → V Ticket
v||Authenticator
c
Ticket
v=E(K
v,[K
c,v||ID
c||AD
c||ID
v||TS
4||Lifetime
4])
Authenticator
c=E(K
c,v,[ID
c||AD
c||TS
5])
Client requests service
6. V → C E(K
c,v,[TS
5+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 ID
c||ID
tgs||TS
1
2.Ticket for local TGS
AS → C E(K
c,[K
c,tgs||ID
tgs||TS
2||Lifetime
2||Ticket
tgs])
3.Request ticket for remote TGS
C → TGS ID
tgsrem||Ticket
tgs||Authenticator
c
4.Ticket for remote TGS
TGS → C E(K
c,tgs,[K
c,tgsrem||ID
tgsrem||TS
4||Ticket
tgsrem])

20. 5.Request ticket for remote server
C → TGS
rem ID
vrem||Ticket
tgsrem||Authenticator
c
6.Ticket for remote server
TGS
rem → C E(K
c,tgsrem,[K
c,vrem||ID
vrem||TS
6||Ticket
vrem])
7.Request remote service
C → V
rem Ticket
vrem||Authenticator
c
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