PRACTICAL-10 AIM: Study of Kerberos system.

An Introduction to Kerberos Kerberos is a system of authentication developed at MIT as part of the Athena project. Kerberos uses encryption technology and a trusted third party, an arbitrator, to perform secure authentication on an open network. Specifically, Kerberos uses cryptographic tickets in order to avoid transmitting plain text passwords over the wire. Kerberos was based upon the NeedhamSchroeder protocol. There are two versions of Kerberos currently in use, version 4 and version 5. Kerberos versions 1 through 3 were internal development versions and never released. Kerberos version 4 has a number of known weaknesses and should no long be used. This document deals only with Kerberos 5. Kerberos 5 is defined in RFC1510. The term Kerberos Infrastructure refers to the software, servers, and client configurations that will allow an administrator to use the Kerberos protocol to perform authentication on their network. Specifically, Kerberos Infrastructure consists of the Kerberos software itself, secured redundant authentication servers, a centralized account and password store, and systems configured to authenticate through the Kerberos protocol. This document will take you through the steps to install, configure, and deploy such an infrastructure. The Benefits of Kerberos For individuals unfamiliar with the Kerberos protocol, the benefits of deploying it in their network may not be clear. However, all administrators are familiar with the problems Kerberos was designed to mitigate. Those problems include, password sniffing, password filename/database stealing, and the high level of effort necessary to maintain a large number of account databases. A properly deployed Kerberos Infrastructure will help you address these problems. It will make your enterprise more secure. Use of Kerberos will prevent plaintext passwords from being transmitted over the network. The Kerberos system will also centralize your username and password information which will make it easier to maintain and manage this data. Finally, Kerberos will also prevent you from having to store password information locally on a machine, whether it is a workstation or server, thereby reducing the likelihood that a single machine compromise will result in additional compromises. To summarize, in a large enterprise, the benefits of Kerberos will translate into reduced administration costs through easier account and password management and through improved network security. In a smaller environment, scalable authentication infrastructure and improved network security are the clear benefits. How Kerberos Works Kerberos is an authentication protocol which uses a shared secret and a trusted third party arbitrator in order to validate the identity of clients. In Kerberos, clients may be users, servers, or pieces of software. The trusted third party arbitrator is a server known as a Key Distribution

Center (KDC) which runs the Kerberos daemons. The shared secret is the users password transformed into a cryptographic key. In the case of servers or software systems, a random key is generated. In Kerberos, users are known as principals. The KDC has a database of principals and their secret keys which is uses to perform authentication. In Kerberos knowledge of the secret key is considered sufficient for proof of identity. Since knowledge of a secret key translates into proof of identity in Kerberos, the Kerberos server can be trusted to authenticate any client to any other client. Authentication is Kerberos is done with out sending any clear text passwords across the wire. Below I'll explain how the Kerberos protocol maps to the GNU/Linux Kerberos software. The KDC runs two important Kerberos daemons. These daemons are kadmind and krb5kdc. While GNU/Linux daemon naming conventions suggests that processes which have names starting with "k" are Kernel related or Kernel space processes, this is not true in the case of krb5kdc and kadmind. These two daemons are run as root in user space. kadmind is the administrative daemon for the Kerberos server. kadmind is used by a program named kadmin to maintain the database of principals and policy configuration. If you choose to disallow any remote logins via ssh on your Kerberos hardware, kadmin will allow you to remotely administer the Kerberos components of the server. krb5kdc is the workhorse of the Kerberos server. It is responsible for performing the role of the trusted third party arbitrator in Kerberos authentication. When a user wants to authenticate himself to a system or service, the user requests a ticket from the KDC. A ticket is a datagram consisting of the client's identity, a session key, a timestamp, and some other information. The datagram is encrypted with the server's secret key. In detail that process works as follows, first the request for authentication is sent to the krb5kdc daemon. When the daemon received this request, it looks up the client, the principal, trying to authenticate in the principal database. It reads the clients secret key from this database and encrypts a special ticket called a Ticket Granting Ticket (TGT) which it then sends back the client. The client receives this encrypted TGT which contains a session key. If the client knows the password (the secret key stored in the principal database) and can successfully decrypt the TGT, it can present the ticket encrypted with the enclosed session key to a Ticket Granting Service (TGS). The TGS will then issue a subsequent ticket which will provide the client with the authentication they need to use a specific system or service. Through the use of encrypted tickets which can only be decrypted if the client knows the secret key, secure authentication takes place. Time stamp information is included in the tickets to prevent replay attacks. A replay attack would be the fraudulent representation of a previously issued ticket in order to gain unauthorized access. Compromise of Kerberos Infrastructure The primary way in which an attacker will attempt to compromise a Kerberos Infrastructure would be to attack the Kerberos servers. If an attacker can gain root access to a KDC, the attacker will have access to the database of encrypted passwords of the principals. The attacker will also have access to the Kerberos software and configuration files both of which they can then modify to make the system perform authentications which should not be successful.

Other methods of attacking Kerberos infrastructure include replay attacks and passwordguessing attacks. A replay attack would involve intercepting or otherwise acquiring a Kerberos ticket and then fraudulently representing that ticket in an attempt to gain authentication. Password guessing in a Kerberos system could be done by intercepting Kerberos tickets from the network and then making a brute force attempt to decrypt the intercepted tickets. An attacker may exploit outdated software in the infrastructure. For example, there are many problems with Kerberos version 4. Most importantly, Kerberos version 4 has a basic protocol weakness in the encryption used. The design of Kerberos 4 included the use of DES in standard mode which allows attackers to intercept and modify the ciphertext of Kerberos tickets in an undetectable way. In order to prevent these attacks, Kerberos 5 has been modified to use triple DES in Cipher Block Chaining (CBC) mode. When discussing the strength of Kerberos 4, it is also important to note that many implementations of Kerberos version 4 have buffer overflow vulnerabilities. While the reference implementations of version 5 fixed the buffer overflow weaknesses in version 4, distributions of Kerberos 5 usually ship with software to provide backward compatibility to support legacy Kerberos 4 applications. Some of the backward compatibility code for version 4 support in Kerberos version 5 releases is still believed to be vulnerable to buffer overflow attacks. Therefore, due to the protocol weaknesses in version 4 and the potential for buffer overflow attacks with version 4 implementations and version 4 backward compatibility code, it is best not to support or use Kerberos version 4. In summary, from this description on how a Kerberos infrastructure can be compromised, we realize that we must give great priority to the security of the Kerberos servers themselves, run up to date Kerberos software, and remain vigilant in picking good passwords and in setting good password policy.

Installing and Configuration

General Machine Configuration Overview This section of the document describes the installation and configuration of the machines and software which will function as the KDCs. You may want to make some adjustments to the configurations suggested, but there are a few key points presented that are very important to remember when configuring your KDCs. So, if you do decide on an alternative configuration strategy make sure you understand the material presented here. The machines will run the Kerberos daemon and store password and policy data. Therefore, it's very important to the security of the network that these servers remain secure. We should take every possible measure to prevent these servers from being compromised. Pay particular attention to the security advice given in this section. The key points of that security advice are that you should dedicate hardware to providing Kerberos KDC service. You should physically secure that hardware, and you should harden GNU/Linux as much as possible on that hardware. If a KDC is compromised, your entire Kerberos infrastructure is compromised.

Hardware Kerberos service does not place a great demand on hardware and the Kerberos services have a capability for redundancy, therefore server hardware can be minimal. For the Kerberos servers which I've deployed I've used uni processor PIII machines with two hardware RAID 1 drives. These machines are meant to handle between forty and one hundred thousand authentications per day. While servers may be deployed with redundant NIC cards, having both cards active simultaneously should be avoided. Kerberos includes the IP of the KDC in tickets, therefore difficulties authenticating may occur if the KDC is contacted on multiple interfaces by a client during an authentication session. It is important to note that Kerberos service should be run on dedicated hardware. Dedicating a machine to Kerberos means that only the Kerberos administrator will need to log in on those machines. It also means that no other services, except perhaps SSH, will be run on the machines. Since all of your users passwords are stored on the Kerberos servers, it is a good idea to limit access as much as possible to the hardware. Along with dedicating servers to Kerberos, you should also physically secure your servers as much as possible. For Kerberos servers, this may include locking the servers in a cabinet and having a dedicated terminal attached to them. In order to take advantage of Kerberos' built in capability for redundancy, you must have at least two machines running as KDCs. Kerberos is designed to be deployed with one primary master server, and one or more secondary slave servers. You may have as many secondary servers as you would like. GNU/Linux Installation The servers we're installing GNU/Linux on will be dedicated to the task of performing Kerberos service, therefore we can take some extra steps to secure them. First, we'll only install software that is absolutely necessary for Kerberos service. This includes the base operating system and the Kerberos packages. We should not install X or any GUI applications. SSH is optional. SSH may be installed if you wish to be able to administer the servers remotely. However, the servers would be significantly more secure if you only provide login access to them through an attached terminal. In Fedora Core based GNU/Linux, the packages required to provide Kerberos service are:
krb5-server krb5-libs

Documentation and development libraries should not be installed on the KDC, since we do not want to use this machine for anything but the performance of KDC service. The next step will be to make sure that no ports are open that do not need to be and that any necessary security patches that are needed are applied. The methodology to determining what security patches need to be applied is depended up what package management software is installed. To determine what ports the machine is currently listening on, the netstat command can be used. For example, on a machine which only ssh running we should see the following:

bash$ netstat -an | grep -i listen | less tcp 0 0 0.0.0.0:22

0.0.0.0:*

LISTEN

Finally, we'll configure the server to restrict access only to servers that need to talk to it for authentication. This should be done by editing /etc/hosts.allow and /etc/hosts.deny as well as with iptables. Choosing A Realm Realm names are case sensitive and must be unique on your network. It is a standard best practice to use your second level domain name in all uppercase letters as your realm name. If you are setting up Kerberos for only a subnet rather than your entire network, you should use the trailing domain name of the subnet. When determining your realm topology, you should take the overall structure of your organization into account. If your organization has one or more remote offices or independent sub groups, they may be best included under a separate realm. Kerberos realm topology should mirror system management topology rather than physical network topology. Finally, legacy systems should also be taken into account. For example, legacy Kerberos deployments or existing network topology grouping which you wish to preserve (i.e. Windows NT domains). If you are installing Kerberos on a network which already has Kerberos deployed in the overall network or in a subnet, you must avoid a realm name collision. The most common occurrence of deploying Kerberos on a network with a preexisting Kerberos installation occurs when working with a network that includes an IBM SP cluster. The best solution is to create a realm specifically for the SP cluster at third or high domain name level and then use a second level domain name for your primary Kerberos realm. In this document, we'll use an example to help illustrate the design and configuration of an infrastructure. For our example, we'll use a mythical university which was founded to educate people with, and perform research in the area of, free content - Gnu University in Dublin, Ireland. The Gnu University Dublin example will include two Kerberos servers used to authenticate students and faculty. The TLD for the university is gnud.ie, therefore we'll use the Kerberos realm of GNUD.IE. Kerberos Software Configuration Now, you'll need to configure Kerberos, create an administrator, determine a policy, and initialize the Kerberos principal database. The first step is to edit the /etc/krb5.conf configuration file. In this file you'll need to set your realm, expand on the realm definition by specifying the Kerberos servers, and finally setting the domain realm. For our example, this is done as follows:
default_realm = GNUD.IE [realms]

GNUD.IE = { kdc = kerberos1.gnud.ie:88 kdc = kerberos2.gnud.ie:88 admin_server = kerberos1.gnud.ie:749 default_domain = gnud.ie } [domain_realm] .gnud.ie = GNUD.IE gnud.ie = GNUD.IE

To initialize and create the Kerberos database, you must run the follow command:
{Kerberos1}bash# /usr/Kerberos/sbin/kdb5_util create -s

The -s flag tell the KDC to create a stash file to authenticate itself. You may also use a -r flag to specify a realm. Specifying a realm for the new database is only necessary if you have more than one realm defined in your krb5.conf file. Kerberos will then ask you to set the master password for your Kerberos database. It is very important that you do not forget this password. You will not be able to administrate your server if you do not remember the master password. Next on the KDC you must edit the acl file to grant administrative access. Typically, this file is located at /var/Kerberos/krb5kdc/kadm5.acl. If necessary, specify the acl file location in your kdc.conf file. The location of your kdc.conf file is specified in your /etc/krb5.conf file and defaults to /var/Kerberos/krb5kdc/kdc.conf. For our GNU University Dublin example, we'll modify the acl file to include the following contents:
*/admin@GNUD.IE *

The meaning of those acl contents are that any account which ends with a /admin in the GNUD.IE realm is granted full access privileges. Now that we've set up access for our administrative user, we need to create that administrative user. You can do this with the kadmin.local command from a root shell on the KDC, using the addprinc sub command. The standard is to name the administrative account admin. For the Gnu University Dublin Kerberos Administrator, the following command would accomplish this:
{Kerberos1}bash# /usr/Kerberos/sbin/kadmin.local -q "addprinc admin/admin"

The daemons that must run on the server are krb5kdc and kadmin. If necessary, krb524 may also be run to provide backward compatibility to Kerberos 4 clients. However, before starting krb524 remember our security warning about Kerberos V4 and be sure that you really need to provide that functionality. On the KDCs krb5kdc and kadmin should be configured to start automatically by turning them on with the chkconfig command.
{Kerberos1}bash# /sbin/chkconfig krb5kdc on {Kerberos1}bash# /sbin/chkconfig kadmin on

Finally, we can start them up manually, with the following command:

{Kerberos1}bash# /etc/rc.d/init.d/krb5kdc start {Kerberos1}bash# /etc/rc.d/init.d/kadmin start

and we have a working KDC. Principal Creation You can create the first user principal in Kerberos with the following command:
{Kerberos1}bash# kadmin.local {Kerberos1}kadmin.local: addprinc <username>

A script could be written to create principals in bulk if you have a large number of accounts which you will be supporting with Kerberos.