1. The Authentication Service ‘Kerberos’ and It’s Limitations

2. OUTLINE What is Kerberos ? How does it work ?
Kerberos infrastructure and Cross-realm Authentication
Kerberos Encryption
Attacks on Kerberos ?
Limitations of Kerberos
Future Work

3. 1. What Is Kerberos ? Definition :
In Greek mythology, Kerberos was “ a three headed
dog that guards the entrance to Hades.
An authentication service developed as part of Project
Athena at MIT to enable network applications to
securely identify their peers.
It was intended to have three components to guard a
network’s gate: authentication, accounting, and audit.
The last two were never implemented.
Versions 1 through 3 were internal development
versions. Version 4 is the original Kerberos.
Motivation :
In an open environment, in which network connections

4. to other machines are supported, there is a need to
protect user information and resources stored at the
server. To do this :
Require the user to prove identity for each service
invoked. Also require that servers prove their identity
to clients.
These are supported by Kerberos.
It should be :
Secure: opponent does not find it to be the weak link
Reliable: it should employ a distributed server architecture,
with one system able to back up another.
Transparent : user should not be aware that authentication
is taking place.
Scalable : supporting large numbers of clients and servers.

5. (2) (1) (4) (3) (5) (6) Kerberos Authentication Server
Ticket - granting
Server (TGS)
Request ticket-granting ticket
Ticket + session key
Request Service
Provide server authenticator
Request service-granting ticket
Ticket+session key
Once per user logon session
Once per type of service
Once per service session
(1)
(4)
(3)
(5)
(6)

6. 1. User logs on to workstation and request service on host.
2. AS verifies user’s access rights in database, creates TGT
and session key. Results are encrypted using key derived
from user’s password.
3. Workstation prompts user for password and uses pass-
word to decrypt incoming message, then sends ticket and
authenticator that contains user’s name, network address,
and time to TGS.
4. TGS decrypts ticket and authenticator, verifies request,
then creates ticket for requested server.
5. Workstation sends ticket and authenticator to server.
6. Server verifies that ticket and authenticator match, then
grants access to service. If mutual authentication is
required, server returns an authenticator.

7. How does it work ? 1. C -----> AS : IDC , PC , IDV
AS----> C : Ticket
C------> IDC, Ticket
Ticket = EKv [ IDC , ADC , IDV ]
Where
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 encrytion key shared by AS and V

8. A more secure Authentication
The first scenario does not solve the followings:
1. The number of times that a user has to enter a password.
2. It involved a plaintext transmission of the password (mess1)
To solve these problems, we introduce ticket-granting server.
The new scenario:
Once per user logon session :
1. C -----> AS : IDC , IDtgs
2. AS----> C : Ekc[ Tickettgs]
Once per type of service:
3. C------> TGS : IDC , IDV , Tickettgs
4. TGS--> C : TicketV

9. Once per service session :
5. C------>V : IDC , TicketV
Tickettgs = EKtgs[IDC , ADC , IDtgs
, TS1, Lifetime1]
TicketV = EKv[ IDC , ADC , IDV , TS2 , Lifetime2]
TS = Timestamp
This new scenario satisfies the two requirements of only one
password query per user session and protection of the user
password.
We still have two additional problems :
1. The lifetime associated with the ticket-granting ticket.
If it is short (e.g., minutes), the user will be repeatedly

10. asked for a password. If it is long, then an opponent has a
greater opportunity for replay.
2. There might be a need for server to authenticate itself to
users.
Solution : Session Keys
The threat : Opponent will steal the ticket and use it before it
expires.
The solution : AS provide both the C and TGS with a secret
piece of information in a secure manner. Then,
C can prove its ID to the TGS by revealing the
secret. An encryption key ise used as the secure
info., this is referred to as a session key.
So the actual Kerberos protocol :

11. Summary of Kerberos Version 4 Message Exchanges
a) Authentication Service Exchange : to obtain TGT
1. C > AS : IDC , IDtgs ,TS1
2. AS-----> C : EKc[ KC,tgs, IDtgs,TS2, Lifetime2, Tickettgs]
Tickettgs = EKtgs[ KC,tgs, IDC, ADC, IDtgs,TS2, Lifetime2]
b) Ticket-Granting Service Exchange : to obtain service-
granting ticket
3. C > TGS : IDV , Tickettgs ,AuthenticatorC
4. TGS---> C : EKc[ KC,V, IDV,TS4, TicketV]
TicketV = EKv[ KC,V, IDC, ADC, IDV,TS4, Lifetime4]

12. AuthenticatorC = EKc,tgs[IDC, ADC, TS3]
c) Client/Server Authentication Exchange : to obtain service
5. C------> TGS : TicketV, AuthenticatorC
6. K------> C : EKc,v [ TS5 +1] (for mutual authentication)
TicketV = EKv[ KC,V, IDC, ADC, IDV,TS4, Lifetime4]
AuthenticatorC = EKc,v[IDC, ADC, TS5]

13. Kerberos Realms
A full-service Kerberos environment consisting of a Kerberos
server, a number of clients, and a number of application
servers, requires the following :
1. The Kerberos server must have the UID and hashed pass-
word of all participating users in its database. All users are
registered with the Kerberos server.
2. The Kerberos server must share a secret key with each
server. All servers are registered with the Kerberos server.
For inter-realm authentication;
3. The Kerberos server in each interoperating realm shares a
secret key with the server in the other realm. The two
Kerberos servers are registered with each other.
This means that the Kerberos server in one realm trust the
Kerberos server in the other realm to authenticate its users

14. AS
TGS
Kerberos
Client
Server 1 2 3 4 5 6 7
1. Request ticket for local
2. Ticket for local TGS
3. Request ticket for
remote TGS
4. Ticket for remote TGS
5. Request ticket for
remote server
6. Ticket for remote server
7. Request remote service
Realm A
Realm B

15. Encryption for Privacy and Integrity
The data structures that Kerberos encrypts need to be
protected from both disclosure and modification.
Kerberos uses DES algorithm for encryption. For a long
message CBC (Cipher Block Chaining) could be used and
it does a good job on privacy.
Problem :However, there is no integrity
check. If an intruder were to modify block cn,then mn and mn+1
would be garbage. No way for kerberos to detect this.
Solution: Plaintext Cipher Block Chaining (PCBC).
It has the property that modifying any ci will result in garbling
plaintext blocks starting with mi all the way to the end. There
is a recognizable data at the end of a message so that it will
decrypt to see whether the final block is proper.
Question: What if we swap two adjacent blocks of ciphertext?

16. Plaintext Cipher Block ChainingIV m1 c1 E m2 c2 m3 c3 m4 c4
Encrypt
with
secret key

17. Attacks on Kerberos 1. Replay Attacks 2. Secure Time Services
3. Password-Guessing Attacks
4. Spoofing Login
5. Inter-Session Chosen Plaintext attacks
6. Exposure of Session Keys
7. The Scope of Tickets

18. Limitations of Version 4
Environmental Shortcomings :
1. Encryption system dependence (it uses only DES)
2. Internet protocol dependence (requires the use of IP addr.
3. Message byte ordering
4. Ticket Lifetimes (a maximum lifetime of 211/4 hours).
5. Authentication Forwarding ( an intermediate server may
need to accsess some resource with the rights of the client
for example a print server)
6. Principal naming. ( principals are named with three compo-
nents: name, instance, and realm, each of which may be up
to 39 charactres long which are too short for some applicati-
ons and installation environments
7. Inter-realm authentication. (The pairwise key exchange
requires a lot of key exchanges for n realms).

19. Technical Deficiencies :
1. Double Encryption: The ticket is encrypted twice when
transmitted to the client, and only once when sent to the
application server. If encryption is computationally intensive
this is unneccesary use of processing time.
2. PCBC encryption:This mode was an attempt to provide data
encryption and integrity protection in one operation. But, an
intruder can modify a message with a special block-
exchange attack which may not be detected by the receiver.
3. Authenticators and replay detection
4. Password attacks
5. Session keys
6. Cryptographic checksum : The MIT implementation does
not perform this algorithm as described; the suitability of the
modified version as a CCF is unknown.

20. Future Work Version 5 of Kerberos is a step toward the design of an
authentication system that is widely applicable.The framework
is flexible enough to accommodate future requirements.Some
items expected to add to Kerberos in the near future include:
1.Public-key cryptosystems: It will give the ability to interope-
rate with the Privacy Enhanced Mail (PEM) infrastructure.
2.Smartcards: Hand-held devices can be used to augment
normal password security methods.
3.Remote administration : Remote extraction of server key
tables, password “quality checks”, and a provision for
servers to change their secret keys automatically often.
4.Validation suites: To verify that the protocol is properly imp-
lemented. It could prevent future problems.
5. Applications : , Usenet, distributed file systems.