About Kerberos-based Windows Network Authentication [Part II]

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 article, I have been emphasizing the following principle:Data encrypted with a Long-term Key of an Entity cannot 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 three Sub-protocols, the Ticket carried by the Client isServer Master KeyEncryption, which does not conform to our principles and reduces 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 first Sub-protocol of Kerberos that we will introduce today:User2User Protocol. 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, the encrypted Ticket is only used between the Server and KDC.Session Key (SKDC-Server ).

We know that the Client obtains the Server access Ticket from KDC through The TGT obtained in the AS Exchange stage. The original Ticket isMaster Key of the ServerAnd the Master Key can be obtained through the Account Database. But now, KDC needs to useSKDC-ServerAnd KDC does not maintain the Session Key.This 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). For the Server, it can useAS ExchangeObtain the Session Key (SKDC-Server) And a Session Key encapsulated andTGT for KDC Master Key encryptionOnce 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.

Related content:
[Original] about Kerberos-based Windows Network Authentication-Part I
[Original] about Kerberos-based Windows Network Authentication-Part II
[Original] about Kerberos-based Windows Network Authentication-Part III

Author: Artech
Source: http://artech.cnblogs.com
The copyright of this article is shared by the author and the blog Park. You are welcome to repost this article. However, you must retain this statement without the author's consent and provide a clear link to the original article on the article page. Otherwise, you will be held legally liable.