Kerberos is an authentication system based on symmetric keys. In fact, it sometimes works better than PKI Based on asymmetric keys. Especially in small-scale network architecture, Kerberos is more centralized and convenient for management, it is even more efficient. I believe that many people can read this classic conversation, but after reading it, many people also need time to digest it. In fact, this conversation is not just about the principles of Kerberos, it is more important to show a method of research problems, from simple to complex, making up for vulnerabilities by 1.1 points, and finally adding numerous trade-offs, A safe, efficient, and feasible solution is provided. This article briefly summarizes the specific process of Kerberos.
Kerberos has three most important rules: first, it never transmits plain text on the Internet, which ensures the confidentiality of the authentication process. This is the premise of everything, the second is to share a secret between the authenticated and authenticated parties. This ensures the foundation of the authentication, that is, it cannot be impersonated or forged. How can we achieve Kerberos, third, there is a highly credible trusted institution, which ensures the confidentiality of the authentication itself and cannot be impersonated. In the authentication system, Kerberos is centralized, while PKI is relatively democratic? The Kerberos process is roughly divided into two steps. The first step is access authentication, and the second step is communication authentication. First, let's look at the first step:
1. First, the client accessing the network needs to obtain an access statement from a trusted institution, that is, to obtain the trust of the trusted institution. It only needs to simply send the user name to the institution;
2. the trusted institution uses the user name to check the user's password, and then generates an access certificate (including client information) and a shared key shared by the client and the trusted institution, use the client password to encrypt and send it to the client;
3. After receiving the encrypted admission certificate and shared key, the client decrypts the key with a secret that only the client and the trusted institution know and obtains the shared key. At this point, the client becomes an access key;
Note: The same access authentication is also required for each server to access the network. The process is slightly different but roughly the same.
The following is the second step:
1. next, if the client needs to communicate with a server, then it encrypts the server ID together with its own access certificate and the key shared by the trusted institution together with A validator (User Information encrypted with the shared key) and the plain text of user information is sent to the recipient together;
2. after receiving the request, the trusted institution will verify the user's access, query the shared key using the user name, use the shared key to decrypt the validators, and then compare the information with the plain text user. If the information is consistent, the institution will pass the authentication;
3. the trusted institution generates a key shared by the server and the client based on the requested server ID, then, it is encrypted with the user information, server information, and timestamp information by using the shared key of the trusted institution and client, and then transmitted back to the client;
Note: user information, server information, and timestamp information contain the shared keys of the client and server and are encrypted with the keys of the requested server. Therefore, the client cannot obtain more information, it is impossible to forge a credential for communication with the server.
4. after receiving the package, the client unlocks the package with the key shared by the trusted institution, obtains the key shared with the server, and then encrypts a piece of client information with the key-validators, send the encrypted information along with the remaining part obtained from the trusted institution to the server;
5. after receiving the accesskey, the server first decrypts the remaining part of step 1 with its own key, obtains the password shared by the server and the client, and then decrypts the authenticator sent from the client using the password, verify the information.
The above is the entire Kerberos authentication process, with the time stamp Restriction Mechanism omitted (I do not like this mechanism, I feel very bad ), the key point is that the server secret cannot be known to the client, but the client can only master the server secret to make the server fully think it is trusted. Imagine that you only tell the secret to someone you trust, in turn, if a person knows your secret, then you need to trust it to a great extent? Kerberos cannot be guaranteed. The client may save the secret, which may allow many clients to know the secret of the server. Therefore, the preceding complicated Kerberos mechanism emerged. After the emergence of RSA, everything above can be done in only two steps. One is to encrypt one is a signature, and a digital envelope can be used for key negotiation, and DH can be used, however, we need to know that asymmetric key systems are costly. In small-scale networks, Kerberos is very useful. However, the single point of failure (spof) of KDC has a great impact on security, therefore, we must do everything we can to protect KDC without using PKI. After all, the key information has been built into the digital certificate. By the way, the key negotiation process in the SSL handshake can also negotiate a key using Kerberos. The process is as follows: the client has obtained the credential provided by the trusted institution to communicate with a server, the password shared by the client and the server that the client and the trusted institution share the key encryption, and a "certificate" that also contains the password ", the "certificate" here is the "ticket" in the classic conversation (encrypted by the server key). In the SSL clientkeyexchange message, the client sends the "certificate" and the pre_master_secret encrypted by the password shared with the server to the server. The server decrypts the "certificate" with its own key, obtains the password shared with the client, and decrypts the pre_master_secret.