Kerberos: The Computer Network Authentication Protocol
It’s being nearly 11 months journey as an intern at WSO2 and it has certainly being an amazing experience for me. Throughout these months I have come across many new technical terms which I wasn’t aware of. “Kerberos” is such term. I have seen the term Kerberos appearing in several mail threads and documentations. Out of curiosity, I did a bit of exploring and got a basic understanding about what and how Kerberos comes into play in the technical world. So here I am to share the facts I have gathered. If you’re a newbie for Kerberos and interested in network security, I recommend you to have a look at this post :)
With the technological advancements, communication over the internet is rapidly increasing day by day. Well, so does the increase of eavesdropping and replay attacks over the internet. Many authentic services have been developed to prevent malicious users from trying to access data passed over the network. Kerberos is such protocol designed to ensure the security when communicating over a non-secure network. Simply I can put it as an authentication protocol which allows only legitimate users to access the intended services over the internet.
Kerberos was named after the ferocious three-headed guard dog of Hades appearing in Greek myths. Kerberos was developed by Massachusetts Institute of Technology (MIT) for a project called Athena.
Enough with the background explanation, let’s dive in :)
Main entities involved in Kerberos flow:
- Client: Initiates the communication for a service request. Acts on behalf of the user.
- Server: The server with the service the user wants to access.
- Authentication Sever (AS): Performs client authentication. If the client is authenticated successfully the AS issues a ticket called TGT (Ticket Granting Ticket). TGT proves to other servers that client has been authenticated .
- Key Distribution Center (KDC): In Kerberos environment authentication sever is logically seperated into three parts: Database (db), Authentication Server (AS) and Ticket Granting Server (TGS). Physically these 3 parts are existing in a single server and it is called as Key Distribution Center.
- Ticket Granting Server (TGS): An application server which provides the issuing of service tickets as a service.
In Kerberos flow there are 3 important secret keys. A unique secret key is there for client/user, TGS and server which is shared with the AS.
- Client/user secret key: Hash derived by the user’s password.
- TGS secret key: Hash of the password used to determine TGS.
- Server secret key: Hash of the password used to determine the server offering the service.
Now comes the interesting part. I’ll be explaining step by step what happens in the Kerberos authentication protocol. Please note that I’ll be using several abbreviations when explaining to prevent the repetition of common terms.
First of all the user has to log into his/her account. By using the password provided by the user, client secret key is computed. Next comes the actual Kerberos flow.
Step 1 -
This is the initial authentication request. The client requests AS for a Ticket Granting Ticket (TGT). The client ID is sent in the request. Note that the password and client/user secret key is not sent.
Step 2 -
The AS checks for the availability of the client and TGS in the database (db). If either of values are not found, then an error message is sent to the client. If both values are available then the client/user secret key is generated by using the hash of the password of the user. The password of the user is available in the db. Also the TGS secret key is computed.
AS generates a session key (SK1) to be shared between the client and the TGS. SK1 is encrypted using the client secret key.
AS generates a TGT which contains client ID, client network address, lifetime, timestamp and SK1. The ticket is encrypted with the TGS secret key, so it’s contents can only be deciphered by the TGS.
The response message to be sent to client contains of the generated SK1 and TGT. Finally this message body is encrypted with the client/user secret key so that only the client is able to decode the message.
Step 3 -
Client decrypts the message using it’s client/user secret key (generated from the password entered by the user) and extracts SK1 and TGT. The authenticator which is used to validate the client to TGS is generated. The authenticator contains client ID, client network address and client machine timestamp and is encrypted using the extracted SK1.
The client sends the created authenticator and the extracted TGT to TGS, requesting a ticket from the server offering the service.
Step 4 -
The TGS decrypts the recieved TGT using the TGS secret key and extracts SK1. Using this key, the TGS decrypts authenticator and checks if client ID and client network address from TGT and authenticator match. A check is also performed to find if the TGT has not expired from. This is done from the timestamp extracted.
If all the checks are met then a service session key (SK2) is generated. SK2 is the secret shared between the client and the target server.
A service ticket containing client id, client network address, timestamp and SK2 is generated. This ticket is encrypted with the server secret key which is obtained from the db.
The response message body to be sent to the client contains SK2 and service ticket. Finally the message is encrypted with SK1 which is known to the client.
Step 5 -
After receiving the message, the client decrypts it using SK1 and extracts SK2. A new authenticator, which includes the client ID, client network address and timestamp is generated. This authenticator is encrypted using SK2.
The client sends the authenticator and service ticket to the target server.
Step 6 -
The target server decrypts the service ticket with the server secret key. SK2 is extracted from the service ticket. Next the authenticator is decrypted using SK2 and client ID, client network address, timestamp is extracted.
Checks are performed to verify if client ID and client network address from service ticket and authenticator match. A check is also performed to find that the service ticket has not expired.
If all checks are met the target server returns a message consisting of the time stamp plus 1, encrypted with SK2 to the client. This message proves that client and the server have completely authenticated each other. Therefore a trusted service session can now begin.
So this is how the Kerberos authentication protocol allows clients to communicate over a network in a secure manner. At a glance it might look complex. If so I recommend you to go through the steps once more :)