Introduction to Kerberos Information can use the ticket-granting ticket obtained through this verification to access multiple services, that is, SSO (Single Sign On). Since a shared key is established between each Client and Service, the protocol is quite secure.

Conditions

Let’s first look at the prerequisites of the Kerberos protocol:

Client and KDC, KDC and Service already have their own shared keys before the protocol works, and Since the messages in the protocol cannot penetrate the firewall, these conditions restrict the Kerberos protocol from being used within an organization, making its application scenarios different from X.509 PKI.

Process

The Kerberos protocol is divided into two parts:

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

At this time, only the real Client can use the key between it and the KDC to decrypt the encrypted TGT, thereby obtaining the TGT.

(This process avoids the unsafe method of the client sending the password directly to the KDC in order to pass the verification)

2. The client uses the TGT obtained previously to request the KDC for tickets for other services, thus Authentication through other services.

The focus of the Kerberos protocol lies in the second part, and the introduction is as follows:

1. The Client sends the previously obtained TGT and the service information to be requested (service name, etc.) to the KDC. The Ticket Granting Service in the KDC will generate a Session Key between the Client and the Service for the Service to authenticate the Client. The KDC then packages the Session Key together with the user name, user address (IP), service name, validity period, and timestamp into a Ticket (this information is ultimately used by the Service to authenticate the Client) and sends it to the Service. However, the Kerberos protocol does not Send the Ticket directly to the Service, but forward it to the Service through the Client. So there is a second step.

2． At this time, the KDC forwards the just Ticket to the Client. Since this Ticket is for the Service and cannot be seen by the Client, the KDC uses the key between the KDC and the Service before the protocol starts to encrypt the Ticket and then sends it to the Client. At the same time, in order to share the secret (the Session Key created by KDC for them in the first step) between Client and Service, KDC uses the key between Client and it to encrypt the Session Key and return it to the Client together with the encrypted Ticket.

3． In order to complete the delivery of the Ticket, the Client forwards the Ticket just received to the Service. Since the Client does not know the key between the KDC and the Service, it cannot modify the information in the Ticket. At the same time, the Client decrypts the received Session Key, then packages its user name and user address (IP) into an Authenticator, encrypts it with the Session Key, and sends it to the Service.

4． After receiving the Ticket, Service uses the key between it and the KDC to decrypt the information in the Ticket, thereby obtaining the Session Key, user name, user address (IP), service name, and validity period. Then use the Session Key to decrypt the Authenticator to obtain the user name and user address (IP), and compare it with the user name and user address (IP) decrypted in the previous Ticket to verify the Client's identity.

5． If the Service returns a result, return it 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 mainly does two things

1． Secure delivery of tickets.

2． Secure release of Session Key.

Coupled with the use of timestamps, the security of user authentication is guaranteed to a large extent. And using the Session Key, the messages passed between the Client and the Service after passing the authentication can also be guaranteed by Confidentiality (confidentiality) and Integrity (integrity). However, since an asymmetric key is not used, it cannot be non-repudiation, which also limits its application. However, relatively speaking, it is much simpler to implement than the X.509 PKI identity authentication method.

Specific process

(Note: This process uses symmetric encryption; this process occurs in a certain Kerberos realm; lowercase letters c, d, e is the message sent by the client, and the capital letters A, B, E, F, G, H are the messages sent back by each server)

First, the user uses the program on the client (the user's own machine). Login:

The user enters their user ID and password into the client.

The client program runs a one-way function (mostly hash) to convert the password into a key. This is the "user key" (K_client) of the client (user). The trusted AS also obtains the same key as this key through some secure means.

Subsequently, client authenticates (client gets ticket for ticket (TGT) from AS):

Client sends 1 message to AS (Note : The user does not send the key (K_client) to the AS, nor the password):

A clear text message containing the user ID, such as "User Sunny wants to request a service" (Sunny is the user ID)

AS checks the validity of the user ID, and then returns 2 messages:

Message A: "Client-TGS session key" encrypted by user key (K_client) (K_TGS-session) (The session key is used for future communication (session) between the client and TGS)
Message B: "Ticket Authorization Ticket" (TGT) encrypted by TGS key (K_TGS) ( TGT includes: client-TGS session key (K_TGS-session), user ID, user URL, TGT validity period)

The client decrypts A with its own key (K_client) to get 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, the service authorizes (the client gets the ticket (T) from the TGS):

The client sends the following 2 messages to the TGS:

Message c: Message B (K_TGS encrypted TGT), and the service ID of the service you want to obtain (note: not the user ID)
Message d: Client-TGS session secret The "authentication character" encrypted by the key (K_TGS-session) (the authentication character includes: user ID, timestamp)

TGS uses its own key (K_TGS) to decrypt B in c to obtain TGT, Thus, the client-TGS session key (K_TGS-session) provided by AS is obtained. Then use this session key to decrypt d to get the user ID (authentication), and then return 2 messages:

Message E: "Client-Server Ticket" encrypted by the server key (K_SS) ( 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) encryption After the "client-SS session key" (K_SS_session)

the client decrypts F with the client-TGS session key (K_TGS-session) to 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, service request (client gets service from SS):

Client sends 2 messages to SS:

Message e: Message E
Message g: "New authenticator" encrypted by client-server session key (K_SS_session) (new authenticator includes: user ID, timestamp)

SS decrypts e/E with its own key (K_SS) to obtain T, thereby obtaining the client-server session key (K_SS_session) provided by TGS. Then use this session key to decrypt g to get the user ID (authentication), and then return a message (confirmation letter: confirming that the identity is true and willing to provide services):

Message H: client-server session The "new timestamp" encrypted by the key (K_SS_session) (the new timestamp is: the timestamp sent by the client plus 1)

The client uses the client-server session key (K_SS_session) Decrypt H and get the new timestamp.

The client checks that the timestamp is updated correctly, then the client can trust the server and send a service request to the server (SS).

Server (SS) provides services.

Defects

Fails at a single point: it requires continuous response from the central server. When the Kerberos service ends, no one can connect to the server. This shortcoming can be compensated by using a composite Kerberos server and a defective authentication mechanism.
Kerberos requires that the clocks of the hosts participating in the communication are synchronized. Tickets have a validity period, so if the host's clock is out of sync with the Kerberos server's clock, authentication will fail. The default setting requires that the clock times differ by no more than 10 minutes. In practice, a Network Time Protocol daemon is often used to keep host clocks synchronized.
Management protocols are not standardized and there are some differences in server implementation tools. RFC 3244 describes password changes.
Because the keys used by all users are stored in the central server, compromising the security of the server will compromise the keys of all users.
A dangerous client will compromise user passwords.

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