Experience shows that a major source of computer security incidents is the compromise of re-usable passwords by clear text transmission over the network, or by weakly protected storage on disk on individual systems. This project proposes to greatly reduce the risk of such compromise by implementing a strong authentication system based on the Kerberos authentication protocol developed at MIT that avoids transmission or storage of passwords. The also system provides a secure portal between those systems where only Kerberos access is permitted (the "strengthened realm") and those systems where other forms of access are permitted (the "untrusted realm"). A phased implementation is proposed, beginning with the Run II systems now under development.

An analysis of the major computer security incidents at the laboratory over the past year, as well as the general sense of security incidents prior to that, shows that a common root cause of incidents is the compromise of passwords by transmission in clear text over the network. Passwords in clear text are susceptible to "sniffing" by any compromised or unscrupulous system in the network path between the source and destination. Once intercepted, they can be re-used to gain unauthorized access to the destination system. This is a well-known and common method for hackers to gain unauthorized access, and seems to be particularly a problem for university networks.

Further, with user access to a compromised system, hackers can fairly easily gain privileged root access. The local password file can then be cracked for weak passwords, leading to further compromise. This has been a factor in several of our major security incidents and further aggravates the response, since it can lead to requiring all the users of the compromised system to change their passwords. This is a major task on a large interactive system, such as the large servers for the Run II experiments.

The primary goal of this project is to implement a strong authentication system that eliminates (so far as practical) the transmission over the network of clear text re-usable passwords and their storage on local systems. Strong authentication systems are available and, in some cases, widely deployed, that address the vulnerabilities in transmitting and storing passwords. The inter-laboratory SLCCC Unclassified Computer Security Technical Working Group recommended that DOE laboratories adopt such a system in their white paper, Alternatives to Reusable Passwords: Robust Authentication. Strong authentication is likely to be required by new DOE unclassified computer security requirements.

Secondary, but important, goals include:

• Providing a single sign-on environment for users. A single authentication should allow users to gain access to many services on many systems;
• Integrating existing accounts, especially the Kerberos v4 accounts used for AFS;
• Centralizing account maintenance, in order to reduce the account maintenance burden for system administrators and allow laboratory-wide control of authentication;
• Consistent enforcement of password policies, such as length, quality and lifetime.

The system must provide acceptable levels of improvement in authentication and access control. It must be adaptable to new computer security threats and changes in system security requirements and new styles of computing and computing. It must be robust and stable. It must be readily deployable to universities and laboratories we collaborate with, including those not in the United States.

The system must include the supported Unix variants, as well as Windows NT. Support for Macintosh and Windows 95/98 systems is desirable. Certain systems, such as embedded systems or specialized on-line systems may not be capable of participating directly in strong authentication. These systems may be accommodated by alternate access.

The system must accommodate access for users and systems from outside the realm where strong authentication is enforced. In particular, the system must accommodate strong authentication of users without the installation of special hardware or software on the users’ desktops. This will accommodate those users who need to login from systems that do not or cannot have strong authentication directly installed (e.g. a public terminal, a "dumb" X terminal, or a pda).

The system should be capable of establishing trust relationships with other institutions where similar strong authentication systems are in place. This will allow user to have a single identity at multiple institutions. This assumes the systems are sufficiently compatible and the security policies at the other institution meet our criteria.

Finally, the implementation must allow meaningful improvements in security and authentication for the Run II experiments. It should be incorporated into the software infrastructure now being developed for Run II. This requires that prototyping of the strong authentication system proceed quickly enough to provide a stable framework while the Run II applications are being developed.

The model chosen for strong authentication divides the environment into four realms. The first of these, the strengthened realm, consists of all systems (whether on- or off-site) that require strong authentication for access from the network. These systems must disallow all traditional means of access that use weak authentication, such as telnet, rlogin, ftp, etc. Local access (i.e. via the console or locally attached display) with weak authentication is allowed, as are means of access over the network that do not otherwise expose passwords.

The untrusted realm consists of those systems that do not require strong authentication and permit weak authentication and traditional means of access. These systems may expose cleartext passwords on the network.

The portal provides a secure gateway between the strengthened and untrusted realms. Users will authenticate between systems in the untrusted realm and the portal realm through non-reusable passwords (e.g. SKey one-time password lists or password-generating hardware tokens such as SecureID or CryptoCard). Other than physical possession of the one-time passwords by the user, no special hardware or software is required on the untrusted system. The portal will provide the strong authentication for the user on the untrusted system to systems in the strengthened realm and will act as an application gateway for telnet and ftp, and perhaps other applications (e.g. ssh). Once authenticated via the portal, the user will use strongly authenticated versions of these applications from the portal to access strengthened systems. Strengthened systems will allow weakly authenticated outgoing connections to untrusted systems.

Finally, other sites which implement strong authentication, and which meet certain criteria, may be included in the trusted realm. Trusted realms will be required to provide levels of security and authentication equivalent to our own. Systems in a trusted realm (say, at another national laboratory) use their local strong authentication method, and trust relations (cross-authentication) between the trusted realm and the strengthened realm allow access to the strengthened realm without further authentication. Trusted realms are an optional but desirable feature of the plan –we may establish few (or no) trust relationships, depending on the criteria established (which include both technical and policy aspects).

Kerberos Authentication Features

The strong authentication protocol chosen for this project is Kerberos v5. Kerberos was developed at MIT in 1987 and has matured into a stable product with widespread operating system and application support. Even Microsoft is basing the authentication in Windows2000 on Kerberos v5. Kerberos continues to see active development, with new releases occurring approximately twice per year. Kerberos v4 is already in use at Fermilab as part of AFS and both Kerberos v4 and v5 are widely used at other laboratories and universities.

Kerberos is provides mutual authentication for users as well as services running on systems. Collectively, these are referred to as principals. Each principal has a symmetric key used to encrypt and decrypt short messages exchange with a key distribution center (kdc). For a user, this key is a hash of the user’s password; for a service, it is a random bit string. Knowledge of a key (equivalent to the ability to correctly decrypt messages from the kdc) authenticates the identity of a principal. The kdc holds a copy of the key for all the principals in the strengthened realm – clearly security of the kdc is critical.

Kerberos is specifically designed for use over insecure networks. Kerberos never transmits passwords over the network, not even encrypted. In order to reduce the possibility of obtaining a password by brute-force decryption attack, the password is only used to encrypt the initial exchange with the kdc, which is used to obtain a session key with a limited lifetime. This limits the amount of data encrypted with the user’s password that can be subjected to a brute-force attack.

Tickets are obtained from the kdc to authenticate a user to a service. A ticket contains a session key and information encrypted with the key of the service principal. A second copy of the session key is encrypted with the user’s key. The user presents the ticket to the service (this is handled by the user’s client application) and the ability of both the user and service to correctly decrypt the relevant parts of the ticket establishes knowledge of the correct keys and therefore establishes authentication. A particular ticket is the ticket-granting ticket, which authenticates a user with the ticket-granting service of the kdc, and allows a user to obtain tickets for other services.

Tickets can be forwardable, renewable, and/or post-dated. Forwardable tickets can be used with the kdc to authenticate to additional services beyond the original service they were obtained for. Renewable tickets can have their lifetime extended, by action of the user, beyond the default lifetime, up to an established limit. Post-dated tickets become valid after a time in the future.

Additional details of the Kerberos protocols are found in the Kerberos specification:

and the Frequently Asked Questions at:

The MIT Kerberos home page is located at:

Portal Features

Authenticated network access to systems within the strengthened realm must only be possible through Kerberos; all non-Kerberos methods of access must be disabled. The portal provides the gateway between the Kerberos strengthened realm and the non-Kerberos untrusted realm. In order to prevent disclosure of passwords on the untrusted network, non-disclosing one-time passwords must be used to authenticate to the portal. The portal will then obtain the initial set of Kerberos tickets on the user’s behalf.

The portal will function as an application gateway and will support limited applications. Currently, telnet and ftp will be supported. Other applications, including ssh, may be considered, based on user requirements. To work interactively on strengthened systems from the untrusted realm, users will first telnet to the portal and provide non-reusable authentication (Skey or hardware token). The portal will obtain Kerberos tickets on the users’ behalf. The Kerberos version of telnet will then be used on the portal system to access strengthened systems, without requiring users to enter their Kerberos password on an unencrypted connection. From the strengthened system, users will be able to invoke X applications to open multiple windows and applications on their untrusted system. Alternatively, the users may open multiple telnet sessions via the portal, but each session will require a separate authentication (use of a one-time password) and will consume additional resources on the portal.

Ftp is a portal issue only for file "pulls" from the strengthened realm to the untrusted realm. File "pushes" will be allowed directly and will not need the portal. "Pulls" may be implemented mounting the users’ AFS space on the portal, so that a two step operation is required. First, the file is placed in AFS space via a system in the strengthened realm. Then, the file is "pulled" to the untrusted system from AFS space via the portal, using a one-time password. Alternatively, a modified ftp server may be written for the portal that incorporates a Kerberos ftp client, allowing for "pass-through" file transfers.

SKey (or similar password list) authentication will be supported and will probably be preferred for "casual" or infrequent portal users. In addition, a hardware token system will be supported and will be preferred for regular portal users. SecureID and CryptoCard are possibilities.

Since there may be many concurrent interactive sessions through the portal, the portal will be chosen for its ability to support large numbers of interactive users. Scalability will also be considered so that the system can be grown, as necessary, to support the demand.

The portal is a necessary feature because there will be many systems which may not be able to participate in the strengthened Kerberos realm, for either technical or local policy reasons. However, it is clear that it will be more convenient for users to access systems in the strengthened realm if their own systems are in the strengthened realm, and the installation of Kerberos on individuals’ desktops will be encouraged and made as easy as possible. There are support issues to be considered for off-site systems. In addition, there are policy issues regarding the criteria for including systems into the strengthened realm and how there will be enforced (or the extent to which these will be enforced) when the system is not located at Fermilab.

System Administrator Issues

Placing a system in the strengthened realm will be a straight-forward procedure. A UPS install will load the required software onto the system, disabling the non-Kerberos clients and servers and replacing them with their Kerberos equivalents. Updates will be infrequent (a few time per year).

In order to prevent the disclosure of Kerberos passwords on the untrusted network, the initial Kerberos tickets must be obtained with a local login, via the console or local display. This requires disabling traditional methods of access – non-Kerberos telnet, ftp, rlogin, etc. – for systems in the trusted realm. To enforce this, a scan for these services will be conducted regularly (and automatically) for systems requesting tickets in the strengthened Kerberos realm. Systems not meeting the necessary criteria will not be allowed to obtain tickets. Exceptions will be made for services that do not disclose passwords (e.g. anonymous ftp).

Within the strengthened realm, password policies, including length, quality and lifetime of passwords, are managed and enforced at the kdc.

Kerberos manages authentication, establishing the identity of a user. Kerberos does not manage authorization, what services a user is allowed to access. The local system administrator manages authorization. By default, Unix will map a Kerberos user principal (less the local realm name) to a matching user in the local password file (i.e. the Kerberos principal "NOMAN@FNAL.GOV" matches the local user "noman") for login authorization. No password is recorded, however, in the local password file. In addition, if multiple principals are granted access to the same local account, or if the principal’s realm name is not the local realm (i.e. a login from a trusted realm), the individual principals can be listed in a $HOME/.k5login file, similar to a .rhosts file. This technique is useful for shared group accounts, particularly root accounts.

User Issues

With a desktop in the strengthened realm configured with krb5.login (for Unix, or the equivalent kerbgina for Windows) to obtain initial tickets, users enter their Kerberos password once for the initial login to their desktop. As long as the limited lifetime of the initial ticket-granting ticket doesn’t expire, the clients for services such as telnet and ftp obtain tickets automatically and transparently when accessing other strengthened systems.

For very long sessions, the ticket-granting ticket can be renewed before expiration, up to the maximum renewable lifetime. These lifetimes will be set long (~12 hours lifetime and ~7 days renewable lifetime) to support both long interactive sessions and batch jobs. Once the ticket-granting ticket expires, new connections cannot be opened, but existing connections are not terminated.

Non-Kerberos access to Kerberos services (i.e. direct access from the untrusted realm to the strengthened realm) will simply be refused without the possibility of entering (and therefore exposing) a password.

For access from the untrusted realm to the strengthened realm, users must login to a portal system, as described previously. This may be an unfamiliar procedure for casual users (e.g. users whose desktops are normally in the strengthened realm, but are "on the road" and using an untrusted system). Services on the portal realm (e.g. telnet and frp) will be more cumbersome to use and certain services may not be usable at all. "Push" services (including X) that initiate outgoing connections from the strengthened realm to the untrusted realm will not need modification. Most users will prefer to place their systems in the strengthened realm, since this provides the greatest convenience and transparency of access.

Figures (1) through (3) illustrate the modes of accessing the strengthened realm:

Figure 1: Strengthened Realm to Strengthened Realm (Kerberos Secured Access)

Figure 2: Trusted Realm to Strengthened Realm (Cross-Authenticated Access)

Figure 3: Untrusted Realm to Strengthened Realm (Portal Access)

Feedback Groups

Computing Division charged to groups to provide feedback on the strong authentication plan. These groups consisted of "power" users and software developers within the Computing Division, with the users representing specific experiments (primarily drawn from Run II). The groups were given the charge:

"This group has the very important job of making sure that the proposed authentication strategy does not make it overly difficult to perform normal user/normal software development and maintenance functions."

The groups met bi-weekly from 1/21/99 through 3/4/99 and consisted of:

User Feedback: Vivan O’Dell (KTeV); Stephan Lammel (CDF); Mike Diesburg (D0); Chris Stoughton (SDSS); Alan Jonckheere (D0); Robert Harris (CDF);

Developer Feedback: Marilyn Schweitzer, Jim Fromm (Farms); Jon Bakken (Enstore); Krzystof Genser (HPSS); Mark Fischler (PAT); Matt Vranicar (Databases); Carmenita Moore (Online); Lauri Loebel-Carpenter (Applications);

The groups examined seventy individual issues in thirteen broad areas, including: CVS code distribution; scripts; batch; applications interface; online systems; portal realm features; system administration; Oracle database; SAM/CORBA; mass storage; web; security features; miscellaneous issues. Acceptable technical solutions were proposed for all major issues raised by the feedback groups; no "show-stopping" issues were identified.

The complete report of the feedback groups can be found at:

A third feedback group is being formed to address the issues facing remote users, such as at universities.

The implementation of the strong authentication project is intended to make significant improvements for Run II, and therefore the schedule is driven by the need to provide a stable limited production system for final Run II software development, and well in advance of Run II data-taking in late CY2000.

Initial Tests

The initial implementation phase consists of installing a prototype kdc with a small number of principals (~2-3) and performing basic functionality checks of the MIT distribution software on a small number of desktops (~2-3). This phase will provide "proof of concept". Preliminary investigations will be done of issues for user interface, operations and maintenance, software development and hardware requirements. Portal hardware and software requirements will be investigated, including any pre-existing software implementations that can be adapted for use here. MSWindows integration will also be investigated.

This phase is essentially completed.

Pilot Project: CDF Run II Analysis Prototype

The next phase consists of a small pilot project with "real" end users and applications. The CDF Run II Analysis Prototype has been chosen for this pilot. The system consists of two server, a Sun and SGI, and an initially small number (~6) Linux desktops. Software distributions for these operating systems will be built and made available via UPS, and supported for the pilot project.

Interim user and developer documentation will be developed and made available, and the necessary Kerberos software libraries will be built for those operating systems and applications supported for the pilot. Specific software applications (in addition to those already included in the MIT distribution) will be modified to use Kerberos authentication. These applications will be limited during the pilot project to cron, batch (LSF) and www (Apache). The goal is to be able to build and run the analysis applications, and import and export data, using Kerberos authentication. Certain applications are specifically excluded from the pilot. These include Oracle and CVS.

This phase will include acquisition and installation of kdc and portal systems similar to those expected for final production. Operations and maintenance issues for the kdc and portal will be investigated, including the correct sizing and scaling of these systems for the expected production load. The choice of hardware token will also be evaluated.

In order that software development work can proceed during the initial period of the pilot project traditional services will not be turned off. Kerberos authentication will be optional, although participants in the pilot will be expected to use it whenever possible. We expect to enforce Kerberos authentication or access through the portal before the end of the pilot, with traditional services turned off (just as they will be in the production systems).

This phase has been started.

Limited Production: Run II

The limited production phase will include the remaining systems, users and applications needed for the Run II experiments. By the end of this phase, approximately 1500 systems and 1000 users will be using the strengthened realm and portal. These will include the Run II farms, new and old analysis systems, mass storage and on- and off-site desktops. The applications include Oracle, FMSS, Enstore, SAM, ROOT, the support databases, DIM and others.

Final user and developer documentation will be developed and made available, and the Kerberos software libraries will be built for the remaining supported operating systems and applications. User, system administrator and helpdesk training will be developed and provided.

Decisions will be made for MSWindows and Macintosh support and recommended configurations.

Based on the experience of the pilot project, any needed upgrades to the kdc and portal systems will be acquired and installed.

The necessary Kerberos principals will be created, and the passwords distributed. Hardware tokens will be acquired and distributed, using the final choice made in the pilot phase. The centralized name and address database now under development in Business Services will be used to maintain the user and principal information in the kdc.

Based on the needs of the laboratory, other systems (Beams, Business Services, central computing) may be included in the limited production phase.

Final Production

The final production phase assimilates the remaining areas of the laboratory, with necessary upgrades to the kdc and portal, additional training and documentation, and incorporation of Kerberos authentication into applications where desirable or necessary.