一、 Kerberos Authentication
Kerberos Authentication solves the problem of "how to prove that a user is indeed the user he claims to be".
The whole process of Kerberos Authentication involves Client and Server, and a Key (KServer-Client) should be used to represent the certificate passed between them. In order for the Server to authenticate itself effectively, the Client provides the following two sets of information to the other party:
① The information representing the Client's own Identity 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 by Client and Server, the Client Identity encrypted by Client using KServer-Client can only be decrypted by Client and Server. Similarly, the Server receives the two sets of information transmitted by the Client, first decrypts the latter through the KServer-Client , and then compares the confidential data with the former. If they are exactly the same, it can be proved that the Client can provide the correct KServer- Client. Client , since only the real Client and itself know KServer-Client , so the other party is the user it claims.
二、Key Distribution:KServer-Client
Before discussing how Client and Server get KServer-Client , we need to introduce an important role: Kerberos Distribution Center-KDC .
KDC plays an important role as a third party trusted by both Client and Server in the entire Kerberos Authentication, and the Kerberos authentication process is completed through the cooperation of these three parties. Kerberos originated from Greek mythology. It is a god dog with three heads that guards the underworld. In keberos Authentication, the three heads of Kerberos represent the three parties involved in the authentication process: Client, Server and KDC . Kerberos is therefore name.
Before introducing Kerberos Authentication in detail, we first introduce two important concepts:
Long-term Key/Master Key : In the field of security, some keys may remain unchanged for a long time. For example, your password may not change for several years. Such Key, and the Key derived from it are called Long-term Key. There is such a principle for the use of Long-term Key: the data encrypted by Long-term Key should not be transmitted on the network.
The reason is simple, once these packets encrypted by Long-term Key are intercepted by a malicious network listener, in theory, as long as there is enough time, he can obtain the Long-term Key you use for encryption through calculation.
Short-term Key/Session Key: Since the data packets encrypted by Long-term Key cannot be used for network transmission, we use another Short-term Key to encrypt data that needs to be transmitted over the network.
Since this kind of Key is only valid for a period of time, even if the encrypted data packet is intercepted by a hacker, when he calculates the Key, the Key has already expired. We can see the simple process of
KDC distributing KServer-Client through the figure below:
①Client A sends an application for SServer-Client to KDC. The content of this application can be simply summarized as " I am Client A, and I need a Session Key to access Server A ".
② After receiving the request, the KDC generates a Session Key.
③In order to ensure that the Session Key is only known to the Client A who sent the request and the Server A he wants to access, the KDC will generate two copies of the Session Key, which are used by Client A and Server A respectively.
④ KDC extracts the Master Keys of Client A and Server A from the Account database to perform symmetric encryption on the two copies respectively. The Session Key encrypted by the SAMaster key will be encrypted together with some information about Client A.
⑤ KDC sends the encrypted Session Ticket and C Session Key to Client A.
answer
a. The KDC directly sends the two encrypted packets to the Client and the Server respectively. For the Server, there will be two problems:
①Because a Server will face several different Clients, and each Client has a different The Session Key. Then the Server will maintain such a list of Session Keys for all Clients, which is troublesome and inefficient for the Server.
②Due to the uncertainty of network transmission, there may be such a situation: the Client obtains the Session Key quickly, and sends the Session Key as a Credential along with the access request to the Server, but the Session Key for the Server has not been received yet. And it is very likely that the one carrying the Session Key will never reach the Server, and the Client will never be authenticated.
b. If Client B claims to be Client A, KDC will still use the Master Key derived from Client A's Password to encrypt the Session Key, so only the party that actually holds Client A's Password will obtain the Session Key through decryption, and other users Can't impersonate.
三、Authenticator
Authenticator
After passing KServer-Client , Client A obtains two sets of information:
① C Session Key encrypted by CA Master Key. ② Session Ticket
containing Client A information encrypted by SA Master Key. In a real network environment, only use There are security holes in the above two authentications. For this reason, the Client needs to provide more proof information. We call this proof information Authenticator . The Authenticator in Kerberos is actually some information about the Client (Client Info) and the current time (Timestamp) . Through the following figure, we can see how the Server authenticates the Client:
①Client A decrypts the C Session Key encrypted by KDC through its own CA Master Key to obtain the Session Key (SServer-Client) . ②Create Authenticator (Client Info + Timestamp) . ③Use the Session Key (SServer-Client) to encrypt the Authenticator . ④Send it to Server A together with the Session Ticket (Client Info + Session Key) obtained from the KDC and encrypted by the Server's Master Key. ⑤ After Server A receives these two sets of data, it first decrypts the Session Ticket with its own SA Master Key to obtain the Session Key (SServer-Client) and Client A Info . ⑥Server A uses Session Key (SServer-Client) to decrypt
Authenticator to obtain Timestamp and Client A Info .
⑦The KDC compares the Timestamp decrypted from the Authenticator with the current Timestamp , and refuses to authenticate Client A if the time exceeds 5 minutes (default). ⑧KDC compares the Client A Info decrypted from the Authenticator and the Client A Info decrypted from the Session Ticket , if they are the same, then the authentication of Client A is realized
Mutual Authentication (two-way authentication)
An important advantage of Kerberos is that it can provide two-way authentication: not only the Server can authenticate the Client, but the Client can also authenticate the Server .
Check the following figure on the basis of Authentication:
⑨After Server A successfully authenticates Client A, it will propose the Timestamp in Authenticator , encrypt it with Session Key (SServer-Client) , and send it to Client A. ⑩Client A compares the Timestamp obtained after decryption with the Timestamp generated by itself , and if they are the same, Client A will authenticate Server A
answer
a. Why use Timestamp?
Let's imagine this phenomenon: the data packet sent by the Client to the Server is intercepted by a malicious network listener, and the listener then uses the data packet as its own Authenticator to pretend to be the Client to access the Server. In this case, the successful authentication of the Server can still be successfully obtained. In order to solve this problem, the Client will add a Timestamp of the current time in the Authenticator . Before the Server compares the Client Info in the Authenticator with the Client Info in the Session Ticket, it will first extract the Timestamp in the Authenticator and compare it with the current time . If the deviation between them exceeds an acceptable time range (generally is 5mins), the Server will directly reject the Client's request. What needs to be known here is that the Server maintains a list that records all authenticated Clients and authentication times within this acceptable time range. For the Client whose time deviation is within this acceptable range, the Server will obtain the latest authentication time of the Client from this list , and only when the Timestamp in the Authenticator is later than the latest authentication time of a Client , the Server will Follow up with the certification process.
b. During two-way authentication, why doesn't the server directly send the Authenticator encrypted by the Session Key to the client as it is, but extracts the Timestamp and encrypts it and sends it to the client?
Prevent malicious listeners from impersonating the Server through the obtained Authenticator sent by the Client to obtain the Client's authentication
四、Ticket Granting Service
Through the above introduction, we found that Kerberos is actually a Ticket -based authentication method. If the client wants to obtain the resources on the server side, it must first pass the authentication of the server; the prerequisite for authentication is that the client provides the server with a session ticket (session key + client info) encrypted with the S master key obtained from the KDC . It can be said that the Session Ticket is a ticket for the Client to enter the Server field. And this ticket must be obtained from a legal Ticket issuing authority, which is the KDC trusted by both Client and Server . At the same time, this Ticket has a super anti-counterfeiting mark: it is encrypted by the Server's Master Key. For Client, obtaining Session Ticket is the most critical part of the whole authentication process, which is the basic process of KDC distributing Ticket to Client.
TGT generation
This authentication credential is called TGT. Through the following figure, we can understand how Client obtains TGT from KDC:
①Client initiates an application for TGT to KDC , and the content of the application can roughly be expressed as follows: " I need a TGT to apply for a Ticket for accessing all Servers ".
② After receiving the application request, KDC generates a Session Key (SKDC-Client) for secure communication between the Client and KDC .
③ KDC uses CA Master Key to encrypt Session Key (SKDC-Client) to generate SKDC-Client , and uses KDC Master Key to encrypt Session Key (SKDC-Client) , which contains some information about Client that will be used to identify Client identity later. These two copies are both called SKDC-Client's Copy
④ KDC sends these two copies to the Client. One thing to note here is: In order to save the KDC from the trouble of maintaining the Session Key based on different Clients, just like the Server will not save the Session Key (SServer-Client) , the KDC will not save the Session Key (SKDC -Client ), and the choice depends entirely on the method provided by the Client itself.
⑤When the Client receives the two encrypted data packets from the KDC, it first uses its own CA Master Key to copy the first copyDecrypt to obtain the Session Key (SKDC-Client) of KDC and Client , and cache the Session and TGT.
With the Session Key and TGT, the Client's own Master Key is no longer needed, because after that, the Client can use the SKDC-Client to apply to the KDC for a ticket to access each Server. Compared with the Long-term Key of the Client's Master Key, SKDC-Client is a Short-term Key, and the security guarantee is better guaranteed, which is the key to Kerberos adding this step. At the same time, it should be noted that SKDC-Client is a Session Key, which has its own life cycle. At the same time, TGT and Session are related to each other. When the Session Key expires, the TGT will become invalid. After that, the Client has to apply for a new TGT from the KDC. The KDC will generate a different Session Key and the TGT associated with it. At the same time, since Client Log off also leads to the failure of SKDC-Client, SKDC-Client is also called Logon Session Key .
Client uses TGT to get the Ticket of the target Server from KDC
Let's take a look at how the Client uses TGT to obtain the Ticket of the target Server from the KDC through the following figure :
①Client A generates its own Authenticator and the name of the server to be accessed (Server Name ) after obtaining the Session Key (SKDC-Client) of itself and the KDC. ②Client A uses the Session Key (SKDC-Client) to encrypt the Authenticator and Server Name . ③Client A sends the encrypted data packet and TGT to KDC together. ④KDC uses its own KDC Master Key to decrypt the TGT to obtain Client A Info and Session Key (SKDC-Client) . ⑤KDC uses Session Key (SKDC-Client) to decrypt the encrypted data packet Get Authenticator and Server Name . ⑥ KDC uses Session Key (SKDC-Client)
Decrypt Authenticator to get Client A Info and Timestamp .
⑦The KDC compares the Timestamp decrypted from the Authenticator with the current Timestamp , and refuses to authenticate Client A if the time exceeds 5 minutes (default). ⑧ KDC comparesthe Client A Info decrypted from the Authenticator with the Client A Info decrypted from the TGT . If they are the same, then the authentication of Client A is realized. ⑨After successful authentication, KDC sends Session Ticket to Client.
Notice
Ticket is based on a specific Server, and TGT is independent of the specific Server. Client can use a TGT to obtain Tickets based on different Servers from KDC.
Five, 3 Sub-protocol
Through the above introduction, we basically understand the whole process of Kerberos authentication: the whole process generally includes the following three sub-processes:
①Client applies for TGT (Ticket Granting Ticket) from KDC.
②Client applies to DKC for a Ticket for accessing Server by obtaining TGT.
③Client finally submits Ticket to Server for its own authentication.
However, the above introduction is still a little different from the real Kerberos Authentication. The entire Kerberos authentication process is completed through three sub-protocols. These 3 Sub-Protocols respectively complete the 3 sub-processes listed above. The three sub-protocols are:
①Authentication Service Exchange
②Ticket Granting Service Exchange
③Client/Server Exchange
The following figure simply shows how to complete the three sub-protocols for Message Exchange.
1． AS(Authentication Service) Exchange
Through this Sub-protocol, the KDC (more precisely, the Authentication Service in the KDC) realizes the confirmation of the Client's identity and issues a TGT to the Client. The specific process is as follows:
①Client A creates Server Name , Client name & realm , and encrypts Client A Info and Timestamp with CA Master Key to generate Pre-authentication data .
- Pre-authentication data: Contains information to prove your identity. Used to prove that you know the password of the account you claim. Generally, its content is a Timestamp encrypted by the Client's Master key.
- Client name & realm: simply Domain name\Client
- Server Name: Note that the Server Name here is not the name of the Server that the Client actually wants to access. The Server Name here is actually the Server Name of the Ticket Granting Service of the KDC .
②Client A uses CA Master Key to encrypt Server Name , Client name & realm , and Pre-authentication data to generate Authentication Service Request (KRB_AS_REQ) .
③ KDC sends KRB_AS_REQ to KDC.
④ After receiving the data, KDC decrypts KRB_AS_REQ with CA Master Key to obtain Server Name , Client name & realm , and Pre-authentication data . ⑤ KDC uses CA Master Key to decrypt Pre-authentication data to obtain Timestamp .
⑥KDC compares the Timestamp decrypted from the Pre-authentication data with the current Timestamp, and refuses to authenticate Client A if the time exceeds 5 minutes (default).
⑦After successful authentication. KDC generates Session Key according to Server Name , then uses CA Master Key to encrypt Session Key to generate Session Key (SKDC-Client) , and then creates an End Time . - Session Key(SKDC-Client)：Logon Session Key
- Client name & realm: simply Domain name\Client
- End time: The time when the TGT expires.
⑧ KDC encrypts Session Key (SKDC-Client) , End Time , Client name & realm with its own KDC Master Key to generate TGT .
⑨KDC generates KRB_AS_REP from TGT and Session Key (SKDC-Client) .
⑩ KDC sends KRB_AS_REP to Client A.
2． TGS(Ticket Granting Service) Exchange
①Client A creates Client name & realm , Server name & realm , and uses Session Key (SKDC-Client) to encrypt Client A Info to generate Authenticator .
②Client A generates a Ticket Granting Service Request (KRB_TGS_REQ) from Client name & realm , Server name & realm , Authenticator , and TGT .
- TGT: The Ticket Granting Ticket obtained by the Client through the AS Exchange, and the TGT is encrypted by the Master Key of the KDC.
- Authenticator: It is used to prove whether the owner of the TGT is himself, so it must be encrypted with the method of TGT and its own Session Key (SKDC-Client: Logon Session Key).
- Client name & realm: Simply put, Domain name\Client.
- Server name & realm: Simply put, it is Domain name\Server, this time it is the Server that Client is trying to access.
③Client A sends KRB_TGS_REQ to KDC.
④ After KDC receives the data, use KDC Master Key to decrypt TGT to obtain Session (SKDC-Client) and Client A Info .
⑤ KDC uses Session Key (SKDC-Client) to decrypt Authenticator to obtain Client A Info .
⑥ KDC compares the Client A Info decrypted from the Authenticator with the Client A Info decrypted from the TGT Ticket . If they are the same, then the authentication of Client A is realized. ⑦ KDC generates Session Key (SServer-Client) and End Time , and then uses SA Master Key to encrypt Session Key (SServer-Client) , End Time ,
Client name & realm generate Session Ticket . At the same time, use Session Key (SServer-Client) to encrypt Session Key (SKDC-Client) . Finally, use the encrypted Session Key (SKDC-Client) and Session Ticket to generate KRB_TGS_REP .
- Session Key：SServer-Client。
- Client name & realm: Simply put, Domain name\Client.
- End time: The expiration time of the Ticket.
⑧ KDC sends KRB_TGS_REP to Client A.
3． CS（Client/Server ）Exchange
CS Exchange (one-way)
①Client A uses the CA Master Key to decrypt the Session Key (SKDC-Client) to obtain the Session Key (SServer-Client) .
②Client A uses the Session Ticket to encrypt Client A Info and Timestamp to generate an Authenticator to prove that it is the real owner of the Ticket.
③Client A uses the Session Key (SServer-Client) to encrypt the Authenticator . ④Client A generates KRB_AP_REQ
with encrypted Authenticator and Session Ticket and sends it to Server A. ⑤After receiving the data, Server A decrypts the Session Ticket with the SA Master Key to obtain the Session Key (SServer-Client) and
Client A Info .
⑥Server A uses Session Key (SServer-Client) to decrypt Authenticator to obtain Timestamp and Client A Info .
⑦Server A compares the Timestamp decrypted from the Authenticator with the current Timestamp , and refuses to authenticate Client A if the time exceeds 5 minutes (default). ⑧Server A compares the Client A Info decrypted from the Authenticator and the Client A Info decrypted from the Session Ticket. If they are the same, the authentication of Client A is realized. ⑨After successful authentication, Server A generates KRB_AP_REP and sends it to Client A.
CS Exchange (two-way)
Based on CS Exchange (single item)
⑨After Server A successfully authenticates Client A, it will propose the Timestamp in Authenticator , encrypt it with Session Key (SServer-Client) , and send it to Client A. ⑩Server A generates KRB_AP_REP and sends it to Client A. Client A compares the Timestamp obtained after decryption with the Timestamp generated by itself . If they are the same, Client A will authenticate Server A.
六、User2User Sub-Protocol
User2User Sub-Protocol can effectively monitor the security of Server.
We know that the Client obtains the Ticket to access the Server from the KDC through the TGT obtained in the AS Exchange stage. The original Ticket is encrypted through the Master Key of the Server , and this Master Key can be obtained through the Account Database. But now the KDC needs to use the SKDC-Server between the Server and the KDC for encryption, and the KDC will not maintain the Session Key, so the Session Key can only be provided by the Client that applies for the Ticket . Therefore, between AS Exchange and TGS Exchange, Client has to make a request to Server to obtain the Session Key ( SKDC-Server ) between Server and KDC. As for the Server, it can obtain the Session Key ( SKDC-Server ) between him and the KDC through AS Exchange like the Client and a TGT that encapsulates the Session Key and is encrypted by the Master Key of the KDC . Once the TGT is obtained , the Server will cache it, waiting for the Client's request for it. We now discuss this process in detail.
From the above figure, we understand that this process consists of 4 steps, let us briefly understand it from beginning to end:
- AS Exchange: Client obtains its own TGT through this process . With this TGT , Client can apply to KDC for a Ticket for accessing a certain Server.
- KRB_TGT_REQ/KRB_TGT_REP: 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 KDC. If the TGT exists in the server's cache, the server will directly return it to the client. Otherwise, get it from KDC through AS Exchange.
- TGS Exchange: Client provides KDC with its own TGT , Server's TGT and Authenticator to apply to KDC for a Ticket to access Server . KDC uses its own Master Key to decrypt Client's TGT to obtain SKDC-Client , and decrypts Authenticator through SKDC-Client to verify whether the sender is the real owner of TGT , and then uses its own Master Key to decrypt Server's TGT to obtain KDC and Server Session Key (SKDC-Server) , and use the Session Key to encrypt the Ticket and return it to the Client.
- C/S Exchange: The client carries the encrypted Ticket through the KDC and the Server's Session Key (SKDC-Server) and accesses the Server through the Authenticator of the Client and Server's Session Key (SServer-Client) , and the Server decrypts the Ticket through the SKDC-Server to obtain SServer-Client , through the SServer-Client to decrypt the Authenticator to verify the Client.
References
kerberos authentication principle - very detailed and easy to understand