[Original] about Kerberos-based Windows Network Authentication-Part II

4. Introduce Ticket Granting Service

Through the above introduction, we found that Kerberos is actually based onTicket. To obtain Server resources, the Client must first pass Server Authentication. A prerequisite for authentication is that the Client provides the Server withMaster Key of the ServerEncryptedSession Ticket (Session Key + Client Info). In this case, Session Ticket is a Ticket for the Client to enter the Server field. The Ticket must be obtained from a valid Ticket authority.KDC trusted by both Client and ServerAt the same time, this Ticket has a strong security identifier: 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 shares to the public in case of stock allotment, additional issuance, fund expansion, and stock reduction.WarrantsThe holder of the warrants can use the warrants to subscribe to a certain number of shares of the company. The warrants are financial derivatives 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 in KerberosTGT: Ticket Granting TicketThe 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 can be roughly expressed as follows:"I need a TGT to apply for obtaining the Ticket used to access all servers.". After receiving the request, KDC generates a secure communication between the Client and KDC.Session Key (SKDC-Client). To ensure that the Session Key is only used by the Client and itself, KDCMaster Key of the ClientAndMaster KeyEncrypt the generated Session Key to obtain two encryptedSKDC-Client. For the latterSKDC-ClientEncrypted together, it also contains information about the Client that will be used to identify the Client. Finally, KDC sends the two copies to the Client. Note that, in order to avoid the trouble of KDC maintaining Session keys based on different clients, the Server will not saveSession Key (SServer-Client)Similarly, KDC will not save this Session Key (SKDC-Client.

When the Client receives two encrypted data packets from KDCMaster KeyDecrypts the first Copy to obtainSession Key (SKDC-Client)And cache the Session and TGT. With Session Key and TGT, the Master Key of the Client is no longer needed, because the Client can useSKDC-ClientApply to KDC for the Ticket used to access each Server. 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 adding Kerberos to this 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 calledLogon 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. Let's get down to the point where the Client obtains its own and KDCSession Key (SKDC-Client)Generate your own Authenticator and the name of the Server to be accessed and useSKDC-Client. Then it is sent to KDC together with TGT. KDC usageMaster KeyDecrypts TGT and extracts Client Info andSession Key (SKDC-Client)And then use thisSKDC-ClientDecrypt the Authenticator to obtain the Client Info, and 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_REQTo ensure that KRB_AS_REQ is only known to itself and KDC, the Client uses its 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 actuallyServer 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 a Ticket Granting Service Request (KRB_TGS_REQ. 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, Authentication is performed throughLogon Session Key (SKDC-Client)The Session Key is not saved. Therefore, the TGS must first decrypt the TGT provided by the Client through its Master Key to obtain the Logon Session Key (SKDC-Client ).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 consists of two parts:Logon Session Key (SKDC-Client)Encrypted for Client and ServerSession Key (SServer-Client)And useMaster Key of the ServerEncrypted Ticket. 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 usesLogon Session Key (SKDC-Client)ObtainSession 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 will use our 3rd Sub-protocols: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 obtainsSession Key (SServer-Client)Then create the Authenticator used to prove that you are the real owner of Ticket, and useSession 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.

So far, the whole process of Kerberos has been introduced. I wonder if they are aware of any security risks? When I first introduced Long-term Key and Short-term Key, I emphasized that it is best not to transmit the information encrypted by Long-term Key over the network, then the Ticket obtained by the Client from KDC is indeed encrypted through the Master Key of the Server, which is obviously insecure for the Server. To solve this problem, Kerberos introduces 4th Sub-protocols: user2User. For more information about User2User Protocol, see the third part of this Blog.

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.