A Framework for Role-Based Access Control in Group Communication Systems

In this paper we analyze the requirements access control mechanisms must fulfill in the context of group communication and define a framework for supporting fine-grained access control in client-server group communication systems. Our framework combines ro

AFrameworkforRole-BasedAccessControlinGroup

CommunicationSystems

CristinaNita-RotaruandNinghuiLiDepartmentofComputerSciences

PurdueUniversityWestLafayette,IN47907

Abstract

Inthispaperweanalyzetherequirementsaccesscontrolmechanismsmustful llinthecontextofgroupcommunicationandde neaframeworkforsupporting ne-grainedaccesscontrolinclient-servergroupcom-municationsystems.Ourframeworkcombinesrole-basedaccesscontrolmechanismswithenvironmentpa-rameters(time,IPaddress,etc.)toprovidesupportforawiderangeofapplicationswithverydi erentre-quirements.Whiletheaccesscontrolpolicyisde nedbytheapplication,itse cientenforcementisprovidedbythegroupcommunicationsystem.

1Introduction

Manycollaborativeapplicationssuchasphoneandvideoconferencing,white-boards,distance-learningapplications,games,sharedinstrumentcontrol,aswellascommand-and-controlsystems,haveincommontheneedforacommunicationinfrastructurethatpro-videse cientmessagedisseminationtomultiplepar-ties(oftenorganizedingroupsbasedonacommonin-terest),e cientsynchronizationmechanismsthatal-lowforcoordinationandlast,butnotleast,securityservices.Groupcommunicationsystems(GCS)pro-videsuchservices.Examplesofgroupcommunica-tionsystemsinclude:ISIS[9],Horus[21],Transis[4],Totem[6],RMP[28],Rampart[20],SecureRing[13],Ensemble[24]andSpread[8,3].

Animportantaspectforsecurecollaborativegroupsisde ningandenforcingasecuritypolicy.Asetofdef-initionsandrequirementsofsecuritypoliciesingroupsispresentedin[12].Theminimalsetofsecurityser-vicesthatshouldbeprovidedbyanysecureGCSandshouldbespeci edinagrouppolicyinclude:clientau-thentication,accesscontrol,groupkeymanagement,dataintegrityandcon dentiality.

Whileconsiderableresearchhasbeenconductedto

designscalableandfault-tolerantgroupkeymanage-mentprotocols[29,23,5],andtoprovidedatacon -dentialityandintegrity[17,2,25,7]forgroups,lessworkfocusedontheaccesscontrolservices.WhenGCSareusedasacommonplatformbyseveralap-plicationswithdi erentsecurityrequirements,thereisanobviousneedtocontrolwhocanjoinagroup,whocansend/receivemessages,etc.MajorchallengeswhenprovidingaccesscontrolservicestoGCSarerec-onciling exibilitywithscalability,ande cientlyen-forcingaccesscontrolinthecontextofdynamicanddistributedgroupswhilesupportingprocessfailuresandnetworkpartitions.

MostexistingworkinprovidingaccesscontrolforgroupsemploystraditionalaccesscontrolschemessuchasAccessControlLists(ACL’s).Suchschemesmakeauthorizationdecisionsbasedontheidentityoftherequester.However,indecentralizedormulti-centricenvironments,theresourceownerandtherequesterareoftenunknowntooneanother,makingaccesscon-trolbasedonidentityine ectiveorveryexpensivetomaintain.

Weadoptanapproachinwhichtheoperationsaclientisallowedtoperformdependsontheroletheclientisplayinginthegroup,andauthenticatedat-tributesoftheclientareusedtodeterminewhichrolestheclientcanplayinagroup.WefocusonaGCSus-ingaclient-serverarchitecturewherethedistributedprotocolsarerunbetweenasetofserversprovidingservicestonumerousclients.Morespeci cally,ourcontributionsare:

WeinvestigatetherequirementsforaccesscontrolmechanismsinGCSandshowwhyidentity-basedschemesdonotprovideenough exibilitytosup-portalargeclassofcollaborativeapplications. Wedesigna ne-grainedaccesscontrolframeworkforGCS,basedonideasinRole-BasedAccessControl[26,10]andRT[15],aRole-BasedTrust-Managementlanguage.Ourframeworkallowsan

In this paper we analyze the requirements access control mechanisms must fulfill in the context of group communication and define a framework for supporting fine-grained access control in client-server group communication systems. Our framework combines ro

applicationtode neitsspeci cpolicieswhiletheenforcementisperformedinane cientmannerbytheGCS.Thisisachievedbyde ningasetofbasicgroupoperationsandrolesthatcanbecon-trolledandenforcedbytheGCS.Anyapplicationspeci cpolicycanbedecomposedintotheseba-sicoperationsandapplicationspeci crolescanbemappedtosystemroles.

Weanalyzewhataretheimplicationsofprocess(serversandclients)failuresandnetworkconnec-tivitychangesonthelifecycleofagrouppol-icyingeneral,andofanaccesscontrolpolicyinparticular,andsuggesthowtheseissuescanbeaddressed.RoadmapWediscussthefailureandtrustmodelsweuseinSection2.InSection3wepresentindetailsthecomponentsforagrouppolicy,whileinSection4wediscussthee ectsofprocessfailuresandnetworkpartitionsonthelifecycleofthepolicy.WeoverviewrelatedworkinSection5.Finally,wesummarizeourworkandsuggestfutureworkdirectionsinSection6.

2TrustandFailureModels

Inthissection,wediscussthetrustandfailuremod-elsweareusinginthispaper.

2.1TrustModel

Inclient-serverGCS,atrustmodelhastode nethetrustrelationshipswithineachlayer(trustrelationshipbetweenclientsandtrustrelationshipbetweenservers)aswellasbetweenlayers(i.e.doclientstrustserversornot).Giventhisenvironment,severaltrustmodelsarepossible,rangingfromamodelwherenoentitytrustsanyotherentityforanyoperation,bothwithinalayerandbetweenlayers,toanoptimisticmodelwhereserversandclientstrusteachothercompletely.Inthispaper,weadoptthefollowingtrustmodel: Serverstrusteachother:Inorderforthesystemtobebootstrappedcorrectly,alistoflegitimateserversshouldbeprovidedtoallservers,intheformofanACL.Settingupthislistisasystemadministrator’staskandnotanapplicationtask.Weassumethatthereisawaytoauthenticateaserverwhenitcomesupandverifywhetheritisontheauthorizedcon gurationlist.Onceauthenti-catedandauthorizedallserverstrusteachother.Wenotethatingeneralthenumberofserversissmallandthatthewaythesesystemsareusedis

rstde neaservers’con gurationthatprovidesbestperformanceforaspeci cnetworkenviron-mentandapplicationdeployment.Therefore,inthiscase,anACLisanacceptablesolution. Clientstrustserverstoenforcetheaccesscontrolpolicy.Thisassumptionisacceptablebecause,intheclient-serverGCSarchitecture,clientsal-readytrusttheserverstomaintaingroupmem-bershipandtotransport,orderanddelivergroupmessages,soitseemsnaturaltotrustthemalsoforenforcingtheaccesscontrolpolicy.Further-more,thiswillallowforamoree cientenforce-mentsinceinnumerouscasesthedecisioncanbemadebyeachserverlocally,diminishingthecom-municationoverhead. Clientsarenottrusted(eitherbytheotherclientsorbyservers).Therefore,compromisingoneclientdoesnotcompromisethesecurityofthewholesystem.

2.2FailureModel

Ourmodelconsidersadistributedsystemthatiscomposedofagroupofserversexecutingonseveralcomputersandcoordinatingtheiractionsbyexchang-ingmessages.Themessageexchangeisconductedviaasynchronousmulticastandunicast.Messagescanbelostorcorrupted.Weassumethatmessagecorrup-tionismaskedbyalowerlayer.Aclientobtainsthegroupcommunicationservicesbyconnectingtooneoftheservers.Aclientcanconnectlocallyorremotely.Bothclientsandserversmayfail.Whenaserverfails,alltheclientsthatareconnectedtothatserverwillstopreceivinggroupcommunicationservices;theyarenotredirectedtootherservers.

Duetonetworkevents(e.g.,congestionoroutrightfailures)thenetworkcanbesplitintodisconnectedsubnetworkfragments.Atthegroupcommunicationlayer,thisisreferredtoasapartition.Anetworkpar-titionsplitstheserversandcanpotentiallysplitsev-eralclientgroupsindi erentcomponents.Whilepro-cesses(serversorclients)areinseparatedisconnectedcomponentstheycannotexchangemessages.Whenanetworkpartitionisrepaired,thedisconnectedcompo-nentsmergeintoalargerconnectedcomponent,thisisreferredatthegroupcommunicationlayerasamerge.Firstserversaremerged,whichinturncantriggerseveralclientgroupstobemerged.

Byzantine(arbitrary)processfailuresarenotcon-sideredinthiswork.

In this paper we analyze the requirements access control mechanisms must fulfill in the context of group communication and define a framework for supporting fine-grained access control in client-server group communication systems. Our framework combines ro

3

APolicyModelforAccessControlinGroupCommunicationSystems

Inthissection,westudytherequirementsforspec-ifyingaccesscontrolpoliciesinGCSandproposeapolicymodelfordoingso.Ourgoalistodesignapol-icymodelthatis exibleenoughsuchthatitsupportsadiversi edsetofapplicationpolicies,Inaddition,thepolicymodelcanbee cientlyimplementedbytheGCS.Thebasicapproachweuseisasfollows.Foranygroupthereisasetofbasicoperationsthatcanbeper-formedbyprincipals(entities)basedontheirrole,inagivencontext.Themappingbetweengroupoperationsandroles,inagivencontext,de nestheaccesscon-trolpolicyforthatgroup.Thisway,insteadofhavingeveryindividualapplicationtoimplementandenforceitsownaccesscontrolmechanisms,wehaveapplica-tionsde ningspeci cpoliciesthataretranslatedtothesetofbasicoperationsthattheGCSisawareofandcanenforceaccesscontrolon.

Therestofthissectionisorganizedasfollows.Webeginbydescribinganexamplescenarioanddis-cussingthevariouspossibleaccesscontrolpoliciesinSection3.1.InSection3.2,wedescribethegroupop-erationsthataresubjectedtoaccesscontrol.Wean-alyzetheuseofrolesingrouppoliciesinSection3.3.WepresentthepolicymodelinSection3.4.InSec-tion3.5wedescribehowapolicyspeci edinthemodelisenforced.Wediscussthechallengesinmaintainingthepolicy,whiledealingwithdynamicmembership,failuresandnetworkpartitionsinSection4.

3.1AnExampleScenario

Consideravirtual-classroomapplicationimple-mentedusingaGCS.Multiplecoursesexistintheapplication.Eachcoursehasmultiplesessions,eachofwhichisrepresentedbyavirtualclassroom,im-plementedasagroup.Foreachcourse,therearein-structors(somecoursesmayhavemorethanonein-structors),TA’s,andstudents.Aclassroomshouldbecreatedonlybyanauthorizeduser;thusapolicycon-trollingthecreationofgroupsmustexistbeforethecreationofagroup.Wecallsuchapolicy,atemplatepolicy.Eachcoursehasatemplatepolicy.Sincetem-platepoliciesexistoutsidethecontextofanygroupandcanbeviewedasresourcesnotspeci ctoGCS,standardaccesscontroltechniquesareusedtocontrolthecreationandmodi cationoftemplatepolicies.Inthesimplestcase,onlytheGCSadministratorisal-lowedtocreateormodifytemplatepolicies.

Atemplatepolicydetermines,amongotherthings,whocancreateagroupbasedonthepolicy.Onepos-

siblegroupcreationruleisthatonlytheinstructorsofacourseareallowedtocreateaclassroomforthecourse.AnalternativeruleisthataTAmayalsocreateaclassroom.Onemayalsoallowthecourseinstructortodelegatetoanotheruser,e.g.,aguestlecturer,theauthoritytocreateaclassroom.

Aftertheclassroom/groupiscreated,agrouppolicyneedstobecreated.Agrouppolicycanbecreatedbycopyingthetemplatepolicy.Thisgrouppolicymaythenbetailoredtosuittheneedofthecurrentclass-roomsession.Onlyauthorizedusersshouldbeallowedtochangethegrouppolicy.

Varioususersmayjointheclassroomindi erentroles,e.g.,instructor,TA,student.Onlyauthorizedusersshouldbeallowedtojointheseroles.Forjoiningasastudent,di erentrulesaredesirablefordi erentcases.Examplesincludes:onlystudentswhoareen-rolledintheclassmayjoin,theinstructorortheTA’scanadmitadditionalstudentsinspecialcases,oronlystudentswhoareconnectingfromcertainIPaddressesmayjoin(e.g.,whentakinganexam).

Severalkindsofcommunicationmaybegoingonsimultaneouslyintheclassroom,andtheyshouldbesubjectedtodi erentaccesscontrolrules.Forexam-ple,communicationcanbepublic:lecturesdeliveredbytheinstructor,publicquestionsaskedbyastudentandtheanswerstothosequestionsbytheinstructororanothermemberoftheclassroom.Someclassroomsmayallowanystudenttofreelyaskquestions,muni-cationcanalsobeprivate,forexamplestudentsmaybeallowedtoaskquestionsprivatelytotheTA’s,orsubmittheiranswerstoaquizgiveninclass.Thein-structormaybealsoallowedtoejectastudentfromtheclassroom.

Wenotethatmostoftheaboveservicesarepro-videdbyaGCS,withoutanyaccesscontrolenforce-ment.Forexample,theSpread[8]groupcommuni-cationsystemallowsformulticast(public)anduni-cast(private)communicationwithinagroup,italsoallowsforanymembertobebothasenderandare-ceiverandcandistinguishbetweendi erenttypeofmessages,whileprovidingdi erentreliabilityandor-deringcommunicationservices.Inaddition,con den-tialityandintegrityofthedataisprovided.

3.2OperationsinGroups

Fromtheabovescenariodescription,wecanextractthesensitiveoperationsthatneedaccesscontrol.Thefollowingoperationsarenotperformedwithinthecon-textofagroup,theyprecedethegroupcreationand

In this paper we analyze the requirements access control mechanisms must fulfill in the context of group communication and define a framework for supporting fine-grained access control in client-server group communication systems. Our framework combines ro

arenotsubjectedtoagrouppolicyoratemplatepol-icy:1)createagrouptemplatepolicyand2)modifyagrouptemplatepolicy.

Acomprehensivelistofbasicoperationthatapplytoagroupandaretheobjectofaccesscontrolispre-sentedbelow:1.createagroup.

2.modifyagrouppolicy.3.joinagroup.

4.sendamessageofagiventype.5.receiveamessageofagiventype.6.ejectauserfromagroup.7.

destroyagroup.

Theabovelistdoesnotincludetheoperationofleavingagroupbecausethisisanoperationthatcannotbecontrolled.Itisimpossibletopreventaclientfromleavingagroup1.

Weallowseparatecontrolforjoiningagroup,send-ingamessage,andreceivingamessagetoprovidesupportforawiderangeofapplications.Forsomeapplicationsseveralgroupmembersmaybeallowedtosend,butnottoreceivemessages.Anexampleofsuchanapplicationisainformationreportingmilitaryapplicationwhereclientsusewirelesscommunication;itisdesirabletolimittheinformationclientsreceiveandstoretominimizethedamagecausedincaseofcompromise.Forotherapplications,somegroupmem-bersmaybeallowedtoreceivebutnottosendmes-sages.Forexample,inaconferencewithalargenum-berofparticipantsonlyrepresentativesmayanswerquestions,whiletherestoftheparticipantsarejustlistening.

3.3RolesinGroups

OneapproachtospecifyandenforceaccesscontrolistouseAccessControlLists(ACL’s).Underthisap-proach,agrouphasanACL,whichincludesasetofusersandtheoperationstheyareallowedtocarryout.Suchanapproachisappropriatewhenthenumberofprincipalsandoperationsissmallandstatic.Ingen-eral,ACL’shavethefollowingdisadvantages.First,ACL’scangetverylarge.Forexample,ifeveryregis-teredstudentinauniversityisallowedtojoinaclass-room,thentheACLwouldbesimplytoolong.Sec-ond,theACLoftenduplicatesinformationmaintainedinotherplacesanditsuseinadynamicdistributedsystemwillrequiremaintainingitsconsistencyacross

1Any

clientcane ectivelyleaveagroupbyclosingthecon-nectionwiththeserver.

severalsiteswhichcanbeverydi cultandpronetointroduceinconsistencyinthesystem.

FromthescenariodescribedinSection3.1,itisclearthatthesetofoperationsauserisallowedtocarryoutdependsupontherolethattheuserisplay-inginagroup.Forexample,althoughausermaybetheinstructorofacourse,inaguestlecturesessionshemaybeplayingaTAorastudentrole.

Wedistinguishbetweentwokindsofroles:systemrolesandapplicationroles.Systemrolesareprede- nedbytheGCS;theyexistineverygroupandhaveprede nedmeaningsintermsofoperationstheyareallowedtocarryout.Thefollowingaresystemrolesourframeworksupports:

(group)creator:thisrolehasatmostonemem-ber,identifyingtheuserthatistheoriginalcre-atorofthegroup,i.e.,the rstmemberofthegroup.Becauseoffailures,agroup’screatorrolemaybeempty. (group)controller:thisrolehasexactlyonemem-ber,whohasfullcontroloveragroup,includingchangingthepolicyforthegroupanddestroy-ingagroup.Whenausercreatesagroup,itisautomaticallymadethecreatorandthecon-trollerofthegroup.Wedi erentiatethegroupcreatorfromthegroupcontrollerforseveralrea-sons.First,thecreatorofagroupmaywanttotransferthecontrollerresponsibilitiestoanothermemberofthegroup;forexample,aTAmaycre-ateaclassroombeforetheinstructorcomesandthen,aftertheinstructorjoins,transfertheroletotheinstructor.Second,evenwhenthegroupcreatoristheoriginalcontroller,itmaycrashorleavethegroup,inwhichcaseanothermemberneedstoassumethegroupcontrollerrole. (group)member:anyuserwhojoinsagroupisautomaticallyamemberofthisrole.Eachsystemrolecomeswithasetofallowedoper-ationsandhasasetofoperationsthatcanbemore negrainedde ned.Forexample,foraclientwiththerolegroupmemberrestrictionsonsendandreceivecanbede nedbasedonthemessagetype.

Eachgroupmayalsohaveasetofapplication-speci croles,forexample,inthevirtualclassroomsce-nario,thefollowingapplicationrolesmaybeneeded:instructor,TA,student,auditor.

Onceauserjoinsagroup,theusermayalsoperformthefollowingoperationsrelatedtoroles:1.assumearole.2.droparole.

In this paper we analyze the requirements access control mechanisms must fulfill in the context of group communication and define a framework for supporting fine-grained access control in client-server group communication systems. Our framework combines ro

3.appointanotherusertoarole.4.removeanotheruserfromarole.

Weallowaclienttodroparoleatitswill;however,theotherthreeoperationsaresubjectedtoaccesscon-trol.

Theaccesscontrolpolicyofthegroupde nestheoperationseachroleisallowedtocarryout.Inotherwords,agroupaccesscontrolpolicymapseachroletoasetofoperations.Atanytime,auserinagroupplaysasetofroles.Whenauserisabouttoperformanaction,therolesthattheuserisplayingareusedtodeterminewhethertheactionshouldbeauthorizedornot.Therolesandpermissionsthattheapplicationde nesaremappedtosystemrolesandoperationsaGCSisawareofandcanenforce.

3.4

AModelforAccessControlPoliciesinGCS

Clientsmustbeauthenticatedbeforeanaccesscon-trolpolicyisenforced.Severalauthenticationmech-anismsarecommonlyused.AGCSmayprovideausername/passwordbasedauthenticationmechanismormayuseanexternalauthenticationsystemsuchasKerberos[14,18].TheclientmayconnectwiththeserverthroughTLS/SSL[1]withclientauthenti-cation,inwhichcasetheclient’spublickeyandX.509[22]DistinguishedNameareavailable.Anothersolu-tionishavingtheclienttousecerti catesthatdocu-mentattributesoftheclients,e.g.,certi catesintrustmanagementsystemssuchasRT.

Thesetofoperationsaclientisallowedtocarryoutmaydependonmorethanjusttherolesoftheclient;environmentalfactorsmayalsohaveane ect.Forexample,astudentmaybeallowedtoattendalectureifhe/sheisregisteredfortheclassandifthestudentjoinsthe“classgroup”inaparticulartimeframe,afterthelecturestarted,he/shecannotjointhegroup.Toaccommodatethediversi edauthenticationmethodsandthee ectofenvironmentalfactorsinac-cesscontrol,weintroducethenotionofcontexts.TheGCSmaintainsaclientcontextforeachconnectedclientandagroupcontextforeachgroup.Agroupcontextconsistsofasetofname/valuepairs,inwayssimilartoUnixenvironmentalvariables.Agroupcon-textprovidesenvironmentalinformationsuchascur-renttimeandgroupstateinformation(e.g.,lecturehasbeganinaclassroom).Theclientcontextissimi-lartoagroupcontext;itstoresinformationspeci ctoaclient,suchastheIPaddressfromwhichtheclientisconnectingandtheresultofauthentication(e.g.,authenticatedattributesoftheclient).

Thecombinationofrolesandcontextcanaccom-modateawiderangeofapplicationswithverydiversepolicyrequirements.Adescriptionofourmodelofgroupaccesscontrolpolicies,aswellasanexamplepolicyarepresentedin[19].

3.5

EnforcingAccessControlinGroupCommunicationSystems

WhenenforcingaccesscontrolinGCSitisveryimportantwhoismakingtheaccesscontroldecisionandwhoisenforcingit.Rememberthatweconsideraclient-serverarchitecture,whereservicetoclients(organizedingroups)isprovidedbyasetofservers.Manygroupscanexistinthesystem.

Onesolutionistohaveaccesscontrolenforcedbygroupmembers(clients).Althoughthisapproachseemsappealingbecauseinfactaccesscontrolpoli-ciesaregroupspeci c,itdecreasesthescalabilityofthesystemsinceeachgroupmustperformitsownen-forcementmechanism.Additionally,whenaccesscon-trolisperformedbyclients,accessrestrictionssuchasdroppingmessagesandrequestsatthereceiveraremoredi culttoprovide.

Asclientsarealreadytrustingtheserversformain-taininggroupmembershipanddeliveringandorderingcorrectinformation,thesecuritymodelisnotweak-enedbyrequiringtheserverstoalsoperformtheac-cesscontrolenforcement,thepotentialbene tbeingincreasedscalabilityandmore exibilityoftheoper-ationsthatcanbeenforced.Basedongroup’spolicy,serversmust rstreachadecision,ifaccessisgrantedornot,andthenenforcethatdecision.Wedistinguishbetweentwogeneralapproaches:

localdecision:onlyoneserverisrequiredtomakeadecision.Forexample,whenaclientrequestsaccesstoagroupduringajoinoperation,theservertheclientisconnectedtocanmaketheac-cesscontroldecisionlocallybasedontheclient’srole,groupnameandgrouppolicyandenforceitimmediately.

distributed(collaborative)decision:thepolicyre-quiresseveralserverstocollaborateinordertoreachadecision,byusingforexampleavotingmechanism,suchasagivenpercentageofgroupmembersofacertainrolehavetoapprove.Thisapproachrequiresacompleteviewofallthemem-bersofallrolesofagroup,informationavailabletotheservers.Onefundamentalquestionishowdoestheapplica-tionspeci caccesscontrolpolicytranslatesintoapol-icythattheGCSunderstands.Thistranslationcanbe

In this paper we analyze the requirements access control mechanisms must fulfill in the context of group communication and define a framework for supporting fine-grained access control in client-server group communication systems. Our framework combines ro

operatedbyaPolicyTranslationEnginethatparsesthegrouppolicyandoutputsanother lethattheGCSwilluseinmaking/enforcingaccesscontrol, lethatde nespermissionbasedontherolesandoperationsthattheGCSimplements.Twoadditionaloperationsarerequiredonceapolicyisinplace.The rstoneinvolvesacheckonmakingsurethatthepolicydoesnotincludeanycontradictoryrules.Thesecondonerelateswiththeonethepolicyisdistributedtotheotherserversandmakesurethatallservershavethesamepolicy.Incasethepolicyisstaticallisneededisthatthepolicyiscerti ed(digitallysigned)anddis-tributedbyaserver.Incasethepolicyisdynamic,thepolicy leshouldbetreatedasreplicateddataamongthesetofservers.

Besidesdecisionreaching,anotherimportantaspectiswhoisenforcinganoperation.Formostoftheoperations,theenforcementcanbedonelocallybytheserverthatmakestheauthorizationdecision.Forothergroupoperations,suchasgroupdestroying,theserverenforcingthedecisioncanbedi erentfromtheonemakingthedecision.Forlackofspacewecouldnotincludeadetaileddescriptiononhowenforcementisperformedoneachgroupoperations.Thisinforma-tionisavailablein[19].

4

LifeCycleofanAccessControlPol-icy

Intheprevioussectionwedescribedhowa ne-grainedaccesscontrolpolicyforGCScanbede nedandenforcedinamodelwherefaultsdonothappen.Unfortunately,thisisnotthecaseintherealworldwhereprocessescancrash,computerscanfail,net-workmis-con gurationscanhappen,orthenetworkoverloadcancreateunusuallatenciesthatcanbeper-ceivedasnetworkpartitions.Inthissectionweexam-inehowfailuresandnetworkconnectivitya ectthelifecycleofthepolicy.

Thelifecycleofapolicyisde nedbythepolicycreationandsubsequentupdates.Asdescribedintheprevioussectionweassumethatbasedonanapplica-tionpolicy’sspeci cationsagrouptemplateisgener-ated.ThecreationandrevisionofagrouptemplateishandledbytheadministratorofaGCS.Basedonthetemplate,agrouppolicyiscreatedwhenaclientallowedtocreategroups,createsagroupbasedonthetemplate.

Anaccesscontrolpolicycanbestatic,inotherwordsitcanneverchangeduringthelifeofthegroup,oritcanbedynamic,inwhichcaseitcansu er

changes.Incaseofdynamicpolicies,apolicyrecon-ciliationmustbeperformedinmanycases.Asshownin[16],policyreconciliationcannotalwaysbesolv-able,inwhichcasethequestioniswhathappenstothegroup.Forexample,currentgroupmembersthatdonotsatisfythepolicyanymorecanbeexcludedfromthegroup.Thistaskcanbetakenbythegroupcon-troller.Notethateveninthecaseofstaticpolicies,policyreconciliationcannotbeavoidedwhenseveralgroupsneedtobemerged.

Wenowdiscusswhathappenswhentwoormoregroupsneedtobemerged.Ifthegroupstobemergedhavetheoriginsinthesamegroup–e.g.theyaretheresultofanetworkpartitionthatseparatedagroup–andifthegrouppolicyisstatic,thegroupsshouldinfacthavethesamepolicysonoreconciliationwillbenecessary.Whatneedstobeaddressediswhowillbecomethenewgroupcontroller,sinceeachpolicyspeci esthesamegroupcreatoroftheoriginalgroup,butdi erentcontrollers.

Anothercaseiswhengroupswiththesamenamewerecreatedindependentlyinpartitionedcompo-nents.Somesystemsuniquelyidentifygroupsbasedonlyonthegroupname,sotheywilltrytomergethegroups,which,canpossiblyhavedi erentpolicies.Again,thereisnoguaranteethatareconciliationispossible.Incaseareconciliationisnotpossible,theserverscandecidetodestroythegroupandinformallclientsthatthegroupwasdestroyedbecauseapolicyreconciliationwasnotpossible.IftheGCSidenti- esgroupsnotonlybyname2,thengroupscreatedindependentlyinpartitionedcomponentswillbein-terpretedasdi erentgroupsandnomergeandpolicyreconciliationwillberequired.

Fromthepreviousscenariositisapparentthatthepolicyframeworkshouldspecifyandprovidesupportfortheselectionofanewgroupcontroller.Thereareseveraleventsthatcandrivesuchaneed:

aclientorservercrashed:Theclientthatcrashedwasthegroupcontroller,ortheserverthatcrashedwasservingthegroupcontroller3.

anetworkpartitionoccurred:Thegroupcon-trollerwillenduponlyinonenetworkcomponent,whiletheothercomponentswillneedtoselectanewgroupcontroller.

anetworkmergeoccurredandpolicyreconcili-ationwaspossible:Inthiscasethenewmerge

2One

possibilityistoaddalsotheidenti eroftheserver

thatrepresentstheentirecon gurationofserversinanetworkcomponent.

3Ourfailuremodelassumesthatclientsarenotredirectedwhentheservertheyareconnectedtocrashes,soalltheclientsconnectedtothatserverwillfailtoo.

In this paper we analyze the requirements access control mechanisms must fulfill in the context of group communication and define a framework for supporting fine-grained access control in client-server group communication systems. Our framework combines ro

groupwillhavetoselectoneofthegroupstobemergedcontroller,asthenewgroupcontroller.WhilewewanttheGCStomakethedecisions,wewouldliketoprovidetheapplicationwiththeabilitytospecifythepolicy.De ninghowfailuresshouldbehandledcanbedonebytheapplication.Ofcoursesomedefaultpoliciescanbeused,incaseanapplica-tiondoesnotwanttodealwithit.Faultscana ectclientsaswellasservers,soafailurehandlingpolicyshouldbede nedforbothclientsandservers.

Belowwearguewhyafailurehandlingpolicyisre-quiredforbothclientsandservers.Considerthecaseofselectinganewgroupcontroller.Ifagroupcon-trolleralreadyexists,changingthegroupcontrollercanbeachievedbyasimpleroledelegation.Incaseagroupismerged,severallegitimategroupcontrollerswillexist(oneforeachsubgroup),the“oldest”con-trollerwillbeselectedasthenewgroupcontroller.Aninterestingcaseiswhenthegroupcontrollerfailedandthereisnoauthoritythatcanperformtheroledelegation.Inthiscasewecande neanexten-sionoftheroleoftheclientasagroupcontrollertotheserverthatheisconnectedto,sotheservercantemporarilytakeovertheroleofthegroupcontrollerandjustdeterministicallyselect(actingasadelega-tor)anewgroupcontrollerfromalistprovidedbytheapplication.Iftheapplicationdidnotprovidesuchalist,thiswillbeperceivedasafatalfailureandtheservercanjustdecidedestroyingthegroup.

Now,considerthattheserveritselfcrashed.Inthiscase,thesetofserversmustdecidewhichoneofthemwilltakeoverthetaskofselectingthenewgroupcon-troller.Thiscanbedoneinseveralways,theeasiestisforexampletodeterministicallyselectanyoftheservers(let’ssaythe rst).Iftheapplicationwantstorestrictthistoaparticularsetofservers,itcanpro-videanorderedsetofpotentialtake-overserversorapercentageifavotingpolicyisdesired.

5RelatedWork

Thereareseveralgroupcommunicationsystemsthatconsideredaccesscontrol.TheEnsemblese-curegroupcommunicationsystem[24,25]assumesthe‘fortress’modelwhereanattackcancomeonlyfromoutside.Thesystemusesasymmetric-keybasedkeydistributionschemeandusesAccessControlList(ACL)asaccesscontrolmechanism.TheACListreatedasreplicateddatawithinthegroup.

In[2]accesscontrolingroupsisprovidedbyus-inganauthorizationservice,Akenti[27],whichrelies

onX509[22].Themethodusedistohaveallgroupmembersregisteringwiththeauthorizationserviceo -linetoobtainamembershipcerti catesignedbytheAkentiserver,andthenwhenthegroupmembershipchanges,everymemberveri esthemembershipcer-ti cateandthepersonalcerti cateofeverymember.Theapproachreliesonidentityforaccesscontrolandprovidesacoarsegranularityforaccesscontrol.

Relevanttoourwork,butsomehoworthogonalistheAntigone[17]framework.Antigoneprovidesapolicyframeworkthatallows exibleapplication-levelgroupsecuritypoliciesinamorerelaxedmodelthantheoneusuallyprovidedbygroupcommunicationsys-tems.Alsorelevanttoourworkis[11]thatde nesgen-eralrequirementsandcomponentsforasecuregrouppolicy.

Mostofthesystemsdescribedaboveprovideac-cesscontrolbasedonidentityofparticipantsanddonotdiscusshowfailurescana ecttheenforcementofpolicies.Asopposetoabovedescribedschemesourapproachisnotidentity-based.Instead,wetakead-vantageofrole-basedaccesscontrol[26,10]andRT[15],afamilyofRole-basedTrust-managementlan-guages,tode nea ne-grainedaccesscontrolframe-workforgroupcommunicationsystems.Suchsystemshavebothscalabilityandfault-tolerancerequirements.Wereasonedabouthowtheserequirementscanbemetwhileproviding exibilitytotheapplicationinde n-ingspeci cpolicies.

6Conclusions

Inthispaperwehaveanalyzedtherequirementsaccesscontrolmechanismsmustful llinthecontextofgroupcommunicationandde nedaframeworkforsupporting ne-grainedaccesscontrolforgroups.Ourframeworkcombinesrole-basedaccesscontrolmecha-nismswithenvironmentparameters(time,IPaddress,etc.)toprovidepolicysupportforawiderangeofap-plicationswithverydi erentrequirements.Inordertoprovideboth exiblepolicyande cientenforcement,weusethegroupcommunicationserverstodecideandenforceaccesscontrol.Weidentifythesetofallpossi-blegroupoperationsthatcanbecontrolledandde nethegrouppolicyasamappingbetweenrolesandop-erationsusingcontextasconstraints.Inaddition,wesuggestawayinwhichfailurepolicycanalsobespec-i edbytheapplication.

Severalthingsremaintobeaddressedinfuturework.Theyinclude:providinga“user-friendly”inter-faceforourframeworksothatpoliciescanbegener-atedinanautomaticwaybasedonuserspeci cations

In this paper we analyze the requirements access control mechanisms must fulfill in the context of group communication and define a framework for supporting fine-grained access control in client-server group communication systems. Our framework combines ro

anddesigningandimplementingaparserenginethatcantranslateapplicationspeci cpoliciesinsystem-understandablepolicies.

References

[1]TheTLSPro-tocolVersion1.0.Number2246inRFC.T.Dierksand

C.Allen,1999./rfcs/rfc2246.html.[2]D.A.Agarwal,O.Chevassut,M.R.Thompson,and

G.Tsudik.Anintegratedsolutionforsecuregroupcommu-nicationinwide-areanetworks.InProceedingsofthe6thIEEESymposiumonComputersandCommunications,Hammamet,Tunisia,July2001.[3]YairAmir,ClaudiuDanilov,MichalMiskin-Amir,John

Schultz,andJonathanStanton.TheSpreadtoolkit:Archi-tectureandperformance.Technicalreport,DS-2004-1,JohnsHopkinsUniversity.[4]YairAmir,DannyDolev,S.Kramer,andD.Malki.Tran-sis:Acommunicationsub-systemforhighavailability.Di-gestofPapers,The22ndInternationalSymposiumonFault-TolerantComputingSystems,pages76–84,1992.[5]YairAmir,YongdaeKim,CristinaNita-Rotaru,John

Schultz,JonathanStanton,andGeneTsudik.Securegroupcommunicationusingrobustcontributorykeyagreement.InToappearinTransactionsonParallelandDistributedSystems,September2003.[6]YairAmir,L.E.Moser,P.M.Melliar-Smith,D.A.Agar-wal,andP.Ciarfella.TheTotemsingle-ringorderingandmembershipprotocol.ACMTransactionsonComputerSystems,13(4):311–342,November1995.[7]YairAmir,CristinaNita-Rotaru,JonathanStanton,and

GeneTsudik.Scalingsecuregroupcommunicationsys-tems:Beyondpeer-to-peer.Inthe3rdDARPAInfor-mationSurvivabilityConferenceandExposition(DISCEXIII),Washington,D.C.,April2003.[8]YairAmirandJonathanStanton.TheSpreadwidearea

groupcommunicationsystem.TechnicalReport98-4,JohnsHopkinsUniversity,CenterofNetworkingandDis-tributedSystems,1998.[9]KenethP.BirmanandRobertV.Renesse.ReliableDis-tributedComputingwiththeIsisToolkit.IEEEComputerSocietyPress,March1994.[10]DavidF.Ferraiolo,D.RichardKuhn,andRamaswamy

Chandramouli.Role-BasedAccessControl.ArtechHouse,April2003.[11]H.Harney,A.Colegrove,andP.McDaniel.Principlesof

policyinsecuregroups.InNetworkandDistributedSys-temsSecurity,SanDiego,CA,February2001.[12]HughHarney,AndreaColegrove,andPatrickMcDaniel.

Principlesofpolicyinsecuregroups.InNetworkandDis-tributedSystemsSecuritySymposium,2001.[13]KimPotterKihlstrom,LouiseE.Moser,andP.M.Melliar-Smith.TheSecureRingprotocolsforsecuringgroupcom-munication.InProceedingsoftheIEEE31stHawaiiInter-nationalConferenceonSystemSciences,pages317–326,January1998.

[14]JohnKohlandB.Cli ordNeuman.TheKerberosNetwork

AuthenticationService(Version5).RFC-1510,September1993.[15]NinghuiLi,JohnC.Mitchell,andWilliamH.Winsbor-ough.Designofarole-basedtrustmanagementframe-work.InProceedingsofthe2002IEEESymposiumonSecurityandPrivacy,pages114–130.IEEEComputerSo-cietyPress,May2002.[16]P.McDanielandA.Prakash.Methodsandlimitationsof

securitypolicyreconciliation.InIEEESymposiumonSe-curityandPrivacy,pages73–87,Oakland,CA,May2002.[17]PatrickMcDaniel,AtulPrakash,andPeterHoneyman.

Antigone:A exibleframeworkforsecuregroupcommuni-cation.InProceedingsofthe8thUSENIXSecuritySym-posium,pages99–114,August1999.[18]B.Cli ordNeumanandTheodoreTs’o.Kerberos:An

authenticationserviceforcomputernetworks.IEEECom-municationsMagazine,pages33–38,September1994.[19]CristinaNita-RotaruandNinghuiLi.Aframeworkfor

role-basedaccesscontrolingroupcommunicationsystems.Technicalreport,2003.CERIASTR-2003-31,PurdueUni-versity.[20]MichaelK.Reiter.Secureagreementprotocols:reliable

andatomicgroupmulticastinRampart.InProceedingsofthe2ndACMConferenceonComputerandCommunica-tionsSecurity,pages68–80.ACM,November1994.[21]R.V.Renesse,K.Birman,andS.Ma eis.Horus:A municationsoftheACM,39:76–83,April1996.[22]ITU-TRec.X.509(revised).TheDirectory-Authentica-tionFramework.InternationalTelecommunicationUnion,1993.[23]O.Rodeh,K.Birman,andD.Dolev.Optimizedgroup

rekeyforgroupcommunicationsystems.InProceedingsofISOCNetworkandDistributedSystemsSecuritySympo-sium,February2000.[24]OhadRodeh,KenBirman,ingAVL

treesforfaulttolerantgroupkeymanagement.TechnicalReport2000-1823,CornellUniversity,ComputerScience;Tech.Rep.2000-45,HebrewUniversity,ComputerScience,2000.[25]OhadRodeh,KenBirman,andDannyDolev.Thearchi-tectureandperformanceofsecurityprotocolsintheEn-sembleGroupCommunicationSystem.ACMTransactionsonInformationandSystemSecurity,4(3):289–319,August2001.[26]RaviS.Sandhu,EdwardJ.Coyne,HalL.Feinstein,and

CharlesE.Youman.Role-basedaccesscontrolmodels.IEEEComputer,29(2):38–47,February1996.[27]MaryR.Thompson,AbdelilahEssiari,andSrilekha

Mudumbai.Certi cate-basedauthorizationpolicyinaPKIenvironment.ACMTrans.Inf.Syst.Secur.,6(4):566–588,2003.[28]B.Whetten,T.Montgomery,andS.Kaplan.Ahighper-formancetotallyorderedmulticastprotocol.InTheoryandPracticeinDistributedSystems,InternationalWorkshop,LNCS,page938,September1994.[29]ChungKeiWong,MohamedG.Gouda,m.

Securegroupcommunicationsusingkeygraphs.InPro-ceedingsoftheACMSIGCOMM’98,pages68–79,1998.

本文来源：https://www.bwwdw.com/article/vq9m.html