Learn more about how Kerberos authentication works

Step through the process of working with the Kerberos protocol

This article is I read this English explanation after the self-summary, has not finished writing ...

Https://technet.microsoft.com/zh-cn/library/cc961976.aspx

Is summed up, not translation, so I read the following according to their own understanding of the written, if there is a problem, please correct me!

The word Kerberos is a three-head dog in Ancient Greek mythology, the dog guarding the gates of hell and preventing the living from breaking in. The Kerberos protocol is named because the important part of the protocol is also three: client, server, KDC (Key Distribution center). Let's start with the simplest mutual authentication and step through the process of working with the Kerberos protocol

1. Simple Mutual authentication

When a sends a message to B, it attaches a authenticator (authentication code, the data structure = identity information + timestamp) to authenticate each other. Before starting the validation, A and B already have a key that is known to only two people. Here is the workflow:

A. A uses the key to encrypt the "information +authenticator (identity + timestamp)" and send it to B

B. b decrypts a authenticator with a key and records the time stamp contained therein. B compares this timestamp to its current time, if the time difference is greater than a certain value (5 minutes by default under Windows), B considers the information not to be a, and rejects subsequent validation. If the time difference is less than the set value, B checks if there is a authenticator with an earlier timestamp in the last 5 minutes, and if not, B thinks the message is indeed a. This completes the verification of B to a.

C. b encrypts the timestamp in the athenticator with the key and sends it back to a to prove that it is indeed B.

D. A after receiving, decrypt the timestamp, after their own comparison, confirmed that the other party is indeed B. This completes the verification of A to B

2. Introduction of Session key and Key Distribution center KDC

The 1 implementation has a premise that A and B must have a key that only two people know. In 2, we design a key distribution mechanism to refine the 1 process. This introduces Key Distribution center, KDC Key Distribution center. When a tries to send a message to B, the KDC will issue an encrypted session key to A and B, which is equivalent to the one in 1 that has and only AB know (note that during the transfer session key will wrap a layer of key to encrypt it, as described below).

3. Introduction of secret key (encryption of key)

Session key needs to be encrypted during transmission. So we introduced an encryption key, called secret key (or long term key, which is derived from the account password in the user account verification). This key is a key that is available between the KDC and a (or b) and is known only to both parties. When the KDC transmits between a and a, it is encrypted by a key that is known only to both A and KDC. When transmitting between KDC and B, it is encrypted by a key that is known only by B and the KDC.

4. Introduction of Session ticket (identification of key)

In practice, a KDC corresponds to a large number of clients and services, with a shared session key (key) between each client and server. To differentiate these session keys, we introduced the concept of Session ticket, which is a data structure embedded with session key and client identity information (the original authorization data for the clients). Equivalent to session key and client 1-to-1 table.

Here are the specific work processes:

A. The client submits client identity information to the KDC (which is encrypted using client Secretkey) and requires mutual authentication with the server.

B. The KDC generates a session key that is known only to the client and the server.

C. The KDC appends session key to the client identity information to form the session ticket, and the server side secret key to encrypt session Ticke and then pass to the server. The server received the KDC reply, using the server secret key decryption, obtained and only the client and the server is aware of the key session key.

D. The KDC will "session key+ server secret key encryption session ticket" with the client secret key encryption, passed to the client. The client received a reply from the KDC, using the client secret key to decrypt the session ticket "session key+ server secret key encryption." The decrypted two pieces of content are placed separately in a secure cache (a piece of isolated memory space, not on the hard disk). When the client sends the information to the server again, the client can send the message to the server directly, the session ticket+ with session key encrypted authenticator (identity + timestamp) when the server secret key is encrypted.

E. The server received the above credentials from the client, first using the server secret key to decrypt the session ticket, get embedded in the session ticket session key, with it will authenticator decrypt, Gets the timestamp of the client sending the message. Then follow steps b, C, d in the simple mutual authentication process in 1.

Ps:

1. Session ticket can be reused. After the client obtains session ticket from the KDC, it is placed in the secure cache (a piece of isolated memory space, not on the hard disk). Whenever the client wants to access the specified server, the client presents the corresponding session ticket.

2. Session ticket has a failure period, usually 8 hours, which can be set in the corresponding Kerberos policy.

3. The server does not need to store session ticket. The KDC is only responsible for sending information and does not verify that the information is released to the correct object. Because even if the wrong object is sent, the other party does not have the secret key (with only the KDC and the correct object to know the key), is not open information.

This article is from the "Work Notes" blog, so be sure to keep this source http://huamingao.blog.51cto.com/3602336/1703571

Learn more about how Kerberos authentication works