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:
The more useful group of tools replace the ordinary Unix-like remote communication services:
There are also other utilities for remotely managing the KDC and for
interoperability with Kerberos version 4.
Therefore, the results from this test bed interact with those of the Enhanced Authentication Test Bed and Fortezza Test Bed.
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.
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.
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.
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.
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.
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:
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.
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?
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.