A Security Architecture for Computational Grids*

Ian Foster* Carl Kessekan2 Gene Tsudik2 Steven Tueckel

1 Mathematics and Computer Science 2 hformation Sciences hstituteArgonne National Laboratory University of Southern CAfornia

Argonne, IL 60439 Marina del Rey, CA 90292{foster,tuecke} @mcs.anl.gov ~ {carl,gts}@isi.edu

Abstract

State-of-the-art and emerging scientific applications requirefast access to large quantities of data and commensuratelyfast computational resources. Both resources and data areoflen distributed in a wide-area network with componentsadministered locally and independently. Computations mayinvolve hundreds of processes that must be able to acquire re-sources dynamically and communicate efficiently. This pa-per analyzes the unique security requirements of large-scaledistributed (grid) computing and develops a security policyand a corresponding security architecture. An implemen-tation of the architecture within the Globus metacomputingtoolkit is discussed.

1 Introduction

Large-scale distributed computing environments, or ‘com-put ationfl grids” as they are sometties termed [4], cou-ple computers, storage systems, and other devices to enableadvanced apphcations such as distnbut ed supercomputirtg,teleimmersion, computer-enhanced instruments, and d~tri-buted data mining [2]. Grid applications are distinguishedfrom traditiond chent-server apphcations by their simulta-neous use of large numbers of r=ources, dynamic resourcerequirements, use of resources from mdtiple administrativedomains, complex communication structures, and stringentperformance requirements, among others.

WMe scdabtity, performance and heterogeneity are desirable go~ for any distributed system, the characteristicsof comput ationd grids lead to security problems that are not

that collectively span many administrative domains. Fur-thermore, the dynamic nature of the grid can make it iru-possible to =tabkh trust relationships between sites priorto apphcation execution. Fmdy, the interdomaiu securitysolutions used for grids must be able to irtteroperate with,rather than replace, the diverse intradomti accms controltechnologies inevitably encountered in individud domains.

In this paper, we describe new techniques that overcomemany of the cited Mculties. We propose a security pol-icy for grid systems that tidresses requirements for singlesign-on, interoperabfity with local pohcies, and dyttarnicflyvarying resource requirements. This pohcy focuses on au-thentication of users, resources, and processes and supportsuser-t~resource, resourc~t ~ttser, process-t-resource, andproces%t~process authentication. We &o describe a se-curity architecture and associated protocok that implementthis pohcy. Fittdy, we present a concrete implementation ofthis architecture and discuss our experiences deploying thisarchitecture on a large grid testbed spanning a diverse col-lection of resources at some 20 sites around the world. ThEimplement ation is performed in the cent ext of the Globussystem [5], which provides a tooMt, testbed, and set of apphcations that can be used to evaluate our approach. How-ever, we betieve that the proposed techniques are generalenough to make them apphcable outside the Globus con-text.

In summary, this paper makes four contributions to ourunderst andirtg of distributed system security:

1. it provides au in-depth analysis of the security problemin comput ationd grid systems and app~cations;

addres~ed by eti~ig security tech~o~ogies for distributedsystems. For example, par~el computations that acquire

2. it includes the first dettied formation of a securitypoticy for grid systems;

mdtiple computational resources introduce the need to e-tabkh security relationships not simply between a chent 3. it proposes solutions to specific techrticd issues raisedand a server, but among potentifly hundreds of processes by this poEcy, including Iocd heterogeneity and scd-

● This work was supported in part by the Mathematical, Inform a-abfity; and

tion, and Computational Sciences Division subpro~ of the Officeof Computational and Technology -search, U.S. Department of En-

4. it d=cribes a security architecture that uses these s~erg, under Contract \V-31-l 09-Eng-38; by the Defense Advanced W lutions to implement the security pohcy, and it demon-search Projects fl.gency under contract N66001-9&G852~ and by theNational Science Foundation.

strates - via larg~scde deployment - that th~ archi-tecture is workable.

Permission[clmakedigitalorhardcopiesof allorpartof thisworkforpersonalorclassroomuseis granted~vithoutfeeprovidedthatcopies 2 The Grid Security Problemarenotmadeordistributedforprofitorcommercialadvantageandthatcopiesbearthisnoticeandthefullcitationon thefirstpage.To copy We introduce the grid security problem with au exampleothen~,ise.torepublish,topostonsemersor toredistributeto lists, tiustrated in Figure 1. This example, although somewhatrequirespriorspecificpermissionantiora fee. contrived, captures import ant elements of red apphcations,jth Conference on Computer& CommunicationsSecuritySan Francisco CA USA

such as those discussed in Chapters 2-5 of [4].

Copfight ACM 199S1-581134074/98/1 1...S5.00 83

- -—..-.

sin~e, ffly connected logical entity, Iow-levd commu-nication connections (e.g., TCP/IP sockets) may becreated and destroyed dynamicdy during program ex-ecution.

Resources may require Merent authentication and au-thorization mechanisms and pohcies, which we @have Wted abtity to change. In Figure 1, we indi-cate this situation by showing the local access controlpohcies that apply at the Merent sites. These includeKerberos, plaintext passwords, Secure Socket Library(SSL), and secure sh&.

An individual user@ be associated with Merent lG

●

I.-&d@ .,.. .. ... ...’

........... ‘ k-”~”,.....-

.......... ,....,.-.. ...

— .. ....”’ ...

●

cd name spaces, credenti&, or accounts, at differentsites, for the purposes of accounting and access con-trol. At some sites, a user may have a regtiar account(“ap~ ‘physicist: etc.). At others, the user may usea dynamicdy assigned guest account or simply an ac-count created for the cotiaboration.

Resources and users may be located in Merent coun-tries.

To summatie, the problem we face is providing securitysolutions that can flow computations, such as the one justdescribed, to coordinate diverse access control pohcies andto operate securely in heterogeneous environments.

●

Figure 1: ExamDle of a lar~escde distributed commutation:us~r initiates a ~omput atio~ that accesses data and-comput-ing resourc= at mtitiple locations.

We imagine a scientist, a member of a mtiti-institutionrdscientific co~aboration, who receives ~mti from a coUeagueregarding a new data set. He starts an analysis program,which dispatches code to the remote location where the datais stored (site C). Once started, the anflysis program deter-mines that it needs to run a simtiation in order to comparethe experiruentd resdts with predictions. Hence, it contactsa resource broker service maintained by the co~aboration (atsite D), in order to locate ide resources that can be used forthe simtiation. The resource broker in turn initiates com-putation on computers at two sites (E and G). These com-puters access parameter values stored on a fle system at yetanother site (F) and *O communicate among themselves(perhaps using specitied protocob, such as mtiticast) andwith the broker, the original site, and the user.

This example Nustrates many of the distinctive charac-teristics of the grid computing environment:

● The user poptiation is large and dynamic. Partici-pants in such virtual organizations as this scientificco~aboration d include members of many institu-tions and @ change frequently.

● The resource pool is large and dynamic. Because indi-vidud institutions and users decide whether and whento contribute resources, the quantity and location ofavtiable resources can change rapidy.

● A computation (or processes created by a computa-

3 Securi& Requirements

Grid systems and apphcations may require any or fl of thestandard security functions, including authentication, accesscontrol, integrity, privacy, and nonrepudiation. In this pa-per, we focus primady on issues of authentication and ac-cess control. Speficdy, we seek to (1) provide authentica-tion solutions that ~ow a user, the processes that comprisea user’s computation, and the resources used by those pr~cesses, to verify each other’s identity; and (2) flow localaccess control mechanisms to be apphed without change,whenever possible. As ~ be discussed in Section 4, au-thentication forms the foundation of a security pohcy thatenables diverse Iocd security pohcies to be integrated intoa global framework.

In developing a security architecture that meets theserequirements, we *O choose to satisfy the fo~owing con-straints derived from the characteristics of the grid environ-ment and grid apphcations:

Single sign-on: A user should be able to authenticateeonce (e.g., when starting a computation) and initiate com-putations that acquire resources, use resources, release re-sources, and communicate internfly, without further au-thentication of the user.

Protection of credentials: User credenti~ (passwords,private keys, etc.) must be protected.

Interoperability with local security solutions: Whtie oursecurity solutions may provide interdomain access mecha-nisms, access to local resources }fl typicdy be determinedby a loc~ security pohcy that is enforced by a local securitymechanism. It is impractical to modify every local resourceto accommodate interdomain access; instead, one or moreentities in a domain (e.g., interdomain security servers) mustact as agents of remote chents/users for local resources.

Exportability: We require that the code be (a) exportableand (b) executable in mtitinational testbeds. In short, theexportabfity issues mean that our security poticy cannotduectly or indirectly require the use of bulk encryption.

tion) may acquire, start processes on, and release r~sources dynamicdy during its execution. .Even inour simple example, the computation acquired (andlater released) resources at five sites. In other words,throughout its fifetime, a computation is composed ofa dynamic group of processes running on different resources and sites.

The processes constituting a computation may com-municante by using a variety of mechanisms, includingunicast and mtiticast. WMe these processes form a

●

84

—— —----

Uniform credentials/certification infrastructure: Inter-domain access requires, at a minimum, a common way ofexpr~~sing the identity of a security principal such as an ac-tual user or a resource. Hence, it is imperative to employa standard (such as X.509v3) for encoding credenti~ forsecurity principals.

Support for secure group communication. A computationcan comprise a number of processes that WN need to coordl-nate their activities as a group. The composition of a processgroup can and WM change during the tifetirne of a compu-tation. Hence, support is needed for secure fin th~ context,authenticated) communication for dynamic groups. No cur-rent security solution supports this feature; even GSS-APIhas no provKlons for group security contexts.

Support for multiple implementations: The security pol-icy should not. dictate a spe~c implementation technology.fither, it shotid be possible to implement the security pol-icy with a range of security technologia, based on both pubECand shared key cryptography.

4 A Grid Security Policy

Before delving into the spedcs of a security architecture, itis important to identify the security objectives, the partic-ipating entities, and the underlying assumptions. In short,we must define a security policy, a set roles that define the se-curity subjects (e.g., users), security objects (e.g., resources)and relationships among them. WWe many Merent secu-rity pohcies are possible, we present a specific poficy that ad-dresses the issues introduced in the preceding section w~ereflecting the needs and expectations of applications, users,and resource owners. To our knowledge, the fo~owing &cussion represents the first such grid security pohcy that hasbeen defined to this level of detd.

In the fo~owing discussion, we use the foHowing termin-ology from the security hterature:

● A subject is a participant in a security operation. Ingrid systems, a subject is generdy a user, a processoperating on behti of a user, a resource (such as acomputer or a file), or a process acting on behalf of aresource.

A credential is a piece of information that is used toprove the identity of a subject. Passwords and certti-cates are examples of credenti&.

Authentications the process by which a subject provesits identity to a requester, typicfly through the useof a credentid. Authentication in which both par-ties (i.e., the requester and the requestee) authenticatethemselves to one another simtitaneously is referred toas mutual authentication.

An object is a resource that is being protected by thesecurity po~cy.

Authorization is the process by which we detertiewhether a subject is ~owed to access or use an object.

A trust domain is a logical, administrative structurewithin which a single, ;ons~tent Iocd security poticyholds. Put another way, a trust domain is a coUec-tion of both subjects and objects governed by singleadrniniitration and a single security pohcy.

With these terms in mind, we define our security poficyas fouow%

1.

2.

3.

4.

5.

6.

The grid environment consists of mtitiple trust do-mains.

Comment: ThB pohcy element states that the grid secunty pohcy must integrate a heterogeneous co~ectionof locfly administered users and resources. In general,the grid environment Id have bited or no influenceover Iocd security pohcy. Thus, we can neither requirethat Iocd solutions be replaced, nor are we flowed tooverride Iocd pohcy decisions. Consequently, the gridsecurity poficy must focus on controfing the interd~main interactions and the mapping of interdomain okeratiohs into locrd security pohcy.

Operations that are confined to a single trust domainare subject to local security poticy ody.

Comment: No additiond security operations or ser-vices are imposed on locfl operations by the grid se-curity po~cy. The local security pohcy can be imple-mented by a variety of methods, including firew&,Kerbero,s and SSH.

Both globrd and Iocd subjects exist. For each trustdomain, there exists a partial mapping from global tolocal subjects.

Comment: In effect, each user of a resource ~ havetwo rimes, a globfl name and a potentifly Merentlocfl name on each resource. The mapping of a globflname to a Iocd name is sit~spedc. For example, asite might map global user names to: a predefine Iocdname, a dynamicdy docated local name, or a single“group” name. The existence of the ~obd subjectenables the pohcy to provide single sign-on.

Operations between entities located in ~erent trustdomains require mutual authentication.

An authenticated globrd subject mapped into a Iocdsubject is assumed to be equivalent to being locflyauthenticated as that Iocd subject.

Comment: In other words, within a trust domain, thecombination of the grid authentication pohcy and theIocd mapping meets the security objective of the hostdomain.

N access control decisions are made Ioctiy on thebasis of the Iocrd subject.

Comment: This poficy element requires that acc~scontrol detilons remain in the hands of the local sy~tern administrators.

7. A program or process is Wowed to act on behfi of a

8.

user =d be delegated a subset of the user’s rights.

Comment: This pohcy element is necessary to supportthe execution of long-hved programs that may acquireresources dynamicdy without additiond user inter-action. It is &o needed to support the creation ofprocesses by other processes.

Processes running on beh~ of the same subject withinthe same trust domain may share a single set of cre-denti~.

Comment: Grid computations may involve hundredsof processes on a single rwource. This poticy comp~nent enables sc~abtity of the security architecture tolarg~scde parflel apphcations, by avoiding the needto create a unique credential for each process.

85

>. .—

Figure 2: A computational grid security architecture.

We note that the security poticy is structured so as notto require b& privacy (i.e., encryption) for any reason.Export control laws regarding encryption technologies arecomplex, dynamic and vary from country to country. Con-sequently, these issues are best avoided as a matter of design.We &o observe that the thrust of this pohcy is to enablethe integration of diverse Iocd security poficies encounteredin a comput ationd grid environment.

5 Grid Security Architecture

The security poficy defined in Section 4 provides a contextwithin which we can construct a spedc security architec-ture. In doing so, we specify the set of subjects and objectsthat = be under the jurisdiction of the security poticy anddefine the protocok that d govern interactions betweenthese subjects and objects. Figure 2 shows an overview ofour security architecture. The foUowing components are depitted: entities, credenti&, and protocob. The thick finesrepresent the protocok described later in the paper. Thecurved he separating the user from the rest of the figuresigfies that the user may disconnect once the user proxyhas been create~ the dashed hes represent authenticatedinterprocess communication.

We are interested in computational environments. Con-sequently, the subjects and objects in our architecture mustinclude those entities from which computation is formed. Acomputation consists of many processes, with each processacting on behti of a user. Thus, the subjects are usersand processes. The objects in the architecture must includethe wide range of resources that are avtiable in a grid en-vironment: computers, data repositories, networks, displaydevices, and so forth.

Grid computations may grow and shrink dynamicdy,acquiring resources when required to solve a problem andreleasing them when they are no longer needed. Each timea computation obtains a resource, it does so on behalf ofa particdar user. However, it is frequently impractical forthat “use~ to interact directly with each such resource forthe purposes of authentication the number of resources in-volved may be large, or, because some apphcations may run

for extended period of time (i.e., days or weeks), the usermay wish to ~ow a computation to operate without inter-vention. Hence, we btroduce the concept of a user prozgthat can act on a user’s behti without requiring user inter-vention.

Defiltion 5.1 A user proxy is a session manager processgiuen permission to act on beha~ of a user for a limitedperiod of time.

The user proxy acts as a stand-in for the user. It hasits own credentib, etiating the need to have the useron-he during a computation and etiiating the need tohave the user’s credenti~ av~able for every security operation. Furthermore, because the Metirne of the proxy isunder control of the user and can be Nted to the dura-tion of a computation, the consequences of its credenti&being compromised are less dire than exposure of the user’scredenti&.

Within the architecture, we &o define an entity thatrepresents a resource, serving as the interface between thegrid security architecture and the Iocd security architecture.

Defition 5.2 A resource proxy is an agent used to trans-late between interdomain security operations and local in-tradomain mechanisms.

Given a set of subjects and objects, the architecture isdetermined by specifying the protocok that are used whensubjects and object interact. In defining the protocok, we~ use U, R, and P to refer to a user, resource, and process,respectivdy, whtie UP and RP d denote a user proxy andresource proxy, respectivdy. Many of the fo~owing prot~cok @ rely on the abtity to assert that a piece of dataoriginated from a known source, X, without modification.We know these conditions to be true if the text is ‘signed”by X. We indicate signature of some text ttitby a subjectX by Sigx {tezt}. This notation is summarized in Table 1.

Table 1: Notation used in the rest of the paper

~

The range of interactions that can occur between entitiesin a computational grid is defined by the functionfity of theunderlying grid system. However, based on experience andthe current grid systems that have been btit to date, it isreasonable to assume that the grid system ~fl include thefo~owing operations:

● Wocation of a resource by a user (i.e., process cre-ation),

. ~ocation of a resource by a process, and

● communication between processes located in dfierenttrust domains.

(We use the term allocation to denote the operations re-quired to protide a user with access to a resource. On somesystems, this * involve interaction with a schedtier to obtain a reservation [3].) We must define protocok that controlUP-RP, P-RP, and P-P interactions. In addition, the intr~duction of the user proxy means that we must estabhh howthe user and user proxy (U- UP) interact.

86

Within our architecture, we meet the above requirementby Wowing a user to frog on” to the grid system, creating auser proxy using Protocol 1. The user proxy can then d~cate resources (and hence create processes) using Protocol 2.Using Protocol 3, a process created can ~ocate additionalresources duectly. Finfly, Protocol 4 can be used to definea mapping from a globfl to a Iocd subject.

We now describe each of these protocok in more detd.We note that to minimize problems with export controk,the protocok are d designed to rely on authentication andsignature techniques, not encryption. Furthermore, our descriptions do not tdk about specific cryptographic methods.In fact, as we shd see below, our implementation uses theGeneric Security Services apphcation programming interfaceto achieve independence from any spedc security technol-ogy.

5.1 User Proxy Creation Protocol

Reed that a user proxy is an entity within our architecturethat acts on behti of a user. In practice, the user proxy is aspecial process started by the user which executes on somehost local to that user. The main issue in the user proxycreation protocol is the nature of credenti~ given to theproxy and how the proxy can obtain these credenti&.

A user could enable a proxy to act on her behalf by giv-ing the proxy the appropriate credenti~ (e.g., a passwordor private key). The proxy codd then use those creden-tials directly. However, this approach has two sigdcantdisadvantages it introduces an increased risk of the creden-ti& being compromised and does not flow us to ratrict thetime duration for which a proxy can act on the user’s beh~.Instead, a temporary credentid, CUP, is generated for theuser proxy; the user indicates her permission by signing thiscredential with a secret (e.g., private key). CUP includes thevddity interval as we~ as other restrictions imposed by theuser, e.g., host names (where the proxy is dewed to operatehorn) and target sites (where the proxy is Wowed to startprocesses and/or use resources.)

The actual process of user proxy creation is summarizedin Protocol 1. As a consequence of this protocol, the userproxy can use its temporary credentid to authenticate withresource proxies.

1. The user gains acc=s to the computer from whlcb the userproxy is to be created, using whatever form of local authenti-cation is placed on that computer.

2. The user produces the user proxy credential, CUP, by usingtheir credential, Cu, to sign a tuple containing the user’s id, thename of the local host, the validlty interval for Cup, and anyother information that will be required by the authenticationprotocol used to implement the architecture (such as a pubfickey if certificatebssed authentication is used):

CUP = Sigu {user-id, host, start-time, end-time, auth-info,. . . }.

3. A user proxy process is created and provided with CUP. It isup to the Iocd security policy to protect the integrity of CUPon the computer on which the user proxy is located.

Protocol 1: User Droxv creation

The concept of a user proxy is not unique to our archi-tecture. For example, Kerberos generates a Wted-hfetimeticket to represent a user. Various pubfic key systems [7, 12],use techniques sirniiar to ours in which temporary creden-ti~ Q.e., a pubhc and private key pair) are used to generate

87

a tited Hetime certificate which is then signed by the userto indicate that th~ certificate represents, or is a proxy for,the user. What distinguishes our architecture from these appreaches is the way that a user proxy interacts with the re-source proxy to achieve single sign-on and delegation, whichis discussed in the next section.

5.2 Resource Allocation Protocol

In discussing resource Wocation, we decompose the probleminto two classes: Wocation of resources by a user proxy and~ocation Qf resources by a process. As process docationis a genertization of user proxy docation, we }fl start ourd~cussion with ~ocation by a user proxy.

Recfl that operations on resources are controUed byan entity, cded a regource prozy, which is responsible forschedtig access to a resource and for mapping a compu-tation onto that resource. The resource proxy is used asfoUows. A user proxy requiring access to a resource first de-termines the identity of the resource proxy for that resource.It then issues a requ-t to the appropriate resource proxy.If the request is successful, the resource is flocated and aprocess created on that resource. (The procedure wotid bestiar if our god was simply to flocate a resource, such asnetwork or storage, with which no process was to be ass~ciated. However, for brevity, we assume here that processcreation always fo~ows resource docation.)

The request can fti because the requested resource isnot avtiable (flotation ftiure), because the user is nota recognized user of the resource (authentication ftiure),or because the user is not entitled to use the resource inthe requested mode (authorization fdure). As discussedabove, it is up to the resource proxy to enforce any localauthorization requirements. Depending on the nature of theresource and Iocd poEcy, authorization may be checked atresource flotation time or process creation time, or it maybe imp~cit in authentication and not be checked at fl.

We define as Protocol 2 the mechanism used to issue a r~quest to a resource proxy from a user proxy. The veficationin Step 3 may require mapping the user’s credenti& into alocal user id or account name if the pohcy of the resourceproxy is to check for authorization at resource Wocationtime. Nternatively, authorization checks cart be delayeduntfl process creation time. The mechanism by which thismapping is performed is discussed in Section 5.4. Noticethat the abfity to have a resource proxy create credenti~on behti of the proc=s it creates rehes on a process and itsresource proxy executing in the same trust domain.

The protocol creates a temporary credentid for the newlycreated processes. This credentid, CP, gives the processboth the abtity to authenticate itseM and the identify ofthe user on whose behti the process was created. A sin-gle resource ~ocation request may ratit in the creation ofmtitiple processes on the remote resource. We assign Wsuch processes the same credentid, as ~owed by securitypoLcy element 8. An advantage of this decision is that inthe situation when a user docates resources on large par-~el computers, scdabfity is enhanced. A disadvantage isthat it is not possible to use credenti~ to distinguish twoprocesses started on the same resource by the same Woca-tion request. However, we do not betieve that th~ featureis often usefd in practice.

The existence of process credenti& enables us to irnpl~ment a range of additiond protocok that ~ow a process tocontrol access to incoming communication operations on a

——-— ._ .— -—. . .-

1.

2.

3.

4.

5.

6.

7.

8.

The user proxy and r=ource proxy authenticate each other u%ing GUP and CRP. As part of this process, the resource proxychecks to ensure that the user proxy’s credentials have not ex-pired.

The user proxy presents the resource proxy with a signed r~quest in the form Sigup{arlocationspecification}.

The resource proxy checks to see whether the user who signedthe proxy’s credentials is authorized by local pohcy to makethe allocation request.

If the request can be honored, the resource proxy creates a~SOURCEC~DENTIALS tupIe containing the name of theuser for whom the resource is being allocated, tbe resourcename, etc.

The resource proxy securely passes the RESOURCECREDENTIALS to the user proxy. (This is possible fromstep 1.)

The user proxy examines the RESOURCRCREDENTIALS r~quest, and, if it wishes to approve it, signs the tuple to produceCp, acredentid forthe requesting resource.

Theuser proxy securely passea Cptothe resource proxy. (Thisisagain possible due to step 1.)

Ther=ource proxy dlocatea the resource and passes the newprocess(es)Cp. (The latter transfer reheonthe fact that theresource proxy tid process arein the same trust domain.)

Protoco12: Resource allocation (arrdproc=s creation)

per-subject basis. Forexample, onecanuse theprocesscr~denti& to authenticate a sending process to a destinationprocess, negotiate a session key, and then sign d point-t~point communication, guaranteeing the identity of thesender. The authentication process is simple, since we needsimply to check that the other process’ credenti& are vtid,i.e., in the same group.

5.3 Resource Allocation from a Process Protocol

WMe resource flotation from a user proxy is necessary tostart a computation, the more common case is that resource~ocation W be initiated dynamic~y from a process cr~ated via a previous resource docation request. Protocol 3defines the process by which this can be accomphhed.

1. The process and its user proxy authenticate each other usingCp and cup.

2. The proc~s issues a signed request to its user proxy, with theform

S*gp { “allocate”, allocation reguest parameters }

3. If the user proxy decides to horror the requ-t, it initiates aresource allocation request to the specified resource proxy usingProtocol 2.

4. The resulting proc=s handle is signed by the user proxy andreturned to the requ~ting process.

Protocol 3: R~ource allocation from a user procms

Adrnittedy, this technique lacks scdabfity because of itsrehance on a sin~e user proxy to forward the request to theresource proxy. However, this protocol offers the advantageof both sirnphcity and finegrained control. Whale the formeris seU-evident, fin~grained control requires some elabora-tion. Consider the obvious alternative of dewing a process(running remotely on behti of a user) to flocate further r~sources and create other processes utiaterfly. This wotidhave two titations:

●

●

A user must be able to encode and embed arbitrarypohcy into each process so as to support individualcriteria for resource do cation.

A security breach or a compromise at a remote site canrestit in mrdicious and fraudtient resource Wocationpurported on behti of an unsuspecting user.

The creation of process spedc credenti~ in protocol3 resdts in a delegation of a set of rights horn the user tothe process. The use of delegation for distributed authen-tication hw been addressed in the security Eterature (e.g.,[7]). What sets our approach apart from delegation-basedauthentication schemes is the role played by the resourceproxy. Approaches such as those proposed by [7] requirethat addltiond inter-resource trust relationships be estabhhed to enable delegation between processes running onthose resources. In our protocoh, authentication is alwaysbetween a user proxy and a resource proxy. Consequently,our single sign-on protocol leverages the existing trust rela-tionship between a user and a resource that was estabkhedwhen the user was initi~y granted access to the resource.

5.4 Mapping Registration Protocol

A central component of the security pohcy and the resultingarchitecture is the existence of a ‘correct” mapping betweena global subject and a corresponding Iocd subject. Weachieve this conversion from a global name (e.g., a ticket orcertificate) into a Iocd name (e.g., login name or user ID) byaccessing a mapping table maint ained by the resource proxy.W~e a mapping table can be created by the Iocfl systemadministrator, this approach imposes a certain administra-tive burden and introduces the possibtity for error.l Hence,we have developed a technique that dews a mapping to beadded by a user.

The basic idea behind this technique, presented as Prot~COI4, is for a user to prove that he holds credenti~ for botha ~obd and Iocd subject. This is accompbhed by authen-ticating both globdy and directly to the resource using theIocd authentication method. The user then asserts a mapping between global and local credenti~. The assertion iscoordinated through the resource proxy, since it is in a posi-tion to accept both global and Iocd credenti&. In the firsttwo steps, we show the ~erent activities performed by useras it authenticates globdy (1 .a and lb) and to the resource(2a and 2.b).

Matching MAP-SUBJECT-P and MAP-SUBJECT-UPrequests must be issued from both the user proxy and mapping process. This ensures that the same user is in possesion of both global and Iocd credentids. If the results ofthe mapping protocol are stored in a database accessible tothe resource proxy, then the user need execute the mappingprotocol ofly once per resource. The duration of time forwhich a mapping remains vtid is determined by Iocd systern administration poficy. However, we would hope that amapping W remain in place for the Efetime of either theglobal credenti~ or the user’s local account.

Part of the mapping protocol requires that the user loginto the resource for which the mapping is being created.ThE requires that a user authenticate themselves to thelocfl system. Consequently, the mapping protocol is only

1However, ss will be &scussed in Section 6.3, some sit= actuaf[y

want to manage the mapping table explicitly as part of their accountcreation process. Such sites consider protocol 4 as an optional feature.

-J ,- . “—.

l.a User proxy authenticates with the resource proxy.

1.b User proxy issues a signed hfAP-SUBJECT-UP requ=t to r-source proxy, providing as arguments both global and r=ourcesubject names.

2.a User logs on to the resource using the resource’s authenticationmethod and starts a map registration process.

2.b hlap registration proc-s issues MAP-SUBJECT-P request toresource proxy, providing as arguments both global and r~source subject namm.

1. Resource proxy waits for MAP-SUBJECT-UP and MAP-SUBJECT-P requests with matching arguments.

2. Resource proxy ensures that map registration process belongsto the r=ource subject specified in the map requ~t.

3. If a match is found, r~ource proxy sets up a mapping and sendsacknowledgments to map registration process and user proxy.

4. If a match is not found within hIAP-TIMEOUT, resource proxypurges the outstanding request and sends an acknowledgmentto the waiting entity.

5. If acknowledgment is not received within MAP-TIMEOUT, r+quest is considered to have failed.

Protocol 4: Nfapping global to local identifier.

as secure as the locfl authentication method. Clearly, r~sources with strong authentication (for example based onKerberos [14], S/KEY, or Secure SheU [22]) d restit in amore secure mapping.

6 An Implementation of the Grid Security Architecture

In this section, we describe the Globus Security Infrastruc-ture (GSI), an implementation of our proposed grid secu-rity architecture. GSI was developed as part of the Globusproject [5], whose focus is to

●

●

●

understand the basic infrastructure required to support the execution of wide range of computational gridapplications,

bufld prototype implementations of this infrastructure,and

evaluate applications on largescde testbeds.

As part of the Globus project, we have btit GUSTO, atestbed that spans over twenty institutions and couples over2.5 tertiops of peak compute power. This testbed has beenused for a range of compute and communication-intensiveapphcation experiments.

As speded by our security architecture, GSI providessupport for user proxies, resource proxies (the Globus resource do cation manager (GRAM) [3]), certtication au-thorities, and implementations of the protocob describedabove. We describe here selected aspects of this implement-ation, focusing on our use of the Generic Security Servicesapphcation programming interface (GSS-API), the SecureSocket Layer (SSL), and our experiences deploying the imp-lement atlon in a large t=tbed.

6.1 Use of the Generic Security Services Application Pr~gramming Interface

The protocok defined above are expressed in terms of a~stract security operations, such as signature and authenti-cation, rather than in terms of spefic security technologies,such as DES or MA. Hence, these protocok can be implemented by using any of a number of modern security tech-nologies and mechanisms, such as shared secrets and tick-ets (e.g., Kerberos), pubtic key cryptography (e.g., SSL), or

89

*

Figure 3: Use of GSS-API in Globus

smart-cards. This separation of protocol and mechanism is adesirable property in an implementation as we~, since it en-hances the overd portabtity and flexibtity of the restitingsystem.

To achieve the desired separation, GSI is implementedon top of the Generic Security Services application program-ming interface (GSS-API) [16]. As the name irnphes, GSS-API provides security services to cders in a generic fashion.These services can be implemented by a range of underlyingmechanisms and technologies, dewing sourc~level port a-bfity of applications to ~erent environments.

GSS-API dews us to construct GSI simply by transcribing the grid security protocok into GSS cA. We can thenexploit various grid-level security mechanisms without d-alteringthe GSI implementation. The relationship betweenGlobus and GSS-API is shown in Figure 3.

GSS-API is oriented toward tw~party security contexts.It provides functions for obtaining credenti~, performingauthentication, signing messages, and encrypting messages.GS$API is both transport and mechanism independent.Transport independence means that GSS-API does not depenal on a spedc communication method or Ebrary. Rather,each GSS-API cd produces a sequence of tokens that canbe communicated via any communication method an a~pfication may choose. Currently, GSI uses raw TCP sock-ets and the Nexus communication hbrary [6] to move tmkens between processors, although other transports can beeastiy used as we~. Mechanism independence means thatthe GSS does not specify the use of spedc security prot~cob, such as Kerberos, SESAME, DES, or RSA pubfic keycryptography. In fact, a GSSAPI implementation may support more than one mechanism and use negotiation-specificmechanisms when the parties in the GSS operation initidycontact one another.

GSS-API bindings have been defined for several mech-anisms. To date, we have worked with two: one based onplaintext passwords, and one based on X.509 certificates. (Intidition, a proof-of-concept Kerberos V5 implementationhas been recently completed.) The plaintext password imp-lementation was designed to support system debugging andsmfl-scde deployment, wtie the certficat~b~ed iraple-mentation is used for wid~area “production” use. The flex-ibtity of our GSS-API implementation dews us to switchbetween pubtic key and plaintext versions of Globus withoutchanging a single he of Globus code.Remark: Whale the use of GSS-API has proven to be asignificant benefit, the interface is not without tilt ations.GSS-API does not offer a clear solution to delegation, nordoes it provide any support for group contexts. The formeris needed to ~ow temporary and tited transfer of user’srights to a process in the event that the user trusts the site

2The delegation flag in the gss-init~ec-contuto notwithstanding.

——>7 _. - ,....w. /.- . ..,.

. ,..--——-.. . .

.. ___,. >:--- .—

(and resource) hosting th~ process enough to forgo an au-thenticationfauthorization handshake with the user proxyeach time a new process needs to be created. Group con-text management is needed to support secure communica-tion within a dynamic group of processes belonging to thesame computation (or even the same user).

6.2 Support for Public Key Technology in GSI

The GSI implementation currently uses the authenticationprotocob defined by the Secure Socket Library (SSL) pr~tocol [10]. At first glance, this may seem We an odd choice,since SSL defines a communication layer w~e GSS exphc-itly does not. However, in principle, it is possible to separatethe authentication and communication components of SSL.To avoid confusion between the SSL authentication protwCO1and the SSL communication Ebrary, we use the termSSL Authentication Protocol or SAP to refer spe~cfly tothe authentication elements of SSL. We refer to our GSSimplementation using SAP as GSS/SAP.

The use of SAP was motivated by several factors. First,there exists a high-qutity, pubfic-domtin implementation ofthe SSL protocol (SSLeay), developed outside of the UnitedStates and hence avoiding export control issues. Second,SSLeay is structured in a way that flows a token streamto be extracted easfly, thus making the GSS implementa-tion straightforward. Third, SSL is widely adopted as themethod of choice for authentication and secure communi-cation for a broad range of distributed services, includingHTTP servers, Web browsers, and directory services [11].By combining GSS/SAP with TCP sockets, we can, in fact,reconstitute the entire SSL protocol. Consequently, a com-putation can use GSI to access not ordy Globus services, but*O generic Web services.

6.3 Deployment

GSI has been deployed in GUSTO, a grid testbed spanningsome 20 sites [5] in four countries. GUSTO iududes NSF su-percomputer centers, DOE laboratories, DoD resource cen-ters, NASA laboratories, universities, and companies.

The initial deployment in late 1997 w= hmited to thepassword implementation of GSI and involved inst~ationof the GRAM resource proxy described previously and theestabkhment of a globusrnap fle that describes the globd-t~locd mapping apphcable at a particular site. Since Pr~tocol 4 above has not yet been implemented, this file iscurrently maintained manu~y by site administrators. (Wenote that, in practice, site administrators often seem to wantto maintain this fle manudy, using it as a form of accesscontrol ht.) The GRAM resource proxy runs as root soas to implement the appropriate mapping for each incomingrequest.

As mentioned ear~er, GSS/SAP is intended to be thedefadt method for Globus apphcations. After obttilng ex-port approvfl and hcense in early 1998, GSS/SAP i~pl~mentation has been deployed on a widescfle (both nationaland iuternationd) basis starting in Spring 1998. The pass-word implementation is no longer in production use.

We are *O operating a Globus certification authorityto support. certificate generation for users and resources.To date, resource proxies have been developed that providegateways to Iocd Kerberos and cleartext/rsh authenticationmechanisms.

Our (admittedy tilted) experience with GSI deploy-ment offers some confidence that the techniques proposed

in this paper are workable. Partictiarly iutcresting in th~regard is the experience of inst fig resource proxies at var-ious sites. Because it runs as root, resource proxy code wassubject to careful review by security administrators at dfier-ent sites. The result to date has been unanimous approval.

7 Related Work

We distinguish among two main clwses of related worktradition distributed systems security solutions and tech-niques geared spe~cdy towards large, dynamic, and high-performance computing environments. Not surptilngly, therehas been comparatively httle work in the latter area.

There are many general-purpose solutions for distributedsystems security. Notable examples are Kerberos, DCE,SSH, and SSL. We now review them in brief.

Kerberos has been widely used shce the rnid-1980s.Although it has evolved considerably during that time, thecurrent MIT release st~ rehes heady on conventional cryptography and the on-fine AS/TGS combination. Recently,optional Kerberos extensions have been proposed to supportthe use of pubhc key cryptography for certain tasks, includ-ing initial user Iogin (PKINIT) [20], interdomain authentica-tion and key distribution (PKCROSS) [19], and peer-t~peerauthentication (PKTAPP) [17]. We note that the last twohave not progressed past Internet Drafts (expired) and noimplementations are avtiable. Although these extensionsmake Kerberos more attractive (since pubhc key cryptogra-phy lends itse~ to greater security and scdabtity), Kerberosstti remains a fairly heavyweight solution best suited for in-tradomain security.

DCE is a mature product developed by the Open Groupwith the security component derived largely from Kerberos.DCE authorization service is much richer and more effectivethan that of plain Kerberos. In addition to security ser-vices, DCE includes a time service, a name service, and afle system. ~ this is both a blessing and a curse: a bless-ing since DCE sites get a bunded solution, and a curse,since it is hard to use ody selected components of DCE.Furthermore, because of its Kerberos legacy, DCE is basedon conventional, shared-key cryptography with trusted thirdparties (TTPs) such as authentication, ticket granting, au-thorization, and credentid servers. Interdomain security ispossible albeit with some comphcations on-tine presence of~Ps in fl domains is =sumed. The latest DCE releasedoes support the option of using pubhc keys for initial 1*gin. However, the AS/TGS are stti assumed to be on tine,and pubhc key cryptography is not used for peer-t~peerauthentication. Moreover, MIT Kerberos and DCE are notcompatible, in particular, where pubhc key use is concerned.

SSH has been developed as a replacement for (mostlyUNIX-flavored) remote Iogin, file transfer, and remote exe-cution commands. It is geared primady for the chent-servermodel. Urdike DCE/Kerberos, SSH is fu~y pubfic key en-abled; that is, ~ authentication and session key distributionis pubhc key based. SSH supports X.509v3, PGP, and SPKIcertificate formats. Nso unhke DCE/Kerberos, SSH is ori-ented toward interdomain communication security. This is adefinite plus. However, SSH is essentidy an W-or-nothingsolution. It provides a secure pipe between the connectionend-points and leaves out important elements such as auth~rization and delegation. SSH does not provide a we~-definedAPI and does not dow decoupling of communication andsecurity services. In addition, SSH’S use of bulk encryptionis problematic with respect to the overd performance.

SSL is Netscape’s secure communication package. It

90

-. ---

is used primarfly for securing HTTP-based Web traffic, d-althoughthe software is general enough to secure any type ofabove-transport-layer traffic. SSL supports X.509v3 certifi-cates and uses pubtic key cryptography (RSA) for authen-tication and key distribution (the latter can be done witheither RSA or D~e-HeHman). Like SSH, SSL is a ‘securepipe” solution. Communication and security services are in-tertwined; SSL ~ssumes a stream-oriented transport layerprotocol underneath, for example, TCP. However, we notethat SSL dews authenticated, yet nonencrypted, commu-nicantion.

We now turn to more recent and more specirdized solu-tions aimed at large-scale, wid~area distributed computing.

CRISIS is the security component of WebOS, an oper-ating system developed for use in wide area distributed com-puting [21, 1]. M7ebOS and Globus are sirniiar in that bothaim to provide seatiess access to fles and comput ationd re-sources d~tributed throughout a wide-area network. CH-S1S, We GSI, employs SSL for point-tmpoint secure datatransfer and X.509 for certificates.

CNSIS is both a more intrusive and a more completesecurity architecture. Wthough it supports local site auton-omy insofar as poticy, it does not accommodate Iocrd securitymechanisms. As mentioned ear~er, one of our primary gordsis to provide a thin layer of homogeneity to tie together dis-parate and, often incompatible, Iocd security mechanisms.On the other hand, CWSIS encompasses more than justauthentication; it *O includes extensive access control pr~ti~ions, caching of credenti&, and a secure execution envi-ronment, Janus [8].

Utike Globus, CRISIS does not treat a process as a r~source or an entity. This is an important ~erence becauseour security architecture dews processes to act indepen-dently, for example, to request access to other resources orstart another process ekewhere. This makes a running pr~cess a temporary principal and, at the same time, a resourcejointly owned by the user it belongs to and the Iocd hostsite.

A further d~tinction is that we view a grid computationas a dynamic group of peer processes running on ~erentresources in ~erent sites. (Therefore, security in dynamicpeer groups is a fundamental issue.) Because of its origins,CWSIS is a more Webonented architecture that, althoughquite suitable for remote execution, is not aimed at (or suit-able for) a typical grid computation.

The Legion ([9, 15] project &o has gords solar tothose of Globus, focusing on object-based software technol~gies for application in grid systems. An object-oriented ar-chitecture provides much flexibtity with respect to, in par-ticdar, security mechanisms. Every object (e.g., fle) con-tains a number of “hooks” flowing security services to beadded/extended on a very grantiar level. However, Legiondefines a rather high-level security model without an acturdarchitecture and protocok. In fact, the Globus too~t canbe used to construct an implementation of the Legion’s security model.

To summarize, existing distributed computing securitytechnologies are concerned primtiy with problems thatarise in dent-server computing and do not adequately ad-dress the issus of creating N-way security contexts, verylarge (as we~ as diverse) user and resource sets, or localmechanism/pohcy heterogeneity.

91

8 Conclusions and Future Work

We have described a security architecture for Iarge-scdedistributed computations. ThB architecture is immediat elyuseful and, in addition, provides a firm foundation for inves-tigations of more sophisticated mechanisms. We have *Odescribed an implementation of th~ architectur~ thw im-plementation has been deployed on a nationd-scde testbed.

Our architecture and implementation address most of therequirements introduced in Section 3. The introduction ofa user proxy addresses the single sign-on requirement and*O avoids the need to communicate user credenti&. Theresource proxy enables interoperabtity with local securitysolutions, as the resource proxy can translate between inter-domain and intradomain security solutions. Because encryption is not used within the associated protocok, export con-trol issues and hence internationrd use are sirnphfied. Withinthe implementation, the use of GSS-API provides for porta-bfity. Group communication is one major requirement notaddressed.

The security design presented addresses a number ofscdabtity issues. The sharing of credenti~ by processescreated by a single resource docation requmt means thatthe estabkhment of process credenti& ~ not, we expect,be a bottleneck. The fact that W resource Wocation re-quests must pws via the user proxy is a potentird bottle-neck this must be evrduated in re&tic apphcations and,if required, addressed in future work. One major scdabd-ity issue that is not addressed is the number of users andresources. Clearly, other approaches to the estabkhmentof global to locrd mappings ~ be required when the num-ber of users and/or resources are large on example is theusecondition approaches to authorization [13]. However, webeheve the current approach can ded with this.

We hope to develop the techniques described in this pa-per in four major directions: more flexible poticy-based ac-cess control mechanisms, bwed for example on use condi-tions [13]; representation and implementation of interd~main access control pohcies; secure group communication,btiding for example on work in the CLIQUES project [18];and delegation mechanisms to support scdabtity to largenumbers of resources and users.

Acknowledgments

We grateffly acknowledge Doug Engert’s assistance withthe development of the SSL implementation of the Globussecurity architecture, Stuart Martin’s contributions to theimplement ation of the Globus Resource Mocation Manager,and Bfi Johnston’s comments on a draft of the paper. We*O thank the anonymous referees for their insightfti cri-tique.

— –- -,. ..—... r. .---.——

Referent=

[1]

[2]

[3]

[4]

[5]

[6]

E. Bdani, A. Vahdat, T. Anderson, and M. Dam.The CMSIS wide area security architecture. In UsenixSecurity Symposium, January 1998.

C. Catlett and L. Smarr. Metacomputing. Communi-cations of the ACJf, 35(6):4452, 1992.

K. Czajkowski, I. Foster, C. Kessehuan, S. Martin,W. Smith, and S. Tuecke. A resource managementarchitecture for metacomputing systems. Technical r~port, Mathematics and Computer Science Ditilon, Ar-gonne National Laboratory, 1998.

I. Foster and C. Kasehnan, editors. ComputationalGrids: The Future of High Performance DistributedComputing. Morgan Kaubann, 1998.

I. Foster and C. Kessehnan. The Globus project: Aprogras report. In Heterogeneous Computing Work-shop, March 1998.

I. Foster, C. Kessehnan, and S. Tuecke. The Nexusapproach to inte~ratin~ mdtithreadin~ and communi--- --cation. Journal of Parallel and Distn-buted Computing,3fi70-82, 1996.

-.

[7] M. G=er and E. McDermott. An architecture for prac-tical delegation in a distributed system. In IEEE Sym-posium on Research in Security and Priuacy, pages 20-30, May 1990.

[8] I. Goldberg, D. Wagner, R. Thomas, and E. Brewer.A secure environment for untrusted helper applications— confining the tiy hacker. In Proc. 1996 USENIXSecurity Symposium, 1996.

[9] A. Grirnshaw, W. Wti, J. French, A. Weaver, and P.

[10]

[11]

[12]

[13]

[14]

[15]

Reynolds, Jr. Legion: The next Iogicd step toward anationwide virtu~ computer. Technicfl Report C$9421, University of Viginia, 1994.

K. Hickman and T. Elgarnd. The SSL protocol. Inter-net draft, Netscape Communications Corp., June 1995.Version 3.0.

T. Howes and M. Smith. A scalable, deployable di-rectory service framework for the internet. TechnicalReport CITI TR-9$7, CITI, University of Michigan,Jtiy 1995.

D. Hiihdein. Credentid management and secure sin-@eIogin for SPKM. In ISOC Network and DistributedSystem Security Symposium, March 1998.

W. Johnston and C. Larsen. A us~condition centeredapproach to authenticateed globrd capabfities: Securityarchitectures for Iarge-scde distributed co~aboratoryenvironments. Technical Report 3885, LBNL, 1996.

J. KoN and C. Neurnan. The Kerberos network.authen-tication service (v5). ~ternet RFC 1510, September1993.

M. Lewis and A. Grimshaw. The core Legion object model. In Proc. 5th IEEE Symp. on High Per-formance Distributed Computing, pag= 562-571. IEEEComputer Society Press, 1996.

[16]

[17]

[18]

[19]

[20]

[21]

[22]

92

J. Llnn. Generic security service apphcation programinterface, version 2. Internet RFC 2078, January 1997.

A. Medvinsky and M. Hur. Pubhc key utfizing ticketsfor application servers. Internet draft, January 1997.

M. Steiner, G. Tsudik, and M. Waidner. CLIQUES:A new approach to group key agreement. In IEEEICDCS’98, May 1998.

B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Som-merfdd, A. Medvinsky, and M. Hur. Pubhc key cryptography for cros~reahn authentication in Kerberos.Internet draft, November 1997.

B. Tung, J. Wray, A. Medvinsky, M. Hur, and J. Tro~tie. Pubhc key cryptography for initial authenticationin Kerberos. Internet draft, November 1997.

A. Vahdat, P. Eastham, C. Yoshikawa, E. Belani,T. Anderson, D. Ctier, and M. D*. WebOS: Oper-ating system services for wide area apphcations. Tech-nical Report UCB CSD-97-938, U.C. Berkdey, 1997.

T. Wonen, T. Kivinen, and M. Saarinen. SSH protocolarchitecture. Internet draft, November 1997.