Part 1 Kerberos protocol introduction 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 the Massachusetts Institute of Technology (MIT) in 1980s. it is A FreeBSDKerberos
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. Separate with the second part with '@'. the default value is local Realm.
For example, Principal "cnhawk/hawk.the9.com@THE9.COM" indicates 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.COM's 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 Credential-saving file and submits it to the 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 the file ". 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 root@wv1u.btc.adaptec.com:/usr/obj/usr/src/sys/GENERIC i386
IP address: 192.168.0.4
Machine name: test3.the9.com
2. Kerberos 5 software installation and configuration
Kerberos 5 is installed directly in ports, and the latest version is the krb5-1.3.1_1.
Install on test machine
Test1 # cd/usr/ports/security/krb5/
Test1 # make & make install
Install FreeBSD 4.9 on test server B. select krb5 during installation.
Install DNS on B
Test2 # cd/usr/ports/dns/bind9
Test2 # make & make install
Install on test machine C
Test3 # cd/usr/ports/security/krb5/
Test3 # make & make install
We chose test machine A as the KDC server and test machine B as the client.
Now, log on to test machine A and add the following two items to/etc/rc. conf:
Export os5_server_enable = "YES"
Kadmind5_server_enable = "YES"
In this way, the server can directly start the os5 service after the next restart, and then create/etc/krb5.conf with the following content added;
[Libdefaults]
Default_realm = THE9.COM
[Realms]
THE9.COM = {
Kdc = test1.the9.com
Admin_server = test1.the9.com
Default_domain = the9.com
}
[Domain_realm]
.The9.com = THE9.COM
[Logging]
Default = FILE:/var/log/krb5libs. log
Kdc = FILE:/var/log/krb5kdc. log
Admin_server = FILE:/var/log/kadmind. log
Because Kerberos needs to resolve domain names to each other, set DNS, and be able to resolve addresses to each other.
Log on to test machine B,
Copy/etc/krb5.conf on test machine A to test machine B and test machine C;
3. debugging and deployment of Kerberos 5
At the same time, reboot drops the two systems. after the machine is started, it needs to synchronize the time of the two servers. The time is very important for Kerberos, and the default time offset allowed by Kerberos is very small, if the time difference between the two servers exceeds the Kerberos value, you cannot obtain the ticket from the KDC server. I wrote a script to regularly synchronize the time on the server. Start to operate on test machine A after the completion of the time;
Test1 # kstash
Master key: hawk
Verifying password-Master key: hawk
Test1 # kadmin-l
Kadmin> init THE9.COM // add the default domain name to be consistent with that in krb5.conf.
Realm max ticket life [unlimited]:
Kadmin> add cnhawk/test1.the9.com // directly enter the user name/the user who specifies which host this is, use cnhawk/test1.the9.com@THE9.CON when logging on
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
Password: hawk
Verifying password-Password: hawk
Kadmin> exit
Hawk #
After the user is added, perform a local test.
Hawk # kinit cnhawk/test1.the9.com@THE9.COM
Cnhawk/test1.the9.com@THE9.COM's Password:
Hawk # klist-f
Credentials cache: FILE:/tmp/krb5cc_0
Principal: cnhawk/test1.the9.com@THE9.COM
Issued Expires Flags Principal
Jun 7 17:12:21 Jun 8 03:12:21 I krbtgt/THE9.COM@THE9.COM
We can see that the local ticket has been obtained.
Add the domain name information of test machine B below, that is, allow test machine B to log on to test machine. Note that Kerberos must use a domain name to access the machine. If you use IP addresses to add hosts, some unexpected problems may occur.
Test1 # kadmin-l
Kadmin> add -- random-key host/test1.the9.com // indicates that the host is not a user.
Max ticket life [1 day]:
Max renewable life [1 week]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes []:
Kadmin> ext host/test1.the9.com
Kadmin> ext -- keytab =/tmp/the9.keytab host/test1.the9.com
After this is done, the basic configuration is complete and can be used.
Debugging
We started to deploy network services using Kerberos authentication. Note that by modifying the. klogin and. k5login files in the user's main directory, you can add the user Principal you are allowed to log on to the file.
Test1 # cat. k5login
# $ FreeBSD: src/etc/root/dot. k5login, v 1.1 2003/04/30 20:58:49 markm Exp $
#
# User1/root@YOUR.REALM.WHEREVER
# User2/root@YOUR.REALM.WHEREVER
Test1.the9.com@THE9.COM/cnhawk
In this way, you can
Use Kerberos-authenticated telnet
Modify/etc/inetd. conf to add
Telnet stream tcp nowait root/usr/libexec/telnetd-a user
Enable
Test2 # inetd
Then log on to test2 from test1.
Test1 # kinit cnhawk/test1.the9.com // Obtain the ticket first
Cnhawk/test1.the9.com@THE9.COM's Password:
Test1 # klist-f // check whether the command is obtained.
Credentials cache: FILE:/tmp/krb5cc_0
Principal: cnhawk/test1.the9.com@THE9.COM
Issued Expires Flags Principal
Jun 11 16:21:36 Jun 12 02:21:36 I krbtgt/THE9.COM@THE9.COM
// Yes
Test1 # telnet-a-l the9 192.168.0.3 // start logging on
Trying 192.168.0.3...
Connected to test2.the9.com.
Escape character is '^]'.
[Trying mutual KERBEROS5 (host/test2.the9.com@THE9.COM)...]
[Kerberos V5 accepts you as ''cnhawk/test1.the9.com@THE9.COM '']
FreeBSD/i386 (test2.the9.com) (ttyp1)
// Login welcome word
% Id
Uid = 1001 (the9) gid = 0 (wheel) groups = 0 (wheel)
% // Success
Use Kerberos-authenticated ssh
Modify the sshd configuration file for test A, B, and C.
# Kerberos options
Osaosauthentication yes
KerberosOrLocalPasswd yes
Then restart sshd.
Test2 # kill-HUP 80
Log on to test2 from test1. because only ssh1 supports Kerberos, use the ssh1 connection to enable debug information at the same time.
Test1 # ssh-1 v the9@test2.the9.com
OpenSSH_3.6.1p1 FreeBSD-20030924, SSH protocols 1.5/2.0, OpenSSL 0x0090703f
Debug1: Reading configuration data/etc/ssh/ssh_config
Debug1: Rhosts Authentication disabled, originating port will not be trusted.
Debug1: Connecting to test2.the9.com [192.168.0.3] port 22.
Debug1: Connection established.
Debug1: identity file/root/. ssh/identity type-1
Debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1 FreeBSD-20030924
Debug1: match: OpenSSH_3.5p1 FreeBSD-20030924 pat OpenSSH *
Debug1: Local version string SSH-1.5-OpenSSH_3.6.1p1 FreeBSD-20030924
Debug1: Waiting for server public key.
Debug1: encrypted Ed server public key (768 bits) and host key (1024 bits ).
Debug1: Host 'test2 .the9.com 'is known and matches the RSA1 host key.
Debug1: Found key in/root/. ssh/known_hosts: 3
Debug1: Encryption type: 3des
Debug1: Sent encrypted session key.
Debug1: Installing crc compensation attack detector.
Debug1: encrypted Ed encrypted confirmation.
Debug1: Trying Kerberos v5 authentication.
Debug1: Kerberos v5 authentication accepted.
Debug1: Requesting pty.
Debug1: Requesting shell.
Debug1: Entering interactive session.
Last login: Fri Jun 11 16:31:14 2004 from test1.the9.com
Copyright (c) 1980,198 3, 1986,198 8, 1990,199 1, 1993,199 4
The Regents of the University of California. All rights reserved.
FreeBSD 4.9-RELEASE (GENERIC) #0: Mon Oct 27 17:51:09 GMT 2003
FreeBSD/i386 (test2.the9.com) (ttyp1)
// Login welcome word
% Id
Uid = 1001 (the9) gid = 0 (wheel) groups = 0 (wheel)
% // Success
The test has been completed. You can use Kerberos.
Ftp service
% Kinit cnhawk/test1.the9.com
Cnhawk/test1.the9.com @ THE9.COM's Password:
% Klist-f
Credentials cache: FILE:/tmp/krb5cc_1001
Principal: cnhawk/test1.the9.com@THE9.COM
Issued Expires Flags Principal
Jun 11 18:49:56 Jun 12 04:49:56 I krbtgt/THE9.COM@THE9.COM
%/Usr/local/bin/ftp-v hawk.the9.com
Connected to hawk.the9.com.
220 hawk.the9.com FTP server (Version 5.60) ready.
334 Using authentication type GSSAPI; ADAT must follow
GSSAPI accepted as authentication type
GSSAPI authentication succeeded
Name (hawk.the9.com: cnhawk ):
232 GSSAPI user cnhawk@THE9.COM is authorized as cnhawk
Remote system type is UNIX.
Using binary mode to transfer files.
Ftp>
FTP can also be logged on.
Summary
Pay attention to some points during Kerberos usage. for example, time must be synchronized, because Kerberos maintains synchronization based on timestamps, and the amount of time overflow allowed is very small. Therefore, the time must be accurate.
Cnhawk # kinit cnhawk/test1.the9.com@THE9.COM
Cnhawk/test1.the9.com@THE9.COM's Password:
Kinit: krb5_get_init_creds: time skew (314) larger than max (300)
Cnhawk # ntpdate time.the9.com
7 Jun 16:59:49 ntpdate [623]: step time server 61.129.93.5 offset 211.348035 sec
Cnhawk # kinit cnhawk/test1.the9.com @ THE9.COM
Cnhawk/test1.the9.com@THE9.COM's Password:
In addition, you often need to check whether the ticket has expired before logging on.
Hawk # klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: cnhawk/test1.the9.com@THE9.COM
Issued Expires Principal
Jun 7 17:19:25> Expired <krbtgt/THE9.COM@THE9.COM
Jun 7 17:20:23> Expired
At the same time, make sure that both user information and host information are stored on the KDC central database. In this way, the user can log on to the server smoothly after obtaining the ticket.
