Table of Contents
What is Kerberos?
Kerberos is a network authentication protocol that is used to verify the identity of a user or host. The protocol works on the basis of tickets to allow nodes to communicate over a non-secure network to prove their identity. Both sides mutually authenticate each other through this protocol. Kerberos is designed to provide security and authentication.
Let’s suppose that a client would like to access a File Server like figure in below. According to the authentication protocol, the client has to be verified through a trusted third party, which is called Key Distribution Center (KDC). The KDC has two functions: An Authentication Service/Server (AS) and a Ticket Granting Service/Server (TGS). The following figure summarizes how the authentication process occurs and what packets are exchanged during the authentication.
Breakdown of the authentication steps
Step-1: The client sends a request (AS-REQ) to the AS, asking for a TGT. The request is partially encrypted with a shared secret key derived from the client’s password. Once the AS receives the request, it uses the client id (username) and retrieves the client password from the database. It derives the same secret key from the password and decrypts the request.
Step-2: After verifying the client id, the AS replies the client with an AS-REP packet which includes a TGT. The TGT contains information such as service name, client id, expiry date, a session key, the client’s address etc. and is encrypted with the AS’s master key. Beside the TGT, the AS encrypts the session key with the shared secret key derived from the client’s password and inserts the encrypted session key into the reply as well. The client does not have the AS’s master key to decrypt the received TGT. It only has the shared secret key derived from the client’s password to decrypt the session key.
Step-3: The client sends the TGT to the TGS with a TGS-REQ packet. With this request, the client asks the server for a service ticket. When the TGS receives the request, it decrypts the TGT with the secret key shared with AS (AS’s master key).
Step-4: The TGS creates a service ticket and encrypts it with another secret key which is shared between TGS and the File Server. The service ticket includes information such as service name, client id, expiry date, a new session key, the client’s address etc. One copy of the new session key is encrypted with client’s session key and inserted into the reply.
Step-5: The client constructs an AP-REQ (Application Request) message to the File Server, providing its service ticket.
Step-6: The files server replies with an AP-REP (Application Reply) message to the client, letting the client to access the resources for a period of time.
The screenshot below shows the details of the authentication process with another perspective.
Decrypting Kerberos Authentication packets with Wireshark
Thanks to Wireshark, we can decrypt Kerberos packets partially with help of keytab file to analyze the packets. A keytab is a file containing pairs of Kerberos principals and encrypted keys that are derived from the Kerberos password.
Step-1: Download the capture and keytab file from here (https://wiki.wireshark.org/uploads/__moin_import__/attachments/SampleCaptures/krb5_tgs_fast.tgz). The capture contains the packets explained above.
Step-2: Launch Wireshark and open 'krb5_tgs_fast.pcapng' file.
Step-3: Navigate to Edit → Preferences and a window opens.
Step-4: Expand the protocol tree from the left pane and find KRB5(Kerberos). First select 'Try to decrypt Kerberos blobs', then use browse button to add 'ndc.keytab' keytab file and click 'OK' to finish.
Analyzing Kerberos protocol packet by packet
After decrypting the packets with using keytab file, we will analyze each packet.
Packet number 1: The client sends an AS-REQ to the AS. The packet includes the headers below.
- pdata: It is called Pre-Authentication data. The client inserts a time stamp here and encrypt it with the client password. The goal is to avoid replay attacks. From screenshot below, it can be seen this value is empty in the packet number 1.
- cname: It contains the user(client) name to be authenticated.
- realm: It is the domain name.
- sname: This field contains the service name being requested.
- till: It includes the requested expiration time of the ticket being requested.
- etype: The encryption types that client supports.
Packet number 2: Since the client did not include the Pre-Authentication data, AS replies with an error code, asking for Pre-Authentication data.
Packet number 3: The client reconstructs an AS-REQ with Pre-Authentication data this time and sends it to the AS. The following output marked with blue color shows decrypted Pre-Authenticated data which contains a timestamp.
Packet number 4: The AS replies with an AS-REP packet. The packet contains an encrypted TGT and a session key. As it is seen below, since the TGT is encrypted with AS master key, the client is not be able to decrypt it. Wireshark marks unencrypted packet with yellow color while showing the decrypted parts with blue color. The client decrypts the session key with its password.
Packet number 5: After receiving the TGT, the clients make a request (TGS-REQ) to TGS. The request contains TGT and an authenticator which is encrypted with the client’s session key. With this request, the client asks the server for a service ticket. When the TGS receives the request, it decrypts the TGT with master key shared with AS.
Packet number 6: The TGS construcs a service ticket and encrypts it with another secret key which is shared between TGS and the File Server. The service ticket includes information such as service name, client id, expiry date, a new session key, the client’s address etc. One copy of the new session key is encrypted with client’s session key and inserted into the reply.
Kerberos authentication presents several advantages over other network authentication methods.
- Kerberos support is built in to all major computer operating systems, including Microsoft Windows, Apple macOS, FreeBSD and Linux.
- Tickets in Kerberos have a limited period. If the ticket gets stolen, it is hard to reuse the ticket because of strong authentication needs.
- Passwords are never sent over the network.
- Both sides (Client and Server) mutually authenticate each other through the protocol.
Overall, the strong cryptography and third-party ticket authorization make it much more difficult for attackers to break the authentication. We can not say it is impossible to break but once a flaw has found, we must know how the protocol works before introducing new measures.