The Insight Of Kerberos Protocol Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

This paper is an article thoroughly talks about the Kerberos protocol. Kerberos protocol is developed at Massachusetts Institute of Technology (MIT), it had developed with many security concern put in list to satisfy various application needs and easy implementation. Thus, it has been widely adopted by major organization in implementation on proprietary application or protocol.

The Kerberos protocol, in simple words, it used to authenticate clients from various network services but on the same time maintaining the whole transaction is secured and safe. Kerberos protocol easily turns an insecure network to a highly integrated secured network, thus allow users and data to be protected from eavesdropping from unknown sources and many other attack. Besides, Kerberos protocol doesn't carry password over the network while only passing hash key across the network as authentication process further enhances the security and become one of the exclusive advantages of this protocol.

Furthermore, this protocol is widely adopted and backed up by major organization participate in development and research, it is one of the most solid network authentication agent could be provided.

Although Kerberos holds the major authentication agent crown, there is nothing as impossible in current cyber world. A protocol needs to give and take to fit into various needs and limitation while still providing users as secured as possible and user-friendly. Thus, vulnerabilities of protocol is then appeared.

Introduction to Kerberos Protocol

Motivation of Protocol

Internet is an inter-connected network. Since its introduction phase of ARPANET with few nodes until currently uncountable available nodes, authentication is already post as a problem that to make sure data is travelled from one node to designated node without being modified. In the early development of internet, problem is discovered and many approaches have been designed. Early approaches is simply using password, clear text password to be specific. This clear text password authentication soon become a problem as it is easily sees by any clients that the data is travel through. Later encrypted password is introduced while it doesn't stays long enough as once cracker get hold of decryption process, encrypted password will be too become as clear text to them. Here, the problem domain is there is an urged need of an authentication protocol to prevent or at least minimize the damage of the visit of intruders to the network data, especially in the rapid grown of internet since the introduction.

Kerberos is then begins its research and development progress. It is started from Massachusetts Institute of Technology (MIT) as part of a project called Project Athena. (The MIT Kerberos Consortium) Project Athena proposed to create an integrated network to produce a campus-wide distributed computing network for campus education purposes. The project started in year 1983, same goes to Kerberos protocol which started simultaneously with the project. Kerberos is the backbone support for the project where used in client authentication across the network. It is so crucial that make sure the data is travel only to designated node across the internet or intranet of the campus.

Besides, Kerberos also set to make sure user-friendliness that avoid multiple passwords to each of the services provided, but on the same time making sure that all application is authenticated with appropriate user and just adequate access. (Calloway)

All these goals make Kerberos the better protocol.

Development of Kerberos

As previously states that Kerberos is part of the Project Athena which is campus network. It is a private development process until it is ready for open to public for further customization and improvement. Thus, there is no detail is published for Kerberos protocol from version 1 to 3. (Hewlett-Packard Development Company, 2005)

Kerberos on version 4, there is not much standardization process of the protocol involved. Version 5 is later published in year 1993 defined in RFC 1510, which many improvements and patches. But within 5 years of development, all the goals defined have been achieved. (Calloway)

The development process has been involved in many people to successfully develop the protocol. Started from version 1 to 3 which is internally developed by a team from Project Athena, there is document published known with any authors or developers name. Later, version 4 is more to public, Steve Miller and Clifford Neuman is the major contribution to the design and refinement of it, with the help from Jerome Saltzer, and Jeffrey Schiller. while version 5 is still led by them, but with help from John Kohl, major contribution on designing the protocol, Jennifer Steiner, and Theodore Ts'o. Besides, many members from Project Athena also joined forces to further contribute to the protocol development process. (Cisco Corp., 2006)

Each protocol needs to go through standardization through standardization body to make a protocol a standard. As the Kerberos version 4 is widely used once it is published and spread to other environment quickly, there is a need for standardization process which creates a standard platform for Kerberos to allow it is uniformly deployed and access. The standardization of the Kerberos protocol starts on version 5. The first published RFC 1510 for Kerberos has been passed through comment and review. A group of people, Celeste Anderson, Ravi Ganesan, Virgil Gligor, Sridhar Gullapalli, Charlie Lai, Gennady Medvinsky, Stuart Stubblebine, and Peter Will had commented on the draft paper of the protocol. RFC 4120 later superseded RFC 1510 and also updates RFC 1964. With the great support for Kerberos, RFC 4120 later being updated by RFC4537, RFC5021, and RFC5896 in different extension. Later in year 2007, Kerberos consortium is founded for Kerberos development progress. (The MIT Kerberos Consortium)

Typical Usage of Kerberos

Since publication of Kerberos protocol, vendor is amazed by its functionality and features it could achieved. The software giant, Microsoft implemented Kerberos protocol in Microsoft Windows for Workgroups and part of the ActiveDirectory, Microsoft's directory service for Microsoft networks. Microsoft use CHAP (Challenge Handshake Application Protocol) to send challenge response authentication through the network to authenticate users, it doesn't send any password through the network. (Hornstein, 2000) It this advantage, hacker could not eavesdropping on network and retrieve data. Compare to Berkeley UNIX networking, where a pair of username and password which sent over the network as clear text could easily been sniffed and abuse.

Besides of Microsoft, Sun Microsystem also implemented Kerberos on their NFS (network file system). (Cisco Corp., 2006) Kerberos protocol is used to authenticate users and allow access to their own home directory. On top of that, IPSecurity defined in RFC 2401 (Kent, 1998) also uses Kerberos in authentication process. This shows that how wide is Kerberos being implemented.

Hewlett-Packet (HP) also published Kerberos whitepaper (Hewlett-Packard Development Company, 2005) and explains its usage of Kerberos protocol in various service, from simple client authentication service of LDAP directory service to remote access service such as ftp, telnet and more.

Besides, it would be implements into web server to provide a robust and trusty network. Below is the image on how it authentication users with remote server. (Kent, 1998)

Kerberos - Inner Detail

How it works?

Kerberos protocol set to achieve a few goals in its design. First major goal of it is prevent the transfer of clear text password across the network which promotes eavesdropping and unauthorized access. To accomplish this goal, Kerberos uses secret-key cryptography idea, it uses secret key to authenticate user rather than password.

Kerberos suite is comes in a few packages or elements. There are Realm, Key Distribution Centre (KDC), Principal, and Tickets. Kerberos is a sophisticated system. A Kerberos Realm is a system boundary that define administrative limit of the networks, such as what service is included in the network and what is not a service suppose in the network. (Steiner, Neuman, & Schiller, 1988)

A Kerberos Distribution Centre (KDC) running 2 services which are Authentication Server (AS) and also Ticket Granting Server (TGS). Each of the single nodes in the Realm has their own secret key. But KDC have a copy of every principal's password.

First, principal ask user to input username and password. Principal will send a clear text to AS. This clear text include principal username, indicates AS, timestamp, and nonce. Nonce is a unique number randomly generated to prevent Replay Attack.

Once the packet arrived at AS, AS will generate principal's secret key by hashing the principal's password in the KDC database. AS use the secret key to encrypt TGS's session key. AS also pass a Ticket Granting Ticket (TGT) that encrypted using TGS's own secret key. TGT contain the information of principal to be able to access and also randomly generated principal/TGS session key. At the point of principal received the data, principal uses its secret key to decrypt the packet to get the freshly generated TGS's session key, the TGS's session key is cached locally for further communication with TGS within the key's lifetime. Principal is now holding enough information to authenticate itself to TGS. Importantly, due to TGT is encrypted using TGS's secret key, principal doesn't able to decrypt the TGT. TGT supposed to decrypt by only TGS.

By using the TGS's session key, principal generate and encrypt an Authenticator. Authenticator contains the principal credential information and timestamp and service request. This Authenticator packet and TGT is passed to TGS.

TGS at this point receives 2 packets from principal, first packet is the TGT, while second packet is Authenticator packet. Since TGT is encrypted with TGS's secret key, TGS will able to decrypt it and get principal/TGS session key as well as principal's credential in return. By using this principal/TGS session key, TGS decrypt the second packet from principal. It matches the principal information from the packet against the TGT. The Authenticator packet also tells TGS which service that principal would like to access.

TGS now need to generate 2 packets back to principal to allow principal to connect to secure service (SS) provided. Again, TGS has the secret key of SS. TGS generate and encrypt a SS's Ticket using SS's secret key, it also includes principal's credential. That is the first packet. Second packet is randomly generates a principal/SS session key and principal's credential with valid access time. Principal/SS session key is then encrypted with principal's secret key. Both of these packets is sent to user.

Principal at this point receives 2 packets from TGS, first packet is SS Ticket, while second is principal/SS's session key packet. SS Ticket is encrypted using SS's secret key thus principal does not able to decrypt it. But the principal/SS's session key packet is encrypted using principal's secret key. Principal then decrypts the packet to retrieve the principal/SS's session key.

Principal it is now ready to connect to specific service in the Realm. Principal generate a Authenticator which principal's credential, timestamp. This Authenticator is encrypted with principal/SS's session key. Now, both the SS Ticket and Authenticator is passed to SS.

SS will receive 2 packets from principal to begin authentication. SS decrypt the SS Ticket to retrieve principal's credential and principal/SS's session key. By using the principal/SS's session key, SS decrypt the second packet and match the principal's information from two packets. If it matched, then authentication is done and principal returned with access. (Kohl, Neuman, & Ts'o, 1992)

To simplify understanding on the protocol authentication process, image below will provide a simplified and overview of the process.

Principal's secret key is stored as a copy in the KDC's database. If there is too many simultaneous request from various principal, AS might be bottleneck and return in slow performance or worse not responding to request. To further enhance and polish the performance, KDC's database could be split as Master and Slave copy by Kerberos Database Management Service (KDBM). Master copy with authenticated administrator allow read and write access. While slave copy allow read-only request. Read-only means that whenever there is an occurrence where Master Kerberos database could not be contacted, principal can contact slave database copy to request for TGT ticket. While Master allow write access which means there is add principal request or principal change password request. To prevent the problem data consistency, master Kerberos will push a copy to slave every hour. Slave will check and match the checksum from master copy and update only if checksum is matched. (Leipold, 1999)

Kerberos Strength

Kerberos has been promoted with its robust securities characteristic throughout the development process; clearly there are many advantages that it holds to be one of a crown in authentication protocol.

First of all, Kerberos prevent network eavesdropping to happen. This is achieve by enforce that password do not travel across the network, either encrypted or not. Instead of using password to authenticate network user, password only used to authenticate user locally. To authenticate themselves via network, principal send a request (in clear text) to Authentication Server. Authentication Server replies with secret key encrypted packet over the network. The authentication process is done locally in Authentication Server or client, while both verify each other by their secret key. Even if there is eavesdropping occur somewhere in the network, without the secret key from the principal, the packet could not be able to decrypt to be useful enough. Even successfully decrypted, the information provided does not match to principal credential, the packet does not work. (Kohl, Neuman, & Ts'o, 1992)

Security mechanism does not just stop there. Prevention of Replay attack on the Kerberos protocol also takes in consideration. Each packet that sends through network is stamped with timestamp and lifetime. The lifetime of the ticket is configuration to further suit into each and every network. The timestamp ensure that packet that received is unique and valid on a period of time. Replay attack which capture the packet and resend it over the network tries to fool server with fake authentication would not work as it will not be valid as time passed. (Garman, 2003)

Furthermore, to attract interest on this protocol, Kerberos will randomly generate session key that specifically used between two nodes communication. This session key is later encrypted with node's secret key. This double encryption method is known with high security and passes with good comments. Brute-force attack on these packets is then render impossible as cracking will easily take months even on a supercomputing speed. By the time encryption is done, the key would be useless as it passed the valid access time. (Cisco Corp., 2006)

Last but not least, the second feature that Kerberos promote to further enhance its network is single sign-on (SSO, in short). The best security mechanism is to authenticate each and every service with user whenever there is a need for connection. Thus, even user account got compromised; unauthorized user is not hacked into all the services. Ticket-based authentication mechanism from Kerberos protocol is based on the theory above, and authenticate user to each and every service with ticket, each ticket to assign to each service. Although this might seems to violate the rules of single sign-on approach, Kerberos implemented a better approach to this goal. After principal done authentication with AS, principal keep a cached copy of TGT. With this ticket, principal could initiate further service request yet still maintaining the security level. (Hornstein, 2000)

Kerberos Weakness

In this modern time, nothing is impossible especially comes to technologies which is something fresh every day. The claimed impossible is slowly become possible. Throughout the time of development of this protocol, although there is intensive research and testing is carry out on the protocol, but there is something that not avoidable and vulnerable.

This can then discuss as Kerberos weakness and vendor needs to weight the advantage and scarification on this implementation.

First of all, KDC contain the password in a realm. This also reflects single point of failure. In easier way to say, if the KDC host is compromised, it will affect the whole network, worst come is the whole network will be compromised. (Hornstein, 2000)

Then, Kerberos authentication works best in single-user principal node. It might post security risk if node is a multi-user terminal. Due to keys are stored locally in the terminal, if keys are being compromised, then unauthorized user can impersonate by using the key found on the machine, he/she could access to the resources available until administrator invoke the account or the key is expire.

In version 4 of the Kerberos, which is now still available on production platform, there is a 5 minutes of timeout for each Authenticators transferred. If sniffer sniffed the packet out from network, they have roughly about 5 minutes time to request for service or authentication provided that other security measures is matched. This problem is later solved in version 5 of Kerberos, which introduce the use of replay cache. This cache will identify each Authenticator and disallow the use of it more than once. (Kohl, Neuman, & Ts'o, 1992)

Besides, version 4 also has another security flaw. Since the first authentication process is allowed to everyone in the network, principal send in clear text and request for TGT which encrypted with principal's secret key. This packet can be sniff and decrypt it offline with password using brute force or dictionary attack and retrieve the principal's secret key. Again, solution is too introduced, preauthentication is used in prevent this from happening. (Bellovin & Merritt, 1990)

Last, as mentioned previously that there is a Master and Slave of KDC. The purpose of this approach is to prevent bottleneck of request on primary KDC. The security catch here is that, malicious user can introduce down or failure of Master KDC to principal, in this case, principal instead of authentication with Master, they will turn to Slave version of KDC to continue authentication. This might sounds right, but malicious user can easily compromise the slave KDC as it is a cached copy. Malicious user can run different hash cracking and hacking method on it to reveal the password of users. This attack is famous in Microsoft Network environment, the ActiveDirectory service. (Cisco Corp., 2006)

In a nutshell, administrator who plans to implement this approach in network authentication should thoroughly review the protocol. And harden the vulnerable side to reduce risk of unauthorized access. Failover or recovery plan should be planned, and take in consideration of attack.