The Authentication Service Kerberos and Its Limitations OUTLINE

The Authentication Service ‘Kerberos’ and It’s Limitations

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

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

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.

(2) Once per user logon session Kerberos g ticket n i t n a r g icket tt (1) Reques Authentication Server n key o i s s e s icket + T Request service-granting ticket Ticket+session key (3) Req Prov id uest e se Once per service session (5) rver Serv (4) Once per type of service auth Ticket - granting Server (TGS) entic ator (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 password 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.

How does it work ? 1. 2. 3. C -----> AS : IDC , PC , IDV AS----> C : Ticket C------> IDC, 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 K = Secret encrytion key shared by AS and V

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 (mess 1) 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 : Ticket. V

Once per service session : 5. C------>V : IDC , Ticket. V Tickettgs = EKtgs[IDC , ADC , IDtgs , TS 1, Lifetime 1] Ticket. V = EKv[ IDC , ADC , IDV , TS 2 , Lifetime 2] 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

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 :

Summary of Kerberos Version 4 Message Exchanges -----------------------------------------a) Authentication Service Exchange : to obtain TGT -----------------------------------------1. C-------> AS : IDC , IDtgs , TS 1 2. AS-----> C : EKc[ KC, tgs, IDtgs, TS 2, Lifetime 2, Tickettgs] Tickettgs = EKtgs[ KC, tgs, IDC, ADC, IDtgs, TS 2, Lifetime 2] -----------------------------------------b) Ticket-Granting Service Exchange : to obtain servicegranting ticket -----------------------------------------3. C-------> TGS : IDV , Tickettgs , Authenticator. C 4. TGS---> C : EKc[ KC, V, IDV, TS 4, Ticket. V] Tickettgs = EKtgs[ KC, tgs, IDC, ADC, IDtgs, TS 2, Lifetime 2] Ticket. V = EKv[ KC, V, IDC, ADC, IDV, TS 4, Lifetime 4]

Authenticator. C = EKc, tgs[IDC, ADC, TS 3] -----------------------------------------c) Client/Server Authentication Exchange : to obtain service -----------------------------------------5. C------> TGS : Ticket. V, Authenticator. C 6. K------> C : EKc, v [ TS 5 +1] (for mutual authentication) Ticket. V = EKv[ KC, V, IDC, ADC, IDV, TS 4, Lifetime 4] Authenticator. C = EKc, v[IDC, ADC, TS 5] ------------------------------------------

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 password 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

Kerberos Client 1 3 2 4 AS TGS Realm A 7 5 6 Kerberos AS Server TGS Realm B 1. Request ticket for local TGS 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

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?

Plaintext Cipher Block Chaining m 1 m 2 m 3 m 4 E E c 1 c 2 c 3 c 4 IV Encrypt with secret key

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

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 components: name, instance, and realm, each of which may be up to 39 charactres long which are too short for some applications and installation environments 7. Inter-realm authentication. (The pairwise key exchange requires a lot of key exchanges for n realms).

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 blockexchange 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.

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 interoperate 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 implemented. It could prevent future problems. 5. Applications : E-mail, Usenet, distributed file systems.