[Network Security] Graphical Kerberos: Identity Authentication

Kerberos is an identity authentication protocol that is widely used in the big data ecosystem, and can even be said to be the de facto standard for big data identity authentication. This article will explain the Kerberos principle in detail.

1. What is Kerberos?

The word Kerberos comes from Cerberus in ancient Greek mythology - the three-headed dog guarding the gates of hell. The figure below is the Kerberos logo.

In a word, Kerberos is an authentication protocol based on encrypted Ticket. Kerberos mainly consists of three parts: Key Distribution Center (KDC) , Client and Service . The approximate relationship is shown in the figure below:

The client will first access the KDC twice, and then access the target Service, such as: HTTP service.

2. Basic concepts of Kerberos

2.1 Basic concepts

(1) Principal : It can be roughly regarded as the user name in the Kerberos world, which is used to identify the identity. PrincipalIt mainly consists of three parts:primary,instance(optional) andrealm.

• instanceThose that include Principalare generally used as Serverthe terminal Principal, such as: NameNode, HiverServer2, Presto Coordinator, etc.
• Those that do not contain instanceare Principalgenerally used as Clientthe terminal Principalfor identity authentication.

(2) Keytab : password book. A file containing multipleprincipalpasswords and passwords that users can use for authentication.

(3) Ticket Cache : After the client interacts with the KDC, the file containing identity authentication information is valid for a short period of time and needs to be continuedrenew.

(4) Realm : One of the Kerberos systemsnamespace. Different Kerberos environments canrealmbe distinguished by .

2.2 KDC

Key Distribution Center (KDC) , the core component of Kerberos, mainly consists of three parts:

• Kerberos Database : Contains all Principals, passwords and other information in a Realm. (Default: BerkeleyDB)
• Authentication Service (AS)Ticket Granting Tickets : Perform user information authentication and provide (for the clientTGT.
• Ticket Granting Service (TGS) : Verify TGT and Authenticator, provided for the clientService Tickets.

3. Kerberos principle

Before understanding the principles of Kerberos in depth, let me introduce several major premises of the Kerberos protocol to help you understand:

• Kerberos implements authentication based on tickets, not passwords. If the client cannot use the local key to decrypt the encrypted Ticket returned by the KDC, the authentication will fail.
• The client will interact with the Authentication Service, Ticket Granting Service and the target Service in turn, a total of three interactions.
• When the client interacts with other components, it will obtain two pieces of information, one of which can be decrypted by the local key, and the other cannot be decrypted.
• The target service that the client wants to access will not directly interact with the KDC, but will be authenticated by whether it can correctly decrypt the client's request.
• KDC Database contains passwords corresponding to all Principals.
• The information encryption method in Kerberos is generally symmetric encryption (can be configured as asymmetric encryption).

Below, we will take the client access HTTPservice as an example to explain the entire authentication process.

3.1 Client and Authentication Service

In the first step, the client passes kinit USERNAMEthe client ID , the target HTTP service ID , the network address (it may be a list of IP addresses of multiple machines, and may be empty if you want to use it on any machine), and TGT Information such as the lifetime of the validity period is sent to Authentication Service.

In the second step, Authentication Server will check whether the client ID is in the KDC database.

If the Authentication Server check operation is normal, then KDC will randomly generate a Key for the client to communicate with Ticket Granting Service (TGS). This Key is generally called TGS Session Key . Authentication Server will then send two messages to the client. The schematic diagram is as follows:

One of the messages is called TGT , which is encrypted by the key of TGS and cannot be decrypted by the client, including client ID , TGS Session Key and other information.

The other message is encrypted by the client key, and the client can decrypt it normally, including the target HTTP service ID , TGS Session Key and other information.

In the third step, the client uses the local key to decrypt the second message. If the local key cannot decrypt the information, then the authentication fails. The schematic diagram is as follows:

3.2 Client and Ticket Granting Service

At this time, the client has TGT (because there is no TGS key locally, its data cannot be decrypted) and TGS Session Key .

In the fourth step, the client will:

• Forward the TGT (encrypted by the TGS key) sent by the AS to the TGS.
• Send the Authenticator (encrypted by TGS Session Key) containing its own information to TGS.

In the fifth step, TGS will use its own key to decrypt the TGS Session Key from the TGT , and then use the TGS Session Key to decrypt the client's information from the Authenticator.

After TGS decrypts all the information, it will conduct identity check and authentication:

• Compare the client ID with the TGT's client ID.
• Compare the timestamp from the Authenticator with the TGT's timestamp (typical tolerance for Kerberos systems is $2$ minutes, but can also be configured separately).
• Check if the TGT has expired.
• Check whether the Authenticator is already in the TGS cache (in order to avoid replay attacks).

When all checks are passed, TGS randomly generates a Key for communication encryption when the client interacts with the HTTP service, that is, the HTTP Session Key . Similarly, TGS will send two pieces of information to the client: one is HTTP Ticket, which is encrypted by the HTTP service key; the other is encrypted by TGS Session Key, which contains client information and time stamp.

In the sixth step, the client will use the TGS Session Key to decrypt one of the messages, and the other message cannot be decrypted because it is encrypted by the target HTTP service.

3.3 Client and HTTP Service

At this time, the client has the HTTP Ticket (because there is no key for the HTTP service locally, its data cannot be decrypted) and the HTTP Service Session Key .

In the seventh step, the client will:

• Forward the HTTP Ticket (encrypted by the HTTP key) sent by TGS to the target HTTP service.
• Send the Authenticator containing its own information (encrypted by the HTTP Service Session Key) to the HTTP service.

Note : In the above picture, the Ticket for HTTP Service should be installed with the HTTP Service Session Key, not the TGS Session Key. There is a small mistake, pay attention to the screening.

In the eighth step, the HTTP service first uses its own key to decrypt the HTTP Ticket information to obtain the HTTP Service Session Key; then, uses the HTTP Service Session Key to decrypt the user's Authenticator information.

After the information is decrypted, the HTTP service also needs to do some information checks:

• Compare the client ID in the Authenticator with the client ID in the HTTP Ticket.
• Compare the timestamp from the Authenticator with the timestamp of the HTTP Ticket (typical Kerberos systems have a tolerance for differences of $2$ minutes, but can also be configured separately).
• Check whether the Ticket has expired.
• Check if the Authenticator is already in the HTTP server's cache (to avoid replay attacks).

The HTTP service then sends an authenticator message containing its ID and a timestamp to confirm its identity to you, encrypted with the HTTP Service Session Key.

Your machine reads the authenticator message by decrypting it with the cached HTTP Service Session Key and knows it must receive the message with the HTTP Service ID and timestamp.

You are now authenticated to use the HTTP service. Future requests will use the cached HTTP Service Ticket as long as it has not expired as defined in the lifetime property.

---

The reference is as follows:

• Explain like I’m 5: Kerberos
• Introduction To Kerberos
• Get Kerberos in one article