Kerberos authentication process)

Http://blog.163.com/jobshot/blog/static/947091982008118105524719/

 

I. Basic Principles

Authentication solves the problem of "how to prove that a person is indeed the one he or she claims. For how to authentication, we adopt this method: If a secret exists only in A and B, then one person claims to B that he is, B asks a to provide this secret to prove that this person is the he or she claims. This process actually involves three important aspects about authentication:

• How to express secret.

• How does a provide secret to B.

• How B recognizes secret.

Based on these three aspects, we have simplified Kerberos authentication to the maximum extent: the entire process involves client and server. The secret between them is represented by a key (kserver-client. To enable the server to effectively authenticate itself, the client provides the following two groups of information to the other party:

• Information representing the client's own identity, which is transmitted in plaintext for convenience.

• Use the client identity as the public key and use symmetric encryption.Algorithm.

Because the kserver-client is only known to the client and server, the client identity encrypted by the client using the kserver-client can only be decrypted by the client and server. Similarly, the server first decrypts the two groups of information sent by the client through the kserver-client, and then compares the confidential data with the former. If they are the same, it can prove that the client can provide the correct kserver-client. In this world, only the real client and the user know the kserver-client, so the other party can be the one he claims.

In general, Keberos authenticates based on this principle. However, Kerberos is far more complex than this. I will continue to expand this process in the subsequent chapters to understand the real authentication process of Kerberos. To make it easier for readers to understand the subsequent sections, we will 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.

II. Introduction of Key Distribution: Where does kserver-client come from?

We have discussed the basic principles of Kerberos Authentication above: Let the authenticated party provide a key only known to him and the authenticated party to authenticate the real identity of the other party. The data packet encrypted by this key must be transmitted between the client and the server. Therefore, this key cannot be a long-term key, but may only be a short-term key, this can only be valid in a session between the client and the server. Therefore, we call this key the session key (sserver-client) between the client and the server ).

Now let's discuss how the client and server obtain the sserver-client. Here we will introduce an important role: Kerberos Distribution Center-KDC. KDC plays an important role in Kerberos authentication as a third party trusted by the client and server, and the Kerberos authentication process is completed through the collaboration between the three parties. By the way, Kerberos originated from Greek mythology. It is a goddog with three heads in the underworld. In Keberos authentication, the three heads of Kerberos represent the three sides involved in the authentication process: client, server, and KDC.

For a Windows domain, domain controller plays the role of KDC. KDC maintains an account database that stores all accounts in the domain (generally, this account database is maintained by AD), that is, he knows the name of each account and the master key generated in the account password. The sserver-client used for client and server mutual authentication has KDC distribution. Let's take a look at the KDC sserver-client distribution process.

We can see the simple process of KDC distributing sserver-Client: first, the client sends an application for sserver-client to KDC. This application can be summarized as "I Am a client, and I need a session key to access a server ". KDC generates a session key when receiving this request. to ensure that this session key is only known to the client sending the request and the server it wants to access, KDC generates two copies for the session key, which are used by the client and server respectively. Then, the master keys of the client and server are extracted from the account database to perform symmetric encryption on the two copies. For the latter, encrypted together with the session key also contains some information about the client.

KDC now has two session keys encrypted by the master key of the client and server respectively. How can these two session keys be obtained by the client and server respectively? Maybe you will immediately say that KDC can directly send these two encrypted packets to the client and server, but if you do so, the following two problems may occur to the server:

• Because a server faces several different clients, each client has a different session key. The server maintains a list of session keys for all clients. This is troublesome and inefficient for the server.

• Due to the uncertainty of network transmission, the client may quickly obtain the session key and send the session key as the credential to the server along with the access request, however, the session key used for the server has not yet been received, and it is likely that the session key that carries this session key will never reach the server end, and the client will never be authenticated.

To solve this problem, the Kerberos method is very simple. The two encrypted copies are sent to the client together, and the client that belongs to the server is sent to the server.

Some may ask If KDC does not actually authenticate the client sending the request to be the one he claims and sends the session key to him. Is there any problem? If another person (such as client B) claims that he is Client A, he will also get the session key of Client A and server. Is there any problem? In fact, there is no problem. Because client B claims that it is Client A, KDC uses the master key derived from the password of Client A to encrypt the session key, therefore, the party that truly knows the password of Client A will obtain the session key through decryption.

Iii. Introduce authenticator-provide evidence to prove Validity

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. Through section 1, we said that only a key known to both parties can be used to authenticate the other party effectively. However, in a network environment, this simple approach involves security vulnerabilities, the client must provide more proof information. We call this proof information authenticator, in Kerberos, authenticator is actually a timestamp about the client and the current time (I will explain the role of this security vulnerability and timestamp later ).

On this basis, let's take a look at how the server authenticates the client: the client decrypts the session key encrypted by KDC through its master key to obtain the session key, then the authenticator (Client info + timestamp) is created and encrypted 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.

Why use timestamp?

Many people think that the authentication process is seamless: Server authentication can be obtained only when the client provides the correct session key. However, in the real environment, this has a large security vulnerability.

We can imagine this phenomenon: a malicious network listener intercepts the data packets sent by the client to the server. The Listener then uses the data packets as their credential to impersonate the client to access the server, in this case, you can still successfully obtain the server's successful authentication. To solve this problem, the client adds a timestamp of the current time to the authenticator.

Before the server compares the Client info in authenticator with the Client info in session ticket, it extracts the timestamp in authenticator and compares it with the current time, if the deviation between them exceeds an acceptable time range (generally 5 mins), the server will directly reject the client's request. Here, you need to know that the server maintains a list that records all the authenticated clients and the authentication time in this acceptable time range. For clients whose time deviation is within this acceptable range, the server obtains the last authentication time of this client from this list, the server performs subsequent authentication only when the timestamp in authenticator is later than the latest authentication time of a client.

The importance of time synchronization

The above timestamp-based authentication mechanism is meaningful only when the client and server are synchronized. Therefore, maintaining time synchronization is particularly important throughout the authentication process. In a domain, you can synchronize the time by accessing the same time service to obtain the current time.

Mutual authentication)

One important advantage of Kerberos is that it provides two-way authentication: not only can the server authenticate the client, but also can the client authenticate the server.

The specific process is as follows. If the client needs to authenticate the server it accesses, it will set a flag for authentication in the credential it sends to the server. After the server successfully authenticates the client, it puts forward the timestamp in the authenticator and encrypts it using the session key. After the client receives and decrypts the data using the session key, if you confirm that the timestamp is exactly the same as the original one, you can determine that the server is the server he is trying to access.

So why does the server not directly send the authenticator encrypted through the session key to the client as it is, but extract the timestamp and send it encrypted to the client? The reason is to prevent malicious listeners from impersonating the server as the authenticator sent by the obtained client to obtain client authentication.

4. Introduce ticket granting service

Through the above introduction, we found that 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.

The above is just a simple description of the process in which KDC distributes ticket to the client. The real ticket distribution in Kerberos is more complex. 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.

After the client receives two KDC encrypted data packets, it first decrypts the first copy using its master key to obtain the session key (skdc-client) of the KDC and client ), and cache the session and TGT. With session key and TGT, the master key of the client will no longer be needed, because the client can then use skdc-client to apply for access to the ticket of each server from KDC, compared with the long-term key of the master key of the client, skdc-client is a short-term key, which ensures better security. This is also the key to Kerberos's additional step. At the same time, it should be noted that skdc-client is a session key with its own lifecycle, and TGT is associated with the session. When the session key expires, TGT becomes invalid, after that, the client has to apply for a new TGT from KDC. KDC will generate a different session key and a TGT associated with it. At the same time, because the client log off also leads to skdc-client failure, skdc-client is also called the logon session key.

Next, let's take a look at how the client uses TGT to obtain a server-based ticket from KDC. Here I want to emphasize that ticket is based on a specific server, while TGT is irrelevant to the specific server, the client can use a TGT to obtain ticket based on different servers from KDC. To put it bluntly, after obtaining the session key (skdc-client) of the client and KDC, the client generates its own authenticator and the name of the server to be accessed and uses skdc-client for encryption. Then it is sent to KDC together with TGT. KDC uses its master key to decrypt TGT, extracts Client info and session key (skdc-client), and then uses this skdc-client to decrypt authenticator to obtain Client info, compare the two Client info to verify the real identity of the other client. The verification is successful. A Ticket Based on the server accessed by the client is generated to the client. This process is the same as described in section 2.

5. Three sub-protocols of Kerberos: The entire Authentication

Through the above introduction, we have basically understood the entire Kerberos authentication process: the entire process includes the following three sub-processes:

1. The client applies for TGT (ticket granting ticket) from KDC ).

2. The client requests dkc to access the server's ticket by obtaining the TGT.

3. The client finally submits ticket to the server for authentication.

However, the above introduction is a little different from the real Kerberos authentication. Kerberos authentication is completed through three sub-protocols. The three sub-protocols complete the three sub-processes listed above. The three sub-Protocols are:

1. Authentication Service exchange

2. Ticket granting service exchange

3. Client/Server exchange

The message exchange that completes the three sub-protocols.

1. Authentication Service exchange

Through this sub-protocol, KDC (specifically the authentication service in KDC) can confirm the client identity and issue a TGT to the client. The specific process is as follows:

The client sends the authentication service request (krb_as_req) to the authentication service of KDC. To ensure that krb_as_req is only known to itself and KDC, the client uses its own master key to encrypt the main part of krb_as_req (KDC can obtain the master key of the client through the account database of the domain ). Krb_as_req generally includes the following content:

• Pre-authentication data: contains information used to prove your identity. To put it bluntly, it means that you know the password of the account you claimed. Generally, its content is a timestamp encrypted by the client's master key.

• Client name & realm: domain name \ Client

• Server Name: note that the server name here is not the name of the server that the client really wants to access, and we also say that TGT is irrelevant to the server (the client can only use ticket, instead of using TGT to access the server ). The server name here is actually the server name of the ticket granting service of KDC.

As (authentication service) uses the krb_as_req it receives to verify whether the sender is the one claimed in client name & realm, that is, to verify whether the sender knows the password of the client. Therefore, as only needs to extract the master key corresponding to the client from the account database to decrypt the pre-authentication data. If it is a valid timestamp, it can prove that the password provided by the sender and recipient is correct. After the verification is passed, as sends an authentication service response (krb_as_rep) to the client. Krb_as_req consists of the master key encrypted session key (skdc-Client: logon session key) of the client and the TGT encrypted by itself (kdc. TGT generally includes the following content:

• Session Key: skdc-Client: logon session key

• Client name & realm: domain name \ Client

• End Time: the time when TGT expires.

After the client decrypts the first part of the session key (skdc-Client: logon session key) through its master key, it can proceed to the next step with TGT: TGS (ticket granting service) exchange.

2. Tgs (ticket granting service) Exchange

TGS (ticket granting service) Exchange sends the ticket granting service request (krb_tgs_req) to the TGS (ticket granting service) in KDC through the client. Krb_tgs_req generally includes the following content:

• TGT: the client obtains ticket granting ticket through as exchange. TGT is encrypted by the master key of KDC.

• Authenticator: used to verify whether the TGT owner is himself. Therefore, it must be encrypted using the TGT Method and Its session key (skdc-Client: logon session key.

• Client name & realm: domain name \ Client.

• Server Name & realm: domain name \ Server. This is the server that the client is trying to access.

Before receiving krb_tgs_req from the client, the TGT provided by the entire client is issued to the client. Therefore, it must be proved by the authenticator provided by the client. However, the authentication is encrypted by using the logon session key (skdc-client), but the session key is not saved by yourself. Therefore, TGS must first decrypt the TGT provided by the client through its master key to obtain the logon session key (skdc-client), and then use this logon session key (skdc-client) decrypt the authenticator for verification. Verify that ticket granting service response (krb_tgs_rep) is sent to the recipient ). This krb_tgs_rep is composed of two parts: the session key (sserver-client) used for client and server is encrypted using the logon session key (skdc-client) and ticket encrypted using the master key of the server. The ticket includes the following content:

• Session Key: sserver-client.

• Client name & realm: domain name \ Client.

• End Time: The expiration time of ticket.

The client receives krb_tgs_rep and uses the logon session key (skdc-client) to decrypt the first part and then obtains the session key (sserver-client ). With the session key and ticket, the client can interact with the server without using KDC as the intermediary. Therefore, Kerberos is an efficient authentication method, which can be completed directly by both the client and server, unlike the NTLM authentication method in Windows NT 4, each authentication must be completed by a 3rd-party trusted by both parties.

Now let's take a look at how the client interacts with the server using ticket. In this phase, we use our 3rd sub-protocols to complete: CS (Client/Server) exchange.

3. CS (Client/Server) Exchange

This has already been introduced in section 2 of this article, and it is no longer cumbersome for repeated content. The client obtains the session key (sserver-client) of the client and server through TGS exchange, creates the authenticator used to prove that it is the real owner of the ticket, and uses the session key (sserver-client). Finally, the encrypted authenticator and ticket are sent to the server as application service request (krb_ap_req. In addition to the preceding two items, krb_ap_req also contains a flag to indicate whether the client needs mutual authentication (mutual authentication ).

After receiving krb_ap_req, the server decrypts ticket through its master key to obtain the session key (sserver-client ). Use the session key (sserver-client) to decrypt the authenticator, and then verify the identity of the other party. The verification is successful and the client is allowed to access the resources to be accessed. Otherwise, the request is rejected directly.

For two-way authentication, the server extracts timestamp from the authenticator, uses session key (sserver-client) for encryption, and sends it to the client to verify the server's identity.

Vi. user2user sub-Protocol: effectively safeguards server security

Through the introduction of three sub-protocols, we can fully master the entire Kerberos authentication process. In fact, in the Windows 2000 era, Kerberos-based Windows authentication is implemented according to this workflow. However, as I mentioned at the end of the previous section, Kerberos based on three sub-protocols has its own limitations and security risks as a network authentication. Throughout the entire articleArticleWe have been emphasizing the principle that data encrypted with a long-term key of an entity should not be transmitted over the network. The reason is very simple. All encryption algorithms cannot guarantee 100% security. decryption of encrypted data is only a process of time. The best way to ensure security is: use a short-term key (session key) instead of long-term key to encrypt the data, so that when a malicious user decrypts the key to obtain the encrypted key, the key has long expired. However, for C/S exchange of the three sub-protocols, the ticket carried by the client is encrypted by the server master key, which does not conform to our principle, reduce the Security Factor of the server.

Therefore, we must seek a solution to solve the above problems. This solution is obvious: a session key of short-term is used instead of the server master key to encrypt ticket. This is the 4th sub-Protocol: user2user protocol of kerberos that we will introduce today. We know that since it is a session key, only two parties are involved, and the entire Kerberos authentication process involves three parties: client, server, and KDC, therefore, only the session key (skdc-server) between server and KDC is used to encrypt ticket ).

We know that the client obtains the server access ticket from KDC through The TGT obtained in the as exchange stage. The original ticket is encrypted through the master key of the server, and the master key can be obtained through the account database. However, KDC uses the skdc-server between the server and KDC for encryption, but KDC does not maintain the session key. Therefore, the session key can only be provided by the client requesting ticket. Therefore, between as exchange and TGS exchange, the client must request the server to obtain the session key (skdc-server) between the server and KDC ). For the server, it can obtain the session key (skdc-server) between the server and KDC through as exchange like the client) and a TGT that encapsulates the session key and is encrypted by the master key of KDC. Once the TGT is obtained, the Server caches it for client requests. We will discuss this process in detail now.

Basically, the authentication process based on user2user is translated. This process consists of four steps. We found that compared with the authentication process based on the traditional three sub-protocol described in the previous section, this time we got to the 2nd sub-protocols. Let's simply go over it from start to end:

1. As exchange: the client obtains its own TGT through this process. With this TGT, the client can apply to KDC for access to a server's ticket.

2. The main task of this step is to obtain the TGT of the server that encapsulates the session key (skdc-server) of the server and KDC. If the TGT is stored in the server cache, the server returns it directly to the client. Otherwise, use as exchange to obtain data from KDC.

3. TGS exchange: the client provides KDC with its own TGT, server TGT, and authenticator to apply for a ticket to access the server. KDC uses its master key to decrypt the client's TGT to obtain the skdc-client, and uses the skdc-client to decrypt the authenticator to verify whether the sender is the real owner of The TGT, verify that the KDC and server session key (skdc-server) are obtained by decrypting the server TGT with the master key, and the session key is used to encrypt the ticket and return it to the client.

4. C/s exchange: the client uses the session key (skdc-server) of KDC and server to encrypt ticket and the session key (sserver-client) of client and server) the Authenticator accesses the server. The server decrypts ticket through the skdc-server to obtain the sserver-client, and decrypts the authenticator through the sserver-client to verify the client.

This is the entire process.

VII. Advantages of Kerberos

After analyzing the entire Kerberos authentication process, let's summarize the advantages of Kerberos:

1. High Performance

Although we have repeatedly said that Kerberos is a three-party authentication process: client, server, and KDC. However, once the client obtains a ticket that has been used to access a server, the server can verify the client based on the ticket without the re-involvement of KDC. Compared with the traditional Windows NT 4.0-based NTLM that fully relies on trusted third party, it has a great performance improvement.

2. Mutual authentication is implemented)

The traditional NTLM authentication is based on the premise that the remote service accessed by the client is credible and does not require verification. Therefore, NTLM does not provide a two-way authentication function. This is obviously idealistic. Therefore, Kerberos makes up for this deficiency: the client can perform authentication on the server's identity before accessing the server's resources.

3. Support for Delegation

Impersonation and delegation are two important functions in a distributed environment. Impersonation allows the server to use the Logon account locally to perform some operations. The delegation requires the server to bring the Logon account to another context to perform the corresponding operations. NTLM only supports impersonation, while Kerberos supports delegation through a bidirectional, deliverable (mutual, transitive) trust mode.

4. Interoperability)

Kerberos was first created by MIT and has now become a widely accepted standard for a row. Therefore, different platforms can perform extensive interoperability.