[Reprint]kerberos Authentication principle

A few days ago in explaining how Windows was authentication through Kerberos, it was a long time to talk about the man and almost put himself in. Then think of the following two points: for a person who does not fully understand Kerberos, the whole authentication process of Kerberos does not really understand--a moment to encrypt this key, and then another key to encrypt it, It is really easy to stun people, on the other hand, I have a problem with the way of explaining the whole authentication process from the 3 sub-protocol of Kerberos from the beginning, which is a bit higher for a person who does not understand Kerberos at all. To this end, I spent some time writing this article, as far as possible, in a deep, layered way to tell me what I understand the Kerberos-based Windows Network authentication, Hopefully this article will help those who are unaware of the Kerberos message. For some of the wrong places, you are welcome to criticize.

First, the basic principle

Authentication solves the problem of "how to prove that someone is really who he or she claims to be." For how to do authentication, we use this approach: if a Secret (secret) exists only in A and B, then there is a person who claims to B that he is a, a, or a, by giving the A a secret to prove that the person is the a he or she claims to be. This process actually involves 3 important aspects of authentication:

• Secret how to express.
• A how to provide secret to B.
• b How to identify secret.

Based on these 3 aspects, we minimize the Kerberos authentication: The entire process involves the Client and server, the secret between them we use a key (kserver-client ) to indicate. In order for the server to authenticate itself effectively, the client provides the following two sets of information to the other party:

• Information that represents the identity of the client, and is transmitted in clear text for simplicity.
• Use kserver-client as the public Key for the Client's identity and encrypt it with a symmetric encryption algorithm.

Since kserver-client is only known to the client and server, the client identity that the client uses Kserver-client encrypted can only be decrypted by client and server. Similarly, the server receives the two sets of information sent by the Client, which is decrypted by kserver-client , then compares the confidential data with the former, and if it is identical, proves that the client can provide the correct Kserver-client, and in this world, only the real Client and himself know kserver-client, so can the other party is the person he claimed.

Keberos is generally based on such a principle to authentication. But Kerberos is far more complicated than this, and I will continue to expand this process in subsequent chapters to know the Kerberos real authentication process. To make it easier for the reader to understand the following sections, here we first give two important concepts:

• long-term Key/master key: In the realm of security, some key may remain constant for a long time, such as you in the password, may not change for several years, such a key, and the derived key is called long-term key. There is a principle for the use of long-term key: data that is encrypted by long-term key should not be transmitted over the network. The reason is simple, once these long-term key encrypted packets are intercepted by a malicious network listener, in principle, as long as there is sufficient time, he can be calculated to obtain the long-term key you use for encryption-any encryption algorithm is impossible to achieve absolute secrecy.

In general, for an account, the password is often limited to the owner of the account, and even for any domain administrator, the password should remain confidential. But the password is to prove the identity of the credentials, so must be based on your password derived information to prove the true identity of the user, in this case, generally your password hash operation to get a hash code, we generally control such a hash code is called Master Key. Because the hash algorithm is irreversible, while ensuring that the password and master key is one by one corresponding, so that both the confidentiality of your password, but also to ensure that your master key and the password itself in the proof of your identity has the same effect.

• Short-term key/session key: Because packets encrypted by long-term key cannot be used for network transfer, we use another short-term key to encrypt the data that needs to be transmitted over the network. Since this key is only valid for a period of time, even if the encrypted packet is intercepted by a hacker, the key has already expired when he calculates the key.

Second, the introduction of key distribution:kserver-client from where

Above, we discuss the basic principle of Kerberos authentication: to authenticate a person's true identity by providing the authenticated party with a key that is only known to him and the authenticator. The packet encrypted by this key needs to be transferred between the client and the server, so this key cannot be a long-term key, but it may be short-term key. This can only work in a session of the client and server, so we call this key the session key between the client and server (sserver-client).

Now let's talk about how the Client and server get this sserver-client. Here we are going to introduce an important role:Kerberos distribution CENTER-KDC. The KDC plays an important role in the entire Kerberos authentication as a third party that trusts both client and server, and the authentication process for Kerberos is done through these 3-party collaborations. By the way, Kerberos originated in Greek mythology, a god dog guarding the underworld with 3 heads, and in Keberos authentication, 3 heads of Kerberos represent the 3 parties involved in the certification process:Client, Server and KDC.

For a Windows domain, theDomain Controller plays the role of the KDC. The KDC maintains an account databasethat stores all the accounts in the domain (typically, it is maintained by AD ), i.e., He knows the name belonging to each account and the Master Keyderived from the account password. The sserver-client for mutual authentication between Client and server is a KDC distribution. Let's look at the process by which the KDC distributes sserver-client .

We can see the simple process by which the KDC distributes sserver-client: First the client sends a request to the KDC for sserver-client. The content of this application can be briefly summed up as "I am a client, I need a session key to access a server ". When the KDC receives this request, it generates a session key, in order to ensure that the session key is limited to the client sending the request and the server he wants to access, the KDC generates two copy for the session key. Used by client and server, respectively. Then extract the client from account database and the server's master key to encrypt each of the two copy symmetrically. For the latter, encrypted with session key also contains some information about the client.

The KDC now has two session keys that have been encrypted by the client and server master key, and how are the two session keys obtained by client and server respectively? You may soon say that the KDC directly sends these two encrypted packets to the client and server, but if you do, the following two questions will appear for the server:

• Because one server faces several different clients, each client has a different session Key. Then server will maintain a list of such a session key for all clients, which is cumbersome and inefficient for the server.
• Due to the uncertainty of network transmission, it may occur that the client quickly obtains session key and sends the session key as credential with the access request to the server, but the session for server Key has not received, and it is likely to host this session key will never go to the server side, the client will never be certified.

To solve this problem, the Kerberos approach is simple, and the two encrypted copy is sent to the client, and the copy of the server is sent to the server by the client.

One might ask if the KDC is not really authenticating the client that sent the request, is it really the person he claims to be, and sending the session key to him, will there be any problems? If another person (such as client B) claims to be client A, he will also get the session Key for client A and server, would that be a problem? In fact, there is no problem, because client B claims that it is client A,KDC will use the password derived master key of client A to encrypt session key, so we really know that client a Password's party will be decrypted to get session Key.

Iii. introduction of Authenticator- providing evidence for effective proof of self

Through the process above, the client actually obtains two sets of information: A session key that is encrypted by its master key, and a packet encrypted by the sever master key that contains the session key and some confirmation information about itself. Through the first section, we say that as long as a mutual known key can be effective authentication, but in a network environment, this simple practice is a security vulnerability, for this reason, the client needs to provide more proof information, we call this proof information Authenticator, Authenticator in Kerberos is actually some information about the client and a Timestamp of the current time (I'll explain later on this security vulnerability and timestamp).

On this basis, let's look at how the server authenticates the client: the client decrypts the session key encrypted by the KDC via its master key to get session key, Then create Authenticator (Client Info + Timestamp) and encrypt it with Session Key . Finally, the data packets (Client Info + Session Key) obtained from the KDC and encrypted by the server's master key are sent to the server side. We call the Session TicketA packet that has been encrypted through the server's master key.

When the server receives these two sets of data, the session ticket is decrypted using his own master key to obtain session Key. The session Key is then used to decrypt the Authenticatorby comparing the client Info and Session in the Authenticator Client Info in ticket to enable client authentication.

Why use timestamp?

Here, many people may think that this certification process is seamless: only when the client provides the correct session key to get the server certification. But in the real world, there is a big security hole in it.

Let's think of this phenomenon: the packet sent by the client to the server is intercepted by a malicious network listener who then passes the packet seat's own credential impersonate the client to access the server, in which case Successful authentication of the server can still be achieved smoothly. To solve this problem, the client adds a current time Timestampto the Authenticator .

Before the server compares the client info in client info and session ticket in authenticator, the Timestampin authenticator is extracted and The current time is compared, and if the deviation between them exceeds an acceptable time range (typically 5mins),the server rejects the client request directly. What you need to know here is that the server maintains a list of all the client and authentication times that are authenticated within this acceptable time frame. For the time skew in this acceptable range, Client,server will get the most recent authentication time for the client from this list, only if Authenticator in timestamp is later than the last authentication time through a client , the server uses the subsequent authentication process.

The importance of time synchronization

The above timestamp-based authentication mechanism only makes sense if the client and server are synchronized at the time. So keeping time synchronization is especially important throughout the certification process. In a domain, synchronization of time is generally achieved by accessing the same time Service to obtain the current times.

Bidirectional authentication (Mutual authentication)

An important advantage of Kerberos is its ability to provide two-way authentication: Not only the server can authenticate the client, but the client can also authenticate the server.

The process is this, if the client needs to authenticate the server he accesses, it will set a flag that requires authentication in the credential it sends to the server. After the server has successfully authenticated the client, the timestamp in authenticator will be put forward and encrypted by session key, and when the client receives and decrypts with session key, if it confirms Timestamp is exactly the same as the original, then he can assume that the server formally tries to access the server.

So why does the server not directly to the session key to encrypt the authenticator is sent to the client, but to timestamp extracted out of the encryption sent to the client? The reason for this is to prevent a malicious listener from acquiring client authentication by impersonating the server with the authenticator sent by the client.


Iv. introduction of Ticket granting Service

With the introduction above, we find that Kerberos is actually a Ticket -based authentication method. The client wants to obtain server-side resources, first through the server authentication, and the prerequisite is that the client provides the server with a server-acquired master Key to encrypt the Session Ticket (Session Key + Client Info). So to speak, Session ticket is a ticket to the client entering the server field. And this ticket must be obtained from a legitimate ticket authority, which is the KDC trusted by both client and server, and this ticket has an ultra-strong security identity: it is encrypted by the server's master key. For the client, getting session ticket is the most critical part of the entire certification process.

Above, we simply illustrate the process by which the KDC distributes ticket to the client, and the ticket distribution that really is in Kerberos is more complex. In order to better illustrate the whole process of ticket distribution, I am here to make an analogy. Now the stock is very hot, Shanghai is basically a stock of stocks, I would like to cite an example of warrants. Some listed companies will issue warrants to the public in the case of shares allotment, additional issuance, fund expansion, share reduction and so on, the holder of warrants may subscribe a certain number of shares of the company by virtue of this warrant, which is a financial derivative product with call option.

And the process that we are talking about today as a client gets ticket is similar to the process of buying shares through warrants. If we compare the ticket that the client provides to the server for authentication to the stock, then the client needs to obtain this ticket subscription warrant before obtaining ticket from the KDC, which is called in Kerberos Tgt:ticket granting Ticket, the TGT's distributor is still the KDC.

Let's take a look at how the client obtains the TGT from the KDC: first the client initiates an application to the KDC for the TGT, and the content of the application can be broadly expressed as: " I need a TGT to request access to all of the server's ticket." After the KDC receives the request, it generates a Session Key (skdc-client)that is used for secure communication between the Client and the KDC. To ensure that the session key is used only by the client and itself, the KDC uses the client's master key and its own master key to encrypt the generated session key to obtain two encrypted Copy of skdc-client . For the latter, encrypted with Skdc-client also contains some information about the client that will be used to authenticate the client later. Finally, the KDC sends these two copies to the client as a concurrent copy. One thing to note here is that in order to avoid the KDC's trouble maintaining the session key based on the different Client, just as the server does not save session key (Sserver-client) , The KDC does not save the session Key (skdc-client), but chooses to do so entirely by the Client itself.

After the client receives two encrypted packets from the KDC, the first copy is decrypted with own master Key to obtain the KDC and client Session Key (skdc-client) and caches the session and the TGT. With session key and Tgt,client own master key will no longer be required, since the Client can then use skdc-client to request a ticket to the KDC to access each server. The long-term key,skdc-client is a short-term key relative to the client's master key, and the security guarantee is better protected, which is the key to Kerberos's many more steps. It is also important to note that Skdc-client is a session key, he has his own life cycle, and the TGT and session are interrelated, when the session Key expires, the TGT is declared invalid, after which the client had to re-request the KDC new TGT , the KDC will generate a different session key and the TGT associated with it. Also, because client Log off also causes Skdc-client to fail, Skdc-client is also known as Logon Session Key .

Next, let's look at how the client uses the TGT to get a server-based ticket from the KDC. Here I would like to emphasize that ticket is based on a specific server, and the TGT is not specific to the server, the client can use a TGT from the KDC to obtain a different server-based ticket. We get to the end, after the Client obtains itself and the KDC's Session Key (skdc-client) , generates its own authenticator and the name of the server to be accessed and uses skdc-client for encryption. It is then sent to the KDC together with the TGT. The KDC decrypts the TGT using its own master Key , extracts the Client info and Session Key (skdc-client), and then uses this skdc-client Decryption authenticator obtains client info, which compares two client info to verify the identity of the other person. Validation succeeds, generating a copy of the server based on the client's access to the client, as described in the second section of ticket.

V. 3 Sub-protocol of Kerberos: The entire authentication

With the above introduction, we basically understand the whole process of Kerberos authentication: The whole process consists of the following 3 sub-processes:

1. The client applies to the KDC for the TGT (Ticket granting Ticket).
2. The client requests the ticket for access to the server by obtaining a TGT to DKC.
3. The client eventually submits ticket to the server for its own authentication.

But the above introduction is still a bit out of the real Kerberos authentication. The entire authentication process for Kerberos is done through 3 sub-protocol. The 3 sub-protocol each complete the 3 sub-processes listed above. These 3 sub-protocol were:

1. Authentication Service Exchange
2. Ticket granting Service Exchange
3. Client/server Exchange

A simple demonstration of completing this 3 sub-protocol is a message Exchange.

1. Authentication Service Exchange

The acknowledgement of the client identity is implemented by this SUB-PROTOCOL,KDC (specifically the authentication Service in the KDC) and issued to the client as a TGT. The process is as follows:

The client sends the authentication Service Request (krb_as_req) to the KDC's authentication service, in order to ensure that Krb_as_req is limited to itself and the KDC knows that The client uses its master key to encrypt the main part of the Krb_as_req (the KDC can obtain the client's master key via domain's account database). The Krb_as_req generally contains the following content:

• Pre-authentication data: Contains information to prove your identity. To be blunt is to prove that you know the password of the account that you claim to be. In general, its content is a timestamp that has been encrypted by the client's master key.
• Client Name & Realm: In short, domain name\client
• Server name: Note that server name here is not the name of the server that the client really wants to access, and we also say that the TGT is not server-independent (the client can only use ticket instead of the TGT to access the server). The server name here is actually the server name of the KDC's ticket granting service.

The krb_as_req that the AS (authentication Service) receives through it verifies whether the sender is the person claimed in client name & realm, that is, to verify that the Send and drop knows the client's password. So as simply extracts the client-corresponding master key from the account database to decrypt the pre-authentication data, and if it is a legitimate timestamp, it can prove that the send-and-put provides the correct password. After validation is passed, as sends a copy of the authentication Service Response (KRB_AS_REP) to the client. The krb_as_req consists of two parts: the Client's master key is encrypted by the session key (Skdc-client:logon session key) and the TGT is encrypted by itself (KDC). And the TGT generally contains the following content:

• Session Key:skdc-client:logon Session Key
• Client Name & Realm: In short, domain name\client
• End time:tgt the expiry time.

After the Client has decrypted the first part of the session key (Skdc-client:logon session key) with its own master key, it can enter the next step with the TGT: TGS (Ticket granting Service) Exchange.

2. TGS (Ticket granting Service) Exchange

TGS (Ticket Granting Service) Exchange sends Ticket granting service Request via client to the TGS (Ticket granting Service) in the KDC ( Krb_tgs_req) begins. Krb_tgs_req broadly contains the following content:

• The Ticket granting ticket,tgt obtained by tgt:client through as Exchange is encrypted by the KDC's master key.
• Authenticator: To prove whether the owner of the TGT was himself, so it must be encrypted with the TGT method and its session key (Skdc-client:logon session key).
• Client Name & Realm: In short, domain name\client.
• Server name & Realm: In short, domain Name\server, which is the server the client is trying to access.

TGS receives krb_tgs_req before sending to the client the true ticket, whether the TGT provided by the entire client is as granted to it. So it had to prove it through the authenticator provided by the client. However, authentication is encrypted by the Logon session key (Skdc-client) and does not save the session key. Therefore, the TGS must first decrypt the TGT provided by the Client through its master key to obtain this logon session Key (Skdc-client), and then through this logon session Key (skdc-client) decryption authenticator for verification. Verify by sending Ticket granting Service Response (KRB_TGS_REP) to each other. This krb_tgs_rep consists of two parts: using Logon session key (Skdc-client) to encrypt session key for Client and server (sserver-client) and using the server's master Key to encrypt the ticket. The ticket generally contains the following elements:

• Session key:sserver-client.
• Client Name & Realm: In short, domain name\client.
• The expiry time of the End Time:ticket.

The Client receives Krb_tgs_rep and obtains Session key (sserver-client)after decrypting the first part using Logon session key (Skdc-client) . With session key and ticket,client, you can interact with the server without having to be a middleman through the KDC. So we say that Kerberos is an efficient authentication method, which can be done directly through both client and server, unlike the NTLM authentication method under Windows NT 4, every authentication is done through a trusted 3rd party.

Let's take a look at how the Client interacts with ticket and Server, this phase is done through our 3rd Sub-protocol:CS (client/server) Exchange.

3. CS (Client/server) Exchange

This is already described in the second section of this article, and it is no longer burdensome to repeat the content. The client obtains Session Key (sserver-client)for client and server through TGS Exchange, and then creates a authenticator that proves itself to be the true owner of ticket. and use Session Key (sserver-client) for encryption. Finally, the encrypted authenticator and ticket are sent to the server as application Service Request (krb_ap_req). In addition to the above two items, Krb_ap_req also contains a flag to indicate whether the client needs two-way verification (Mutual authentication).

After the server receives the KRB_AP_REQ, it decrypts the ticket with its own master key to obtain session Key (Sserver-client). The authenticator is decrypted by session Key (Sserver-client) to verify the identity of the other person. Validation succeeds, allowing the client to access the resources it needs to access, otherwise it directly rejects the request.

For two-way authentication, the server extracts timestamp from authenticator, encrypts it using session Key (Sserver-client), and sends it to the client for the client Authentication server.


Vi. User2User Sub-protocol: Securing the Server effectively

Through the introduction of 3 Sub-protocol, we can fully master the whole Kerberos authentication process. In fact, in the Windows 2000 era, Kerberos-based Windows authentication was followed by this workflow. But I also said at the end of the previous section that Kerberos, based on 3 Sub-protocol, is a network authentication with its own limitations and security implications. Throughout this article, I have been emphasizing the principle that data encrypted with an entity's long-term key should not be passed through the network . The reason is simple, all encryption algorithms are not guaranteed 100% security, decryption of encrypted data is only a time process, the best way to provide security is to use a short-term key to replace the long-term Key encrypts the data so that when a malicious user decrypts it to an encrypted key, the key is already invalidated . However, for the 3 sub-protocol C/S exchange,client carry ticket is encrypted by the server Master Key , which does not conform to our proposed principle, reduce the safety factor of the server.

So we have to find a solution to solve the problem above. The solution is obvious: a short-term session key is used instead of the server Master key to encrypt the ticket. This is the 4th Sub-protocol of the Kerberos we are going to introduce today:User2User protocol. We know that since it is session Key, only two parties are involved, while the entire authentication process for Kerberos involves 3 parties: Client, Server, and KDC, so the only possible session between the server and the KDC is to encrypt the ticket. Key (Skdc-server).

We know that the client obtains access to the server's ticket from the KDC through the TGT obtained during the as Exchange phase. The original ticket is encrypted via the server's master key , which can be obtained from the account database. But now the KDC needs to encrypt with the skdc-server between the Server and the KDC, and the KDC does not maintain the session key, so this session key can only be provided by the client requesting ticket . So between as Exchange and TGS Exchange, the client also has to request the server to get the session Key (skdc-server) between the server and the KDC. For the Server, it can get the session key (Skdc-server) between him and the KDC, like a client, via as Exchange , and an encapsulated session key and The KDC's master key encrypts the TGT, and once it gets this tgt,server caches it to wait for the client to request it. We will now discuss the process in detail.

The User2User-based authentication process is basically translated, and the process consists of 4 steps. We find that this is the 2nd, compared to the traditional 3 SUB-PROTOCOL certification process I described in the previous section. Let's simply go through it from beginning to end:

1. As Exchange:client obtains its own TGT through this process, with which this tgt,client can request to the KDC for a ticket to access a server.
2. The main task of this step is to obtain the TGT belonging to the server that encapsulates the session Key (Skdc-server) of the server and the KDC. If the TGT exists in the server's cache, the server returns it directly to the client. Otherwise, it is obtained from the KDC through as Exchange.
3. TGS Exchange:client requests the ticket to the KDC for access to the server by providing its own tgt,server TGT to the KDC and authenticator. The KDC uses its own master key to decrypt the Client's TGT to obtain skdc-client, and Skdc-client decrypts the authenticator to verify that the sender is the true owner of the TGT, verifying that it is using its own master The TGT of the Key decryption server obtains the KDC and server session key (Skdc-server) and returns it to the client using the session key encryption ticket.
4. C/S Exchange:client carriers encrypt ticket via the KDC and server session Key (Skdc-server) and session via client and server The authenticator access Server,server for Key (sserver-client) is ticket by Skdc-server decryption Sserver-client, The validation of the client is achieved by Sserver-client decryption authenticator.

This is the whole process.

Vii. Advantages of Kerberos

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

1. The higher performance

Although we have repeatedly said that Kerberos is an authentication process involving 3 parties: Client, Server, KDC. However, once the client has access to a ticket that accesses a server, the server can validate the client against this ticket without the need for the KDC to participate again. and the traditional Windows NT 4.0-based NTLM comparison of each fully dependent trusted third party has a large performance boost.

2. Two-way verification is implemented (Mutual authentication)

The traditional NTLM authentication is based on the premise that the remote service that the client accesses is trustworthy and does not need to be validated, so NTLM does not provide bidirectional authentication functionality. This is obviously a bit idealistic, and for this reason Kerberos compensates for this deficiency: the client can request authentication for the server's identity before accessing the server's resources.

3. Support for the delegation

Impersonation and delegation are two important functions in a distributed environment. Impersonation allows the server to perform certain operations locally using the logon account, delegation requires the server to bring the logon account into a different context to perform the appropriate operation. NTLM only provides support for impersonation, and Kerberos implements support for delegation through a two-way, transitive (Mutual, transitive) trust pattern.

4. Interoperability (Interoperability)

Originally pioneered by MIT, Kerberos has now become a widely accepted standard. Therefore, it can be widely interoperable for different platforms.

[Reprint]kerberos Authentication principle