Kerberos is an encryption mechanism. Kerberos is said to be a fierce three-headed guard dog in Greek mythology. Encryption mechanism in this name, it is estimated that they think they are very powerful, easy to fight it.
Kerberos is designed to be independent of operating system security, host physical security, url authentication, network security, and the like, even if packets sent over the network can be read, modified, and inserted arbitrarily. This is even more powerful than HTTPS. HTTPS is used to protect information from theft and tampering during transmission, but it depends on CA authentication authority and certificates.
How did you do that? It’s basically encryption. The information transmitted is encrypted, so there is no fear of leakage; It can also be verified, so it is not afraid of tampering and denial. To be honest, encryption and verification are nothing new, but the trick is the encryption.
It uses the other party’s password as a key to encrypt.
To be specific, it is not asymmetric encryption, what private key public key, you come and go so complicated. It’s symmetric encryption. It’s much easier. The only trick is that many encrypted messages have keys that use the recipient’s password.
What do you mean?
The Kerberos mechanism consists of Client, Application Server, and KDC. The Client and Application Server are easy to understand. The KDC is a central authentication module. It is called the KEY Distribution Center (KDC). The KDC consists of two modules: An Authentication service (AS) and a ticket granting service (TGS). Authentication and authorization are two topics of security verification. Certification is about who you are, licensing is about what you can do.
The Kerberos process is as follows:
Combined with the above picture, the explanation is as follows:
1.
The client wants to access an Application Server (Application 1 Server), but Application 1 Server says, “You have no credentials, no identity, no authorization, no reception.”
2,
The client then finds the KDC and reports its username.
3,
KDC.AS sends a packet to the client containing a ticket TGT and a key SK_TGS, denoted {TGT,SK_TGS}. The packet is encrypted using the client’s password. TGT itself is a package {user, address, tgs_name, start_time, lisftime, SK_TGS}, which is encrypted with KDC.TGS password! Notice that the TGT contains the same SK_TGS. SK_TGS is the key used by the client to communicate with KDC.TGS.
4,
After receiving the packet sent by KDC.AS, the client uses its own password to unlock the packet and obtains the TGT and SK_TGS. The client then sends [TGT, Authenticator] to KDC.TGS. Authenticator={user, addresss, start_time, lifetime}, SK_TGS is used for encryption.
5,
KDC.TGS receives the packet from client, unlocks TGT with its own password, and obtains SK_TGS. Then, unlock the Authenticator with SK_TGS and compare and verify the contents with the relevant information in the TGT.
After verification, KDC.TGS generates a session key SK_Service between client and Application 1 Server. Then a package is sent to the client: [{SK_Service}SK_TGS, ST]. SK_Service is encrypted using SK_TGS, and the ticket ST is encrypted using the password of Application 1 Server. Similarly, ST itself is a package with the following contents: {user, address, start_time, lifetime, SK_Service}. Note that there is also a copy of SK_Service.
6,
The client receives the packet sent by KDC.TGS, decrypts the packet using SK_TGS to obtain SK_Service, encrypts the packet using SK_Service to generate Authenticator, and sends [ST, Authenticator] to Application 1 Server.
Application 1 Server unlocks the SESSION key SK_Service in ST with its own password, unlocks the Authenticator, and compares the authentication. A pleasant conversation with the client started using SK_Service.
7,
The client attempts to access the second Application Server, Application 2 Server, but fails. Procedure
Eight,
The identity of the client is verified within the validity period. Therefore, the client does not need to authenticate the client to the KDC.
Kerberos uses a security technique like an e-envelope to place the key in an encrypted ticket, which in turn uses the other party’s password as the key. In addition, there are two kinds of objects in a transmission packet: bill and encryption packet, and the contents in the bill and encryption packet are related. After unlocking the encryption packet with the key in the bill, they can refer to each other to prevent tampering and denial. When you first look at Kerberos, you may find it confusing, with tickets and session keys flying all over the place, but it’s easy to understand once you understand the routine.
To summarize it more thoroughly, Kerberos attaches great importance to the use of session keys. Access different objects, use different session keys, each one, never lost. The session key is generated by THE KDC. How can it be sent to the other party? Encrypt it with the other party’s password. It was a stroke of genius. Compare the HTTPS. HTTPS transmission is also symmetric encryption. But how is the key generated? It is negotiated between the client and the server when the connection is established. After the key is created, asymmetric encryption is used to transmit it to the other party. It is encrypted with the other party’s public key and then decrypted with the other party’s private key, which takes a lot of trouble. How do I know this public key is your public key? So CA’s and certificates come in again. And Kerberos is hard enough, use your password to encrypt, that your password, you must know ah.
This begs the question, how does KDC know each other’s passwords? As a central authentication module, KDC stores the account and application server passwords in advance, which is an important infrastructure for Kerberos. With that in mind, Kerberos has its advantages, but only in custom developed applications. If you’re on the Internet, there seems to be no better solution than HTTPS.