San Diego Supercomputer Center San Diego, California, U.S.A.
September 20, 1995
SDSC is in the process of installing and porting MIT's Kerberos 5 Beta 4 network security software to SDSC systems including the C90, Intel Paragon, SUNs, DEC Alphas, SGIs and RS6000s, and purchasing compatible software for our Macintoshes and PCs. By using Kerberized clients (telnet, rlogin, etc.) ,we will be able to keep plain-text passwords off the network and thereby mitigate the most significant security problem in our distributed environment. This paper will discuss Kerberos features, advantages over DCE authentication, how Kerberos functions in our environment, and the current status of our project. This paper is online at http://www.sdsc.edu/SDSC/Staff/schroede/kerberos_cug.html
Many of these attempts are equivalent to someone walking down the street and casually rattling the knobs of every door to see if one has been left unlocked. Some are sophisticated and well-targeted assaults. Some of these have been serious enough to cause us to escalate our own monitoring and security practices.
An incident on December 25, 1994 eventually led to the arrest of Kevin D. Mitnick after some brilliant cyber-sleuthing by SDSC senior fellow Tsutomu Shimomura and SDSC staff member Andrew Gross. This was reported in the New York Times on February 16, 1995: "How a Computer Sleuth Traced a Digital Trail.".  The incident was first reported in a front-page article in the Monday, January 23, 1995 New York Times.
Since 1993, SDSC has been interested in running Kerberos as one method of improving our security. In late 1994 we began the project, led by SDSC security specialist Tom Hutton, with various members of the SDSC Systems Department participating. All participants had other responsibilities and were not able to commit large amounts of time to the project.
It is a fairly large project, with impact on users, and required a phased-in approach.
Kerberos  was designed to deal with this problem. Through a sophisticated protocol built on DES encryption, plain-text passwords need never be transmitted across the network. And, via a ticket-granting sevice (TGS), users need only enter their passwords once for an entire work period. For example, users can register (kinit) in the morning and then can repeatedly connect (ktelnet) to other systems throughout the day without entering a password again.
Also, Kerberos rlogin has an option (-x) to encrypt an entire session. Encrypting a session causes all entered input and all terminal output to be encrypted while traversing the network. This is particularly useful for users who wish to protect information which is entered on their keyboard or viewed on their monitor.
CRI provides an older version of Kerberos (4) as part of Unicos 8.0, but reportedly has no plans to port and provide Kerberos Version 5.
Further investigation revealed, however, that ESnet staff (a network managed and funded by the U.S. Department of Energy Office of Energy Research (DOE / OER)), had examined Kerberos and DCE Authentication and had developed a proposal to use them for intersite authentication in a wide-area network. This Distributed Informatics, Computing & Collaborative Environment (DICCE) proposal Authentication Infrastructure of the DICCE , included a description of some current limitations:
"DICCE is being based on OSF/DCE which is currently missing a number of the key components needed for a wide area collaborative environment. These include:
So, since DCE does not currently provide Authenticated/Secure Telnet or "r" commands (rlogin, rsh, remsh, rcp), SDSC would not be able to leverage off DCE services for our needs; we would need to install/port the MIT Kerberos release ourselves. It is likely that the OSF/DCE will provide an interoperable authentication system, but probably not for a year or more.
Also, DCE Authentication may not be adopted by all vendors. OSF/DCE is available for SUN platforms, for example, only through a third-party (TransArc-IBM). And Microsoft has stated that it intends to replace the existing security server in Windows NT with MIT Kerberos. 
CRI has been looking at solutions to the Single Login issue for quite some time. The main problem for any of this work is the fact that there is no protocol support for passing authentication information (tickets) with the standard unix login (telnet, rlogin) commands or "r" commands. There needs to be an industry-wide solution for this problem, but to date there is none. If one existed, every vendor would have adopted it long ago .
Currently there are no standard DCE-ized login commands such as telnet, ftp, fta, rlogin, rsh, rexec, and rcp. As part of its 18.104.22.168/22.214.171.124 DCE/DFS product, CRI has integrated DCE authentication into most of the standard login commands (telnet, rlogin, rexec, ftp fta, nqe). This allows users to pick up DCE authentication at login time without the need to take an additional step of doing a dce_login. This is handy for things like placing a user's home directory out in DFS space. But the interaction occurs at login time, within the Cray, and passwords are still sent to the Cray as plain-text.
CRI has been looking at adding DCE network authentication to these commands as well, but in doing so, CRI would be solving this issue only for a collaborative environment of its own. Other vendors would need to adopt the same protocol for passing DCE authentication in order for this feature to be of any use for non-CRAY machines.
The solution that CRI has been leaning toward is using GSSAPI as the authentication service, since this is perhaps a larger standard, and more vendors might be willing to GSSAPI-ize their commands in an attempt to solve these issues. GSSAPI will increase portability and maintainability of commands needed to provide authentication, authorization, and privacy. Underneath GSSAPI there must be vendor-supplied mechanisms providing these functions. Unless vendors supply them (Kerberos V, DCE), sites still will not have interoperablity. Perhaps what is needed is some coordination among vendors to supply these mechanisms.
OSF has stated that its DCE 1.2 release will include implementations of telnet, rlogin, and ftp that have been integrated with the DCE environment, and will use Kerberos-based protocols to avoid exposing users' passwords on a network. CRI is eager to see this code, as it has been stated that mods to the protocol will be handed back for potential inclusion in the IETF standards. This is a good step toward an industry-wide solution.
He cited three main problems:
SDSC is dealing with the second problem by adding public-domain software from other password systems to the KDC. Passwords that do not meet the criteria will be rejected with an explanation of the rules. These include that there be at least one non-alphabetic character and that the password does not match the username or dictionary words.
For the third, SDSC plans to allow only inter-realm authentication between the other NSF centers and SDSC; so we will be dealing with only a few known and trusted system administrators. Most of our users (i.e., those not in Kerberos NSF center realms) will install our clients (i.e., ktelnet, krlogin, kinit, and kpasswd) and authenticate to our KDC without requiring a "shared secret" to function.
Presumably, a set of Kerberos clients will be able to interact with the SDSC realm, and at the same time another set (or the same set, maybe) could interact with another realm. This way, a user now (or in the future) using Kerberos at University XYZ could use our ktelnet to access SDSC and another ktelnet to access his/her local realm.
Regular rlogin can be used in a passwordless manner, but SDSC has not encouraged its use (although we do allow it, and some users use it). rlogin is not particularly secure because of the "trusted host" method associated with the .rhosts entries. If someone were to break into a workstation that was in a user's Cray .rhosts file, the intruder would have access to the user's Cray account. Or if someone were to "spoof" the network into "believing" that his host was that user's workstation, access would also be obtained. Also, rlogin is inefficient, increases system time, and reduces interactivity because it generally sends a network message for every character typed.
With Kerberos, users can have efficient, passwordless, and secure interaction with SDSC systems via ktelnet and other kerberized utilities.
Another advantage, for users, as mentioned earlier, is the encryption option of krlogin to encrypt the terminal traffic of an entire session. This will occasionally be useful.
Users run kinit to get authenticated in the Kerberos system:
number9 1% kinit -f -l10 Password for schroede@TEST.SDSC.EDU:
This creates a ticket-granting ticket that can be listed via the klist command:
number9 2% klist Ticket cache: /tmp/krb5cc_122 Default principal: schroede@TEST.SDSC.EDU Valid starting Expires Service principal 7-Sep-95 08:44:38 7-Sep-95 18:45:55 krbtgt/TEST.SDSC.EDU@TEST.SDSC.EDUThe -f option on kinit makes the ticket forwardable to other systems. By using the ktelnet -F or -f option (or krlogin -F or -f), the Kerberos software forwards a copy of the ticket in a secure way, so that the user does not have to kinit on the remote host (kinit would take a plain-text password). These tickets are viewable via klist. The -l option specifies the number of hours that the ticket-granting ticket (and all tickets generated by it) are valid. Once tickets expire, they are no longer valid, but existing ktelnet sessions, etc., will continue.
A sample session follows.
number9 3% ktelnet -F c90 Trying 126.96.36.199... Connected to c90.sdsc.edu. Escape character is '^]'. [ Kerberos V5 accepts you as ``schroede@TEST.SDSC.EDU'' ] [ Kerberos V5 accepted forwarded credentials ]
San Diego Supercomputer Center CRAY C90 with 8 CPUs and 256 MW running UNICOS 188.8.131.52
Last successful login was : Thu Sep 7 15:44:29 from number9.sdsc.edu Account (? for available accounts) [sys200]:
See 'news sdsc.important.cray' for more details!
If you have any questions, please contact the SDSC consultants at (619)534-5100 or e-mail to firstname.lastname@example.org or visit SDSC's User Services web page at http://www.sdsc.edu/Services/Consult/consult.html
c90 1% klist Ticket cache: /tmp/krb5cc_122 Default principal: schroede@TEST.SDSC.EDU
Valid starting Expires Service principal 7-Sep-95 08:46:53 7-Sep-95 16:48:13 krbtgt/TEST.SDSC.EDU@TEST.SDSC. EDU
c90 2% logout Connection closed by foreign host. number9 4%
number9 4% krlogin c90
San Diego Supercomputer Center CRAY C90 with 8 CPUs and 256 MW running UNICOS 184.108.40.206
Last successful login was : Thu Sep 7 15:47:42 from ibm-6000.sdsc.edu Account (? for available accounts) [sys200]:
number9 5% krlogin graywolf Last login: Thu Sep 7 08:52:54 from number9.sdsc.edu SunOS Release 4.1.3 (SDSC_SPARCSTATION) #6: Tue Apr 26 23:41:03 PDT 1994 Thu Sep 7 08:54:12 PDT 1995 graywolf 1%
The Key Distribution Center (KDC) and Ticket-Granting Service (TGS) are two parts of the Kerberos Server. At SDSC, we are running this on a Sun in the machine room (i.e., physically secure). The initial user passwords are known to the KDC and securely given to users (e.g., through paper mail).
When a user runs kinit, a message is sent to the KDC with the user id. The KDC responds with a message that is DES (Data Encryption Standard) encoded using the user's key (which is based on the user's password). When the user enters his password to kinit, it then uses that to make a key and attempt to decrypt the message from the KDC. If it decrypts properly, then the user has entered the password correctly and kinit saves encrypted information, a "ticket-granting ticket," in a ticket file. This is normally just a user-owned file in /tmp, i.e. /tmp/krb5cc_122. If someone broke into the user's workstation, access to his or her Kerberos accounts would be gained until the ticket-granting ticket expired.
The second part of the Kerberos server is the Ticket-Granting Service (TGS). The ticket sent from the KDC to kinit contains the user name, current time, duration of validation, name of workstation, etc., and a DES session key to be used for this session. All this is encoded with the TGS secret key, and then the session key is appended, and all this is encoded with the user's key. Thus if kinit can decrypt the packet, it has a session key, and it has a ticket that is encrypted with a key that it does not know (or need to). Later processes can pass this encrypted ticket, and information encrypted in the session key, to the TGS to begin similar series of authenticated communication transactions.
These methods result in a system in which passwords are only briefly needed on the local system, various keys and encrypted packets are used to authenticate, and secret keys are used but not known by clients.
There are some secret keys that must be set up by hand on some systems to identify each other. These are kept in uid 0 files (with no group or other access permissions), e.g., /etc/v5srvtab, for systems that are servers. The SDSC Cray and most SDSC workstations have v5srvtab files, as these are needed for the Kerberized server processes, i.e., when users ktelnet, or krlogin, etc., into one of these systems.
These secret keys are not needed for the client services, such as kinit, ktelnet, and krlogin, so they will not be needed for most of our remote users using SDSC-provided kerberoized clients for access to SDSC hosts.
The port of the Kerberos libraries to the Cray C90 went fairly well, but the port of various daemons and clients were more involved. After getting a few library compile errors resolved, many of the basic tests worked fine. SDSC staff member Andrew Gross ran some additional tests, found and fixed some problems, and got the basic message passing between the Cray and a test server working.
Our entire Cray port probably took about two man-months (spread over many months), as we had many problems to resolve with the ktelnet, krlogin, and other "r" command daemons. But at this point, we have telnetd (and telnet), krlogind (and krlogin), and the other "r" commands and daemons working well.
Previous versions of Kerberos 5 required the ISO Development Environment, but, fortunately, 5.4 did not. (Sandia had to port a version of the ISODE to the Cray for their Kerberos 5.2 work.) I found that I needed to use GNU make instead of CRI's make for the Kerberos build environment. Also, we found the 5.4 GNU automatic configuration system (which builds the Makefiles) sometimes difficult to work with, and for quite a few problems I patched Makefiles (Kerberos 5.5 has a revised configuration system).
We decided to use Concurrent Versions System (CVS) for our source management (with separate subdirectories for each architecture) and set that up on a fileserver accessible from each relevant host. CVS works well for this type of project, but we encountered various problems with it on the Cray and Alphas in particular.
It was found preferable to use CRI's login process (for both ktelnetd and krlogind) instead of the MIT Kerberos login. There were too many enhancements missing from the Kerberos login to make its use viable, including accessing the UDB, checking and prompting for multiple accounts, using the CRI ia_user routine, etc. Certain restrictions accompany a CRI login, however, such as the requirement of a .rhost entry for krlogind logins.
Most problems had to do with word size or include file and system definitions. In many cases it took a while to track a problem to the key section of code. In some cases small sections of CRI code were added to the Kerberos release (such as PTY handling in krlogind).
There were problems in krlogind interface to login (or init), errors in writing wtmp and utmp entries, problems in reading keytab files, errors in the window-size message processing, md4 encryption/decryption, "no access to tty," the Kerberos syslog system, removing credentials files, rcp buffer sizes, a srandom/srand48 problem, a runaway ktelnetd problem, an EOF tty setup problem, etc. Code was also added to krlogind to purge $TMPDIR directories on logout.
The Alpha required as many similar changes as the Cray for 64-bit words, although since the Alpha can allocate in smaller units, the actual changes differ. For example, changes were needed in routines des_read and des_write in krlogin.c and krlogind.c to handle the 4 byte network stream that is the length of the encrypted message that follows. For the Cray, these reads and writes were offset into the word. On the Alpha, the variable was declared to be an int instead of a long.
Much like the Cray, the SGI port required quite a few corrections to the system interface routines and utilities (telnet, "r" commands, etc.), although the Kerberos libraries themselves installed fairly easily. For krlogind on the SGI, we fixed a set of problems with the following changes:
1) If you attempt a "resize," you get "can't open terminal /dev/tty."
This was fixed when #2 was fixed.
2) Doing a "ps," no processes appear. (We had a similar problem on the Cray, but it doesn't appear to be due to the same cause on the SGIs.)
This is fixed by having krlogind.c do a setsid() call like the Sun and POSIX systems do, before the open(line, O_RDWR) call.
3) The output of a "last" command (which shows recent logins), does not include info in all the fields for a SGI krlogin or ktelnet session.
Various problems with writing utmp and wtmp file records were corrected to resolve this.
4) One does not get the normal SGI rlogin greeting messages:
number9 12% rlogin startrek IRIX Release 5.2 IP22 voyager Copyright 1987-1994 Silicon Graphics, Inc. All Rights Reserved. Last login: Thu Jun 29 09:13:52 PDT 1995 by UNKNOWN@number9.sdsc.edu Thu Jun 29 09:19:26 PDT 1995 voyager 1% logout Connection closed.This was fixed by having krlogind run SGI's login instead of the MIT-released "login.krb5."
number9 13% krlogin voyager Thu Jun 29 16:19:37 GMT 1995 voyager 1%
5) The TZ environment variable, and probably others, are not set.
This was also fixed by having krlogind run SGI's login instead of the MIT released "login.krb5."
6) The Last login message (see #4 above) sometimes shows "UNKNOWN@number9.sdsc.edu" as the last login.
This happens when one logs into an SGI with the regular telnet (as well as ktelnet). The rlogin and krlogin daemons set something correctly so that the user name appears instead of UNKNOWN (on the next login). Since SGI's telnet doesn't handle it right, we are not making it worse with ktelnet. This information may be stored in the SGI extended utmp and wtmp files (utmpx and wtmpx).
Over the next few months (fall, 1995), we plan to phase-in kerberized functions into the SDSC production environment. A primary goal will be to significantly reduce the plain-text passwords used by SDSC staff on the internal network. We also plan to eliminate plain-text root passwords on our network by using only encrypted rlogin sessions when we run `su.' We also plan to support some kerberos client access (i.e., kinit, kpasswd, and ktelnet) by off-site SDSC researchers using workstation types that we have at SDSC.
We plan to eventually integrate Kerberos into all of our systems (including the Paragon) and into more functions (including ftp, UniTree, and HPSS).
NSL UniTree, our mass storage system, is currently accessed via modified ftp clients on SDSC systems. Currently, we allow only limited remote access to UniTree. When we add Kerberos authentication, we will be able to provide secure remote access to UniTree via kerberized ftp clients.
Longer term, we are interested in how DCE authentication will evolve and in its possible interoperation with Kerberos. At some point, we should be able to utilize vendor-supported software for a Kerberos/DCE environment that will secure passwords.
Our mods have been given to staff at ANL and NIH, who were particularly interested in our SGI fixes, and we have sent our mods back to MIT where many of them, presumably, will be incorporated in the next release.
Networking staff: Tom Hutton Andrew Gross Jay Dombrowski Systems staff: Wayne Schroeder Tom Perrine Tom Sherwin Larry Diegel And SDSC User Consultant: Nancy Wilkins-DiehrBill Rahe, Walt VanDevander, and John Noe of Sandia Albuquerque provided us with valuable information (and source code) concerning their port of Kerberos 4 and 5.2. Chuck Athey and Rich Frobose of Livermore Computing shared valuable information on their experiences with Kerberos 5.2 (Sandia's port).
This work was funded in part by National Science Foundation Cooperative Agreement ASC-8902825.
All brand and product names are trademarks or registered trademarks of their respective holders.
For additional information, connect to SDSC's Home page at http://www.sdsc.edu and use the "SEARCH SDSC'S WWW SERVER" facility to search for "kerberos" to find this paper and other information.