Abstract- Kerberos is an authentication protocol which helps users to communicate with each other in safe and secure way. But there is always a challenge to keep improving the Kerberos protocol. There still might be some areas where improvement can be done. In this paper, we take a look at the different ways to improve the Kerberos protocol. Each method would enhance the Kerberos protocol in a better way.
INTRODUCTION
security is one of the major areas that needs to be taken very seriously while communicating through any channel. The Kerberos security protocol was created at the Massachusetts Institute of Technology to overcome the security issues in the network services. In this paper, we would look at the evolution and working of the Kerberos protocol. Then we would look at some of the methods to further improve the Kerberos method. We would look at the following methods which would improve the Kerberos authentication protocol:-
An optimized Kerberos authentication protocol
Kerberos Authentication Protocol based on location.
Public key cryptography extensions into Kerberos protocol.
In the first method, it tries to overcome the fact that Kerberos protocol is susceptible to password guessing attack. It proposes a method that the secret key would not be dependent on the password of the user. In the Kerberos authentication protocol based on location, it overcomes the replay attack problem which the Kerberos protocol faces. It proposes a protocol based on location with the help of the GPS. In the third method, it stresses on the fact that the database of the key distribution center can be hacked and proposes a public key cryptography process in Kerberos protocol to overcome the problem.
Evolution and Working of Kerberos Protocol
Kerberos is a trusted authentication protocol which helps in secure communication. First, we need to know the evolution of Kerberos protocol.
Kerberos protocol [7] was initially developed to help the network to identify the clients in a secure manner. To make this happen, the client would start a three way message process to show that it is genuine to the server. The client will have to prove that it is genuine by showing a ticket to the server. The server would then give an encryption key which is temporary that can be used in order to make communication with the particular principal. The server also sends an authenticator which confirms that the client has a genuine encryption key. The aim of the authenticator is to stop an attacker or the hacker to show the same ticket again to the server in the future.
These tickets will be issued by a secure third party called key distribution center (KDC). The key distribution center will have the database of all the private secret keys which are known by every client and the server on a network. The Key which the key distribution center knows is the basis for any client or server to believe that the ticket it is receiving is indeed a genuine one. The ticket would be valid only for a limited period of time called the lifetime. When that particular interval gets over, that particular ticket would expire. So if any authentication exchanges in the future would be required to have another brand new ticket obtained from the key distribution center.
Let us now understand how the first ticket exchange would take place. Any application would make the ticket exchange when it initially connects to a server. Let us see the figure to under how the first ticket exchange would take place in any application.
Figure: First ticket exchange
As we can see in the above figure, the client would first communicate with the key distribution center, tells about itself and then gives a nonce which means a timestamp. After receiving this message, the key distribution center would choose any casual encryption key known as the session key and then it gives the ticket. The ticket would then identify the client, tells the session key, tells the starting and ending times and then gets encrypted with key Ks which are shared with both the key distribution center and the particular server. Since the ticket would get encrypted by the key which is known only by the key distribution center and the server, no one else could access the ticket. The key distribution center would then respond by sending the second message to the client. Its response would have the session key, ticket and the nonce.
After getting the response, the client would make decryption of using the secret key that it has. After examining the nonce, it would case the ticket and its respected session key to use in the future.
In the next message, the client would produce the ticket and a newly produced authenticator to sever. The authenticator would have a timestamp and it would be encrypted with the help of the session key kc,a.. After receiving the message, the server would then make decryption of the ticket with the help of the key which is shared with the key distribution center and then gets to know the client's identity. In order to verify the client's identity, the server would make decryption of the authenticator and it would also examine whether the timestamp is of current time.
If verification is done in a successful manner, it shows that the client has the session key. In case the client would request for mutual authentication from server, the server would then respond with a new message which is encrypted with the help of a session key. This shows to client that the server indeed has the session key. As the ticket has been encrypted only with the help of key that is known both by the key distribution center and server, the response would make sure that the server's identity is genuine.
Now an additional ticket exchange would place. To minimize the risk of exposing the secret key of the client kc, the exchange which is done above is used mainly to get a ticket for a ticket granting server. The client would delete the copy of the secret key of client when it gets the ticket granting ticket.
A client would produce its ticket granting ticket to the ticket granting server as it would produce to any server. The ticket granting server would verify the ticket, authenticator and it would then reply with a ticket to give access to a new server. The main part of the reply would have encryption done with the help of the session key obtained from the ticket granting ticket, thus the client would not need to regain the actual secret key kc to decrypt. The client would then use the fresh credentials to authenticate with the server.
Now let us look at the complete working of Kerberos. Let us look into the below figure to understand in a better way. We can see the client, application server, authentication server, key distribution center, ticket granting service. In the given figure, AS would refer to the authentication server; KDC would refer to the key distribution center and TGS would refer to the ticket granting service. The client is the person who would want to use a particular service. The application server will be the server to produce the service which was requested by the client.
Figure: Working of Kerberos Protocol
As we can see in the figure, the client would first request to be authenticated from the authentication server. The client then asks for a ticket granting ticket to the authentication server. The authentication server would then verify with the key distribution center which would have the database of all the users' secret keys and then provides the ticket granting ticket along with the session key to the client. The client would then use this particular ticket and session key and it approaches the ticket granting services. It then requests the ticket granting service (TGS) to give it a service ticket in order for it to access the service. The ticket granting server would then verify the details and it would then send the granting ticket with the session key to the client. The client would then use these and request for a service from the application server. The application server would then verify if the ticket is genuine and it would grant the service finally to the client. This is how the Kerberos authentication protocol works.
An Optimized Kerberos Authentication Protocol
Motivation:
Even though the Kerberos protocol has many advantages, it has certain loopholes as well. With the help of password guessing attack, an attacker can try to decrypt the messages. Also Kerberos needs the key distribution centre to be available continuously. These are some of the loop holes which are there in the Kerberos protocol. So in order to overcome them, this method proposes that a secret key would not be dependent on the password of the user. It also proposes to produce a secret key depending upon the profile.
Working
As the Kerberos protocol can be susceptible to password guessing attack, a change to the database of the key distribution centre is proposed. In this change, it is proposed that the secret key of the client or server would not be dependent on the password. Instead of the normal procedure, the key distribution centre would save the profile for every single time while managing a realm. The profile data may be of any type like audio data, video data or even plain text. The database of the key distribution centre would have many mixed profiles. Every client or server present in a network gets registered with the database of the key distribution center with the principle ID[3]. Then the key distribution centre would map the principle ID to the profile which has its name as the principle's ID. To produce the secret key, a hashing algorithm would be applied to the profile and the output would then be encrypted.
We can see in the above figure about the generation of the principle secret key.
Result
As the secret key of the principle would not be dependent on the password of the principle, the Kerberos protocol would no longer be susceptible to the password guessing attack. Thus this mechanism would enhance the Kerberos protocol and improve the existing model.
Kerberos Authentication protocol based on location
Motivation:
The replay attack is a type of attack where the data is illegally repeated. Kerberos protocol has many mechanisms to prevent the replay attack from happening. Despite taking the precautions, the Kerberos protocol sometimes cannot prevent the replay attack from happening. It can so happen that a server can be given wrong information about the actual time [5]. If that happens, attacker can replay the authenticator with ease. In order to overcome this problem, a model called [2]N-Kerberos is proposed which is based on location.
Working of N-Kerberos:
The main aim of this method is to overcome the problems faced by the replay attack. This method proposes to modify the existing Kerberos model. The proposed model called the [6] N-Kerberos model works by knowing the exact position address of the client. This particular address can be known with the help of a global-position-system (GPS).
It is proposed to include the physical address of the user in all the messages which are produced by Kerberos and also the old two conditions like encrypting with a strong password and using a time stamp. Let us look into three methods which give us information in detail.
Method 1
In this first method, it is the [2] server's responsibility to confirm the genuineness of the location. Let us have a look about how messages are transferred in this case.
In the initial message, the user X would request to get the key which would then be used to communicate with user Y. The server would then interpret and sends the response to user X.
This method adds new ways to use GPS. These ways are as follows:-
The genuine location addresses of the users is used by the server to add user X's address to the ticket.
User Y's location address is then added to the message.
The 3rd message will have both the authenticator and a ticket. The ticket would get encrypted and the session key would encrypt the authenticator.
These following changes are made to the old Kerberos authentication protocol: -
X would add his own location address taken from the GPS to the authenticator.
Y would not think that the message is genuine unless the address of Y present in the ticket, given by the server is matched by the GPS.
For X to believe Y, the 2nd message and the 4th message should be made use to validate the location of Y. In order for this to happen, the 2nd message should behave as a ticket and the fourth message should behave as the authenticator. The GPS of Y included in the 4th message must be same as the GPS of Y in the 2nd message which the server sent.
But there was a problem in this case. The problem was there in the 2nd message. The problem is that the 2nd message does not have the user X's physical address. Thus a person who would want to hack would just use the 2nd and 4th messages and do the comparison of GPS(y) in 2nd message and GPS(y) in the 4th message. So the inclusion of GPS in the 2nd message does not make the security any better. In order to overcome this problem, a 2nd method was proposed.
Method 2
In the 2nd method, it is the user's responsibility to confirm the genuineness of the location. Let us see the changes from the previous method.
The 2nd message will have the user X's physical address instead of user Y's physical address. Now user X should prove that he is in an allowed position. This would be done by comparing the server sent message's physical address with the message taken from GPS placed in X's location. Therefore, X would not be able to get the key without matching the addresses.
The ticket which is there in the 2nd message which the server has sent having the user Y's physical address instead of user X's physical address must prove that he is in his allowed position. This would be done by examining the address present in ticket which was sent by the server with the address it would get from the GPS placed in that particular user's location. Even now the user Y would not the key if the addresses are not matched.
It is not needed to include the GPS(X) in the 3rd message and also not needed to add GPS(Y) in the 4th message since it is not needed to compare X's location in the 3rd message with Y's location in 2nd and 4th message.
Even in this method, a problem had arisen. The problem is that the user is not being asked to compare the two physical addresses. It means that a person who wants to hack would not be prevented if he stops the comparison. Thus to overcome this problem, a 3rd method was proposed to make users to do comparison.
Method 3
In order to know what is done in this method, we need to understand the GPS signal's two components. Every GPS satellite will transmit signals of two types, an encrypted and safe signal only for the military persons, encrypted by P(Y) code and a regular signal meant for civilians encrypted by the coarse/acquisition (C/A) code. The P(Y) code's advantage is that it can be able to detect the physical position. Also, it is immensely difficult to find out the P(Y) code by making use of the physical location. In other words, users can user their particular P(Y) code and save it to validate their address signature with the server. Now the changes which are done to the 2nd method are:-
The server should find out all the users P(Y) .
Then the server should use the P(Y) code to hash it and then the key encryption should be done with the hashed value.
The User X can make the decryption of the message with the help of the key and also the key can be decrypted with the hashed value.
The 3rd message will have the ticket with the user Y's signature.
Thus in this method it would become difficult for a hacker to decrypt the signature of user X since time synchronization problem would arise.
Result
Thus with the help of the above methods, the problem of replay attacks which the Kerberos was facing is finally solved. Thus with the help of the location, this proposed method overcomes the problem of replay attacks and other time based attacks.
Public key cryptography extensions into Kerberos
Motivation
Even though the security given by the Kerberos protocol is good enough, some changes still can make it function in a better manner. In the Kerberos authentication system, the server would reply to the client's request of ticket granting ticket by given the client a ticket which is encrypted by his secret key. It means that every client's secret key should be remembered by the key distribution center. If any hacker gains access to the database of the key distribution center, then the secret keys of the users would be known and the security would get compromised. This motivated to introduce public key cryptography into the Kerberos protocol. With the help of public key cryptography, Kerberos can use the public keys to encrypt the ticket granting tickets. So even if the database of the key distribution centre is hacked, it wouldn't compromise the security at all.
Working
Now let us understand how the [1] public key cryptography would work with the Kerberos system. Let us assume a person named Alice as the user or client. Let us look into the below figure to get to see how it works.
Figure: Public key cryptography in Kerberos
The mechanism would work in the following steps:-
Initially the user Alice would request for a ticket granting ticket from the authentication server.
The authentication server would then look into the data base of the key distribution centre to verify that the particular user is authorized or not.
Once verified, the authentication server would produce a session key to Alice which is encrypted with the secret key of Alice.
Now after decrypting the received session key, Alice would then request for a service ticket from ticket granting service with the help of her ticket granting ticket and authenticator.
Now verification is done to authenticator of Alice.
After authenticating, the key distribution centre would send the service ticket to Alice in an encrypted message. The encryption is done with Alice's session key previously given by the authentication server.
Now Alice would decrypt the message and gets the service granting ticket.
Alice would then make her username encrypted with the session key which is shared by both Alice and Bob to prove her genuineness to Bob
Alice would then send the service ticket and the authenticator to Bob. She will also have the option to set the flag which activates mutual authentication and the server would prove it's genuineness to Alice.
If at all Alice asked for mutual authentication, Bob would use the time from her request and would return it using the shared session key.
This is how public key cryptography is done with Kerberos protocol. Public key cryptography can also make the newer keys registration easier because the public keys would be transmitted in a safe manner clearly to the database of the key distribution center. [4] Protecting the secret keys privacy while it gets registered in the key distribution channel is only made possible by safe channels for communication or entries which are made on the key distribution center manually. Thus, public key cryptography would give the users with the freedom to access remotely.
Result
The public key cryptography thus would further enhance the Kerberos protocol. The secret keys of the users would be safe and the security would not get compromised in the key distribution center even if the hacker will get access to it and hacks it. Thus the public key cryptography extension into Kerberos authentication protocol proves to be a good step to handle security issues.
Conclusion
In this paper, we have seen how the Kerberos model was evolved and how it works. We have also seen some of the methods to improve the Kerberos authentication protocol. Thus the main problems like the replay attack, password guessing attack and key distribution center's database loophole are solved with the help of the methods proposed in this paper. With the help of these methods, the Kerberos protocol would now be further enhanced and would be more powerful in terms of security.
