Kerberos introduction _ PHP Tutorial

Kerberos introduction. Kerberos introduction Kerberos protocol: Kerberos protocol is mainly used for computer network Authentication. it features that users only need to enter the Authentication information once.

Kerberos protocol:

The Kerberos protocol is mainly used for Authentication of computer networks. it features that users only need to enter the Authentication information once to obtain the ticket (ticket-granting ticket) through this Authentication) access multiple services, that is, SSO (Single Sign On ). Because a shared key is established between each Client and Service, the protocol is quite secure.

Condition

Let's take a look at the prerequisites for the Kerberos protocol:

The Client and KDC, KDC, and Service have their own shared keys before the protocol works, and the messages in the protocol cannot penetrate the firewall, these conditions limit that the Kerberos protocol is often used inside an organization to make its application scenario different from that of X.509 PKI.

Process

The Kerberos protocol is divided into two parts:

1. the Client sends its identity information to KDC. KDC obtains TGT (Ticket-Granting ticket) from the ticket granting Service and uses the key between the Client and KDC to encrypt and reply the TGT to the Client before the protocol starts.

At this time, only the real Client can use the key between it 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)

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 Kerberos protocol focuses on the second part. the introduction is as follows:

1. the Client sends the previously obtained TGT and requested service information (service name, etc.) to KDC, the Ticket Granting Service in KDC generates a Session Key between the Client and the Service for the Service to authenticate the Client. Then, KDC packs the Session Key and user name, user address (IP), Service name, validity period, and timestamp into a Ticket (the information is used for Client authentication by the Service) but the Kerberos protocol does not directly send Ticket to the Service, but forwards it to the Service through the Client. so there is step 2.

2. 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 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.

3. to complete Ticket transfer, the Client forwards the received 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. At the same time, the Client decrypts the received Session Key, and then packs the user name and user address (IP) into an Authenticator, which is encrypted with the Session Key and sent to the Service.

4. after receiving the Ticket, the Service uses the Key between it and KDC to decrypt the information in the Ticket to obtain the Session Key and user name, user address (IP), Service name, and validity period. Then, the Session Key is used to decrypt the Authenticator to obtain the user name. The user address (IP) is compared with the user name decrypted in the previous Ticket, and the user address (IP) is compared to verify the Client identity.

5. if the Service returns results, return them to the Client.

Kinit-Obtain and cache Kerberos ticket-granting ticket

Kinit is used to obtain and cache Kerberos ticket-granting tickets. This tool is similar in functionality to the kinit tool that are commonly found in other Kerberos implementations, such as SEAM and MIT Reference implementations.

The user must be registered as a principal with the Key Distribution Center (KDC) prior to running kinit.

SYNOPSIS

Kinit [commands] [ ]

Summary

In summary, the Kerberos protocol is mainly used for two tasks.

1. secure transfer of Ticket.

2. secure release of the Session Key.

In addition, the use of timestamps ensures the security of user authentication to a great extent. The Session Key can be used to ensure the Confidentiality and Integrity of messages transmitted between the Client and the Service after authentication. However, since asymmetric keys are not used, they cannot resist denial, which limits their applications. However, it is much easier to implement than the identity authentication method of X.509 PKI.

Procedure

(Note: This process uses symmetric encryption. this process occurs in A Kerberos domain. The lower-case letters c, d, and e are the messages sent by the client, and the upper-case letters A, B, e, F, G, and H are the messages sent back by each server .)

First, the user logs on using a program on the client (the user's own machine:

1. Enter the user ID and password to the client.
2. The client runs a one-way function (most of which is a collection) to convert the password into a key. this is the "user Key" (K_client) of the client (user ). Trusted AS obtains the same key AS this key through some security means.

Then, the client authenticates (the client obtains the ticket from the AS (TGT )):

1. The client sends one message to the AS (note: The user does not send a key (K_client) or a password to the ):
• Plaintext message containing the user ID, for example, "user Sunny wants to request Service" (Sunny is the user ID)
2. AS checks the validity of the user ID, and then returns two messages:
• Message A: The "client-TGS session key" (K_TGS-session) encrypted by the user key (K_client) (The session key is used for future communication between the client and the TGS (session)
• Message B: TGS key (K_TGS) encrypted "ticket authorization ticket" (TGT) (TGT includes: client-TGS session key (K_TGS-session), user ID, user URL, TGT validity period)
3. The client decrypts A with its own key (K_client) to obtain the client-TGS session key (K_TGS-session ). (Note: The client cannot decrypt message B because B is encrypted with the TGS key (K_TGS ).

Then, service authorization (the client obtains the ticket from TGS (T )):

1. The client sends the following two messages to TGS:
• Message c: message B (K_TGS encrypted TGT), and the service ID of the service to be obtained (note: it is not the user ID)
• Message d: client-TGS session key (K_TGS-session) encrypted "Authenticator" (Authenticator includes: User ID, timestamp)
2. TGS uses its own key (K_TGS) to decrypt B in c to get TGT, so AS to get the client-TGS session key (K_TGS-session) provided by the ). Use this session key to decrypt d to get the user ID (authentication), and then return two messages:
• Message E: Server Key (K_SS) encrypted "client-server ticket" (T) (T includes: client-SS session key (K_SS-session), user ID, user URL, T validity period)
• Message F: client-TGS session key (K_TGS-session) encrypted "client-SS session key" (K_SS_session)
3. The client uses the client-TGS session key (K_TGS-session) to decrypt F and obtain the client-SS session key (K_SS_session ). (Note: The client cannot decrypt message E because E is encrypted with the SS key (K_SS ).

Finally, the service request (the client obtains the service from the SS ):

1. The client sends two messages to the SS:
• Message e: that is, message E
• Message g: the "new authenticator" encrypted by the client-server session key (K_SS_session). The new authenticator includes the user ID and timestamp)
2. The SS uses its own key (K_SS) to decrypt e/E to obtain T, so as to obtain the client-server session key (K_SS_session) provided by the TGS ). Use this session key to decrypt g to get the user ID (authentication), and then return one message (confirmation letter: confirm the identity, willing to provide services ):
• Message H: "New timestamp" encrypted by the client-server session key (K_SS_session) (the new timestamp is: the timestamp sent by the client plus 1)
3. The client uses the client-server session key (K_SS_session) to decrypt H and obtain the new timestamp.
4. When the client checks that the timestamp is correctly updated, the client can trust the server and send service requests to the server (SS.
5. The server (SS) provides services.

Defects

• Failure at single point: it requires a sustained response from the central server. No one can connect to the server before the Kerberos service ends. This defect can be remedied by using the compound Kerberos server and the defect authentication mechanism.
• Kerberos requires that the clock of the host involved in communication be synchronized. The ticket has a certain validity period. Therefore, if the host clock is not synchronized with the Kerberos server clock, authentication will fail. The default setting requires that the time difference between the clock is no more than 10 minutes. In practice, the network time protocol background program is usually used to synchronize the host clock.
• Management protocols are not standardized and there are some differences in server implementation tools. RFC 3244 describes the password change.
• Because the keys used by all users are stored in the central server, the behavior endangering the security of the server will endanger the keys of all users.
• A dangerous client will compromise the user password.

Reference:
Http://idior.cnblogs.com/archive/2006/03/20/354027.html
Http://bey2nd.blog.163.com/blog/static/12063183120141275250466/
Http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/kinit.html

Protocol Kerberos protocol: Kerberos protocol is mainly used for computer network Authentication. it features that users only need to enter the Authentication information once...