Use Kerberos 5 authentication on FreeBSD

Source: Perls Blog

Part 1 Introduction to Kerberos protocol
1. Kerberos protocol Introduction

In Greek mythology, Kerberos is the three dogs that guard the gate of hell. In the computer world, the Massachusetts Institute of Technology (MIT) named the network authentication system they developed as Kerberos. The Kerberos authentication protocol was first proposed and implemented by MIT in 1980s and is part of the Athena program of the school. Because Kerberos is a third-party authentication protocol, it verifies the identities of computers in the network based on a third-party service center called the Key Distribution Center (KDC) and establishes keys to ensure secure connections between computers. The Kerberos protocol is basically feasible and effective. KDC consists of the authentication server AS and the ticket authorization server TGS. Kerberos is a network authentication protocol that allows a computer to exchange encrypted messages to prove its identity with another computer on the entire non-secure network. Once the identity is verified, the Kerberos protocol will provide the keys for the two computers for secure communication. The Kerberos protocol can authenticate the identity of an online user and encrypt the communication between users by using the key and password. In general, Kerberos is a Network Authentication System Based on the private key encryption algorithm and requires a trusted third party as the authentication server. It allows entities that communicate on the network to prove each other's identities and prevent attacks by means of listening and replay. Moreover, it can protect the confidentiality and integrity of communication data.
Kerberos has gone through five versions since it was proposed. Among them, versions 1 to 3 are mainly used internally by the school. When it was developed to version 4, it has been widely recognized and applied outside the MIT campus. Due to the spread of version 4, people gradually discovered some of its limitations and shortcomings (such as limited network environments and redundancy in the encryption process ). MIT has fully absorbed these opinions and modified and expanded version 4 to form Version 5, which is a perfect version today. The latest implementation of Kerberos V5 that can be provided by MIT is krb5 1.3.3. The implementation mentioned in this article is based on it.

2. Kerberos protocol terminology

Principal: In Kerberos, Principal is the basic entity for authentication. In general, there are two types: one is used to represent users in the Kerberos database, the other is used to represent a specific host, that is, Principal is used to represent the entity of the client and the server, the Principal format adopts the ASN.1 standard, that is, Abstract Syntax Notation One, to accurately define). Principal consists of three parts: name, instance ), REALM (domain ). For example, a standard Kerberos user is name/instance @ REALM.
Name: the first part. In the case of customer representatives, it is a user name; in the case of host, it is written as host.
Instance: the second part. Further description of the name, such as the host name or type of the name, can be omitted. It is separated by/From the first part, but is written as host/Instance as the host description.
Realm: Part 3. It is the Management Division of Kerberos. A domain database in KDC is called Realm. The database stores all prinal Al and their keys in the network. The database content is used by the Kerberos authentication server AS and the ticket authorization server TGS. Generally, Realm is an uppercase character. In most Kerberos system configurations, Realm is consistent with the DNS domain in the network environment. Use @ to separate them from the second part. The default value is local Realm.
For example, Principal "cnhawk/hawk.the9.com@THE9.COM" represents the user cnhawk on host hawk.the9.com in Realm "THE9.COM, principal "host/hawk.the9.com @ THE9.COM" is usually used to indicate the host hawk.the9.com in Realm "THE9.COM.

Credential: the combination of Ticket and the session key associated with it is called Credential. The reason for this concept is that they are two things required by the client to prove their identity to the server. during the lifetime of a Ticket, the client saves these two items in a Cache file in Credential units.

Ticket: a Ticket is a set of information used to securely pass user identities. It not only contains the identity of the user, but also contains other related information. In general, it mainly includes the Principal of the customer, the Principal of the target service, the IP address of the customer, the timestamp (the time when the Ticket is distributed), the lifetime of the Ticket, and the session key. Its format is also accurately defined using ASN.1.

Authenticator: when the client authenticates to the server, another part sent along with Ticket is used to prove that the user who sends Ticket is the user who owns Ticket, that is, to prevent replay attacks. Its main content is a timestamp (the time when the client sends Ticket), which has its complete ASN.1 definition in rfc1510.

AS (Authentication Server): a Server that distributes TGT (Ticket Granting Ticket) to users.

TGT (Ticket Granting Ticket): the Ticket that the user certifies to TGS (Ticket Granting Server.

TGS (Ticket Granting Server): the Server that delivers the final purpose Ticket to the user. The user uses this Ticket to prove his identity to the Server that requests the service. In terms of implementation, AS and TGS are actually completed by the same program, because their implementation mechanisms are not very different, only the keys used for the encrypted Ticket are different (AS uses the user's key while TGS uses the session key ).

KDC (Key Distribution Center): A Key Distribution Center. Generally, AS and TGS are collectively referred to as kdc. Sometimes, AS is also called as kdc separately.

3. authentication process

1) Client → KDC: the user cnhawk applies to the Key Distribution Center (KDC) for TGT;
2) KDC → Client: Pass the KDC User Password Authentication and cnhawk receives the TGT issued by KDC;
3) Client → KDC: Apply to obtain the host/s required by cnhawk;
4) KDC → Client: KDC issues host/s to cnhawk Based on The TGT provided by cnhawk;
5) Client → Server: the user cnhawk provides the Server with cnhawk, TGT, and host/s; the Server verifies the cnhawk login application based on the host/s stored on the host and the user's cnhawk information.
6) Server → Client: confirm the Server and send the message to the Client to allow cnhawk to log on to the Server.

4. One application instance

For A clearer description of the Kerberos 5 authentication protocol, the example in the actual application (the specific example can be seen in the actual application below): Assume that A Local Area Network, its DNS domain is the9.com; Realm is THE9.COM; Kerberos databases, AS and TGS servers are all on the host test1.the9.com. The prinal Al corresponding to user cnhawk on host test2.the9.com in a is cnhawk/test2.the9.com@THE9.COM; the Principal corresponding to the telnet server on another host test3.the9.com in a is host/test3.the9.com@THE9.COM. The client program telnet of Rlogin and the server program telnetd both support Kerberos, that is, both support Kerberos authentication protocol. Cnhawk wants to use telnet to remotely log on to another host test3.the9.com in A. The steps to complete cnhawk are as follows:

① Run the kinit program. The kinit program applies for TGT from AS and stores the obtained TGT and session key in the file that saves Credential. To do this, cnhawk type on the command line:

% Kinit cnhawk/test1.the9.com
After the kinit program receives a message from the AS, it prompts cnhawk to enter the password:

% Kinit cnhawk/test1.the9.com cnhawk/test1.the9.com@THE9.COMs Password:
After cnhawk correctly enters the password, the kinit program converts the password into a cnhawk key using the agreed algorithm, and decrypts the message sent from TGS with this key to obtain the Credential used in the next step. At this point, the kinit program has ended. It can be seen that the cnhawk password is not transmitted on the Internet, and it is transmitted only after the cnhawk key is encrypted.

② Run the telnet client program. For this reason, cnhawk type on the command line:

Test1 # telnet-a-l cnhawk test3.the9.com the telnet program first searches for the expired TGT in the file that saves Credential, and submits it to TGS to obtain the Ticket that accesses the rlogin service on test3.the9.com. Next, it sends the Ticket and Authenticator together to the server program telnetd of test3.the9.com. After verifying the cnhawk identity, telnetd searches for files in the local cnhawk home directory ". k5login ", in ". the k5login file contains Principal that allows you to remotely log on to the cnhawk account with rlogin. After finding the cnhawk/test1.the9.com@THE9.COM, telnetd applies for a virtual terminal and fork a shell, then the test1.the9.com terminal will display:
Test1 # telnet-a-l cnhawk test3.the9.com
Trying test3.the9.com...
Connected to test3.the9.com.
Escape character is ^].
[Trying mutual KERBEROS5 (host/test3.the9.com@THE9.COM)...]
[Kerberos V5 accepts you as ''cnhawk/test1.the9.com@THE9.COM]

FreeBSD/i386 (test3.the9.com) (ttyp1)
% Id
Uid = 1001 (cnhawk) gid = 0 (wheel) groups = 0 (wheel)

Part 2 installation and Application of Kerberos 5
1. System Installation

Two FreeBSD 5.2.1 systems need to be installed. I have installed one FreeBSD 4.9 system on a virtual machine.
Test Machine
Operating System: FreeBSD test1.the9.com 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23 20:45:55 GMT 2004 root@wv1u.btc.adaptec.com:/usr/obj/usr/src/sys/GENERIC i386
IP Address: 192.168.0.2
Machine name: test1.the9.com
Test Machine B
Operating System: FreeBSD test2.the9.com 4.9-RELEASE FreeBSD 4.9-RELEASE #0: Mon Oct 27 17:51:09 GMT 2003 root@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/GENERIC i386
IP Address: 192.168.0.3
Machine name: test2.the9.com
Test Machine C:
Operating System: FreeBSD test3.the9.com 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23 20:45:55 GMT 2004