9.8. Kerberos

9.8.1. Introduction

The Kerberos protocol originated from the Athena project of the Massachusetts Institute of Technology in the United States. Based on the public and private key encryption system, it provides two-way authentication for the distributed environment. It was adopted in RFC 1510. Kerberos is the default authentication protocol in the Windows domain environment.

Simply put, Kerberos provides a single sign-on (Single Sign-On, SSO) method. Consider a scenario where there are different servers in a network, for example, a print server, a mail server, and a file server. These servers all have authentication requirements. Naturally, it is impossible for each server to implement an authentication system by itself, but to provide a central authentication server (Authentication Server, AS) for these servers to use. This allows any client to log in to all servers by maintaining only one password.

The Kerberos protocol is a ticket-based system. There are at least three roles in the Kerberos system: an authentication server (AS), a client (Client), and a common server (Server).

The authentication server authenticates the user and issues a TGT (Ticket Granting Ticket) that the user uses to request a session ticket. The Ticket Granting Service (TGS) issues ST (Session Tickets) for network services on the basis of TGTs issued to clients.

In the Kerberos system, both client and server have a unique name called Principal. At the same time, both the client and the server have their own passwords, and their passwords are only known by themselves and the authentication server AS.

9.8.2. Basic Concepts

  • Principal (secure individual)

    • The authenticated individual has a name and password

  • KDC (Key Distribution Center)

    • A web service that provides tickets and temporary session keys

  • Ticket

    • A record that a user can use to identify themselves to the server, which includes the user’s identity, session key, timestamp, and other information. Most of the information in the Ticket is encrypted, and the key is the server’s key

  • Authenticator

    • A record containing some recently generated information that requires a session key shared between the user and the server

  • Credentials

    • A ticket plus a secret session key

  • Authentication Server (AS)

    • Authenticate users by long-term key

    • AS grants user ticket granting ticket and short-term key

    • Certification Services

  • Ticket Granting Server (TGS)

    • Authenticate users with short-term key and Ticket Granting Ticket

    • TGS issues tickets to users to access other servers

    • Authorization and Access Control Services

9.8.3. Simplified Certification Process

  1. The client initiates a request to the server, and the content of the request is: the principal of the client, the principal of the server

  2. After the AS receives the request, it randomly generates a password Kc, s (session key), and generates the following two tickets to return to the client

    1. The ticket to the client, encrypted with the client’s password, the content is random password, session, server_principal

    2. The ticket to the server, encrypted with the server’s password, the content is random password, session, client_principal

  3. After the client gets the two tickets in the second step, it first unlocks the tickets with its own password to get Kc, s, and then generates an Authenticator, which mainly includes the current time and the check codes of Ts, c, and uses the SessionKey Kc,s encryption. After that, the client sends the Authenticator and the ticket to the server to the server at the same time

  4. The server first unlocks the ticket with its own password, gets the SessionKey Kc,s, then unlocks the Authenticator with Kc,s, and checks as follows

    1. Check if the timestamp in the Authenticator is within 5 minutes of the current time, and check if the timestamp appears for the first time. If the timestamp is not the first time, it means that someone intercepted the content sent by the client before and carried out a Replay attack.

    2. Check if the checksum is correct

    3. If all are correct, the client is authenticated

  5. The server segment can optionally reply to the client with a message to complete the two-way authentication, the content is the timestamp encrypted with the session key

  6. The client verifies the server by unpacking the message and comparing whether the timestamp sent back is consistent with the timestamp sent by itself

9.8.4. Complete Certification Process

The process described above has been able to complete the mutual authentication between the client and the server. However, the inconvenience is that each authentication requires the client to enter its own password.

Therefore, in the Kerberos system, a new role is introduced called: Ticket Granting Service (TGS - Ticket Granting Service), its status is similar to that of an ordinary server, but the service it provides is for clients to issue tickets to other servers. Certified ticket.

In this way, there are four roles in the Kerberos system: Authentication Server (AS), Client (Client), Normal Server (Server) and Ticket Authorization Service (TGS). In this way, the authentication process for the initial communication between the client and the server is divided into the following six steps:

  1. The client initiates a request to the AS, and the content of the request is: the principal of the client, the principal of the ticket authorization server

  2. After the AS receives the request, it randomly generates a password Kc, s (session key), and generates the following two tickets to return to the client:

    1. The ticket to the client, encrypted with the client’s password, the content is random password, session, tgs_principal

    2. The ticket to tgs, encrypted with the password of tgs, the content is random password, session, client_principal

  3. After the client gets the two tickets in the second step, it first unlocks the tickets with its own password to get Kc, s, and then generates an Authenticator, which mainly includes the current time and the check codes of Ts, c, and uses the SessionKey Kc,s encryption. After that, the client initiates a request to tgs, including:

    1. Authenticator

    2. The ticket to tgs is also issued to the server

    3. server_principal

  4. TGS first unlocks the ticket with its own password, gets the SessionKey Kc,s, then unlocks the Authenticator with Kc,s, and checks as follows

    1. Check if the timestamp in the Authenticator is within 5 minutes of the current time, and check if the timestamp appears for the first time. If the timestamp is not the first time, it means that someone intercepted the content sent by the client before and carried out a Replay attack.

    2. Check if the checksum is correct

    3. If all are correct, the client is authenticated

  5. Tgs generates a session key to assemble two tickets to the client

    1. Ticket encrypted with session key of client and tgs, including newly generated session key and server_principal

    2. A ticket encrypted with the server’s password, including the newly generated session key and client principal

  6. After the client receives the two tickets, it unlocks its own, then generates an Authenticator and sends a request to the server, including

    1. Authenticator

    2. ticket to server

  7. After the server receives the request, it unlocks the ticket with its own password, obtains the session key, and then unlocks the authenticator with the session key to verify it for no reason.

  8. The server may choose to return a timestamp encrypted with the session key to complete the two-way authentication

  9. The client verifies the server by unpacking the message and comparing whether the timestamp sent back is consistent with the timestamp sent by itself.

9.8.5. Advantages and disadvantages

9.8.5.1. Advantages

  • Passwords are not easy to be eavesdropped.

  • Password is not transmitted online.

  • Password guessing is harder.

  • Difficult to use after the ticket is stolen, because it needs to be used with the authentication header.

9.8.5.2. Disadvantages

  • Lack of revocation mechanism

  • Introduces complex key management

  • clock synchronization required

  • Scalability is limited