About Kerberos-based Windows Network Authentication [Part 1]

Content:

Basic Principles
Introducing Key Distribution: Where does KServer-Client come from?
Introduce Authenticator: provide evidence to prove Validity
Introducing Ticket Granting Service: how to obtain Ticket
Three Sub-protocols of Kerberos:Entire Authentication process
User2User Protocol: effectively safeguards Server security
Advantages of Kerberos

A few days ago, when I explained how Windows uses Kerberos for Authentication, I told him not to understand the old man for a long time and almost wrapped myself in. There are two reasons for this: for a person who does not fully understand Kerberos, the entire Authentication process of Kerberos is really hard to understand-it will encrypt the Key later and encrypt it with another Key later, so it is very easy to confuse people; on the other hand, I have a problem with the method of explanation. From the very beginning, I have described the entire Authentication process from the three Sub-protocols of Kerberos, for a person who does not know Kerberos at all, the requirement is also a little higher. For this reason, I spent some time writing this article, trying to explain the Kerberos-based Windows Network Authentication in a simple, in-depth way, I hope this article will help those who are unknown about Kerberos. You are welcome to criticize and correct some mistakes.

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 can simplify Kerberos Authentication to the maximum extent: the whole process involves Client and Server, and the Secret between them we use 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 IdentityKServer-ClientAs a Public Key and uses symmetric encryption algorithms for encryption.

BecauseKServer-ClientOnly known to the Client and Server, the Client Identity encrypted by the Client using KServer-Client can only be decrypted by the Client and Server. Similarly, the Server receives the two groups of information sent by the Client, first throughKServer-ClientDecrypt the latter, and then compare the confidential data with the former. If they are the same, it can prove that the Client can provide the correctKServer-ClientIn this world, only the real Client and yourself knowKServer-ClientSo 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 needs to be transmitted between the Client and the Server, so this Key cannot beLong-term KeyAnd onlyShort-term KeyThis can only be valid in one Session of the Client and Server. Therefore, we call this Key the Session Key between the Client and Server (SServer-Client).

Now let's discuss how the Client and Server get thisSServer-Client. Here we want to 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 ControllerAssume the role of KDC. KDC maintainsAccount Database(Generally, this Account Database is composedADIn other words, he knows the name of each Account andMaster Key. Used for mutual authentication between Client and ServerSServer-ClientKDC distribution is available. Next let's take a look at KDC DistributionSServer-Client.

We can see the simple process of KDC distributing SServer-Client: first, the Client sends an application for SServer-Client to KDC. The content of 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 evidentiary information.AuthenticatorIn Kerberos, Authenticator is actuallyClient InformationAnd the current timeTimestamp(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 passesMaster KeyDecrypt the Session Key encrypted by KDC to obtainSession KeyAnd then createAuthenticator (Client Info + Timestamp)AndSession KeyEncrypt it. Finally, together withMaster Key of the ServerEncrypted data packets (ClientInfo + Session Key) And sent to the Server. We call the data packets encrypted through the Master Key of the ServerSession Ticket.

When the Server receives the two groups of data, useMaster KeyDecrypt Session Ticket to obtainSession Key. Then useSession KeyDecryptionAuthenticator, Through comparisonClient Info in AuthenticatorAndClient Info in Session TicketTo authenticate the Client.

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: the data packet sent by the Client to the Server is intercepted by a malicious network listener, and the listener then impersonates the Credential of the data packet to access the Server, in this case, you can still successfully obtain the Server's successful authentication. To solve this problem, the ClientAuthenticatorWill be added toTimestamp.

Before the Server compares the Client Info in Authenticator with the Client Info in Session TicketTimestamp, AndCurrent TimeFor comparison, if the deviation between them exceeds oneAcceptable time range (generally 5 mins ),The Server directly rejects the request from the Client. 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 will obtain from this listThe last authentication time of the Client., Only whenThe Timestamp in Authenticator is later than the last authentication time of a Client.In this case, the Server adopts the subsequent authentication process.

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 DomainTime ServiceTo synchronize 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 confirmTimestampIt is exactly the same as the original one, so he can identify 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.

About Kerberos-based Windows Network Authentication-Part II

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