Kerberos Task Force

James A. Rome, Oak Ridge National Laboratory
Douglas E. Engert, Argonne National Laboratory
Kenneth Renard, Army Research Laboratory

Purpose

The Kerberos test bed was aimed at answering the following questions:
  • What is Kerberos, and what sort of security solution dies it provide?
  • How does one obtain and install Kerberos?
  • How do you deploy Kerberos across a large organization?
  • How do the different versions of Kerberos interoperate?
  • How does Kerberos interoperate with other security solutions?
  • Why isn't Kerberos the whole security solution?
  • Background

    Kerberos is a suite of client and server applications that was developed and is still being maintained and improved by the Massachusetts Institute of Technology (MIT). Kerberos is a network security service which provides for strong authentication over unsecured networks.  Kerberos can provide for mutual authentication between two parties, called principals, usually a client and a server using a third party trust model. Kerberos normally uses a software-only method of authentication, so it relies upon "something you know," a password, to provide this authentication. With modifications, it can be used with hardware devices, such as smart cards to provide additional security. The power of Kerberos is that it can identify you to a remote computer without sending your password over the network in clear text

    In order to use Kerberos securely, a Kerberos client must be installed on the user's local computer.  Kerberos uses the concept of a ticket, which is usable only by the user and only for a specific server. This local client requests tickets from the Kerberos Server known as a key distribution computer (KDC).  The KDC normally sends back a ticket encrypted such that only the user can decrypt and use the ticket. The local client accepts the user's password from the keyboard, uses it to decrypt the ticket (KDC). Since only the client using the user's key can decrypt the ticket, the ticket is useless to anyone else. Since symmetric encryption keys are usually used, where exposing one exposes the other, (with DES there are identical) it is extremely important to locate the KDC in a secure environment and to protect it carefully. To avoid requiring the user to enter in the password for every ticket request, the concept of a ticket which can be used to obtain other tickets, a "ticket granting ticket" (TGT) is normally used. Tickets have many properties, including an expiration time. A detailed explanation of Kerberos can be found in the book Network Security, PRIVATE Communication in a PUBLIC World, by Charlie Kaufman, Radia Perlman, and Mike Spencer (Prentice Hall, 1995).

    The computer user must not share his password or else security will be compromised. To counteract this, some implementations of Kerberos replace (or augment) the password with a token such as a smart card.

    Kerberos has been deployed in large organizations, especially university communities such as MIT. It is especially noteworthy that although security flaws have been found in Kerberos over the years, there have been no significant break-ins reported. The bottom line is that is a user is content to use the services provided by Kerberos, Kerberos provides a user-friendly method for once-a-day sign-on for networked resources while offering enhanced security

    The Kerberos client software consists of many parts. There is a component to handle tickets:

  • kinit asks the user for his password and securely gets the Kerberos ticket.
  • klist displays the user's current tickets and their properties.
  • kdestroy lets the user destroy unneeded tickets.
  • kpasswd lets the user change his password on the KDC without sending it in clear-text over the net.
  • The more useful group of tools replace the ordinary Unix-like remote communication services:

  • ktelnet provides encrypted telnet sessions. Note, however, that any X sessions started by this connection will not be encrypted.
  • kftp provides file transfer services without clear-text passwords. The file contents can be encrypted.
  • krlogin is analogous to the usual rlogin function and works like ktelnet.
  • ksu lets a user become superuser securely.
  • krcp provides a secure way to copy files from one computer to another.
  • krsh provides the secure analog to the Unix rsh command.
  • There are also other utilities for remotely managing the KDC and for interoperability with Kerberos version 4.
     

    Relationship to other test beds

    Kerberos is probably the best protocol for securely transferring an identity across the net without the use of additional hardware. Kerberos has been integrated with hardware tokens to provide additional security, or, the Kerberized login can be used to replace other protocols such as in the secure shell (SSH). Microsoft announced that Kerberos 5 will serve as the basis for security in the next version of the NT operating system.

    Therefore, the results from this test bed interact with those of the Enhanced Authentication Test Bed and Fortezza Test Bed.

    Activities of the Kerberos Test Bed

    Installing Kerberos

    The first step was to deploy Kerberos at our sites so that we could gain experience in this process. Unfortunately, Kerberos is a large and complicated program and building it successfully on various platforms using different compile-time options is not simple. In order to codify this knowledge, we created a Kerberos Web Site (http://www.epm.ornl.gov/~jar/HowToKerb.html) that leads the user by the hand through this process. This Web page is now linked into the official MIT Kerberos page (http://web.mit.edu/kerberos/www/index.html). Our Web page has had over 1100 visitors. Once Kerberos is built, the KDC and Kerberized resources must be configured, and we have also provided step-by-step instructions for these procedures.

    The diversity of Kerberos

    Kerberos has been around around for years, having originally been defined and developed at MIT. This development continues with many other organizations making changes and adding new features to the MIT reference implementation. Many vendors have taken this code over the years and used it as a bases for security in their specific application, or with enhancements to provide a total network security solution. Others have "Kerberized" (added Kerberos security) specific applications.

    The Kerberos RFCs defines the Kerberos network protocol, they do not define a programming API, nor do they define how each system will store needed information on the local machine. There are also two versions of Kerberos in current use, Version 4 and Version 5 which in same cases can interoperate, but not always.

    Export control issues have also played a part in the Kerberos development. Many vendors have been reluctant to use Kerberos because of this, or they will only use its authentication features, and
    specifically not provide the full range of Kerberos applications which provide encryption.

    Therefore, interoperability of Kerberos implementations is an important issue and the task force has been keeping an eye on the developing situation.

    Kerberos Version 5 fixed some of the problems with Version 4, by adding pre-authentication, better cross-realm authentication, and by implementing the forwarding of credentials. Also added were renewable, postdated, and proxyable credentials. Some implementations of Kerberos Version 5 will also support many of the Version 4 applications.

    One of the largest and oldest products to use Kerberos is the the Andrew File System (AFS) which was developed at Carnegie Mellon University (CMU). AFS is now available as a commercial product from Transarc. It was developed at about the same time as Kerberos V4. But it uses Kerberos mostly for internal purposes. It does provide some Kerberized applications, but only in order to allow the use of AFS with them. An example is a FTP daemon which will allow you to access AFS via FTP. Unfortunately, this daemon requires that you send your clear-text password across the net, so the main advantage of Kerberos has been thrown away!

    The Distributed Computing Environment (DCE) from the Open Group is one of the newer products that uses Kerberos. The DCE security service is based on Kerberos V5, and all the other DCE services use it for their security.  DCE was designed to provide secure distributed applications using secure remote procedure calls (RPC).. Its chief feature is the Distributed File System (DFS) which is similar to AFS, but which uses the DCE base services. The latest version of DCE does come with some Kerberized applications, rlogin in particular, but like AFS does not have the full suite of applications. The DCE security is compliant with the Kerberos RFC and can work with other Kerberos implementations using only the Kerberos portion of DCE. But DCE does not support Version 4 applications or protocols.

    DCE is now a component of, or available on almost every major Unix computer system. IBM, HP and DEC have integrated it into their products. SGI and Cray also offer it as products that can be purchased. Third parties have implemented DCE for Solaris, Windows 95, Windows NT and the Macintosh. Unfortunately, a major difficulty is that there is a significant (about a year) version lag between the time the the DCE reference version is made available to the manufacturers and the time it is available to the user. This results on more interoperability questions.

    Solaris comes with some of the Kerberos Version 4 clients, and a Kerberized NFS. To use them, you must provide the other services using some other package.

    Cygnus produces the KerbNet product, and recently released the source code which is freely available. This is very close to the MIT Version 5, and interoperated well. The Cygnus product includes PC and Mac telnet clients.

    Cyber Safe and Open Vision are two other companies with sell total network solutions based on Kerberos. We have not had much experience with either.

    Platinum Technologies has a PC and Mac product called PC-Enterprise which uses Kerberos Version 4 and Version 5. It allows access to AFS and DFS, and has a Kerberized POP server with will work with Eudora Pro, but it too does not have the full suite of Kerberized applications.

    Microsoft has stated that NT 5.0 will use Kerberos Version 5 for its primary authentication mechanism. They have also said they would be compliant with the RFCs and will interoperate with other compliant Kerberos implementations. If this NT implementation is done correctly, it could greatly enhance the image of Kerberos, by bring it to the masses, and by giving applications developers a foundation on which to build Kerberized
    applications on NT.

    Kerberos has been added to Web browsers as well. But neither of the two major browsers, Netscape or Microsoft's Internet Explorer have Kerberos yet. When Microsoft introduces NT 5.0, we would expect that it would be integrated into Internet Explorer for use in intranet environments.

    Gradient Technologies does have a number of products which are add-ons to the current browsers, or which use the security of the current browsers to add DCE authentication and authorization.

    Finally, the Open Group is also working on a Java version of Kerberos which includes Netscape and Internet-Explorer plug-ins.

    Cross-realm Kerberos authentication

    If you are a member of a Kerberos realm, and you need access to resources in another realm, you can either become a member of the second realm, and obtain a ticket for that realm, or you can create an inter-realm trust and perform cross-realm authentication. It is very awkward to maintain an identity in two separate realms at once, so in applications where a single application must be distributed across realms, cross-realm authentication looks very attractive.

    A Kerberos realm (or in DCE terms a cell) is comprised of the user and service principals, and the Key Distribution Center (KDC), which serves as the third-party in the third-party trust model.

    A principal is one realm can authenticate to a server principal in another realm if the two realms are registered in each other's database. Additional realms can also be involved. This is one of the nice features of Kerberos Version 5.

    The cross-realm authentication can be used between organizations, a model being pursued by the DOE ESNet. There are more policy and procedural issues to this then technical issues.  As compared to the traditional user with password authenticating to to a system, you now have an other organization who is vouching for the authentication of the user, and for the policies used in providing that authentication. We feel that this mechanism works best where the realms are each large. In the first place, it cuts down the administrative burden and the number of tickets needed for a transaction. In the second place, we feel that it is easier to place trust in a large realm because they probably have stronger controls on their KDCs and on the identification of their users. In such situations, it is necessary to have clear stated administrative policies for each of the realms that are involved. One such policy example for secure servers was created by an ESNet task force led by John Volmer of ANL.

    There are technical issues as well. The Kerberos RFC 1510 is vague on how the authentication path is determined by the client and server, which they use to determine if it is acceptable to have these intermediate realms involved in the authentication.  The DCE and MIT reference implementations do this differently, and thus have an inter-operability problem when a Kerberos realm and DCE cell participate in cross-realm authentication.

    The DOE ESNet Authentication Task Force (ATF) has a solution for this, and it has been incorporated into the MIT reference port. The ATF also had discussion with the Open Group and HP on solving this problem, as well as input to the IETF for the next version of the Kerberos RFC in an effort to improve the situation.

    The ORNL and ANL Kerberos realms were set up to perform cross-realm authentication. In addition, the ANL realm was a member of a large ESNet DCE cell. We were able to transparently log in to each other's realms using these mechanisms, and were even able to use a local Kerberos ticket to obtain access to resources on a remote DCE cell.

    Misuse of Kerberos

    At the spring IETF meeting, the Internet Architecture Board (IAB) session emphasized security and one thing which should NOT be done, namely do not send clear-text passwords across the network.  This is one of those obvious points, but everyone is still doing it.

    Kerberos has long been viewed as an excellent network security system which used a password to authenticate on the local system, but does not require the password to be sent over the network.  It primary function is to protect the password from exposure over the network. But in many situations when Kerberos was not on the local system this authentication has been done over the network, and the password sent across the network in clear text. This is clearly a violation of the Kerberos principles, but continues to be overlooked. One example is a popular Terminal server vendor which has implemented Kerberos, but requires you to send your password over the phone lines to the terminal server.  Another example is Transarc's Andrew File System (AFS) which uses an older version of Kerberos to get tickets, but does not protect the password if you login over the network.

    DCE until recently had the same problem. If DCE administrator had to to log in over the network to do system administration functions on DCE servers, they had to send the root password or cell-admin password over the network in clear text.

    Kerberos Version 5 and multitiered environments

    For Kerberos to be an effective security solution, it needs to be implemented correctly, and it needs to work in multitiered environments. Only Kerberos V5, has the ability to forward credentials rather than passwords; Kerberos V4 did not have this capability, and was thus limited to client-server environments. Some have tried to extend this, but many of these extensions have introduced additional security risks, and are not standardized.

    The Open Group's Distributed Computing Environment (DCE) and Distributed File System (DFS) uses Kerberos V5 internally, in  much the same way AFS does. DCE internally did allow for multitiered  applications, and delegation of authority.  But only in their latest release they do provide some of the Kerberos applications which allow for sending forwarded credentials instead of passwords to allow for remote authentication.

    The DOE ESNet community has been very active in this area, using the MIT implementation of Kerberos version 5 with DCE. In particular, the ability to use a Kerberos version 5 forwarded credential to get a DCE context and/or AFS token. They continue to help influence the Open Group and the vendors to continue this interoperability.  ESNet has also integrated AFS into this environment with a goal of single sign-on.

    Kerberos and DCE as a foundation for security

    Kerberos can be combined with other security technologies, and can form the bases for authentication.  There are two IETF drafts PK-INIT and PK-CROSS which use public-key technology with Kerberos. PK-INIT uses public key technology for the original user authentication, rather then having a password. DCE 1.2.2 has implemented PK-INIT, and has included a smart-card API which can be used with PK-INIT. PK-CROSS deals with using public key technology with cross-realm authentication.

    There is also a draft document on how to use Fortezza authentication with DCE, and thus Kerberos. The merging of these two technologies will benefit all. DCE's wide installed base, (it is bundled with IBM's AIX, and HP's HPUX systems for example) will benefit from improved security, and the Fortezza technology will have a much wider application base, thereby helping to offset its cost.

    Other PKI or smart-card technologies will also benefit from this.  HP sells such a system. Entrust has been talking to the OpenGroup about integration with DCE. SecureID can be already used with Kerberos due to the efforts of Ken Horenstein of Naval Research Laboratory. A lack of application support and reluctance of software vendors to eliminate the password problem has caused delays in these implementations. DCE can use these technologies as will as Fortezza for authentication.

    Kerberos deployment for large installations

    The true benefit of Kerberos comes from a fully deployed environment where software is installed and used for all network transactions.  This nirvana of computer security is seldom realized.  Deployment of a "Kerberized" environment throughout an organization is usually more challenging than porting and installing the software itself.  There are several technical and political hurdles involved such as education, large-scale installation, and support.

    The Army Research Laboratory's Aberdeen Proving Ground (APG) site has deployed Kerberos Version 5 to about 2000 users and 800 Unix hosts over a 2.5 year period (about 4500 Kerberos "principals").  Although there are several academic sites with over 20,000 principals, deploying Kerberos across a government installation is different and instructive to report here. The majority of the Unix hosts were Sun (SunOS and Solaris) and SGI-Irix machines with a small number of various other architectures such as HP-UX, IBM AIX, Cray Unicos, Pyramid OSX, and DEC Ultrix.

    A large portion of the deployment effort went into porting Kerberos to these Unix platforms.  At the time of initial deployment, the MIT Kerberos distribution (V5-beta 3) was not as clean and portable as is it today. Changes were made to existing applications to make the transition for users easier such as:
     

  • Changing kinit to always request forwardable tickets
  • Making ticket forwarding the default for BSD commands
  • Building kinit into OS version of /bin/login and ftpd
  • Software installation and distribution at ARL was made easy by use of an existing rdist infrastructure.  Kerberos was made available to all hosts via a nightly distribution of standard software packages.  Standard inetd.conf  and /etc/services files were made available as well as text files which included the entries to append to these files.  A sufficient number of system administrators must be given "add" privileges for running kadmin to get krb5.keytab files for installation of application servers.

    Most "Kerberized" applications run on different port numbers than their un-Kerberized counterparts. This situation makes the transition to a Kerberized environment more flexible because you can run both Kerberized and un-Kerberized services in parallel for a period of time. The strategy employed at the ARL was to install Kerberos clients and application servers on all Unix machines and gradually phase out un-Kerberized services. This maintains the benefit of Kerberos application functionality (such as encrypted rlogin/telnet connections) while being flexible in the transition of user's day-to-day operations.  Obviously, the full benefit of Kerberos is not realized until all un-Kerberized services are discontinued and this transition should be done as quickly as possible.

    A short course including a overview of the Kerberos protocol and the administrator and user command suites was given to site system administrators. A site policy for system administrators was established to require remote access of privileged accounts (/bin/su) to be done via an encrypted rlogin or telnet session. This had an immediate benefit of keeping plain-text root passwords off the network. Creation of Kerberos accounts was made standard procedure for getting an account on most large servers. In some cases, passwords were set only in the Kerberos database, not in the host's password file. This makes password management easier for users since there is only one centrally managed password required for access to multiple hosts.

    A large obstacle in the initial deployment and early training was resistance by administrators and users to accept the additional workload and inconvenience of using Kerberos software.  Many claims were made by these users and administrators that would preclude Kerberos from being a viable security solution on their hosts. Most of these claims were based on a lack of resources that would be necessary to implement the additional security on their hosts, the main complaint being a lack of time. Other claims were based on misunderstandings of Kerberos, Unix, and/or security. Convincing management of the need for security is getting easier due to recent media attention.  Convincing management to expend the necessary resources is a different issue.

    A successful strategy employed at ARL for deployment of Kerberos was to bring all new machines on line in Kerberos-only mode. In this manner, you are not taking away access that users once had, but masking the additional access procedures behind a new computing resource. Users will resist, but will eventually realize the need and ease of additional security measures.

    User education is an essential element in a successful deployment of Kerberos. Successful training sessions have included a background knowledge of basic networking principals, client-server concepts, examples of security threats (sniffers, TCP hijacking, etc.), real examples and statistics of site security incidents, demonstrations of software usage, and handouts of basic Kerberos commands and troubleshooting.  User's are generally more acceptable in a learning environment where they can understand the need for security rather than being forced into usage without apparent reason.

    KDC workload for up to 4000 principals is still trivial.  A Sun ELC or Sparc Classic has more than enough horsepower to serve a site of this size.  Daily maintenance is minimal on the KDC itself (backups and careful systems administration) and failures are extremely rare.  At least one backup KDC is highly recommended for larger deployments, mostly for network failures. Network bandwidth requirements are low and connectivity to high-bandwidth networking (FDDI, ATM, HIPPI, etc.) serves mainly to increase routes to KDC. Database propagation takes less than 30 seconds over Ethernet.

    Kerberos is dependent on a few core services such as time, accurate name service, host OS, network connectivity, and power.  Most Kerberos errors are the result of failures in these core services.  About 95% of all reported Kerberos problems are not Kerberos problems.  The failure of a Kerberized rlogin will generally be reported as a "Kerberos problem" even if the remote host or network is down.  A list of common errors, causes, and solutions is helpful for administrators and users.  Kerberos error messages are usually verbose and can be confusing to the uninitiated.

    Maintenance of a Kerberos realm consists mostly of user support and accounts management.  Password management can be accomplished by use of the "policy" mechanism within kadmin.  This feature sets basic requirements for acceptable passwords.  Attributes of a password policy are:  maximum lifetime, minimum lifetime, minimum length, minimum classes, and history.  "Classes" are sets of characters such as lowercase, uppercase, numbers, punctuation, and all other characters.  History is the number of previous passwords for which the user cannot select.  The kpasswd command conveniently explains password requirements to the user.  Many policies can be created and applied to different principals.  A policy named 'default' will be applied to all new  principals.  Another useful password management feature is the definition of a "dict_file" in the kdc.conf file.  The kadmin daemon will check all new passwords against the defined dictionary and not allow matches.

    A successful deployment of Kerberos will continue to provide user-friendly access for authorized users while limiting access enough to manage the risk associated with a site's network connectivity.  By requiring Kerberos authentication for primary access mechanisms (telnet, rlogin, rsh, ftp, etc), you can reduce a large amount of risk.  Complete risk avoidance is nearly unobtainable and should never be used a reason not to take the first step.
     

    What's missing?

    Kerberos seems to offer a highly secure one logon solution for access to networked resources.  Some of the institutional resistance to Kerberos conversion has been outlined already. However, the other factor is that there are no full suites of Kerberos client tools for Macs and PCs. Kerberos is definitely targeted at Unix systems to avoid having to integrate the code into the GUI interfaces. For example, the NT client version of Kerberos only has telnet and ticket management tools. There are no NT versions of the Kerberos daemons. Most Macintosh Kerberos clients only support Version 4.

    So, in an environment where PCs and Macs prevail, it is difficult to implement Kerberos without removing important features from the users such as ftp.  If a user must send his clear-text password over the net to transfer files, is it worth the effort to provide a telnet that does not send passwords over the net?
     

    The next steps

    Kerberos is gradually spreading to new platforms and new tools are appearing for existing platforms.  If Kerberos V5 really appears in the next version of Windows NT, it will constitute a major  vote of confidence for the Kerberos security mechanisms.

    We feel that the most effective way to increase the deployment of Kerberos is to provide the information necessary so that site administrators can get things working without wasting too much time. To achieve this, we have created our "How to Kerberize your Site" Web page. This page has proven to be very useful, and must be maintained and updated.