ncsa

User Information Home
Compute Resources
Software
Data
Security
Allocations
Consulting
Training
Advanced Support for TeraGrid Applications

Introduction to Kerberos 5

Table of Contents

• Introduction
• Problems with current authentication methods
• How Kerberos works
• What programs work with Kerberos
• Additional Kerberos 5 features
• Kerberos 5 and AFS
• Shortcomings of Kerberos
• Kerberos Principals
• Kerberos Realms
• Glossary

---

Introduction

Kerberos 5 is a authentication and privacy package that provides a means of protecting passwords and other user data from third-party sniffing on a network between two hosts. It does this using "tickets" to provide a secure authentication mechanism and strong encryption of network traffic. Kerberos provides replacements for many of the standard Unix network utilities (e.g. telnet, ftp, rlogin, rsh) as well a library to allow adding Kerberos security to arbitrary programs.

Problems with current authentication methods

Normally today when most users make a connection over a network to a remote host they use a program like telnet or rlogin and then authenticate themselves either with a password or .rhosts file. Both of these methods are vulnerable to attack from a malicious party out on the network.

By typing their password in a normal remote login session with any of the standard network utilities, the characters of the password are all sent over the network in the clear. It is easy for a third party who has access to the network to intercept these characters and get the user's password and record it for later use.

By using a .rhosts file a user's password doesn't go over the network, but the .rhosts mechanism relies on the securing of the Internet Protocol (IP) layer. This is the layer of the network that gets packets from one host to another and unfortunately the IP layer has very little in the way of security and this makes the user vulnerable to an attacker using an attack called "IP spoofing".

For example, say a user had a .rhosts file allowing the user "j-user" at "somehost" access to their account. When a rlogin connection is made to the machine, the rlogin daemon would look at the IP packets to see where the connection is coming from and then it looks at the data coming from the rlogin client to determine who the user is. What a clever attacker can do is forge packets to fool the rlogind so that it thinks the attacker is coming from "somehost" and is the user "j-user". There is nothing in the IP layer to protect from this occurring.

How Kerberos works

Kerberos 5 solves these problems by providing a means of authenticating the user where the user's password never goes over the network. Kerberos bases it's authentication on electronic "tickets" that are send encrypted over the network. A central server, called a KDC (Key Distribution Center), authenticates the user and gives them tickets that allow them to access hosts and services (like popper). Kerberos calls every user, host or service that uses Kerberos a principal and each principal has a key. For more information on principals see the section on Kerberos Principals. For users, the key is created from their password and for hosts and services it is a long random number. These keys, like passwords, are kept secret and are known only to the principal the key belongs to and the KDC.

By using a form of encryption called "symmetric encryption", these keys can be used to do authentication and send secure messages. Symmetric encryption means that if a message is encrypted with a key, it can only be decrypted with the same key. Since keys are only known to two parties, the principal they belong to and the KDC, this allows secure messages to be sent between principals and the KDC.

(Much of the following information in this section was transposed from the "Final Report and Recommendations of the ESNET Authentication Pilot Project", G. R. Johnson, C. L. Athey, D. E. Engert, J. P. Moore, J. E. Ramus.)

Kerberos authentication is normally accomplished by the user running a program like kinit. kinit sends a request to the KDC requesting a ticket-granting-ticket (tgt) for the user. This message is sent in the clear and contains no sensitive information, just the request. The KDC generates and sends back two things, a session key and a tgt, which contains a copy of the session key. It encrypts the session key with the user's secret key and the tgt with a secret key known only to the KDC. It then sends these back to the user.

The user's secret key is generated from the user's password using what is called a one-way hash. Basically this is a way of turning a string of characters into a number. So when kinit gets the response back from the KDC, it asks the user for their password, which they then type in and kinit converts it into their secret key. The key is then used to decrypt the session key from the KDC. Assuming the password the user typed in was correct, kinit will successfully decrypt the session key and user is now ready to get further Kerberos tickets.  The session key and tgt are then saved in a credentials cache on the local machine, this is typically a temporary file. Notice that that user's password never left the machine the user was on.

Now say the user wants to login to a host using Kerberos. For example, if they want to log into the machine hal.ncsa.uiuc.edu. So, let us say they run the Kerberos rlogin program, specifing "hal.ncsa.uiuc.edu" as the target host. First the rlogin program will open the user's credentials cache and retrieve the user's tgt and session key. It then sends a request to the KDC stating it wants a ticket for "host/hal.ncsa.uiuc.edu" (by convention this is the name of the principal for the host hal.ncsa.uiuc.edu), the user's tgt (still encrypted with the KDC's secret key), and some additional information that authenticates the user which it encrypts with the session key.

The KDC then decrypts the tgt in the request using it's secret key and then using the session key in the tgt decrypts the authentication information which validates the user. Assuming this all went right, they KDC now believes the user is who they say they are. It now generates another session key to be shared between the user and target host they want to log into, and incorporates this, along with the user's identity, into a new ticket for "host/hal.ncsa.uiuc.edu". This new ticket is then encrypted with the secret key for "host/hal.ncsa.uiuc.edu". The KDC also encrypts a copy of the new session key with the session key it already shares with the user. The new ticket and session key are send back to the user.

Rlogin receives the ticket and key from the KDC. It stores both in the credentials cache for possible later use. It then connects to hal.ncsa.uiuc.edu and sends the ticket for "host/hal.ncsa.uiuc.edu" to prove the user's identity. The rlogin daemon on the host retrieve the secret key for "host/hal.ncsa.uiuc.edu", which is key in a secured file on local disk called a keytab, and uses this to decrypt the ticket from the user. From the decrypted ticket it gains the user's identity and the session key. Since only the host and the KDC shared the secret key the rlogin daemon can safely assume the ticket was encrypted by the KDC and so it can trust the information in the ticket in regards to the user's identity. Notice that both the target host and the user have access to the new session key now, allowing them to use that for further encryption between them for forwarding tickets or encrypting keystrokes.

What programs work with Kerberos

A lot of the standard Unix clients and servers have been modified to support Kerberos 5. These include telnet, rlogin, rsh, rcp, and ftp. There are also Windows clients for these as well as support for Eudora. Unfortunately there is currently no GUI ftp for Windows at this time.

Additional features of Kerberos

Besides offering a more secure authentication method, Kerberos offers a couple of other nice features. Kerberos offers the ability to encrypt all traffic going over the network. This allows you to type additional passwords after you log in or transfer sensitive data without worrying about third parties sniffing the network traffic.

Kerberos also allows you to forward your ticket-granting-ticket from one host to another remote host when a connection is made. This means that when you connect to a remote host you can make further Kerberos connections from that host and they will use your forwarded ticket to authenticate you. This allows you to authenticate once and make any number of connections without having to ever type your password again.

Kerberos 5 and AFS

AFS uses the older Kerberos 4 to do it's authentication. Since Kerberos 5 offers support of Kerberos 4 it has the ability to create an AFS token from a Kerberos 5 ticket without further authentication by the user. This involves creating an AFS key and putting it in both you Kerberos 5 and AFS databases. This allows Kerberos 5 to generate tickets encrypted with that key that will be accepted by the AFS database.

For more details check out the AFS-KRB5 migration kit from the Naval Research Lab.
 

Shortcomings of Kerberos

Ticket lifetime:
Once a Kerberos ticket leaves the KDC it is prone to be stolen and used by a third party like a password. Although Kerberos has mechanisms in place to help prevent this from happening, if a machine where a credentials cache is stores is compromised, it is possible tickets can be stolen. To help limit damage from such an event, all tickets have a lifetime encoded into them so that they expire after a set period of time. How long depends on the local site configuration, but is typically on the order of a day.

Unfortunately from the user perspective this is a pain. This means they must re-authenticate every so often and requires special support for long-running processes.

Bad passwords:
Although Kerberos offers some support for preventing user's from choosing bad passwords with dictionary checking, character class counts, and password history, the user still must be responsible for choosing a password that won't be easily guessed by a hacker.

Kerberos Principals

A Kerberos principal is basically any entity that must authenticate or be authenticated to, and includes users, hosts, and other services like popper. Each principal has a secret key associated with it that is known only to the principal and the KDC.

Each principal has a name describing the principal. The name is of the form primary/instance@realm.

The realm portion indicates the Kerberos Realm to which the principal belongs. See the section on Realms for more information.

In the case of a user principal, the primary portion is usually the username and instance can be empty or can contain a string indicating special privileges of the principal. The string "admin" is typical to indicate that a principal has administrative privileges in the Kerberos database. For example the following are typical user principals in the realm NCSA.EDU:

• vwelch@NCSA.EDU
• vwelch/admin@NCSA.EDU

In the case of a host or service principal, the primary portion indicates the type of service the principal represents, e.g. "host" or "pop". The instance portion then indicates the machine on which the service is running. For example:

• host/pecos.ncsa.uiuc.edu@NCSA.EDU
• pop/pop.ncsa.uiuc.edu@NCSA.EDU

Kerberos Realms

A Kerberos realm is a administrative domain consisting of a collections of machines that share a common set of principals and trust the same KDC. Realm names conventionally are the upper-case version of the domain name, but this is not required.

It is possible to establish a trust relationship between two realms using cross-realm authentication. This involves the administrators of the two realm sharing keys so that each realm can hand out tickets for the other realm. This allows users from one realm to easily authenticate into the other.
 

Glossary

This glossary was copied from the Kerberos User's Guide (1.0 dated 12/18/96). Copyright 1990, 1991, 1992, 1993, 1994, 1995, 1996 by Massachusetts Institute of Technology. Any typos may be considered mine.
 
 

client	An entity that can obtain a ticket. This entity is usually either a user or a host.
host	A computer that can be accessed over a network.
Kerberos	In Greek mythology, the three-headed dog that guards the entrance to the underworld. In the computing world, Kerberos is a network security package that was developed at MIT.
KDC	Key Distribution Center. A machine that issues Kerberos tickets.
keytab	A key table file containing one or more keys. A host or service uses a keytab file in much the same way as a user uses his/her password.
principal	A string that names a specific entity to which a set of credentials may be assigned. It generally has three parts:    primary The first part of a Kerberos principal. In the case of a user, it is the username. In the case of a service, it is the name of the service. instance The second part of a Kerberos principal. It gives information that qualifies the primary. The instance may be null. In the case of a user, the instance is often used to describe the intended use of the corresponding credentials. In the case of a host, the instance is the fully qualified hostname. realm The logical network served by a single Kerberos database and a set of Key Distribution Centers. By convention, realm names are generally all uppercase letters, to differentiate the realm from the internet domain The typical format of a typical Kerberos principal is primary/instance@REALM.
service	Any program or computer you access over a network. Examples of services include "host" (a host, e.g., when you use telnet and rsh), "ftp" (FTP), "krbtgt" (authentication; cf. ticket-granting ticket), and "pop" (email).
ticket	A temporary set of electronic credentials that verify the identity of a client for a particular service.
TGT	Ticket-Granting Ticket. A special Kerberos ticket that permits the client to obtain additional Kerberos tickets within the same Kerberos realm.

---

Questions or comments about this page may be sent to kerberos@ncsa.uiuc.edu  

Back to NCSA Kerberos Information