High Level Description Of The Kerberos 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 research report gives a high level description of the Kerberos protocol. Mainly concentrating on Methodology, application in real world, future changes in Kerberos. It includes detailed information about important concepts and features of Kerberos authentication.

Introduction to Kerberos

What is Kerberos?

It is a network authentication protocol. It is designed to provide reliable authentication over insecure or open networks. Kerberos is customized according to the operating systems and network systems available. The main working is similar there are only some changes, which are customized according to the operating system.

The open network is am insecure place. The protocols used in the internet fails to provide complete security. People fail prey to malicious attackers to end up providing password. It might not be intentional, the person fails to identify the threat. Hence applications which sends an unencrypted password over the network are highly vulnerable. The server applications depends on the client program and trusts the identity of the user who is using it.

Few websites use firewalls to protect their network from attacks. But firewalls fails to identify that the threat is from insiders and not on the outside. Firewalls also brings in restriction how users use the internet.

Kerberos was initially created by MIT as a solution for the network security issues. Kerberos distributes secret keys and uses cryptographic protocols like Needham-Schroeder to verify possession of these keys. This made client confirm its identity to a server and other way, across an insecure network. All of server-client communications can be encrypted to achieve privacy and data integrity, only after client and server has used Kerberos to confirm their identity.

It is freely available under copyright permissions. The source form of the Kerberos is provided by MIT, so anybody who wants to use it can check the code and confirm that the code is trustworthy. It is also available from many vendors for those who depend on support related to Kerberos. It is used as a effective protocol to provide tools of authentication and strong cryptography over the network to secure information systems.


Kerberos was developed by MIT for Project Athena. Main developers were Miller and Neuman. It was named after the Greek mythology character 'Cerberus', a three headed guard dog of Hades. MIT integrated network computers as a part of its campus curriculum in 1983 by Project Athena. It received grants from Digital Equipment Corporation and IBM. It had already acquired many operating systems from different vendors. The main aim of that project was to achieve Single Sign-On, unified graphical environment, naming convention service and networked file systems. There are several versions of Kerberos. The initial versions 1-3 were meant for internal use in MIT. Version 4 was released in 1980 and was limited to Project Athena. Version 5 was released in 1993.


How does it work:

To understand how Kerberos works. We need to get familiarized with few terms and components used in the working of Kerberos. The below listed are not the only used terms and components but these are the ones which are sufficient to explain the working.


Realm: It indicates an authentication administrative domain. Its main function is to establish the limitations within which an authentication server has the authority to authenticate a user, host or service. Even though two objects are part of different realms but there is a trust relationship between them then the authentication takes place. This is known as cross-authentication.

Usually realms are in upper case. In an organization it is best practice to have company DNS domain name as realm. e.g WORDPRESS.COM

Principal: It is name used to refer to the entries in database of authentication server. It is usually associated with each user, host or service of a given realm.

Principal for an user is: Name/instance@REALM e.g: shashi/admin@WORDPRESS.COM The Instance is optional and is usually used to improve the quality of the user type.

Principal for services is: Service/Hostname@REALM

First part in the above is the name of the service for example ftp,AFS,imap. Usually it is the generic access to the system.

Second part is fully qualified domain name(FQDN) of the system providing the service.

Kerberos Ticket: All entries in Kerberos have a secret key, It is shared only with authentication server. To request services from an application server in a Kerberized environment, client must obtain what is called a Kerberos ticket. It is used to prove the authenticity of the client to server.

A Kerberos ticket contains:

The requesting user's principal

The principal of the service

The IP address of the client system from which the ticket can be used.

The timestamp when the validity starts.

The expiry of the ticket

The Session key

Encryption: Kerberos needs to encrypt and decrypt messages often passing between client, server and other components in Kerberos. The encryption type is symmetrical key encryption that is same key is used to encrypt and decrypt.

Key distribution centre(KDC): There 3 functioning bodies in JDC.

Authentication Server(AS): It is the one which replies to the initial authentication request from the client, after user enters the correct password. As a response to the authentication request by the client, AS issues a special Kerberos ticket known as Ticket Granting Ticket(TGT). The principal associated with AS is krbtgt/REALM@REALM.

Database: Whenever the client requests for authentication verification, the AS checks the user id and password in its database. The master key is used to implement encryptions which is associated with the principal L K/M@REALM

Ticket Granting Server(TGS): It is the body which is responsible for distributing service tickets to the clients with a valid TGT ensuring the authenticity of the identity.

Session Key: The session key plays an vital role in demonstrating the authenticity of the user. The secret which user shares with the KDC is the key, obtained from their password. The secret which services share with the KDC is the key. These keys are called long term keys. The user shares a secret with the service for the time period in which a client has established a work session on a server this key is called session key and is generated by the KDC. The copy corresponding to service is enveloped by the KDC in the ticket, similarly copy corresponding to user is encapsulated in an encrypted packet with the user long term key.

Authenticator : It is a packet added by the client along with the ticket containing user request, which has time stamp and user principal, encrypted with session key. The authenticity of a client is not confirmed in open and non secure, even if the user principal is present in a ticket and only the server can decrypt it. In a man in the middle attack, attacker can capture the ticket sent by the authentic client to the server and send it to server mocking the client and use the requested service. In such cases the authenticator proves the authenticity of the client.


There are two version of Kerberos. For the ease of understanding, I have explained both in different ways so that there is no confusion. Working of version 4 is as below:

Working of Kerberos version 4.

The process can be symbolized using notations. The notations used in the symbolic form are:

C - Client

AS - Authentication Server

V - Server

IDC - Identifier of user on C

IDV - Identifier of server

PC - Password of user on C

AdC - network address of C

KC - Secret key shared between C and AS

KC,TGS - Secret key for C and TGS generated by AS.

KC,V - Session key for C and V generated by TGS

Ktgs - Secret key shared between TGS and AS

TS - Timestamp

|| - concatenation

Diagrammatic representation:


Below is a explanation of simple version 4 Authentication Dialogue.

Step 1:

Step 2:

Step 3:

Working of Kerberos 5

The working is based on the Kerberos tutorial (Ricciardi, 2007). However a simplified versions is followed after this explanation. Main working is shown in the diagram below:

Diagram Source Ricciardi Tutorials

Kerb work.JPG

The necessary packet details are given below:

AS_REQ: is initial user authentication request.


AS_REP: It is the reply from AS to Client.



TGS_REQ: It is the request from client to TGS for a service request.



TGS_REP: It is the reply from TGS to Client



AP_REQ: Is the request that the client sends to an server for a service.


4.5 2.JPG

AP_REP: Is the reply which has proof that server is authentic and is ready to give requested service.

The above explanation might require better understanding about the terminologies. Therefore another easy explanation is down below.

Working of Kerberos in simple words: There are 3 parties involved, making sure the user is communicating with authentic sources.

Client: Which needs a service e.g a file server.

Server: Which is providing the service.

Key Distribution Centre: It has two parts: Authentication server: which contains user names and passwords, Ticket Granting server: tickets for all the servers

User logs in using his user name: 'User' and password: 'kerboros4v'. When he initiates a login, the client generates an one way hash - secret key

When the client wants to use a service it sends a clear text message to authentication server requesting for the service.

The AS checks if the client is in its database. if yes, AS generates a client secret key based on the user name and password of the user from the client machine. Then AS sends two messages to client.

Message A contains : Client/TGS session key which is encypted with client secret key. This will be used between client and the TGS.

Message B is the Ticket Granting Ticket which includes client ID, Client network address, ticket validity period and Client/TGS session key which is encrypted with TGS secret key. Only TGS can decrypt.

When client receives these messages it decrypts message 1 and obtains client/TGS session key which was encrypted with client secret key. Client cannot decode message 2 since it is decrypted with TGS secret key. Then client sends two messages to the TGS.

Message C: Ticket granting ticket from message 2, which is encrypted with TGS secret key and the service id.

Message D: Authenticator composed of client ID and timestamp which is encrypted with Client/TGS session key from message 1.

The TGS decrypts message C to get Ticket granting ticket consisting of Client ID, client network address, ticket validity period and client/TGS session key. Both Client and TGS can communicate with each other since they have client/TGS session key.

TGS decrypts message D using client/TGS session key and gets Client ID and timestamp. So it knows when the client sent this message. TGS checks if the client ID from message C matches client ID from message D and has the ticket validity period expired i.e the timestamp does not exceed ticket validity period then it sends 2 messages to client.

Message E: Client/Server ticket which is encrypted with Server secret key and contains Client ID, network address, validity period, client/server session key.

Message F: Client/server session key encrypted with client/TGS session key from message A.

Client decrypts message F using the client/TGS session key and obtains client/server session key. Client sends message E it received from TGS earlier. This contains Client ID, network address, validity period, client/server session key. It also sends message G which contains Authenticator composed of client ID and timestamp which is encrypted with client/server session key from message F.

Server decrypts Message E using server secret key and gets Client ID, network address, validity period, client/server session key. It decrypts message G using client/server session key and gets client ID and timestamp. Servers has client ID from message E amd G. Server checks if these two matches and timestamp does not exceed validity period. If it hasn't expired the server sends message H to confirm its true identity and willing to serve the client. Message H contains the timestamp found in G +1 encrypted with the client/server session key.

Client decrypts H using client/server session key and checks if the timestamp is timestamp + 1, if so it is correctly updated and client can trust the server. After that client issues service requests to the server and server services the request.

Differences and Changes

The drawbacks in version 4 led to version 5 with overcoming the limitations. The limitations and the counter measures are discussed below. Also It should in a way bring out the differences between them.

Dependency over encryption method and IP address

Drawbacks of version 4: Version 4 uses Data Encryption Standard to encrypt messages. The usage of version 4 was set back when US Government restricted the export of DES. Using of IP address rendered unsuitable for few environments.

Changes in 5: Distinct software bits are added which can be manipulated by the programmer. Type identifier is attached to the cipher text making it easy to identify the descryption algorithm. Data type and length is added to the IP address which makes it easy to identify even if there are multiple networks.

Message encoding

Drawbacks of version 4: The sender and receiver bothe uses their own byte ordering which leads to unusual byte order and interoperability is affected.

Changes in 5: A message describing method is fixed. It uses Abstract Syntax Notation One(ASN.1) Which indeed prevents unusual byte order.

Ticket Lifetime

In version 4 the ticket lifetime is calulated using the basic Unix time stamp and 8 bit lifetime quality in five minute units, resulting in a lifetime of around 22hours. Some long running transactions require more than 22 hours.

Changes: This was overcome by decoding the messages with 'start time' and 'end time' which made its lifetime limitless.

Naming Principal: In version 4, 3 components name, instance, realm contribute to principal naming. Character length of each of them is 39 characters and which seemed to be less. Also, the period(.) was not allowed in naming and hence would make account name and name portion of the principal identifier same. Which was a major drawback.

Changes : In version 5, principal naming is contributed by multiple components. Identifier has two parts realm and remainder of the name. Realms is separated to implement realm-traversal routine and realm-sensitive access checks. The remainder of name is made up of numerous components needed to name the principal.

Inter-realm support: In version 4, the assignment and management of inter-realm keys is too broad and monotonous. The pair wise key exchange requires O(n2) key exchanges to interconnect to n realms.

Changes in 5: In version 5, hierarchy based on the name of the realm is used to cooperate among the realms. Different pair of inter-realm keys are exchanged among each real with parent realm and its child realm. The number of key exchanges reduces to O (log n) exchanges.

Additions in version 5: The drawbacks in version 4 have been improved by adding new features.

Tickets: Additionally tickets in version 5 has timestamps and flags field, two expiration times, mechanism to renew tickets, ticket forward- authentication forwarding. These are the additional features related to the tickets. The timestamps inhibit better flexibility. Expiration is not fixed and has two fields. The ticket in version 5 is renewable. Proxy handling is enabled because of the ticket forward feature, which indeed is like credentials issued to one client can be forwarded to some other host for another client's use, only after KDC sees the flag in TGT to permit such use.

Authorization data: Kerberos version 5 provides a safe transmission of authorization information and accounting data as a part of the ticket. These details act as restrictions for using the tickets. The application server is responsible for using authorization data and accordingly restrict client's access to its services. Authorization data is used to forward the ticket to another client with its capability to use the authentication data.

Pre-authentication data: To prevent the password theft pre-authentication data field has been added. These data fields have information about password alternatives. These field in the initial ticket exchange can be used to change the Kc in which reply is encrypted. Changing the password makes the password theft attempt useless. In additional ticket exchange the pre-authentication fields are used to transfer TGT to the KDC.

Subsession key negotiation: To prevent issues caused by reusing a ticket's session key across many connections, server and client can share a subsession key which helps to protect a single connection. When the connection is closed, these subsession keys are discarded. Privacy of the message published to multiple recipients can be protected by using the subsession key negotiation.

Sequence Number: There are two message formats available for applications to protect their communications. KRB_SAFE format uses cryptographic checksum to achieve data integrity. KRB_PRIV uses encryption to achieve privacy and integrity. In version 5 application can select to use timestamp or sequence numbers. If sequence number is selected then receiver must verify if it is receiving it in the correct sequence.

Kerberos in real world

Kerberos is mostly used by all major operating systems and most of the online services. The main reason it is used by majority of them is because it is less prone to attacks and it is very efficient. Kerberos is also used in a mixed environment (Shinder, 2006), using both UNIX and Windows servers.

Kerberos in mixed environment:

The Kerberos implementation in real world is an important task. We need to understand the usage of the services and decide the proper implementation. Kerberos version 5 from MIT has few utilities like:

Kinit: It is used t login to the realm with the client's key

Kpasswd: It is sued to change the password.

Klist : It is used to view the tickets in the credential cache

Kdestroy: deletes from the credential cache

Kadmin: It is used to make changes in accounts in the Kerberos database

Kprop: It is used to sync the master KDS

In windows, domain controller plays the role of KDC along with active directory server. Windows servers supports transitive key trusts. In simple words Domain A trusts Domain B and Domain B trusts Domain C, then between Domain A and Domain C there is an implicit trust. Since Windows uses RFC 1510, the Active directory functions similar to Unix realm.

In a mixed environment Windows and Unix can authenticate one another or each other. The Kerberos client software should be set up to use the right KDC and realm. With the help of Kinit tool, by pointing it to Windows DC as its primary KDC, Unix clients can get Kerberos tickets from Windows server. Similarly Windows clients can be configured to authenticate to a Unix KDC using Ksetup, Microsoft command line tool to configure Kerberos realms, KDC and kpasswd servers. Configuring one way trust between Kerberos realm and the Windows can allow access from Kerberos realm to Windows clients on a regular basis. This will make Windows users to automatically trusted by the Unix Kerberos server, since it is authenticated to windows server. Another one way trust can be configured from Unix to windows in a similar method, which in turn will make them two way trusted. Non- Windows users can log into Unix server and vice versa.

Similar to Windows and Unix there are many operating systems which uses Kerberos authentication protocol. Few of them are FreeBSD, Apple's Mac OS X, Red Hat Enterprise Linux, Oracle's Solaris, IBM's AIX and Z/OS, HP's OpenVMS.

Limitations of Kerberos: The drawbacks of Version 4 is eliminated to certain extent by the release of version 5. There are few limitations in version 5 too. The main ones are:

Availability: The Kerberos server availability is critical. If it is down the entire log in procedure fails. Multiple Kerberos servers can be used to handle this limitations.

Secure time system: The systems which are taking part in the Kerberos authentication must have synchronized time with the Kerberos system. The tickets have validity period and a entity timestamp. If the clocks are not in synchronization there are high chances that the authentication fails.

Password guess: Initially there is no requirement of any authentication to request a ticket. An attacker can also initiate the ticket request and then the Kerberos system is under the password crack once the attacker gets to know this method.

Future changes to the technology

There are many version of future proposals. This is because of the numerous tie ups and sponsorship for the Kerberos. It is important to know the ones which will change the way Kerberos is now in the real world.

The main vulnerabilities of Kerberos are man in the middle, password hack. There is a proposal to save the profile consisting of login credentials for every instance in the realm the KDC manages. The profile may contain audio, video, image or simple text. The KDC might have different types of profiles. Every principal in the network is registered in the KDC database using the principal id that belongs to the profile. Hashing algorithm is applied to the principal's profile and then encrypt the output. The lifetime of the secret key is controlled using the current KDC system time which is appended to the principal's profile. This changes the input to the hashing function and also the output and the secret key will change. Refer below diagram.


Picture courtesy : International Journal of Network Security [1] 

Interoperability with SAML and SASL

The inclusions of SAML and SASL would give new dimensions to the existing Kerberos functioning. The below is the snapshot of the MIT Kerberos Consortium answer related to inclusion of SAML.


Courtesy : MIT Kerberos Consortium

Availability on more devices: MIT Kerberos said it would want to ectend the implementation in more phone devices. Apple is already one of the supporters for Kerberos and Google is expected to enter the market. It is rumoured that Sun technologies offers its Java technology to device managers in form of JavaPhone. Improving security on mobile devices helps everyone else.