ASP. NET: Kerberos network authentication process

I took some time to start learning about the Kerberos network authentication process. I hope to share it with you as follows.

I. Preliminary definition of Kerberos:

Kerberos is a term derived from the Greek mythology "Three-headed dog-The Guardian of the gate of hell ". Kerberos is a network authentication protocol designed to use a key system for client/server applications.ProgramProvides powerful authentication services. The authentication process does not depend on the host operating system authentication, and does not require host address-based trust and physical security of all hosts on the network, it is assumed that data packets transmitted over the network can be read, modified, and inserted at will. In the above cases, Kerberos, as a trusted third-party authentication service, implements authentication services through traditional cryptographic technologies (such as shared keys.

Kerberos service isSingle Sign-onSystem, which means that you only need to perform a self-verification for each session to the service to automatically protect the security of all subsequent transactions in the session process. After the service verifies you, you do not need to use Kerberos-based commands (suchFTPOrRsh) Or perform self-verification when accessing data on the NFS file system. Therefore, you do not need to send a password on the network each time you use these services (the password may be blocked on the network ).

 

Ii. Kerberos authentication process:

There are two major steps as shown in the following figure:

Step 1: apply for and obtain TGT. The procedure is as follows:
1. The client sends its own identity information (Info C) to KDC)
2. After receiving the client's identity information, KDC obtains TGT (ticket-granting ticket) from the ticket granting service)
3. KDC uses the key a between the client and KDC generated before the Protocol starts to send the TGT encrypted reply to the client.
4. The client uses key a to decrypt the encrypted TGT to obtain the unencrypted TGT. Because the key is the key between the client and KDC, only the real client can use the key between the client and KDC to decrypt the encrypted TGT to obtain the TGT. (This process avoids the client from sending a password directly to KDC for an insecure authentication method)

Step 2: the client uses the previously obtained TGT to request the ticket of other services from KDC, and then uses the identity authentication of other services. The procedure is as follows:
5. The client sends the previously obtained TGT and the requested service information (Info CS) to KDC.
6. The ticket granting service in KDC generates a session key between the client and the service for the service to authenticate the client.
7. KDC packs the session key and user name, user address (IP), service name, validity period, and timestamp into a ticket -- (Service tictket) (This information is finally used by the Service to identify the client) sent to the service, but the Kerberos protocol does not directly send the ticket to the service, but forwards it to the service through the client. so there are steps 8-11.

8. At this time, KDC forwards the ticket to the client. Because this ticket is intended for the service and cannot be seen by the client, KDC encrypts the ticket and sends it to the client using the key C between the KDC and the service before the Protocol starts. At the same time, in order to share the secret between the client and the service (the session key that KDC created for them in the first step ), KDC uses the key between the client and it to encrypt the session key and return it together with the encrypted ticket to the client. That is to say, the session key (Key B) between the client and the Service sends two copies, one for the client and the other for the service, the client can decrypt and decrypt the messages sent to the client, but the key C is encrypted and forwarded to the service through the client. Therefore, the client cannot extract the messages, after arriving at the service end, it can be taken out by the service end.
9. to complete ticket transfer, the client forwards the received service ticket to the service. because the client does not know the key between the KDC and the service, it cannot calculate and modify the information in the ticket, and can only honestly complete the forwarding task.
10. The client decrypts the received session key (decryption with key)
11. The client packs the user name and user address (IP) into an authenticator and uses the session key (Key B) obtained earlier to encrypt it and then sends it to the service.
12. after receiving a ticket, the Service decrypts the information in ticket using the key C between it and KDC to obtain the session key and user name, user address (IP), service name, and validity period. The session key (Key B) is used to decrypt the authenticator to obtain the username. The user address (IP) is used to decrypt the authenticator with the username and user address (IP) decrypted in the previous ticket) to verify the client identity.
13. If the service returns results, return them to the client.