Today I’ll explain what Kerberos is. First, I will explain the advantages Kerberos has over other types of authentication. Then we will deep dive into how it works as a protocol.
What is Kerberos ? – Kerberos Authentication
Let’s say you are in an insecure network where you want to authenticate but don’t want to send your clear text password across the wire. Kerberos provides a secure authentication on an insecure network 4 major advantages of using Kerberos are:-
- It never sends clear text passwords across the network.
- Any private or public Encryption keys are never directly exchanged on the network.
- The user and the application can mutually authenticate each other.
- It is commonly used as a basis for single sign-on.
The name for Kerberos comes from Greek mythology it is named after the “Cerberus the hound of hades”. He is a 3 headed dog that protects the gates of the underworld.
Kerberos Basic Terminologies – Kerberos Authentication
Kerberos Realm
All of this is part of kerberos realm.
It is a group of systems on which kerberos have the authority to authenticate a user to a service. we can have multiple realms and we can connect these realms.
Principal
Within a realm we have principals these are unique identities a user, service or an application.
Client
A client is a process that accesses a service on behalf of the user. you can have multiple users or clients within a realm. In simple terms, these are the users that want to access stuff in our realm. eg:- john ( a user in our realm ).
Service
A service is a resource provided to a client. we can have multiple services that clients can access.example a file server or an application that user wants to access.
KDC (Key Distribution Centre)
KDC is the heart of kerberos. It supplies tickets and generates temporary session keys that allow a user to securely authenticate to a service. It also stores all the symmetric keys in it. There are two servers within the KDC authentication server and the ticket granting server.
Authentication server
The authentication server confirms that a KNOWN user is making an access request and issue ticket granting tickets.
Ticket Granting Server
The ticket granting server confirms that the user is requesting access to a KNOWN service and issues service tickets.
Messages
The process of communication happens with a lot of messages passed between client and servers. some of them are encrypted and others are sent in plain text.
there are two types of messages authenticators these are record of information that are shown to have been generated using the clients session key which is only known to the client and the server. in simple terms authenticators allow a client to authenticate to a service and a service to authenticate to the client ( mutual authentication).
Other type of messages are tickets. tickets store all the other information related to the authentication for example clients id, session keys, time stamps, service id, time to live etc all encrypted using servers secret key.
Now that we have understood about all the components of kerberos lets see the cycle of authentication in depth.
Kerberos Process – Kerberos Authentication
It looks simple but this is a complex process atleast to me so i have broken down this in multiple steps to make it easier to understand.
Authentication Server
In the first step user/client makes a clear text message which includes the Username and id of the user. In this case, rob is the user. The service he wants to access in this case its a CRM. User’s IP address it can also be null or multiple IP’s in this entry and, at last, the lifetime of the TGT that the user wants. Users can request a TGT that never expires and stays valid for 1000 years but depending on how Kerberos is setup it’ll ignore the request if it doesn’t comply.
Once the user has their first message ready they will send it over to the authentication server. The Authentication server then checks the user id from the message with the list of users that are in the KDC if the user is found in the KDC Authentication server then takes the secret key of the user from the KDC.
After authentication server gets the secret key of the user from the KDC.It creates 2 messages to send back to the user. The first message contains the id of the ticket-granting server. Timestamp of the message generation. Then it adds the Lifetime of the TGT which is either the one that the user requested or what kerberos supports. at last authentication server adds a TGS session key which is a randomly generated key to both TGT and the message. The TGT has all the important information too the username of the user. TGS id, timestamp, IP address, a lifetime of the TGT, and a TGS session key.
Generating Clients Secret – Kerberos Authentication
When the client receives the message from the authentication server. He generates a key (client secret key) using his password and salt that is generally the username and the realm name and a key version number (KVNO). Then passed to a hashing function called string2key and the client’s secret key is ready.
Ticket Granting Server – Kerberos Authentication
Now that the client has his client’s secret key he can decrypt the first message that came from the authentication server. After decryption, the client gets the ID of the Ticket Granting Server the timestamp of when the message was created, and a TGS session key. Now user generates two new messages a plain text message that states what service we want to access and for how long we want our ticket to be valid. the second message is an authenticator which is encrypted with a TGS Session key that we got because we knew our secret key.
The user now sends these 2 messages and TGT received from the Authentication Server to Ticket Granting server.
On receiving these three messages from the client TGS checks if the service id from the plain text message matches its records if so it grabs the secret key of the service and then Decrypts the TGT because it was encrypted with the secret key of the ticket-granting service secret key. the TGT contains the TGS Session Key with this key Tiket granting server can now decrypt the authenticator message where it finds the user id and the timestamp. timestamps should be not older then 2 minutes and the user id is compared if they match. Compares the ip address to the clients ip address that the message came from and at last checks if the TGT lifetime has not expierd. if everything validates correctly.
Ticket Granting Server Cache – Kerberos Authentication
Then it compares the authenticator message with the TGS Cache and if the authenticator is not found then its added to the cache and we move forward. although if it is found then the ticket granting server will reject the request right away this provides protection against replay attacks.
Service Ticket Generation – Kerberos Authentication
The last step the Ticket Granting server does is it creates a message with the service id, timestamp, lifetime and Service session key. And in second message it sends the Service ticket that the client will then use to authenticate to the service. the first message is encrypted with TGS session key that the user already have and the Service Ticket is encrypted with the services secret key.
Then the Ticket Granting Server sends these two messages to the user.
The user had the TGS Session key so he can decrypt the first message with that key. Get the service session key. Then the user creates another authenticator with the user id and timestamp and encrypt it with service session key he got from the Ticket Granting Server.
The Service – Kerberos Authentication
After Creating the authenticator user then sends the service ticket and the authenticator to the service
When the service receives the message it decrypts the service ticket with the service secret key. After decryption we get the service session key using which it decrypts the authenticator. Then the service validate the data.like Ticket granting server did before it checks the user id matches with the one in the service ticket. IP address is the same as the service ticket expects and timestamp is not older than 2 minutes. At last that the service ticket is not expired.
Than checks service caches if the authenticator is in it than it rejects the authentication session. At last if the authenticator is not in the list then it adds it and proceeds to the next step.
After validating the service generates its own authenticator message. Encrypt it using the service session key it got from the service ticket.
Then sends it to the user at last user will decrypt the message using the service session key. Check his own cache if the authenticator is not present in the cache it will add it completing mutual authentication.
Conclusion
This is how kerberos completes the full circle of authentication and soon we will see ways to attack these steps of kerberos authentication. You can checkout Heist writeup which was a really cool windows box.Leave comments if you want me to write other such explanations.
Credits
credit for infographics goes to this guy https://www.youtube.com/watch?v=5N242XcKAsM.
2 thoughts on “How to Kerberos? its components and function”