Whether we’re talking about ordinary customers or the business world as a whole, cybercrime is an awful reality these days. There is no such thing as a safe corporation or organization, and the situation is unlikely to improve very soon. Experts estimate that cybercrime will cost the world $6.1 trillion by 2021. As if that weren’t awful enough, Forbes forecasts that an increasing number of cybercriminals will scale their attacks using Artificial Intelligence (AI).
These and other predictions speak to the unpleasant fact that cybercrime is here to stay, and the problem will only worsen. As a result, the digital world is eager to discover and implement new cyber security techniques.
Today, we’ll look at authentication mechanisms, specifically Kerberos. Let’s take a look behind the curtain and get to know this useful network protocol.
Let’s start with the basics and learn what Kerberos is and how it works.
Kerberos is a computer network security protocol that authenticates service requests across an untrusted network, such as the internet, between two or more trustworthy hosts. It authenticates client-server applications and verifies users’ identities using secret-key cryptography and a trusted third party.
Microsoft Windows’ default authentication technique is Kerberos. In the late 1980s, the Massachusetts Institute of Technology (MIT) developed it for Project Athena. Kerberos is supported by a variety of operating systems, including Apple OS, FreeBSD, UNIX, and Linux. Microsoft first released Kerberos in Windows 2000, and it has since become the industry standard for websites and single sign-on solutions on a variety of platforms. The protocol is named after the three-headed Greek legendary hound Kerberos (also known as Cerberus), who guarded the underworld’s entrance. Kerberos had a serpent tail and an especially terrible temper, yet he was a highly useful guardian, with one significant exception.
The three heads of Kerberos, on the other hand, represent the client, the server, and the Key Distribution Center in the protocol (KDC).The latter acts as a trustworthy third-party authentication source. Kerberos users, computers, and services rely solely on the KDC, which is a single process that performs two functions: authentication and ticket issuance. KDC “tickets,” which allow nodes to securely validate their identities, benefit all parties. Kerberos authentication protects communications from eavesdropping and replay (or playback) attacks by using traditional shared secret cryptography to prevent packets from being read or changed as they travel across the network. Now that we’ve understood what Kerberos is, let’s look at what Kerberos is utilized for.
What is the purpose of Kerberos?
Kerberos is used extensively on secure systems that rely on dependable auditing and authentication features, despite its widespread use in the digital world. Posix authentication, Active Directory, NFS, and Samba all use Kerberos. It’s also an option to SSH, POP, and SMTP for authentication.
Let us now study the Kerberos protocol flow as part of our understanding of what Kerberos is.
Overview of the Kerberos Protocol.
By breaking down Kerberos authentication into its essential components, we can have a better understanding of what it is and how it operates.
The following are the main players in a typical Kerberos workflow:
Client. The client communicates with the server for a service request on behalf of the user.
Authentication Server is the server that hosts the service that the user wishes to utilize (AS).
The AS is in charge of completing the required client authentication. If the authentication is successful, the AS issues a TGT ticket to the client (Ticket Granting Ticket).
This ticket ensures that the client is authenticated by the other servers’ Key Distribution Center (KDC). The authentication server in a Kerberos system is logically divided into three parts.
database (DB), an authentication server (AS), and a ticket-granting server (TS) (TGS). These three components are housed in the Key Distribution Center Ticket Granting Server, which is a single server (TGS). The TGS is a service-oriented application server that generates service tickets.
Let’s have a look at the protocol flow.
In the Kerberos flow, there are three critical secret keys involved. The client/user, the TGS, and the server all have their own secret keys that are shared with the AS. TGS secret key hash obtained from the user’s password The password hash is used to generate the TGS Server secret key. The password hash is used to find the server that provides the service.
The following are the steps in the protocol flow:
1. Authentication request from the client.
The user requests from the authentication server a Ticket Granting Ticket (TGT) (AS). The client ID is included in this request.
2. KDC checks the credentials of the client.
The AS looks up the client’s and TGS’s availability in the database. If both values are found, the AS produces a client/user secret key using the user’s password hash.
The AS then generates a session key (SK1) that is encrypted using the TGS secret key and the client/user secret key. The AS then generates a TGT including the client ID, network address, timestamp, lifetime, and SK1 data. The TGS secret key is then used to encrypt the ticket.
3. The message is decrypted by the client.
The client decrypts the message with the client/user secret key and extracts the SK1 and TGT, resulting in the authenticator that validates the client’s TGS.
4. The client submits a request for access via TGT.
By delivering the extracted TGT and the constructed authenticator to TGS, the client requests a ticket from the server providing the service.
5. The KDC generates a file server ticket.
The TGS then decrypts the TGT received from the client with the TGS secret key and retrieves the SK1. The TGS decrypts the authenticator and compares it to the client ID and network address to verify if it matches. The retrieved timestamp is also used by the TGS to ensure that the TGT hasn’t expired.
The KDC generates a service session key (SK2) that is shared between the client and the target server if the process passes all of the checks.
Finally, the KDC creates a service ticket that includes the client’s id, network address, timestamp, and SK2 data. The server’s secret key is then acquired from the database and used to encrypt the ticket. The service ticket and the SK2, all encrypted with SK1, are sent to the client as a message.
6. The client authenticates using the file ticket.
The client decrypts the message with SK1 and extracts SK2. This step creates a new authenticator using the client network address, client ID, and timestamp encrypts it with SK2 and delivers it to the target server along with the service ticket.
7.Decryption and authentication are sent to the target server.
The target server decrypts the service ticket and extracts the SK2 using the server’s secret key. The server decrypts the authenticator with SK2, running tests to ensure that the authenticator’s client ID and network address match the service ticket’s. The server also checks to determine if the service ticket has expired.
When the checks are completed, the target server sends a message to the client confirming that the client and server have successfully authenticated each other. A secure session is now available to the user.
Average Rating