Single Sign-On and the System Administrator · PDF fileSingle Sign-On and the System...

The following paper was originally published in theProceedings of the Twelfth Systems Administration Conference (LISA ’98)

Boston, Massachusetts, December 6-11, 1998

For more information about USENIX Association contact:

1. Phone: 510 528-86492. FAX: 510 548-57383. Email: [email protected]. WWW URL: http://www.usenix.org

Single Sign-On and the System Administrator

Michael Fleming Grubb and Rob CarterDuke University

Single Sign-On and theSystem Administrator

Michael Fleming Grubb and Rob Carter – Duke University

ABSTRACT

Large organizations are increasingly shifting critical computing operations from traditionalhost-based application platforms to network-distributed, client-server platforms. The resultingproliferation of disparate systems poses problems for end-users, who must frequently trackmultiple electronic identities across different systems, as well as for system administrators, whomust manage security and access for those systems. Single sign-on mechanisms have becomeincreasingly important in solving these problems. System administrators who are not alreadybeing pressured to provide single sign-on solutions can expect to be in the near future. DukeUniversity has recently embarked on an enterprise-wide single sign-on project. This paperdiscusses the various factors involved in the decision to deploy a single sign-on solution,reviews a variety of available approaches to the problem of electronic identity proliferation, anddocuments Duke’s research and findings to date.

Introduction

The number of mission-critical computing plat-forms in today’s enterprise is exploding. Applicationsthat were once housed on ‘‘big iron’’ (MVS main-frames, enterprise-class Unix servers, etc.) are increas-ingly replaced with network-distributed client-serverapplications running across large numbers of smallersystems. Concurrently, the number of end users asso-ciated with these systems has increased dramaticallyin recent years. Together, these changes have resultedin a sizable increase in the number of disparate sys-tems which end users interact with on a regular basisand which system administrators manage.

The forces driving these changes are well-known. Increased functionality and faster responsetime for end-users, increased demand for access toorganizational information, decreased total cost ofownership, and Y2K considerations have all con-tributed to the explosion in network-based systems.While network-distributed applications have obviousadvantages for both end-users and system administra-tors, their growth poses new problems for authentica-tion, auditing, and security management.

In the traditional, host-based application environ-ment, authentication was simplistic. Users wereauthenticated by the host operating system as they pre-sented for entry into the system, and were then grantedaccess to applications and data based on their locally-authenticated identities. Multiple applications co-located on a single large host system would shareauthentication information through the host’s operat-ing system, and access to the host system could bemanaged cheaply and centrally.

Audit trails could also be maintained centrally,and because all applications shared a common, operat-ing system-specific authentication mechanism, could

easily be correlated between applications. Each indi-vidual would appear with a single identity across allapplications on the central host. Therefore, auditrecords pertaining to an individual’s actions withinone application housed on the central host could easilybe correlated with records pertaining to other actionstaken by that same individual. Similarly, security andaccess management was straightforward, amounting inmost cases to little more than maintaining a single userdatabase and various application-specific authoriza-tion tables.

With the advent of network-distributed applica-tions and the accompanying increase in the number ofdisparate enterprise systems, authentication andrelated issues have become more complex. Each dif-ferent application or service may require separateauthentication for its users. Users of multiple applica-tions or systems may be confronted with a maddeninglist of disparate electronic identities and authenticatorsto remember. End users may be required to authenti-cate themselves multiple times during a single worksession, and may have to remember and maintain adaunting number of login ids and passwords.

From the standpoint of the system administrator,the situation is no less disturbing. In the more dis-tributed world, administrators must maintain authenti-cation information across multiple platforms by creat-ing, issuing, and deleting users’ authentication infor-mation in multiple different contexts. While auto-mated account management systems and distributedmanagement tools (e.g., Tivoli, CA/Unicenter) canreduce the per-user effort involved in managing useridentities across multiple systems, they are often asdifficult to manage and maintain as the systems theysupport.

Further, administrators who manage electronicsecurity for their organizations must often go to great

1998 LISA XII – December 6-11, 1998 – Boston, MA 63

Single Sign-On and the System Administrator Fleming Grubb and Carter

lengths to ensure that audit trails from disparate sys-tems, regardless of whether they share authenticationinformation with one another, can be reconciled.Actions performed by one individual across a numberof different systems may be difficult to correlate withthat single individual if the systems involved do notagree as to the individual’s authenticated identity.

Additionally, the proliferation of electronic iden-tities has social ramifications that can be devastatingto overall system security. Presented with ten or moredifferent authenticators for separate applications andsystems, many end-users will resort to using insecurebut easily remembered passwords, or will resort torecording their authentication information in an inse-cure fashion. At Duke, the authors have frequently runacross this phenomenon in the form of users (and insome cases, system administrators) taping lists of theirvarious logins and passwords to monitors in theiroffices. Enforcing any reasonable security policy insuch an environment can be well-nigh impossible.

As end-users become increasingly frustrated bythese issues, and as organizational leaders grow intheir awareness of the serious security ramifications ofelectronic identity proliferation, pressure increases onsystems administrators to provide technical solutionsto these problems. Typically, this pressure results inthe demand for a ‘‘single sign-on solution.’’

Single sign-on is something of a holy grail forlarge organizations. Everyone seems to want it, manypeople claim to have it for sale, but no one seems toagree as to what, exactly, it is. To many, ‘‘single sign-on’’ means that each user in the enterprise has onlyone userid and associated password. To others, ‘‘singlesign-on’’ means that wherever a user logs in, he is pre-sented with an interface and application set that isspecifically tailored to him and which follows himthroughout the enterprise. Another interpretation,favored by the authors, is that ‘‘single sign-on’’ per seis the goal of presenting the end user with only oneauthentication challenge during a single work session.

At Duke, the demand for a ‘‘single sign-on solu-tion’’ started in earnest as the University began workon a number of parallel enterprise-wide computingprojects. Payroll, human resources, student informa-tion systems, and purchasing were all targeted formigration off the institutional MVS mainframe andonto a set of distributed Unix-based systems. As thesoftware engineers working on the deployment ofthese new systems began to consider work-flow pat-terns and information sharing requirements, and asusers began to realistically consider the effect thesenew systems would have on their day to day activities,they realized the potential pitfalls in managing userinformation across such widely-distributed systems.

The authors, as lead system administrators forthe arm of the university charged with the design andmaintenance of institutional computing infrastructure,were approached with a deceptively simple question:

How should the University go about providing a ‘‘sin-gle sign-on’’ for the many and varied enterprise-wideapplications in use and soon to be deployed on cam-pus? A review committee, chaired by the authors, wasformed and charged with answering this question.What was originally expected to be a three-monthreview process followed by rapid deployment of acomplete solution has since become a 9-month-longinvestigation culminating in a recommended institu-tional strategy for user authentication which, we hope,will limit but not eliminate the proliferation of elec-tronic authenticators across the enterprise. With thispaper, we hope to offer other systems administratorsthe benefit of experience thus far at Duke in designingand implementing a comprehensive single sign-onsolution.

Single Sign-On: One Password, Two Flavors

Before designing a single sign-on solution, a sys-tem administrator must first determine precisely what‘‘single sign-on’’ means in her local environment. Isthe demand for a single sign-on solution being drivenby a need for enhanced security and auditability, or isit more an outgrowth of end-user frustration with theproliferation of electronic identities? To what extentare existing systems, many of which may alreadyhouse multiple authenticators for individual users, tobe participants in a single sign-on solution? Is the userpopulation highly mobile, or do individual users workfrom fixed locations, and to what extent do individualusers need simultaneous access to multiple differentapplications or systems? Answers to these and otherbasic questions will help focus efforts on solutionsappropriate to local environments.

In particular, it is critical that organizationsinvestigating single sign-on solutions decide whethertheir need is for a method by which to reduce the num-ber of authenticators each end-user must rememberand maintain, or whether their need is for a method bywhich to reduce the number of authentication opera-tions a given user must perform in the course of a sin-gle work session. In the former case, the ultimate goalis the creation of a Single Authentication Realm, orSAR, where each user has only one authenticator(userid and password). In the latter case, the ultimategoal is the creation of an actual Single Sign-On, orSSO, mechanism, where each user authenticates onlyonce during each work session. In the SAR case, indi-vidual users may be required to authenticate multipletimes during a given work session, typically once foreach disparate application or system accessed. In theSSO case, each user performs at most one authentica-tion operation during each work session, althoughmultiple authentication operations may be performedon behalf of the user by SSO software during thecourse of the user’s work.

Building an enterprise-wide SAR is not a neces-sary prerequisite to an SSO solution, but in manycases it may be sufficient to meet an organization’s

64 1998 LISA XII – December 6-11, 1998 – Boston, MA

Fleming Grubb and Carter Single Sign-On and the System Administrator

needs. A SAR can eliminate many of the security risksassociated with electronic identity proliferation. Withonly one set of authentication information to remem-ber and maintain, users are less likely to practice poorpassword hygiene and are more likely to protect theirauthenticator information. A SAR can also eliminatemany of the system administration problems posed byuserid proliferation. As each user has only one authen-ticated identity, reconciling audit trails across systemsparticipating in the SAR becomes as easy as reconcil-ing audit trails across multiple host-based applicationson a single host, and user identity management (creat-ing and removing authentication information for indi-vidual users) is reduced to managing data associatedwith the SAR. A SAR can also significantly reducethe overall cost of managing access to critical systemsby reducing the number of times individual users mustbe initially certified (that is, the number of times indi-viduals’ actual identities must be ascertained andrecorded in order to validate new authentication iden-tities issued to them). With a functioning SAR, eachindividual need only be identified by system staff once(to authenticate their identity within the SAR at itsinception), so strong certification policies can beenforced with less time investment by both end-usersand system administrators.

A SAR, however, may not be sufficient to satisfythe demands of an organization’s user population.While each user may have only one authenticator(e.g., a login/password pair) to remember and main-tain, users may still be annoyed by the need to repeat-edly enter authentication information during a singlework session. At Duke, this has been of particular con-cern to the health-care community associated with theUniversity’s Medical Center. Physicians, nurses, andother health-care providers are understandably con-cerned about the time they may be required to spendrepeatedly identifying themselves to different systemsduring a single session. In life or death situations, thefew seconds a physician spends re-authenticating dur-ing a critical work session may make a real differencein the outcome of his or her patient’s treatment.

Depending on exactly how it is implemented, aSAR may also increase the exposure of secure authen-tication information on possibly insecure networks,resulting in an overall decrease in system security. Inessence, although each user need only remember onecombination to open any organizational safe, the like-lihood of that combination being compromised by adetermined safe-cracker bent on watching the user’sday-to-day activities may be increased under some cir-cumstances.

Addressing these latter issues usually involvesthe deployment of a full SSO solution. This may takevarious forms: a carefully-designed SAR issuingreusable authentication credentials honored by all par-ticipating systems and services, a redesigned set ofendpoint systems and applications built specifically torely on a third-party authentication system to identify

users, a separate SSO application designed to proxyauthentication operations for previously-authenticatedusers, or some mixture of all three. In addition to theadvantages offered by its underlying (or implicit)SAR, an SSO solution can increase overall user satis-faction with computing systems, and can reduce thefrequency and extent of a system’s security exposure.

Depending on the specific SSO approach chosen,however, deploying and maintaining an SSO solutioncan be both labor-intensive for the system administra-tor and expensive. Maintaining the SAR and/or SSOinfrastructure itself may in some circumstancesbecome a significant drain on system administrators.Developing and maintaining interfaces between agiven SSO mechanism and legacy applications orapplication environments may also be difficult orimpossible. Additionally, cost considerations maylimit the extent to which an SSO mechanism can bedeployed enterprise-wide.

Application-Independent Authentication vs. Appli-cation-Dependent Authorization

It is important to note that both SAR and SSOsolutions pertain to authentication, rather than autho-rization. Authentication, for purposes of this discus-sion, is the process by which the unique identity of anindividual user is determined and represented in elec-tronic form. Authorization, on the other hand, is theprocess by which a particular authenticated individualis identified as authorized to access a particular ser-vice or datum. As the authors found in early discus-sions at Duke with interested parties, authenticationand authorization are frequently confused with oneanother, and as the authors also found in early discus-sions at Duke, authorization issues are frequentlymuch more political than authentication issues.

Authentication is by its nature an application-independent process because an individual’s identity isunique to the individual, regardless of what role theindividual is fulfilling or what operation the individualis attempting to perform. Authorization is by contrastan application-dependent process because differentapplications may need to control access within theirindividual domains quite differently. User authoriza-tion poses its own unique set of challenges for bothapplication programmers and system administrators,none of which are directly addressed by SAR or SSOsolutions.

Authentication and authorization are, however,closely interrelated. In order to make appropriateauthorization decisions, applications must amongother things have access to reliable authenticationinformation. An application which cannot uniquelyidentify its user cannot hope to make appropriateauthorization decisions. Ideally, a SAR can providethe basis for building a cross-platform authorizationinfrastructure within an organization. While authoriza-tion mechanisms are outside the scope of this paper, it



should be noted that strong authentication mechanismscan play a part in supporting strong authorizationmechanisms.

Options for Establishing a SAR

Once a decision has been made to implement aSingle Authentication Realm, the system administratormay be tasked with recommending a particularauthentication solution for use within the SAR. Thereare a variety of authentication options, each with itsown strengths and weaknesses. Depending on organi-zation-specific needs, any or all of the availableoptions may need to be investigated or used in thedevelopment of an enterprise-wide SAR.

Policy-Based SAR: Solution by Fiat

Perhaps the simplest, although certainly neitherthe most robust nor the most functional solution theauthors have heard of for building a SAR for a largeenterprise is to dictate by organizational policy thateach user shall use one userid and password for eachsystem and application. Effectively, the organizationachieves a SAR by fiat; institutional policy forbids theproliferation of authenticators.

In the authors’ experience, such restrictive dictaare virtually impossible to enforce in any but thesmallest and most tightly-managed organizations. Asthe number of users increases, and particularly as thereare more system administrators who must cooperatewith such a policy in order to make it enforceable, thelabor required to enforce the policy increases beyondmanageable limits.

Further, it is impossible to enforce such a restric-tive policy across disparate systems without sacrific-ing password security; either those administratorsresponsible for enforcement of the policy must haveaccess to users’ individual authenticator information,or systems must somehow compare authenticators ona regular basis to identify violations of the policy.

Moreover, successful implementation of such arestrictive policy could increase the overall securityvulnerability of systems managed under the policy byincreasing the number of points from which the secu-rity of users’ authenticators are vulnerable to attack.Because all cooperating systems must replicate users’authentication information locally, the security of allcooperating systems is limited by the security of themost loosely-managed system in the group. Also,since there is no single location from which all possi-bly-compromised authenticators owned by a particularindividual can be modified or revoked, it becomestime consuming and expensive for system administra-tors to address emergent security breaches, and usersrun the risk of neglecting to update one or more com-promised authenticators, leaving themselves open tocontinued attack.

Despite its weaknesses, this approach can bemade to work under certain circumstances. A similar

approach has been in use within the Duke UniversityMedical Center for a number of years. Upon arrival,each employee of the Medical Center is assigned aDEMPO (Duke Electronic Mail Post Office) id whichis guaranteed unique within the set of DEMPO ids,along with a DEMPO password. System administra-tors throughout the Medical Center are required, bypolicy, to use DEMPO ids in creating accounts ontheir systems.

When the policy was instituted, in the late 1980s,the Medical Center had only a few multi-user systems,and still fewer system administrators. The majority ofcomputing within the Medical Center was still central-ized on a large MVS mainframe, and the majority ofdepartmental computing platforms within the MedicalCenter were managed by a handful of corporate sys-tem administrators. Along with the policy, the MedicalCenter established an electronic mail service based onthe PMDF product from Innosoft, and used a PMDFmail gateway to provide the appearance of a unifiedelectronic mail system using DEMPO ids as electronicmail aliases. This unified electronic mail service madethe DEMPO id mandate somewhat more palatable toend-users than it might otherwise have been, andgiven the limited number of administrators involved,the project was an initial success. Once the DEMPO idpolicy had become a part of the Medical Center corpo-rate culture, its success as an organizational policywas a fait accompli.

A variety of complications have arisen over theyears as a result of this policy. For example, DEMPOids are assigned to end-users based on their surnamesat the time of their hiring. Since many individualschange their surnames as a result of changes in maritalstatus, adoption, etc., there are frequent requests tochange users’ DEMPO ids to match their new sur-names, requests which cannot be honored under exist-ing policy. Further, enforcement of the DEMPO idpolicy has been impossible in an environment inwhich individual principal investigators have almostcomplete control over their grant-funded operations,and each failure in enforcement leads to increasedfriction among those system administrators who areforced to follow the stated policy. Although the policyhas been in effect within the Medical Center for anumber of years, it continues to be the cause ofrepeated complaints by end-users and system adminis-trators alike.

Unfortunately, this policy-based approach mayoften be the first one put forward by managers andadministrators eager to arrive at a ‘‘quick fix’’ for theproblem of identity proliferation. This method may, atfirst, seem like a low-cost, high-yield solution to whatcould otherwise be an expensive and complex problemto solve. At Duke, this was the case; it was originallysuggested that enforcing a strict policy across systemsmight provide a simple way to control identity prolif-eration at the institution. We strongly discourage this



approach, which was ultimately discarded at Duke infavor of other, more feature-rich options.

Network-Based Authentication Mechanisms: ABetter ApproachA more sound approach to the creation of a SAR

is the use of a network-based authentication service ofsome kind. A number of different services are avail-able to the system administrator, ranging in complex-ity from simple network-distributed databases to com-plex third-party authentication protocols based on var-ious encryption technologies. Each of theseapproaches has its own strengths and weaknesses, andany or all of them may reasonably be viewed as candi-dates for partial or complete SAR solutions, depend-ing on the specific requirements of an organization.

The simplest and most widely-utilized network-based solutions are network-distributed databases. Byproviding network-distributed access to a singleauthentication database, multiple cooperating systemscan share users’ authentication information, yielding aSAR. Some of the most common implementations ofthis approach are little more than network extensionsof the well-known Unix passwd(4) table mechanism.

rgc HS TXT "rgc:PASSWORDCRYPT:103:4:His Nobs:/home/rgc:/bin/bash"103 HS TXT "rgc:PASSWORDCRYPT:103:4:His Nobs:/home/rgc:/bin/bash"

Figure 1: Domain table records.

Hesiod: Authentication via DNS

One such approach, Hesiod, is a mechanism fordistributing passwd table information (or virtually anyarbitrary textual information) across a network usingextensions to the traditional domain name service(DNS). Developed in the late 1980s at MIT, Hesiodbuilds on what was and still is a well-supported stan-dard for network-based information distribution. In theHesiod approach, authentication information tradition-ally stored in a local Unix passwd table (userids,encrypted passwords, etc.) is stored in extended DNSrecords and made available via extensions to the nor-mal domain name resolution protocol (cf. RFCs 1034& 1035). Hesiod-capable DNS servers support, inaddition to the traditional DNS records of class ‘‘IN,’’records of class ‘‘HS.’’ Class ‘‘HS’’ records mayinclude records of type ‘‘TXT,’’ containing arbitrarytext strings indexed by other arbitrary text strings.

For a number of years, Digital Equipment Cor-poration’s Ultrix operating system provided nativesupport for Hesiod as a means of distributing Unixpasswd table information. The DEC implementationof Hesiod was in use for some time within Duke’spublic Unix computing facilities, and presents a rea-sonable example of the Hesiod approach.

In this implementation, additional Hesiodpseudo-domains are constructed containing class‘‘HS,’’ type ‘‘TXT’’ records carrying user informationin the standard Unix passwd and group table formats.

The primary DNS server for a given domain,‘‘team.foo.org’’ for example, publishes not only theauthoritative ‘‘team.foo.org’’ DNS information, butalso authoritative Hesiod information for the pseudo-domains ‘‘passwd.team.foo.org’’ and‘‘group.team.foo.org.’’ These pseudo-domain tablescontain standard passwd and group table information.For example, the ‘‘passwd.team.foo.org’’ domain tablemight include records of the form show in Figure 1that support access to user passwd table entriesindexed on both login id and uid number.

This information, along with standard DNSinformation, is then made available across a networkvia an extended version of the standard name resolu-tion protocol. An extension to the standard DNS APIis made available through Hesiod-aware replacementsfor the standard resolver routines (commonly, a single‘‘hes_resolve()’’ routine and a single ‘‘hes_error()’’routine) to allow applications to search for authentica-tion information in the form of passwd table entries.Hesiod queries for records pertaining to ‘‘rgc.passwd.team.foo.org’’ or ‘‘103.passwd.team.foo.org’’ would,in the example above, return passwd table informationfor the user ‘‘His Nobs.’’

In the DEC implementation of Hesiod, this abil-ity to index individual passwd table entries within aHesiod server’s primary Hesiod tables on multiplekeys was used to provide native support within theUltrix operating system for Hesiod as a primaryauthentication mechanism. Under Ultrix, Hesiod-aware versions of the standard getpwnam(), getp-wuid(), and getpwent() library calls were made avail-able which would, depending on the configuration of agiven system, return information retrieved via theHesiod resolver API. Thus, a homogeneous networkof Ultrix machines could achieve the benefits of aSAR through direct use of Hesiod.

Hesiod exhibits a number of strengths. Havingbeen developed as part of the MIT Athena project,source code to implementations of Hesiod is freelyavailable, and having been implemented as an exten-sion to a well-known and well-standardized protocol,Hesiod boasts a level of standards compliance fewsimilar systems achieve. Hesiod tables are relativelyeasy to manage, being structured similarly to regularDNS tables, and can be distributed across multipleHesiod servers via the same zone transfer mechanismused to synchronize DNS tables between primary andsecondary domain name servers. As is the case withtraditional DNS information, Hesiod information canbe published by multiple cooperating servers, some ofwhich may act as ‘‘caching’’ servers to enhance Hes-iod look-up performance across wide-area networks.



Hesiod is not, however, a perfect solution to theSAR problem. To date, the authors are only aware ofone major vendor providing native operating systemsupport for Hesiod as a primary authentication mecha-nism (Digital Equipment Corporation). Although it ispossible to use the open Hesiod API to modify anyarbitrary operating system or application to support aHesiod-based SAR, retrofitting Hesiod support intoexisting applications (particularly vended applica-tions) can be difficult.

Additionally, Hesiod does not in itself provideany mechanism for securing information stored inHesiod tables. Not only are Hesiod tables stored inplain text on Hesiod servers, but Hesiod information isalso transported over the network in plain text. Fur-ther, Hesiod servers do not necessarily enforce anylimits on what client machines can gain access to Hes-iod information, although recent versions of the BINDname server can be used to address that problem.These properties make Hesiod unsuitable for the dis-tribution of secure information, and depending on thesecurity requirements of specific organizations, unsuit-able as the basis for a SAR.

NIS (YP): Authentication Databases via RPCs

Another network-based authentication databaseapproach to developing a SAR is the use of Sun’s Yel-low Pages (YP) or Network Information Nameservice.Developed by Sun Microsystems under the auspices ofthe company’s ONC development project, NIS (for-merly known as Yellow Pages) provides much thesame functionality as Hesiod, but uses a completelydifferent network infrastructure. Although NIS wasoriginally developed as a Sun Microsystems initiative,the subsequent opening of Sun’s ONC RPC interfacehas led to a number of different vendors offering sup-port for the mechanism.

In the NIS environment, as in the Hesiod envi-ronment, groups of cooperating machines are referredto as domains. Although they frequently coincide withDNS domains, NIS domains are completely orthogo-nal to DNS domains. Machines in multiple differentDNS domains can, in theory, be members of the sameNIS domain, and vice-versa.

Like Hesiod, NIS provides a mechanism for dis-tributing arbitrary database tables (termed ‘‘maps’’)from a single set of database servers to a number ofclients across a network. Also as is the case with Hes-iod, the database tables distributed by NIS can includeauthentication information, typically stored in thestandard Unix passwd and group table format.

NIS, however, uses a completely different mech-anism to actually distribute information across the net-work. Whereas Hesiod relies on the pre-existing DNSstandard for network extensibility, NIS relies on Sun’sONC RPC mechanism. In the NIS scenario, clientmachines within a given NIS domain use any of avariety of NIS-specific RPC calls to perform search,retrieval, and update operations on NIS data tables

stored on NIS servers. NIS clients are directed to theirrespective domains’ NIS servers via a process of clientbinding. NIS client machines are intrinsically aware ofthe NIS servers in their environment, and direct anyrequired RPC calls to their respective servers.

When used as the basis for a SAR, NIS takes theplace of the traditional Unix passwd and group tablemechanism, much as Hesiod does in the earlier exam-ple. NIS client systems are typically equipped withNIS-aware versions of the standard getpwnam(), getp-went(), and getpwuid() routines, allowing the use ofNIS for network-based access to authentication infor-mation in a manner that is transparent to applicationswritten to use native Unix authentication mechanisms.

As is the case with Hesiod, there may be morethan one NIS server configured for a given NISdomain. In such cases, one NIS server acts as the mas-ter, processing all updates and periodically conveyingnew copies of its master tables to the other servers,which act as slaves. Both NIS master servers and NISslave servers can respond to RPC requests, permittingmultiple servers to be used both for redundancy andfor load balancing. NIS is ‘‘open,’’ in the sense thatSun Microsystems has released information about theNIS API and its associated network protocols, andvarious free versions of Unix and Unix-like operatingsystems include source code to functional NIS imple-mentations.

Like Hesiod, NIS suffers from some seriousdrawbacks when viewed as a complete SAR solution.While NIS is supported ‘‘out of the box’’ by a widervariety of operating systems and applications plat-forms than Hesiod, they suffer from similar securityproblems. NIS implementations used as the basis forSARs typically still expose secure authenticationinformation on a possibly insecure network, and mayin some cases promiscuously distribute passwd tableinformation to systems outside a given NIS domain.Such exposure is widely considered to constitute asecurity breach, since publication of user authentica-tion information (particularly encrypted passwords)can assist would-be intruders in the exercise of brute-force and cryptographic attacks against the authentica-tion system.

NIS+: Security at a Cost

Partially to address concerns regarding the open-ness of the NIS and Hesiod security models, SunMicrosystems developed NIS+, a NIS (version 2) fol-low-on. NIS+ provides some of the same features asHesiod and NIS, but does so through yet another com-pletely different network distribution mechanism.Although similar to NIS in name and general function-ality, NIS+ represents a major shift in Sun’s approachto network-distributed passwd table information.

Like NIS, NIS+ relies on an RPC mechanism toachieve network distribution of arbitrary data, and likeNIS, NIS+ is designed specifically to solve the prob-lem of extending the traditional Unix passwd table



mechanism (and similar mechanisms) into a net-worked environment. NIS+, however, relies on a mod-ified RPC mechanism called ‘‘Secure RPC.’’ In thetraditional NIS model, arbitrary clients can bind them-selves to any available NIS server and execute RPCsto access data housed on the server, leaving open thepossibility of unauthorized accesses to secure authen-tication data. In the NIS+ model, clients and serversshare a secret encryption key, allowing NIS+ clientsand servers to cross-authenticate before information inany NIS+ tables is accessed. This additionally allowsSecure RPC-based applications like NIS+ to takeadvantage of session-level encryption of network con-versations, limiting or eliminating the exposure ofsecure information in plain text across a possibly inse-cure network. As a replacement for traditional NISimplementations in supported environments, NIS+offers some significant security advantages.

NIS+ suffers from some serious drawbacks asthe basis for a SAR in a heterogeneous network envi-ronment, however. To our knowledge, Sun Microsys-tems has not ‘‘opened up’’ the NIS+ protocols suffi-ciently to enable competing implementations. Thus,stable NIS+ clients are only available for use with Sunplatforms (although note that there has been some lim-ited success with reverse engineering NIS+ behaviorfor FreeBSD, Linux and other Free Unix platforms).While NIS+ servers can be operated in ‘‘NIS compati-bility mode’’ to support non-Sun clients, runningservers in compatibility mode erodes any securityadvantages offered by NIS+, making the NIS+-in-compatibility-mode server little more secure than atraditional NIS server.

Further, NIS+ has been demonstrated to sufferfrom serious performance degradation and stabilityproblems in very large environments. The authorshave particular experience with these problems, hav-ing been tasked with managing a NIS+-based passwdtable distribution mechanism for a collection ofapproximately 200 Solaris machines for over twoyears. At Duke, NIS+ is in use as a mechanism for dis-tributing passwd table information (but not, as we willdiscuss later, actual authentication information) forsome 37,000 Solaris users, and we have observed anumber of serious problems with this rather largeNIS+ deployment.

While running performance of NIS+ in the pres-ence of no underlying server or network problems hasnot been a significant issue, serious problems havearisen when one or more NIS+ servers have failed.Specifically, it has been our experience that multipleNIS+ servers cannot be expected to function reliablyin failsafe modes. In theory, NIS+ shares the tradi-tional NIS feature of supporting multiple serverswithin a given NIS+ domain, each of which canrespond to service requests from clients in the event ofa failure among the server group. In practice, ourexperience at Duke has been that NIS+ servers fre-quently exhibit failure modes in which, rather than

refusing to respond to RPC requests and triggeringclient fall-back to other servers in the NIS+ domain,they respond incorrectly to RPC requests, resulting inclients receiving incorrect or invalid information. Fur-ther, because NIS+ (unlike NIS) offers no mechanismfor forcing a particular client machine to direct itsSecure RPC calls to a particular NIS+ server, we havefound it to be exceedingly difficult to localize NIS+failures when they occur, and nearly impossible toresolve them in an acceptable timeframe.

NIS+ has also exhibited serious administrativeperformance problems at times when it has been nec-essary to perform significant updates to large NIS+tables. Transferring Duke’s 37,000-entry passwd tablefrom the local NIS+ master server to its slaves acrossa 100-Mbit FDDI ring has been observed to take aslong as 15 minutes. More significantly, regeneratingNIS+ credential information (required by the SecureRPC framework underlying the NIS+ service) for all37,000 system users has been seen to take in excess of12 hours real time on an 85-MHz Sparc5 workstation,during which time no access is available to NIS+objects within the directory tree rooted on the affectedserver. Solutions to these problems recommended bythe vendor have essentially amounted to replacingNIS+ with another service. NIS+, we have been told,was designed to support tables containing up to 10,000objects, and is known to suffer performance degrada-tion when table sizes increase beyond that limit.

These issues have driven us at Duke to worktoward eliminating as many dependencies on NIS+ aspossible, and lead us to recommend against NIS+ asthe basis for a SAR in any heterogeneous or largeenvironment. NIS+ can be used effectively as areplacement for NIS or YP in small, homogeneousenvironments, but does not scale well to large applica-tions and is not appropriate for use in heterogeneouscomputing environments.

RADIUS, etc.: SAR by Proxy

Hesiod, NIS, and NIS+ are all SAR-like servicesbased on the concept of distributing a single databaseof authentication information (usually a Unix-stylepasswd table) to a variety of possibly heterogeneoussystems. Authentication is still achieved, with thesemechanisms, through client-based look-up of authenti-cation information and direct comparison of authenti-cators presented by end-users against those recordedin central authentication databases. While thisapproach has some advantages, among them interoper-ability with a plethora of existing applicationsdesigned around the traditional Unix security model,other approaches to network-distributed authenticationare available.

One such approach, authentication by proxy, isexemplified by the RADIUS (Remote AuthenticationDial In User Service) authentication mechanism. Inthe RADIUS scenario, authentication is achieved byclients passing their users’ authenticators to a central



RADIUS server, which performs table look-ups todetermine their validity, and returns an ‘‘accept’’ or‘‘reject’’ response to the clients depending on theresults of the RADIUS look-up. Client systems neednot have direct access to any secure authenticationtables, since actual authentication operations are per-formed by proxy on the RADIUS server. Rather thandistributing the authentication database to clientmachines, RADIUS and related mechanisms pass indi-vidual users’ authenticator information to a centralserver for validation.

RADIUS has been implemented by a number ofvendors of remote-access hardware (terminal servers,routers and other network devices) as a cost-effectivemechanism for providing user authentication fromwithin embedded applications.

Depending on the specifics of particular imple-mentations, RADIUS can suffer from a variety ofsecurity flaws as a basis for an organizational SAR. Inparticular, although the network path between aRADIUS client and a RADIUS server can be and fre-quently is hardened, the connection between aRADIUS client and its user is often unencrypted. Assuch, widespread use of RADIUS has traditionallybeen confined to applications in which the connectionbetween the authenticating agent and the RADIUSclient can be expected to be invulnerable to passivemonitoring attacks (e.g., dial-up terminal servers).

A mechanism similar to RADIUS has been inuse at Duke University for a number of years in sup-port of authenticating dial-up access to the institution’scampus-wide network. Users make dial-up connec-tions to terminal servers on campus which, in turn,prompt for their authentication information and pass itto a Unix machine implementing a RADIUS-styleauthentication mechanism based on a secure third-party authentication service (Kerberos v4). Dial-upaccess to the terminal servers is either granted orrefused based on the success or failure, respectively,of the Unix machine’s authentication operation. Whilethis poses serious security issues in the Duke environ-ment, traditionally it has been felt that the risk ofauthenticator compromise involved in passing authen-tication information in plain text over a presumablysecure telephone network and across the hardenedEthernet network connecting the terminal servers withthe authentication proxy is more acceptable than therisk of allowing unauthenticated dial-up access to thecampus network.

Because they are widely supported in certainniche-applications (terminal servers, etc.), RADIUSand related authentication proxying mechanisms arelikely to play a role in any large organization’s SAR.We do not, however, recommend that they be viewedas the basis for building a SAR, but rather recommendthat they be used as an adjunct to other, more secureand more widely-applicable SAR solutions.

OTP: The Contrapositive of SAR

Yet another set of network-distributed authenti-cation mechanisms which should be identified, per-haps less as SAR-building platforms than as compet-ing solutions to many of the security problemsaddressed by properly-chosen SAR solutions, is thegroup of so-called OTP or One Time Password sys-tems. Ranging in their implementation from totallysoftware-based approaches (like S/Key) to totallyhardware-based solutions (so-called ‘‘smart cards’’),OTP solutions address the problem of identity prolif-eration in a somewhat radical manner.

Rather than striving to reduce a plethora of sys-tem- and application-specific authenticators issued toeach end-user to a single, highly-secure authenticator,OTP solutions strive to make authenticators secure bychanging them each time they are used. In the typicalOTP scheme, a given user will have as many pass-words (although hopefully not as many login ids) ashe or she has authenticated work sessions. Each time auser ’s password (or, more generally, a user ’s authenti-cation information) is used, it is immediately invali-dated, and new authenticators are issued for the user.

Provided that the mechanism by which newauthenticators are issued to end-users is sufficientlyunpredictable to third parties, such OTP schemes caneliminate the security risks involved in sending plain-text authentication information over an insecure net-work. By the time a nefarious observer becomes awareof the user’s identity and authentication information, itis no longer of any value.

Insofar as most OTP systems rely on some cen-tral authority to manage and coordinate the issuanceand revocation of single-use authenticators, they mayrealistically be viewed as providing a sort of SAR, andto the extent that OTP systems maintain consistencyof user identities (login ids, for example) throughtime, they can form the basis of something very simi-lar to a SAR.

Software-based OTP mechanisms, such asS/Key, typically work by pre-assigning a sequence ofauthenticators to each individual, a list of ‘‘upcoming’’passwords, as it were. Each user must periodicallyquery the S/Key service for a new list of futureauthenticators, and must refer to the list whenever per-forming authentication operations on supported sys-tems. Similarly, all supported systems must be accessi-ble at an administrative level to the S/Key service, sothat authenticators may be invalidated and replaced asthey are used.

Obviously, such list-based OTP solutions canonly be as secure as the mechanisms by which theselists of authenticators are transported. Requesting anew authenticator list over an unsecured networkchannel, printing an authenticator list on an insecureprinter, or storing an unencrypted list of future authen-ticators online or in some other insecure fashionundermines the security of the entire list. So long as



sufficiently secure channels are used to manipulateauthenticator lists, however, list-based OTP mecha-nisms can provide an inexpensive enhancement to theoverall electronic security of an organization.

By contrast, hardware-based OTP solutions (likeSecurity Dynamics’ SecurID product) typically gener-ate new authenticators as they are required, thus elimi-nating the need for persistent lists of single-useauthenticators. In these schemes, each user is issuedan electronic device (typically a roughly credit-card-sized microcomputer) equipped with enough intelli-gence to calculate a complex and unit-specific cipherwhich is in turn used as the owner’s authenticator.Depending on the specific implementation, the ciphermay be a function of the current time (in which casethe user’s ‘‘smart card’’ must have a means for syn-chronizing its clock with the central security system),a function of some random challenge string presentedto the user at the start of an authentication operation(in which case the user’s ‘‘smart card’’ must offersome means for ascertaining the value of the challengestring), or a function of both. Additionally, smart cardsystems may require users to provide the interfacebetween cards and authenticating systems (by manu-ally responding to OTP challenges presented by targetsystems) or may make use of additional hardware todirectly connect authenticating systems to smart cards.

Provided that the cipher calculated by the user’ssmart card is sufficiently secure (that is, provided thatit is both cryptographically secure and sufficiently dif-ficult to reproduce using other hardware) such systemscan offer the same sorts of advantages list-based OTPsolutions like S/Key offer. In addition, hardware-basedsystems offer the advantage of requiring little or nochange in the behavior of end-users; users need notlearn to operate a new software system in order tomanage their authentication information. Rather, theymay simply substitute a password provided on demandby their personal authentication device for a traditionalremembered password.

Hardware-based OTP solutions typically involvemuch higher installation and deployment costs thansoftware-based solutions. Especially in large organiza-tions, the cost of acquiring and issuing thousands ofsmart cards and possibly card reading interfaces maybe prohibitive, and in addition, the long-term cost ofmaintaining and replacing malfunctioning or stolenauthentication devices can be exorbitant. Similarly,although software-based OTP solutions may bedeployed without significant capital outlay, evenwithin large organizations, the cost associated with re-training users and supporting their use of a more com-plicated authentication scheme may be prohibitive.

Unlike distributed database SAR solutions andproxy solutions such as RADIUS, OTP solutions relyon ‘‘something the user has,’’ rather than ‘‘somethingthe user knows’’ to achieve strong user authentication.Depending on the extent to which users protect their

OTP lists or smart cards, such ‘‘bearer bond’’ authen-tication strategies can be either more or less secure,overall, than equivalent password-based systems.Increasingly, OTP mechanisms are being viewed as anadjunct to, rather than a replacement for more tradi-tional password systems. While the cost of deployingan OTP solution ubiquitously across a large organiza-tion may be prohibitive, the cost of deploying such asolution for a few, key users within the organization(presumably those whose level of authorization makesthe strength of their authentication particularly impor-tant) may be less so. In many instances, hardware-based OTP solutions are being deployed in addition totraditional password-based mechanisms in order toachieve an even higher level of certainty in authentica-tion than either mechanism can provide alone.

PKI: SAR Meets Star Wars

Yet another, arguably much more secureapproach to network-distributed authenticationinvolves the use of digital certificates under the aus-pices of a public key infrastructure, or PKI. Althoughit has yet to achieve the status of a true ‘‘standard,’’the most widely-accepted approach to digital certifi-cate/PKI authentication is the proposed X.509 stan-dard.

In this scenario, authentication is achieved bypresenting a digital certificate to the challenging sys-tem or application. This digital certificate is actually astructured block of data identifying the certificate’sowner and typically including the owner’s public keywhich has been digitally signed (using one of a num-ber of related public-key encryption technologies) bythe certificate’s issuer, the user’s certificate authorityor CA. Presented with this digital certificate, a cooper-ating system can verify (by decrypting the certificatewith the CA’s public key) that the certificate is gen-uine (i.e., that it was issued by the certifying author-ity). The CA can frequently be queried to verify that aparticular certificate is valid (i.e., that it has not beenrevoked). Certificate authorities, in this scenario, musteach have their own public key/private key pairs (toeffect signing of the certificates they issue), and mustact as key distribution agents, providing a centralrepository for the retrieval of public key information.Participating systems and applications then ‘‘trust’’particular certificate authorities, accepting valid cer-tificates issued by those CAs, usually on the basis ofthe CA’s being known to use trusted methods to iden-tify individuals before issuing them certificates.

Public key certificates offer a number of advan-tages as an authentication mechanism. Being based onpublic key encryption mechanisms, certificates arehighly cryptographically secure. Forging a public keycertificate without prior knowledge of both a user’sprivate key and his CA’s private key is virtuallyimpossible. Further, certificates offer some of theadvantages of hardware-based OTP systems, in thatauthentication is achieved based on a user’s



possession of something (his or her certificate) ratherthan his knowledge of something (his or her pass-word).

Additionally, digital certificates provide a naturalmeans for engaging in secure communications over apossibly insecure network. Once a user’s public keycertificate has been exchanged and validated as proofof authentication, a shared encryption mechanism isavailable to both the authenticating user and the sys-tem to which he or she is authenticating. The user mayencrypt data in his or her private key (as distributed bythe user’s CA) to ensure the authenticity of transmis-sions (data encrypted in the user’s private key canonly be decrypted using that user’s public key). Partic-ipating systems may encrypt data in the user’s publickey, ensuring that their transmissions can only bedecrypted using the user’s private key.

Public key certificate systems are not, however, aperfect solution to the SAR problem. In order todeploy a SAR based on public key certificates, anorganization must first develop and deploy a rathercomplicated set of support services, a public key man-agement infrastructure, which may include, in additionto one or more local Certificate Authorities, a keyescrow system (for the secure storage and retrieval ofprivate key information) and mechanisms for updat-ing, invalidating, and re-publishing public keys. Secu-rity of the various portions of the public key infras-tructure becomes critical, since compromise or imper-sonation of a part of the public key infrastructure candirectly undermine the security of any authenticationmechanisms designed around it.

In certain environments, it may be feasible torely on an external CA, effectively outsourcing thework involved in setting up and maintaining a publickey infrastructure. In many organizations, however,the need for guaranteed access to the certificateauthority or special requirements for user identity veri-fication and certificate maintenance (frequent certifi-cate revocation, for example) may make an off-siteCA untenable. On the downside, reliance on an orga-nization-specific CA may cause difficulties for userswho interact with systems which do not trust the orga-nizational CA, resulting in individuals having to jug-gle multiple personal certificates (one for use withinthe organization, for example, and one for use outsidethe organization) and undermining the intent of aSAR.

Moreover, few applications and no commonoperating systems are currently built to support PKIcertificates as the basis for user authentication. So-called ‘‘personal certificates’’ are supported by a widerange of web-based applications via the intrinsic sup-port for certificates provided through common webbrowsers (Netscape, Internet Explorer), but non-web-based applications and systems typically offer nomechanism for supporting certificates as an authenti-cation tool. A SAR based entirely on the exchange of

public key certificates in any but the most homoge-neous of organizational environments would requiresignificant re-development of common applicationsand systems.

PKI certificates further pose problems in envi-ronments where users are highly mobile. Because oftheir complexity and size, certificates cannot be feasi-bly memorized or re-entered by their owners, and somust be stored electronically. In non-mobile user envi-ronments, certificates can reasonably be stored onusers’ preferred client machines, where they can bereliably accessed at all times. In more mobile environ-ments, where a single user may work from any of anumber of locations, access to a user’s PKI certificatecan become more complicated. Hardware-based solu-tions, in which certificate information is stored in‘‘token cards’’ carried by users, can make certificateseasily transportable, but are expensive to implementacross large organizations. Software-based solutionsinvolving key and certificate escrow systems canmake certificates network-accessible, but require someform of alternative authentication in order to ensuresecure access to escrowed key/certificate information.These difficulties are specific, of course, to end-userauthentication systems; public key certificates used toauthenticate systems to one another need not be trans-ported from one system to another and so do not sufferfrom these complications.

In spite of these difficulties, it is clear that publickey certificates will play an increasingly importantrole, particularly in the realm of secure electroniccommerce applications. Any SAR or SSO infrastruc-ture developed today will need the ability to use publickey certificates where they are appropriate. However,building a SAR based solely on public key certificatesand a central CA will only be feasible for the shortterm within certain organizational environments. Theauthors believe that the cost of deploying, managingand maintaining a public key infrastructure currentlymakes certificate-based authentication mechanismsunattractive from the point of view of the typical sys-tem administrator.

Kerberos: Established Technology, Secure Authentica-tion

Yet another secure network-based authenticationmechanism, and one which the authors recommend asthe preferred basis for developing SARs within mostorganizations, is Kerberos. Developed at MIT underthe same Athena project which spawned the Hesiodsystem discussed earlier, Kerberos has been in usewithin a large number of organizations for a numberof years. The Kerberos technology, represented byMIT Kerberos versions 4 and 5 as well as by the secu-rity service associated with the Open Group’s DCEinfrastructure, is both widely-understood and reason-ably impervious to common methods of attack.

The impetus for the development of the Kerberosauthentication model was a simple question: how can



users be authenticated to systems across insecure net-works without exposing their authentication informa-tion to would-be attackers monitoring network traffic?Relying in part on previous work by Needham andSchroeder, developers at MIT designed the Kerberosmodel as a means of authenticating clients withoutresort to passing re-usable authentication information(passwords, etc.) over an insecure network.

In the Kerberos approach, clients and servers areloosely grouped together into ‘‘realms,’’ with eachrealm containing at least one shared security server.This security server, called a KDC or Key DistributionCenter, shares a secret encryption key with eachauthenticatable user and with each participating net-work service provider within the realm. These keysare used as shared secrets to effect user authenticationand to issue reusable authentication credentials called‘‘tickets.’’ Users and service providers within a givenrealm trust the realm’s KDC, and in some cases, maytrust foreign KDCs through a chain of trust relation-ships and shared keys between KDCs in multiplerealms.

Kerberos achieves authentication through the useof shared secret keys. The model is based on the sim-ple realization that if two parties wish to verify oneanother ’s identities, they may do so securely byexchanging information strongly encrypted in a sharedsecret key. The party initiating the authentication pro-cess can send a message encrypted in the shared secretkey, and if the responding party is able to properlydecrypt the message, both parties can be reassured ofone another’s identities. Provided that the key is actu-ally a secret shared solely between the two parties, theability to decrypt one another’s messages is sufficientto prove authentication. If part of the encrypted infor-mation passed in the original exchange is furtherencrypted in a secret key known only to the originat-ing party, the originating party can subsequently verifythe origin of the initial message.

In reality, the Kerberos model is made morecomplicated by the need for more than two parties toauthenticate to one another securely in real environ-ments (necessitating the use of persistent ‘‘tickets’’ asrecords of prior authentication), and by the need toaddress certain security vulnerabilities intrinsic to itsuse in insecure network environments (network replayattacks, dictionary-based key-guessing attacks, etc.).

Conceptually, the KDC can be viewed as provid-ing two different but related services: an initial‘‘authentication service’’ or AS, used to perform initialauthentication of users and issue tickets for the ticketgranting service, and a ticket granting service or TGS,used to issue tickets for other participating services. Inmost existing implementations of the Kerberos model,the AS and TGS reside on the same secure host(s), andin most cases the two are implemented using the sameexecutable code.

In the classical Kerberos authentication model,initial authentication involves the acquisition of a‘‘ticket granting ticket’’ or TGT (basically, a ticket forthe ticket granting service) from the KDC’s AS. Thisis accomplished in two steps. In the first step, theclient sends an authentication request to the AS, indi-cating the user for whom a ticket granting ticket issought and providing information (time stamps, etc.)useful for validating the request. The AS respondswith a TGT which is encrypted in the user’s secretkey. The client’s ability to decrypt this TGT is thebasis for the client’s proof of authentication, sinceonly the user and the KDC are presumed to know theuser ’s secret key. Encryption is usually achieved usingthe DES encryption algorithm, but can in theory beachieved using any symmetric-key encryption scheme.

Enclosed in the ticket granting ticket are a num-ber of pieces of information, of which five are particu-larly important: an actual user credential identifyingthe authenticated user (encrypted, itself, in the server’sown secret key, to prevent foreign construction of cre-dentials), a timestamp issued by the KDC identifyingthe time at which the ticket granting ticket was issued,a lifetime value indicating how long the ticket is toremain valid, a checksum useful for ensuring that theticket has not been modified from its original content,and a randomly assigned ‘‘session key’’ for use as ashared secret between the now-authenticated user andthe KDC. If the client is able to decrypt the ticketgranting ticket correctly (i.e., if the resulting ticketcontains a valid checksum) and if the timestamp onthe ticket matches (within a short window) the currentlocal time on the client, the ticket is accepted as valid.If any but the correct key is used to decrypt the ticket,or if the data within the ticket is changed from whatwas originally issued by the KDC, the resultingdecrypted key will not match its checksum and theticket can be identified as invalid. Together, encryp-tion in the user’s secret key and the presence of thechecksum ensure the integrity and confidentiality ofthe TGT.

At no time during the initial ticketing transactiondoes the user’s secret key information pass over thenetwork, and at no time do reusable authenticationcredentials pass over the network unencrypted. Assuch, the initial ticket exchange can in principle beperformed securely over an insecure network.

Once acquired, the user’s ticket granting ticketcan subsequently be used in additional ticketexchanges with the KDC, usually to acquire so-called‘‘service tickets’’ as proof of authentication for usewith services other than the TGS. Subsequent ticketexchanges proceed similarly to the initial ticketexchange, with requests being made to the TGS ratherthan the AS, and with requests specifying a target ser-vice in addition to a target user. Authentication for ser-vice ticket requests may be performed in the same wayas authentication for initial ticket requests is per-formed (using the client’s knowledge of the user’s



secret key to authenticate the user), but more com-monly, a previously-acquired TGT is used as proof ofauthentication. The TGS responds to a service ticketrequest with a service ticket containing informationsimilar to that in the TGT. The response is encryptedin the session key shared between the KDC and theauthenticated user, and contains within it informationencrypted in the secret key shared between the targetservice and the KDC. This service ticket can then beused as part of an authentication transaction with thetarget service, which can ensure that the ticket beingpresented to it is valid based on its being encrypted inthe target server’s secret key (a key known only to thetarget server and the KDC).

Three different implementations of the Kerberosmodel are currently in common use: the ‘‘original’’Kerberos version 4, Kerberos version 5, and the OpenGroup’s DCE security server. All are built atop thegeneral framework outlined above, although each dif-fers from the others in the specifics of the communica-tion protocol used and the details of the contents oftickets. Kerberos version 4 is perhaps the most com-monly-deployed implementation of the model, havingbeen generally available since the mid-1980s. As Ker-beros V4 came to be deployed on larger scales, itbecame apparent that the original implementation suf-fered from some serious security flaws, including aparticular susceptibility to dictionary-based attacks.Kerberos V5 was developed in the early 1990s toaddress these concerns, and to provide some addi-tional features (e.g., better cross-realm authentication,forwardable tickets, and renewable tickets) requiredby new applications of the model. The addition of sup-port for prior encryption of ticket granting requestsand changes in the underlying ticket exchange proto-col make Kerberos V5 less vulnerable to certain com-mon dictionary-based cryptographic attacks. The DCEsecurity service was developed as part of the OpenGroup’s Distributed Computing Environment, a larger(and some have said, too large) project striving to pro-vide an infrastructure for secure, cross-platform dis-tributed computing. Loosely based on an intermediateversion of Kerberos V5 from MIT, the DCE securityservice is conceptually similar to Kerberos V5, butrelies on the DCE ‘‘secure RPC’’ mechanism as theunderlying conduit for ticket exchanges.

Kerberos offers a number of positive features forboth system administrators and end-users as the basisfor an organizational SAR. The Kerberos model pro-vides the advantages of strong authentication based onstrong encryption without the overhead and complica-tions exhibited by current PKI implementations. Inprinciple, only one dedicated network server must beinstalled, secured, and maintained to support a Ker-beros infrastructure, although in practice multiple‘‘clone’’ security servers are usually deployed to pro-vide redundancy and availability. Like PKI/certificatebased authentication mechanisms, Kerberos provides anatural mechanism for ensuring the privacy and

integrity of application-level data exchanges over aninsecure network (via the session keys distributed withKerberos tickets), and provides a mechanism forbipartisan authentication (i.e., the model supports boththe authentication of client users to server systems andthe authentication of server systems to client users).

Kerberos boasts an enormous installed user base,and is one of the most proven network-based authenti-cation schemes available. From the standpoint of thesystems administrator, who may be held ultimatelyresponsible for both the security and availability ofsystems participating in the SAR, this historical trackrecord can be a significant advantage. Kerberos is fur-ther supported by well-established Internet standards,and as such forms the basis for continuing develop-ment efforts world-wide. New implementations of theKerberos model continue to be developed (viz., workat KTH in Sweden and recent work toward both Tcland Java-based implementations of Kerberos V5).Kerberos is already supported as an authenticationmechanism by a number of high-profile applicationvendors (Oracle, SAP), a variety of common openapplication servers (IMAP, POP, ACAP) and is sup-ported natively on a number of operating system plat-forms (AIX, Solaris). Upcoming versions of somevery popular operating systems (Windows NT, NovellNetware) are also expected to include native supportfor Kerberos as an optional authentication method.

Kerberos does suffer from some well-knowndeficiencies, both as an authentication system and asthe basis for an organizational SAR. Kerberos is, at itsbase, a password-based system, and as many havepointed out, it is subject to a variety of password-guessing attacks. Further, the model (particularly inits implementation under Kerberos V4, but to someextent still in Kerberos V5 and the DCE implementa-tion) is subject to certain types of replay attack; adetermined attacker may, under certain circumstances,be able to circumvent the replay protections built intothe Kerberos protocol and for a short time masqueradeas an authenticated user by replaying part of a previ-ous ticket exchange on an insecure network. AsBellovin and Merritt, among others, have pointed out,Kerberos is also subject to environmental attacks.Depending, as it does, on time synchronizationbetween participating clients and servers, Kerberossecurity can be undermined in the presence of insecuretimekeeping mechanisms. Additionally, since Ker-beros session keys may be used to encrypt multiplemessages between a single client and server during thelifetime of a given Kerberos ticket, session keys maybe vulnerable to cryptographic attack by sufficientlydetermined enemies.

Like PKI solutions, the security of a Kerberos-based SAR is wholly dependent on the security (bothlogical and physical) of the systems making up theauthentication infrastructure. The security of the KDCwithin a given realm is as important in the overallsecurity of a Kerberos-based SAR as the security of



any portion (CA, key escrow systems) of a shared PKinfrastructure. The authors believe that, because of itsrelative simplicity and wide availability, a KerberosSAR can be more easily (and thus, more probably)secured against infrastructural attack than a more com-plex, less widely-implemented certificate-based SAR.As certificate-based systems come of age, however,systems administrators may find that PKI-based SARsolutions gain ground in this respect.

Like the PKI/certificate approach, the Kerberosapproach to building a SAR is not without develop-ment costs. Applications must be designed or modi-fied to support Kerberos (must be ‘‘Kerberized’’) inorder to participate in a Kerberos-based SAR, andalthough a number of applications and operating sys-tems already provide some measure of Kerberos sup-port, many do not. Depending on an organization’sinstalled base and usage patterns, adoption of a Ker-beros-based SAR may require significantly more orsignificantly less retrofitting of existing applicationsand systems than a PKI-based SAR.

Experience at Duke, where Kerberos has been inuse for a number of years in a SAR supporting a vari-ety of public computing labs on campus, has shownthat Kerberizing applications whose intrinsic authenti-cation models are relatively modular, while not trivial,is relatively straightforward. The published KerberosAPI, with its support for RFC 1510’s GSS-API stan-dard, makes Kerberizing most applications a matter ofadding on the order of ten or twenty lines of C toserver and client code. Kerberos extensions developedat Duke (including the Exu system co-developed byone of the authors) have simplified the integration ofKerberos authentication into a variety of systems-related tasks. It should be noted, of course, that notevery application or system can be modified at everysite. In the case of proprietary software and systems,the system administrator must frequently rely on coop-eration from one or more vendors in order to imple-ment support for a Kerberos- or PKI-based SAR. AtDuke, the authors have been fortunate in havingaccess to source code for some proprietary systems,and in having the support of upper management in theuse of free and open software wherever possible.

Likewise, experience at Duke has shown theKerberos model to be extremely scalable, supportingvery large numbers of authenticatable entities (termed‘‘principals’’) with little or no measurable degradationin performance or stability. Currently, the‘‘ACPUB.DUKE.EDU’’ Kerberos realm supports inexcess of 37,000 users and provides secure, authenti-cated access to a range of applications from electronicmail to dial-up networking across a variety of comput-ing platforms, from Macintoshes to Unix-based file-servers. This is not to say that there are not costswhich increase as the user-base for a SAR grows (cer-tainly, end-user support costs can increase dramati-cally) but rather that the administration of a Kerberosinfrastructure supporting tens of thousands of users is

not significantly more complex or time-consumingthan the administration of a similar infrastructure sup-porting only hundreds of users.

Many of the security vulnerabilities in Kerberosare addressed to varying extent in recent implementa-tions of the authentication model; Kerberos V5 is sig-nificantly stronger as an authentication mechanismthan Kerberos V4, and the DCE implementation ofKerberos offers even greater protections against cer-tain forms of attack by modifying the ticket exchangeprotocol in some significant (if incompatible) ways.Kerberos implementations continue to evolve, withMIT and others investigating extensions to the Ker-beros protocol to support more cryptographicallysecure authentication mechanisms and to integratesupport for newer authentication approaches (includ-ing digital certificates and PKI-based authentication).

The authors believe that, for most organizations,a Kerberos-based SAR can provide more than ade-quate security with greater confidence and less admin-istrative overhead than other SAR mechanisms. WhilePKI-based authentication mechanisms may offeradvantages in the realm of electronic commerce,where users may not be known by the organizationsthey interact with until the need for authenticationarises, they do not yet offer the proven reliability northe existing installed base of standard implementationsKerberos boasts.

SSO Alternatives: The Dream of a Single Sign-On

Many of the SAR solutions discussed abovemight reasonably be viewed as also providing the ben-efits of a full SSO solution. In the Kerberos model, forexample, a single authentication to the SAR acquiresthe client reusable credentials sufficient to authenticateto any Kerberized application without re-enteringauthenticator information. Likewise, in the PKImodel, possession of a personal PK certificate mayallow a user to freely authenticate to a variety of sup-ported applications without re-entering passwords orother authentication information.

Nevertheless, in all but the most restricted ofenvironments, it is unrealistic to expect that a SARcan provide a complete SSO solution for an organiza-tion. In the face of a heterogeneous computing envi-ronment comprising many different systems and appli-cations, it is unlikely that a SAR can support the needsof the entire organization. Further, while a SAR mayprovide a basic level of SSO functionality (oneauthentication operation per user per work-session), itcannot usually provide the look-and-feel featuresdemanded by many users. Systems administratorsmay find that providing a mechanism whereby usersneed only authenticate themselves once per work ses-sion is not enough to satisfy their user populations;users may demand not only strict SSO functionalitybut also a simplified authentication interface commonto multiple environments.



Hence, system administrators charged withdesigning and building SSO infrastructures must fre-quently look beyond SAR options and investigate trueSSO approaches. Common SSO approaches fall intothree main categories: those which rely on an underly-ing SAR to facilitate authentication into multiple ser-vices at login-time, and those which rely on some cen-tralized authenticator repository (a ‘‘key box’’) to pro-vide multiple applications and systems with the ‘‘illu-sion’’ of a shared, single sign on, and hybrid solutionsincorporating features of both the SAR-based and keybox-based solutions.

Entry-Point Authentication: Pay No Attention tothe Man Behind the CurtainOne common approach to providing SSO func-

tionality involves the modification of common entry-point applications (login programs, etc.) to performmultiple authentication operations each time a userinitiates a work session. In this approach, a number ofdifferent systems and applications sharing user infor-mation through some sort of SAR pass authenticationinformation between one another in order to effect theappearance of a single sign-on solution.

Typical examples of this methodology includethe Windows NT ‘‘layered GINA replacement’’ mech-anism and the Kerberized Unix login mechanism.

The Windows NT user authentication mechanism(GINA) is designed in such a way that multiple differ-ent authentication modules can be invoked in succes-sion when a user logs into an NT machine. Providedthat a single common login and password are suffi-cient to authenticate a user to, for example, both anNT domain and a Novell NDS tree, layered GINAmodules can be used to provide a sort of single sign-on appearance to the end-user.

Similarly, the MIT Kerberos distributionincludes standard replacements for the normal Unix‘‘login’’ program which, rather than checking user’sidentities against a local or distributed Unix passwdtable, perform Kerberos authentication using the loginand password supplied by the user. In essence, theKerberized Unix login replacement is a sort of SSOmechanism, presenting an SSO interface for authenti-cating to both a Kerberos realm and an individualUnix machine.

Certainly, these methods have a place in organi-zational SSO planning. In order to implement a Ker-beros-based SAR, for example, in a fashion palatableto general users, Kerberized entry-point applications(login programs, etc.) must be made available acrossas many platforms as possible. These sorts ofapproaches offer little beyond what can be achievedthrough a SAR alone, however, and do nothing toachieve a unified look-and-feel across applications orsystems.

More importantly, these solutions still rely onunderlying application- and system-level support for

some form of SAR, and in all but the least compli-cated situations, require significant re-engineering ofentry-point code on multiple systems. Clearly, whilethe entry-point approach to single sign-on is of inter-est, it is not a comprehensive solution to the demandfor SSO functionality.

The Key Box: SSO in a Fire SafeAnother common approach to the SSO problem,

and one which seems to have been en vogue amongvendors in recent years, is the ‘‘key box’’ mechanism.A central authenticator repository is established con-taining each user’s various application- and system-specific authenticators (login/password pairs, certifi-cates, etc.). Rather than the user authenticating to indi-vidual applications and systems directly, the userauthenticates once to the central SSO server, which inturn sends the necessary authenticator information tohis or her client machine to allow an SSO client appli-cation to authenticate to other systems and applica-tions on the user’s behalf. Typically, the SSO clientapplication populates the user’s graphical desktop withicons (or otherwise makes available a list of exe-cutable links) for each of the systems the user has SSOaccess to. Launching one of the ‘‘virtual’’ applicationsset up by the SSO client causes the appropriate appli-cation to be started and automatically authenticates theuser to the application using whatever authenticatorinformation was provided by the SSO server. In effect,the SSO client provides the user with the appearanceof a single sign-on by performing authentication oper-ations on the user’s behalf.

Unlike the entry-point authentication approach,the key box approach doesn’t require the prior exis-tence of a SAR. Because the SSO server can storemultiple different authenticators for a single user (onefor each different system and application the user isauthorized to access), there is no need for a SAR assuch. Multiple authentication operations are per-formed during each work session, but they may beperformed entirely without the user’s knowledge.

While key box approaches to the SSO problemcan provide a high level of functionality for end users,they can also pose some difficult challenges for sys-tem administrators, both in the realm of providing ade-quate security and in the realm of managing users’authentication information.

Clearly, the security the key box or SSO serversystem is of primary importance, since compromise ofthat system would lead directly to compromise of allsystems and applications participating in the SSOsolution. Further, ensuring the security of communica-tions between the SSO server and its clients is ofparamount importance. Depending on the specificimplementation, users’ authenticators may be repeat-edly exposed to passive network attacks as they aretransferred from the SSO server system to variousclient machines. Since the SSO client must typicallystore reusable authenticators for its users locally in



order to provide the appearance of a single sign-onenvironment, SSO clients must themselves be secure,lest client-based attacks permit the compromise of allof a particular user’s authenticators.

Additionally, SSO clients must be specificallydesigned to interoperate with target applications andsystems. In order for an SSO client to perform authen-tication on behalf of the user, it not only must haveaccess to the user’s authenticators via the SSO server,but also must have special knowledge of the nativeauthentication interfaces used by each SSO-supportedapplication. As applications and systems change, SSOclients may need to be modified or replaced in order tosupport new authentication interfaces.

Likewise, key box-based SSO solutions intro-duce special problems for user and authenticator man-agement. While the key box-based SSO approach cansimplify authentication for the end user, it does not byitself address the system administrator’s need toreduce the number of individual authenticators whichmust be validated, issued, and maintained for eachuser. Further, the SSO software must provide somemechanism for maintaining (adding, removing, andupdating) authenticators stored in the central SSOrepository, and should ideally provide some mecha-nism for ensuring that the authenticators housed in thecentral SSO repository are kept synchronized withapplication- and system-specific authentication infor-mation. In some implementations, end-users may notbe privy to their own authenticator information; loginids and passwords, for example, may be chosen andmaintained by the SSO server. While this can simplifythe management of a large set of users or participatingsystems, it can lead to serious problems if user’sclients are not carefully managed. If a user’s clientloses the ability to interact properly with the SSOserver and becomes unable to retrieve authenticatorsfrom the server, the user has no means of authenticat-ing to other systems. In many cases, the benefits ofcentral user management afforded by such SSO sys-tems can be completely eroded by the associatedincrease in system management effort needed toensure proper configuration of client systems.

GSO: IBM’s Lock Box Solution

IBM’s Global Sign-On (GSO) product is a typi-cal implementation of the key box approach to SSO.In the GSO implementation, users’ authenticationinformation is warehoused on one or more centralGSO servers, which also provide DCE-based authenti-cation services. Users install GSO clients on theirworkstations which: manage the initial authenticationoperations necessary to access the GSO server, presenta virtual desktop prepopulated with icons for all theapplications for which the GSO server holds the user’sauthenticators, and transparently perform authentica-tion on behalf of the user for each supported applica-tion when it is invoked. Once a user has started theGSO client and authenticated to the GSO server, the

user need not perform any further authentication oper-ations to access supported applications. Further, theGSO server provides built-in mechanisms for auto-matically responding to password aging as well as auser interface for changing passwords on supportedsystems. Recently, IBM has begun marketing the GSOproduct in conjunction with Tivoli remote systemmanagement products in an effort to provide a com-prehensive user management/SSO solution.

The IBM GSO product is exemplary among itscompetitors in its attention to security and its integra-tion with a remote management facility (Tivoli). Byrelying on DCE for its primary user authentication, theGSO product can provide some of the advantages of astrong SAR in addition to providing the advantages ofa targeted SSO solution. One of the strengths of DCE(and its underlying Kerberos structure) as a method ofprimary authentication is the natural way it providesfor session-level encryption of data flowing over anetwork. IBM’s GSO takes advantage of this strengthto provide a fair level of security in the transmissionof sensitive data (logins, passwords, etc.) between theGSO server and its clients.

By integrating the product with Tivoli, IBM cir-cumvents two of the most difficult administrativeproblems associated with the use of targeted SSOsolutions: the distribution and maintenance of SSOclient software across an organization and the creationand management of system- and application-specificauthentication identities across distributed systems.The inner workings of Tivoli’s TME-10 product arebeyond the scope of this paper, but in brief, Tivolibrings to the GSO product a mechanism for central-ized installation and upgrade of GSO client softwareacross a large organization, and provides a mechanismfor creating and registering with the GSO server newuser identities across a range of systems.

Similar solutions (differing mostly in the meth-ods used to authenticate users to the central key boxserver and the mechanisms by which application-spe-cific authentication operations are proxied by the SSOclient) are offered by other vendors, including Plat-inum Technologies (in a product called PlatinumAutoSecure) and CoreChange (a vendor specializingin SSO solutions for the health-care industry).

Hybrid Solutions: Best of Both Worlds

SSO solutions share a primary goal: simplifyingauthentication operations for the end-user. Issues ofactual security and manageability are frequently ofsecondary importance in the design of packaged SSOsolutions. At times, the system administrator is con-fronted with an apparent trade-off between addressingthe demands of end users through an SSO solution, onthe one hand, and managing and securing systems ade-quately through a SAR, on the other.

The authors believe that a hybrid approach to theSSO problem is often the system administrator’s best



option. Such a hybrid approach would rely on astrongly-secure SAR solution to provide the appear-ance of a single sign-on for the most critical systemsand applications within an organization and wouldalso rely on a possibly-integrated SSO solution to sup-port those systems which cannot feasibly be integratedinto a SAR and to provide end-users with the look-and-feel features they want. By building a key boxSSO solution on top of a secure SAR mechanism(such as Kerberos), the system administrator can oftenaddress organizational security and managementrequirements as well as end user ease-of-operationrequirements with a single comprehensive solution.

SnareWorks: Hybrid Key Box and SAR

One such product, which the authors have rec-ommended for use at Duke, is the SnareWorks productavailable from IntelliSoft, Inc. The SnareWorks solu-tion sits atop a minimal DCE infrastructure (to providesecurity and authentication services), and providesboth end-to-end encryption of network traffic andauthentication/single sign-on services to supportedapplications.

In the SnareWorks approach, network servers areequipped with a SnareWorks server application whichtakes control of incoming network connections on theserver. Likewise, network clients are equipped with a‘‘thin’’ SnareWorks client application which takescontrol of outgoing network connections on the client.A centrally-managed SnareWorks ‘‘master server’’manages information about the security, authentica-tion, and single sign-on requirements of individualservers and clients, and provides for rather fine-grained definition of security rules. A particular IPport on a particular server can be configured, forexample, to require authentication before acceptingincoming connections, and to perform different levelsof encryption at different times of day, when talking todifferent client machines, and when manipulating con-nections authenticated as different users.

When a ‘‘snared’’ client machine connects to a‘‘snared’’ server, the SnareWorks software on the twoparticipating machines negotiates the levels of securityto be provided for the new connection: whether to per-form network-level encryption, and if so, using whatkeys and what encryption mechanisms, whether torequire authentication before establishing the connec-tion, and what, if any, ‘‘single sign-on’’ services toprovide over the connection. If the machines agreethat authentication is required, the SnareWorks clientchecks to determine whether authentication credentialshave already been obtained from the associated DCEcell, and if they have not, automatically prompts itsuser for authenticators with which to acquire creden-tials. If credentials are already cached within theSnareWorks client, the client engages in a normalDCE/Kerberos authentication interchange with theserver to prove its identity. Depending on the configu-ration of the SnareWorks client and server in question,

unauthenticated connections may be refused, or maybe treated differently from authenticated connections.

SnareWorks provides single sign-on featuresthrough a secure key box mechanism based on thenecessarily-present DCE registry. Using extended reg-istry attributes, the SnareWorks software storesauthenticator information for various users on varioussystems and applications in the DCE cell’s central reg-istry. On snared servers for which single sign-on sup-port is available, small loadable modules (termed‘‘Program Support Modules’’ or PSMs) are installedwhich encapsulate the information necessary for theSnareWorks server to perform application- or system-level authentication on behalf of pre-authenticatedusers. Single sign-on is effected through the PSMwhen the appropriate SnareWorks server retrieves (viaa DCE Secure RPC channel) authenticator informationfor an already-authenticated user and intercepts theauthentication transaction on the server. In essence,the PSM running on the server plays the role of theclient, providing a single sign-on appearance withoutrequiring any interaction on the part of the client.SnareWorks clients provide a straightforward userinterface for creating and modifying user-specific sin-gle sign-on information in an associated DCE registry,and SnareWorks PSMs provide support for server-driven authenticator management (single sign-oninformation updates resulting from authenticator orpassword expiration, for example). SnareWorks comespre-packaged with PSMs for a number of commonnetwork-based applications and protocols (telnet,rlogin, ftp, LDAP, X11, Oracle-8, etc.) and offers arelatively simple API for constructing PSMs to sup-port single sign-on features for more exotic or site-specific applications.

With the addition of a SnareWorks Web serverinterface, the SnareWorks software can be used to pro-vide secure authentication for and highly-configurablecontrol over web-based CGI applications running onstandard HTTP servers. Unlike other SnareWorksproducts, the SnareWorks Web server can providethese features to end-users running on clients whichdo not themselves have SnareWorks client softwareinstalled – the SnareWorks Web interface onlyrequires the existence of a web browser on clientmachines. With the addition of an optional Snare-Works CA, the software can be made to interoperatewith certificate-based authentication and authorizationstrategies and can be made a part of an organizationalPKI.

The SnareWorks approach offers a number ofadvantages both as a network security mechanism andas a single sign-on solution. Based on a secure strongauthentication mechanism (DCE), SnareWorks canprovide all of the features of a secure SAR for applica-tions which have native support for Kerberos or DCEauthentication. Further, SnareWorks provides a flexi-ble, configurable mechanism for enforcing encryptionof application data flowing over a possibly-insecure



network. SnareWorks also provides a scalable andretargetable mechanism for providing a single sign-onpresentation to end-users, all without requiring modifi-cation of any application client or application servercode. Security management is centralized through asimplified administrative user interface, allowingsecurity rules to be changed in one location and propa-gated to snared servers throughout an organization.Likewise, management of the authentication informa-tion stored on an associated DCE cell is simplifiedthrough the SnareWorks administration interfacewhich can, if so desired, be configured to provide forautomatic registration of users within a DCE cell.

The approach does have some shortcomings,however. Currently, IntelliSoft offers client support forSolaris, AIX, and HP/UX workstations and MicrosoftWindows 95 and Windows NT client machines.Solaris, AIX, HP/UX, and Windows NT servers arealso supported. Other platforms (including Apple’sMacIntosh) are not supported natively, although cer-tain features can be presented to unsupported clientsthrough the SnareWorks web interface. Additionally,although source code to all of IntelliSoft’s PSMs isavailable, the solution is a proprietary vended applica-tion; sites intent on having source code availablelocally for all critical software may find it difficult tojustify this approach.

The Duke Authentication Project: A Short CaseStudy

As mentioned above, Duke University is cur-rently involved in a major project to provide institu-tion-wide authentication, security, and single sign-onservices. The project was originally conceived bysenior management within the University’s Office ofInformation Technology as a means of simplifying useof certain newly-deployed enterprise-wide applica-tions (e.g., SAP/R3, PeopleSoft, Lotus Notes). Ini-tially, the project was directed at finding an SSO-onlysolution (with or without implementing a SAR) whichwould allow users to authenticate only once per worksession, regardless of the applications they might beusing.

A review committee was formed, with theauthors as co-chairs and comprising representativesfrom major computing organizations on campusinvolved in enterprise-wide applications deployment,and tasked with investigating available technologiesand returning an implementation proposal. Originally,this process was expected to take only two or threemonths, and result in a plan which could be imple-mented in roughly the same timeframe. After someinitial discussions within the committee, it becameclear that the process would be more involved thanhad previously been expected.

As the committee process unfolded, it becameclear that different constituencies within the organiza-tion had different priorities and different requirements

for an ‘‘acceptable’’ solution. Those of us involved insystem administration were primarily concerned withensuring the security of the authentication service andthose applications and systems it supports. Thoseinvolved in application programming were concernedwith reducing the impact of any new infrastructure onexisting applications and systems. End-user supportstaff were primarily concerned with ease of use issues,while management was primarily concerned with find-ing a cost-effective solution.

Starting from these different points of view, thecommittee were able to arrive at a number of site-spe-cific requirements for an acceptable solution. Amongthese were:

• The absence of a ‘‘flag day’’ visible to end-users. Whatever solutions might be deployed,they should be deployed with a minimum ofdisruption to existing end-user work-flow pat-terns, and should be introduced into the existingenvironment in a stepwise fashion, allowingusers to adjust gracefully to changing usagepatterns.

• Compatibility with existing infrastructures. Atthe start of the investigation, Duke already hada large investment in Kerberos technology, hav-ing operated for a number of years a centralUnix computing facility using Kerberos version4 to support in excess of 35,000 users. Further,a number of applications were already in useacross the enterprise, and would need to be sup-ported by any successful SSO solution.

• The absence of any recertification of users. TheUniversity had, at the inception of this investi-gation, already performed significant identityverification for well-over 35,000 of its con-stituents in order to issue them Kerberosauthenticators. The cost of this verification(which had originally been performed over aperiod of many years) was significant, and thecommittee as a whole agreed that any solutionwhich would require the recertification of exist-ing users (i.e., which would require issuing newauthenticators to individuals already in posses-sion of Kerberos principals and passwords)would be less than optimal.

After three months of discussion regarding thefunctional requirements of each constituency for aninstitutional authentication/single sign-on project, thecommittee began the process of reviewing possiblesolutions. The group reviewed self-maintained solu-tions incorporating MIT’s Kerberos version 5 and var-ious available PKI components, as well as vendedsolutions from IBM, Platinum, CyberSafe, Tivoli, andTransarc/IntelliSoft. Some solutions were eliminatedfrom consideration on the basis of their not meetingthe committee’s requirements for scalability or sup-portability (CyberSafe, Platinum AutoSecure). Othersolutions were eliminated on the basis of their not pro-viding the security enhancements desired in



conjunction with deploying an enterprise-wide singlesign-on solution (IBM GSO, Tivoli User Manage-ment). Ultimately, the committee agreed to recom-mend a solution based on IntelliSoft’s SnareWorkssoftware.

At the time of this writing, the institutional singlesign-on project at Duke is completing the final stagesof the organizational funding review. Once a fundingmodel is established for the project, work can begin inearnest on the wide deployment of authentication,security, and single sign-on features called for in thecommittee’s recommendations at the institution.

Conclusions: Learning From Duke’s Experience SoFar

Clearly, implementing SSO for any but thesmallest and most homogeneous of enterprises is ahighly organization-specific task, and certainly no onecan provide a true ‘‘cook book’’ for arriving at anagreeable and functional solution for use in all envi-ronments. Nevertheless, the authors are convinced thatas organizational computing infrastructures becomeincreasingly complex and users become more dissatis-fied with the ease of use problems associated with het-erogeneous computing environments, system adminis-trators will increasingly be called upon to provide‘‘single sign-on’’ solutions for their organizations. Ifthe question hasn’t been asked yet, rest assured that itwill.

While no single set of rules can guide the admin-istrator in designing a single sign-on solution for aparticular organization, a few guidelines may be ofassistance in the decision-making process:

• Any complete SSO solution must embrace notonly critical applications, but also the operatingsystems they depend upon, the network ser-vices they rely on (ftp, electronic mail, etc.),and the underlying data services (HTTP ser-vices, database management services, etc.)required by applications. An SSO solutionwhich supports only a handful of critical appli-cations but does not encompass the underlyingservices those applications rely upon will beincomplete at best, and may well fail to servethe needs of end-users, not to mention therequirements of system administrators.

• In designing an SSO solution, weigh not onlythe cost of deploying SSO-related software andhardware, but also the cost of supporting theenvisioned authentication and/or SSO infras-tructure. Pay special attention to the ‘‘hidden’’costs of re-engineering applications and operat-ing systems to support any chosen SAR or SSOsolution, and to the possibly-enormous costsassociated with verifying user identities and(re)issuing authenticators to end-users. Fre-quently, these costs will far exceed the initialcapital costs of deploying an SSO solution foran organization.

• Keep in mind any security policies already inplace within the organization, and those whichmay be mandated by any given SSO solution.Duke, in particular, has suffered from a dearthof strong security policies, so enabling enforce-ment of stronger security policies was a signifi-cant factor in our investigations. Sites withestablished policies should take care to reviewthe effects an SSO solution may have on theenforcement of existing policies before makingany sort of SSO deployment decision.

• Decide initially which of the possible key fea-tures are of the greatest importance to the orga-nization. We recommend consultation with bothend-users and management to investigate therelative importance of four key features to theorganization:

• Reduced authenticators/sign-ons. If theprimary goal within the organization isto eliminate the proliferation of authenti-cator information for end-users, a classi-cal, vended SSO solution may be ade-quate. If the primary goal is to eliminatethe proliferation of authenticators fromthe point of view of the system adminis-trator, a SAR may suffice.

• Site policy control. If the primary goalwithin the organization is to achievetighter control over the enforcement ofsite security policies, a SAR may be thebest solution, possibly with a vended‘‘key box’’-style SSO solution.

• Security enhancement. If the primarygoal within the organization is to tightensecurity for specific applications andsystems, a SAR approach using one ofthe more secure mechanisms discussedabove may be ideal. In the case of DukeUniversity, the additional securityenhancements provided by SnareWorks’network encryption facilities were a sig-nificant factor in the choice of Intel-liSoft’s products. If security enhance-ment is of little or no concern, classicalSSO solutions (such as IBM’s GSO)may be most appropriate.

• End-user convenience. If the primarygoal within the organization is simplify-ing authentication interfaces presented toend-users, a targeted SSO solution, mostlikely without the deployment of a net-work-based SAR, may be the mostappropriate solution. In these environ-ments, organizations should consider thepossibility of employing a ‘‘niche’’ SSOsolution (CoreChange, for example,offers an SSO solution specifically tar-geted at the health-care market); suchtightly-focused solutions can usually



provide end-users with features notavailable in more generic SSO solutions,but are frequently not applicable to thewide range of applications and systemsfor which large, unfocused organizationsmay need support.

• Plan from the outset for a much larger systemthan can possibly be envisioned. When the SSOproject at Duke was first discussed, it wasviewed as a relatively simple project supportinga few thousand users and a handful of mostlyadministrative systems. In the process of flesh-ing-out the details of various constituents’needs, we on the Duke project committee foundthat what was actually needed was an institu-tion-wide infrastructure capable of supportingthe 40,000+ current organizational affiliates,and capable of expanding to support a growingpopulation of ‘‘new’’ affiliates associated withthe University’s ever-growing Duke HealthSystems initiative. Building a system to be scal-able can be difficult, but redressing a too-smallsolution once it has been deployed can benearly impossible.

• Take advantage of any tools and resourcesalready in place within the organization. AtDuke, the prior existence of a large Kerberosversion 4 realm has provided the institutionwith a ‘‘leg up’’ in developing an institutionalSAR. While the decision to retain compatibilitywith the existing Kerberos version 4 realm didlimit our choices with respect to SAR- andSSO-building products, it has enabled the insti-tution to consider implementing an organiza-tion-wide solution without the initial costs asso-ciated with re-verifying 35,000 users’ individ-ual identities.

• Set reasonable, attainable goals for the SSOsolution. Initial discussions at Duke centered onfinding an SSO solution which would solveauthentication and single sign-on problems forevery application and environment in use at theinstitution: a full-scale single sign-on approach.Later, we came to realize that the goal of elimi-nating all user identity proliferation was tooambitious, and we have instead opted for devel-oping a ‘‘reduced sign-on’’ solution. This hasallowed us to provide for a higher level of func-tionality for those applications and systemsmost critical to the organization, at the expenseof not supporting some less-critical applicationsand guaranteeing that some users of legacyapplications will own multiple authenticators.

• Avoid implementation plans that introduce‘‘flag days’’ for end-users. This is a lesson theauthors learned in managing the growth andreorganization of institutional electronic mailinfrastructures at Duke, and which applies atleast as well to the deployment of SSO

solutions within organizations. Flag days areextremely expensive in terms of goodwill capi-tal with end-users, and in the case of SSO solu-tions, are likely to result in the sorts of unrecov-erable failures which can require an entire orga-nization to be recertified. A gradual, incremen-tal approach to deploying an SSO solution canprevent organization-wide catastrophes in theevent that unforeseen problems arise in thedeployment of an enterprise-wide authentica-tion mechanism.

A Note on Committee Dynamics: Staying Sane in aPolitical Minefield

If one factor can be expected to appear ubiqui-tously in the quest for organizational SAR and SSOsolutions, it is politics. Having worked within theDuke computing infrastructure for a combined total ofover 17 years, the authors expected political factors tointerfere with the progress of Duke’s institutional SSOproject, yet even we were somewhat surprised at theextent to which the ‘‘SSO issue’’ was cause for politi-cal intrigue. Here are a few tips derived from ourexperience with the Duke SSO review committee:

• Take the time to involve a diverse cross-sectionof the community throughout the decision-mak-ing process.This was perhaps the most difficult and themost useful approach we used. We were fortu-nate at Duke, in that the request for a ‘‘singlesign-on solution’’ came from relatively high onthe corporate ladder (the Office of the Associ-ate CIO). This facilitated our enlisting othercomputing professionals from within the cen-tral computing support groups at the University,as well as end-users, administrators, and man-agers from various departments around campusin our work. Although the diversity of the com-mittee made our initial work slow (some mem-bers of the committee started with virtually nounderstanding of the issues involved), it paidoff in the end with a broad base of support forthe project, once it was fully described.

• Take the time to address first principles, andfind common goals across the participants.In our case, this was a significant challenge. Inparticular, the authors found that with theexception of a few extremely technical staff vir-tually no one on the SSO review committeecame into the process with a clear understand-ing of what ‘‘SSO’’ really meant. Many hoursof meetings were necessary just to clarify thedistinction between authentication and autho-rization for the committee (most membersfailed to see the distinction at first), and manymore hours were necessary to work through thetrade-offs between ease-of-use factors (of criti-cal importance to end-users and managers) andsecurity factors (of critical importance to



system administrators and programmers). Inthe end, more than half of the time spent incommittee was spent discussing ‘‘first princi-ples.’’ Once these issues were agreed upon,however, vendor reviews and the choice of anapproach were comparatively simple.

• Expect the process to take some time.At Duke, our original mandate was to completethe review of available options and return to thesenior administration a proposal within threemonths. At the three-month mark, our commit-tee had barely achieved agreement on thenature of the problem at hand, let alone selecteda particular solution. The unfortunate absenceof the authors’ departmental director as a resultof an extended illness allowed us to petition theadministration for additional time. However,pressure mounted as scheduling of vendor pre-sentations and meetings with the review com-mittee and key managers outside the institu-tional computing infrastructure forced the pro-ject schedule to slip further and further.

• Expect the process to be expensive. Warn yourmanagement early.No matter what path an organization takesthrough the SAR/SSO obstacle course, beassured that the result will be more expensivethan originally expected. If the solution(s) cho-sen are proprietary in nature, much of theexpense may be in software licensing andacquisition. If the solution(s) chosen are‘‘free,’’ the costs may be weighted toward stafftime for development and installation. Regard-less, we urge system administrators working onSSO solutions for their organizations to be openand up-front with management about the realcosts involved. At Duke, we expect the initialyear of development and deployment to cost inthe neighborhood of $1 million, with continu-ing costs between $100,000 and $200,000 peryear. Original estimates of the total cost for aninstitutional SSO project were significantlylower, although compared to the costs of someof the major efforts ongoing at the institution(some of which will run into the tens of mil-lions of dollars), the expense is less staggering.Note that Duke is a large and diverse enterprise,with more than 40,000 individual users. Yourmileage may vary.

Software Availability

See Table 4 for URL references for software dis-cussed in this paper.

Author Information

Michael Fleming Grubb has worked as a Unixsystem administrator at Duke University for six years.He is the principal architect of the campus-wide emailand web infrastructure. He is also a licensed attorney.

He can be reached via post at Box 90132, Duke Uni-versity, Durham, NC 27708-0132, USA, or via emailat <[email protected]>.

Rob Carter has worked as a Unix system admin-istrator at Duke University for over eleven years. Hehas been the lead system administrator for the Univer-sity’s public Unix computing facilities throughouttheir existence, although he did not invent Unix. Hecan be reached via post at Box 90132, Duke Univer-sity, Durham, NC 27708-0132, USA, or via email at<[email protected]>.

References

Bellovin, S., and M. Merritt. ‘‘Limitations of the Ker-beros Authentication System.’’ ACM ComputerCommunications Review, October 1990.

Dyer, S. ‘‘The Hesiod Name Server.’’ USENIX Con-ference Proceedings, Winter 1988.

Fraser, B., ed. RFC 2196: Site Security Handbook,1997.

Haller, N. and R. Atkinson. RFC 1704: On InternetAuthentication, 1994.

Haller, N., ‘‘The S/Key One-time Password System.’’Proceedings of the Symposium on Network &Distributed Systems Security, Internet Society,San Diego, CA, February 1994.

Haller, N., C. Metz, P. Nesser, and M. Straw. RFC2289: A One-Time Password System, 1998.

Hess, D., D. Safford, and U. Pooch. ‘‘A Unix NetworkProtocol Security Study: Network InformationService,’’ ACM Computer CommunicationsReview 22 (5), 1992.

Kaufman, C., R. Perlman, and M. Speciner. NetworkSecurity: Private Communication in a PublicWorld. Prentice Hall, 1995.

Kohl, J., and C. Neuman. RFC 1510: The KerberosNetwork Authentication Service (V5), 1993.

Linn, J. RFC 1964: The Kerberos Version 5 GSS-APIMechanism, 1996.

Linn, J. RFC 2078: General Security Service Applica-tion Program Interface, Version 2, 1997.

Mockapetris, P. RFC 1034: Domain Names – Con-cepts and Facilities, 1987.

Mockapetris, P. RFC 1035: Domain Names – Imple-mentation and Specification, 1987.

Mullan, S. OSF RFC 92.0: DCE Interoperability withKerberos, 1996.

Pato, J. OSF RFC 6.0: A Generic Interface forExtended Registry Attributes, 1992.

Ramm, K. and M. Grubb. ‘‘Exu – A System forSecure Delegation of Authority on an InsecureNetwork.’’ Proceedings of the Ninth SystemsAdministration Conference (LISA IX), Monterey,CA, September 1995.

Ramsey, R. All About Administering NIS+. SunSoftPress, 1994.

Rigney, C., A. Rubens, W. Simpson, and S. Willens.



RFC 2138: Remote Authentication Dial In UserService (RADIUS), 1997.

Steiner, J., C. Neuman, and J. Schiller. ‘‘Kerberos: AnAuthentication Service for Open Network Sys-tems.’’ USENIX Conference Proceedings, Winter1988.

Stern, Hal. Managing NFS and NIS. O’Reilly &Assocs., 1991.

Wray, J. OSF RFC 5.2: GSS-API Extensions for DCE,1994.



Appendix 1: Tables

Applicationor System

Short-Term Medium-Term Long-Term

AFS X X XUnix net apps (ftp, telnet, etc.) X X XX11 X X XIMAP4 X X XPOP3 X X XHTTP/CGI X X XSAP R/3 X XPeopleSoft X XLDAP X XLotus Notes X XMVS/RACF XOracle8 XNetware (4+) X

Table 1: Systems and Applications Targeted for SAR/SSO at Duke.

Feature Critical Important Nice-to-haveStrong Authentication XDistributable Management XUnix compatibility XNT compatibility XStandards Compliance XScalability XPerformance XNetwork Security XStability/Easy maint. XWin95/Win98 compat. XMacOS support XSSO features XApplication Support XPublished API XSSO user interface XAutomated user registration XRemote installation X

Table 2: Decision Matrix: Features Required for SAR/SSO at Duke.



Strng Dstrb Unix NT Stds Scala Perf Net Stab Win MacAuth Mgmt Supp Supp Compl blity . Sec lity 95 OS

Vendor Product

MIT Hesiod - = + - = = + - = - -Sun NIS - = + - = - + - - - -Sun NIS+ - + = - - = = = - - ---- S/Key = - = - - - = + = - -MIT K4 + = + = + + + = + = =MIT K5 + = + = + + + + + = =CyberSafe --- + = + = = + ? + = = -IBM GSO = + = + = + ? = + + -Platinum AutoSecure - + = + - = ? - ? + -IntelliSoft SnareWorks + + + + + + + + = + -

SSO Applic. Pub User Install/features Support API Regis. Maint.

Vendor Product SSO-GUI

MIT Hesiod = = (+/Unix) + - - =Sun NIS = = (+/Unix) = - - =Sun NIS+ = - (+/Solaris) - - - ---- S/Key - = = - - -MIT K4 + = + - - =MIT K5 + - + - - =CyberSafe ---- + = - = - ?IBM GSO + + - + = +Platinum AutoSecure + = - + = ?IntelliSoft SnareWorks + = + = + +

K E Y+: strength of product=: available, but not particular product strength-: not available or too weak to rely upon?: insufficient data gathered to determine

Table 3: Vendor Performance: Features of Vended Products.

Product LocationHesiod ftp://athena-dist.mit.edu/pub/ATHENA/hesiod/NIS (Distributed with most Unix variants)NIS+ http://www.sun.com/software/white-papers/wp-nisplus/RADIUS http://www.livingston.com/tech/docs/radius/S/Key ftp://ftp.bellcore.com/pub/nmh/SecurID http://www.securid.com/MIT Kerberos V4 ftp://athena-dist.mit.edu/pub/kerberos/README.KRB4MIT Kerberos V5 http://web.mit.edu/kerberos/www/DCE http://www.opengroup.org/dce/KTH Kerberos V4 http://www.pdc.kth.se/kth-krb/Tcl-Kerberos http://www.neosoft.com/tcl/ftparchive/sorted/net/tcl-krb5/Java-Kerberos http://www.camb.opengroup.org/RI/www/jkrb/GSO http://www.software.ibm.com/enetwork/globalsignonSnareWorks http://www.isoft.com/CoreChange http://www.corechange.com/Platinum AutoSecure http://www.platinum.com/products/sysman/security.htmTivoli http://www.tivoli.com/

Table 4: Software Availability.



Protocol PSM Authentication Encryption Authorization SSOTelnet, FTP Yes Yes Yes Yes YesX11 Yes Yes Yes Yes N/ASMTP Yes Yes Yes Yes N/AIMAP4 Yes Yes Yes Yes YesHTTP Yes Yes Yes Yes YesPOP3 Yes Yes Yes Yes YesR{login,sh} Yes Yes Yes Yes YesNNTP Yes Yes Yes Yes YesIIOPNS Yes Yes Yes Yes YesSNMP Yes Yes Yes Yes YesMQseries Yes Yes Yes Yes YesPeopleSoft Devel Yes Yes Devel DevelSAP Devel Yes Yes Devel DevelLDAP Yes Yes Yes Yes YesLotus Notes Devel* Yes Yes Devel* Devel*SMB/Netbios Yes Yes Yes Yes YesOracle8 Yes Yes Yes Yes YesArbitrary IPprotocols

No** Yes Yes No** No**

K E YYes: SnareWorks provides this feature for the protocol

Devel: SnareWorks is currently developing this featureNo: SnareWorks does not provide this feature

N O T E S* Upcoming versions of Notes are reported to support X.509

certificate-based authentication. Such would make a NotesPSM redundant, since SnareWorks provides native support forX.509.

** The SnareWorks API provides a mechanism for sites todevelop their own PSMs, providing SSO and Authorizationfeatures for arbitrary IP protocols.

Table 5: SnareWorks Application Support Levels.


Single Sign-On and the System Administrator · PDF fileSingle Sign-On and the System...

Documents

Transcript of Single Sign-On and the System Administrator · PDF fileSingle Sign-On and the System...