Kerberos for the Quick
Revision 4, April 2005
This article has two intended audiences. One is people who have heard that there's this thing called Kerberos, and it's supposed to be cool, but they don't have a clear idea what Kerberos is or how it works. The other group is system administrators who are about to implement Kerberos on their network and are looking for the pieces they'll need.
If you really want to implement Kerberos on your network, I strongly recommend you get the book "Kerberos: The Definitive Guide" by Jason Garman (published by O'Reilly, ISBN 0-596-00403-6). It goes into great detail and covers the fundamentals you'll need to make your network secure. It also contains extensive installation and setup instructions.
Much information in this article comes from my personal experience and, as a result, is somewhat limited in scope. In particular, I only cover Kerberos 5, not the now outdated Kerberos 4.
This section tries to explain what Kerberos is and what it isn't, and how it is related to similar technologies.
Kerberos provides network-wide, single-sign-on authentication. In an ideal Kerberos-enabled network, you type your user name and password once in the morning, when you log in to your local workstation, and no network service (e.g. file sharing, remote login, mail) will prompt you for anything for the rest of the day. Most real networks do not achieve this goal in full, but still allow you to use a single password for all services.
LDAP, NIS, NetInfo, and so on are directory services. They have a much broader scope than Kerberos and can be used to implement authentication ("Is the user who she claims to be?") and authorization ("Is the user allowed to do what she tries to do?") as well as defining what users exist in the first place. Kerberos only provides authentication, so it is often used together with LDAP or NIS. Using only LDAP you can have a single password for all services in the network, but you still have to type it on every login (i.e. no single-sign-on).
On a side note, some Kerberos implementations can use a LDAP directory as their storage backend, i.e. the Kerberos server's internal data is stored in the directory (alongside public information, protected by ACLs) instead of some file on the filesystem.
Microsoft Active Directory integrates LDAP, Kerberos, and a few other pieces to provide a single point of administration for Microsoft Windows based networks. By and large, if you have Active Directory, you also have a fully functional Kerberos server for non-Windows clients and servers.
The Remote Authentication Dial-In User Service (RADIUS) protocol provides authentication, authorization, and accounting (AAA) for dial-in infrastructures. It allows you to use the same account and password to log into your company network via modem, WiFi, or a VPN tunnel. RADIUS has many carrier-grade features (the whole accounting part, for example) and is designed to operate in explicitly configured backbone networks. It is not well suited for PC and workstation networks and doesn't have the single-sign-on capability offered by Kerberos.
Yes, as long as your users choose good passwords. User passwords are never transmitted in clear text over the network, nor are they cached (stored) on the client machine. Instead, encrypted so-called tickets are used, which have a limited lifetime, 10 hours by default. Also, Kerberos always does "mutual authentication", i.e. both sides prove their identity to the other party, not just the user to the server.
Kerberos only ensures that authentication is secure. Each application is responsible for securing the actual data transfer. In theory, Kerberos generates a secure session key during authentication, but few applications make use of it.
Yes and no. Ideally, Kerberos is transparent to the user and eliminates the need to type passwords over and over again. Unforturately, this requires Kerberos support in all client and server software used, and proper configuration. Finding Kerberos patches for all of your software can be a daunting task. This article tries to help by documenting my own findings.
Here's the big picture, without the cryptographic details:
When you log in, your client contacts the Kerberos server and uses your password to prove your identity. In return it receives a special "ticket granting ticket" (TGT), valid for several hours.
When your client wants to contact a network service on your behalf (e.g. to mount a network file share), it first contacts the Kerberos server with the TGT and the name of the service. The Kerberos server issues a service ticket, which your client presents to the actual network service. The network service validates the ticket (without contacting the Kerberos server) and allows the connection.
Kerberos uses a central server for all authentication, which introduces a single point of failure to your network – when the Kerberos server is down, no one can log in. Most implementations support replication to make this less critical.
Password changing is not standardized and differs between server implementations. Users may have to use special programs to change their Kerberos password. To keep Kerberos passwords synchronized with some other system, you must hook into the Kerberos password change mechanism; Kerberos doesn't store plaintext passwords.
Kerberos relies on host names and the availability of the Kerberos server, being designed for local network operation. There are some difficulties getting it to work properly through firewalls, over the Internet, or on mobile computers. Kerberos also requires the clocks of the involved hosts to be synchronized; authentication will fail if they aren't.
Kerberos only works well when it is properly supported by the operating system. First, the TGT needs to be shared between all of your network applications, so you want a single Kerberos implementation that is used by all installed applications. Second, you want the system login to support Kerberos. All of today's mainstream systems do both.
Kerberos was developed at MIT, and this is the original code base [website]. It includes a Kerberos authentication server, libraries for client applications, and libraries for network service daemons. The distribution also includes patched versions of the BSD network programs that add Kerberos support: rsh/rlogin, rcp, telnet, ftp.
Seamless Kerberos support on Unix requires additional components, most importantly a PAM module to obtain Kerberos tickets on local login.
Heimdal [website] is an alternative implementation of Kerberos 5 for Unix. It is developed outside the US, so it is not affected by US export regulations. Heimdal strives to be API-compatible with MIT Kerberos, i.e. a program that compiles with the MIT distribution should also compile with Heimdal.
Microsoft Windows 2000 and XP support Kerberos 5 out of the box. A workstation that is a member of an Active Directory domain automatically obtains Kerberos tickets on login. With the ksetup command line tool, a Windows workstation can be configured to authenticate against non-Microsoft Kerberos servers. Microsoft also provides a minimal tray icon application to manage tickets. A full-blown ticket manager application is avaliable from MIT.
Mac OS X 10.3 ("Panther") ships with Kerberos support based on MIT Kerberos 1.3.x. Apple has wrapped the libraries into a "Framework" – a versioned bundle containing a shared library and its header files – but also provides compatibility symlinks such that Unix-based Kerberos software should compile out of the box.
The login screen (technically called "loginwindow") can be configured to use Kerberos for authentication, or to use local authentication and get Kerberos tickets using the same password. There is a GUI tool (/System/Library/CoreServices/Kerberos) to display and manipulate your tickets. Some command line programs are compiled with Kerberos support, including telnet and ssh.
Supporting every conceivable authentication method in every application procotol (and the software that implements it) is a lot of work. Several approaches were made to address this problem. The general idea is that the application talks to a single generic library. That library uses one plug-in per authentication method to handle the gory details. Neither the authentication plug-in nor the application need to know about the other part.
With the Generic Security Service Application Program Interface (GSSAPI, RFCs 2743 and 1964), an authentication method generates opaque byte strings which are transferred unchanged through the application protocol, and handed back to GSSAPI on the other side. GSSAPI also provides functions for data integrity (i.e. checksums against tampering) and confidentiality (encryption) of application protocol data.
Unfortunately, GSSAPI hasn't caught on in the non-Kerberos world. It also lacks a mechanism to negotiate which authentication method to use. SPNEGO (RFC 2478) defines such a negotiation mechanism, but it is seldom used. In the real world, "GSSAPI support" and "Kerberos 5 support" are synonyms.
The Simple Authentication and Security Layer (SASL) provides generic authentication in a way similar to GSSAPI – the application protocol defines a way to pass binary data strings back and forth, and the authentication method handles the details. SASL supports Kerberos 5 by wrapping GSSAPI. Other standard profiles include plaintext passwords and several challenge-response mechanisms.
The Pluggable Authentication Modules (PAM) library is used on many Unix systems to authenticate and authorize users logging into the system. It is generic enough to allow for various password-based backends, one-time password schemes, and things like smart cards, but provides no explicit support for network protocols. As a result, Kerberos modules for PAM can check your password against the Kerberos server, but don't support true single-sign-on. For example, SSH already supports PAM, but needs a GSSAPI-based patch to enable password-less Kerberos logins. Still, PAM works nicely for the initial local login using xdm.
This section lists individual application protocols, describing how the protocol was extended to allow for Kerberos and which implementations support it.
Telnet was one of the first targets of Kerberos. Patched versions of telnet and telnetd are distributed as part of the Kerberos distributions for Unix.
The BSD programs rlogin, rsh and rcp have also been primary targets since the early days of Kerberos. Even if you have Kerberos-enabled versions of these programs, a command line option may be required to actually use Kerberos. These services also support Kerberos-based encryption, which uses a different TCP port. The Debian GNU/Linux server packages require the use of encryption in the default configuration.
Since the File Transfer Protocol has been around for a long time, so has Kerberos support for it. Kerberos 5 is supported through GSSAPI. Unfortunately, most mainstream FTP servers and clients don't support it out of the box. Unix Kerberos distributions come with a patched server and command-line client.
The Secure Shell protocol provides a secure replacement for telnet, rsh, rcp, and ftp. Even without Kerberos, SSH can be used to have password-less remote login, using a RSA or DSS public key scheme. This doesn't require a central server, so it is very useful if you have to use many machines in different administrative zones. Kerberos on the other hand can give you access to many other services besides SSH with the same password.
There are two incompatible revisions of the SSH protocol, SSH1 and SSH2. Only the combination of SSH2 and Kerberos 5 is covered here.
SSH is both a remote network service and a point of initial login to a realm. As a result, there are several ways to use Kerberos with SSH. Password-less logins are supported through GSSAPI. Under certain circumstances, the Kerberos authentication also replaces SSH host key checking, because Kerberos always authenticates the service to the client as well as the client to the service. The Kerberos support in SSH also allows your TGT to be forwarded to the remote machine, so you can access further network services from the remote machine without entering your password as well.
The other part of Kerberos integration in SSH consists of doing a password-based initial login. The password you enter is used to obtain a TGT on the remote host. SSH uses its own encryption to protect the transmission of the password.
There is a patch for OpenSSH 3.6 that supports both scenarios. If you're only interested in the second scenario, you can get by with a Kerberos module for PAM. Mac OS X 10.3 ships with a patched version of SSH. On Debian GNU/Linux, install the ssh-krb5 package.
The LDAPv3 protocol has two ways to authenticate users, in addition to anonymous operation. The first one is called "simple bind" and works by transmitting a password in clear text. This is what most LDAP authentication modules use, by the way, and it isn't even remotely secure unless used with SSL (i.e. connection-level encryption). The other method uses SASL.
The OpenLDAP [website] server and client tools use the Cyrus SASL library, and automatically support Kerberos if a Kerberos SASL module is installed on both client and server machines.
The Network File System is still the standard protocol for file sharing between Unix machines and is traditionally lacking in security. The recent NFSv4 standard makes Kerberos 5 support mandatory for all implementations. Since all versions of NFS use Sun-style Remote Procedure Calls (RPC) for communication and GSSAPI support is implemented at the RPC level, some implementations may support Kerberos even for the older NFSv3 or NFSv2 protocols.
SMB is the protocol used by Windows file servers. Windows 2000 and later use Kerberos 5 for authentication when configured to use Active Directory. Unfortunately, Microsoft has extended the Kerberos protocol with proprietary authorization data (the infamous PAC), which so far has impeded Kerberos support in open source SMB implementations.
Samba 3.0 [website] has limited support, meaning that it only works for Windows clients using an Active Directory server as their Kerberos authentication server. The state of Kerberos support in the Samba client libraries is unknown.
AFP is the protocol used by Apple's file sharing servers, also known as AppleShare. (Note that AppleTalk is a network protocol suite to be compared with TCP/IP, and AFP can use either as a transport layer.) The latest revision, AFP3, supports Kerberos 5 through GSSAPI.
The netatalk package [website] implements an AFP server for Linux and other Unix systems. Version 2.0 supports AFP3 and Kerberos 5 authentication and is interoperable with Mac OS X 10.3.
These three mail-related protocols support SASL for authentication and can be made Kerberos-aware that way. I haven't tried to use it, so that's all I can say.
Kerberos support for the world wide web seems to be still thin. Microsoft pioneered this and has defined a "Negotiate" authentication method based on GSSAPI and SPNEGO. This is one of the few cases where GSSAPI is not used for Kerberos alone, but also for Microsoft's legacy NTLM scheme. The Negotiate method only provides authentication, so it is generally recommended to combine it with HTTPS to ensure integrity and confidentiality.
Internet Explorer and Microsoft IIS both support Kerberos through the Negotiate method (plus NTLM, naturally) starting with version 5 in both cases, provided they run on Windows 2000 or later. Mozilla 1.7 and Firefox 1.0 support Kerberos through the Negotiate method on Windows, Mac OS X and generic Unix platforms. The mod_auth_kerb module for Apache 1.3 and Apache 2 [website] supports both the Negotiate and Basic HTTP methods. In the latter case the password is requested from the user, transmitted in clear text and checked against the Kerberos server by Apache.
Note that all browsers mentioned require explicit configuration to enable Negotiate authentication. This is to prevent attacks from malicious Internet web sites.
Even recent versions of the MySQL database only supports its custom username/password authentication scheme. For command-line work you can put your username and password for the local database in the per-user configuration file ".my.cnf".
The PostgreSQL database supports Kerberos 5 authentication for TCP/IP connections. The only drawback is that your database user name is always equal to your Kerberos principal name.
|Apr 18, 2005||Copyright © 2002-2011 Christoph Pfisterer|