| SUSE LINUX – Administration Guide Chapter 19. Security in the Network / 19.3. Network Authentication — Kerberos | ||||
|---|---|---|---|---|
 | 19.2. SSH — Secure Shell, the Safe Alternative | 19.4. Installing and Administering Kerberos |  | |
| SUSE LINUX – Administration Guide Chapter 19. Security in the Network / 19.3. Network Authentication — Kerberos | ||||
|---|---|---|---|---|
| 19.2. SSH — Secure Shell, the Safe Alternative | 19.4. Installing and Administering Kerberos | | |
An open network provides no means to ensure that a workstation can identify its users properly except the usual password mechanisms. In common installations, the user must enter the password each time a service inside the network is accessed. Kerberos provides an authentication method with which a user must register once and is then trusted in the complete network for the rest of the session. To have a secure network, the following requirements must be met:
Have all users prove their identity for each desired service and make sure no one can take the identity of someone else.
Make sure each network server also proves its identity. If you do not, an attacker might be able to impersonate the server and obtain sensitive information transmitted to the server. This concept is called mutual authentication, because the client authenticates to the server and vice versa.
Kerberos helps you meet the above requirements by providing strongly encrypted authentication. The following shows how this is achieved. Only the basic principles of Kerberos are discussed here. For detailed technical instruction, refer to the documentation provided with your implementation of Kerberos.
![[Important]](admon/important.png) | Important |
|---|---|
The original Kerberos was designed at the MIT. Besides the MIT Kerberos, several other implementations of Kerberos exist. SUSE LINUX ships with a free implementation of Kerberos 5, the Heimdal Kerberos 5 from KTH. Because the following text covers features common to all versions, the program itself is referred to as Kerberos as long as no Heimdal-specific information is presented. | |
The following glossary defines some Kerberos terminology.
Users or clients need to present some kind of credentials that authorize them to request services. Kerberos knows two kinds of credentials — tickets and authenticators.
A ticket is a per-server credential used by a client to authenticate at a server from which it is requesting a service. It contains the name of the server, the client's name, the client's Internet address, a time stamp, a lifetime, and a random session key. All this data is encrypted using the server's key.
Combined with the ticket, an authenticator is used to prove that the client presenting a ticket is really the one it claims to be. An authenticator is built of the client's name, the workstation's IP address, and the current workstation's time all encrypted with the session key only known to the client and the server from which it is requesting a service. An authenticator can only be used once, unlike a ticket. A client can build an authenticator itself.
A Kerberos principal is a unique entity (a user or service) to which it can assign a ticket. A principal consists of the following components:
primary — the first part of the principal, which can be the same as your user name in the case of a user.
instance — some optional information characterizing the primary. This string is separated from the primary by a /.
realm — this specifies your Kerberos realm. Normally, your realm is your domain name in uppercase letters.
Kerberos ensures that both client and server can be sure of each others identity. They share a (session) key, which they can use to communicate securely.
Session keys are temporary private keys generated by Kerberos. They are known to the client and used to encrypt the communication between the client and the server for which it requested and received a ticket.
Almost all messages sent in a network can be eavesdropped, stolen, and resent. In the Kerberos context, this would be most dangerous if an attacker manages to obtain your request for a service containing your ticket and authenticator. He could then try to resend it (replay) to impersonate you. However, Kerberos implements several mechanisms to deal with that problem.
Service is used to refer to a specific action to perform. The process behind this action is referred to as a server.
Kerberos is often called a third party trusted authentication service, which means all its clients trust Kerberos's judgment of another client's identity. Kerberos keeps a database of all its users and their private keys.
To ensure Kerberos is worth all the trust put in it, run both the authentication and ticket-granting server on a dedicated machine. Make sure only the administrator can access this machine physically and over the network. Reduce the (networking) services run on it to the absolute minimum — do not even run sshd.
Your first contact with Kerberos is quite similar to any login procedure at a normal networking system. Enter your user name. This piece of information and the name of the ticket-granting service are sent to the authentication server (Kerberos). If the authentication server knows about your existence, it will generate a (random) session key for further use between your client and the ticket-granting server. Now the authentication server prepares a ticket for the ticket-granting server. The ticket contains the following information — all encrypted with a session key only the authentication server and the ticket-granting server know:
the names both of the client and the ticket-granting server
the current time
a lifetime assigned to this ticket
the client's IP address
the newly-generated session key
This ticket is then sent back to the client together with the session key, again in encrypted form, but this time the private key of the client is used. This private key is only known to Kerberos and the client, because it is derived from your user password. Now that the client has received this response, you are prompted for your password. This password is converted into the key that can decrypt the package sent by the authentication server. The package is “unwrapped” and password and key are erased from the workstation's memory. As long as the lifetime given to the ticket used to obtain other tickets does not expire, your workstation can prove your identity.
To request a service from any server in the network, the client application needs to prove its identity to the server. Therefore, the application generates an authenticator. An authenticator consists of the following components:
the client's principal
the client's IP address
the current time
a checksum (chosen by the client)
All this information is encrypted using the session key that the client has already received for this special server. The authenticator and the ticket for the server are sent to the server. The server uses its copy of the session key to decrypt the authenticator, which gives him all information needed about the client requesting its service to compare it to that contained in the ticket. The server checks if the ticket and the authenticator originate from the same client.
Without any security measures implemented on the server side, this stage of the process would be an ideal target for replay attacks. Someone could try to resend a request stolen off the net some time before. To prevent this, the server will not accept any request with a time stamp and ticket received previously. In addition to that, a request with a time stamp differing too much from the time the request is received can be ignored.
Kerberos authentication can be used in both directions. It is not only a question of the client being the one it claims to be. The server should also be able to authenticate itself to the client requesting its service. Therefore, it sends some kind of authenticator itself. It adds one to the checksum it received in the client's authenticator and encrypts it with the session key, which is shared between it and the client. The client takes this response as a proof of the server's authenticity and they both start cooperating.
Tickets are designed to be used for one server at a time. This implies that you have to get a new ticket each time you request another service. Kerberos implements a mechanism to obtain tickets for individual servers. This service is called the “ticket-granting service”. The ticket-granting service is a service just like any other service mentioned before, so uses the same access protocols that have already been outlined. Any time an application needs a ticket that has not already been requested, it contacts the ticket-granting server. This request consists of the following components:
the requested principal
the ticket-granting ticket
an authenticator
Like any other server, the ticket-granting server now checks the ticket-granting ticket and the authenticator. If they are considered valid, the ticket-granting server builds a new session key to be used between the original client and the new server. Then the ticket for the new server is built, containing the following information:
the client's principal
the server's principal
the current time
the client's IP address
the newly-generated session key
The new ticket is assigned a lifetime, which is the lesser of the remaining lifetime of the ticket-granting ticket and the default for the service. The client receives this ticket and the session key, which are sent by the ticket-granting service, but this time the answer is encrypted with the session key that came with the original ticket-granting ticket. The client can decrypt the response without requiring the user's password when a new service is contacted. Kerberos can thus acquire ticket after ticket for the client without bothering the user more than once at login time.
Windows 2000 contains a Microsoft implementation of Kerberos 5. As SUSE LINUX makes use of the Heimdal implementation of Kerberos 5, find useful information and guidance in the Heimdal documentation. See Section 19.3.4. “For More Information”.
Ideally, a user's one and only contact with Kerberos happens during login at his workstation. The login process includes obtaining a ticket-granting ticket. At logout, a user's Kerberos tickets are automatically destroyed, which hinders anyone else from impersonating this user when not logged in. The automatic destruction of tickets can lead to a somewhat awkward situation when a user's login session lasts longer than the maximum lifespan given to the ticket-granting ticket (a reasonable setting is ten hours). However, the user can get a new ticket-granting ticket by running kinit. Enter the password again and Kerberos obtains access to desired services without additional authentication. Those interested in a list of all the tickets silently acquired for them by Kerberos should run klist.
Here is a short list of some applications that use Kerberos authentication. These applications can be found under /usr/lib/heimdal/bin. They all have the full functionality of their common UNIX and Linux brothers plus the additional bonus of transparent authentication managed by Kerberos:
telnet, telnetd
rlogin
rsh, rcp, rshd
popper, push
ftp, ftpd
su
imapd
pine
You no longer have to type your password for using these applications because Kerberos has already proven your identity. ssh, if compiled with Kerberos support, can even forward all the tickets acquired for one workstation to another one. If you use ssh to log in to another workstation, ssh makes sure the encrypted contents of the tickets are adjusted to the new situation. Simply copying tickets between workstations is not sufficient as the ticket contains workstation-specific information (the IP address). XDM and KDM offer Kerberos support, too. Read more about the Kerberos network applications in the Kerberos V5 UNIX User's Guide at http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3/doc/krb5-user.html.
SUSE LINUX contains a free implementation of Kerberos called Heimdal. Its documentation is installed along with the package heimdal under /usr/share/doc/packages/heimdal/doc/heimdal.info. It is also available at the project's home page at http://www.pdc.kth.se/heimdal/.
The official site of the MIT Kerberos is http://web.mit.edu/kerberos/www/. There, find links to any other relevant resource concerning Kerberos. A “classical” dialog pointing out the principles of Kerberos is available at http://web.mit.edu/kerberos/www/dialogue.html. It is a less technical but still a comprehensive read.
The paper at ftp://athena-dist.mit.edu/pub/kerberos/doc/usenix.PS gives quite an extensive insight to the basic principles of Kerberos without being too difficult to read. It also provides a lot of opportunities for further investigation and reading about Kerberos.
These links provide a short introduction to Kerberos and answer many questions regarding Kerberos installation, configuration, and administration:
http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3/doc/krb5-user.html,
http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3/doc/krb5-install.html,
http://web.mit.edu/kerberos/www/krb5-1.3/krb5-1.3/doc/krb5-admin.html.
The official Kerberos FAQ is available at http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html. The book Kerberos — A Network Authentication System by Brian Tung (ISBN 0-201-37924-4) offers extensive information.
