Introduction to Kerberos Authentication principles and kerberos Authentication principles

Introduction to Kerberos Authentication principles and kerberos Authentication principles

1.1 What is Kerberos

1.1.1 Introduction
Kerberos is a protocol used to authentication. It uses symmetric key encryption, which means that the key will not be transmitted over the network. In Kerberos, unencrypted passwords are not transmitted over the network. Therefore, attackers cannot steal users' passwords through sniffing networks.

Kerberos uses symmetric encryption and trusted third parties (KDC, key distribution center) to identify users who require network services. All hosts managed by KDC and secondary KDC constitute a domain (realm ).

After a user's identity passes KDC authentication, KDC will send a certificate/ticket to the user (the Certificate/ticket is bound to this session ), other authenticated services will search for the ticket on the user's host, instead of asking the user to use the password to verify his identity.
1.1.2 concepts about Kerberos
Principal
A user is authenticated by KDC as a unique identity, which is called principal. A Principal consists of three parts: primary, instance, and realm. The composition form is primary/instance @ realm.
Primary: it can be the username or service name in the OS;
Instance: used to distinguish multiple principals belonging to the same user or service. This parameter is optional;
Realm: similar to the domain in DNS, it defines a set of principals.
1.1.3 authentication process
1. After a user logs on to his workstation in a kerberos-aware network, the authentication server will send a TGT request (a request for a ticket-granting ticket) to the KDC ), and his principal will be part of it. This request can be sent by the login program (this process is transparent to the user), or by running kinit after the user logs on.

2. KDC checks the pricipal in its database.

3. If the principal is found, KDC creates a TGT, encrypts it with the user key, and then sends the encrypted TGT to the user. Here, the user key is not the user password, but calculated by the user password (such as hash ).

4. the logon program or kinit program of the Kerberos client of the user's host uses the user key to decrypt the encrypted TGT. The user key will only be used on the client host and will never be transmitted over the network. The ticket sent by KDC will be saved in a local file (credentials cache), which can be checked by the authenticated services.

5. After the user's identity authentication is complete, the servers (running the authenticated applciations & services) can check the identified principals and their keys (which will be saved in the keytab ), you do not need to use kinit for checking.

TGT has a configurable expiration time (usually 10 ~ 24 hours), which will be stored in the credential cache of the host Where the client is located. Before ticket expires, the user does not need to enter the user password again when requesting the services of the authenticated services, unless they log out and then log on.

Whenever a user needs to access a network service, the client will use TGT to request a new ticket for the specific network service from the ticket-granting server. Then, you can use the service ticket to implement authentication for the network service.
1.1.4 How Kerberos works
KDC is a trusted third party (trusted third party arbitrator). KDC runs two important Kerberos daemons, namely, kadmind and krb5kdc.
Kadmind: This is the process for managing the Kerberos server. A program named kadmin uses kadmind to maintain the principal database and policy configuration.
Krb5kdc: Responsible for trusted third party arbitrator during Kerberos authentication.

1.2 authentication principles
1.2.1 knowledge preparation
To make it easier for readers to understand, here we first give two important concepts:
Long-term Key/Master Key: In the Security field, some keys may remain unchanged for a Long time.
For example, your password may not change for several years. Such a Key and the derived Key are called Long-term keys. The use of Long-term keys follows the principle that data encrypted by Long-term keys should not be transmitted over the network. The reason is very simple. Once these Long-term Key-encrypted packets are intercepted by malicious network listeners, in principle, as Long as there is sufficient time, he can obtain your Long-term Key for encryption through computation-no encryption algorithm can be absolutely confidential.

Generally, for an Account, the password is limited to the owner of the Account. Even for Administrator of any Domain, the password should be kept confidential. However, passwords are creden for identity verification. Therefore, you must use the derived information of your password to prove your real identity. In this case, generally, you can obtain a Hash code by performing a Hash operation on your password. Generally, such a Hash Code is called the Master Key. Hash Algorithm is irreversible, and the password and Master Key are one-to-one matched. This ensures the confidentiality of your password, at the same time, ensure that your Master Key and password have the same effect when proving your identity.
Short-term Key/Session Key: data packets encrypted by Long-term Key cannot be transmitted over the network, therefore, we use another Short-term Key to encrypt the data to be transmitted over the network. Because this Key is valid only for a period of time, even if the encrypted data packet is intercepted by hackers, the Key has expired long before it is computed.
1.2.2 detailed authentication principles
Kerberos is actually a Ticket-based authentication method. To obtain Server resources, the Client must first pass Server Authentication; the prerequisite for authentication is that the Client provides the Server with a Session Ticket (Session Key + Client Info) encrypted by a Master Key of the Server obtained from the KDC ). In this case, Session Ticket is a Ticket for the Client to enter the Server field. This Ticket must be obtained from a valid Ticket authority, which is a KDC trusted by both the Client and Server. At the same time, this Ticket has a powerful anti-counterfeit logo: it is encrypted by the Master Key of the Server. For the Client, obtaining Session Ticket is the most important part in the authentication process.
To better illustrate the entire Ticket Distribution process, I will make an analogy here. The stock market is very popular now. Shanghai is basically a nationwide stock market. I will give an example of the stock right certificate. Some listed companies will issue warrants to the public in case of stock allotment, additional issuance, fund expansion, and stock reduction. The holders of the warrants can subscribe to a certain number of shares of the company by virtue of the warrants, warrants are a financial derivative product with bullish options.
The process of obtaining Ticket from the Client today is similar to the process of purchasing a stock through the warrants. If we compare the Ticket provided by the Client to the Server for authentication to a stock, the Client needs to obtain the Ticket subscription certificate before obtaining the Ticket from the KDC, this warrant is called TGT: Ticket Granting Ticket in Kerberos, and The TGT distributor is still KDC.
Now let's take a look at how the Client obtains TGT from KDC: first, the Client initiates an application for TGT to KDC. The application content is roughly as follows: "I need a TGT to apply for a Ticket to access all servers ". After receiving the request, KDC generates a Session Key (SKDC-Client) for secure communication between the Client and KDC ). To ensure that the Session Key is only used by the Client and itself, KDC uses the Master Key of the Client and its Master Key to encrypt the generated Session Key, to obtain the Copy of two encrypted SKDC-Client. The latter, encrypted along with SKDC-Client, also contains information about the Client that will be used to identify the Client. Finally, KDC sends the two copies to the Client. Note: To avoid the trouble of KDC maintaining Session keys based on different clients, just as the Server does not save Session keys (SServer-Client, KDC does not save the Session Key (SKDC-Client), but selects the method provided by the Client.

Through the above process, the Client actually obtains two sets of information: one is the Session Key encrypted by the Master Key of the server, and the other is the data packet encrypted by the Master Key of the server, contains the Session Key and some confirmation information about yourself.

The Client decrypts the Session Key encrypted by KDC through its Master Key to obtain the Session Key. Then, it creates an Authenticator (Client Info + Timestamp) and encrypts it with the Session Key. Finally, the data packets (Client Info + Session Key) obtained from KDC and encrypted by the Master Key of the Server are sent to the Server. We call the data packet encrypted through the Master Key of the Server Session Ticket.
After the Server receives the two groups of data, it uses its Master Key to decrypt the Session Ticket to obtain the Session Key. Then, the Session Key is used to decrypt the Authenticator and Authenticator is authenticated by comparing the Client Info in Authenticator with the Client Info in Session Ticket.

1.2.3kafka authentication process
In summary, it is also very simple. When the Broker is started, you need to use the identity and key file in the configuration file to authenticate to the KDC (Kerberos server). If the authentication succeeds, you will join the Kafka cluster. Otherwise, an error will be reported and exited.
After the Producer (or Consumer) is started, follow these steps to establish a secure Socket connection with the Broker:
1. The Producer authenticates the identity to KDC and obtains the TGT (ticket request ticket) if it passes the authentication. Otherwise, an error is returned and exits.
2. The Producer uses TGT to request the Kafka service from KDC. KDC verifies the TGT and returns the SessionKey and ServiceTicket (service ticket) to the Producer)
3. producer uses SessionKey and ServiceTicket to establish a connection with the Broker. The Broker uses its own key to decrypt ServiceTicket and obtain the SessionKey that communicates with the Producer. Then, it uses SessionKey to verify the Producer's identity and establish a connection, otherwise, the connection is rejected.

Reprinted: http://www.cnblogs.com/xiaodf/p/5968086.html